Кто отвечает за качество?

Исходя из названия профессии “QA Engineer”, логично предположить, что QA и является тем, кто отвечает за качество продукта. Я как QA не совсем согласен с этим.

Sonderupgaard

QA может оказать большое влияние на качество. Конкретно в наши задачи входит следующее:

  • Тестирование требований. Необходимо проверять, что требования к продукту однозначны, достаточны и не противоречат друг другу;
  • Системное тестирование;
  • Автоматизация системного тестирования;
  • Создание и поддержка тестовых артефактов: тест плана, тестовых наборов, тест-кейсов, дефектов и т.д.;
  • Составление отчетов о тестировании;
  • И другие рутинные функции, в основном не имеющие прямого отношения к качеству;

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

  • Следование целям бизнеса. Команда разработки может потратить колоссальное количество времени на имплементацию, тестирование и доведение до совершенства какой-либо части функциональности. Однако, это время будет потрачено впустую, если эта функциональность никому не нужна. В связи с этим в команде должен быть человек, который понимает специфику бизнеса и может помочь команде разработки делать продукт, который действительно найдет своё применение. Как правило, этот человек – бизнес-аналитик;
  • Качество кода. Несмотря на то, что многие QA сейчас умеют писать код, оценка качества кода – задача, с которой могут справиться только разработчики. Это связано с тем, что кроме знания ЯП для корректной оценки необходимо понимание архитектуры приложения и знание используемого инструментария;
  • Рефакторинг. Разработка продукта в agile-like иногда приводит к тому, что код, отлично работавший раньше не может быть расширен для поддержки новой функциональности. В этом случае, существующий код должен быть переработан. Только разработчики могут донести до команды необходимость такой переработки;
  • Приоритизация. Обычно за время спринта нужно имплементировать как можно больше новой функциональности. Из-за этого тестирование, исправление существующих багов и рефакторинг могут оказаться активностями второго приоритета. Это, в свою очередь, может привести к ситуации, когда новая функциональность имплементируется на основе старого кода, который содержит баги или просто не может быть корректно расширен. Имплементации новой функциональности, в таком случае, делает исправление старой кодовой базы более трудоёмким из-за создания дополнительных зависимостей. Единственным путем решения подобных трудностей является правильная приоритизация задач, которая в свою очередь может быть достигнута только путем коммуникации внутри команды.

Кроме этого, наверняка, есть и другие факторы специфичные для определенного процесса разработки или даже определенного проекта. Эти примеры показывают, что качество может быть достигнуто только если каждый участник процесса разработки заинтересован в этом. Так что, качество – задача каждого.