.png)
До выпуска "в люди" любой программный продукт (сайт, приложение) проходит долгий путь проверок и доработок, пока он на 100% не будет отвечать ожиданиям пользователей. Проверка качества ПО, соответствия заявленных к нему требований и реальной функциональности, поиск и исправление ошибок (багов) и устранение дефектов — эти и другие задачи решает тестирование. Оно нужно как самим разработчикам, чтобы увидеть готовность продукта к рынку, так и заказчикам — убедиться, что бюджет потрачен не зря.
Ручное тестирование (manual testing) — классический метод оценки качества ПО, когда тест-кейсы запускаются без использования средств автоматизации: тестировщики вручную проходят тестовые сценарии и составляют отчеты об ошибках. Этот процесс довольно трудоемкий и продолжительный, без сочетания с автотестами используется только на небольших проектах.
Автоматизированное тестирование выполняется с помощью специальных скриптов, при этом вмешательство человека сводится к минимуму, а точность и скорость проверок гораздо выше.
Чтобы говорить о автоматизации тестирования предметно, рассмотрим примеры ее внедрения в наших проектах: системе управления школой дистанционного обучения (на базе Source LMS), healthcare-проекте и большом онлайн-магазине.
В случае системы управления школой и онлайн-магазина автотесты нужны как проверка устоявшегося критического функционала. Такие сценарии кардинально не изменяются, но требуют постоянной оценки работоспособности, поэтому было принято решение заменить одни и те же ручные проверки на автоматические.
Автоматизация присутствует и на healthcare-проекте, где кроме цели экономии времени требуется мониторинг состояния критических сценариев на сайте в любое время. Также мы разработали и внутреннюю систему нотификации о результатах тестирования.
Критические сценарии и мониторинг были выбраны для автоматизации как наименее динамично меняющиеся и наиболее требующие покрытия задачи на всех проектах. Тесты могут дописываться и меняться, но не требуют постоянной поддержки со стороны какого-либо из отделов.
Критические сценарии — сценарии, ошибки в работе которых принесут клиенту убыток, помешают получить ожидаемую прибыль. Например, для e-commerce проектов это процесс поиска и покупки товара, регистрация и авторизация.
Так, в автоматизации проекта интернет-магазина в основные сценарии входит добавление товара в корзину с разными параметрами, переход в карточку товара и проверка правильности данных в ней, оформление заказа с выбором опций доставки и оплаты. В работе healthcare-портала эти сценарии включают работу с купонами (загрузка, покупка, получение, отображение) для зарегистрированных и незарегистрированных пользователей.
Пример одного из автоматических тестов в системе управления школой: авторизация на сайт, выбор из списка контроля знаний требуемой проверки (набор вопросов с вариантами ответов), полное прохождение контрольного задания и получение результата (оценки в баллах). Его мы рассмотрим ниже.
Покрытие автотестами любых сценариев, вплоть до целого проекта, возможно, но не всегда целесообразно.
Некритические сценарии вызывают минимум простоев, дискомфорта клиентов проекта и не влияют на прямые доходы заказчика. Например, проверка работоспособности вывода статических страниц интернет-магазина: на них присутствует разнообразная информация, но в случае проблем с этими страницами заказчик испытает гораздо меньше сложностей, чем при ошибках в работе заказа товара.
Проверки с помощью автотестов проводятся перед релизами, а также планово по расписанию:
Для всех проектов возможен запуск тестов вручную путем выполнения скрипта из консоли или с использованием интерфейса Gitlab.
Репозитории с автотестами для всех проектов лежат в Gitlab, а в качестве основного стека был выбран Playwright + Jest. У такого варианта есть ряд преимуществ:
Достоинства стека позволяют ощутимо сэкономить время при покрытии большого количества сценариев поведения для каждой из возможных конфигураций устройств клиентов.
На проекте интернет-магазина опробован стек Java + Selenium. Наш отдел тестирования остановился на нем, чтобы расширить используемые технологии в автотестах и создать более сложный по архитектуре фреймворк. Этот стек зарекомендовал себя при написании самых разнообразных тестов и отлично подходит для проверки end-to-end сценариев.
При создании автотестов для healthcare-портала выбор пал на связку Python + Selenium. Это первый проект, на котором появилась автоматизация тестирования в компании, и выбор языка программирования и фреймворка именно такой в силу экспертизы команд разработки, тестирования и DevOps.
Когда принято решение о необходимости автоматизации на проекте и выбран технологический стек, подбираем сценарии для покрытия тестами, создаем тестовую документацию с конкретными шагами и набором данных для каждого сценария, разрабатываем тестовый фреймворк и интегрируем его с участием DevOps-команды.
Сам процесс автоматизации тестирования обычно происходит так:
На нашем healthcare-проекте тесты перезапускаются автоматически, если на одном из шагов произошла ошибка.
При запуске тестов можно выбрать параметр окружения, определяющий, где именно будут происходить автоматические проверки: на тестовой среде или на проде. Примеры выполняющихся шагов: авторизация, добавление в корзину, покупка, оплата тестовыми картами, получение письма, скачивание файла.
После завершения тестирования либо на экран, либо в базу сохраняются результаты прохождения сценария. Если на каком-то шаге возникла ошибка — получаем уведомление об этом, если все прошло успешно — получаем уведомление об успешном прохождении. На проекте healthcare-портала письмо приходит на почту клиента и на почту компании, что особенно полезно при возникновении проблемы на сайте: следующий запуск автотестов с успешным прогоном всех тестов показывает, что проблема решена или больше не повторяется.
1. Автотест запускается вручную или автоматически по расписанию на сервере.
2. Автоматически открывается браузер, выбранный в скрипте для запуска (любой, например, Chromium). При запуске по расписанию с сервера автотест работает в headless-режиме.
3. Скрипт автоматически вводит адрес сайта, попадает на страницу авторизации и переходит в кабинет школьника.
4. Согласно выбранным параметрам скрипт переходит в выбранный тест. Цель — пройти все задания и набрать максимальный балл. Для контроля результаты сверяются с данными из базы, к которой скрипт также подключается автоматически.
5. Скрипт проходит тест без вмешательства человека, проставляя правильные ответы, заранее полученные из базы.
6. Когда урок пройден, на страницу выводится оценка "автостудента". Ожидаемый результат — 12/12 баллов.
7. После окончания теста окно браузера автоматически закрывается, а информация выводится в консоли:
Результаты можно сохранять в базе, передавать по почте, выводить комментарием к задаче.
1. Запускается скрипт автотеста, после чего автоматически откроется браузер.
2. На главной странице сайта автоматически вводятся регистрационные данные для входа в личный кабинет.
3. Из кабинета скрипт переходит в калькулятор и случайным образом выбирает город для подсчета стоимости пакета анализов.
4. Выбор нескольких анализов в корзину, расчет оптимальных тарифов. На экран выводятся подобранные скидки и выбранные предложения.
5. Действия повторяются для других случайно выбранных городов.
Результаты прохождения выводятся на экран или отправляются на почту.
По проекту онлайн-школы время тестирования сократилось в среднем на 20%:
На healthcare-проекте до автоматизации ручное выполнение тестовых сценариев занимало 30-40 минут и было обязательным при каждом цикле тестирования. Автотесты же полностью отрабатывают за 10-12 минут.
При тестировании функционала онлайн-школы часть кейсов все равно нужно выполнять вручную. Однако кейс с автоматизацией покрывает в среднем 15-20% всего тестирования для большинства релизов. В редких случаях (при отсутствии изменений в модулях, не покрытых автотестами) этот показатель может доходить до 60%.
На healthcare-проекте автотесты сократили время на тестирование на 99% — тестировщик привлекается на проект крайне редко, и если привлекается, проверяет результаты выполнения тестов.
Кроме этого автотесты позволяют отслеживать состояние системы, получать нотификации о проблемах для клиента и для нас. Так что со стороны DevOps на поддержку требуется минимальное количество времени — привлекаются только, если тесты падают несколько раз.
Еще один плюс — автоматический перезапуск тестов, если на каком-то шаге произошел сбой. Благодаря этому удается исключить “ложные” падения, когда система работает нормально, но произошел кратковременный сбой, который не повлиял на работу сайта, но помешал автотестам корректно выполниться. Внутренняя система нотификации позволяет всегда знать, что прод рабочий, узнать о проблеме и быстро на нее среагировать.
Подводя итоги, скажем, что автоматизация тестирования — это инвестиция в будущее компании и возможность значительно повысить качество и скорость обновления программного продукта, оптимизировать расходы.
Если вы хотите внедрить автоматизацию на своем проекте, свяжитесь с нами. Подберем наиболее эффективное решение и настроим систему тестирования под ваши специфические требования.
