На связи команда Айтигро. В статье подробно расскажем, что такое автотесты, когда и как их нужно и не нужно использовать, а также на конкретном примере разберем опыт внедрения автотестов в проекте «Наигру».
3143 просмотров
Автотесты в веб-сервисы Наигру: сценарии
Что такое автотесты простым языком?
Если совсем просто, то это когда вместо человека тестирование производит программа. Первые автотесты появились в эпоху бородатых систем DOS. В общем технология не новая и человечество в этом вопросе набило немало шишек.
В интернете встретили хорошую аналогию: представьте что мост — это программа (или в нашем случае веб-сервис). По мосту запускаем полностью нагруженный товарный состав (виртуальный трафик). Когда поезд едет по мосту, на котором установлены датчики, мы получаем информацию о трещинах, деформации балок, разрушении железнодорожного полотна. Это есть end-to-end тестирование (подробнее описано ниже). А вот если добавить, что после каждого изменения моста (добавление балки, изменение геометрии опор и т.д.) поезд запускается автоматически, а датчики, улавливая ошибку, не пропускают его дальше – то это уже автоматическое end-to-end тестирование.
В бизнес-класс без миллиона. Ресурсный тест: BMW 523i или Mercedes E 200 CGI?
Простое тестирование – это когда после изменения конструкции моста мы запускаем поезд вручную и смотрим, оцениваем, выдержит ли мост поезд или нет (и ставим под мост тестировщиков и разработчиков, ха-ха).
С определениями разобрались. Поехали дальше.
Что и как можно автоматически тестировать?
Автоматически можно тестировать программный код или пользовательский интерфейс. В статье мы будем говорить про автотесты через пользовательский интерфейс.
Если говорить совсем точно, статья будет про автоматическое end-to-end (E2E, сквозное) тестирование, имитирующее пользовательскую среду и поэтапно моделирующие действия пользователей.
Автоматическое end-to-end (E2E) тестирование — это процесс автоматического тестирования с подробной эмуляцией действий пользователя: кликаньем мышки, переходами по страницам, заполнения форм и так далее. Цель E2E тестирования — удостовериться, что программа работает именно так, как задумано для конечного пользователя.
E2E тестирования обычно проводится в самом конце перед «выкаткой» изменений или доработок на рабочие версии продуктов. Поэтому ошибки, возникающие при некачественном E2E тестировании, могут быть очень дорогими.
Пример. Мы «выкатываем» приложение с потенциалом 10 000 регистраций в месяц. Предположим, мы не заметили, что после изменения одной из функций пользователи не видят модальное окно об успешной регистрации и это снижает общую конверсию на 5%. Стоимость одной регистрации составляет 15 долларов. За первый месяц мы потеряем 7 500 долларов.
Типы E2E тестирования: черный и белый ящик
Метод черного ящика — метод тестирования, при котором проверяется только интерфейс. Ошибки в логике не отслеживаются.
Метод белого ящика — метод тестирования, при котором проверяется сопоставление работы программы с эталоном.
Сдаю тест в бизнес класс, в Яндекс от начала и до конца.
Авто тесты бизнес класс
Вы знали, что команда Amazon Web Services еще в 2015-м выпускала 50 миллионов релизов в год? Это чаще, чем один в секунду! Как у них так получалось? Свою продуктивность в Amazon объясняют использованием принципов DevOps и эффективной автоматизацией тестирования.
В свою очередь компания QASymphony опрашивала экспертов, среди которых, например, Энджи Джонс, ведущий инженер по тестированию Twitter. И все они согласны с тем, что рынок предъявляет все более жесткие требования к качеству программных продуктов и скорости их обновления. Поэтому одним из трендов эксперты называют сдвиг акцента с ручного тестирования на автоматизированное.
Но в своей оценке эффективности и применимости автоматизированного тестирования эксперты часто разделяются во мнениях где, как и в каких объемах его применять. Почему так происходит? Объясняем в этой статье.
Почему автоматизация не панацея: плюсы и минусы автотестов
Начнем с плюсов:
1. Неутомимость: автотесты работают даже когда вы спите. Роботы запускаются автоматически, дистанционно, по расписанию. Они не отвлекаются, не забывают, и делают проверку столько раз, сколько нужно.
2. Скорость: робот в 99% случаев пройдет тест быстрее ручного тестировщика. В оставшемся 1% случаев не забывайте, что человек может устать, а робот нет.
3. Многофункциональность: это не просто перебор значений в формах. Автотесты могут быстро проверить функционал в разном окружении и при разных настройках тестируемого ПО.
4. Масштаб: автоматизация позволяет имитировать действия большого количества пользователей.
5. Экономия сил: автотесты освобождают ручных тестировщиков от рутины. Часто с помощью автотестов проверяется базовый функционал, а тестировщик сосредотачивается на тестировании новинок.
6. Экономия средств: основная задача автотестов в бизнесе — сокращение затрат на тестирование. И они отлично справляются с этой задачей, если были внедрены с умом и в нужном месте.
Теперь переходим к минусам:
1. Поломки: автотесты ломаются, иногда даже из-за незначительного изменения кода. На актуализацию нужно время.
2. Близорукость : Автотест проверяет только то, на что запрограммирован. Он не заметит ошибку, которую ему не поручали искать.
3. Трудно поддерживать: с ростом количества автотестов, время на их актуализацию и анализ старых, превышает время на разработку новых.
4. Не везде применимы: есть области тестирования, которые не поддаются автоматизации. Это юзабилити, проверка верстки и переводов, инсталляционное тестирование и другие подобные сферы.
5. Затратность: автотест это как промышленное оборудование, в него нужно сначала инвестировать, а потом смотреть на окупаемость. А если “станок” постоянно чинится и перепрошивается — он может и не окупиться.
Есть и спорные моменты
1. Выгода от автоматизации. С одной стороны – почти всегда время на разработку автотеста будет больше, чем время прохождения тестов «руками». Еще и специалист нужен более квалифицированный/высокооплачиваемый. С другой – если автотест не нуждается в реанимации и постоянной актуализации, то он работает практически бесплатно. Поэтому очень важно рассчитывать ROI автоматизации.
И делать это регулярно! Мы в «Лаборатории Качества» рекомендуем проводить анализ окупаемости автоматизации тестирования еще до старта проекта.
2. Сложность анализа результатов. С одной стороны разработчик автотестов действительно может сделать так, что отчеты будут понятны только ему. С другой стороны, если грамотно подойти к стратегии логирования результатов, то даже новый тестировщик сможет понять на каком шаге упал автотест. Специалисты «Лаборатории Качества» всегда составляют четкие инструкции по своим автотестам и по желанию заказчика полностью передают их штатным специалистам.
Когда лучше ручное тестирование, а когда процесс требует автоматизации ?
Ручное тестирование подойдет больше, если у вас:
- молодой проект с нестабильным функционалом;
- ручных тестов мало и они проходят быстро;
- нужно проверять верстку, переводы, юзабилити;
- нужно локализовать и описывать ошибки;
- нет времени на разработку автотестов.
О необходимости автоматизации тестирования говорят такие факторы:
- большое количество ручных тестов и не хватает времени на регулярное проведение полного регресса;
- большой процент пропуска ошибок по вине человеческого фактора;
- большой промежуток времени между внесением ошибки, ее обнаружением и исправлением;
- подготовка к тестированию (настройка конфигурации, генерация тестовых данных) занимает много времени;
- большие команды, в которых нужна уверенность, что новый код не сломает код других разработчиков;
- поддержка старых версий ПО, в которых нужно тестировать новые патчи и сервис-паки.
Как автоматизировать тестирование
Вот наши рекомендации по автоматизации, которые мы сформировали исходя из практики 155+ проектов.
1. Определите, чего вы хотите от автотестов. Кто-то ищет оптимизации расходов, кто-то хочет разгрузить ручных тестировщиков, кто-то хочет увеличить охват тестов. Регулярно проверяйте способствует ли автоматизация достижению вашей цели. Также цель позволяет определить что именно автоматизировать и что делать в первую очередь.
2. Регулярно рассчитывайте ROI автотестов и собирайте соответствующие метрики. Это позволяет узнать действительно ли вам нужны автотесты и при необходимости корректировать план автоматизации.
3. Проанализируйте сколько автотестов вам требуется. И как часто понадобится писать новые и актуализировать старые. Возможно, вам выгоднее сразу отдать автоматизацию на аутсорс и платить только за выполненные работы. В то время как наемный сотрудник будет сидеть без дела после выполнения основного объема работ на старте проекта.
Запросить анализ
4. Определите, что вы хотите видеть в отчетах. От этого зависит их полезность и ваша степень доверия к этому инструменту. Рекомендуем найти баланс между минимумом и максимумом данных, так чтобы автотесты приносили пользу, но не съедали ваши ресурсы. Собранная информация должна приносить пользу. Опытные автоматизаторы на аутсорсе могут посоветовать вам, что должно быть в отчете.
5. Позаботьтесь, чтобы тестировщики понимали что именно делает автотест. Только так после падения сценарий можно перепроверить вручную. Создайте четкие пошаговые инструкции. В случае, если вы отдали эту задачу на аутсорс компании, в которой есть и ручные тестировщики и автоматизаторы, попросите у них такие инструкции – на всякий случай, вдруг придется проверять самим.
6. Не стоит доверять начальный этап автоматизации программисту-джуну. Не забывайте, что автотесты – такой же программный продукт, как и все остальные. От классификации разработчика зависит эффективность, правильно выстроенная архитектура и легкость актуализации.
7. Последняя в списке, но не последняя по значению рекомендация – придерживайтесь пирамиды автоматизированного тестирования. Создавайте большое количество низкоуровневых автотестов (например, API) и меньшее количество высокоуровневых UI тестов. Просто поверьте нашему опыту, или напишите нам в комментариях, чтобы мы написали отдельную статью по этой теме. Поверьте, для этого хватит материала, с красочными примерами.
Выводы
Многим QA-специалистам очевидно, что вопрос «автоматизировать или тестировать руками?» звучит, как минимум, некорректно. Нельзя раз и навсегда выбрать что-то одно, а от чего-то отказаться.
Все тесты автоматизировать нерентабельно, а порой и вовсе невозможно. Пока AIOps не достигли нужного уровня, ручное тестирование будет востребовано на проектах. Потому, квалификация руководителя проекта тут определяется скорее умением найти точный баланс между этими двумя подходами. Определить, где автотесты будут максимально эффективны и внедрять их именно в этой сфере.
Что касается вопроса отдавать ли автоматизацию на аутсорс или заниматься самому, то все нужно просчитывать применительно к своему бизнесу. Для того, чтобы делать автотесты самостоятельно, должно сойтись много факторов.
- Как минимум, вы должны быть уверены, что автоматизация окупится и уметь правильно считать ROI.
- Плюс найти квалифицированного автоматизатора, что трудно с учётом их востребованности на рынке труда.
- А ещё вы должны загрузить его работой не только на старте проекта, но и на постоянной основе.
- Ну и убедиться, что автотесты будут работать без этого специалиста. Иначе — начинай всё сначала.
Сильные QA-компании, предлагая свои услуги — всегда инициируют процесс автоматизации с просчета его ROI и выбора наиболее прибыльной стратегии тестирования.
Сама автоматизация должна строиться на имеющихся у QA-компании наработках и готовых библиотеках фреймворков, что экономит время и средства заказчика.
В конце проекта заказчику должны быть переданы гибкие автотесты, которые легко актуализировать и поддерживать своими силами.
Не удалось до конца определиться — внедрять автоматизацию у себя на проекте или продолжать кормить армию ручников. Свяжитесь с нами. Посчитаем все за и против вместе.
Узнать подробнее
Словарь тестировщика: автотесты, юнит-тесты и другие важные слова
В прошлой статье про тестирование калькулятора мы занимались ручным тестированием. Это эквивалент любого другого ручного труда: может быть эффективно, но плохо масштабируется, и вообще это не инженерный подход.
А вот — инженерный. В этой статье разберём на базовом уровне основные подходы к инженерному тестированию.
Что такое автотесты
Автотесты — это тесты, которые выполняет компьютер, а не человек. Внутри автотест это тоже программа, цель которой — протестировать, как работает другая программа.
Автотест делается и работает так:
- Программист берёт часть программы, которую он тестирует, и прикидывает, какие данные она должна вернуть, если в неё попадут другие данные.
- Затем программист собирает нужные ему для тестов комбинации данных на вход и на выход, которые должны быть в идеальной ситуации.
- После этого он добавляет в тест специально неправильные данные и ожидаемый ответ в этом случае.
- Когда все проверочные данные готовы, он оборачивает их в код и пишет тест — программу-тестировщика, которая обращается к программе-жертве и смотрит, как та отреагирует на разные данные.
После этого тестировщики смотрят на тестовые и реальные результаты и делают вывод, правильно работает эта часть программы или нет.
Автотесты делятся по масштабам тестирования на юнит-тесты, сервисные тесты и интеграционные тесты.
Юнит-тесты
Юниты — это отдельные модули или части программы, каждый из которых отвечает за что-то своё.
Юнит-тесты проверяют работу отдельных юнитов: берут модуль и прогоняют его по всем своим тестам. Чем меньше и проще модуль, тем проще сделать юнит-тест и прогнать его по модулю. Модулем может быть что угодно — функция, метод класса, часть API и так далее.
Юнит-тесты — самые простые в обслуживании и написании. Работают быстро, проверяют модуль вдоль и поперёк, но есть нюанс: если в программе больше одного модуля, то просто протестировать их по одному недостаточно — они могут работать классно поодиночке, но вместе работать плохо. Чтобы проверить работу нескольких модулей вместе, делают сервисные тесты.
Сервисные тесты
Задача сервисного теста — протестировать работу нескольких модулей вместе: как они запускаются, передают друг другу данные и правильно ли решают свою общую задачу как одно целое.
Это уже сложнее, чем юнит-тесты, зато помогает понять, как модули работают вместе. Правда, не все используют сервисные тесты, а переходят сразу к интеграционным, но знать про них тоже полезно.
Интеграционные тесты
Эти тесты проверяют, как работают все модули сразу или даже как работает вся программа.
Интеграционные тесты — самые сложные, потому что если меняется что-то хотя бы в одном модуле, то, скорее всего, нужно будет переделать весь интеграционный тест. Это дорого и занимает много времени, поэтому в компаниях стараются делать так:
- писать побольше юнит-тестов, прям чтобы было много;
- сервисных тестов писать поменьше;
- а интеграционных — ещё меньше, в идеале один или два, и всё.
Минусы автотестов
Если бы всё можно сделать автотестами, которые не пропускают ни одной ошибки в программе, то в разработке ПО наступил бы идеальный мир. Но у автотестов тоже есть минусы.
Стоимость разработки. Так как автотест — это тоже программа, на её разработку тоже нужны время и деньги. Чем сложнее автотест, тем больше ресурсов на него нужно. Иногда проще разбить один большой тест на много тестов поменьше, чем разрабатывать огромную универсальную тест-машину.
Поддержка. Там, где разработка, там и поддержка ПО. Автотесты тоже нужно поддерживать в актуальном состоянии: следить за правильностью тестируемых параметров, текущими названиями классов и методов и версиями тестируемого софта.
Выбор тестов. Чтобы написать хороший автотест, нужно перед этим определиться, а что именно он будет тестировать. Иногда на это уходит столько же времени, сколько и на пару юнит-тестов, а иногда и больше. Если ошибиться на этом этапе, тест может сработать вхолостую и пользы для проекта не будет.
Вот пример: если бы мы автотестировали калькулятор, то мы бы могли сделать тесты с числами 1, 2, 3, 4, 5 … 9999. В нашей голове это максимальное значение, которое людям нужно в обычной жизни. Мы даже не подумаем, что кому-то в нашем калькуляторе понадобится число длиной 17 знаков. А ведь именно на таком числе наш калькулятор и сломался.
Умение программировать. Сейчас появляются инструменты, которые упрощают задачу тестировщика, но без знания алгоритмов пока ещё никуда. Чем лучше инженер по тестированию умеет программировать и строить в голове нужные алгоритмы для проверки, тем круче у него всё получается. Про это как раз в следующем разделе.
Где этому научиться
Можно прочитать нашу подборку книг для новичков — там книги идут по возрастанию сложности, и лучше читать их по порядку. А можно прийти в Практикум и полностью освоить профессию тестировщика за несколько месяцев. По времени будет столько же, а пользы в сто раз больше.
Источник: thecode.media
