За 10 лет в QA я заходила на проекты, где процессы не «не были настроены» - их не было вообще. Задачи прилетали от разработки, тестировали по задачам, требования жили кто где: на одном проекте - в задачах, на другом - в Confluence. Решения принимал РП. И все выживали как могли. 😅

Расскажу, как я это чинила.

1. Сначала - аудит, не реформы. Я не бегу внедрять. Сначала смотрю: что уже есть, к чему команда привыкла, что реально болит. Слушаю ретро. Внимательно. Потом анализирую: если появится вот это - что изменится? И только потом «прощупываю почву»: как к этому отнесётся РП, заказчик, команда.

2. Иду по чек-листу. Когда меня зовут именно «наладить процессы» - у меня есть план. Сбор текущих данных, сбор того, что куплено заказчиком, сбор того, что было бы хорошо внедрить. Без этого - пальцем в небо.

3. Начинаю с боли, а не с красоты. Если у команды болят баг-репорты - иду туда. Если непонятно, как тестировать - внедряю тест-кейсы и базу знаний. Описывать «как надо тестировать» - хорошо. Но если люди тонут в передаче багов, сначала спасаю там.

4. Убеждаю, а не продавливаю. Через «почему это поможет проекту не утонуть», «чем это облегчит жизнь тебе и команде». Был РП, который говорил: «Бюджета нет, просто протестируйте без лишнего». Мы договорились на минимальные процессы. В итоге команда пользуется ими до сих пор - и пошла дальше улучшать. Это ли не успех? 😊

5. Если не идет - переделываю. Я не сдаюсь, но и не ломаю через колено. Либо я убеждаю, либо меня убеждают. Всегда находим компромисс. Был случай: согласовали с заказчиком регламент автоматизации, даже план утвердили - а потом заказчик отказался от автоматизации. Бывает. Идем дальше.

6. Процессы - не бюрократия. Они нужны, чтобы работа была прозрачной: кто что ждет, какие договорённости, где доказательства. Особенно когда заказчик или РП любит менять правила на ходу. И особенно - чтобы новый тестировщик не тонул в первый день.

Что изменилось? Работа стала понятнее и прозрачнее. Хуже стало только одно: РП захотели ещё больше процессов. 😄

QA-лиду, который заходит на проект без процессов, совет простой: посмотри, что реально поможет лично тебе и команде. Выслушай людей. Начинай с их боли, а не со своих красивых схем.