« Я тестер ! »

Как стать экспертом в тестировании

noreply@blogger.com (Maksim Grinevich) — Tue, 09 Feb 2010 09:32:00 +0000

Вот оно! Теперь понятно, как стать настоящим экспертом в тестировании, нужно всего лишь...

Спасибо уважаемому Andy Glover'y за тестирование в комиксах!

The Rise And Fall of Waterfall

noreply@blogger.com (Maksim Grinevich) — Fri, 05 Feb 2010 16:58:00 +0000

Наконец-то уважаемый Zenegment (в жизни Максим Дорофеев) завершил свой короткометражный фильм The Rise And Fall of Waterfall.

Этот фильм-клип обещал быть интересным ещё по трейлеру.

Смотрите здесь или идите в его ЖЖ, там можно и откомментировать :).

Самая острая память

noreply@blogger.com (Maksim Grinevich) — Thu, 04 Feb 2010 10:06:00 +0000

И вновь я возвращаюсь к теме цитат из народа.

«Самая острая память тупее самого тупого карандаша».

Если хотите что-то запомнить — запишите.

Сниму квартиру в Москве

noreply@blogger.com (Maksim Grinevich) — Mon, 25 Jan 2010 14:02:00 +0000

В связи со сменой места работы и переездом в стольный город Москву ищется место проживания для себя и своей семьи.

Все требования и пожелания далее по тексту...

Итак, требования:

Месторасположение — естественно Москва — район метро Беговая, Полежаевская, Октябрьское поле, Щукинская, Тушинская или Савеловская, Дмитровская, Тимирязевская
Две комнаты (три многовато, но при хороших условиях можно и такой вариант посмотреть)
Телефон (нежелательно отключение 8ки)
Internet
Длительный срок аренды (не хочу через год судорожно искать квартиру, потому что у Вас изменились обстоятельства жизни; но в то же время понимаю, что все мы люди )
Заключение договора аренды — защита и для Вас и для меня

Пожелания:

Мебель: ту всё зависит от ситуации, если все остальное подходит, то можно и почти пустую квартиру — но в пожелания допишу — минимум мебели: кухонные шкафчики, секция или какие-нибудь шкафы для одежды — будет очень кстати и т.д.
Нужна квартира из «неэлитного» сегмента — просто обычная московская двушка (максимум трешка), в хорошем состоянии.
Не выше третьего этажа

Кто снимает:

Квартира нужна лично мне — семья из 4х человек, двое из которых дети (девочки: 1 и 2,5 года). Опыт аренды квартир на длительный срок имею. Плачу своевременно. Все первоначальные договоренности выполняю :). И вообще положительный арендатор. Из домашних животных возможны только две черепахи в аквариуме (по полу не ходят, не гадят, не воняют и шерсть не оставляют).

Сроки:
Здесь все определено достаточно жестко: хотелось бы въехать и счастливо начать жить в промежутке между 28 февраля и 10 марта. Посмотреть квартиру получиться в это же время.

Цена:

Здесь всё просто — она зависит от квартиры. Это ведь как с работой — разговоры о зарплате после интервью. Но обратите внимание на требование "неэлитного" жилья.

Агентам и агентствам:
Рассмотрю обращение к профессионалам, но сделаю это сам и только к тому, кто будем иметь соответствующее имя/рекомендации.

P.S.: Коллеги, если у Вас есть подходящий вариант — готов общаться в почте (m.grinevich@yatester.ru), аське (171-418-911), скайпе (maksim.hrynevich) и других контактах.
P.P.S.: Если квартира находится в другом месте или какие-то условия частично не совпадают — пишите мне в таком случае. Я готов рассмотреть и смежные варианты.

И в завершение:
Прошу прощения у коллег, кто ожидал увидеть в этом посте что-нибудь про тестирование :)

Update: добавил новые станции метро, которые в принципе подходят.

Суеверия тестировщиков

noreply@blogger.com (Maksim Grinevich) — Mon, 18 Jan 2010 15:10:00 +0000

Суеверие — суетная вера — вера в пустое.

Тестировщики, как и все остальные земляне, не остаются в стороне и верят. Верят, порой не имея особых на это оснований...

Профессиональное:

в проекте обязательно должна быть позиция тестировщика
если хватит времени проверить весь тестируемый продукт, то мы найдем все ошибки
внедрение автоматизации уменьшает объем рутинной работы
хорошо описанная документация — наше все! Нет документов — нет качества.
качество продукта зависит о тестировщика
выпуск релиза в срок — к очень хитрой ошибке, которую заказчик найдет при первой же проверке

Менеджерское (о тестировании):

тестировщики стоят дешевле программистов
если на проекте появляется новый тестировщик, вырастает количество ошибок, которые напишут программисты
чем больше времени на тестирование, тем меньше ошибок попадет к заказчику
тестировщики не просят дополнительного времени на тестирование — «они что там совсем не работают?»

Программистское:

приход / письмо / «typing» в мессенджере от тестировщика — к багу
тестировщик долго тестирует и молчит / нервно курит / ехидно улыбается / щебечет с такими же, как сам — к бООльшому багу

~~Пост~~ Кризисное:

если не дали бонусов в прошлом году/квартале/месяце, то в следующем обязательно дадут
смена работы — не к добру.

А во что верите вы?

P.S.: Возможно не все из перечисленного суеверия...

Приключения майора Звягина

noreply@blogger.com (Maksim Grinevich) — Wed, 13 Jan 2010 11:52:00 +0000

Недавно Денис Петелин дал почитать довольно интересную книгу Михаила Веллера «Приключения майора Звягина».

Даже не знаю, почему так случилось, что я её не видел раньше.

Книга о том:

как надо жить, чтобы жизнь была в радость — но без пустых нравоучений
как мужественно противостоять проблемам — но без кичливого самовосхваления
как можно добиваться своих целей — но без инструкций типа «25 шагов и вы у цели»
что зачастую один человек может помочь другому — считая выгодой для себя саму возможность решить трудную головоломку
что нужно дарить радость жизни тем, у кого её нет — а на средства достижения смотреть не стоит
как управлять людьми — но так, что люди даже не подозревают об этом
как мотивировать людей — но без заезженных игр/забав/прибауток

