При автоматизации тестирования очень часто приходится сталкиваться с вопросом «Что автоматизировать в первую очередь?» Автоматизация не делается ради автоматизации: хочется видеть результат процесса, который давал бы положительный ROI (подробнее о расчете ROI можно прочитать тут).
Почему важно использовать автоматизацию?
Принято считать, что автоматизация тестирования действует как инструмент поддержки ручного тестирования, но на самом деле важно понять, что автоматизация – это наилучший способ не просто сэкономить время, но и повысить эффективность, широту охвата и точность тестирования, ведь повторяющиеся задачи в условиях ручного подхода подвергаются риску человеческих ошибок. Автоматизация не превосходит и не заменяет ручное тестирование, но дополняет его. Подобно управлению тестированием автоматизация также нуждается в разработке стратегии с надлежащим планированием, мониторингом и контролем. Автоматизаторы не только изучают новые способы автоматизации, но и принимают много продуманных решений. Автоматизация при правильной реализации может стать преимуществом для команды, проекта и организации.
Существует много преимуществ автоматизации, мы упомянем следующие:
- ускоряет выполнение обычных задач, таких как дымовые и регрессионные тесты;
- помогает при подготовке тестовых данных;
- оптимизирует выполнение тестовых примеров, связанных со сложной бизнес-логикой;
- облегчает проведение кроссплатформенных тест-кейсов (например, при проверке разных ОС, браузеров и т.д.);
- отлично подходит для выполнения тест-кейсов, которые трудно или даже невозможно выполнить вручную;
- хорошо помогает в тех случаях, когда количество итераций при выполнении заранее неизвестно.
При этом не стоит забывать, что автоматизировать весь процесс тестирования программного обеспечения сложно и экономически неэффективно как из-за дороговизны инструментов тестирования, так и из-за вероятности нестабильного характера определенных разделов приложения. Ситуации на проекте сильно влияет на выбор области для автоматизации (будь то автоматизация тестов для регресса или автоматизация, которая покажет узкие места в частых сборках). Описывая все возможные варианты, мы рискуем получить целую книгу, а потому рассмотрим лишь наиболее часто встречающуюся ситуацию: необходимо автоматизировать набор регрессии.
Итак, каковы критерии выбора тест-кейсов для автоматизации?
Одна из самых частых ошибок, которые делают тестировщики, – выбор неправильных тестов для автоматизации. Нужно внимательно проанализировать и наметить кандидатов для автоматизации с учетом наиболее важного фактора, а именно ROI; другими словами, необходимо выяснить способы получения более высокой и положительной ROI. Для этого придется предпринять ряд действий:
- определить частоту выполнения тестового примера (запускают его для каждой новой сборки или один раз, но с большим объемом ввода?);
- выяснить, является тест-кейс критичным для бизнеса или охватывает полный сквозной сценарий;
- убедиться, что анализ результатов автотеста не будет превышать время, которое затрачивается при ручном тестировании (в противном случае он потеряет свою актуальность для автоматизации);
- учесть вероятность обнаружения ошибок (ввести тесты, которые чаще всего показывают ошибки и слабые места);
- понять, может ли тест стать блокирующим для важной функции или функциональности, которая имеет решающее значение для бизнеса.
Какие типы тестов следует исключать из тестирования автоматизации?
Перечислим случаи, при которых тесты-кейсы нужно отфильтровать от автоматизации:
- тесты юзабилити, требующие ручного вмешательства для проверки ошибок или отклонения от ожидаемого поведения;
- тестовые примеры, включающие в себя установку или не нуждающиеся в повторном исполнении функции (тем не менее, вы должны автоматизировать тесты, предполагающие объемные входные данные);
- избегайте автоматизировать тесты, которые могут привести к непредсказуемым результатам (например, новый функционал, временные тесты, проверка даты истечения срока действия);
- UX-тесты, которые включают проверку повторной калибровки объектов на разных размерах экрана.
Что дальше?
Исходя из вышеперечисленных факторов отбора, мы получим сценарии, которые будут участвовать в отборе для автоматизации.
Следующим шагом будет разбиение тестируемого приложения на модули. Для каждого модуля анализируем и идентифицируем тест-кейсы, которые будут выполняться с различным набором данных, на различных средах (ОС/Браузер) и со сложной бизнес-логикой, используют большой объем данных (в том числе и специальных) и применяются различными пользователями.
Рассмотрим процесс на примере. У нас есть модуль с созданием заявок в системе, для которого мы отбираем тест-кейсы, участвующие в процессе создания заявки. После того, как все тесты выписаны, мы отмечаем, выполняется ли хотя бы одно из условий определенное нами выше (рис.1).
Y – условие выполняется
N – Условие не выполняется
Таким образом, мы получаем 3 тест-кейса, которые можно начать автоматизировать, и 2 тест-кейса, не требующих автоматизации. Мы выполнили самую важную задачу и добрую половину работы: беспорядок новой темы превращается в подробный план того, что нужно сделать.
Вывод
Чаще всего мы предпочитаем автоматизировать набор регрессии, поскольку он содержит большее количество тестовых примеров, а его функционал уже стабилен (то есть, не меняется от сборки к сборке). В этом случае мы можем разбить регрессионные наборы на модули и принять решение о запуске соответствующего пакета в соответствии с требованиями к выпуску.
Вместо автоматизации всего набора мы выбираем фазовую автоматизацию. Другими словами, мы следуем прототипу модели для разработки пакета автоматизации.
Итак, создавайте структуру или фреймворк с реализацией меньшего количества тестовых примеров, а затем улучшайте его, добавляя все больше примеров.
Любите тестировщика в себе, а не себя в тестировании!
