автотесты что это такое
Автотесты – барское дело
Зачем разработчикам писать автотесты? С таким же успехом их можно заставить класть плитку или вести бухгалтерию. Не барское это дело! Или, все-таки, барское?
Примечание: в статье под автотестами имеются ввиду не unit-тесты, а автоматизированные функциональные тесты, выполняющиеся на полностью развернутом продукте в окружении, максимально приближенном к боевому.
В разработке программного обеспечения существует много мифов и глупостей. Рассмотрим два из них.
Так уж сложилось, что тестировщики в индустрии в среднем зарабатывают меньше, чем разработчики. Происходит это, видимо, из-за того, что бытует мнение, что на роль тестировщиков можно нанять студентов по три рубля пучок, показать им куда надо «тыкать» — и все, команда обезьяно-тестеров готова. Это ерунда, конечно. Хороший тестировщик является по сути опытным хакером-педантом с не дюжим интеллектом и должен стоить дорого, но это почему-то мало кто понимает.
Вторая глупость – это отношение к автотестам. Считается, что разработка автотестов – это тупая нудная работа, которую можно и нужно поручать кому угодно, кто согласится её выполнять, так как пользователю и заказчику на автотесты вообще плевать, ему продукт нужен.
Вторая причина вытекает из того, что команда тестирования не владеет продуктовым кодом. Кодом владеют разработчики и только они могут вносить в него исправления.
Из практики применения юнит-тестов известно, что их разработка наиболее эффективна тогда, когда занимается ей автор тестируемого кода. В этом случае код, как правило, получается более пригодным для тестирования и в результате тесты выходят проще и надежнее.
Точно такая же ситуация имеет место быть и при разработке функциональных автотестов. Когда продуктовый код пишут разработчики, а тесты для этого кода тестировщики, то трудоемкость и качество (поддерживаемость, скорость выполнения, хрупкость и пр.) таких тестов получается хуже, чем если бы и то и другое разрабатывала одна команда. Это происходит из-за того, что разработчик имеет возможность слегка подправить код так, чтобы ему самому было удобнее для этого кода написать автотест. Теоретически, инженер из команды тестирования тоже может попросить команду продуктовых разработчиков модифицировать код. Но на практике, это происходит не всегда, так как часто тестировщику проще оставить в тесте костыль (например, sleep), чем обращаться с просьбой к команде разработчиков, которые в данный момент заняты чем-то важным, ждать пока они реализуют то, что ему нужно, потом получить не то, что он просил и так по кругу. В результате, со временем тесты обрастают костылями, становятся неподдерживаемыми и превращаются в тот самый чемодан без ручки, который и выбросить жалко и тащить тяжело.
Таким образом, самые надежные и легко поддерживаемые тесты получаются, когда их делает команда продуктовых разработчиков. Но данный вариант также не лишен недостатков. Эти недостатки хорошо известны и благодаря им вообще существуют тестировщики. Все в конечном итоге сводится к тому, что тестировщики лучше находят ошибки.
Поэтому оптимальным является некоторый промежуточный вариант, когда автотесты пишутся и разработчиками и тестировщиками. При таком комбинированном подходе удается объединить сильный стороны тех и других. Разработчики закладывают грамотную архитектуру автотестов, адаптируют продукт и обеспечивают покрытие тестами продуктового кода. Тестировщики, со своей стороны, обеспечивают покрытие тест-кейзов, используя в качестве базы автотесты разработчиков.
Разработка автотестов является у нас неотъемлемой частью общего процесса разработки продукта. При планировании итерации для каждой пользовательской истории мы обязательно закладываем время на подготовку автотестов для неё. Трудоемкость автотестов обычно составляет 10-20% от трудоемкости истории, но потраченное время потом многократно окупается.
При внедрении такого подхода к разработке автотестов могут быть проблемы с мотивацией разработчиков, но преодолеть эти проблемы не сложно. Надо сделать так, чтобы прогон автотестов (по крайней мере, части из них) стал внутренним делом команды программистов. Это означает, что тестировщики получают в тестирование только те сборки, на которых полностью прошли автотесты. При этом, на сломанный функционал, который был обнаружен автотестами, не заводятся баги, так как тестировщики про этот позор ничего не знают. Если программист чекинит код, который ломает автотесты, то он либо сразу откатывает чекин, либо быстро его чинит, если там какая-то мелочь.
Потом остается только контролировать и поддерживать регулярные занятия автотестами, чтобы опять не завалиться на диван и не заплыть жиром.
Словарь тестировщика: автотесты, юнит-тесты и другие важные слова
Основные подходы и понятия инженеров по тестированию
В прошлой статье про тестирование калькулятора мы занимались ручным тестированием. Это эквивалент любого другого ручного труда: может быть эффективно, но плохо масштабируется, и вообще это не инженерный подход.
А вот — инженерный. В этой статье разберём на базовом уровне основные подходы к инженерному тестированию.
Что такое автотесты
Автотесты — это тесты, которые выполняет компьютер, а не человек. Внутри автотест это тоже программа, цель которой — протестировать, как работает другая программа.
Автотест делается и работает так:
После этого тестировщики смотрят на тестовые и реальные результаты и делают вывод, правильно работает эта часть программы или нет.
Автотесты делятся по масштабам тестирования на юнит-тесты, сервисные тесты и интеграционные тесты.
Юнит-тесты
Юниты — это отдельные модули или части программы, каждый из которых отвечает за что-то своё.
Юнит-тесты проверяют работу отдельных юнитов: берут модуль и прогоняют его по всем своим тестам. Чем меньше и проще модуль, тем проще сделать юнит-тест и прогнать его по модулю. Модулем может быть что угодно — функция, метод класса, часть API и так далее.
Юнит-тесты — самые простые в обслуживании и написании. Работают быстро, проверяют модуль вдоль и поперёк, но есть нюанс: если в программе больше одного модуля, то просто протестировать их по одному недостаточно — они могут работать классно поодиночке, но вместе работать плохо. Чтобы проверить работу нескольких модулей вместе, делают сервисные тесты.
Сервисные тесты
Задача сервисного теста — протестировать работу нескольких модулей вместе: как они запускаются, передают друг другу данные и правильно ли решают свою общую задачу как одно целое.
Это уже сложнее, чем юнит-тесты, зато помогает понять, как модули работают вместе. Правда, не все используют сервисные тесты, а переходят сразу к интеграционным, но знать про них тоже полезно.
Интеграционные тесты
Эти тесты проверяют, как работают все модули сразу или даже как работает вся программа.
Интеграционные тесты — самые сложные, потому что если меняется что-то хотя бы в одном модуле, то, скорее всего, нужно будет переделать весь интеграционный тест. Это дорого и занимает много времени, поэтому в компаниях стараются делать так:
Минусы автотестов
Если бы всё можно сделать автотестами, которые не пропускают ни одной ошибки в программе, то в разработке ПО наступил бы идеальный мир. Но у автотестов тоже есть минусы.
Стоимость разработки. Так как автотест — это тоже программа, на её разработку тоже нужны время и деньги. Чем сложнее автотест, тем больше ресурсов на него нужно. Иногда проще разбить один большой тест на много тестов поменьше, чем разрабатывать огромную универсальную тест-машину.
Поддержка. Там, где разработка, там и поддержка ПО. Автотесты тоже нужно поддерживать в актуальном состоянии: следить за правильностью тестируемых параметров, текущими названиями классов и методов и версиями тестируемого софта.
Выбор тестов. Чтобы написать хороший автотест, нужно перед этим определиться, а что именно он будет тестировать. Иногда на это уходит столько же времени, сколько и на пару юнит-тестов, а иногда и больше. Если ошибиться на этом этапе, тест может сработать вхолостую и пользы для проекта не будет.
Вот пример: если бы мы автотестировали калькулятор, то мы бы могли сделать тесты с числами 1, 2, 3, 4, 5 … 9999. В нашей голове это максимальное значение, которое людям нужно в обычной жизни. Мы даже не подумаем, что кому-то в нашем калькуляторе понадобится число длиной 17 знаков. А ведь именно на таком числе наш калькулятор и сломался.
Умение программировать. Сейчас появляются инструменты, которые упрощают задачу тестировщика, но без знания алгоритмов пока ещё никуда. Чем лучше инженер по тестированию умеет программировать и строить в голове нужные алгоритмы для проверки, тем круче у него всё получается. Про это как раз в следующем разделе.
Где этому научиться
Можно прочитать нашу подборку книг для новичков — там книги идут по возрастанию сложности, и лучше читать их по порядку. А можно прийти в Практикум и полностью освоить профессию тестировщика за несколько месяцев. По времени будет столько же, а пользы в сто раз больше.
Как мы применяем автотестирование в проектах с быстроменяющимся кодом
Не спорим, за автоматизацией будущее. Но пока мы живем в настоящем, не все так однозначно. Вместе разбираемся, в чем автотесты уступают ручному тестированию и как лучше использовать автоматизацию, чтобы не потонуть в оверхеде.
В Меркури мы много времени работаем со стартапами, где функции постоянно меняются, а код переписывается от спринта к спринту. Если написали автотест, а потом команда решила внести изменения в программу, то он может быстро стать неактуальным. Поэтому, вместо ожидаемой экономии сил и средств, мы тратим время на постоянную починку тестов.
Подобный опыт наша команда пережила с собственным продуктом. Изначально думали так: большой проект, вручную тестировать долго, нужна автоматизация. Но по факту команда QA не успевала переписывать автотесты под новый функционал — продукт менялся с каждым спринтом, то есть буквально раз в две недели.
У нас была ситуация, когда переписывали приложение с Xamarin на натив, а часть нативного кода перенесли на React Native. Команда потратила много часов, чтобы переписать все под новый интерфейс.
В итоге от UI-тестов отказались: времени на поддержку уходит непозволительно много, они не успевают развиваться вместе с остальным проектом, часто пропускают критичные баги и падают из-за несовершенства технологий.
Исходя из нашего опыта определили пять типов автоматизации, которые мы используем в работе с быстроразвивающимися проектами.
Тестируем общение клиента и сервера. Обычно протокол стабилен, а изменения во фронтенде и бэкенде не затрагивают клиент-серверное взаимодействие. Эмулируем запросы от клиента, в редких случаях — ответы от сервера.
Для клиентских запросов чаще всего используем Postman, а также различные самописные решения на основе проверенных библиотек и фреймворков. Это могут быть Python в связке с Requests или Ruby с REST Client.
Для эмуляции ответов сервера обычно применяем спуферы, например: Fiddler, Burp Suite, Charles Proxy. Настроили API-тесты, чтобы они автоматически запускались несколько раз в день и проверяли, насколько корректно работает прод.
Вместе с новым билдом получаем высокие риски возможных ошибок. В этом случае, с помощью автоматического смок-тестирования быстро обнаруживаем и устраняем баги на раннем этапе и не тратим драгоценное время на заведомо нестабильный софт.
Ставим эксперимент и пробуем автоматизировать нагрузочные тесты. Пока что рано делать выводы, но в перспективе это должно помочь разработчикам определять падение производительности еще на этапе написания кода, а также помочь тестировщикам сократить время на регрессионное нагрузочное тестирование.
Даже в постоянно меняющихся проектах рано или поздно часть функциональности приложения становится относительно стабильной. Применяем автотесты, когда такие куски появляются в проекте, и это действительно экономит нам время.
Разработчики просматривают кейсы на выполнение функций приложения и тестируют методы внутри самого кода. Это самый правильный подход, однако здесь возникает соблазн продолжить писать функциональный код, вместо того, чтобы каждый раз писать к коду тест. Редко когда получается выделить достаточное количество часов разработки на юнит-тесты, поэтому мы не так часто их используем.
В остальных случаях чаще всего тестируем вручную. QA продумывают кейс, тестируют и мы сразу получаем результат.
Как правило, автоматизация тестирования в стартапе работает так:
Если проект меняется быстро, то тесты устаревают еще быстрее. Усилия, которые команда тратит на их поддержку зачастую себя не оправдывают. Этот процесс отнимает много бесценного времени, поэтому мы каждый раз спрашиваем себя: а не проще ли провести ручное тестирование?
Без автотестов не обойтись в энтерпрайзе — сложном продукте, где много повторяющихся действий и невозможно искать баги вручную. В таких компаниях на автоматизацию процесса закладывается дополнительное время, функционал продукта более стабилен, и тесты не переписываются раз в две недели.
В нашем случае все меняется от проекта к проекту, поэтому принимая решение о целесообразности автоматизации приложения задаемся вопросом: «Перевешивают ли преимущества автоматизации ее недостатки?» — хотя бы для некоторой функциональности приложения. Если в проекте есть такие части — автоматизируем.
На самом деле, область автоматизации в тестировании еще только развивается, а современные инструменты ограничены:
Однако, как и писали в самом начале: будущее за автоматизацией. Уже сейчас QA без серьезных скиллов в автотестировании готовят тестовые сценарии, а автоматизаторы и разработчики работают над созданием ядра для автотестов.
Индустрия развивается, и уже лет через пять большая часть ручного поверхностного UI-тестирования перейдет в простые «human-readable» сценарии. Верим, надеемся, ждем.
Вопрос применения автотестов в любом проекте — это единство грамотно выбранной стратегии тестирования, комплексного анализа и гибкого подхода. В Меркури мы работали над многими проектами, но универсального «правила» так и не нашли.
Зато определили для себя сценарии, когда автоматизация даже в быстроменяющемся продукте наиболее часто окупает себя:
В этой статье мы делились своим опытом и постарались сами для себя ответить на один из самых сложных вопросов тестирования. И пускай мы не пришли к однозначному ответу, эти выводы помогают команде осознанно подходить к процессу автоматизации в развивающихся продуктах.
Автоматизация тестирования с нуля. Часть 1
Добрый день, уважаемые читатели.
Хочу рассказать об опыте построения системы автоматизации тестирования, когда на проекте или совсем нет тестирования, или ее степень минимальная.
Надеюсь статьи будет полезна начинающим автотестерам.
Когда делать автотесты?
Краткий ответ — как можно раньше.
А полный будет раскрыть ниже. В любом случае, когда проект работает 3 года, и все проверялось вручную, жить становится очень монотонно. И парк из 5000 сценариев автоматизировать за месяц-два проблематично. Как правило в таких проектах придется начинать прорабатывать сценарии заново. Потому что это окажется быстрее. И не факт, что старые получится автоматизировать без существенных изменений.
Почему?
Потому что автотетсы:
Накопленные сценарии
Чем больше парк автоматизированных сценариев, там больше вероятность найти регрессию, особенно если при каждом запуске данные изменяются.
Если автотест проходил стабильно и на какой-то ветке упал, то или меняли требования, или баг, или инфраструктура подвела.
Непредвзятость
Если меняли требования — автотест должен отправиться на переделку вместе с переделкой основного функционала. Именно поэтому тестировщики принимают участи в согласовании ТЗ.
Если прогон теста автоматически линкуется к задаче, то никто не сможет сказать, что это не тестировалось. Или наоборот, сможет. В общем проблем точно становится меньше.
Скорость
Если каждый тест удовлетворяет занудным условиям:
Предусловие — Тест — Постусловие
То такие тесты легко автоматизировать.
А потом легко распараллелить. Потому что они получаются независимыми.
Количество потоков — сколько выдержат тестовые сервера и чтобы не мешать другим.
Второй момент это сама по себе скорость. В ручном режиме прокликать создание товара, его поиск и покупку в интернет магазине это 5 минут. 4 браузера. Итого 20 минут. На всего лишь одном небольшом сценарии.
Автотест по этому сценарию проходит за 1,5 минуты. Но на 8 браузерах. (Последняя и предпоследняя версии каждого браузера).
С чего начать?
С пользовательских сценариев.
Ценность атомарных тестов все время падает, особенно на микросервисах. И вообще, в идеальном мире это зона ответственности программиста. Такие ошибки должны быть обнаружены на этапе юнит-тестирования.
QA должен работать от user story. Потому что программист обычно и не знает ее, и не хочет знать.
Соответственно логика 1 тест — 1 пользовательский кейс (бизнес сценарий) наиболее приближена к реальности.
Есть конечно сложности с подготовкой данных, например в случае интернет-магазина процесс оплаты картой требует наличия вещей в корзине, и или данных для нового пользователя, или данных авторизации существующего.
Да, иногда предусловия занимают больше времени, чем тест, но при переиспользовании сценариев сложности не несет.
Какие сценарии автоматизировать
Наименее подверженные изменениям в ближайшей перспективе. Чтобы автоматизация хоть сколько-то прожила.
Или наиболее часто используемые. Есть смысл помогать ручному тестированию в генерации тестовых данных. Например в доске объявлений есть смысл автоматизировать создание объявлений, т.к. далее любой сценарий требует созданного объявления.
Что конкретно делать?
Обычно в проектах есть
Поэтому предлагаю заняться Бэкэндом и Фронтом.
Выбираем сценарий
Допустим, у нас есть интернет-магазин.
Есть админка, есть клиентский и админский фронт.
Есть API, которое все это обслуживает.
С чего начать автоматизацию?
Есть клиенты, есть сотрудники.
У клиента первый кейс — просмотр и поиск товара, добавление его в корзину, и оформление.
У сотрудника самый распространенный кейс — добавление карточки товара.
Какой кейс автоматизируем первым? И как?
Самое важное для магазина — продажи.
Поэтому клиентская история наиболее важна для бизнеса. Поэтому найти товар, поместить в корзину и завершить оформление с любым способом оплаты это первое, что нужно сделать.
По API. Но без фронта. Тут можно поспорить, но скорее всего дизайн поменяется 2-3 раза еще, а вот бэкэнд вряд ли. Так что на 1 этапе придется интерфейс проверять вручную.
Далее сделать проверки на API редактирования карточки товара и ее фронт.
И вернуться к клиентскому. На этом этапе уже будет статистика наиболее частых действий пользователей, и наиболее частых путей клиента. Да, Яндекс Метрика и Вебвизор помогают и тестировщикам.
Нет никакого смысла на первом этапе проверять, работает ли функция оплаты на счет фирмы через сгенерированную платежку, если этой функцией пользуется 0,5% посетителей. Конечно можно задать менеджеру вопрос зачем это тут нужно, но тут не об этом.
Допустим у нас 40% человек платят на сайте картой, 30% наличкой, 20% наложенным платежом и 10% все остальные способы.
Какой тип оплаты будем проверять первым? Конечно картой.
То есть мы должны четко представлять, какой сценарий самый важный для бизнеса в данный момент. И его качество обеспечивать в первую очередь.
Постусловия
Мы насоздавали всего-всего в тестах. Намусорили. Надо бы за собой убрать. Нужно заранее предусмотреть, в каких тестах мы будем за собой убирать, а в каких — нет.
Если товар можно оставить в магазине, и ничего страшного не произойдет, то добавление прав администратора обычному пользователю нужно вернуть. А то следующий тест, связанный с правами может упасть. Или хуже — пройти позитивно, хотя должен был упасть.
Странности
Есть странный подход, когда автоматизируют сценарии, в которых пользователи находили баг. Обычно это очень экзотические сценарии, и тратить ресурс на них нет смысла. Была ситуация когда сломался функционал обновления данных банка-контрагента. Сбоила синхронизация со справочником БИК.
То есть новый БИК не обновлялся. Но новый банк заводился нормально.
Есть ли смысл автоматизировать этот сценарий? Если контрагенты меняются каждый день — может быть. И тогда это была недоработка планирования.
Если это делается 5-6 раз в год, то может лучше более приоритетной задачей заняться?
Что будет дальше?
В следующей статье я расскажу как быстро начать тестировать API, встроить эти тесты в релизы, распараллелить тесты, как подбирать данные для тестов и что нам это даст.
Напомню про эффект пестицида, и как его свети к минимуму.
Технологии: Java + maven + testng + allure + RestAssured + Pict.
Когда нужны тесты и автотесты, взгляд из надсистемы
Нужно ли автотестирование? Когда оно нужно? Какую ценность оно приносит?
В статье разобраны когда и зачем нужно тестирование как таковое и в каких случаях нужна его автоматизация.
В ходе дискуссии по этому вопросу, проводимой в клубе им. Френсиса Бекона (“ВебПосиделки КиФБ” в teleram), коллеги обменялись опытом и записали свои мысли.
Автоматизация тестирования нужна, если это приносит ценность. Когда же само тестирование приносит ценность? Выявлено два случая.
Если процесс отлавливает ошибки в ПО перед выкладкой на бой
Если тестирование новой версии выявило ошибки, которые были в последующем исправлены, то это тестирование было проведено не зря.
Но что если ситуация обратная? Если тестирование не нашло ошибки, но они проявились на бою? Если ошибки при этом были обнаружимы на тестовом стенде (в т.ч. тестовый стенд настроен наиболее близко к бою).
Утверждается, что в этом случае тестирование проведено некачественно.
Как измерять качество тестирования? Для этого случая пригодна метрика = количество ошибок на тестовом окружении / (количество ошибок на тестовом + боевом окружении). При этом количество ошибок берется взвешенное по уровню их критичности.
А что если тестирование не нашло ошибок и их не было обнаружено на боевом сервере?
Утверждается, что этом случае тестирование, как таковое, не принесло ценности и эти работы были сделаны зря (за исключением следующего случая, про который мы расскажем позже). С точки зрения Lean это потери.
Когда возможна такая ситуация? Когда тестируемый модуль не изменялся. Что может изменить модуль?
Когда нужно писать автотесты в этом случае?
Начнем с того, что автоматизированное тестирование не отменяет тестирование постановки, тестирование дизайна и написания тест кейсов по постановке! И не заменяет их. Если этого нет, то и автоматизацией не следует заниматься. При этом под автотестами следует понимать не только само выполнение сценария, но и подготовку к их прогону и использование результатов.
Если писать автотесты после создания кода, то это приведет к увеличению time2market (что автоматически приведет к увеличению связного капитала). Поэтому если принято решение покрывать код автотестами, то следует писать эти автотесты параллельно основному коду, в парадигме разработки “TestFirst” или “TDD”.
Основная ценность создаваемая при этом автоматизацией тестирования — это сокращение time2market за счет более быстрой выкладки новой версии.
Тесты нужны для гарантии работоспособности критических процессов
Несмотря на то, что автомобиль ни разу не загорелся, тем не менее наличие огнетушителя в нем не бесполезно.
Ошибка на сайте с большим трафиком, не позволяющая добавлять товар в корзину, может привести к более значимым потерям, чем расходы на разработку и проведение тестирования этой функции за год.
Следовательно, нужно выделить критические процессы, которые войдут в регулярные проверки (которые стоит делать если происходит какое-то изменение). Сопоставлять следует:
Это возможно через запуск нескольких инсталляций решения и тестирования новых beta-версий на “кошечках”, если это технически возможно и если найдутся такие добровольцы. После выкладки новой версии мониторится телеметрия и производится откат, в случае деградации показателей. (Напомним, что телеметрия на бою обязана быть вне зависимости от наличия тестирования).
Еще один случай полезности регрессионного автотестирования — это тестирование API (тестирование контракта API), если это API требуется для обеспечения критического процесса. Особенно это важно, если разработчики чужого модуля что-то меняют и не делают качественное тестирование изменений на своей стороне.
Когда не нужна автоматизация тестов
Если вам достался большой объем унаследованного не очень качественного кода. Покрывать автотестами такой хаос это увеличивать хаос.
В этом случае стоит выделить из этого решения логический модуль. После выделения слоя взаимодействия этого модуля с остальным кодом нужно покрыть взаимодействие автотестами. Это обеспечит гарантии сохранности поведения модуля и целостности после его перекодирования.
Автотесты не заменяют ручного тестирования. Ручное тестирование чаще всего провести быстрее и дешевле чем написать и в последующем сопровождать автотесты. В частности, если тестирование проводится после разработки кода, то из этого тестирования автоматизировать нужно только тот кусок, который войдет в регулярное тестирование критического функционала.
И напоследок — чеклист готовности компании к автотестам
Сразу оговоримся, этот чек лист не для всех, он написан для тестировщиков компаний, для которых разработка софта есть основной источник дохода.