Далеко не все методы майора Звягина приемлемы для меня, но эпилог книги очень многое объясняет. Советую прочитать, особенно тем, кто любит читать про судьбы известных/неизвестных людей. (тут этого нет в чистом виде, но жанр сохранен)

От издателя:

В этой книге много тайн, и все они раскрываются на удивление просто. Во-первых, Звягин — не майор. Ну — бывший майор. Во-вторых, приключения его — никакие не приключения. Эта книга — «наука побеждать» и добиваться любой поставленной цели в наших обыденных условиях. Человек может все — вот гениальная идея романа. Может переломить судьбу, стать любимым и счастливым, преодолеть даже смертельный недуг. За десять лет общий тираж «Звягина» приблизился к миллиону.

Скачать

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

В главном — единство...

noreply@blogger.com (Maksim Grinevich) — Mon, 11 Jan 2010 17:34:00 +0000

«В главном — единство,

во второстепенном — свобода,

во всем — любовь»

Августин Блаженный

Единство:

Знают ли все члены вашей команды цель своей работы? Вы уверены, что цели ключевых фигур проекта совпадают? Вы можете однозначно сказать в нескольких словах, какова цель вашего проекта? Причем не в «космических кораблях, которые бороздят просторы...» ©Шурик_или_кто-то_там_другой.

Только тогда проект/билд/релиз/и т.д. будет успешен, когда ВСЕ, именно все, члены команды будут работать на эту главную цель.

Когда цель ясна:

— длительные рабочие дни (которые лучше уже называть рабочими сутками) не вызывают претензий;

— успешность деятельности не соразмеряется с уровнем зарплаты;

— удовлетворенность/увлеченность работой перевешивает какие-либо межличностные конфликты;

— т.д.

Причем, на мой взгляд часто дело даже не в проекте (был один проект, будет другой). Зачастую важно, что бы продуктивная команда знала, зачем они работают. Почему нужно выпускать софт, за который не стыдно. Почему, когда один начинает «лажать», другие вынуждены нести и его ношу ответственности на своих плечах. Ведь кажущаяся мелочь работы одного, второго, третьего — и вот уже их часть работы сваливается непосильным грузом на того четвертого, кто просто вынужден выполнять всю оставшуюся работу.

Свобода:

Свобода это хорошо, это даже просто великолепно, но только если оно идет после единства. Таким образом получается, что каждый член команды свободен в выборе способов достижения цели, если эти способы не есть суть главное. Каким образом тестировщики будут осуществлять нагрузочное тестирование все на самом деле побоку — главное, чтобы исходя из проекта это отвечало требованиям бизнеса. Каким образом программист положит значение вот в этой форме — пусть решит он в своем свободном профессиональном полете мысли — главное, чтобы это шло в унисон с целью проекта.

Любовь:

Святой Августин был верующим человеком, поэтому он оперировал и таким понятием как любовь. Что же такое «любовь» в контексте IT сферы? Ведь там где бизнес и деньги, там нету места чувствам. Кажется так говорили новоявленные «бизнесмены» последних 2-х десятилетий прошлого столетия? Тогда на самом деле нужны были винтики, человеко-роботы, которые никогда не ломаются и не болеют, не имеют вредных привычек и разных характеров. Сейчас же у нас совершенно другое время: сейчас не только работодатель выбирает себе работника, но и работник зачастую перебирает — где же ему будет комфортно работать. Подробнее об этом написал «директор белорусской силиконовой долины» .

Вот тут и проявляется своеобразная любовь между работодателем и работовыполнителем, которая проявляется с одной стороны в:

— интересных проектах/задачах

— финансовой компенсации проведенных за работой часов (читай зп)

— хороших условиях труда

— чего_кому_ещё_надо

С другой же стороны это выражается в:

— высокоорганизованной работе над проектами/задачами

— самоотдаче

— продуктивности

— всего_чего_надо_заказчику

О том, как работник и компания находят друг друга через половой отбор написано здесь.

В итоге:

Если нет последнего, то грош цена тому единству и свободе. Тут расписывать не буду — и так понятно, что отсутствие описанной «любви» накладывает неизгладимый отпечаток на цели и решения такого специалиста.

P.S.:

Как ни странно, но действительно умные замечания старцев работают даже тогда, когда они были сказаны совершенно по другому поводу.

С Рождеством Христовым!

noreply@blogger.com (Maksim Grinevich) — Thu, 24 Dec 2009 22:58:00 +0000

1. Если я говорю языками человеческими и ангельскими, а любви не имею, то я -- медь звенящая или кимвал звучащий.

KJV: Though I speak with the tongues of men and of angels, and have not charity, I am become as sounding brass, or a tinkling cymbal.

2. Если имею [дар] пророчества, и знаю все тайны, и имею всякое познание и всю веру, так что [могу] и горы переставлять, а не имею любви, -- то я ничто.

KJV: And though I have the gift of prophecy, and understand all mysteries, and all knowledge; and though I have all faith, so that I could remove mountains, and have not charity, I am nothing.

3. И если я раздам все имение мое и отдам тело мое на сожжение, а любви не имею, нет мне в том никакой пользы.

KJV: And though I bestow all my goods to feed the poor, and though I give my body to be burned, and have not charity, it profiteth me nothing.

4. Любовь долготерпит, милосердствует, любовь не завидует, любовь не превозносится, не гордится,

KJV: Charity suffereth long, and is kind; charity envieth not; charity vaunteth not itself, is not puffed up,

5. не бесчинствует, не ищет своего, не раздражается, не мыслит зла,

KJV: Doth not behave itself unseemly, seeketh not her own, is not easily provoked, thinketh no evil;

6. не радуется неправде, а сорадуется истине;

KJV: Rejoiceth not in iniquity, but rejoiceth in the truth;

7. все покрывает, всему верит, всего надеется, все переносит.

KJV: Beareth all things, believeth all things, hopeth all things, endureth all things.

8. Любовь никогда не перестает, хотя и пророчества прекратятся, и языки умолкнут, и знание упразднится.

