Должен ли QA отчитываться перед разработкой? [закрыто]

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

Интегрировать его в состав группы (групп) разработчиков.

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

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

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

I guess it depends a little on what QA actually does. In the very typical scenario where QA's mission is to provide lack of errors (and only indirectly (hopefully) improve quality), then I think that having them equal is the best option. If QA on the other hand really had improving quality as the primary mission, then I think I agree with gbjbaanb that development should report to QA.

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

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

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

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

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

Equivalent. The goals should be the same - release of quality software. Without an open discussion between equals, this cannot happen.

Quite the opposite. Development should report to QA.

If you imagine the QA department to be your customer (note: QA, not test) then you will do very well. Bugs will get fixed, products will get developed to good standards, development will realise they are there to serve the business and code products accordingly.

However, company politics gives seniority in other ways, so generally development does become more senior to the smaller QA department, if you have a QA department at all.

EDIT: a little addendum to explain myself: at one company I worked at, we had a 'model office' that was set up as a customer site. We'd build the installer CD and deliver it to the QA team, who would install it onto a cleanly-restored set of machines. If there was problems with it in any way, it's be reported back to us and we'd have to fix it (obviously, depending on bug severity) before building another CD and repeating the process. At first I thought "this is gonna be hell", and it was.. but only for a couple of iterations, then dev got the message and made sure those CDs worked, and the software it installed worked.

My current company needs something like that, feedback from site is through a mailing list, installer often doesn't fully work, sometimes there's missing dependencies, and the same install issues crop up again and again. Quality here is poor in comparison to the QA dept that made sure it worked so well before. Here we have a dev-driven group, they're always focussed on the next release, new features. QA is always concerned about the current release, the existing product. It makes a huge difference to what the end-user gets.

So, even if the QA dept is there to ensure quality is acceptable, I still think it should be treated as if it is the customer that development 'reports' to.

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

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

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

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

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

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

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

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

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

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

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

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

Как привратник конечного продукта, отдел QA нуждается как в автономии, так и в полномочиях, чтобы объявить что-то неполным или неприемлемым. Обеспечение качества должно «сохранять реальность».

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

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

Ваш вопрос несколько неоднозначен. О структуре компании и организации отделов? Или об организации проекта?

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

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