Этот пост про релизные процессы от discovery до готовности к внедрению изменений. Про discovery писал тут https://set.ki/post/mT75WSh Я не буду вдаваться в теорию, так как всё это есть на просторах интернета и в книгах, а больше опишу своё субъективное мнение и отношение к некоторым аспектам.

Во-первых, работа аналитиков и составление технической документации. К сожалению, крайне недооценённый этап разработки ПО, на который «забивают» даже в компаниях с критически важными сервисами. В большинстве случаев нет стандартов ведения документации, шаблонов технических спецификаций (ТС), ревью разработанных ТС. Само собой, это приводит к хаосу и огромному количеству багов в будущем. Да, в краткосрочной перспективе это даёт свои преимущества в скорости разработки, и, к сожалению, менеджеры этим активно пользуются. Но если задать такой вектор, то исход всегда будет плачевным, исправить это уже не получится. Останется лишь работать с тем, что есть, и тушить пожары по мере их поступления (а они будут появляться регулярно). Кстати, популярный подход shift-left в тестировании в таком случае совсем не применим. Это превращается в сущий кошмар для QA, потому что приходится проводить двойную работу: готовить тестовую документацию во время разработки ТС и затем актуализировать её (или зачастую переделывать) уже во время тестирования.

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

Следующий этап — тестирование. Опять же, не углубляясь в теорию, обязательно - составление тестовой документации: тестовые кейсы и чек-листы, а также добавление тестирования нового функционала в тестовый план регресса (при необходимости). Если у вас Jira, то чек-листы очень удобно вести в самой задаче на изменение или в сабтаске, открытой для тестирования. Затем с помощью запросов можно достать нужные проверки на тот же регресс и соединив с имеющимися ТК получить полноценный тест-план.

Кроме того, необходимо оформлять дефекты на выявленные ошибки в работе ПО, чтобы эффективно оценивать воронку багов и дефектов (думаю, для этой темы потребуется отдельный пост).

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

А далее изменения почти готовы, и мы подходим к финальным процессам: релизным комитетам, pre-deliver, самому внедрению и ретроспективному анализу прошедшего релиза.