KJV: Charity never faileth: but whether there be prophecies, they shall fail; whether there be tongues, they shall cease; whether there be knowledge, it shall vanish away.

Библия, 1-е Коринфянам, 13:1-8

Желаю каждому иметь в сердце любовь, надежду и веру!

С Рождеством Христовым!

Искусство управленческой борьбы

noreply@blogger.com (Maksim Grinevich) — Mon, 07 Dec 2009 08:38:00 +0000

Недавно с подачи моего друга Игоря Колосовского начал ~~читать~~ слушать книгу "Искусство управленческой борьбы" от В.К. Тарасова.

Должен сказать, что книга местами неоднозначна, как собственно и все в нашей жизни: ведь и атом изначально придумывали как мирный, а получилось "как всегда". Пусть местами я не согласен с автором, но все равно советую послушать/почитать.

"Книга посвящена методам и технике успешного ведения борьбы за перехват и удержание управления, которой так богата жизнь каждого активного человека: будь то руководитель любого ранга, предприниматель, политик или школьный учитель. Книга не имеет аналогов и, без всякого сомнения, станет настольной для многих и многих людей. И дело не только в том, что она учит побеждать, но и в том, что помогает квалифицированно избегать борьбы там, где она не нужна и даже вредна для обеих сторон, что чаще всего и имеет место в нашей противоречивой жизни."

Скачать книгу в mp3:

~~Часть 1~~

~~Часть 2~~

~~Часть 3~~

~~Часть 4~~

Скачать в pdf или посмотреть.

Купить на ozon.ru

Будь реалистом...

noreply@blogger.com (Maksim Grinevich) — Wed, 25 Nov 2009 08:13:00 +0000

Очередная цитата из народа после долгого перерыва:

«Будь реалистом - требуй невозможного!»

Вырастим себе замену?

noreply@blogger.com (Maksim Grinevich) — Mon, 23 Nov 2009 08:41:00 +0000

«вы - письмо Христово, через служение

наше написанное не чернилами, но Духом

Бога живаго, не на скрижалях каменных,

но на плотяных скрижалях сердца.»

Библия (2-е Коринф. 3:3)

Уже не раз сталкивался среди знакомых с тем, что при повышении или переходе с одного проекта на другой лидера группы или менеджера — некого поставить взамен. Вроде сам менеджер вполне успешен, да и команда попалась весьма продуктивная. Но когда вопросы касаются роста из инженеров в лиды или менеджеры, то сразу слышны слова «Некого поставить», «поставили Василия, потому что больше некого, а не потому что он достоин», «придется искать на стороне, т. к. среди команды нету человека, который может взять бразды руководства в свои руки» и т.д.

Думаю, что ситуацию я обрисовал вполне конкретно.

На днях, когда общался с одним человеком совершенно по другому поводу, он сказал мне замечательные слова: «Мы — то самое письмо из эпиграфа.» Т.е. когда мы работаем, мы показываем модели поведения своим подчиненным. Мы своей работой учим их делать нашу работу. Ни один тренинг или семинар не даст столько информации, лучших практик, известных ошибок, и прочего, как работа рука об руку с хорошим менеджером проекта.

Так а в чем проблема тогда, если лучше всего учиться у коллег, они всегда рядом, но людей то не хватает?

Думаю, что проблема собственно в самих менеджерах и лидерах команд. Они не стремятся воспитать себе замену. Их больше заботит — что конечно же правильно — работа команды, её продуктивность, выполнение конкретных задач. Но ведь если ты нацелен на рост. Ты знаешь, что рано или поздно ты будешь подниматься по должности и званию, так почему же не вложить в своих коллег? Почему не сделать свой рост себе же легче — ведь если будет кому занять Ваше место, тем раньше вы сможете занять место «по выше», «по теплее». Тут конечно есть много не обозначенных моментов (а вдруг вырастет коллега на столько ,что его поставят на то место, где я вижу себя; а вдруг он уволиться, а я планировал его на свое место и т.д.), но, на мой взгляд, лучше попробовать, чем ничего не делать и получить потом себе в подчинение неадекватного лидера команды или менеджера проекта.

Успеть везде или оправдать ожидания.

noreply@blogger.com (Maksim Grinevich) — Thu, 19 Nov 2009 08:58:00 +0000

Уже не раз на просторах интернета звучало:
— узнавайте то, что от Вас ожидают;
— делайте это;
— делайте больше (перевыполняйте) этого.

И тогда всем Вам будет счастье:
— Ваш начальник будет повышать Вас в должности и поднимать Вам зарплату;
— Ваша жена и дети будут самыми счастливыми людьми на свете (ещё бы: не каждой муж дарит миникупер и всячески проявляет свою любовь и преданность, не каждый папа дни напролет проводит в парке с детьми и дарит им самые последние «модные» игрушки ); (если Вы жена и мама, то представьте адекватный сценарий)
— Ваши друзья будут счастливы видеть Вас на рыбалке и в бане и т.д.

Но умудренный опытом человек правильно возмутиться: «Да на это всё и в таких количествах не хватит и трех жизней!!»

Так как же успеть ВСЁ? Оставим пока в стороне семейную жизнь и вернемся к тестированию:
— Как успеть проверить все багофичи? и при этом
— ... обновить документацию по проекту в соответствии с текущими изменениями требований? и при этом
— ... собрать метрики по отделу/проекту/билду ? и при этом
— ... прояснить ожидания от тебя начальника/ сослуживцев(тестировщиков, программистов и других обитателей IT компании) ? и при этом
— ... замечать изменения в отношении к работе коллег по отделу, их заинтересованность в одних проектах и не желание работать с другими? и при этом
— ... и много чего ещё при этом, но за 8 часов в день и 40 часов в неделю?

Частично в этом могут помочь:
— классная снежинка от Славы Панкратова
— интересная Помидорная техника
— ну и куда же мы денемся от Дэвида Аллена и его GTD
— расставление приоритетов согласно проектным нуждам
— ставьте цели и добивайтесь их! А может и не надо!
— А вдруг что-то ворует ваше время? Защита от темных искусств.

