вторник, 6 декабря 2011 г.

blogspot.com bug? feature?

После того, как на blogspot.com пользователь меняет фотографию профиля в старых комментария этого пользователя светится старая фотография. Фича илл всё таки баг?


P.S. Надеюсь хозяйка блога приведенного в пример на скриншоте не будет против. Пусть будет реклама ;-)

понедельник, 24 октября 2011 г.

Мысли про English

В очередной раз затронута плодотворная в плане холивара тема английского языка для тестировщиков. А почему бы и... да.
Сначала о хорошем – на все 100% согласен со всем сказанным Натальей Руколь в её посте, но есть и ложка дегтя, может даже половничек, всё зависит от масштабов трагедии.

Ремарка: дальше будет больно, особам с тонкой душевной организацией не читать.

Такая, например, гипотетическая ситуация.
Имеется два соискателя на одно место в аутсорсинговую компанию. Один с хорошим опытом., testing skill прокачан дай боже, но средним английским, второй практически (или не практически) без опыта, зато english skill прокачан выше среднего. Кого берут? Правильно, того, кто сможет читать доки и писать письма. Первый конечно может со временем подтянуть английский, но то когда будет, а надо уже сейчас. О честно-нечестно, справедливо или нет, даже и речи не идёт. Жизнь она вообще интересная штука - у кого-то борщ постный, у кого-то жемчуг мелкий, не о том речь. То, что наш первый герой не владеет английским на должном уровне это личные проблемы. Второй владеет, второй молодец. Господа рекрутёры, чьё резюме полетит в корзину? Кто не удовлетворяет требованиям компании? Кто не способен удовлетворить иноземный менеджмент? Кто не способен красиво и грамотно отмазаться на понятном выставляющим претензии языке?.. В итоге мы имеем некоторое число хорошоанглокомуницирующих, но таксебетестирующих специалистов с, допустим, филфаком за плечами и весьма поверхностным погружением в пучину непосредственно тестирования. Вроде бы ничего страшного, сколько их там таких, можно отмахнуться и забы(и)ть... а отрасль-то растет, ширится и множится популяция и в этой популяции несть числа подобным. Вроде знание английского должно помогать отличать QA от QC, ан нет - не помогает, smoke от regression – и тут мимо, blackBox-whiteBox - опять не туда... это же база, коллеги, это должен знать каждый. Зато в СV все пишут QA и сами в это верят. Вы с такими сталкивались? Я, увы, да. И почему большинство программистов предвзято относятся к тестировщикам? А если только такие примеры перед глазами что им бедным остается-то! Почему рейтинг профессии не шибко высокий? Хотя нельзя не признать, что в последнее время становится всё лучше. Почему нас тестирующих считают низшей ступенью эволюции в IT? Незрелость умов и рынка? (Хм... а неплохой каламбур вышел умов -это условий по-украински). Несведущесть работодателей?
Не факт, коллеги, не факт...
Увы, но не всё так с английским просто, как кажется на первый взгляд...

P.S. А английский всё-таки нужен. По крайней мере в условиях Украинского IT бизнеса, когда компаний работающих на внутренний рынок раз два и обчелся, а остальные работают на иностранных заказчиков, играя по их правилам, в том числе и языковым. Так что учите English господа, не только, как тестировщики желающие развиваться и совершенствоваться, но и как умные образованные люди!
Коллеги, удачи и вдохновения!

пятница, 30 сентября 2011 г.

Притча

Сегодня остро вспомнилась одна притча.
"Один подмастерье пришел к мастеру и спросил:
-Мастер почему ты платишь мне за работу 5 рублей, а Петру который работает так же как я - 10.
Мастер вместо ответа посмотрел на улицу и спросил:
- Видишь телегу?
- Вижу, - ответил подмастерье.
- Узнай, что везут.
Подмастерье убежал. через время вернулся
- Картошку везут.
- Узнай куда везут.
Подмастерье убежал.
- На рынок. - ответил подмастерье.
- А по чем продавать будут?
Опять убежал подмастерье. Вернулся
- По гривенному за мешок.
- А если всю телегу взять, дешевле отдадут?
Убежал подмастерье.
- Ну скинут маленько, - принес ответ.
-Хорошо, - ответил мастер. - зови Петра.
Пришел Петр, указал ему мастер на телегу:
- Узнай что везут.
Воротился Петр и говорит
- Везут картошку, на рынок продавать будут по гривенному за мешок ежели всю телегу брать, то скинут цену.
Повернулся Мастер ко второму подмастерью:
-Теперь ты понял почему я плачУ ему больше чем тебе."

