Нейросеть для тестировщика помогает накидать тест-кейсы, граничные случаи и баг-репорт. Исследование, оценка и проверка остаются за тестировщиком.
Е
Евгений
Эксперт по профессиям LibraChat
7 мин чтения
Большая часть работы тестировщика выглядит со стороны скучно: на каждую фичу надо расписать десятки проверок, перебрать очевидные сценарии, оформить найденное в аккуратный баг-репорт. Эта рутина съедает время, которое хочется тратить на настоящую охоту за хитрыми дефектами, а не на выписывание того, что очевидно. Я стал подключать нейросеть для тестировщика не затем, чтобы она тестировала за меня, а чтобы скинуть на неё черновую часть: накидать базовый набор тест-кейсов, подсказать граничные случаи, причесать формулировку бага. Когда машина закрывает очевидное, у меня остаётся голова на то, что она не умеет: на исследование, чутьё, проверку руками.
Сразу про рамку, в этой профессии она важна: машина накидывает варианты и оформляет, но проверять, оценивать риск и отвечать за качество буду я. Она не запускает продукт, не видит реального поведения, выдумывает шаги и спокойно пропускает неочевидный дефект, потому что про него не написано в требованиях. Поэтому её кейсы я беру как заготовку и опору для памяти, а не как готовый план тестирования. Дальше расскажу: почему ручной перебор выматывает, что я отдаю машине, как прошу собрать кейсы, где она подводит и что остаётся за тестировщиком. Расклад тут такой: рутину перебора и оформления машине, а исследование, оценку риска и решение о релизе себе.
Почему ручной перебор кейсов выматывает
Объясню, в чём ловушка работы. На любую функцию приходится продумать кучу проверок: позитивные сценарии, негативные, граничные значения, пустые поля, неверные форматы, поведение при сбое сети. Половина из них однообразна и предсказуема, но пропустить нельзя ни одну, ведь дыра обычно прячется именно в скучном месте, которое поленились проверить. Эта дотошность необходима, но она же быстро притупляет внимание, а ведь именно внимание это главный инструмент тестировщика.
Беда в том, что на десятой однотипной проверке глаз замыливается, и легко не заметить пробел в покрытии. Машина тут полезна как генератор полноты: я описываю функцию и требования, а она быстро разворачивает их в список кейсов, включая те негативные и граничные варианты, о которых под конец дня забываешь. Это не готовый набор к исполнению, а каркас покрытия: из него я выкидываю лишнее, дополняю специфику системы и расставляю приоритеты. Базовый список она собирает за 5 минут, тогда как вручную я бы выписывал его долго и с риском что-то упустить. Особенно это выручает на старте задачи, когда страшно не неизвестное, а именно банальное: легко с головой уйти в хитрый сценарий и забыть проверить пустое поле или нажатие кнопки дважды. Машина закрывает этот базовый слой ровно и без усталости, а я уже сверху достраиваю то, до чего она не додумается. По сути, она гарантирует, что фундамент покрытия заложен, и освобождает меня для верхних этажей.
Часть работы тестировщика это не охота за хитрыми багами, а монотонная выписка очевидного и приведение находок в порядок. Вот её я и передаю машине, чтобы беречь внимание для исследования.
О чём прошу машину · Что получаю
Черновик тест-кейсов — базовое покрытие функции
Граничные случаи — подсказку, что ещё проверить
Негативные сценарии — варианты «что сломать»
Оформление баг-репорта — чёткую формулировку из моих заметок
Тестовые данные — наборы значений для проверки
Сгенерированный список я не гоняю как есть, а прохожу своей головой: выкидываю неприменимое, дописываю кейсы под реальную логику системы, проверяю, что покрытие не дырявое. Машина даёт полноту и оформление, а исследование, оценку, проверку беру на себя. И граничные случаи всё равно додумываю сам, ведь самый злой баг обычно там, где не было ни требований, ни очевидного сценария. Машина мыслит по написанному, а дефекты живут в зазорах между написанным: на стыке двух фич, в странной последовательности действий, в том, что пользователь сделает не по инструкции. Эти зазоры видит только тот, кто держит в голове всю систему и нарочно ищет, где она хрупкая, а такой настрой ни в один промпт не вложишь.
Как я прошу нейросеть для тестировщика собрать кейсы
Расскажу свой обычный порядок. Сперва даю контекст: что за функция, какие требования, какие есть ограничения и роли пользователей. Прошу не «протестируй», а конкретное: сначала список тест-кейсов по сценариям, отдельно граничные значения, отдельно негативные проверки. Дробный запрос даёт управляемые куски, которые легко просмотреть и проверить по очереди, в отличие от сплошной простыни, где глаз скользит и пропускает пробелы в покрытии.
А дальше работаю сам:
Прошу каркас, не вердикт. Список проверок, а не оценку качества.
Отсекаю неприменимое. Выкидываю кейсы, что не про нашу систему.
Достраиваю граничные. Злые случаи додумываю своей головой.
Проверяю руками. Реальное поведение вижу только в запуске.
Конкретный контекст работает лучше общего «придумай тесты»: на пустом запросе машина выдаёт шаблонные кейсы без учёта реальной системы. Помню, как однажды взял её список не вычитав, а половина шагов ссылалась на кнопки, которых у нас нет, с тех пор каждый кейс сверяю с продуктом. Перебор и оформление я доверяю машине, а исследование и оценку держу за собой, ведь подписываю готовность к релизу я, а не чат. На бумаге кейс выглядит пройденным, а реально работает только то, что я прогнал руками и увидел своими глазами.
Где нейросеть для тестировщика подводит
Назову, где машина не помощник, а ловушка, и где доверять ей нельзя.
Реальное поведение. Что происходит при запуске, видите только вы.
Неочевидный дефект. Баг вне требований машина не предскажет.
Финальное решение. Выпускать ли фичу в релиз, решаете вы, не чат.
Сведу к сути: машина накидывает каркас кейсов, граничные, негативные варианты, оформляет баг-репорты, а исследование, оценка риска, проверка руками и решение о релизе остаются за тестировщиком. Я зову её, чтобы не выгорать на однотипном переборе и быстро оформлять находки, а не чтобы она решала, готов ли продукт. И помню главное: качество подтверждается запуском и чутьём, а не длиной списка кейсов, поэтому за то, что уйдёт к пользователю, отвечаю я.
Что остаётся за тестировщиком
Машина сильна на переборе и оформлении, но тестирование это про исследование, а исследует человек. Заподозрить, что вот здесь разработчик наверняка ошибся, пойти проверить сценарий, которого нет ни в одной спецификации, воспроизвести плавающий баг, оценить, насколько находка критична для бизнеса, может только тестировщик, который думает как враг системы и видит её живьём.
Раньше я тратил уйму времени на выписывание однотипных проверок и подходил к настоящему исследованию уже подуставшим. Теперь рутину держит машина, а свою энергию я вкладываю в то, что её не заменишь: в поиск дыр там, где их не ждут, в воспроизведение и в оценку рисков. Помню, как именно свежая голова на исследовании помогла поймать дефект на стыке двух фич, которого не было ни в каких требованиях и который машина в кейсы не внесла. Получается, машина забрала черновую часть, а саму суть профессии оставила мне. И ценность тестировщика от этого только растёт: команде нужен не тот, кто умеет аккуратно переписать требования в кейсы, это и машина может, а тот, кто думает как враг системы и находит то, о чём никто не подумал. Освободив время от рутины, я как раз и могу вкладываться в это умение, а не выгорать на копировании очевидного.
Соберите кейсы, проверьте сами
Если вы вязнете в выписывании однотипных проверок и оформлении баг-репортов, а на настоящее исследование уже не остаётся свежести, не расписывайте однотипную рутину вручную, а отдайте её машине и сберегите внимание для настоящей охоты за дефектами.
Во сколько обойдётся такой помощник для работы, показано в разделе с ценами. Откройте LibraChat: опишите функцию и требования и попробуйте получить черновик тест-кейсов, а исследование, проверку, решение оставьте за собой. Рядом пригодится разбор, как нейросеть помогает редактору: там тоже про поиск дефектов и проверку, только в тексте, а не в продукте.