НО — почему всегда есть это «НО»?

Так уж получается у нас, что большинство хороших советов остаются хорошими советами. Мы пробуем что-то делать и с течением времени это сходит «на нет». Мы читаем умные книги, находим много интересного, но потом остываем...

А всё потому, что мы основываемся на эмоциях, вместо того, чтобы брать решение в основании своих действий. Ты не просто что-то делаешь из-за такого яркого и искрометного докладчика, который уже чуть ли не танцует перед тобой, а потому что ты решил изменить что-то в своей жизни/работе и ищешь способы это сделать. Эмоции правят миром - и поэтому мы так часто получаем не то, что хотим.

Решите изменить свою работоспособность и продуктивность — найдите те техники и методы, которые помогут вам это сделать (а не просто будут «модными» и разрекламированными) — используйте эти методы и средства — получите результат! В процессе Вас могут обуревать различные эмоции — это ни хорошо, ни плохо — это эмоции и с ними интереснее жить. Но не давайте эмоциям взять верх над Вашим решением!

Артефакты тестирования: быть или не быть?

noreply@blogger.com (Maksim Grinevich) — Wed, 11 Nov 2009 10:32:00 +0000

Вот наконец-то до меня добралась запись моего выступления на Test Labs 2009. Это моя первая копеечка в копилку слайдкастов.

В середине и в конце презентации идут вопросы-ответы, поэтому некоторые паузы явно слышны.
Буду рад прочитать ваши замечания/дополнения/комментарии.

Приятного время препровождения ;)

Артефакты тестирования: быть или не быть?

View more presentations from Magrix.

Вызвать C#.Net dll в QuickTestPro (VBScript)

noreply@blogger.com (Maksim Grinevich) — Thu, 29 Oct 2009 13:09:00 +0000

Есть у меня необходимость использования в рамках автоматизации внутренних библиотек dll, написанных на C#. Однажды гуглив столкнулся с фразой, что некомовские (non-COM) библиотеки нельзя использовать в VBScript. Тогда на этом шаге остановился и обошелся переносом кода тогда ещё маленькой функции на VBScript.

Теперь же дела обстояли иначе: функций на самом деле было не мало, да и их реализация должна была бы занять достаточное время. И значит, поиски начались сначала.

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

Создаем новую C# dll с кодом:

namespace namespacename
{
    public class classname
    {
        public int GetValue()
        {
            return 1;
        }
    }
}

Теперь в QTP пишем:

Set obj = DotNetFactory.CreateInstance("namespacename.classname", "c:\\namespacename.dll")
MsgBox obj.GetValue()

Вот и всё, теперь наша библиотека работает в QuickTest'e.

Есть небольшой нюанс: по своей глупости мне казалось необходимым после пути к dll ещё одним параметром ставить micString - тип возвращаемого значения. И в таком виде оно не работало - ругалось на меня почти матными словами.

Удач в использовании QTP ;)

Первые шаги в Google Wave

noreply@blogger.com (Maksim Grinevich) — Wed, 21 Oct 2009 10:31:00 +0000

Тут давеча уважаемый Samat Jukeshov прислал приглашение в Google Wave. Уже много раз слышал про этот новый сервис от Google'a. Теперь пришло время пощупать.

Сейчас пользователям дана только Preview версия, но это только начало. Они обычно вообще не спешат выходить на релизы с такими штуками - помните сколько их почтовый сервис висел в Beta версии?

Тем, кто ещё не слышал про это, будет полезно посмотреть вот это видео (1 час 20 минут!! ).

Мой пост скорее направлен к тем, у кого аккаунт к этому чудо-сервису уже есть: давайте wave'иться, господа. Заодно и протестируем сей сервис! Мой Wave Address: maksim.hr@googlewave.com

Буду рад познакомиться и поговорить. Дабы не нести чепуху или флуд, предлагаю несколько тем для обсуждения (реальное использование - есть лучшее тестирование):
- внедрение автоматизации там, где её до сих пор не было: проблемы, known issues, know how, etc. Ссылка на волну
- внедрение процессов (создание отдела/группы/команды) тестирования там, где их до сих пор не было. Ссылка на волну.
Обе темы мне интересны самому, признанным экспертом не являюсь, поэтому ожидаю конструктивное общение.
- но можно-таки и просто пофлудить :) (+ обсудить этот блог) Ссылка на волну.

Когда мне будет дана возможность раздавать приглашения - обязательно отпишусь.
Upd: т.к. меня самого пригласили в ближайшее время получить возможность раздавать приглашения у меня не будет :(

Судя по комментам всех беспокоит возможность получения приглашения. Его можно получить здесь www.inviter.ru

UPD2: Сейчас только ленивый не получил ещё приглашение. Но если Вы таков, то я готов Вас пригласить. Один момент: совсем незнакомых людей звать не буду. Вот вы бы хотя бы в читателях отметьтесь :).

Тестирование GUI или сферический конь в вакууме

noreply@blogger.com (Maksim Grinevich) — Wed, 07 Oct 2009 05:00:00 +0000

Тестирование GUI (graphical user interface) очень редко проходит отдельно от основного функционального тестирования. Конечно:

- бывают большие проекты, где этому уделяется внимание;

- бывают пропущены серьезные проблемы, после которых все тестировщики проекта некоторое (зачастую недолгое) время тестируют ГУЙ / ГУИ / УЙ / УИ / UI / GUI

Вот скажите мне, разве можно тестировать то, принципы чего сам до конца не понимаешь? Разве можно найти ошибки в калькуляторе, если не знаешь таблицы умножения?

Многие менеджеры считают, что можно! И тогда все тестировщики становятся не только ГУИтестерами, они сразу ещё и ГУИтворители (ведь программисты исправят ровно так, как это скажет тестировщик).

Такая ситуация очень похожа на историю возникновения самих тестировщиков: программисты (или их начальники) поняли, что писать код и выпускать ПО без ошибок не одно и то же!

Я понимаю, должно пройти время, когда всем станет более-менее понятно: функциональное тестирование и тестирование графического интерфейса пользователя - должны делать разные по своей профессиональной подготовке люди!

