​От компании к компании узнаёшь всё больше компонентов хорошей разработки. На последнем месте работы я увидел очень интересную вещь - отдел тестирования с грамотным руководителем вполне может нивелировать плохое руководство как в менеджерских решениях, так и в отделах разработки.

Я работал в команде, где был старый легаси-проект. Из-за неверной архитектуры и плохих решений ("ща быстро сделаю, а на следующей неделе -перепишу" - типичный комментарий под 5-ти летним коммитом) каждое изменение могло уронить сайт. Тесная связь модулей, где каждый метод может быть дублирован в другом месте, а контекст вокруг метода не всегда позволяет разобраться что это именно он - основной критерий ошибок. И, как это обычно бывает, бизнесу нужны задачи, времени на рефакторинг или распутывание старого кода тебе никто не даёт.

Именно на таких проектах свою роль начинает играть команда тестирования. Прежде я работал с тестировщиками, но чтобы проект тестировали так слаженно -ещё не видел.
Думаю, полезным будет рассказать этапы тестирования и флоу вокруг тестирования глазами разработчика, потому что как показывает практика - в подавляющем большинстве компаний этому уделяется очень мало внимания.
Первый этап - разворачивание проекта не тестовом стенде. Тестовый стенд - это сервер по окружению повторяющий боевой, но привязанный к определённой ветке. Я, закончив задачу, кидаю PR, PR ревьювится кем-то из команды. В нашем случае это всегда был тимлид, и частенько ревью превращалось в перекрёстное, вкупе с другими разработчиками. После получения апрува - код заливается на ветку, привязанную к тестовому стенду, после чего задача уходит в статус "Тестирование".

Когда тестировщик берёт эту задачу, в задаче мной должны быть описаны приёмочные критерии и указана ссылка на тестовый стенд. Приёмочные критерии - это краткое описание того, что задача решает и какое поведение тестировщик должен ожидать при тестировании.
Помимо этого было правило - все неочевидные моменты описывать вложением к задаче, в идеале так, чтобы при тестировании у тестировщика не возникало вопросов, как решать тот или иной момент. По-началу с этим спорили, пока не поняли, что такое описание сэкономит разработчику гораздо больше времени и нервов, нежели чем полчаса отвечать на вопросы в слаке.

Закончив тестирование либо будут описаны моменты, которые вызвали вопросы и задача уйдёт на доработку, либо задача будет переведена на выкладку в dev. dev - это среда, почти дублирующая боевую, за исключением пользовательской нагрузки. После выкладки задача тестируется на dev-среде, и после релизится на боевой сервер.

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

Свой стек приёмочных выполнялся на dev-среде, где нестрашно что-то уронить или затереть пользователя в базе, и свой стек приёмочных был на бою - где тестировались только те элементы, которые не влияют на пользователей. На моём проекте было порядка 5-10 тысяч тестов, которые алертили и били во все колокола в случае, если что-то пошло не так, что позволяло быстро решать проблемы. Вкупе с Unit и интеграционными тестами, что писали мы, это позволяло держать прод в стабильном рабочем состоянии.

При этом как бы не требовал бизнес - выкладка массива задач с dev на prod никогда не производилась без окончания тестирования, и к отделу тестировщиков бизнес вопросов не имел - как дотестируем, так и выложим.

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