Комментарии 11
А ждать в будущем открытого репозитория или какого-нибудь лайв-демо всей этой штуки?)
Какая же жиза — собирать по крупицам информацию для тест-кейсов из разных источников... Вы проделали огромную работу. Это хороший пример того, как правильно использовать ИИ, когда он не замедляет инженера, как в большинстве случаев, а наоборот бустит
Сложность ревью — LLM может нагенерить тестов быстрее, но не увеличилась ли нагрузка на ревью из-за необходимости перепроверять бред и неочевидности?
Отличный момент! Я бы не сказала, что время ревью увеличилось, раньше я смотрела проверки человека, а теперь ИИ…который пишет не хуже, если правила и требования полные (что обеспечиваем). Для этого долго и муторно прорабатывали промт и подход, чтобы результаты стали стабильными. Так, несколько раз улучшали промт, пришли к подходу с такс-листом, а не сразу напрямую генерируем проверки.
Ок, возможно, стало быстрее. Метрика "время" стала лучше. А с остальным как? Не говорите об улучшении покрытия, количестве багов до/после, снижении ошибок в тесте. Как понять то?
Говорится:
Недостаточное покрытие и ошибки
Это естественный риск при использовании ИИ. Для его снижения мы используем поэтапное ревью — таск-листы, ре-ревью проверок, своевременный анализ покрытия и наличия ошибок — и закладываем исправление и дополнение в случае необходимости.
То есть хрен его знает стало ли глобально быстрее и лучше. Да и проблема с рутиной, де факто, не ушла, а видоизменилась. Раньше тратили время на написание кейсов, теперь тратим время на ревью. А ведь, по хорошему, чтобы проревьюить тест нужно в ТЗ вникнуть, макеты посмотреть...
Ведь шаг "Нажать на кнопку корзина" звучит понятно, но по факту на этом этапе такой кнопки может и не быть, ИИ вполне мог её выдумать.
А чтобы вникнуть в ТЗ нужно много времени. И это, опять же, не очень весело.
Спасибо за комментарий! Вероятно не удалось донести, что мы сокращаем не просто написание проверок как есть, а целый процесс:
Сокращаем ручное «Написание проверок ручным QA, ревью проверок другим QA, актуализацию проверок после ревью первым QA, финализацию решения»,
получая вместо этого лишь остатки ручного: «Ревью проверок QA, финализацию решения QA».
Анализ требований и дизайна никуда не ушел, и пока остался в ручном режиме. Поэтому QA полностью погружен в фичу, знает детали, и в новом подходе он намного быстрее получает план тестов и будущую их реализацию, да и ревью выполняется намного быстрее, чем само написание и создание задач в tms.
Отличный вопрос про покрытие! Здесь все осталось, как и было, благодаря тому, что мы оставили процесс ревью. То есть финальный вариант решения остается на том же уровне, что и был.
Мы сокращаем ручное «Написание проверок ручным QA, ревью проверок другим QA, актуализацию проверок после ревью первым QA, финализацию решения», получая вместо этого лишь остатки ручного: «Ревью проверок QA, финализацию решения QA», но именно это и важно при отслеживании качества и самого покрытия.
Но для полного перехода и достижения доверия с ИИ - вопрос отличный, и нужно будет думать шире, что и собираемся дальше делать!
А почему не сделали хоть какой-то ui? Даже простейший дашборд помог бы управлять генерацией и снизить порог входа.
Рутину — ИИ, исследование — людям: новая реальность Surf QA