Ладно, от теории перейдем к практике.

Предположим, что у нас есть окошко, где нужно выбрать период выпуска на прогулку сферического коня из вакуума. У нас есть два поля для ввода даты: Date From и Date To и кнока Submit.

Кроме дизайно-цветового решения всё выглядит даже ничего: можем задать даты и нажать кнопку Сабмит.

Умный тестировщик проверит эти поля на ввод разных значений: прошлый век, наше время, будущее время, (возможно) проверит ситуацию From >To и т.д. А вот когда этим начнет пользоваться конюх сферического коня в вакууме и реально захочет настроить даты выгула этого животного, он встретит реальные проблемы.

Одна из них - как мне настроить выгул коня только на один день? Поставить Date From = 10/07/2009 и Date To = 10/07/2009? Такое правило зачастую не сработает, ведь мудрые девелоперы сохраняют в базу данных ещё и время, а для обоих дат это будет 00:00:00. Можно поставить Date From = 10/07/2009 и Date To = 11/07/2009, но откуда мне как пользователю знать, что мой конь не будет гулять два дня, вместо одного?

Только методом проб и ошибок, запросов на изменение и приперательств с поставщиком ПО.

А вот если бы тестировщик посмотрел заранее в книгу про ГУИ тестирование, на минуту представил себя конюхом в штанах с кожей на жопе коленях, подумал о ежедневном выгуле любимого коня - все могло бы быть совсем иначе.

Не буду продолжать сей короткий опус, но скажу лишь одно - я сам попался на такое - мне не понравилось, и теперь буду представлять себя ковбоем/конюхом/или другим пользователем тестрируемого софта.

Как я ездил на Test Labs 2009...

noreply@blogger.com (Maksim Grinevich) — Wed, 30 Sep 2009 05:19:00 +0000

Эта конференция началась для меня ещё примерно за месяца полтора - подготовкой доклада, получилось или нет - узнаю позже, когда Слава пришлет обещанные фидбэки.

По организации конференции претензий нет - всё сделано умеренно хорошо. Без вложения денег в несущественные вещи (майки, пластиковые бэджи и т.д.), но в то же время обед, на пример, был вкусным.

Ладно, перейдем к делу. В самом начале у меня была проблема: в одно время выступали два человека(Максим и Алексей), попасть на которых мне очень хотелось. Оказалось, что одного доклада не будет и все разрулилось. Первым я пошел на доклад Алексея Баранцева "Во что верят тестировщики?". Заметил, что многие признанные учителя в области плавно переходят из рассказов о конкретных вопросах к общей философии: в качестве примера приведу твиттер у James Marcus Bach - он уже давно философствует о тестировании (и просит спрашивать, если вас волнует что-то конкретно). Так и Алексей решил убедить всех относится более философски к работе тестировщика... Из-за нехватки времени (спасибо задержке на 15 минут открытия конфы) доклад местами получился скомканный, но, надеюсь, у него получилось сказать то, что он хотел. Над этим докладом нужно много думать...

Практически без перерыва следующим выступать стал Налютин Никита - он рассказал, как сделать из сами_знаете_чего конфетку. Мне его доклад был весьма интересен, уж много чего из его описаний подходило под моего работодателя :).

Затем подошла очередь выступить мне... Говорил об артефактах тестирования, когда их стоит писать, когда нет. Вопросы по ходу презентации и после порадовали увлеченностью слушателей. Честно говоря, думал, что все заснут на первых порах. Т.к. храпа не было слышно, считаю свою задачу выполненной... :)

Если присланный фидбек будет иметь не низкий результат, обязательно напишу об этом...

Как я писал ранее - обед удался!

Выступление Александра Якимы (надеюсь правильно просклонял его фамилию) в некотором роде подтвердило истинность фразы: в Agile нужно верить. А кубики, об которые я чуть не сломал глаза, отчетливо показали иллюзорность некоторых особенностей гибки методологий. Понравилось, что у него получилось сделать доклад интерактивным - сами участники делали "заранее" запланированные выводы. Здоровский доклад с точки зрения приобретения новой информации.

Ну и последний доклад Максима Дорофеева про борьбу обезьян и роботов как и всегда порадовал живостью и рисованными карандашом иллюстрациями. Возможно ничего нового я не услышал, но зато КАК это было!!! Вот обязьянобот, который стал итогом всей презентации.

Хотелось послушать Юлию Нечаеву и Александра Александрова, но... надеюсь следующий раз получится.

Ещё отзывы о конференции написали:

Юлия Нечаева, Khizhnyak, Слава Панкратов

Организаторы обещали выложить материалы на сайте конференции.

P.S. Если вы слушали меня, буду рад прочитать ваш отзыв в комментариях к этому сообщению.

5 способов ответить на нечестные вопросы начальства

noreply@blogger.com (Maksim Grinevich) — Thu, 17 Sep 2009 04:00:00 +0000

Автор: Matt Heusser

Перевод: Максим Гриневич

Читая черновик этой статьи, я понял, что хочу перевести её на русский язык и разместить у себя в блоге.
Оригинал статьи от Matt Heusser размещен здесь.

Если вы проработаете в тестировании достаточно времени, то не раз встретите ситуации, когда вам зададут вопросы. Часть из них будет вполне разумными и честными, другая часть – наоборот. В этой статье я помогу вам обнаружить и обезоружить такие вопросы, начиная с самого известного «Почему тестировщики пропустили эту ошибку?»

Около 20 лет назад Tom DeMarco говорил о нечестных вопросах IT в своей статье Why does software cost so much?. Конечно, DeMarco не задает вопросы, он утверждает или предлагает тактику ведения переговоров. Такие вопросы часто так же возникают и в тестировании ПО. Вот мои любимые:

«Почему тестировщики не нашли эту ошибку?»
«Почему именно тестирование является «узким местом» проекта?»
«Почему у нас столько ошибок?»
«Что мы можем сделать, чтобы улучшить производительность отдела тестирования?»
«Мы уже закончили тестирование?»

