Как понять, что пора автоматизировать тестирование

Как понять, что автоматизация тестирования принесет пользу?
Как понять, что автоматизировать, а что нет?
Как безболезненно для проекта начать автоматизацию?

Если вы хоть раз задумывались над этими вопросами, наша статья поможет в них разобраться.

Цели автоматизации

• Повысить эффективность тестирования. Регулярные автотесты освобождают время специалистов для исследования нового функционала вместо контроля качества уже готового (особенно регрессионного тестирования). Можно настроить запуск автотестов в ночное и нерабочее время. Это сократит время на тестирование и обеспечит точность результатов, ведь машины не допускают ошибок;


• Сократить сроки тестирования. Сокращается процесс «нахождение бага - регистрация - исправление - проверка». В «ручном» режиме он занимает около дня, в автоматизированном - 2 минуты. Например, если во время smoke-тестирования после сборки приложения в CI какой-либо из тестов «упал», сборка будет помечена как дефектная и логи тестов направлены ответственным за исправление разработчикам;


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


• Уменьшение затрат на тестирование. Однажды спроектированные и написанные автотесты нуждаются в минимальном сопровождении - в случае изменения функционала и/или интерфейса в новых версиях. На корректировку скриптов уйдет от 10 минут до нескольких часов в зависимости от количества изменений в продукте.

Когда внедрение автоматизации принесет пользу:

• Величина проекта. Проекту больше года, он состоит из множества подсистем. Количество тестов, которые нужно прогонять, растет. Мы начали автоматизировать тестирование системы управления ресурсами, когда «ручных» тест-кейсов накопилось 600, и на их проверку одним человеком уходила неделя. Специалисты должны тестировать, а не проходить тест-кейсы;


• Большая команда. В команде больше двух разработчиков. Разработчик должен быть уверен, что его изменения не сломают чужой код. Без авто-тестов он узнает об этом в лучшем случае через день-два, в худшем — от пользователей;


• Поддержка старых версий. Вы поддерживаете несколько версий продукта и выпускаете патчи и сервис-паки под каждую из них. Тестирование на разных конфигурациях — это рутина, которую можно автоматизировать;


• Генерация тестовых данных отнимает много времени. Вы разрабатываете сервис для обработки и трансформации всевозможных данных: системы заявок, учета профилей и т.д. Заниматься ручным вбиванием в систему данных и визуальным анализом результатов или отправкой запросов и анализом ответов — неоправданная трата ресурсов. Частые релизы. У вас Agile с короткими итерациями и частыми релизами. Тратить неделю на тестирование в рамках спринта - слишком долго, когда можно потратить 1 день.

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

Как мы поняли, что нужно автоматизировать

Мы разрабатываем приложение для учета соискателей и сотрудников для HR: поиск, прием на работу, задания на испытательный период, отпуска, текущие задачи и проекты и т.д.

Предпосылки для автоматизации:

• Продукту 3 года;


• В команде 5 разработчиков;


• Релизы обычно раз в 3 недели;


• Много генерации тестовых данных

Итого: 4 признака из 5. До автоматизации на проверку всех тест-кейсов уходило 4 дня.

Решение

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

Результат

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

Противоположная ситуация сложилась на другом проекте - приложении для создания оценок и аналитики.

Предпосылки автоматизации

Автоматизировать решили в качестве эксперимента. Это молодой проект, в нем пока не так много функционала - всего 61 тест-кейс.

Решение

Проект примечателен тем, что на нем нет ни одного ручного тестировщика. Исследовательское ручное тестирование делает автоматизатор на этапе написания и отладки скрипта автотеста, который затем просто прогоняется в CI, заменяя тем самым ручной труд.

Результат

На июль 2017 года автоматизировано 46 тест-кейсов на бэкeнд и 14 на фронтeнд, покрытие кейсов автотестами около 96%.
Этот проект - наглядный пример того, что будет, если начать автоматизировать с самого старта работ: временны́е затраты на тестирование за все время жизни проекта меньше, чем если бы сначала мы тестировали вручную, а затем внедрили автоматизацию.

План действий по автоматизации

Итак, вы удостоверились, что автоматизация тестирования принесет пользу. Что дальше? Разрабатываем план действий:

• что автоматизировать;
• как автоматизировать;
• чем автоматизировать.

Что автоматизировать

