Четыре уровня автономного тестирования программного обеспечения
1. Написание тестов с помощью ассистента. Вы говорите, что тестировать, — инструмент пишет код. Экономия времени реальная. Но все решения по-прежнему за вами.
2. Сгенерированное покрытие. Инструмент сам предлагает, что тестировать, исходя из спецификации или работающего приложения. Вы проверяете план. Здесь честно находится большинство продуктов.
3. Самоподдерживающиеся тесты. Покрытие подстраивается под изменения продукта, и чинить его вручную никому не нужно. Требует умения отличать намеренное изменение от регрессии.
Четвёртый уровень — замкнутый цикл: он обнаруживает сбой, передаёт свидетельства агенту для написания кода и проверяет исправление. Сегодня это существует в узком виде — для поведенческих дефектов с понятным воспроизведением — и не распространяется на то, что требует продуктового решения.
Что каждый уровень требует от вас
Первый уровень: знать, что нужно тестировать. Все суждения остаются за вами.
Второй уровень: проверить план. Это быстрее, чем писать самому, но не бесплатно: пропустив этот шаг, вы получите покрытие, которого никто не понимает.
Третий уровень: решать, что считать намеренным изменением. Инструмент не может знать, что сценарий переработали специально.
Четвёртый уровень: определить правильное поведение настолько точно, чтобы исправление можно было проверить без вас.
Обратите внимание: по мере подъёма человеческая работа не исчезает. Она смещается выше — от набора текста к принятию решений, а это и ценнее, и труднее делегировать.
Потолок, о котором не пишут в рекламе
Ни один уровень не избавляет от необходимости решать, что считать правильным. Инструмент может вывести, что эндпоинт существует и что поле — строка. Но он не выведет, что две скидки не должны суммироваться, потому что это бизнес-правило, которое живёт в решении, принятом человеком.
Любой продукт, намекающий на обратное, описывает второй уровень и называет его четвёртым.
Вопросы, которые определяют место продукта на лестнице
Поставщики описывают себя на самой высокой ступени, какую способны защитить, поэтому стоит держать наготове вопросы, которые точно указывают их место.
Кто решает, что тестировать. Если решаете вы — это первый уровень, каким бы способом ни писался сам тест.
Что происходит, когда интерфейс меняется, а поведение — нет. Если тест чинит человек — это второй уровень. Если тест выживает — третий. Если он выживает и при этом падает, когда поведение действительно изменилось, — это третий уровень, сделанный как надо, и встречается такое реже.
И что происходит после сбоя. Если результат уходит на дашборд для человека — на этом всё и заканчивается. Четвёртый уровень означает, что результат пригоден для того, что чинит проблему, и исправление проверяется без человека-посредника. Три вопроса подряд занимают пять минут и дают куда более честную оценку, чем любой список функций.
С чего начать
Терминал
npm install -g @testsprite/testsprite-cli
testsprite setup
Если ставить ничего не хочется, то же самое делает дашборд. Всё остальное, что умеет командная строка, собрано в репозитории CLI.
Если пайплайн принадлежит другой команде, то GitHub App — путь наименьшего сопротивления: это вебхук, он ничего не меняет в вашем репозитории и срабатывает, когда сборка сообщает, что новая версия развёрнута. Если же вы хотите видеть проверку прямо в репозитории, добавьте шаг GitHub Actions , который делает то же самое.
Где на этой лестнице находится TestSprite
Второй уровень везде, третий — для изменений поведения, и четвёртый в узком виде: сбой возвращается в форме, с которой может работать агент для написания кода, а исправление проверяется той же проверкой, а не тем рассуждением, которое к нему привело.
Конкретно: покрытие генерируется на основе вашего продукта и уточняется обычным языком, шаги описывают намерения, поэтому косметические изменения их не ломают, а навык проверки устанавливается в тот агент для написания кода, которым вы уже пользуетесь, — и цикл замыкается там, где идёт работа.
За вами остаётся тот самый потолок, описанный выше: решать, что считать правильным для неоднозначного правила. Всё, что ниже, сдвигается, и выигрыш в том, что покрытие перестаёт упираться в то, сколько тестов человек успевает написать.
Какой уровень реалистичен сегодня?
Второй; третий — для изменений поведения, а четвёртый в узком виде — для дефектов с понятным воспроизведением.
Означает ли автономность, что людей понадобится меньше?
Она означает другую работу. Механическая половина сокращается, а половина, где нужны суждения, и становится работой.
Как понять, что это не просто генерация шума?
Прочитайте план, вырежьте то, что не имеет значения, и измеряйте пропущенные дефекты, а не количество тестов.
Что ломается на третьем уровне?
Намеренные изменения. Переработанный сценарий выглядит точно так же, как регрессия, пока кто-то не скажет обратное.
Безопасен ли замкнутый цикл?
Для поведенческих дефектов с понятным воспроизведением и проверкой, про которую вы убедились, что она умеет падать, — да. За этими пределами это оптимизм.
Лестница, а не выключатель.
Автономное тестирование программного обеспечения тянется от написания тестов с помощью ассистента до замкнутого цикла, и большинство продуктов находятся на уровне сгенерированного покрытия. Человеческая работа поднимается по лестнице, а не исчезает, и ни один уровень не избавляет от необходимости решать, что считать правильным.