Home

Оригинал статьи: http://katrinatester.blogspot.ru/2017/07/test-automation-canvas.html

Автор: Катрина Клоки (Katrina Clokie)

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

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

Недавно мне довелось работать с группой из восьми тестировщиков, принадлежащих к четырем разным Agile-командам, работающим над одним и тем же набором продуктов. Они регулярно встречались для обмена идеями, но их автотесты начали сильно различаться. Все тестировщики учились в основном независимо друг от друга.

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

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

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

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

В результате я составила список из девяти ключевых областей:

1. РИСКИ. Какие потенциальные проблемы уменьшаются благодаря этому набору тестов? Почему он вообще существует?
2. ПОКРЫТИЕ. Что делает этот набор тестов?
3. ОГРАНИЧЕНИЯ. Что мешает нам идеально внедрить этот набор тестов? Есть ли известные нам обходные пути?
4. ЗАВИСИМОСТИ. Функционирование каких систем или инструментов необходимо для успешной работы этого набора?
5. ДАННЫЕ. Используем ли мы заглушки, запросы или инъекции? Как мы управляем тестовыми данными?
6. ВЕРСИОНИРОВАНИЕ. Контролируем ли мы версионность? Какой моделью ветвления мы пользуемся для этого набора?
7. ВЫПОЛНЕНИЕ. Этот набор – часть процесса тестирования? Как часто он запускается? Как долго он длится? Стабилен ли он?
8. ВКЛЮЧЕННОСТЬ. Кто создал этот набор? Кто работает над ним сейчас? Кто над ним не работает, а должен?
9. ПОДДЕРЖИВАЕМОСТЬ. Как организован процесс код-ревью? Есть ли документация?

Я решила расположить эти пункты на бумаге формата A3, как матрицу Lean или матрицу возможностей. Я подумала, что такой формат сбалансирует переговоры и записи, так как я ожидала, что и то, и другое будет происходить одновременно.

Вот матрица, которую я сделала:

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

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

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

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

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

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

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

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

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

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

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