1. Труднодоступные места в системе: бэкенд процессы, логирование файлов, запись в базы данных;
2. Часто используемый функционал, где высоки риски ошибок: системы оплаты, регистрации и т.д. Автоматизация проверки критической функциональности гарантирует быстрое нахождение ошибок - 1 тест в среднем идет 2 минуты. Быстрее найдем - быстрее исправим;
3. Рутинные операции: переборы данных, формы с большим количеством вводимых полей. Автоматизировать заполнение полей данными и их проверку после сохранения;
4. Валидационные сообщения: автоматизировать заполнение полей некорректными данными и проверку на появление валидации;
5. Длинные end-to-end сценарии. Например, сценарий для риэлторской CRM: регистрация пользователя - заведение заявки от его имени - создание задачи - взятие в работу - назначение задач на специалистов - получение задач обратно в работу- регистрация результата;
6. Проверку данных, требующих точных математических расчетов: бухгалтерское или аналитическое ПО;
7. Проверку правильности поиска данных.

Как автоматизировать

Не все тест-кейсы нужно автоматизировать в первую очередь. Например, если у вас 300 тест-кейсов для проверки модулей, 100 для компонентов, 20 для подсистем и всего 5 пользовательских сценариев (см. рис.2), начинать автоматизацию лучше с тестов, проверяющих отдельные функции, т.е. с unit-тестов. Они выполняются быстро, но их больше. Когда эти кейсы уже покрыты автотестами, можно приступать к автоматизации тест-кейсов по проверке компонентов, далее - подсистем и т.д.

Полная автоматизация

Предпосылки для автоматизации

Пример полной автоматизации - надстройка над Jira для планирования и управления проектами. На проекте порядка 600 тест-кейсов, все покрыты автотестами. В случае изменений логики или интерфейса, приходится править около 100 скриптов. Это все равно занимает меньше времени, чем ручное тестирование.

Решение

На этапе планирования автоматизации для определения количества автоматизируемых тест-кейсов для каждого уровня архитектуры мы взяли пропорции из пирамиды тестирования (рис.3). В итоге у нас получилось более 300 unit-тестов, 200+ на интеграцию и API и 38 GUI-тестов, повторяющих сценарии использования продукта конечным пользователем.

Результат

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

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

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

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

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

Чем автоматизировать

Выбор инструмента зависит от специфики приложения и требований к тестовым сценариям. Чаще всего выбирается несколько инструментов - отдельно для каждого уровня архитектуры системы. Например, GUI тестируется с помощью Selenium, API с java + restAssured, а нагрузка с jMeter.

На что обратить внимание при выборе

1. Мы не рассматриваем бета-версии и нестабильные сборки инструментов. Это экономит время на решение проблем, связанных с дефектами самого инструмента. Например, проблемы с кодировкой в RF HTTPLibrary;
2. Желательно, чтобы документация инструмента была на русском языке (как, например, для Selenium);
3. Специализированные форумы по конкретному инструменту помогают быстрее получить ответы на вопросы использования. Например, если используете связку java TestNG + Selenium, в интернете можно найти ответ любой вопрос. А вот если возьметесь за Python based Robot Framework - документация будет только на английском и без описания особенностей использования кейвордов, в поисках которых приходится анализировать код библиотек;
4. Обращаем внимание на возможность интеграции инструментов тестирования с программным обеспечением, которое используется в компании;
5. Стоимость инструментов тестирования: если планируете одноразовое тестирование, покупать дорогостоящие инструменты нецелесообразно.

Что для чего подходит

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

Примеры:



• Selenium, Appium, Winium для UI;
• Основанные на Java библиотеки и инструменты: TestNG, jUnit, RestAssured, Allure;
• Основанные на Python Robot Framework, Calabash (KDT), pytest, py.saunter и т.д.

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

Примеры: jMeter, Яндекс.Танк, Siege, HP LoadRunner.

Мы предпочитаем работать с популярными и надежными средствами тестирования: Selenium Webdriver, Java TestNG, jUnit, RestAssured, Allure, jMeter, хотя у нас есть опыт использования и других инструментов (например, Robot Framework).

Практически каждую задачу в пределах одного вида тестирования можно решить с помощью любого инструмента, однако трудоемкость и стоимость решения будут отличаться. Например, если у инструмента нет средств анализа результатов и построения отчетов (как в случае использования, предположим, testNg + Selenium без Allure), то время на анализ результатов автоматизированного тестирования будет примерно таким же, как при ручном тестировании. Выгоды никакой. Внедрение автоматизации тестирования пройдет легко и быстро, только если в самом начале правильно подобрать инструмент под решаемые задачи. Одно лишь это уже может стать ключом к успеху.

Итого

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

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

Автоматизированное тестирование призвано помочь команде делать те же задачи быстрее и оперативней выпускать новые релизы продукта. Если обычно на тестирование уходит 3-4 дня, с автоматизацией это время сократиться до нескольких часов. Это особенно актуально для крупных и постоянно развивающихся IT-продуктов.