Вот почему некоторые люди сами не хотят думать своей головой? Решать задачи, брать ответственность за эти решения на себя? Оно понятно, что когда кто-то скажет, что и как делать гораздо проще и спокойнее. Но зачем же потом хлопать себя ушами по щекам и требовать признания по сути за чужой труд? А ведь иногда доказательство того, что ЭТО должен сделать кто-то другой забирают времени больше, чем само решение проблемной задачи.

четверг, 22 сентября 2011 г.

Люди процесса. Люди результата.

Ситуация с новым сотрудником, который, не отработав даже испытательного срока, уволился, и это не смотря на солидное резюме и опыт работы в непоследних IT компаниях Украины, натолкнула не некоторые мысли. Ему не подошел наш процесс тестирования. Точнее сначала не подошел процесс, а потом добило то, его(процесс) не захотели взять и резко организовать так, как он того хотел и видел. В целом специалист был неплохой, но капризный, предлагать, как улучшать наш, сложившийся не хотел, но так работать не смог. Понять почему всё именно так, тоже не смог или не захотел.
Процесс у нас действительно неоднозначный и далек от эталонного. Проекты с которыми работает наша компания связаны с электронной коммерцией, динамичная область, придумываются и реализовывается достаточно большое количество фич, меняется функционал и пр... (бывает до 5 коммитов на продакшн в день!!!) и всё это в очень сжатые сроки. Потому как потерянное время = потерянные деньги. Проектов не один, не два, даже не пять. Каждый тестирующий занят в нескольких проектах. Такая вот особенность работы. Естественно, времени на медленные танцы нет и не всегда есть окончательный вариант требований, не всегда требования попадают к тестировщику перед началом разработки и есть время досконально всё распланировать, написать детальные тесткейсы и пр... Это не значит, что имеет место авральный манки-кликинг, требования фиксируются, анализируются тестовая документация тоже ведется, остаются артефакты тестирования - чек листы, наборы тестовых сценариев и данных. Такова вот наша специфика, наш процесс и изо дня в день мы стараемся сделать его лучше, но работаем мы всё же на результат.
Приятно, конечно, работать плавно, размеренно где-то даже предсказуемо, как пишут в книгах, статьях, учат на тренингах, но это матрица, а реальный мир вносит коррективы и не всегда в лучшую сторону. Но никто кроме нас самих нам ничего делать не будет. Не будет менеджер всё бросать и делать всё как мы хотим только потому, что мы ему так сказали. Его надо убедить, доказать, аргументировать, а не требовать и ждать пока нам сделают хорошо из того что есть.
Профессионализм, как раз и заключается в умении работать в сложных и нестандартных ситуациях, выжимая при этом максимум пользы. Профессионал вместо того, чтобы просто возмущаться “У вас всё плохо и неправильно”, не прилагая никаких усилий и даже не предлагая вариантов решения проблем, кроме как “менеджеры должны...”, работает с тем что есть, знает к чему стремиться и делает из того что есть, что должно быть. Причем работает эффективно.
К чему это я? К тому, что заметил, что везде, и тестирование тут не исключение, есть люди ориентированные на процесс, а есть люди ориентированные на результат. Люди процесса и люди результата. Одни сразу видят цель и к ней идут, другие идут к цели через процесс. Одни стремятся "ходить сквозь стены" - видеть цель, верить в себя и не замечать препятствий, другим надо, чтобы то, что надо было там где надо и когда надо. Делать выводы кто лучше, а кто хуже глупо - это принципиально разные подходы к работе. Невозможно сразу пробиться к цели полностью игнорируя процесс. Невозможно строить процесс без четкого понимания "зачем". Самый длинный путь начинается с маленького шага, но путь этот должен куда-то вести.
Чего всё таки должно быть больше в специалисте по тестированию процесса или результата? Какая пропорция приносит больше пользы проекту? команде? самому специалисту? Не будут ли эти пользы конфликтовать между собой? Как определить что лучше в данный момент? Кого брать в команду, а кого наоборот выводить из неё?
Есть над чем подумать.