В зависимости от ситуации эти вопросы могут быть правильными и логичными. Но давайте посмотрим какие утверждения спрятаны за этими вопросами:

«Тестировщики должны были найти эту ошибку»
«Тестирование – слабое место проекта»
«У нас слишком много ошибок»
«Тестирование занимает слишком много времени»
«Тестирование должно быть завершено сейчас.»

Здесь и оценки и осуждения. Зачастую спрашивают таким способом, что разумные, логичные, правдивые ответы – всего лишь ... попытка защитить себя.

Доверие и безопасность.

Такие вопросы – это своеобразный трюк или техника. Руководство предполагает, что в ПО слишком много ошибок, и тестировщики несут за это прямую ответственность.

Лучшим ответом на эти вопросы будет занятие позиции, при которой они просто не будут заданы, - предотвратить это можно через обучение и общение. Стоит начать с внесения ясности руководству о том, что будет протестировано, в самом начале проекта. Затем, когда вы найдете ошибку, вы можете сказать: «4 недели назад мы договорились о том, что будет протестировано – за рамки этого я не вышел.» Другой способ – образование: я знаю одного менеджера , который подарил своему начальству в качестве новогоднего подарка копию Perfect Software: And Other Illusions about Testing.

Предупреждение проблем – это хорошая цель, но боюсь, что это не поможет тестировщикам, которым приходится отвечать на такие вопросы прямо сейчас. Итак, моя цель сейчас – обезоружить вопрос, показать что такое осуждение не эффективно и направить команду на путь движения к честности, безопасности и командной работе. Делая это последовательно в итоге можете получить следующую ситуацию. Ваш новый вице президент задает похожий вопрос и тогда кто-нибудь из программистов или Product Managers объясняет ему на сколько данный вопрос нечестен. По крайней мере на это можно надеяться.

Думаю, что теории достаточно. Давайте представим, что вы только что услышали в свой адрес «Почему тестировщики пропустили эту ошибку?». Вот возможные пути ответа:

1. Выбор исходных данных.

Утверждают, что тестировщики должны были найти эту ошибку. Мы можем ответить, что действительно существует заслуживающая внимание причина, почему эта ошибка не была найдена. Далее несколько разъяснений, как я это использовал:

Ошибка воображения: Ошибка прошла потому, что никто даже и предположить не мог о её существовании в этом месте . Программист не подумал о такой возможности, ведь именно он создал её. Команда , работающая над созданием требований, не представила возможности появления ошибки в этом месте, ведь иначе они бы написали более явные требования относительно этого места.Мне кажется, что вся команда допустила ошибку в этом месте. Возможно, в будущем,если группа тестирования будет иметь больше времени для обдумывания путей тестирования (кроме обычных действий), они придут к написанию таких сценариев, которые найдут эту ошибку.

Давайте теперь немного поговорим о давлении расписания и как это влияет на фантазию тестировщиков…

Успешное управление рисками: хорошо. Одна ошибка смогла пройти незамеченной. Достаточно честно. Теперь давайте поговорим о том, что команда тестировщиков работала на протяжении последних двух недель и при этом они смогли найти 15 блокирующих ошибок, 19 критичных и 54 ошибки с приоритетом Normal. Если мы хотим, чтобы эта область была протестирована, мы должны уделить меньше времени другим областям. Итак, какой из 15 блокирующих тасков вы бы хотели, чтобы мы пропустили, потратив время на эту функциональность?
Проблема коммуникации (общения): Мы не можем проверить все возможные комбинации входных данных, поэтому мы вынуждены их сортировать, выбирая более представительные. В данной ситуации мы ошиблись с выбором правильной выборки. Теперь, когда мы знаем о возможны проблемах, мы постараемся уделить больше внимания данной функциональности при тестировании. В будущем, если аналитики, программисты или другие участники проекта будут знать о возможных проблемах, они должны сообщать это команде тестирования.

2. Проблемы исходных данных.

Минуточку: Должны ли были тестировщики найти эту ошибку? Было ли у них достаточно времени? Где был человек, который знал о возможности проблемы? Был ли запрос на использование программных средств, которые позволят найти ошибки такого рода? Такая ситуация может быть хорошим временем, чтобы сказать «Используя данные условия среды разработки/тестирования, мы не должны ожидать, что тестировщики найдут ошибки такого рода. Если же мы хотим не отдавать такие ошибки заказчику, нужно изменить...»

3. Ответ вопросом.

Вместо ответа «вот почему мы не нашли эту ошибку», вам стоит ответить своим вопросом. Это меняет вашу роль, вы перестаете быть жертвой, и становитесь... кем-то, кто действительно пытается повысить качество.

Вот один из примеров того, как можно ответить вопросом на вопрос: «Это верный вопрос, но я считаю, что подобные ошибки лучше предотвращать, чем находить в процессе тестирования. Другой вопрос, над которым стоит подумать: Почему эта ошибка возникла? Программисты ошиблись при реализации функциональности? Ошибка закралась, когда создавались требования? Или это ошибка коммуникации?»

Делая так, вы даете возможность интерпретировать эту ошибку шире – на пример, как эта ошибка появилась – это может спасти вас от враждебности и претензий.

Мой опыт говорит, что бывает три возможных пути развития событий: Команда разработчиков делает brainstorm и предотвращает подобные ошибки в будущем, или они пожимают плечами и говорят «ошибки случаются», или кто-то становится очень грустным. Первых два варианта выглядят хорошо. В третьем случае, иногда вы можете ответить «Я сам не люблю такие вопросы.» Но будьте осторожны. Вы должны знать тех, кому пишите. Мы стараемся построить дружественную атмосферу в команде.

4. Направление дискуссии.

Вместо того, чтобы чувствовать вину на себе и команде, обратите внимание беседы на то, что это всего лишь одна ошибка из сотен найденных в сотнях и тысячах (если не миллионах) строк кода. Если даже здесь ошибка, то что это меняет? Другими словами, вы можете изменить саму суть встречи: вместо упреков и порицания, к празднованию и радости.

