Когда стоит писать автотесты
Вы знали, что команда 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-компании наработках и готовых библиотеках фреймворков, что экономит время и средства заказчика.
В конце проекта заказчику должны быть переданы гибкие автотесты, которые легко актуализировать и поддерживать своими силами.
Не удалось до конца определиться — внедрять автоматизацию у себя на проекте или продолжать кормить армию ручников. Свяжитесь с нами. Посчитаем все за и против вместе.
Узнать подробнее
Мы предлагаем быстрый старт в рамках пилотного проекта со скидкой 50%. Мы выполним часть работ и покажем себя, вы сэкономите половину бюджета и время на раздумья.
Как понять, что пора автоматизировать тестирование
Если вы хоть раз задумывались над этими вопросами, наша статья поможет в них разобраться.
Цели автоматизации
Когда внедрение автоматизации принесет пользу:
Если хотя бы 1 признак относится к вашему проекту, автоматизация принесет улучшения: тестовые данные будут генерироваться автоматически, частые регрессы не будут отнимать время, а промежуток между выявлением дефекта и его исправлением сократится.
Если пока ваш проект не такой, подождите, пока разрастется функционал или команда. Не стоит делать автотесты ради автотестов.
Как мы поняли, что нужно автоматизировать
Мы разрабатываем приложение для учета соискателей и сотрудников для HR: поиск, прием на работу, задания на испытательный период, отпуска, текущие задачи и проекты и т.д.
Предпосылки для автоматизации:
- Продукту 3 года;
- В команде 5 разработчиков;
- Релизы обычно раз в 3 недели;
- Много генерации тестовых данных
Итого: 4 признака из 5. До автоматизации на проверку всех тест-кейсов уходило 4 дня.
Мы решили частично автоматизировать систему, но покрыть автотестами не все 900 тест-кейсов, а только затрагивающие функционал, который не меняется в каждом спринте: авторизация, восстановление пароля, действия с пользователями, нотификации, создание событий. В итоге написали smoke-автотесты для всех модулей, которые прогоняются в непрерывной интеграции (CI) при каждой сборке. Мы могли бы потратить больше времени и автоматизировать остальные кейсы, но это было бы нецелесообразно: проект развивается, бизнес-логика и интерфейс меняются слишком часто, чтобы писать автотесты. Их пришлось бы переписывать в каждом спринте.
В итоге smoke-автотесты запускаются в CI при каждой сборке и сигнализируют разработчикам о дефектах в реальном времени. Так разработчики сразу начинают исправлять их, не переключаясь на другие задачи, а у QA появилось больше времени на тщательное тестирование только что реализованного функционала вместо перепроверок работы старого.
Противоположная ситуация сложилась на другом проекте — приложении для создания оценок и аналитики.
Предпосылки автоматизации
Автоматизировать решили в качестве эксперимента. Это молодой проект, в нем пока не так много функционала — всего 61 тест-кейс.
Проект примечателен тем, что на нем нет ни одного ручного тестировщика. Исследовательское ручное тестирование делает автоматизатор на этапе написания и отладки скрипта автотеста, который затем просто прогоняется в CI, заменяя тем самым ручной труд.
На июль 2017 года автоматизировано 46 тест-кейсов на бэкeнд и 14 на фронтeнд, покрытие кейсов автотестами около 96%.
Этот проект — наглядный пример того, что будет, если начать автоматизировать с самого старта работ: временны́е затраты на тестирование за все время жизни проекта меньше, чем если бы сначала мы тестировали вручную, а затем внедрили автоматизацию.
План действий по автоматизации
Итак, вы удостоверились, что автоматизация тестирования принесет пользу. Что дальше? Разрабатываем план действий:
- что автоматизировать;
- как автоматизировать;
- чем автоматизировать.
Что автоматизировать
- Труднодоступные места в системе: бэкенд процессы, логирование файлов, запись в базы данных;
- Часто используемый функционал, где высоки риски ошибок: системы оплаты, регистрации и т.д. Автоматизация проверки критической функциональности гарантирует быстрое нахождение ошибок — 1 тест в среднем идет 2 минуты. Быстрее найдем — быстрее исправим;
- Рутинные операции: переборы данных, формы с большим количеством вводимых полей. Автоматизировать заполнение полей данными и их проверку после сохранения;
- Валидационные сообщения: автоматизировать заполнение полей некорректными данными и проверку на появление валидации;
- Длинные end-to-end сценарии. Например, сценарий для риэлторской CRM: регистрация пользователя — заведение заявки от его имени — создание задачи — взятие в работу — назначение задач на специалистов — получение задач обратно в работу- регистрация результата;
- Проверку данных, требующих точных математических расчетов: бухгалтерское или аналитическое ПО;
- Проверку правильности поиска данных.
Как автоматизировать
Не все тест-кейсы нужно автоматизировать в первую очередь. Например, если у вас 300 тест-кейсов для проверки модулей, 100 для компонентов, 20 для подсистем и всего 5 пользовательских сценариев (см. рис.2), начинать автоматизацию лучше с тестов, проверяющих отдельные функции, т.е. с unit-тестов. Они выполняются быстро, но их больше. Когда эти кейсы уже покрыты автотестами, можно приступать к автоматизации тест-кейсов по проверке компонентов, далее — подсистем и т.д.
Полная автоматизация
Предпосылки для автоматизации
Пример полной автоматизации — надстройка над Jira для планирования и управления проектами. На проекте порядка 600 тест-кейсов, все покрыты автотестами. В случае изменений логики или интерфейса, приходится править около 100 скриптов. Это все равно занимает меньше времени, чем ручное тестирование.
На этапе планирования автоматизации для определения количества автоматизируемых тест-кейсов для каждого уровня архитектуры мы взяли пропорции из пирамиды тестирования (рис.3). В итоге у нас получилось более 300 unit-тестов, 200+ на интеграцию и API и 38 GUI-тестов, повторяющих сценарии использования продукта конечным пользователем.
Получилось больше всего низкоуровневых тестов, способных отловить баги в отдельных функциях и модулях. Они выполняются быстрее высокоуровневых UI-тестов пользовательских сценариев. Такое соотношение оптимально по времени выполнения автотестов и величины покрытия — информация об обнаруженных багах приходит достаточно быстро, прогон автотестов не занимает много времени и процент покрытия кода достаточно велик (можно быть уверенными, что тесты выявят все критические и значимые дефекты).
Отсюда вопрос: зачем нам такое разнообразие сложных и долгих тестов с пользовательскими сценариями, если можно написать много небольших, быстрых и легких в поддержке unit-тестов?
Unit-тесты тестируют код и дают разработчику уверенность, что отдельный кусок его кода работает, как задумано, и не ломает логику работы кода его коллеги. UI-тесты тестируют систему целиком таким образом, как пользователь будет ее использовать. Создание таких тестов занимает от пары дней до нескольких недель, однако, их важно иметь на проекте. Они имитируют сценарии использования вашего продукта реальными людьми — от них зависит впечатление о вашем продукте в целом.
Общая рекомендация тут одна: иметь все виды автотестов в пропорциях согласно пирамиде на каждом из уровней архитектуры системы. Тогда появляется возможность получать эффективную отдачу от таких тестов. Функциональные тесты, которые тестировщики проводили на протяжении спринта: негативные, позитивные, комбинаторные и т.п., нужно помещать на уровень API-тестов. Так создается быстрый и стабильный пакет регрессионных тестов.
На уровень UI-тестов выносятся приемочные тесты или пользовательские сценарии веб и мобильных приложений.
Следуя рекомендациям пирамиды, мы получаем гарантированно проверенный функционал и при этом экономим время команды. Сравните: регулярные затраты на многодневное регрессионное тестирование 3-4 специалистами по ручному тестированию и 2-3 недели разработки автотестов одним специалистом и пара часов на их поддержку.
Чем автоматизировать
Выбор инструмента зависит от специфики приложения и требований к тестовым сценариям. Чаще всего выбирается несколько инструментов — отдельно для каждого уровня архитектуры системы. Например, GUI тестируется с помощью Selenium, API с java + restAssured, а нагрузка с jMeter.
На что обратить внимание при выборе
- Мы не рассматриваем бета-версии и нестабильные сборки инструментов. Это экономит время на решение проблем, связанных с дефектами самого инструмента. Например, проблемы с кодировкой в RF HTTPLibrary;
- Желательно, чтобы документация инструмента была на русском языке (как, например, для Selenium);
- Специализированные форумы по конкретному инструменту помогают быстрее получить ответы на вопросы использования. Например, если используете связку java TestNG + Selenium, в интернете можно найти ответ любой вопрос. А вот если возьметесь за Python based Robot Framework — документация будет только на английском и без описания особенностей использования кейвордов, в поисках которых приходится анализировать код библиотек;
- Обращаем внимание на возможность интеграции инструментов тестирования с программным обеспечением, которое используется в компании;
- Стоимость инструментов тестирования: если планируете одноразовое тестирование, покупать дорогостоящие инструменты нецелесообразно.
Что для чего подходит
Для автоматизации функционального тестирования важны поддержка конкретного языка программирования, возможность построения отчетов о тестировании для автоматической регистрации обнаруженных дефектов при регулярном прогоне тестов в CI.
Инструментам нагрузочного тестирования требуются поддержка протокола, который используется приложением, встроенные средства мониторинга параметров серверов во время прохождения теста, гибкая настройки и запись сценариев нагрузочного тестирования, средства анализа результатов и построения отчетов о тестировании.
Мы предпочитаем работать с популярными и надежными средствами тестирования: Selenium Webdriver, Java TestNG, jUnit, RestAssured, Allure, jMeter, хотя у нас есть опыт использования и других инструментов (например, Robot Framework).
Практически каждую задачу в пределах одного вида тестирования можно решить с помощью любого инструмента, однако трудоемкость и стоимость решения будут отличаться. Например, если у инструмента нет средств анализа результатов и построения отчетов (как в случае использования, предположим, testNg + Selenium без Allure), то время на анализ результатов автоматизированного тестирования будет примерно таким же, как при ручном тестировании. Выгоды никакой. Внедрение автоматизации тестирования пройдет легко и быстро, только если в самом начале правильно подобрать инструмент под решаемые задачи. Одно лишь это уже может стать ключом к успеху.
Итого
Не на всех проектах действительно нужна полноценная автоматизация. Иногда, чтобы ускорить работу команды, достаточно вспомогательных скриптов.
Если вы планирует развивать продукт годами большой командой, без автоматизации не обойтись. В нашей практике были случаи, когда мы внедряли автоматизацию после 3-4 лет работы над продуктом. И результат был виден и команде, и конечным пользователям. В таких случаях автоматизация начинается постепенно, пока команда привыкает к новым инструментам и процессу работы. Обратите внимание на инструменты — важно выбрать те, которые подходят к уже применяемым инструментам и библиотекам.
Автоматизированное тестирование призвано помочь команде делать те же задачи быстрее и оперативней выпускать новые релизы продукта. Если обычно на тестирование уходит 3-4 дня, с автоматизацией это время сократиться до нескольких часов. Это особенно актуально для крупных и постоянно развивающихся IT-продуктов.
Когда стоит переходить к автоматизации тестирования на проекте?
Почему все больше компаний используют для контроля качества выпускаемого ПО автоматизированное тестирование? Надеюсь, что никто не подумал, что автотесты позволят отказаться от ручного и будут серебряной пулей, решающей все проблемы в процессах. Это заблуждение, т.к. для повышения качества ПО нужна совокупность мер, лишь часть которых будет — автоматизировать всё, что не приколочено. Явными плюсами автоматизации можно назвать ускорение выпуска релизов, обеспечение повышение покрытия автотестами ПО при тестировании.
Автотесты
Ручное тестирование
Тестировщик выполняет кейсы пользователей, таким образом в процессе тестирования можем получить потенциальный пользовательский фидбэк
Предпосылки для использования автотестов в команде:
- Ваше приложение имеет большое количество функций, требующих проверки на регрессе;
- Масштаб проекта и долгоидущие планы на его развитие, хотя бы больше года. В этом случае также пора задуматься об уменьшении ручного труда с переходом в автоматизацию.
- Частые релизы. Если ваш проект увеличивается, релизы ускоряются, но штат сотрудников QA остается прежним, то стоит приступать к автоматизации, многие рутинные операции получится быстрее проверять.
- Усложнение технологий, в котором проверить «вручную» сложно. Перелопачивать действительно большой объем данных, с которым мы можем столкнуться разве что в BigData, не имеет смысла. Например, сложно вручную проверить все связи между микросервисами или в IoT (Internet of Things).
Стратегия, которая поможет на первых шагах автоматизации:
- Исследуйте. Потратьте время на поиски повторяющихся кейсов, которые выполняются регулярно. Это позволит снизить нагрузку на специалистов QA в целом;
- Ищите связи. Если ли вы проводите тестирование в разных браузерах (UI тесты) с одним бизнес-кейсом – автоматизируйте данные операции;
- Работайте в команде. При изменениях вашего ПО (рефакторинге, добавлении новой функциональности или изменении текущей) будьте готовы поддерживать ваши кейсы в актуальном состоянии. И прислушивайтесь на планировании, что делают ваши коллеги разработчики, чтобы тесты не падали.
- Руководствуйтесь логикой. Автотест должен быть независим от других тест-кейсов – тест должен быть объективно маленьким, легко читаться и проверять одно условие.
- Подходите творчески. Автотест должен иметь стабильный ожидаемый результат (не всегда рекомендуется использовать генерацию случайных величин, чтобы избежать нестабильных (flaky) тестов, который то работает, то нет, и каждый раз необходимо тратить время и искать причину).
- Следите за порядком. Автотесты не должны дублировать проверки между собой. Например, на уровне unit-тестов можно проверить вариации данных, на API уровне выполнить проверку между сервисами, используя т.н. заглушки — самописные приложения (stub), UI тестами проверить клиентские сценарии (переход по страницам, ввод данных, нажатие кнопок). Таким образом, будет разбивка между проверками для бизнес-функций на каждом уровне тестирования для достижения оптимального времени прогона автотестов.
Была ли статья полезной?
Автоматизация тестирования на больших проектах: почему и как мы ее проводим
До выпуска «в люди» любой программный продукт (сайт, приложение) проходит долгий путь проверок и доработок, пока он на 100% не будет отвечать ожиданиям пользователей. Проверка качества ПО, соответствия заявленных к нему требований и реальной функциональности, поиск и исправление ошибок (багов) и устранение дефектов — эти и другие задачи решает тестирование. Оно нужно как самим разработчикам, чтобы увидеть готовность продукта к рынку, так и заказчикам — убедиться, что бюджет потрачен не зря.
Разница между ручным и автоматизированным тестированием
Ручное тестирование (manual testing) — классический метод оценки качества ПО, когда тест-кейсы запускаются без использования средств автоматизации: тестировщики вручную проходят тестовые сценарии и составляют отчеты об ошибках. Этот процесс довольно трудоемкий и продолжительный, без сочетания с автотестами используется только на небольших проектах.
Автоматизированное тестирование выполняется с помощью специальных скриптов, при этом вмешательство человека сводится к минимуму, а точность и скорость проверок гораздо выше.
Чтобы говорить о автоматизации тестирования предметно, рассмотрим примеры ее внедрения в наших проектах: системе управления школой дистанционного обучения (на базе Source LMS), healthcare-проекте и большом онлайн-магазине.
Для чего нужны автотесты на больших проектах? Наш опыт
В случае системы управления школой и онлайн-магазина автотесты нужны как проверка устоявшегося критического функционала. Такие сценарии кардинально не изменяются, но требуют постоянной оценки работоспособности, поэтому было принято решение заменить одни и те же ручные проверки на автоматические.
Автоматизация присутствует и на healthcare-проекте, где кроме цели экономии времени требуется мониторинг состояния критических сценариев на сайте в любое время. Также мы разработали и внутреннюю систему нотификации о результатах тестирования.
Критические сценарии и мониторинг были выбраны для автоматизации как наименее динамично меняющиеся и наиболее требующие покрытия задачи на всех проектах. Тесты могут дописываться и меняться, но не требуют постоянной поддержки со стороны какого-либо из отделов.
Что входит в критический и некритический функционал проекта
Критические сценарии — сценарии, ошибки в работе которых принесут клиенту убыток, помешают получить ожидаемую прибыль. Например, для e-commerce проектов это процесс поиска и покупки товара, регистрация и авторизация.
Так, в автоматизации проекта интернет-магазина в основные сценарии входит добавление товара в корзину с разными параметрами, переход в карточку товара и проверка правильности данных в ней, оформление заказа с выбором опций доставки и оплаты. В работе healthcare-портала эти сценарии включают работу с купонами (загрузка, покупка, получение, отображение) для зарегистрированных и незарегистрированных пользователей.
Пример одного из автоматических тестов в системе управления школой: авторизация на сайт, выбор из списка контроля знаний требуемой проверки (набор вопросов с вариантами ответов), полное прохождение контрольного задания и получение результата (оценки в баллах). Его мы рассмотрим ниже.
Нужно ли тестировать некритические сценарии?
Покрытие автотестами любых сценариев, вплоть до целого проекта, возможно, но не всегда целесообразно.
Некритические сценарии вызывают минимум простоев, дискомфорта клиентов проекта и не влияют на прямые доходы заказчика. Например, проверка работоспособности вывода статических страниц интернет-магазина: на них присутствует разнообразная информация, но в случае проблем с этими страницами заказчик испытает гораздо меньше сложностей, чем при ошибках в работе заказа товара.
Когда мы проводим автотестирование?
Проверки с помощью автотестов проводятся перед релизами, а также планово по расписанию:
- на healthcare-проекте автотесты запускаются ежедневно в 3 часа ночи (время выбрали эмпирически);
- для проекта онлайн-школы запуск тестов обязательно осуществляется в ручном режиме на тестовой среде (до релиза), а потом на продакшене (после релиза). Специфика проекта и характер релизов не требуют постоянного мониторинга — тесты не используются в качестве поддержки;
- на проекте онлайн-магазина автотесты интегрированы во все процессы: запуск до релиза на тестовой среде, на продакшене после релиза, периодический запуск в качестве мониторинга.
Для всех проектов возможен запуск тестов вручную путем выполнения скрипта из консоли или с использованием интерфейса Gitlab.
Техстек и выбор текущих решений
Репозитории с автотестами для всех проектов лежат в Gitlab, а в качестве основного стека был выбран Playwright + Jest . У такого варианта есть ряд преимуществ:
- большой и хорошо поддерживаемый набор встроенных инструментов позволяет быстро писать тесты без необходимости создавать перегруженную архитектуру фреймворка;
- тесты разворачиваются на необходимой среде с минимальными затратами времени, официальный Docker image;
- предоставляет список доступных устройств и браузеров, который легко конфигурируется и полностью покрывает нужды на проектах;
- поддержка для автоматических тестов требуется редко и не занимает много времени;
- Playwright быстро развивается, используется во многих компаниях и хорошо поддерживается.
Достоинства стека позволяют ощутимо сэкономить время при покрытии большого количества сценариев поведения для каждой из возможных конфигураций устройств клиентов.
На проекте интернет-магазина опробован стек Java + Selenium. Наш отдел тестирования остановился на нем, чтобы расширить используемые технологии в автотестах и создать более сложный по архитектуре фреймворк. Этот стек зарекомендовал себя при написании самых разнообразных тестов и отлично подходит для проверки end-to-end сценариев.
При создании автотестов для healthcare-портала выбор пал на связку Python + Selenium. Это первый проект, на котором появилась автоматизация тестирования в компании, и выбор языка программирования и фреймворка именно такой в силу экспертизы команд разработки, тестирования и DevOps.
Как проходит автотестирование
Когда принято решение о необходимости автоматизации на проекте и выбран технологический стек, подбираем сценарии для покрытия тестами, создаем тестовую документацию с конкретными шагами и набором данных для каждого сценария, разрабатываем тестовый фреймворк и интегрируем его с участием DevOps-команды.
Сам процесс автоматизации тестирования обычно происходит так:
- запуск (ручной или автоматический по расписанию) со стандартными/выбранными параметрами;
- выполнение теста: автоматически пошагово выполняются сценарии согласно тестовой документации;
- получение результатов теста;
- анализ полученных результатов.
На нашем healthcare-проекте тесты перезапускаются автоматически, если на одном из шагов произошла ошибка.
При запуске тестов можно выбрать параметр окружения, определяющий, где именно будут происходить автоматические проверки: на тестовой среде или на проде. Примеры выполняющихся шагов: авторизация, добавление в корзину, покупка, оплата тестовыми картами, получение письма, скачивание файла.
После завершения тестирования либо на экран, либо в базу сохраняются результаты прохождения сценария. Если на каком-то шаге возникла ошибка — получаем уведомление об этом, если все прошло успешно — получаем уведомление об успешном прохождении. На проекте healthcare-портала письмо приходит на почту клиента и на почту компании, что особенно полезно при возникновении проблемы на сайте: следующий запуск автотестов с успешным прогоном всех тестов показывает, что проблема решена или больше не повторяется.
Пример автоматического прохождения урока в онлайн-школе:
1. Автотест запускается вручную или автоматически по расписанию на сервере.
2. Автоматически открывается браузер, выбранный в скрипте для запуска (любой, например, Chromium). При запуске по расписанию с сервера автотест работает в headless-режиме.
3. Скрипт автоматически вводит адрес сайта, попадает на страницу авторизации и переходит в кабинет школьника.
4. Согласно выбранным параметрам скрипт переходит в выбранный тест. Цель — пройти все задания и набрать максимальный балл. Для контроля результаты сверяются с данными из базы, к которой скрипт также подключается автоматически.
5. Скрипт проходит тест без вмешательства человека, проставляя правильные ответы, заранее полученные из базы.
6. Когда урок пройден, на страницу выводится оценка «автостудента». Ожидаемый результат — 12/12 баллов.
7. После окончания теста окно браузера автоматически закрывается, а информация выводится в консоли:
- результат PASS или FAILED;
- тип браузера;
- количество пройденных и запущенных тестов (в примере — 1);
- время прохождения.
Результаты можно сохранять в базе, передавать по почте, выводить комментарием к задаче.
Автотест проверки работы калькулятора стоимости анализов на healthcare-портале:
1. Запускается скрипт автотеста, после чего автоматически откроется браузер.
2. На главной странице сайта автоматически вводятся регистрационные данные для входа в личный кабинет.
3. Из кабинета скрипт переходит в калькулятор и случайным образом выбирает город для подсчета стоимости пакета анализов.
4. Выбор нескольких анализов в корзину, расчет оптимальных тарифов. На экран выводятся подобранные скидки и выбранные предложения.
5. Действия повторяются для других случайно выбранных городов.
Результаты прохождения выводятся на экран или отправляются на почту.
Результаты после внедрения автотестов на проектах:
Сократили время на тестирование
По проекту онлайн-школы время тестирования сократилось в среднем на 20%:
- без автотестов прохождение кейса вручную занимает от 15 до 30 минут, еще 10-15 минут — подготовка тестовых данных (в случае ошибки кейс придется проходить заново);
- с автотестами кейс выполняется за 1 минуту, на запуск и просмотр результатов уходит 10 секунд. Не нужно готовить тестовые данные, что экономит время и исключает ошибки при подготовке тестов.
На healthcare-проекте до автоматизации ручное выполнение тестовых сценариев занимало 30-40 минут и было обязательным при каждом цикле тестирования. Автотесты же полностью отрабатывают за 10-12 минут.
Улучшили тестовое покрытие
При тестировании функционала онлайн-школы часть кейсов все равно нужно выполнять вручную. Однако кейс с автоматизацией покрывает в среднем 15-20% всего тестирования для большинства релизов. В редких случаях (при отсутствии изменений в модулях, не покрытых автотестами) этот показатель может доходить до 60%.
Разгрузили команду
На healthcare-проекте автотесты сократили время на тестирование на 99% — тестировщик привлекается на проект крайне редко, и если привлекается, проверяет результаты выполнения тестов.
Кроме этого автотесты позволяют отслеживать состояние системы, получать нотификации о проблемах для клиента и для нас. Так что со стороны DevOps на поддержку требуется минимальное количество времени — привлекаются только, если тесты падают несколько раз.
Постоянно мониторим состояние системы
Еще один плюс — автоматический перезапуск тестов, если на каком-то шаге произошел сбой. Благодаря этому удается исключить “ложные” падения, когда система работает нормально, но произошел кратковременный сбой, который не повлиял на работу сайта, но помешал автотестам корректно выполниться. Внутренняя система нотификации позволяет всегда знать, что прод рабочий, узнать о проблеме и быстро на нее среагировать.
Подводя итоги, скажем, что автоматизация тестирования — это инвестиция в будущее компании и возможность значительно повысить качество и скорость обновления программного продукта, оптимизировать расходы.
Если вы хотите внедрить автоматизацию на своем проекте, свяжитесь с нами. Подберем наиболее эффективное решение и настроим систему тестирования под ваши специфические требования.