Вроде бы очевидная вещь: задачи, попадающие в команду, должны быть взвешены и проверены (провалидированы) product-менеджерами, а затем «спущены по иерархии вниз», где команда, полная мотивации и с горящими глазами, подхватывает и воплощает в жизнь идеи бизнеса. Но что, если получившийся продукт, функция или сервис оказываются совсем не тем, что ожидалось? Кто виноват? Product-менеджер, неправильно или недостаточно ясно сформулировавший желание бизнеса? Аналитики, которые неверно интерпретировали описанные гуманитарным языком задачи на техническом языке? Разработка, сделавшая всё по-своему, потому что язык/фреймворк/архитектура/<подставь свое> не позволяют? QA, которые не провели или провели недостаточно хорошее тестирование требований и самого продукта? На самом деле, список вопросов можно продолжать и дальше, добавляя сюда CTO, CPO, SBP и много других не всем понятных аббревиатур. В итоге проигрывает продукт, не приносящий ценности конечному пользователю и теряющий свою репутацию. Помочь решить проблему могут следующие процессные подходы: 1. Приёмка задач, приходящих от бизнеса. Это может быть как простой процесс приёмки задач со стороны аналитиков/QA, так и процесс discovery с привлечением enterprise- и solution-архитекторов. 2. PBR-ы с вовлечением всей команды, т. к. порой замечания могут быть от рядовых специалистов, которые «варятся» в этом каждый день. 3. Тестирование требований. На самом деле этот процесс далеко не простой, т.к. отрывает QA-инженеров от самого тестирования зачастую «горящих» фич. Да и в целом, встроить процесс тестирования требований в классический флоу разработки (аналитика -> разработка -> тестирование) достаточно сложно: нужно обосновать людям пользу, которую они от этого получают. Вариант с ранним написанием тестовой документации, к сожалению, не работает, потому что после готовности продукта тестовую документацию, скорее всего, придётся переписывать или дописывать. 4. Приёмочное тестирование. Пожалуй, самый важный процесс, который критически важно внедрить для исключения ситуаций, описанных в начале поста. Причём чем раньше оно будет проведено, тем лучше. Знаю много случаев, в том числе на собственном опыте, когда позднее приёмочное тестирование сильно влияло на регресс. Само собой, есть и другие инструменты для достижения результата, но соблюдение вышеперечисленных процессов позволит существенно повысить качество продукта.

P. S. Как бы банально ни звучало описанное в посте, нарушается это сплошь и рядом.

#планирование #agile #qa #процессы #тестирование