И люди, и техника несовершенны. Люди допускают ошибки, а техника сбоит и ломается. Но разве допустимо только на основании этих фактов разводить руками и аргументировать инциденты в стиле "такое бывает"? Взять тот же жёсткий диск. Можно использовать не 1 диск, а RAID-массив, и тогда выход диска из строя не принесет потерю данных. А можно сделать кластер серверов. А можно настроить резервирование данных. То есть построить систему таким образом, чтобы выход из строя узла или агрегата не вызвал нарушения работы системы, либо хотя бы имелась возможность восстановления.

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

Однако ошибки могут быть связаны не только с вновь реализованной функциональностью. Возникают ситуации, когда для реализации новой функциональности необходимо не реализовать новые объекты/функции, а модифицировать уже имеющиеся. При этом они могут быть модифицированы таким образом, что новая функциональность будет работать, а в уже имеющейся будут возникать ошибки.

Именно поэтому тестировщик должен проверять не только созданную в рамках задачи функциональность на соответствие постановке, но и функциональность, связанную с модифицированными (измененными) в ходе разработки объектами системы. Как несложно догадаться, для этого в постановку должны быть внесены и вновь созданные объекты ИС, и модифицированные объекты ИС (с конкретикой по изменениям).

Более того, тестировщику должна быть предоставлена не только постановка задачи, но также он должен иметь доступ к материалам, содержащим:

- описание автоматизируемого бизнес-процесса, причем не только тех бизнес-функций, для покрытия которых разрабатывается функциональность, а ко всему БП, так как заранее предугадать, что может быть поломано при разработке новой функциональности, возможности нет;

- детализированное описание требований (опять же, потому что заранее нельзя знать, что поломается при разработке);

- ранее созданные постановки задач (потому что может так статься, что новая функциональность затрагивает объекты, разработанные в рамках предыдущих спринтов).

Таким образом, чтобы получить качественный результат, нужно его качественно описать, выполнить работы по реализации и проверить на соответствие. Хочется передать особый привет тем, кто рассуждает "мне не нужен процесс, мне нужен результат". Видите ли, уважаемые, наша вселенная, к сожалению, построена так, что в ней отсутствует магия. И для того, чтобы дать вам результат, надо и выстроить не кривой процесс, и обеспечить исполнителей ресурсами и материалами, и проконтролировать результат. Без этого, к сожалению, в реальном мире никак.

Полностью цепочка этапов разработки - здесь. Полный перечень результатов по этапам проекта - здесь.