Хабрахабр

[Из песочницы] Что дает объединение ручного и автоматизированного тестирования: опыт 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, продукт разрастается крайне быстро и нет времени на длительные ручные регрессии и оценочное тестирование. У нас эту роль выполняют автотесты, которые покрывают практически каждую составляющую огромного продукта. Это помогает поддерживать качество на должном уровне, оптимизировать ресурсы и быстрее предоставлять пользователям новую функциональность.

Хорошая новость в том, что баги во время фикса также обрастают автотестами.
Почему-то так повелось в сообществе, что идея писать автотесты ручными тестировщиками встречает отторжение. Плохая новость — без багов не обходится, но в нашем случае, чаще всего это все-таки какие-то крайние кейсы. Лично для меня, оба аргумента рассыпаются, когда я осознаю, что могу запустить автотесты в момент разработки фичи и за короткое время понять, насколько она работает правильно. Есть два наиболее популярных аргумента со стороны тестировщиков: “Нам за это не доплачивают” и “У нас и так работы хватает”. Наша работа — улучшать и поддерживать качество продукта, поэтому в ход идет любая возможность облегчить ее. Это дорогого стоит. С момента, как я начал писать автотесты, рутины в моей работе стало меньше, а осознанности больше.

S. P. Поэтому буду рад узнать о подходах, которыми руководствуетесь вы в своей работе. Эта статья отражает только опыт нашей команды и может не соответствовать вашим убеждениям. Также буду рад здоровой критике и возможности обсудить статью в комментариях.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть