Непрерывное тестирование ускоряет поставку программного обеспечения, делая весь процесс тестирования более быстрым. А благодаря незамедлительной обратной связи, которая помогает уже на самых ранних этапах выявлять ошибки и другие проблемы в приложении, гарантирует, что команды разработки будут создавать высококачественные и надежные приложения. Кроме того, сама способность организовать и проводить эффективное тестирование может значительно снизить затраты в компании, как за счёт экономии времени разработчиков, так и вследствие создания добротного конвейера поставки, в котором они могут быстро вносить изменения в код с минимальными рисками нарушения работоспособности приложения в продуктивной среде.
Главным элементом непрерывного тестирования является его автоматизация, что даёт множество преимуществ:
- Быстрое получение обратной связи
- Аккуратное и тщательное тестирование
- Высокое покрытие тестами
- Быстрое обнаружение ошибок
- Повторное использование тестов
- Более короткие сроки поставки
- Адаптация для DevOps
- Экономия времени и денег
Несмотря на перечисленные выше преимущества, начальные вложения в автоматизацию тестирования могут быть очень высоки. Приобретение ПО, затраты на обучение работе с ним, проектирование и создание автоматизированных тестов – всё это требует немалых времени и денег. Однако, как только вы начинаете всё активнее разрабатывать новые функции в своём продукте, ручное тестирование в конечном итоге выходит дороже, а автоматическое – дешевле.
На нашем курсе DevOps: современный подход к организации работы ИТ мы подробно разбираем, как приземлить методологию DevOps на реальные ланшафты организаций. При этом у вас есть возможность обсудить с тренером барьеры, существующие в вашей практике и мешающие полноценно получать выгоду от использования DevOps.
Кроме того, следует понимать – не всё нужно автоматизировать и не всё можно автоматизировать. Поэтому важно тщательно оценить, изучить и проанализировать свои требования, прежде чем решить, как лучше всего организовать автоматизацию тестирования. Когда следует автоматизировать тесты, а когда – нет?
Какие тесты можно автоматизировать
Практически каждая команда разработчиков работает над проектом, который критически зависит от сроков, а значит, что времени на применение всех передовых практик всегда не хватает. То же самое относится к стратегии тестирования, поскольку тестирование как вид деятельности не всегда является приоритетом для команд разработки. Нужно попытаться найти баланс и сделать правильный выбор в зависимости от типа разрабатываемого приложения, временных рамок, используемого ПО для тестирования и имеющихся ресурсов. Вот важные типы тестов, которые можно автоматизировать.
Модульное тестирование
Это отличный способ приступить к автоматизации тестирования, поскольку модульные тесты направлены лишь на часть кода, в ходе которых он проверяется на работоспособность, и не зависят от других частей приложения. Таким образом, разработчики получают больше информации о работе созданной функциональности. Благодаря современной культуре тестирования многие команды используют методологию разработки через тестирование (test-driven development, TDD), при которой они начинают составлять тесты до написания кода. Таким образом гарантируется качество и кода, и тестов.
Приоритетные функции
Если у вас в плане десятки функций и сжатые сроки на их разработку, вы можете выделить среди них те, что имеют высокую вероятность сбоев. Тестирование подобных функций нужно начинать как можно раньше.
Регрессионные и интеграционные тесты
Интеграционные тесты используются для определения того, работают ли отдельные модули в приложении как группа, а регрессионные тесты проверяют, что функции приложения работают должным образом. Эти два теста обычно выполняются после изменений / улучшений приложения, поэтому тестировщики постоянно проводят эти тесты. Автоматизация таких тестов экономит огромное количество времени, высвобождая его для выполнения других типов тестов.
Нагрузочные тесты и тесты производительности
Для тестов производительности и нагрузочных тестов нет альтернативы в виде ручного тестирования, поскольку необходимо моделировать сотни или тысячи пользователей, работающих в разных условиях: из-под разных браузеров, в разных часовых поясах, использующих разные операционные системы и т.п.
Повторяющиеся тестовые сценарии
Это очень важные тесты, которые команды разработки вынуждены запускать чуть ли не постоянно. Например, работоспособность функции входа в систему – она обеспечивает возможность пользоваться приложением, влияя на его доступность. Поэтому лучше автоматизировать тестирование и сэкономить прорву времени тестировщиков и разработчиков.
Базовая функциональность (дымовые тесты)
В отличие от других тестов, дымовые тесты не такие сложные и относительно легко реализуемые. При этом прохождение этих тестов имеет решающее значение. Они информируют команды разработки о том, правильно ли работают базовые функции приложения, например: открывается ли окно входа в приложение, могут ли пользователи войти в систему, доступен ли API, доступно ли приложение из разных мест и т.п.
Какие тесты не нужно автоматизировать
Всё больше и больше узнавая о преимуществах автоматизации тестирования и глубоко проникаясь ими, можно задаться закономерным вопросом – а почему бы не автоматизировать вообще все тесты? Ответ в виде “не нужно пытаться автоматизировать всё” идёт вразрез с DevOps-мышлением, в котором явная установка на автоматизацию всего и вся. Перед планированием автоматизации тестирования нужно учесть несколько факторов. Вот примеры тестов и сценариев, для которых не нужна автоматизация.
Пользовательский опыт (UX)
Эта область тестирования не может быть автоматизирована. Многие аспекты UX-проектирования требуют ручного, долгого и утомительного тестирования. Например, когда разработчики хотят понять, насколько легко пользователи могут зарегистрироваться на веб-сайте, или проверить, какие наборы полей дают лучшую видимость профилей пользователей. Подобные тесты должны быть проведены вручную.
Стадии ранней разработки
Когда какая-то функция только-только разрабатывается, в её код постоянно вносятся изменения, а это может затруднить составление и теста. На ручное тестирование этих функций уходит меньше времени, поэтому следует дождаться стабильной версии.
Функциональность, не имеющая большой важности
Автоматизация тестирования требует времени и усилий, поэтому следует автоматизировать тестирование не всех функций, разрабатываемых в рамках проекта, а лишь самых важных функций. Низкоприоритетные можно оставить в стороне и продолжить тестировать их вручную.
Тесты без понятных результатов
Командам разработки необходимо знать ожидаемый результат для каждого входа функции. Если результаты непонятны, то и автоматизация не предоставит необходимых доказательств того, что функция работает должным образом.
Тесты, которые невозможно полностью автоматизировать
Если автоматизирована половина теста, а другая половина так и осталась выполняемой вручную, то это приводит к сложности и дополнительным расходам, поскольку проведение такого теста требует много времени, а достоверность его под большим вопросом. Было бы рациональнее продолжать тестирование таких функций вручную.
Фреймворки автоматизированного тестирования
В каждой команде разработки и поставки ПО группа QA отвечает за разработку, внедрение и выполнение тестов. Для каждого типа тестирования должен быть определён тестовый сценарий, принципы, правила и инструменты для проведения. Фреймворк тестирования – это набор этих руководств, инструментов и практик, который помогает инженерам-тестировщикам эффективно выполнять тестовые сценарии.
Существуют разные фреймворки для разных целей тестирования. Вот некоторые из самых популярных типов фреймворков для автоматизированного тестирования:
- Модульный: приложение разделено на отдельные модули, и каждый модуль тестируется в изолированном состоянии
- Линейный: составление и исполнение тестовых скриптов. Тестировщики пишут тестовые сценарии последовательно, выполняя их затем для каждого отдельного тест-кейса
- Библиотечная архитектура: создан на основе модульного фреймворка тестирования, с той лишь разницей, что содержит функции для многократного использования
- Управляемое данными тестирование: тестовые скрипты выполняются и верифицируются на основе данных, которые хранятся в центральном хранилище данных или базе данных (SQL, ODBC-ресурсы, csv или xls файлы)
- Тестирование по ключевым словам: в данном фреймворке не обязательно иметь навыки программирования, поскольку ключевые слова, используемые при создании тестов, отделены от технического кода. Тестировщику достаточно иметь представление о всём наборе действий, реализованных во фреймворке
- Гибридный: комбинация из различных фреймворков.
Главная цель всех команд разработчиков программного обеспечения – обеспечить быструю поставку качественного и надежного программного продукта. Чтобы обеспечить быстрый и эффективный процесс поставки, необходимо непрерывное тестирование. Автоматизация – ключ к тому, чтобы разрабатываемое ПО могло быстро пройти через все стадии конвейера разработки и предоставить клиентам свои функции. Однако, это не означает, что команды должны вкладывать всё свое время и ресурсы в автоматизацию тестирования. Команды должны понимать, что можно и нужно автоматизировать, а что не стóит. Правильный выбор охвата тестов на ранних этапах разработки имеет большое значение.
На нашем курсе DevOps: современный подход к организации работы ИТ мы подробно разбираем, как приземлить методологию DevOps на реальные ланшафты организаций. При этом у вас есть возможность обсудить с тренером барьеры, существующие в вашей практике и мешающие полноценно получать выгоду от использования DevOps.
