Автоматизированное тестирование сайта — за и против. С расчетами

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

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

Есть два типа тестирования: ручное и автоматизированное. В первом случае контроль качества производит человек — тестировщик (или QA-инженер) — посредством моделирования действий пользователя. Специальные программы для проверки сайта не применяются.

Во втором случае запуск, инициализация, выполнение, анализ и выдача результата производятся автоматически с помощью специальных инструментов. Тестировщик обрабатывает полученные результаты.

Рассмотрим оба типа подробнее.

В маленьких компаниях тестированием занимаются сами менеджеры проектов. В компаниях побольше — тестировщики (QA-инженеры), которые применяют ручные методы проверки продуктов. Дальнейший рост компании подразумевает рост количества проектов, а значит есть 2 решения: или увеличить штат специалистов, или сделать так, чтобы при том же количестве тестировщиков сохранилось (а лучше — чтобы улучшилось) качество на выходе. Какое решение выбрать — дело за вами. Чтобы вам было проще сориентироваться, мы сравнили оба типа тестирования.

Автоматизация незаменима в регрессионном тестировании, когда происходит повторная проверка функционала после внесенных изменений (исправления ошибок). Если ваша цель — получить на выходе качественный продукт, регрессионное тестирование должно проводиться даже при малейших изменениях в коде.

Несмотря на то, что усилия, которые требуются для внесения небольших изменений, обычно минимальны, повторная проверка функционала включает в себя сравнительно большой объем работ. Выручает автоматизация — она позволяет свести время на регрессионное тестирование к минимуму.

С проблемой больших трудозатрат мы в Uplab столкнулись как раз при регрессионном тестировании. Причем высокие трудозатраты не всегда были равны высокому качеству проведенной работы. При перепроверке функционала специалисту нужно обратить внимание на каждую деталь, однако чаще всего на тот момент у него уже просто «замылен глаз» и он может что-то пропустить. Результат — наличие багов на сайте.

Чтобы исключить человеческий фактор, мы решили внедрить автоматизированное тестирование.

Прежде чем рассказать, как всё работает, дадим несколько определений — они помогут вам сориентироваться в профессиональном мире тестировщика.

Тест-кейс

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

Именно по тест-кейсам пишут автотесты — каждый шаг алгоритма соответствует шагу в тест-кейсе.

Атрибуты тест-кейса:

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

•

Шаги — описание последовательности действий, которые должны привести нас к ожидаемому результату. Каждый шаг отвечает на вопрос «что сделать?» (например, «зайти на страницу „Новости"», «кликнуть на кнопку „Узнать больше"»).

•

Название — основная тема тест-кейса. Краткое описание его сути.

•

•

Фактический результат — то, что происходит, если функционал работает некорректно (ошибка, баг).

Чек-лист

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

Хочу протестировать сайт перед запуском. На что обратить внимание

Баг-лист (баг-репорт)

Документ, описывающий ситуацию или последовательность действий, которые привели к некорректной работе объекта тестирования. В нем указываются причины и ожидаемый результат.

Фреймворк тестирования

Программная платформа или комплекс компонентов и моделей, которые упрощают реализацию продукта. С помощью фреймворков, позволяющих эмулировать поведение реальных пользователей из программной среды, строится автоматизация тестирования.

Фреймворки обычно состоят из двух частей:

API, предоставляющего удобные функции для контролирования этой программы.

•

Программы или надстройки над браузером, которые позволяют управлять браузером.

•

Возможности фреймворков, полезные для тестирования:

Поиск на странице веб-элемента с указанными параметрами.

•

Навигация между веб-страницами.

•

Открытие новой вкладки или окна браузера, изменение размеров.

•

•

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

•

Эмуляция действий пользователя, например, нажатие кнопки мыши на определенный элемент или ввод последовательности символов с клавиатуры.

•

Исполнение на странице команды JavaScript для более сложных действий.

Для автоматизации тестирования подходят разные фреймворки. Самые популярные — Selenium, Watij, HtmlUnit, Jamaleon, Jest.

Мы выбрали Selenium IDE — плагин к браузеру Firefox, который может записывать действия пользователя, воспроизводить их, а также генерировать код для WebDriver или Selenium RC, в котором выполняются те же самые действия.

Допустим, мы хотим проверить форму обратной связи на странице CONTACT US на сайте gazglobal.com. Вот так будет выглядеть тест-кейс:

На основе кейса запишем автотест на Selenium IDE, где, используя перечисленные в таблице шаги, программа пройдет по сайту и запишет результат — есть ошибки в функционале или все работает корректно.

Т.к. тестирование проводится в расширении Firefox, баги тоже фиксируются в этом браузере.

