Home

Перевод: консультант проекта Ольга Захаренко (Агладзе)

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

Better Software
July/August 2004
www.stickyminds.com

Lightweight Development. Heavyweight QA.

Быстрая разработка vs классический QA.

Элизабет Хендриксон (Elisabeth Hendrickson)
Е-майл: Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript ,
Резюме онлайн: http://www.qualitytree.com/services/resume.html

Элизабет является основателем и президентом фирмы Quality Tree Software, Inc. Вместе со своей компанией она предлагает тренинги, консультантирование и услуги в области контроля качества программного обеспечения и тестирования программ. За 15 лет работы в ведущих компаниях, разрабатывающих программное обеспечение, Элизабет видела программы — и в том числе качественные программы — в огромном количестве. Она работала тестировщиком, инженером автоматизации тестирования, техническим писателем, программистом, инженером службы поддержки, системным администратором, и менеджером (иногда одновременно). Как обладатель многих наград за свои статьи и работы, Элизабет имеет большое число публикаций и часто выступает на конференциях по управлению разработкой программного обеспечения. Вы можете узнать больше о ее идеях в области качества и тестирования, посетив сайт www.qualitytree.com.

http://www.qualitytree.com/services/resume.html

Сценарий.

Вы — менеджер команды разработчиков в организации, которая практикует XP. Вы пытаетесь убедить QA менеджера использовать для вашего проекта облегченную процедуру тестирования по методологии Agile, в то время, как он настаивает на выполнении работы с использованием все той же классической документации. По его мнению, тесты должны планироваться на основе спецификации, а также должны детально и точно документироваться. Для регрессионного тестирования должны использоваться все те же привычные ему скрипты, записанные через пользовательский интерфейс. Что еще хуже, QA менеджер утверждает, что ему совершенно необходима детальная спецификация еще до того, как он начнет хотя бы думать о тестировании. Он не делится с вами информацией о видах тестов, которые он намерен выполнять на вашем проекте, и он не желает, чтобы сотрудники его отдела участвовали в раннем тестировании продукта наравне с разработчиками. В результате тестировщики QA отдела больше мешают, чем помогают гибкой работе всей команды проекта. Как вы можете его убедить, что XP методология — это новый стиль работы для всех, не только для разработчиков, но и для тестировщиков?

Решение.

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

Однако стоит отметить здесь, что не все команды разработчиков, которые утверждают, что они работают по XP методологии, в самом деле ей следуют. К примеру, команда использует неформальные и не такие технологичные методы сбора информации, но не практикует модульное тестирование или частую сборку продукта, на самом деле не следует правилам XP. (Обратитесь на сайт www.stickyminds.com/bettersoftware для дополнительной информации по XP). Так что будьте честны перед собой. Вы и в самом деле практикуете XP методологию?

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

«В последнее время в нашей команде мы ведем разработку иначе. Вы заметили какие-либо изменения?»

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

Осмыслите проблемы, на решение которых направлены практики отдела QA.

Почему же отдел тестирования работает так, как он работает? Не предполагайте, что ответ известен заранее. Спросите. Рассмотрите каждую из практик отдела, которую вы хотели бы изменить и открыто обсудите ее с QA менеджером. Поднимите вопрос о том, почему отдел нуждается в той или иной практике. «Открыто» означает — задавайте вопросы типа:

«Расскажите мне больше о регрессионном тестировании. Что является триггером, сигналом к выполнению всего комплекта регрессионных тестов в вашем отделе? Какие проблемы вы пытаетесь найти, применяя регрессионное тестирование?».

Старайтесь избегать формулировки вопросов в стиле: «Зачем нам вообще регрессионное тестирование? Мы же практикуем XP!» Ваша задача — открытое обсуждение проблемы, а не желание заставить QA менеджера занять круговую оборону. Когда вы поймете, почему в отделе практикуется тот или иной подход, вы сможете сместить акцент разговора:

• Объясните вашу точку зрения: «Я думаю, что используя разработку, управляемую тестами, мы резко уменьшаем риск того, что мы не проверим код, где небольшие изменения могут вызвать катастрофические проблемы. У нас есть полностью автоматизированный набор модульных тестов, прогоняемых на каждой версии».
• Опишите проблему, которая вызвана практикой отдела QA: «Прогон полного набора регрессионных тестов задерживает работу проекта и не дает нам никакой новой информации о выпускаемом продукте».
• Договоритесь о совместных действиях: «Каким образом мы могли бы работать вместе, чтобы убедить вас, что в продукте не обнаруживается побочных эффектов, но без необходимости для вашей команды выполнять все тесты на каждой версии программы?»

