Должен ли QA быть частью отдела разработки?

Я работаю в небольшой компании, в которой уже давно есть отдел разработки продуктов. Однако у нас не было группы QA / тестирования.

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

Наша компания примерно структурирована следующим образом:

• Генеральный директор
  • технический директор
    • Директор по развитию продуктов
    • Директор по работе с клиентами
      • Разработчики
    • VP операций
      • Сетевые инженеры
  • Инженеры по продажам / продажам
  • президент
    • контроллер

Да и нет :)

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

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

Мы создали его так, что «Разработка продукта» - это «виртуальный» отдел, созданный двумя конкретными отделами: QA и Development. Оба подчиняются одному и тому же члену команды управления: CTO. Это гарантирует, что за продукт отвечает один человек (наш технический директор) и что QA и разработка независимы друг от друга.

Это действительно зависит от того, насколько серьезно ваша фирма занимается QA. Например, вы будете заниматься разработкой на основе тестов?

Вы упоминаете «группу тестирования», это может предложить несколько человек. Если это группа из нескольких человек, то, вероятно, это должен быть отдельный отдел. Что меня удивляет, так это то, что у вас есть хотя бы один человек, посвященный тестированию и тестированию? Если нет, планируете ли вы быстро создать новую группу? Если это так, то это будет существенная организационная трансформация и может вызвать серьезные трения с вашими текущими разработчиками, которым также необходимо изменить способ их работы.

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

Однако у нас не было QA ...

Там было сделано моё искреннее соболезнование. Хорошо, учитывая выше, я бы сказал, что получение тестера (ов) будет намного лучше, чем у вас сейчас, независимо от того, в каком отделе они будут приземляться.

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

Я принимал участие в двух выпусках, которые были недопустимы с точки зрения контроля качества - один раз как тестер, другой как разработчик. В обоих случаях я думаю, что наличие отдельного отдела обеспечения качества было весьма полезным.

Насколько я могу судить, когда тестеры находятся в отдельном отделе, становится все труднее скрывать проблемы с качеством продукции за фальшивым «согласованием команды» . Это помогло всем ясно понять, что мы выпускаем и почему. Это, в свою очередь, помогло управлять ожиданиями клиентов и планировать дальнейшее развитие.

Почти во всех случаях QA должен быть отделен от разработки. Хотя цель между обоими департаментами одна и та же (выпуск качественных продуктов / решений), QA должно чувствовать, что у них есть разрешение на исправление и внесение предложений по продуктам с развитием, и чтобы они были на равных. Если глава QA отчитывается непосредственно перед руководителем разработки, это может привести к тому, что QA сделает шаг назад и окажется во власти разработки (и, следовательно, неуклюжий код / ​​продукты будут запущены в производство).

Зависит от используемой вами методологии разработки: если вы делаете Agile / Lean, то Agile Testing может быть подходящим способом, и поэтому он должен быть близок к разработчикам.

Из того, что вы говорите, у вас довольно маленькая компания. Для меня имеет смысл использовать этот размер и способность общаться, пока вы можете, прежде чем вы станете больше. Это подразумевает сохранение их с развитием.

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

Теперь я также был бы уверен, что первые несколько позиций QA будут позициями SDET ... т.е. тестеры с кодировкой отбивных. С самого начала включите вашу автоматизацию, работайте и работайте стабильно.