Тестирование формы на базе Selenium IDE

Рассмотрим еще один пример — автотест, который проверяет работоспособность поиска на том же сайте gazglobal.com. На сайте реализовано два функционала поиска: один в шапке, другой в подвале. Проверим первый — в нем есть pop-up с выбором тегов, основанных на самых популярных запросах.

Составим тест-кейс:

А теперь на основе перечисленных шагов запишем автотест:

Тестирование поисковой строки на базе Selenium IDE

Чтобы сделать вывод, целесообразно ли вкладывать средства в автоматизацию тестирования, представим ситуацию. Допустим, есть некая компания X, в которой все специалисты всегда тестировали функционал вручную. То есть автоматизация — это некий эксперимент, который по задумке должен подтвердить гипотезу, что тестирование с помощью программы сократит время на проверку сайта и повысит качество результата на выходе. Срок эксперимента — 3 года.

Чтобы рассчитать эффективность вложений, потребуются следующие данные:

Как часто проводится или планируется проводить регрессионное тестирования.

•

Сколько стоит час специалиста, который на текущий момент занимается ручным тестированием.

•

Сколько стоит час специалиста, который займется процессом автоматизации.

•

•

По скольким тест-кейсам запускается тестирование.

•

Сколько времени требуется на переключение с тестирования одного проекта на другой.

•

Сколько времени уйдет на доработку документации по автоматизации определенного тест-кейса. Важно учитывать возможные проблемы при изучении документации и погружении в особенности каждого проекта.

•

Сколько времени уходит на оформление бага в баг-лист.

•

Сколько времени требуется на разработку одного автотеста.

•

Сколько времени занимает ручное тестирование по 10 кейсам.

Подставим условные значения, чтобы произвести расчет:

Теперь мы можем сравнить затраты на автоматизированное и на ручное тестирование. Обратите внимание: расчеты ниже основаны на первичном приближении и не претендуют на максимальную точность. Мы показываем примерные трудозатраты при описанном алгоритме работы — в вашей компании цифры могут быть другими.

Использовать будем следующую формулу:

Ip = Io + Co + Σ (Ce + Ca + Cm)

Co — стоимость разработки тестов

•

Io — начальные инвестиции

•

Ip — затраты на автоматизацию тестирования

•

•

Σ — планируемое количество циклов тестирования

•

Ce — оценка стоимости однократного выполнения цикла автоматизированного тестирования

•

Ca — оценка стоимости анализа результатов выполненного цикла

•

Cm — оценка стоимости поддержания автоматизированных тестов в рабочем и актуальном состоянии

При расчетах мы не учитываем первоначальные инвестиции — они не нужны, т.к. применяются уже существующие бесплатные технологии (IDE, фреймворки) и отсутствует необходимость инвестировать в дополнительное оборудование.

Расчет

Стоимость разработки автоматизированных тестов:
10 тестов х 2 часа х 600 руб./час = 12 000 руб.

Планируемое количество циклов тестирования:
3 года х 52 недели х 2 часа/день = 312 раз

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

Оценка стоимости анализа багов тестировщиком:
10 тестов x 0,125 часа x 600 руб./час = 750 руб.

Стоимость поддержки автотестов в рабочем состоянии:
10 тестов x 0,3 цикла x 0,5 часа x 600 руб./час = 900 руб.

Подставим данные в формулу:

0 + 12 000 +312 x (0 + 750 + 900) = 526 800 рублей

Следовательно, для автоматизации тестирования в компании X необходимо 526 800 рублей.

Формула:

Gp = Go + Σ (Gc + Ga+ Gm)

Σ — планируемое количество циклов тестирования

•

Go — начальные инвестиции

•

Gp — затраты на ручное тестирование

•

•

Gc — стоимость разработки тест-кейсов

•

Ga — оценка стоимости анализа багов тестировщиком

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

Расчет

Стоимость одного цикла ручного тестирования:
0,75 часа х 10 тестов х 500 руб./час = 3 750 руб.

Стоимость анализа багов тестировщиком:
10 тестов x 0,25 часа x 500 руб./час = 1 250 руб.

Стоимость разработки документации тестировщика с учетом возможных рисков:
10 тестов x 0,5 часа x 500 руб./час = 2 500 руб.

Подставим данные в формулу:

0 + 3 750 + 312 x (0 + 1 250 + 2 500) = 1 173 750 рублей

Сравнив результаты обоих расчетов (526 800 рублей на автоматизированное тестирование и 1 173 750 рублей на ручное), можно сделать вывод, что на данном этапе для компании X целесообразна автоматизация.

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