Каковы затраты? А прибыли? Определитесь с цифрами.

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

Подсчет расходов относительно прост — отследите, сколько часов тратится на выполнение задач, сопровождающих тестирование — на документацию тестов, на сопровождение пакета GUI скриптов для регрессионных тестов, и так далее. Можно провести расчеты в часах, или привести все к стоимости человеко-часа.

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

Для получения дополнительных данных вы можете поинтересоваться:

• Сколько раз кто-либо вне QA отдела жаловался на слишком большой объем документации, сопровождающей процесс тестирования?
• Как часто после прогона пакета скриптов для регрессионного тестирования находились проблемы? Если это происходило часто, возможно, имеет смысл перенести некоторые из наиболее эффективных тестов в пакет модульных тестов?
• Сколько времени тестеры сэкономят, если у них будет полная и детальная спецификация, на основе которой они строят свои тесты?

Поощряйте коллективное обсуждение.

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

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

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

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

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

Отметим, что название для обсуждаемой темы вроде текста «Тестировщики обязаны проверять NULL значения» будет разделять программистов и тестировщиков, потому что содержит в себе подспудный упрек. Замените его на что-нибудь вроде «Проверки NULL значений» — программисты и тестеры могут работать над такими тестами совместно.

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

Измеряйте изменения.

Если QA менеджер сопротивляется изменениям, потому что он мыслит по-другому, нежели программисты при написании кода, проверьте метрики. Если у вас есть данные из системы учета проблем, вы могли бы посчитать степень воздействия XP методики.

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

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

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

Будьте готовы к компромиссу.

Увы... ваш упрямый QA менеджер по-прежнему не уверен. Он все так же предпочитает делать работу его способом, в то время, как вы хотите, чтобы он выполнял ее вашим способом. Тогда — ищите компромис. Возможно, вы сможете договориться об объеме документации, который подходил бы вам обоим. Возможно, вы сможете подсчитать, как облегчить тестирование пользовательского интерфейса, используя промышленное средство автоматического тестирования, так что QA менеджер сможет сохранить стиль автоматизации, который он предпочитает, без необходимости тратить слишком много времени на поддержку скриптов в актуальном состоянии. И помните - точно так же, как вы хотели бы, чтобы ваш QA менеджер действовал в большей степени в вашем стиле, так и он оценит, если вы будете проявлять больше гибкости.

Примечания.

1. Перевод терминов «QA Manager» и «QA Department».

Как любезно пояснила Элизабет, в США большинство фирм-производителей программного
обеспечения имеют специальный отдел — Quality Assurance Department. В 90% случаев, когда говорят «QA» — подразумевают «тестирование».
Следуя рекомендации Элизабет, для обозначения сотрудника, отвечающего за планирование тестирования и организацию процесса тестирования, в переводе используется термин «QA менеджер».
Для обозначения группы тестировщиков, отвечающих за выполнение тестов, за документирование результатов и составление итоговых отчетов, используется термин «QA отдел», или «отдел тестирования».

2. Русская терминология, касающаяся разработки программного обеспечения по правилам экстремального программирования (далее в тексте — XP), взята с сайта http://xprogramming.ru/.

3. Термин «Agile».
Дословный перевод мог бы спровоцировать внесение идеи конфронтации между менеджером проекта и QA менеджером, искажающей общий дух статьи. В переводе этот термин используется как обозначение методики разработки. Дополнительная информация о нем может быть найдена на сайтах http://www.agilemanifesto.org/ и http://www.agilealliance.org/userGroups/index.

4. Wiki — общедоступная web-ориентированная система для общения группы людей, которая позволяет каждому внести свой вклад в обсуждение той или иной проблемы. Подробности могут быть найдены на сайте http://www.wiki.org.

Ссылки на Интернет-ресурсы, использованные при переводе:

http://stickyminds.com/bettersoftware
http://xprogramming.ru/
http://www.info-system.ru/article/article_extrime_prog.html
http://nit.miem.edu.ru/2003/lukin.htm
http://www.agilemanifesto.org/
http://www.agilealliance.org/userGroups/index
http://wiki.org.