« Я тестер ! »

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


ИПТ

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

Что такое?

Идеальный процесс тестирования для меня – это процесс который позволяет решать поставленную задачу максимально эффективно, а так же создает комфортные условия для этого. Идеальный процесс, когда «лучше уже и не надо!»
Хотя само понятие ИПТ достаточно не однозначно, потому что каждый читатель может выдвинуть свои критерии идеальности процесса.

ИПТ не существует

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

ИПТ существует

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

Как?

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

I. Описать то место в проекте, времени и команде, в котором вы находитесь;

II. Идентифицировать проблемные места
     1. идти от проблемы
     2. с точки зрения цели:

• удобный для достижения цели
• предсказуемый результат
• понятный объем работ

III. Приоритизировать проблемы
     1 решать по одной из каждой выделенной области в единицу времени
     2 параллельное решение из несмежных областей

IV. Внести изменения
     1 мотивация команды
     2 обратная связь
     3 довести изменение до конца

V. Проанализировать результат

Несколько примеров

Пример первый.

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

- частое обращение ПМа за информацией о состоянии задач, расчетным временем их исполнения -
введено и применяется сразу практически всей командой: обновление статусов задач в багтрэккере, выставление перед началом и изменение estimations в процессе работы над большими задачами.Убедившись в достаточной верности данных – ПМ реже задает свои вопросы.

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

Пример – второй.

Крупная оффшорная компания. Выделенный центр разработки для одного западного информационного агентства составом в Х человек, из которых 30-40 человек – группа тестировщиков.

- стремясь улучшить процесс для всей группы, изменения вносят на всех, проверяя на одной из групп.
Изменения успешные для группы из 5-7 тестировщиков валяться на группе из 2-х человек, т.к. они работают с другим типом ПО, у них свой «подкрученный» процесс тестирования.

Заключение
Подводя итог выше сказанному, следует отметить следующие моменты:
- стремиться к ИПТ необходимо – он существует и достижим;
- движение стоит начинать от проблемы;
- ...

В дополнение хочу показать карту памяти, которую я использовал для подготовки этого сообщения:


Спасибо mindmeister за сервис.


Текст сообщения и комментарии...

Не совсем про тестирование, но очень понравилось:

"For true success ask yourself these four questions: Why? Why not? Why not me? Why not now?"

"Для настоящего успеха задайте себе следующие четыре вопроса: Почему? Почему бы и нет? Почему не я? Почему не сейчас? "

Текст сообщения и комментарии...

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


1) Нам не требуется такого уровня тестирования.
2) Это стоит до{хрена} кучу денег.
3) Слишком долго будете копаться.
4) Тестирование никогда «не завершится полностью».
5) Мы никогда не знаем, сколько времени уйдет на тестирование.
6) Слишком академично, мы же не NASA.
7) А его собственно и в плане то не было.
8) Тестирование сильно тормозит выход продукта.
9) Кастомер просто весь в нетерпении, а ваши тестеры тормозят процесс.
10) Тестирование выставляет нас идиотами.
11) А какой толк вообще от тестирования?.
12) Пока тестеры нароют все баги – рынок ушагает от нас.
13) Да и вообще всем пофигу на эти баги.
14) А собственно тестирование вообще не дает ответа ни на какой вопрос.
15) Разрабы сами все протестят.
16) Не надо ломать систему, и так работает не очень.
17) Пользователь сам найдет баг и мы все пропатчим.
18) Ну нет у нас времени, чтобы написать требования.
19) И вообще, тестеры никогда не находят самые нужные баги.
20) Тестирование все равно никогда не найдет всех багов.
Текст сообщения и комментарии...

3. А проект/задача от этого выиграют?

Текст сообщения и комментарии...

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

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

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

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

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

Ошибается каждый, но детские ошибки делать НЕ позволительно!

Это была лирика, а теперь выводы.

Попросите 2-3 человека описать Красную площадь или Статую свободы - получите ли вы одно и то же описание? А если посмотите сами на картинку..а если потом "вживую" - сколько разных описаний вы получите?
Текст сообщения и комментарии...

Гляньте-ка вот на эту карту мира!

Странного ничего не находите?..

А это всего лишь южно-ориентированная карта мира.

Пару заметок для тестировщиков далее...


Эта картинка показывает на сколько важно по-новому смотреть на продукт, который вы тестируете.

1. Переключитесь на другую задачу на пару дней/часов.

Это дает возможность освежить взгляд и увидеть то, что примелькалось.

2. "Прогуляйтесь" по продукту с кем-нибудь из команды.

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

3. Посмотрите демку конкурентов.

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

4. Попросите конечного пользователя или Project manager'а рассказать о продукте его словами

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

Источник на английском: Joel Montvelisky qablog.practitest.com

Текст сообщения и комментарии...

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



Несколько пунктов, влияющих на то, как должно быть написано письмо:

WHO		HOW
Позиция и авторитет		Тон письма: подчиненый - > начальник начальник - > подчиненый равный к равному
Количество знаний о теме сообщения		Степень детализации информации
Отношение к теме письма		Положительное, отрицательное, нейтральное
Суть сообщения		Какие факты нужно упоминать и в каком количестве?

В зависимости от отношения используется разная структура сообщения. В начале говорим информацию, если отношение положительное, затем объясняем/уточняем (дедуктивная структура). В начале объясняем/описывает/приводим доводы, а потом сообщаем новость, если отношение отрицательное (индуктивная структура).

Процесс, который проходит сообщение:

1. Привлечение внимания
2. Понимание
3. Согласие
4. Дествие

На каждом из этапов отсеивается порядка 10%. Итого, будет хорошо, если только 67% (0,9*0,9*0,9*0,9) посланных сообщений дойдут до стадии Действие - цели письма.

У каждого запроса/письма должна быть цель достигнуть Действия получателя. Бездействие - это одна из форм действия (например, Вас не уволили - какое приятное бездействие)

Формальность и "сила" :
Любое письмо может быть:
- формальным и неформальным, а так же стоять на какой-то из ступеней между.
- сильным и нейтральным (речь идет об эмоциональной выраженности и присутствии "сильных" прилагательных - очень, весьма, жизненно необходимо, вопрос жизни и смерти, а то мне кирдык :)

"Ты"-перспектива:
Вы можете писать с точки зрения вашей выгоды, ваших результатов, либо с точки зрения результатов и выгоды получателя - результат совершенно разный в итоге. (Для того, чтобы понять как вы пишите, подсчитайте количество местоимений Я и Ты в ваших письмах :)

Ещё говорили о:
- культуре/национальность получателя (линейно-активная, мульти-активная, реактивная) и её влиянии на восприятие информации
- как говорить "нет" politely
- о 3S (Short, Simple, Specific) и 5H+W (Why, Where, What, Who, When + How )
- многом-многом другом

Не думаю, что тренер попадет на мой блог, но все равно говорю ему спасибо.
Тренер: Сергей Кузин

Текст сообщения и комментарии...

Давеча посмотрел фильм ПОП Владимира Хотиненко. Там главный герой рассказывает нерадивому мужу о семейных отношениях между мужем и женой (мой вольный пересказ):

... Без жены я (мужчина, поп) всего лишь единица. Жена без меня — 0. А вместе мы образуем 10 (десятку)...
... Жена — это мой точильный камень. Благодаря ей, то что я делаю получается значительно лучше, чем без неё...

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

Программирование без тестирования способно что-то делать — назовем результат 1. А вот при включении в разработку тестирования (которое само по себе 0) — получаем в результате 10 (десять).А про то, как тестировщики в процессе работы помогают программистам «заточить» продукт, и говорить нечего.

P.S.: надеюсь что этот пост немного объяснит мою точку зрения о тестировании, которая, возможно, была не правильно понята судя по комментариям к этому посту.

P.P.S.: уважаемые девушки, по поводу того, что в притче девушка названа 0 — претензии к автору романа или сценаристу фильма :)
Текст сообщения и комментарии...

Первая иллюзия - тестировщик лично отвечает за качество ПО.

Вторая иллюзия - тестировщик слабое место проекта.


Иллюзия третья - ошибки становятся ошибками только в руках тестировщика.

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

Текст сообщения и комментарии...

• com/mercury/javashared/agentloader/agentbootstrap
• com.mercury.javashared.infra.native
• java.lang.exceptionininitializerError

Более подробно можно прочитать здесь.

Советую не удалять эти параметры, а переименовать. Ведь запускать QTP Вам тоже может понадобиться.
Текст сообщения и комментарии...

——————
Получилось не про тестирование, но надеюсь, что суть понятна ;)
Текст сообщения и комментарии...

Алексей Баранцев здесь говорит:

«Главная деятельность тестировщиков заключается в том, что они предоставляют участникам проекта по разработке программного обеспечения отрицательную обратную связь о качестве программного продукта.»

Ту же самую идею недавно описал Д. Спольски в своей статье «Why testers?»

«A great tester gives programmers immediate feedback on what they did right and what they did wrong.»

Это здорово, но думаю, что это не абсолютная истина. Ведь в зависимости от размера проекта и ролевого распределения цель и задача тестировщика меняется, причем достаточно явно.

Текст сообщения и комментарии...

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

Текст сообщения и комментарии...

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

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

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

Текст сообщения и комментарии...

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

Если хотите что-то запомнить — запишите.
Текст сообщения и комментарии...

Квартира нашлась - cian.ru обошел даже активных риелторов :).
Текст сообщения и комментарии...

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

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

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

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

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

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

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

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

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

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

Текст сообщения и комментарии...

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


Книга о том:

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

От издателя:

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

Скачать


Текст сообщения и комментарии...

Единство:

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

Любовь:

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

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

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

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

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

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

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

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

— самоотдаче

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

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

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

В итоге:

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

P.S.:

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

Текст сообщения и комментарии...