Home

Автор: Ян Яап Каннегитер (Jan Jaap Cannegieter)

Оригинал статьи: http://www.testingcircus.com/the-way-to-involve-stakeholders-in-testing/

Перевод: Ольга Алифанова

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

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

Контекст: организация, проект, система

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

Целью проекта было создание веб-приложения, в котором люди могут получать личные советы по поводу сохранения энергии. Совет был основан на сложном опроснике, который клиентам нужно было заполнить. Функциональность в опроснике и советах была не так-то проста. Разработка приложения была отдана на аутсорсинг компании, занимающейся разработкой. Я в этом проекте работал как аналитик требований, инженер по обеспечению качества и тестировщик. Более того, в проекте участвовали проектный менеджер, полдюжины пользователей (экспертов по контенту) и два сотрудника IT-отдела. Приложение разрабатывалось итеративно, требования выявлялись и документировались заранее.

Проблема с тестированием

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

Охота на баги

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

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

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

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

Во время второй сессии мы использовали отдельные ноутбуки, на которые я предварительно установил ПО и быстро протестировал его наладку. В сессии участвовало четыре пользователя, IT-сотрудник и проектный менеджер – три пары тестировщиков. Я ходил между ними и обсуждал дефекты, требования, специфические экраны. Вышло очень даже неплохо. Во время последнего получаса мы вместе обсудили наиболее важные дефекты, а после сессии я передал дефекты разработчикам. Я был крайне доволен!

Тестирование стало только лучше

С этого дня мы проводили тест-сессии, или, как я их называл, охоты на баги, еженедельно. И они становились все лучше и лучше организованы и управляемы – возможно, потому, что мы регулярно оценивали их успех. Как-то раз я слышал от кого-то «Если вам разрешают внедрить одну-единственную Agile-практику – внедряйте ретроспективу». Полностью согласен! Благодаря этим оценкам тест-сессии постоянно улучшались.

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

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

Для управления тест-сессиями я сделал тест-чартеры с определенным объемом, целью тестирования и точками тестирования. Каждая пара получала чартер, и этой работы им хватало примерно на час. За сессию пары тестировали около двух часов, не включая инструктаж, перерывы и разборы полетов. Этот дополнительный час использовался для исследовательского тестирования (мы называли его свободным тестированием), предпочтительно с определенным масштабом и целью. Заметки об этом тестировании были не особенно хороши, но я как минимум научил своих тестировщиков хорошо оформлять дефекты.

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

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

Ситуационное тестирование

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

Ценность охот на баги

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

Лично я считаю, что профессионалы тестирования должны освоить разные виды тестирования и уметь разобраться, какой из них лучше подходит в отдельно взятой ситуации. Чтобы помощь профессионалам добиться этого в SYSQA B. V., мы разработали ситуационное тестирование – о нем можно прочитать выше.

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

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