У нас уже давно и очень успешно работает AI-агент, который анализирует задачи и формирует чек-листы для тестирования. Учитывает требования, контекст, возможные риски и неочевидные сценарии.

Недавно задумался: а почему мы используем этот подход только для QA?

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

1. Требования. QA анализирует их полноту, ищет противоречия, уточняет сценарии и потенциальные риски ещё до начала разработки.

2. Разработка. Здесь QA практически не участвует. Разработчики реализуют функциональность, проводят технические проверки и code review. Но отдельного механизма проверки полноты реализации с учётом QA-экспертизы у нас пока нет.

3. Тестирование. QA проверяет реализацию, исследует нестандартные сценарии, ищет дефекты и оценивает риски.

4. Релиз. QA участвует в оценке готовности продукта, анализирует оставшиеся риски и помогает принять обоснованное решение о выпуске.

Получается интересная ситуация.

На этапе требований мы помогаем предотвратить ошибки. На этапе тестирования находим их. А непосредственно во время разработки практически не используем накопленную QA-экспертизу.

И мне кажется, это хорошая точка для улучшения.

Ведь в процессе разработки задача может обрастать деталями. Появляются уточнения, дополнительные условия, меняется логика. Разработчик реализует всё по частям, и в конце не всегда просто быстро проверить, что ничего не упущено.

Поэтому сейчас хочу расширить нашего AI-агента.

Помимо подробного чек-листа для тестировщика, он будет формировать короткий чек-лист для разработчика по конкретной задаче.

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

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

Причём подход хотим распространить на frontend, backend и мобильную разработку.

Идея не в том, чтобы QA контролировал каждый шаг разработчика. Наоборот, хочется передать часть нашей экспертизы непосредственно в процесс разработки, сохранив самостоятельность команды.

Сейчас, когда все стремятся оптимизировать процессы и ускорить разработку, важно не забывать одну вещь: можно сколько угодно ускорять тестирование, но если задачи постоянно возвращаются на доработку, мы просто быстрее гоняем их по кругу.

Гораздо интереснее сокращать сами возвраты, а не только время проверок.

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

Для меня здесь главный принцип: качество должно обеспечиваться на каждом этапе, а не становиться ответственностью одной команды в конце процесса.

А как у вас QA взаимодействует с разработкой до передачи задачи на тестирование? Есть какие-то интересные практики?