Home

Автор: Михаил Чумаков

Приближается масштабная юбилейная 20-ая международная конференция для специалистов в области обеспечения качества - SQA Days, которая в этот раз пройдёт в Минске. В этом году мне удалось войти в Программный комитет конференции и принять участие в отборе докладов и подготовке докладчиков.

Как говорится в официальном пресс-релизе: “Доклады, представленные на конференции, прошли не просто серьезный, а можно сказать, суровый отбор.” т.е. большое количество выступлений пришлось отсеять или серьёзно переформатировать.

Одна из тем, на которую было подано целых четыре заявки можно собирательно назвать - “Как делать правильную автоматизацию”. Во многих из докладов рассказывалось про конкретный опыт, набитые шишки, сотни пройденных граблей! Но, как писали в советских методичках,  закаленного инженера такие преграды не устрашат.

Чтобы не потерять полезный опыт и изложить сообществу практические советы коллег, было решено написать эту статью.

Помимо всем известных прописных правил эффективной автоматизации, таких как:

• для автоматизации нужны свои ТС или универсальные ТС, просто ручной тест != тест для автоматизации.
• начинать автоматизацию со смоук/приёмочных тестов
• рутинные операции, такие как переборы данных (формы с большим количеством вводимых полей. Автоматизировать заполнение полей различными данными и их проверку после сохранения)
• валидационные сообщения (автоматизировать заполнение полей некорректными данными и проверку на появление той или иной валидации)
• автоматизировать end-to-end сценарии
• автоматизировать проверку данных, требующих точных математических расчетов
• при создании автотестов помнить про пирамиду тестирования  (Unit / API/ GUI)

у QA-инженеров своя пирамида потребностей

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

Например, Стрункин Павел описал как им в компании удалось решить проблему синхронизации отделов автоматизации и ручного тестирования.

“Раньше у manual тестировщиков в нашей компании были тест-кейсы, у автоматизаторов не было ничего. Мы сделали декомпозицию с точки зрения автоматизации - разбили на логические части (“pages”), которые мы будем использовать в своих тестах для создания pageObject’a. На каждой “пейдже” определили функционал который работает, вплоть до самого последнего элемента, до объекта.

Далее, с точки зрения функционального тестировщика, мы выделили критичность функционала. Т.е. сколько нам будет стоить ошибка в конкретной части системы с точки зрения бизнес-ценности самой системы в целом, и нашей зарплаты в частности :)

Дальше в этом списке мы сделали приоритезацию с точки зрения автоматизатора. Мы оценивали эти кейсы, отвечая на вопрос на сколько быстро можно будет создать автотесты, на сколько будет удобнее писать тесты на основе этого теста, будет ли данный тест стабилен и далее - сопоставили обе таблицы. За основу взяли критичность системы.

В результате получился чек-лист из которого понятно:

• что уже автоматизировано,
• какой следующий тест автоматизировать
• какие тесты проходить руками мануального тестировщика

Стрункин Павел, SoftServe

Сергей Матвеев поделился применяемой практикой разделения тестов на уровни:

“В начале у нас не было проблем в автоматизации. Автоматизировали все, что попадалось под руку.

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

Какой выход нашли мы:

Мы раздели наши тесты на 3 уровня:

• бизнес-логика (на этом уровне пишутся тесты в терминах бизнес логики. Это уровень отражения user cases)
• реализация первого порядка (уровень который понимает, как именно должна реализовываться эта бизнес логика)
• реализация второго порядка (логика работы с драйвером).

Таким образом тесты написанные 1 раз не менялись, пока не поменялась бизнес-логика приложения. Редизайн или изменение карты сайта затрагивали только уровень реализации 1-го порядка. Если вдруг нужно было изменить инструмент для работы с браузером, мы меняли только слой реализации второй порядка.

Всем известный шаблон проектирования Page object не решал нашу проблему, так как мы тестируем современные SPA приложения, с микросервисной архитектурой, т.е. у нас нет привычных страниц. Поэтому мы скомпоновали всю логику различных форм в блоки, которые затем подключали в первый слой реализации.“

