Размышления о миссии QA инженера

  Недавно мы сидели с коллегами вечером в каком-то ресторанчике в Париже и обсуждали миссию DevOps и QA инженеров на проектах.

  "QA должен так описать багу, чтобы, прочитав это описание, разработчик не только сразу понял в чем проблема, но и захотел это тут же исправить" (С) Я.

  Чтобы так описывать баги, QA инженер должен отлично понимать как работает проект, чтобы разработчик проникся описанной проблемой, а не тратил время и силы на "перевод" с языка QA на язык разработчика и многочасовые попытки воспроизвести описанную проблему.

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

Я слышал от многих QA жалобы на то, что разработчики не считают нас профессионалами. Чтобы быть профессионалами, мы должны разобраться в продукте, который тестируем. Мы должны знать все фичи, ревьювить код приложений, участвовать в обсуждениях, общаться с пользователями, предлагать новые фичи.

  Давайте посмотрим еще раз на картинку с котом. Узнаете себя? )

  Я довольно часто слышал такие высказывания:

      "Я потестировал, вроде работает" - так и хочется спросить Что? Что ты потестировал? Что значит ВРОДЕ?

      "Мы провели нагрузочное тестирование. На N пользователях система свалилась" - И? Где результат? Где анализ? Что нам дает информация о количестве пользователей, при котором система не работает? (конечно, что-то дает, но это как раз из оперы "где-то там есть баг")

      "Автотесты работают не стабильно" - они должны работать стабильно, если не работают - переписывайте.

  Возможно, мы и должны быть такими вот котами на проекте, чтобы видеть происходящее под другим углом и делать свою работу, но при этом мы должны постоянно задумываться о том, на сколько мы сами считаем себя профессионалами и на сколько нам нравится результат нашей работы. Можем ли мы, будучи котом, разговаривать с совами? :) Качественное ли программное обеспечение мы выпускаем? Всем ли на проекте понятно какие у нас есть дефекты и как мы это будем исправлять?