Должен ли QA отчитываться перед развитием?

Ответ 1

Лично - я не думаю, что орг. диаграмма имеет значение, если у вас есть хороший, этичный и честный менеджер.
Аргумент о том, что "R & D Manager" может оказать давление на людей QA, чтобы делать/сообщать о некоторых вещах, верно. У вас также может быть менеджер QA, который любит сгибать мышцы и доказывать свою точку зрения. У вас также может быть 2 отдельных отдела, и если у вас плохой менеджер, у вас все еще могут быть проблемы или люди подвергаются давлению, чтобы "подстроить" вещи. Любой способ, которым вы его разрезаете, может оказаться в конечном итоге с политическим и политическим BS, что приводит к плохим выпускам.

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

Ответ 2

Совсем наоборот. Развитие должно отчитываться перед ОК.

Если вы представляете, что отдел QA будет вашим клиентом (обратите внимание: QA, а не тест), то вы сделаете очень хорошо. Ошибки будут исправлены, продукты будут развиваться в соответствии с хорошими стандартами, разработка поймет, что они предназначены для обслуживания бизнеса и продуктов кода соответственно.

Тем не менее, политика компании дает старшинство другим способом, поэтому в целом развитие становится более старшим по сравнению с отделом QA меньшего размера, если у вас есть отдел QA вообще.

EDIT: небольшое добавление, чтобы объяснить себя: в одной компании, в которой я работал, у нас был "модельный офис", который был создан как сайт клиента. Мы построили компакт-диск установщика и доставим его команде QA, которая установит ее на чисто восстановленный набор машин. Если бы у него были какие-то проблемы, это должно быть сообщено нам, и нам нужно будет исправить это (очевидно, в зависимости от серьезности ошибок), прежде чем создавать еще один компакт-диск и повторять этот процесс. Сначала я подумал: "Это будет ад", и это было... но только на пару итераций, затем разработчик получил сообщение и убедился, что эти компакт-диски работали, и программное обеспечение, которое оно установило, работало.

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

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

Ответ 3

Эквивалент. Цели должны быть одинаковыми - выпуск качественного программного обеспечения. Без открытого обсуждения между равными это не может произойти.

Ответ 4

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

Если, с другой стороны, это технологический отдел в целом, то они могут быть равны, поскольку оба подчиняются Директору или CIO или CTO, где решение о распределении ресурсов осуществляется путем балансирования потребностей обеих групп для достижения большей цели.

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

Интегрируйте его как часть команды разработчиков.

Создают ли разработчики автоматизированные тесты дыма для всего, над чем они работают, и qa дополняют/сотрудничают с ними. Это не то, что qa отчитывается перед развитием или наоборот, но сотрудники, выполняющие роли qa, находятся в одной лодке, чем те, которые делают развитие.

Помните, что для автоматизации тестирования требуются навыки разработчика, а обычные дистрибутивы для разработчиков/качество не соответствуют.

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

Ответ 8

Ваш вопрос кажется неоднозначным; Я отвечаю на то, что остальные ответы не адресуют: Должны ли лица, проводящие тестирование, руководителям без QA? У этого есть ответ, и ответ: "Отдел QA должен быть независимым и мощным, он не должен отчитываться перед командой разработчиков. Фактически, глава QA должен обладать правом вето на выпуск любого программного обеспечения, которое не отвечает требованиям дембеля". "Лучшие пять (неправильные) причины, по которым у вас нет тестеров" Джоэл Спольский (http://www.joelonsoftware.com/articles/fog0000000067.html)

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

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

Ответ 9

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

В качестве гейткипера конечного продукта отдел QA нуждается в автономии и полномочиях, чтобы объявить что-то неполное или неприемлемое. QA должен "держать вещи реальными".

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

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

Ответ 10

Фокус вашего вопроса немного смешанный. Это касается структуры компании и организации отделов? Или о организации проекта?

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

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

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

Ответ 11

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

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

Ответ 15

QA должен сообщать, что DEV ошибочен и не принимается в любом случае. Dev никогда не может нести ответственность в случае отказа в Производственной среде. Почему они должны отчитываться перед QA, почему бы не наоборот? В конце концов, они несут ответственность за предоставление функциональных требований в соответствии с требованиями клиента. Увидеть продукты с точки зрения клиента является основной задачей QA. В случае, если что-либо потерпело крах/не удалось в здравом рассудке, они несут ответственность за доставку неполного/незрелого продукта. Тем не менее это традиционный подход.

После появления Agile-методологий QA и Dev должны работать бок о бок в рамках менеджера по разработке продукта или QA, а Dev может иметь отдельные главы, но работать для одной и той же повестки дня, которая представляет собой полнофункциональный продукт в соответствии с требованиями клиента.