Если ошибка на столько важна, что праздновать нечего, постарайтесь ввести самого вопрошателя в процесс проекта: «Это хороший вопрос, Иван. Ты считаешь, что тестировщики должны были найти эту ошибку? Я был бы рад услышать от тебя предложения о том, где бы мы могли улучшить свою работу.» Эта не защищает нас полностью от критики, но приглашает Ивана становится частью процесса, а не просто критиковать.

5. Измени тему.

В своей книге Quality Software Management, Volume III Jerry Weinberg говорит, что не подходящее поведение может спасти команду от критики. Он приводит такой пример: «Посмотрите, какой пятнистый кот на крыше. Как он туда попал?» Тяжело критиковать кого-то, когда смотришь на котенка. Но вам стоит знать людей, с которыми разговариваете, ведь часть людей будут задавать эти вопросы раз за разом.

Консультант по командной работе Pollyanna Pixton предлагает другой вариант: Просто откажитесь отвечать на неудобный или нечестный вопрос.

Другими словами, если кто-то задает вам неудобный вопрос, ничего не говорите и смотрите на него, будто у него выросла ещё одна голова. Если вас продолжают спрашивать, продолжайте пристально глядеть. В итоге, он остановится. Точно вам говорю.

«Тряпка» или политик?

Я постарался представить конкретные предложения по тому, как отвечать на хорошо звучащие, но нечестные вопросы, такие как «Почему тестироващики пропустили эту ошибку?». Типичным ответом на мой очерк является фраза «Мой начальник был весьма зол.»

Да, это возможно. Традиционные альтернативы – отступление и успокаивание – могут быть менее болезненны. Если не считать того, что вы становитесь «тряпкой». Мой вам совет: знайте себе цену, и у вас будет что сказать в момент, когда вам зададут нечестный вопрос.

Да, начальник может быть зол. У вас может даже разгореться конфликт. Через пять лет, вы, возможно, будете работать на новой работе. Я предполагаю, что она будет лучше той, где вы работаете сейчас.

Прочитать эту статью на языке оригинала (English) можно на этом сайте.
Узнать больше об авторе заметки можно на professional web page of Matthew Heusser.

Обсудить на форуме it4business.ru

Лишние знания мешают?

noreply@blogger.com (Maksim Grinevich) — Mon, 14 Sep 2009 05:07:00 +0000

В своем посте "What Makes A Good Software Tester?" Dr. James McCaffrey описывает восемь характеристик настоящего тестировщика. Одной из таких характеристик является: существенные технические данные. Причем, здесь он имеет ввиду, кроме всего прочего, умения/знания программирования:

A great software tester must have significant coding skills in order to understand the system under test, communicate with developers, and write test automation. ... I believe that a great tester must have at least 7.5-on-a-scale-of-1–10 (applications) development skills.

То, что автоматизатору было бы не плохо быть раньше программистом или иметь хоть какой—то опыт написания программ — это точно.

А вот, что касается, всего остального — то тут я не соглашусь с знаменитым доктором...Не раз и не два видел, когда именно апеляция к технической реализации той или иной функциональности системы приводила к выпуску софта с ошибками. В случае же, когда тестировщик не знает/не углубляется(если знает) в технический аспект решения проблемы, тогда аргументы программиста о нюансах реализации не принимаются во внимание — начинает работать логика, понимание use cases, usability — программистам становится интересно реализовать функциональность правильно. И все в шоколаде.... по крайней мере, так хотелось бы.

Что я хотел сказать: далеко не всегда глубокие знания программирования будут помогать тестировщику. Но знать основы ООП или в каком случае равенство имеет смысл а = а + 1 — надо обязательно.

Мысли по организации тестовых сценариев (test cases)

noreply@blogger.com (Maksim Grinevich) — Tue, 08 Sep 2009 06:25:00 +0000

Прежде, чем забить применить новую концепцию отношения к тестовым сценариям (test cases), описанную в посте А так ли нужны test cases ?, я хотел изменить способ хранения этих самых сценариев описанным ниже образом.

Предлагаю оценить возможность использования данного подхода. Конечно, пока это только теория, но как только у меня будет возможность/ресурсы попытаюсь её воплотить в жизнь.

Итак, копия моего предложения с вырезанными project specific местами:

Я подумал, что мы могли бы отойти от идеи хранить кейсы полностью в строгой структуре. Почему?
Если посмотреть на современное развитие всех служб хранения информации (базы данных, почтовые сервера и т.д.), то везде нет твердой структуры. Вот возьмем гугловскую почту как пример: здесь они отказываются от папок, сбрасывая все письма в кучу, позволяя пользователям создавать ярлыки и осуществлять мощную фильтрацию данных по средствам поиска.

Минусы отсутствия твердой структуры с лихвой покрываются возможностью не думать над тем в какую папку засунуть сей документ, когда он с легкостью может быть как в одной папке, так и в другой.
Думаю, что что—то подобное мы можем сделать и с нашими кейсами. Возможно, что полного отказа от типизации и строгости не будет (в базах же присутствуют как типы данных, так и строго заданные таблицы, но непосредственно в файлах все хранится без строгого разграничения)
ЧТО я предлагаю:
------ Требования и организация ---------------
1. Точно определить, что должно быть в полях типа: Module(s), Sub—Module(s) . Если с остальными всё более менее ясно, то в этих полях каждый тестер пишет то, что ему вздумается. Следующим шагом будет переименование этих полей соответственно тому, что в них будет находится.
2. Добавить поле Feature. Куда для ВСЕХ записей будет записываться фича, которую проверяет данный конкретный кейс. Если кейс точно нельзя определить, как проверяющий конкретную фичу, то там будем писать что—то типа Global или Main. Это поле должно разрешать вписывать несколько значений через запятую(так сейчас у нас хранится инфа о конфигурациях для конкретного кейса).
3. Список стоит вынести на отдельную страницу и при добавлении новых кейсов для новой фичи, название фичи добавлять в этот список. И там же связывать ещё раз, в каких конфигурациях эта фича МОЖЕТ быть активизирована.
4. Нужно создать дефолтовый документ, куда будут вноситься все дополнения и изменения. А так же пустой документ, но с готовой структурой, сюда должно быть удобно скопировать кейсы из дефолтового дока.
5. Правильно настроить фильтрацию, возможно понадобится написать пару VBScript'овых макросов.
------- Как этим пользоваться ----------
1. Если нужно проверить конкретную конфигурацию.
1.1. Выделяем с помощью автофильтров необходимые кейсы. Копируем их в пустой приготовленный и производим тестинг. Сохраняем результаты в отдельный файлик.
Или
1.2. После фильтрации создаем новую версию Results for build_version и производим тестинг. На все остальные кейсы, которые не нужно проверять в рамках этого тестирования ставим статус Not required
2. Если нужно сделать из наших кейсов Acceptance cases. Опять таки фильтруем данные. Можем уже ничего никуда не копировать.
------------------------------------
В чем наша выгода:
1. Нам не нужно напрягаться о порядке дабавления кейсов даже для одной фичи. Фильтрация по имени фичи точно покажет все кейсы, которые её касаются.
2. Страничка с перечислением фич сразу покажет, какие фичи добавлены, а какие — нет. При этом здесь мы можем попробовать сделать структуру, которая покажет к чему относится конкретная фича.

