Порассуждаем, как подступиться к написанию авто-тестов на проекте, что делать в первую очередь.
Давайте не будем говорить о конкретном проекте, а представим ситуацию в вакууме? Рано или поздно каждый тестировщик сталкивается с довольно масштабным продуктом, который с каждым релизом все сложнее и сложнее тестировать вручную.
И вот, вы уже в той стадии, когда:
- не помните: когда в последний раз проводили регрессию, потому что времени на нее все нет;
- не знаете, когда же это время появится;
- и все больше и больше ощущаете гнетущую ауру багов, скрывающихся в том функционале, до которого никак не доходят руки.
Смоук занимает сначала 4 часа, потом день, потом полтора и вы, наконец, решаетесь: «Тут нужны автотесты!».
Начнем с того, что нам нужно понять, а что же все-таки автоматизировать? Итак, нам понадобятся следующие вещи:
- Тест-план
По-хорошему, Тест-план должен был быть описан еще в самом начале работы над проектом, но если его по какой-то причине нет, то стоит составить. Кратко описываем продукт, указываем на каких платформах, версия, ОС будем проводить автоматизированное тестирование, не забываем про критерии завершения тестирования.
- Тест-кейсы
Здесь расположился один из самых ответственных этапов автоматизированного тестирования. Нам нужно не просто выбрать кейсы и начать писать код, следует определить основную цель наших автотестов.
1. Выбрать инструменты автоматизации.
Как выбрать инструменты автоматизации? 5 лучших инструментов для автоматического тестирования программного обеспечения прикладываю списком ниже. Выбирайте лучший, под свои нужны и платформу/фичи. Подробный анализ будет позже.
1.1. Selenium
1.2.TestingWhiz
1.3.HPE Unified Functional Testing (HP – UFT ранее QTP)
1.4.TestComplete
1.5.Ranorex
2. Определить трудозатраты, ответственных лиц на проекте.
Автоматизация стоит дорого, нужные специалисты, которые проведут оценку трудозатрат, смогут сделать декомпозицию задач, выбрать ручные тесты для автоматизации. Поэтому, первое с чего нужно начать - определить, кто же будет этим заниматься и не забыть, что должны быть написаны хорошие ручные тесты, определены их приоритеты и составлены комбинации с тестовыми наборами.
3. Просчитать фичи/тесты/кол-во времени на реализацию авто-тестов.
Ключевая автоматизация не может длиться вечно и нужно регулярно показывать какие-то результаты руководителям. Поэтому в первичную выборку должны попасть E2E - тесты, причем по часто-используем сценариям, с наивысшим приоритетом. В этом вопросе поможет интеллек-карта продукта.
4. Записывать план/факт.
Покажите наглядно: сколько времени тратится на выполнение таких же ручных тестов и на авто. Всё станет ясно очень быстро)
5. Начинать с малого - двигаться к большому.
Начните с проектирования тестов с небольшой фичи, отладьте процесс прогона на ней, а далее уже добавляйте все новые и новые тесты.
Разумеется, этот список из пяти пунктов - лишь самое базовое в автоматизации.
Есть смысл подробно обсудить с другими членами QA-команды их текущие практики, найти узкие места (а они обязательно есть), и посмотреть свежим глазом, что в проекте можно решить автоматизацией, и что решить реально другими силами. “Автоматизировать все” по существующему тренду вряд ли получится, а зачастую бывает вредно, представьте, если проект претерпит глобальные изменения - сколько тестов придется актуализировать и отлаживать?
Итак, не везде и не на всех проектах действительно нужна полная автоматизация всех тестов. Иногда, чтобы ускорить работу команды, достаточно вспомогательных скриптов, инструментов без написания кода.