Разделы портала

Онлайн-тренинги

.
QA для самых маленьких. Тестирование в небольших проектах.
17.06.2009 13:33

Автор: Стеценко Дмитрий

Традиционно,  многие компании, занимающиеся разработкой ПО, задумываются о процессах по мере роста. Приглашают консультантов, описывают процессы, изводят тонны бумаги и сотни человеко-часов на инструкции, обучают новичков.
Однако на рынке существует очень много небольших компаний, веб студий, внутренних проектов  на несколько человек. Кризис, подстегнувший желание многих западных компаний сэкономить, увеличивает объемы аутсорсинга, и вызывает увеличение количества фрилансеров и микрокомпаний с персоналом от  2 до нескольких десятков человек.  Очень часто там работают знающие и умеющие разработчики, но вот с тестировщиками ситуация как-то значительно печальнее. А такого редкого зверя, как аналитик, тяжело найти и в более крупных компаниях, что уж говорить о маленьких Smile

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

Но хватит лить воду, начнем.

1.    Кесарю – кесарево.
Менеджерам: Если вы уже собрались вводить тестирование на проекте, не пытайтесь совместить его с другими активностями. Категорически не стоит совмещать тестирование с разработкой;  можно, но не всегда выгодно – с саппортом или бизнес анализом.
Не пытайтесь сшить 7 шапок из одной шкурки. Особенно если это шкурка вашего единственного тестировщика Smile Мне ни разу не встречалась ситуация, когда один тестировщик на проекте был бы недозагружен работой. Если честно, и недозагруженные отделы тестирования мне тоже ни разу не встречались. Вот наоборот случается довольно часто. В индустрии нет каких-то нормативов насчет оптимального соотношения количества разработчиков и тестировщиков. Все очень зависит от сложности системы, цены ошибки, практикуемых методологий, длительности проекта и т.п. Встречаются проекты, где на одного разработчика – два тестировщика. Чаще – наоборот – один тестировщик на 2-3 разработчиков. В отечественном бизнесе бывает один тестировщик на 4-6 разработчиков, и эти героические люди справляются. Как правило, бОльшее количество разработчиков пишут код с такой скоростью, что тестировщик успевает его «потестировать» сколько удастся и отловить наиболее заметные баги, но о том, чтобы все было протестировано, речь уже не идет. Тестирование быстро вырождается в хаотическую активность, с помощью которой находятся наиболее дырявые участки кода и иногда улучшается качество продукта, но в целом лучше от этого уже не становится Smile Встречаются экзотические ситуации, где один тестировщик на несколько десятков разработчиков. Если все что они пишут надо тестировать – ситуация неизлечима. Если попытки увеличить штат или ограничить объемы тестирования не помогают, остается лишь искать другую работу, или заняться дзен-буддизмом и к моменту, когда весь этот хаос таки рухнет, с каменным лицом раздумывать о звуке хлопка одной ладонью.
Тестировщикам:  умные люди уже давно советуют: если времени недостаточно, не пытайтесь потестировать все понемногу – лучше один модуль, про который вы можете сказать что он тщательно протестирован, чем два десятка модулей, про которые ничего толком сказать нельзя. Могу сказать, что пробовал, и такой подход действительно работает. Еще хорошо помогает ранжировать весь функционал по важности (или по рискам) и договориться о том, что все,  что, к примеру, имеет приоритет 1 – будет тщательно протестировано, 2 – протестировано только для нормальных значений – никаких граничных значений из отрицательных диапазонов и 3 – может быть глянем, если останется время.
2.    Начинайте тестирование рано.
 На эту тему уже сказано ну очень много, поэтому не хотелось бы повторяться. Вот только вспоминают руководители проектов об этом по-прежнему нечасто. Стоимость исправления ошибки растет день ото дня. До появления на свет первого функционала, который можно тестировать, тестировщик может проверять требования, планировать тестирование, подготавливать тестовое окружение, писать тест кейсы, сетапить багтрекинг, определятся с инструментами, которые будут использовать, налаживать собственно процесс тестирования. Если коротко, то до начала тестирования его надо спланировать и подготовить. Поэтому, когда тестировщик привлекается на этапе наличия готового, тестопригодного продукта, остается либо наплевать на планирование и подготовку и начать исследовательское тестирование, чтобы не задерживать проект (многократно говорилось о вреде написания кода как можно раньше – до архитектуры итд. В тестирование имеет место быть ровно та же самая ситуация), либо потратить лишнее время на планирование, тем самым либо задерживая выпуск проекта либо урезая объемы собственно тестирования.
