Инструменты тестирования: карта по тому, что уникально выявляет каждый уровень

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

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

Где обычно образуется пробел

У большинства команд есть модульные тесты и какое-то сквозное покрытие, а середина тонкая. Это перевёрнутая картина: именно уровень API выявляет большую часть видимых пользователю дефектов и стоит при этом заметно дешевле, чем уровень над ним.

Второй частый пробел — покрытие отстаёт от объёма кода. Это лечится не ещё одной категорией инструментов, а покрытием, которое не упирается в то, сколько тестов человек успевает написать.

Вопрос, который важнее таблицы возможностей

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

Инструмент, который у вас уже есть и которым вы не пользуетесь

Прежде чем что-то добавлять, стоит посмотреть, что уже установлено и простаивает: в большинстве организаций возможностей для тестирования больше, чем используется.

Обычно находится фреймворк модульных тестов с горсткой тестов двухлетней давности. Часто есть браузерный набор, который гоняется по ночам и который никто не читает. Нередко есть сканер, складывающий отчёт в канал с отключёнными уведомлениями. Каждое из этого когда-то купили или настроили не просто так и перестали использовать тоже не просто так, и причину полезно знать, прежде чем снова тратить деньги на ту же категорию.

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

На что потратить следующий час

1. Сценарий, сломать который было бы стыдно, — покрытый сквозными тестами.

2. API за ним — покрытый вместе с негативными сценариями.

3. То, что сломалось в прошлый раз, — превращённое в постоянную проверку.

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

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

• GitHub Actions встраивает этот шаг в ваш собственный рабочий процесс, настраивается из терминала.

Где на этой карте находится TestSprite

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

Auto-Authentication поддерживает сессии живыми на протяжении всего прогона, Dynamic Variables переносят значения между вызовами, Dependency Chains выводят порядок выполнения, а Auto-Cleanup удаляет ровно то, что создал прогон. Шаги в браузере описаны намерениями, а не селекторами, поэтому редизайн не окрашивает набор тестов в красный.

Модульные тесты остаются вашими и остаются самой дешёвой обратной связью, которая у вас есть. Контрактное тестирование, нагрузочное тестирование и сканирование безопасности остаются отдельными инструментами. Выигрыш в том, что тонкая середина заполняется без дополнительной нагрузки по написанию тестов, которая конкурирует с выпуском релизов.