вторник, 23 августа 2011 г.

Developers black book

Developers Black Book (к Славе Панкратову и его "Черной книге менеджера отношения не имеет").   Нашлось на бескрайних просторах инфернета книга хоть и девелоперовская, но тестировщикам тоже может принести немало пользы - коды символов, ошибок, ошибок памяти, серверных ответов и многое другое.

четверг, 14 июля 2011 г.

Баги в Cut the rope

 Cut the rope - игра первоначально появившаяся для продукции "корпорации зла имени г-на Джобса", цель которой (игры, а не корпорации) кормить забавную, по всем признакам, амфибию, леденцами, получила широкое распространение на Android и в последствии даже хаброодобренна
Профессия, наверное, накладывает отпечаток - нашел и в ней баги.
1. SetUp достаточно долгий - дойти до 21-го уровня седьмой по счету  коробочки - космической.
2. Натянуть с помощью поворотного механизма нижнюю веревочку по максимуму
3. Перерезать нижнюю веревочку

4. И конфета улетает в неизведанное пространство, две верхние веревочки при этом сращиваются в одну.
5. И как результат, вместо довольного животного имеем грустное.

P.S. прошу прощения за столь скверные скриншоты

четверг, 9 июня 2011 г.

Когда подводит память

Бывает что при большом количестве пользователей JMeter вдруг перестает поддерживать  заданное количество повторений заданным количеством пользователей, количество запросов упирается в потолок и всё... пытаешься сохранить в CSV файл хотя бы то что уже насобиралось, а он открывает окно сохранения и очень надолго уходит в страну вечной охоты.

Помог запуск JMeter с принудительным определенным заранее памяти с которой придется работать. Точнее это даже не самому  JMeter, а java машине. Выглядит сам запуск примерно так:

java -Xms512m -Xmx512m -XX:MaxPermSize=256m -jar ApacheJmeter.jar

-Xms512m  - память выделяемая с самого начала, в нашем случае это 512М, можно и 1Г (1g)  дать, сколько не жалко, но не больше чем есть.
-Xmx512m  - максимальное количество выделяемой памяти.
Рекомендуют эти две величины задавать одинаковыми, что бы не отвлекать java машину постоянными пересчетами сколько ей нужно памяти.
 -XX:MaxPermSize=256m - максимальный объем памяти выделяемый "куче"

Для удобства сделал себе bat-ник
"путь к каталогу с jmeter\bin
java -Xms512m -Xmx512m -XX:MaxPermSize=256m -jar ApacheJmeter.jar "






четверг, 2 июня 2011 г.

Мониторинг производительности сервера.

Много где писано , что мониторинг производительности сервера на котором установлено нагружаемое приложение это хорошо, полезно,  а главное красиво, но током найти как собственно подключать и настраивать монитор мало где и то по урывками. Вот всё что удалось найти, систематизировать и собственно применить.

В моем случае был jboss. на его примере и рассмотрим. Для начала не будет лишним убедиться, что можно к нему достучаться.  Идем по ссылке вида
http://jboss.server.com:8080/status 
или что бы посмотреть сырой XML который потом будет парситься
http://jboss.server.com:8080/status?XML=true
вобщем нам нужно знать где лежит этот преславутый XML и есть ли к нему доступ.
Если есть то не мудрствуя лукаво добавляем в Thread Group  "Add">>"Sampler" >>
"HTTP Request" где надо указать 
Server name - сервер или его IP 
Port number - порт 
Path - путь к месту куда сервлет кладет XML 
Добавить параметры в сервлет что бы он возвращал результат как  XML: 
Name = "XML," Value = "true"
Отметить чекбокс "Use as monitor"
Если требуется авторизация то перед этим запросом надо добавить 
HTTP Authorization Manager
Немаловажно добавить к нашему Server Status-у таймер. Нужно это для того чтобы 
дать устаканиться переходным процессам  которые обязательно будут когда на 
сервер пойдет, генерируемая нами, нагрузка и подпортят нам общую картину.
3-8 секунд вполне достаточно
 
И торжественным финалом добавляется Monitor Results listener.
"Add">>"Listeners">>"Monitor Results"

суббота, 21 мая 2011 г.

Считаем md5

