Как автотесты увеличивают деньги от разработки, повышают качество продукта и сокращают расходы
Привет, на связи Alto! Тестирование сайта занимает 30% от всего времени разработки сайта. При этом мало кто понимает, как можно оптимизировать этот процесс. В этой статье разбираем теорию и практику. Рассказываем, в чем разница и как выбрать между автоматическим и ручным тестированием. Показываем, как выглядят автотесты изнутри.
Что это такое и в чем разница?
Пред релизом менеджер проекта передает сайт тестировщику — QA-специалисту. Его задача — проверить, что сайт работает в соответствии с требованиями клиента. То есть тестировщик выявляет скрытые ошибки в функционале и дизайне сайта.
Для этого у QA-специалиста есть два метода:
- ручное тестирование сайта,
- автоматическое тестирование сайта.
При первом подходе тестировщик вручную формирует и проверяет сценарии поведения пользователя. Дополнительные инструменты не используются.
При втором подходе тестировщик автоматизирует проверку сценариев. На входе он подготавливает данные, а затем при помощи инструментов проверяет заготовленные сценарии. Например, в нашей практике мы используем: PHPUnit, Jest для javascript и Playwright для End-2-End тестов.
Автотесты и ручное тестирование имеют свои преимущества и недостатки. В одних ситуациях автоматическое тестирование экономит время и деньги. В других — ручное тестирование оказывается быстрее и дешевле. Поэтому ниже разберем, когда стоит использовать тот или иной подход.
Когда использовать ручное тестирование сайта?
- Тесты запускают редко. Автотесты отнимают много времени на подготовительном этапе. Поэтому ручное тестирование выгоднее там, где не нужны частые и быстрые проверки. Например, если у вас корпоративный сайт на готовом решении от Битрикс.
- Для поиска визуальных или UX ошибок. Такую расплывчатую задачу компьютер решить не может. При автотесте нужны четкие формулировки. Поэтому только ручное тестирование подходит для проверки удобства использования сайта и визуальных ошибок.
- Ошибку нельзя обнаружить при помощи автотестов. К тестированию можно подходить творчески. Например, QA-специалист придумывает необычные поведенческие сценарии — это помогает раскрыть критические ошибки, которые нельзя обнаружить при автоматизированном тестировании.
Когда использовать автоматическое тестирование сайта?
- Для регулярного мониторинга ошибок. Например, когда на сайте каждый час оставляют десятки заказов. А значит, вы должны быть уверены, что форма заказа работает постоянно.
- Повторяющиеся задачи. Внедряйте автотесты там, где совершаются одни и те же шаги. Автоматизируйте все, что повторяется и отнимает много времени при ручном тестировании.
- Тесты запускают часто. Перед каждым обновлением сайт тестируют на ошибки. Если релизы происходят регулярно, то ручная проверка — это худшее решение.
- Ошибки, которые незаметны глазу. Ручное тестирование бывает неточным. Люди совершают ошибки — это нормально. При этом автоматическое тестирование исключает их, поскольку оно основано на коде и сценарии.
- Невозможно запускать тесты вручную. Например, стресс-тестирование — яркий тому пример. QA-специалисты используют этот тип тестирования, чтобы проверить, как сайт ведет себя при высокой нагрузке. Часто стресс-тестирование требует создания тысяч запросов в короткие сроки. Инженер по тестированию просто не может воссоздать этот тип поведения вручную.
Это была теория. Теперь разберем кейсы из нашей практики. Вам станет понятнее как это работает и в каких случаях подойдут автотесты.
Кейс №1. Тестирование добавления филиалов.
Проблема
На одном из сайтов разрабатывали функционал, который позволял создавать свои филиалы для каждого дилера. То есть при авторизации каждый пользователь попадал к закрепленному за ним дилеру. А если пользователь не привязан, его перенаправляло на основной филиал.
Оказалось, что данное решение чувствительно к изменениям в других частях сайта. Ошибки в функционале приводили к блокировке большей части сайта. Поэтому приходилось проходить тест-кейсы после каждого релиза. При этом релизы были каждый день.
Решение
Подготовили несколько тест-кейсов на основе PHPUnit.
- Проверка работы формы авторизации.
- Проверка добавления филиала.
- Проверка добавления пользователя.
- Проверка переадресации на нужный домен.
Тест-кейсы запускали вручную или автоматически, когда разработчик делал commit — при изменениях на рабочем сервере.
В результате после запуска — 9 из 9 тестов успешно пройдены. Заняло это меньше 5 секунд.
Для проверки функционала тестов умышленно его ломаем. В результате получаем ошибку в консоли — это значит, что тест работает корректно.
Окупаемость инвестиций
Теперь давайте проанализируем окупаемость инвестиций при различных сценариях — между автотестом и ручным тестированием. Рассчитывать будем из ставки 2500 рублей в час.
Кейс №2. Тестирование связи района и адреса
Проблема
У одного из наших клиентов периодически возникали расхождения по времени доставки и адресу получателя. Задача усложнялась тем, что время доставки настраивалось по району, а показывалась в зависимости от адреса. В этом нам помогал сервис dadata.ru.
Решение
В классической битрикс-разработке backend и frontend не изолированы. Мы не могли написать отдельные Юнит-тесты на API и Frontend. Поэтому решили написать end-to-end тесты. Они затратны в написании и поддержке, зато подходят для всех видов архитектур
В работе использовали Playwright. Он полностью эмулирует работу браузера. На примере ниже видно, как открывается сразу 3 окна браузера и параллельно проходят тест-кейсы:
- Открывают главную страницу.
- Добавляют первый товар в корзину.
- Заходят в корзину.
- Пробуют вставить заранее подготовленные адреса.
- Сравнивает ожидаемую стоимость и время доставки с фактической.
Для наглядности намеренно запустили тесты с визуальным отображением происходящего. Если запускать из терминала, то результат выглядит следующим образом.
Результат — 1 из 3 тестов завершен успешно. Для клиента вынесли данные в отдельный excel-файл.
Дополнительно подключили HTML-отчет, который можно смотреть после каждого запуска.
Окупаемость инвестиций
Рассмотрим окупаемость инвестиций для этого кейса. Всего у нас было 45 тест-кейсов. Ручная проверка занимает порядка 5 минут — это 225 минут ежедневно. За 3 месяца работы — это 227 часов. При ставке 2500 в час бюджет на ручное тестирование сайта составил бы 567 500 рублей.
При этом на написание автотестов у нас ушло 6 часов и 2 часа на их прохождение. В итоге вместо 500 тыс. бюджет проекта составил 20 000 рублей.
Резюме
Главное, что мы хотели сказать:
- Автотесты и ручное тестирование имеют свои преимущества и недостатки. Они не исключают друг друга, а дополняют.
- Автотест внедряют при непрерывном тестировании или в случае повторяющихся процессов и задач.
- Ручное тестирование выгодно на небольших проектах. Либо там, где автотесты не справляются.
Мы в Alto уже 8 лет занимаемся разработкой и делимся своим опытом. Наш директор, решил, что нужно все полезное об управлении digital-проектами выкладывать в телеграм-канал. Рекомендуем подписаться, если вы связаны с этим.
Раз вы дошли до понимания нужности автотестов, может и с битрикса пора слезать?
это другое, понимать надо.
Битрикс по своему прекрасен. И решает набор определенных задач. Да, есть минусы. Но это не значит, что заказчикам в некоторых случаях, не нужны автотесты
Зачем тестировать? Может быть надо делать сразу нормально?
А как узнать, что сделал нормально?)
Как это вы из автоматического тестирования исключили человеческий фактор? :)
То что криво написали?)