[Из песочницы] Что дает объединение ручного и автоматизированного тестирования: опыт Wrike
Читая статьи на тему web-тестирования, вырисовываются условно две темы: 1) ручное тестирование вымирает, автотесты (здесь и далее под автотестами имеются в виду Selenium UI и REST-тесты) — наше все; 2) автоматическое тестирование — не панацея, без ручного тестирования не обойтись. При этом из статей намечается тенденция на рост требований к качеству программного обеспечения и скорости развития продукта. Wrike — это как раз тот случай, когда эти требования критически важны.
Продукту уже 12 лет, но он до сих пор активно разрастается. Деплои происходят раз в день, а иногда и два. Поэтому нам критически важно, чтобы регрессия проводилась исключительно на автотестах. Однако в Wrike (в компании) свыше 30-ти scrum-команд, а штат команды автоматизаторов не резиновый. В таких условиях ожидать автоматизации ручных сценариев в лучшем случае один-два спринта — не вариант. Опыт нашей компании говорит, что ручной тестировщик может самостоятельно писать автотесты, при соблюдении некоторых нюансов. В статье расскажу о них и почему, на мой взгляд, это умение не только помогает соответствовать тенденциям, но и будет полезно для самого тестировщика.
Стандартный процесс
К какому процессу привыкли многие команды? Он варьируется от случая к случаю, но общие черты примерно одинаковые. Есть отделы автоматического и ручного тестирования. Ручные тестировщики могут быть распределены по scrum-командам. При этом автоматизаторы, как правило, к конкретной команде отношения не имеют.
При работе с новой функциональностью тестировщик создает тестовые сценарии, некоторые из которых он помечает заранее оговоренным способом для автоматизаторов. Кроме того, если уже есть кейсы, в которые вносятся корректировки, то их тоже отмечают, чтобы актуализировать код. Далее помеченные тесты передаются в отдел автоматизации. Команда автоматизаторов берет задачу на исправление текущих и написание новых автотестов в один из следующих спринтов. Помимо программирования тестовых сценариев, в задачи автоматизатора входит прогон автотестов, анализ результатов, а также поддержка и развитие тестового проекта. Получается, что отдел автоматизации выступает в роли outsource-исполнителя, а ручные тестировщики — своего рода заказчики.
Заказчик дополнительно тратит время на составление подробного и точного ТЗ, периодические обсуждения способов реализации и отбор необходимых тестов. Также существуют риски, что за время отсутствия автотестов могут быть пропущены баги. Не стоит забывать, что есть пласт технических задач, которые можно было бы катить только на автотестах, что существенно сэкономило бы время. Такие задачи придется проверять руками в той части, где автоматизация еще отсутствует.
Исполнителю же, не будучи сильно погруженным в функциональность, которой занималась команда, потребуется время на поверхностное погружение в задачу и в осознание ТЗ. При этом есть вероятность, что тест транслирован в код не точно, из-за чего он будет проверять не то, что хотелось бы. Соответственно, КПД тестовой базы снижается.
Команда автоматизации, являясь единственным контрибьютором в тестовый проект, имеет полный контроль над его кодовой базой, что позволяет спокойно его развивать в любом направлении. Однако времени на это становится недостаточно из-за возрастающей нагрузки со стороны других команд. Проблема может решаться расширением штата, но тогда затраты на автоматизацию станут превосходить ее эффективность. Даже, если снять часть нагрузки, дав ручным тестировщикам возможность запускать тесты и анализировать упавшие, то это не принесет должного результата. Так как у них нет инструментов для дебага тестов, они могут не понять, что тест упал из-за изменения xpath и так далее.
Соответственно, на выходе мы получаем, что автотесты при такой схеме не поспевают за ростом продукта, что приводит к плохому покрытию кода. Из-за неточной интерпретации ТЗ тесты могут пропускать баги. Когда они длительное время находятся в неактуальном состоянии, упавшие чинятся не сразу, а ручным тестировщикам трудно сразу сказать, какая часть системы хорошо покрыта автоматизацией. Автотесты становятся некоторым черным ящиком, к которому тестировщики относятся с недоверием. Отсюда растет число излишних ручных проверок, сроки задач растягиваются, а качество в долгосрочной перспективе снижается.
С перечисленными недочетами можно работать, но, чем больше продукт и компания, тем больнее участникам процесса, а главное — сложно следовать тенденции на повышение скорости и улучшение качества. Сам же тестировщик становится заложником рутины и на развитие времени практически не остается.
Wrike way
Итак, как это устроено на примере команды, в которой работаю я. Есть команды автоматического и ручного тестирования. Исходные данные пока схожи, но дальше начинаются различия. Ручные тестировщики распределены по своим scrum-командам. У каждой scrum-команды есть свой автотестировщик. Иногда он может быть выделен не на одну, а на две команды, если нагрузка позволяет.
При работе с новой функциональностью тестировщик пишет чек-листы, по которым потом проводит ручные проверки. Минимально необходимая часть тестов из этого чек-листа автоматизируется. Пишет эти автотесты сам тестировщик еще в момент, когда фича находится в разработке или тестировании. Далее написанный код отдается на review автоматизатору. За редким исключением задача без автотестов выпускаться не может.
Конечно, в Wrike нет требования писать автотесты силами ручных тестировщиков. Это остается на усмотрение команды. Можно отдать все на откуп автоматизаторам. Можно ограничиться исправлениями сломанных и/или написанием новых тестов по аналогии, а более сложные задачи (создание новых тестов или расширение старых back-end ручек, Page Object или тестовых шагов и классов) делегировать выделенному автоматизатору. Все зависит от вас, но глупо упускать те плюсы, которые дает самостоятельное написание автоматических тестов.
У нас вся регрессия построена на автотестах, и в круг обязанностей ручных тестировщиков входит прогон и анализ падений автотестов. По каждой ветке, над которой работает команда, прогоняют автотесты как начальный и финальный гарант качества. Поэтому тем, кто самостоятельно пишет автотесты, гораздо легче понять почему тест, запущенный на их ветке, упал. Иногда действительно хватает таких инструментов, как rerun и отчет в Allure, где по снимку экрана и шагам можно понять причину падения теста. Однако зачастую лучший помощник — возможность запустить тесты локально, поиграться с шагами или запустить их в дебаг режиме, посмотреть ожидаемый и реальный xpath. Без опыта работы с тестовым проектом это будет занимать много времени, либо будет необходимо отвлекать выделенного автоматизатора.
Кроме того, самостоятельное написание автотестов дает возможность прогонять их еще до релиза фичи. Тестировщик всегда знает степень покрытия его части системы, и технические задачи катятся только на автотестах, что существенно экономит время и ресурсы команды. Сами тесты всегда актуальны, так как падения корректируются до релиза. Сломанные тесты правятся сразу в той же ветке, где пишутся новые.
Ручной тестировщик максимально погружен в задачу команды, поэтому выбирается необходимый минимум автотестов, покрывающий большинство кейсов. Выборка несколько раз пересматривается по мере тестирования, так как в ходе ручных проверок функциональность изучается более детально со всеми нюансами. Соответственно КПД таких тестов растет. Написание автотестов позволяет лучше понять архитектуру приложения, используемые компоненты и взаимодействие front-end с back-end. В конечном счете, эти знания помогают более осознанно и эффективно подходить к тестированию продукта. Например, если какая-то команда вносит правки в общий компонент, то у вас больше шансов заранее узнать будет или не будет затронут ваш scope, так как работая с xpath вы понимаете, какие компоненты используются в вашей части приложения.
Можно возразить, что написание автотестов требует времени. Да, задачи релизятся на один-три дня позже обычного, но в долгосрочной перспективе это окупается. Тем более есть способы оптимизации. Например, пока фича находится в разработке, можно составить необходимые чек-листы и сделать заготовку для тестов, тем самым сэкономив время. При наличии готового каркаса функциональности, есть возможность добавить или поправить существующие xpath, при необходимости создать новый Page Object или откорректировать шаги. Тогда на этапе написания автотестов, уже после ручных проверок, нужно будет просто сложить блоки кода в правильном порядке.
Благодаря фреймворку, который разработала наша команда автоматизации, написание автотестов в большинстве своем представляет составление кода из блоков — как Lego. Эта простота позволяет быстрее адаптироваться ручным тестировщикам и начинать писать автотесты по аналогии с уже существующими. По своему опыту скажу, что с момента выхода на работу в Wrike и до первых написанных мною автотестов, вкупе с другими задачами, ушло около двух недель.
Контроль за качеством написанных автоматических тестов осуществляется посредством code review. Ни одна тестовая ветка не попадает в релиз без проставленного ревью. Это хороший обучающий момент, так как из комментариев к своему коду тестировщик черпает полезное и нарабатывает опыт хороших решений: например, эффективнее управляется со стандартной библиотекой Java или точнее определяет xpath. В следующий раз будет понятно, как лучше работать с той или иной ситуацией.
Конечно, развитие тестового проекта, фрэймворка и обучение ручных тестировщиков занимают ресурсы автоматизаторов, особенно на начальном этапе, но, как мне кажется, эти усилия полностью окупаются. У нас много улучшений в среде автоматизированного тестирования, которые нам облегчают работу. Сам продукт имеет хорошее покрытие, благодаря чему на регрессию можно положиться. Это помогает ускорить процесс выкатки фич на пользовательское окружение и здорово бережет нервы тестировщиков.
По опыту нашей команды это один из лучших процессов для работы с большим и быстро развивающимся продуктом в большой компании. Более того, он соответствует текущим тенденциям на повышение качества ПО и скорости его доставки пользователям. Сам же тестировщик практически избавляется от рутины, развивается в нескольких направлениях и смотрит на приложение с нескольких углов.
Коротко о главном
Для удобства выделю плюсы для ручного тестировщика в одном месте, чтобы было легче осознать их значимость по-отдельности или всех вместе:
- Формируется более полная картина об уровне и качестве автоматизации вашего скоупа;
- Автотесты доступны до релиза фичи, что дает возможность в любое время быстро проверить ее качество;
- КПД автотестов возрастает, как и КПД тестирования в целом;
- Формируется более осознанный и эффективный подход к тестированию;
- Избавление от монотонных ручных регрессий и долгих оценочных тестирований;
- Личный рост и развитие компетенций.
Подводя итоги
Конечно, нет никакой серебрянной пули. То, что для одной компании подходит, может резко отвергаться другой. В случае Wrike, продукт разрастается крайне быстро и нет времени на длительные ручные регрессии и оценочное тестирование. У нас эту роль выполняют автотесты, которые покрывают практически каждую составляющую огромного продукта. Это помогает поддерживать качество на должном уровне, оптимизировать ресурсы и быстрее предоставлять пользователям новую функциональность.
Плохая новость — без багов не обходится, но в нашем случае, чаще всего это все-таки какие-то крайние кейсы. Хорошая новость в том, что баги во время фикса также обрастают автотестами.
Почему-то так повелось в сообществе, что идея писать автотесты ручными тестировщиками встречает отторжение. Есть два наиболее популярных аргумента со стороны тестировщиков: «Нам за это не доплачивают» и «У нас и так работы хватает». Лично для меня, оба аргумента рассыпаются, когда я осознаю, что могу запустить автотесты в момент разработки фичи и за короткое время понять, насколько она работает правильно. Это дорогого стоит. Наша работа — улучшать и поддерживать качество продукта, поэтому в ход идет любая возможность облегчить ее. С момента, как я начал писать автотесты, рутины в моей работе стало меньше, а осознанности больше.
P.S. Эта статья отражает только опыт нашей команды и может не соответствовать вашим убеждениям. Поэтому буду рад узнать о подходах, которыми руководствуетесь вы в своей работе. Также буду рад здоровой критике и возможности обсудить статью в комментариях.