Пришлось нагружать JMeter-ом вход в чат, а там имя пользователя, адрес электронной почты и ещё кой чего  генерируется автоматически скриптами в момент создания теста, передается в переменные с которыми потом тест и оперирует.  Сервер же сам считает md5 от входящих  параметров   и при совпадении, даёт добро на логин. Решилась задача вот так - в BeanShell Pre(Post)Processor ну или где там надо  md5 считать его(  Processor) вставляем, внутрь процессора вставляем скрипт следующего содержания (Java код  по сути)
 
setStrictJava(true);
import java.security.MessageDigest;
import java.math.BigInteger;
import java.lang.System;

String nick=String.valueOf(System.currentTimeMillis());
String email=nick+ "@dev.com";

String var1 = vars.get("VAR1");
String var2= vars.get("VAR2");
...
String varN= vars.get("VARN");

String params=var1+var2+...+varN;
log.info("params: " + params);

MessageDigest md = MessageDigest.getInstance("MD5");
byte[] md5hash = new byte[32];
md.update(params.getBytes("utf-8"), 0, params.length());
md5hash = md.digest();

BigInteger bigInt = new BigInteger(1,md5hash);
String hashtext = bigInt.toString(16);
// Now we need to zero pad it if you actually want the full 32 chars.
while(hashtext.length() < 32 ){
  hashtext = '0'+hashtext;
}
vars.putObject("key",hashtext);

и на выходе в переменной    key имеем то, что нам надо )))
  P.S. не ахти чего конечно, но у меня 2 рабочих часа забрало. может для кого и не проблема, но я по образованию не программист...

Темная сущность тестирования.

Господа, мы тёмные.
Теперь обо всём по порядку. Недавно, мне друзья-коллеги-начальство подарили электронную книгочиталку. И не "образовывайся неучь", а на день рожденья (приятно, честно говоря, работать в таком коллективе). Первое, что сделал. конечно, это распотрошил торренты не предмет литературы. Стянул-слил фантастов любимых Стругацких, Снегова, Г.Л. Олди, А Валентинова, Арсения Миронова, Е. Лукина, М.Успенского, Марину и Сергея Дяченко... потом вспомнил и про С.Лукьяненко с его "Дозорами". тем более что "Дневной Дозор" он вместе с В. Васильевым писал, а Васильев,  всё таки земляк - николаевец, но не в этом дело... Взял я пару литров чешского темного (грешен, питаю слабость к темному "Velkopopovický Kozel" особенно, как свежего в Праге пил... ) и залёг читать любимые моменты. На втором бокале понял - мы, господа тестировщики, самые, что ни на есть темные. Темные-притёмные. Мы честнее, мы не созидаем, мы охотнее признаём свои ошибки, мы... да спросите любого разработчика и 90% скажет, что мы зло))) А чего стесняться-то. да мы темные и последняя картинка  в посте ситха Александра (  http://seljava.blogspot.com/2011/05/blog-post_03.html  ) только, подтверждает, у нас есть печеньки, а если нет -мы знаем, где взять ... Как известно, "благими намеренияими выложена дорга в Ад", наши же намерения отнюдь не благие, ergo, мы торим дорогу в Рай, товарищи! Ура! Ура!!Ура!!! Мы темные и не должны этого стесняться и скрывать. Мы темные, но стоим на страже света! Ave, testerus! Ave!

Тестировщик это не профессия...

Пересматривал на днях "ДМБ". Есть там фраза "Нет, военный это не профессия, это половая ориентация". Тестировщик, наверное, тоже не совсем профессия...

среда, 18 мая 2011 г.

"Hello world!"

"Hello world!"
Именно так, поскольку все, что связано с программированием начинается именно так, а тестирование, как ни крути, а с программированием таки связано. Хотя нет, начинается на самом деле с "Урок 1",а "Hello world!" уже потом... но это лишние детали. Тем более, что по старой шутке тестировщиков - прогорамма без багов будет способна только на "Hello world!".
Так что "Hello world!"
Во времена когда блоги есть практически у каждого,а  у некоторых даже не один, и звёзды стали таким образом, что завелся у и меня этот зверь... вобщем, как говорится, родилось - воспитывай, завел блог - пиши. А почему бы и нет? Почему бы не завести себе такую записную книжку в которой можно хранить нароботки и приводить в порядок мысли? Если оно ещё и окажется кому-то полезным - существенное улучшение кармы. Всем добро пожаловать!