В этом, ещё не оттестированном подходе много минусов — это я понимаю. Главный вопрос, который меня интересует: будет ли это жить или есть причины, которые видны «не вооруженным» глазом, из-за которых всё сойдет на нет?

Теперь домен второго уровня YaTester.ru

noreply@blogger.com (Maksim Grinevich) — Fri, 04 Sep 2009 06:00:00 +0000

С мои блогом произошло несколько изменений:

— блог переехал на новую площадку YaTester.ru — так что советую изменить ссылки на фиды (конечно старые будут поддерживаться столько времени, сколько нужно)

— появилась почта ваше_имя@yatester.ru, основанная на сервисе google.com . У меня есть ещё порядка 40 - 45 аккаунтов, которые я могу подарить всем желающим. (Можно настроить пересылку сообщений на ваши основные ящики)

Планирую добавить англоязычную версию блога по адресу YaTester.com, но пока это только планы...

Баг в счетчике LiveInternet

noreply@blogger.com (Maksim Grinevich) — Thu, 27 Aug 2009 13:24:00 +0000

Решил глянуть свою скромную статистику на блоге, и с нерешительностью пытался понять, что же мне показывает мой счетчик LiveInternet.ru

Как вы видите на скриншоте, этот счетчик показывает количество показанных страниц за 24 часа, количество посетителей за последние 24 часа и за сегодня.

Но почему-то сей счетчик показывает, что за последние 24 часа у меня посетителей было меньше, чем за сегодня!

Сколько не фантазировал, объяснения придумать не смог.

Есть у кого-нибудь толкование этому или это обычная бага-фича?

Приходите ко мне с проблемой...

noreply@blogger.com (Maksim Grinevich) — Thu, 27 Aug 2009 11:00:00 +0000

Сегодня очередная цитата из народа:

Приходите ко мне с проблемой, и вы получите решение. Если придете ко мне с решением – получите проблему.

Цитаты из народа...

noreply@blogger.com (Maksim Grinevich) — Sun, 23 Aug 2009 21:10:00 +0000

Последнее время стало «модно» в своих блогах/сайта/и т.д. добавлять цитаты известных людей. Зачастую — это книги, выступления...

Я же хочу собрать подборку «цитат из народа» — это те фразы/слова/изречения, которые висят у нас на стенке, напечатаны на листе бумаги. Один из примеров - табличка «Лес». Есть только одно условие: пусть это не будут прямые цитаты из книг

Сегодня первая цитата:

«Тот, кто поднялся выше, просто полез раньше!»

Если у вас есть такие вещи, или вы видели действительно стоящие бриллианты — буду рад прочитать о них в комментах или у себя в почтовом ящике m.grinevich@yatester.ru

Ночью работать нельзя уходить!!!

noreply@blogger.com (Maksim Grinevich) — Thu, 20 Aug 2009 07:00:00 +0000

Ночная работа... Думаю, что нет никого из опытных ITишников, кто не работал бы ночью. Как переработка (или длительное пребывание на рабочем месте в течении 12-18 часов) отражается на вашей продуктивности?

Всем известны недостатки такой работы:

— усталость: закрываются глаза, голова не хочет думать, компьютеры тормозят сильнее, всю еду уже съели;

— давление начальства (ведь задерживаемся, чтобы сделать что-то быстрее, чем обычно);

— давление домашних (они хотят видеть нас дома «как обычно», а не позже на 3-4..10 часов)

— с каждым часом растущее желание — а не пошло оно всё лесом, я хочу домой/спать/есть/и т.д., подчеркнуть необходимое

— пропущенные дефекты в виду всего выше перечисленного...

Но ведь и плюсы у такой работы тоже есть:

— не знаю, как это случается, но на протяжении первых часов продуктивность растет (вероятно, все ещё надеяться успеть туда, куда начинают опаздывать)

— команда становится более единой -ведь «столько часов вместе!!!»

— зачастую, повышенная оплата труда (это скорее плюс для работника и минус для работодателя) за отработанное время

— все чувствуют на своей шкуре, что значит придерживаться сроков и держать обещания...

Что-то у меня все плюсы какие-то очень маленькие вышли... коллеги, может я что-то пропустил? Ведь переработка не такое и редкое дело в небольших софтверных фирмах. А в преддверии выпуска продуктов — это стандартное поведение исполнителей...

Думаю, случись это раз в два-три месяца или реже, то плохого в этом ничего нет. Единственное, на что стОит обратить внимание девелоперам/тестерам — превращение исключения в практику, когда знаешь, что каждая следующая итерация заканчивается плановой переработкой.

С. Архипенков в своих прикладных мыслях "Руководство командой разработчиков программного обеспечения" пишет о том, что завершение рабочего дня вовремя — один из факторов успешности проекта:

«У проекта разработки ПО сегодня не три, а четыре фактора успеха:
...
4. Каждый участник команды уходил с работы в 18:00 с чувством успеха.»

А где вы поставите запятую в теме поста?