Сергей Матвеев, QIWI wallet

Игорь Любин рекомендует начинать всем автоматизацию с построения непрерывной интеграции (CI) на проекте

“Что можно автоматизировать? Можно автоматизировать тестирование приложения, можно автоматизировать процесс сборки и выкладки. Именно с этого и нужно начинать. Без этого не будет автоматического тестирования, без этого оно не взлетает. Только когда мы сможем автоматически в одно нажатие выполнять сборку проекта и выкатывать его, только тогда мы настраиваем автоматический запуск тестов, вставляем unit-тесты между сборкой и выкладкой. В конце запускаем автоматические интеграционные тесты. Весь этот процесс важно автоматизировать с помощью инструментов CI. Философия DevOps учит нас автоматизировать все эти процессы, чтобы поставлять заказчику как можно быстрее его фичи. Времени размышлять когда там будет выполнено ручное тестирование нам некогда, всё должно быть автоматически.“

Игорь Любин, MediaMarkt, auto-testing.ru

Роман Иовлев изложил несколько анти-паттернов, можно сказать, ТОП-5

“В нашей компании мы стараемся регулярно рассказывать о том, как надо правильно писать автоматизацию, проводим ревью тестовых проектов, и обобщаем правильные практики и решения в так называемые акселераторы - готовые настроенные пустые тестовые проекты. Но поскольку компания большая и растет быстро, то донести информацию до всех сотрудников бывает не просто. Особенно это свойственно для вновь пришедших сотрудников. Для этого мы разработали методичку, которую условно можно назвать "Как НЕ надо писать автотесты"

На мой взгляд - это первый необходимый шаг, до того как объяснять как же правильно писать автотесты. Вот ТОП 5 наших правил"

1. Тестовые сценарии и классы должны быть наглядными и понятными. Их должен уметь прочитать ручной тестировщик или аналитик (даже если это код)

a. Все лишнее из сценариев надо выносить в отдельные модули. Общие части в before/after test. Объединять много (более 2-3) идущих подряд проверок в общую проверку результата шага

b. Размер каждого теста не более 10-15 строк. Тестового класса 150-200. В противном случае скорее всего его можно разбить на несколько

c. Названия тестовых методов и классов должны четко выражать суть теста

d. Каждая строка тестового сценария отображает бизнес действие, которое должен сделать пользователь

e. Все проверки должны присутствовать в сценарии. Не надо прятать их вглубь шага-действия

2. Сами по себе тестовые сценарии бесполезны без правильной инфраструктуры:

a. Тесты обязательно должны запускаться на регулярной основе. Соответственно, сценарии должны быть управляемы через CI (выбор окружения, наборов тестов, браузеры и т.д.)

b. Тестовый набор должен стабильно проходить на работающем приложении. Если это не так исправьте тесты, которые нестабильны или исключите их если сейчас нет времени.

c. Тесты должны предоставлять нужную информацию о результате в удобном формате. Очень часто, результат прогона – это не только passed/fail, а в том числе логи ошибок и соответствующий репортинг. Ваши тесты должны быть рассчитаны на это.

3. Тесты должны быть независимы. Каждый тест можно выполнить отдельно. Используйте предусловия для приведения теста в исходное состояние. Тесты не должны мешать друг другу при параллельном запуске (использовать общие ресурсы). Если это невозможно выносите такие тесты в отдельный suit, их обычно немного.

4. Никогда не используйте ThreadSleep. Вместо этого можно ждать появления элемента, его нового состояния или завершения какого-то действия (загрузки страницы, ajax и т.д.)

5. Думайте головой и получайте удовольствие от тестирования, если автоматизация приносит вам головную боль – это явный признак, что вы что-то делаете не так!”

Роман Иовлев, <epam> systems

Знание начинает приносить пользу, только когда оно превращается в конкретные действия. Коллеги, применяйте полезные практики!

До встречи на SQA Days 20!

Обсудить в форуме