3.    Дайте мне точку опоры, и я переверну мир Smile
Менеджерам: Тестировщику надо на что-то опираться – ведь в процессе тестирования полученный результат мы сравниваем с ожидаемым результатом. И нередко узнать а какой же именно результат будет правильным с точки зрения будущего пользователя становится нетривиальной задачей.  Способ определить правильно ли работает тестируемая система в рамках тестирования называют оракулом. Оракулом может быть  предыдущая версия продукта или аналогичное ПО конкурентов, спецификация, юзкейсы, прототип, или в худшем случае изустное предание.
Именно они, как правило, определяют  функциональное тестирование, позволяют решить, что мы будем тестировать, а что нет, приоритезировать тестирование и убедится, что мы ничего не забыли.
Поэтому критически важно включать тестировщика в обсуждение любых изменений в функциональности.
Тестировщикам: Если у вас нет требований, но есть прототип – вам повезло. Его вполне можно использовать как для составления тест кейсов, так и для исследовательского тестирования.  Тестируйте по юзкейсам, если и этого нет – обходите заинтересованных лиц и собирайте список фич вашего продукта. Тестировщику нужно на что-то опираться. Донесите эту мысль до ваших ПМов и пусть они включат вас в обсуждение с заказчиком всех изменений функциональности. Исследуйте аналогичное ПО, изучайте область применения вашего ПО, налаживайте коммуникации с теми кто знает как оно должно работать. И постарайтесь во всем этом не запутаться Smile
4.    Используйте багтрекер.
Пожалуй стоило бы поставить этот пункт первым. Как ни странно до сих пор есть команды которые этого не делают. Как минимум использование любого самого простого бесплатного багтрекера позволит вам не забывать и не терять найденные дефекты, сортировать их по важности, получать простейшие метрики по дефектам, организовать нормальный жизненный цикл дефекта, при котором пофикшеный дефект проверяется тестировщиком , вести историю, и еще много-много не очень серьезных но значительно облегчающих жизнь вкусностей.
Практика показывает – плохих багтрекеров нет, есть неправильно используемые - разруха в головах (с) Smile Если багтрекера нет вообще – то вам повезло и вы сможете выбрать одну из существующих платных или бесплатных систем. Они все довольно хороши. Еще и кастомизируются. Если заказчик навязывает использование какого-то определенного багтрекера и существуют сложности с его кастомизацией, все равно можно победить многие проблемы, заранее договорившись о том, как будет происходить работа с дефектами.Всегда полезно донести до всех членов команды, как именно это будет происходить, и как пользоваться багтрекером. Это может быть неформальная беседа в курилке или за обедом, короткая презентация или документ, разосланный почтой
5.    Обрабатывайте запросы на изменения.
Договоритесь заранее о том, как будут обрабатываться запросы на изменения. Они обязательно будут, как бы тщательно все не было спланировано. Легче всего заносить их в баг трекиинг, но тогда хорошо бы иметь отдельное поле, чтобы различать дефекты, запросы на изменения и другие типы записей, буде таковые появятся. Несложная процедура ведения изменений при которой все изменения вносятся в баг трекинг тестировщиком, позволит убить сразу двух зайцев – отслеживать запросы на изменения и их состояние и держать тестировщика в курсе всех изменений.
6.    Используйте изолированное тестовое окружение.
Многократно слышал: у нас не хватает ресурсов для поднятия тестового сервера. Их действительно всегда не хватает – то времени, то денег, то и того и другого. Но тестирование в том же окружении, в котором идет разработка, вызовет огромное количество никому не нужных сообщений об ошибках, связанных с тем что кто-то что-то отлаживал, или закомитил недоделанную функциональность в конце рабочего дня или просто по каким-то причинам правит что-то прямо на сервере. Если тестирование продлится дольше чем несколько дней, установка отдельного тестового окружения окупится.
7.    Используйте процесс передачи билда в тестирование.  
Опрделите кто и когда это делает, планируйте деплойменты на некоторое время вперед.  Особую ценность имеют комментарии от разработчиков – что именно изменилось, что исправили, что нового, на что стоило бы обратить внимание. Составить этакие release notes занимет считанные минуты, но они здорово облегчают жизнь, позволют спланировать тестирование. Если у вас разработчики отчитываются о статусе, то такой документ легко получается из писем разработчиков. Если вы используете SCRUM то постарайтесь чтобы ваши ежедневные митинги помогали тестировщику определится с тем что и как  тестировать в новой сборке.
Хорошо работают  ежедневные билды – когда версия собирается ночью или вечером, проходит автотесты и деплоится на тестовый сервер. С одной стороны у тестировщиков есть стабильная версия в которую никто не вносит изменения, с другой – все обновления попадают в тестирование максимум на следующий день.
8.    Грамотно используйте документацию

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

9.    Определитесь  с критериями окончания тестирования.

Самый простой и, пожалуй, наименее приятный для тестировщика вариант, -  когда ПМ (заказчик, еще кто нибудь имеющий на это право ) в один прекрасный день говорит – хватит, пускаем в продакшн. Если у тестировщика есть какие-то количественные метрики, он сможет снабдить руководство внятными данными о рисках чтобы- решение о выпуске продукта принималось осознанно. Лучше всего заранее обговорить их с ПМом, но те зачастую не совсем представляют, что именно это может быть. Можно использовать покрытие требований тестами и количество успешно пройденных тестов. Это может быть количество открытых багов с высоким приоритетом. Количество часов необходимых для нахождения бага/бага с высоким приоритетом.  Степень покрытия кода тестами.. Эксперементируйте, попробуйте сделать список метрик которые вы могли бы собирать и обсудить его с ПМом с целью выбрать наиболее интересные.

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

 Обсудить в форуме

Tags: