Хочу начать цикл небольших постов о релизных процессах, которые, как мне кажется, играют очень важную роль в обеспечении качества. Люди, непосредственно не погружённые во все аспекты работы QA, зачастую считают, что QA — это просто тестировщик (ручной, автоматизатор, не имеет значения). Но это не так. Точнее, не совсем так. Если у команды или продукта очень низкий уровень зрелости, то QA там просто тестировщики и зачастую ручные. Но в таких командах и нет зрелых релизных процессов, как и любых других процессов в принципе. Если же говорить об уже устоявшемся продукте, сформированной и зрелой команде, то, безусловно, релизные процессы играют ключевую роль, как и вовлечение всех членов команды, в том числе и QA. Следует также отметить, что, несмотря на развитые инструменты автоматизации, CI/CD и т. п., релизный процесс не ограничивается разворачиванием разработанного ПО в производственной среде. Это множество взаимосвязанных процессов до и после внедрения:

⁃ Процессы эстимации (планирования ресурсов) и дискавери. Я отношу это к релизному процессу как один из пазлов. ⁃ Сбор и анализ дефектов, выявленных в процессе движения задачи от идеи до реализации. ⁃ Сбор и анализ багов, выявленных после внедрения. Выстраивание взаимосвязей между конкретными фичами. Проведение ретроспектив. ⁃ Сопровождение внедрённых продуктов, в том числе инцидент-менеджмент.

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