Недавно мы сидели с коллегами вечером в каком-то ресторанчике в Париже и обсуждали миссию DevOps и QA инженеров на проектах.
"QA должен так описать багу, чтобы, прочитав это описание, разработчик не только сразу понял в чем проблема, но и захотел это тут же исправить" (С) Я.
Чтобы так описывать баги, QA инженер должен отлично понимать как работает проект, чтобы разработчик проникся описанной проблемой, а не тратил время и силы на "перевод" с языка QA на язык разработчика и многочасовые попытки воспроизвести описанную проблему.
Миссия QA инженера на проекте - это обеспечить создание качественного программного обеспечения, всеми средствами. Сюда относится и наличие правильного CI/CD, и создание особой культуры разработки (как, например, "не релизим в пятницу вечером" или "изменения в коде должны пройти ревью как минимум двух инженеров кроме самого автора кода") и многое другое, но вот о чем многие из нас частенько забывают - QA должен понимать как работает проект и каждый его компонент изнутри и как это выглядит для обычного пользователя снаружи. Эти знания нужны нам, чтобы создавать адекватные тесты и понимать результаты проводимого тестирования, эти знания нужны нам чтобы с легкостью общаться с командой разработчиков, менеджерами и командой поддержки.
