Автотесты или ручное тестирование: разбираем на кейсах

Что это такое и в чем разница?

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

Для этого у QA-специалиста есть два метода:

1. ручное тестирование сайта,
2. автоматическое тестирование сайта.

При первом подходе тестировщик вручную формирует и проверяет сценарии поведения пользователя. Дополнительные инструменты не используются.

При втором подходе тестировщик автоматизирует проверку сценариев. На входе он подготавливает данные, а затем при помощи инструментов проверяет заготовленные сценарии. Например, в нашей практике мы используем: PHPUnit, Jest для javascript и Playwright для End-2-End тестов.

Автотесты и ручное тестирование имеют свои преимущества и недостатки. В одних ситуациях автоматическое тестирование экономит время и деньги. В других — ручное тестирование оказывается быстрее и дешевле. Поэтому ниже разберем, когда стоит использовать тот или иной подход.

Когда использовать ручное тестирование сайта?

• Тесты запускают редко. Автотесты отнимают много времени на подготовительном этапе. Поэтому ручное тестирование выгоднее там, где не нужны частые и быстрые проверки. Например, если у вас корпоративный сайт на готовом решении от Битрикс.

• Для поиска визуальных или UX ошибок. Такую расплывчатую задачу компьютер решить не может. При автотесте нужны четкие формулировки. Поэтому только ручное тестирование подходит для проверки удобства использования сайта и визуальных ошибок.

• Ошибку нельзя обнаружить при помощи автотестов. К тестированию можно подходить творчески. Например, QA-специалист придумывает необычные поведенческие сценарии — это помогает раскрыть критические ошибки, которые нельзя обнаружить при автоматизированном тестировании.

Когда использовать автоматическое тестирование сайта?

• Для регулярного мониторинга ошибок. Например, когда на сайте каждый час оставляют десятки заказов. А значит, вы должны быть уверены, что форма заказа работает постоянно.

• Повторяющиеся задачи. Внедряйте автотесты там, где совершаются одни и те же шаги. Автоматизируйте все, что повторяется и отнимает много времени при ручном тестировании.

• Тесты запускают часто. Перед каждым обновлением сайт тестируют на ошибки. Если релизы происходят регулярно, то ручная проверка — это худшее решение.
• Ошибки, которые незаметны глазу. Ручное тестирование бывает неточным. Люди совершают ошибки — это нормально. При этом автоматическое тестирование исключает их, поскольку оно основано на коде и сценарии.
• Невозможно запускать тесты вручную. Например, стресс-тестирование — яркий тому пример. QA-специалисты используют этот тип тестирования, чтобы проверить, как сайт ведет себя при высокой нагрузке. Часто стресс-тестирование требует создания тысяч запросов в короткие сроки. Инженер по тестированию просто не может воссоздать этот тип поведения вручную.

Это была теория. Теперь разберем кейсы из нашей практики. Вам станет понятнее как это работает и в каких случаях подойдут автотесты.

Кейс № 1. Тестирование добавления филиалов.

Проблема

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

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

Решение

Подготовили несколько тест-кейсов на основе PHPUnit.

1. Проверка работы формы авторизации.
2. Проверка добавления филиала.
3. Проверка добавления пользователя.
4. Проверка переадресации на нужный домен.

Тест-кейсы запускали вручную или автоматически, когда разработчик делал commit — при изменениях на рабочем сервере.

В результате после запуска — 9 из 9 тестов успешно пройдены. Заняло это меньше 5 секунд.

Для проверки функционала тестов умышленно его ломаем. В результате получаем ошибку в консоли — это значит, что тест работает корректно.

Окупаемость инвестиций

Кейс № 2. Тестирование связи района и адреса

Проблема

У одного из наших клиентов периодически возникали расхождения по времени доставки и адресу получателя. Задача усложнялась тем, что время доставки настраивалось по району, а показывалась в зависимости от адреса. В этом нам помогал сервис dadata.ru.

Решение

В классической битрикс-разработке backend и frontend не изолированы. Мы не могли написать отдельные Юнит-тесты на API и Frontend. Поэтому решили написать end-to-end тесты. Они затратны в написании и поддержке, зато подходят для всех видов архитектур

В работе использовали Playwright. Он полностью эмулирует работу браузера. На примере ниже видно, как открывается сразу 3 окна браузера и параллельно проходят тест-кейсы:

1. Открывают главную страницу.
2. Добавляют первый товар в корзину.
3. Заходят в корзину.
4. Пробуют вставить заранее подготовленные адреса.
5. Сравнивает ожидаемую стоимость и время доставки с фактической.

Для наглядности намеренно запустили тесты с визуальным отображением происходящего. Если запускать из терминала, то результат выглядит следующим образом.

Результат — 1 из 3 тестов завершен успешно. Для клиента вынесли данные в отдельный excel-файл.

Дополнительно подключили HTML-отчет, который можно смотреть после каждого запуска.

Окупаемость инвестиций

Рассмотрим окупаемость инвестиций для этого кейса. Всего у нас было 45 тест-кейсов. Ручная проверка занимает порядка 5 минут — это 225 минут ежедневно. За 3 месяца работы — это 227 часов. При ставке 2500 в час бюджет на ручное тестирование сайта составил бы 567 500 рублей.

При этом на написание автотестов у нас ушло 6 часов и 2 часа на их прохождение. В итоге вместо 500 тыс. бюджет проекта составил 20 000 рублей.

Резюме

Главное, что мы хотели сказать:

1. Автотесты и ручное тестирование имеют свои преимущества и недостатки. Они не исключают друг друга, а дополняют.
2. Автотест внедряют при непрерывном тестировании или в случае повторяющихся процессов и задач.
3. Ручное тестирование выгодно на небольших проектах. Либо там, где автотесты не справляются.

Мы в Alto уже 8 лет занимаемся разработкой личных кабинетов, интернет-магазинов, веб-сервисов. Поэтому наш директор, решил, что нужно все полезное об управлении digital-проектами выкладывать в телеграм-канал. Рекомендуем подписаться, если вы связаны с этим.