Всем привет!
Сразу хочу извиниться за некий "поток сознания" на тему, но действительно очень хочется разобраться и разложить все по полочкам с вашей помощью.

Итак, есть два распространенных мнения на этот счет:

1. Тестировщики являются полностью независимым подразделением в организации или, в лучшем случае, подчинены непосредственно менеджеру проекта в обход тимлида
   
2. Тестировщики являются неотемлимой частью проектной команды и подчинены тимлиду (в понимании этой роли, описанной Gaperton'ом
   Автор: Jonathan
   Дата: 01.06.08
   )

Приверженцы первого подхода аргументируют его тем, что, таким образом, обеспечивается полная независимость тестирования от давления менеджмента проекта ("сроки горят, давайте забъем на тестирование и зарелизим, что есть"). С другой стороны, при таком подходе не приходится говорить о кросс-функциональной команде, т.к. команда, по сути, разделена на два "лагеря" — разработчики и тестировщики, с сопутствующими конфликтами, перебрасыванием дерьма через стену и т.п., что отнюдь не в положительную сторону влияет на продуктивность и мотивацию в команде.

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

Я являюсь ярым приверженцем кросс-функциональных команд в НЕортодоксальном смысле (т.е. обязательно содержащих представителей всех дисциплин разработки ПО, но без жесткого требования "все должны уметь делать все") и, поэтому, для меня подход №2 гораздо предпочтительнее. Но — пока не получается найти убедительные аргументы для высшего руководства. Высшее руководство, в свою очередь, склоняется к первому подходу по следующим причинам:

1. "Работает — не трогай" — т.е. в прошлом были проекты, которые вполне успешно делались по "классической" схеме. Хотя, были и очень показательные примеры недостатков такого подхода, вплоть до конфликтов, когда девелопмент лид и тест лид разговаривали между собой только через посредника
   
2. По моим личным ощущениям, высшее руководство, при всем моем к ним уважении, не совсем в курсе современных тендеций к формированию проектных команд (само-организация, отсутствие иерархии внутри команды). И если на само-организации я особо не настаиваю, т.к. не каждая команда к ней, увы, способна, то как минимум на "плоской" структуре команды (пм->тимлид -> все остальные представители всех дисциплин) настаиваю даже очень.
   
3. По моим личным ощущениям, предпочтение первому подходу отдается еще и из-за дефицита по-настоящему зрелых тим лидов, которые бы понимали, что на программировании разработка ПО не заканчивается.

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

Здравствуйте, DmytroL, Вы писали:

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

Если о тех, которые тестируют законченный продукт («кликеры»), такие должны быть совершенно отдельными, и лучше не общаться с программистами вообще. Такие баги отправляются ПМу, он их фильтрует, приоритезирует, оценивает серьезность и т.п., и переправляет тим-лидеру, а он уже смотрит на них с программистской точки зрения и дает задания разработчикам как часть рабочего процесса.

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

Здравствуйте, Аноним, Вы писали:

А>Смотря о каких тестировщиках речь. Если о тех, которые пишут юнит-тесты и другие автоматические тесты, а также утилиты и программные комплексы для тестирования, то они должны быть частью команды и активно участвовать в разработке архитектуры. Это серьезные разработчики, у которых квалификация и зарплата может быть выше, чем у обычных программистов — членов команды. К тому же, для TDD они играют ключевую роль.

Согласен. У нас, например, есть тестировщики в составе команды разработчиков и есть отдел quality assurance со своими тестировщиками, своим багтрекером и проч.

Здравствуйте, DmytroL, Вы писали:

DL>Итак, есть два распространенных мнения на этот счет:
DL>

DL>
1. Тестировщики являются полностью независимым подразделением в организации
   DL>
2. Тестировщики являются неотемлимой частью проектной команды
   DL>

Эти два мнения могут не противоречить друг другу:
Тестировщики входят в состав независимого подразделения и выделяются для выполнения проектных работ.

Здравствуйте, DmytroL, Вы писали:

DL>Всем привет!
DL>Сразу хочу извиниться за некий "поток сознания" на тему, но действительно очень хочется разобраться и разложить все по полочкам с вашей помощью.

А чем конкретно будут заниматься тестировщики в вашем проекте?
Тестируется ли постановка или нет (и есть ли вообще достаточно полная постановка)?
Тесты только автоматические или много ручных?
Делаете коробочный продукт или постоянно обновляемый сайт?
Кто несет ответственность за качество результата (QA или PM или разработка)?

Вот после ответов на подобные вопросы — можно что-то говорить. Так как тестирование — часть жизненного цикла системы, то пока не описать, а что за система — сложно говорить о конкретных реализациях.

Здравствуйте, _Dinosaur, Вы писали:

_D>Эти два мнения могут не противоречить друг другу...

Да не противоречить-то они могут... Но проблема неминуемо возникнет в тот момент, когда тестировщикам придется решать: чьи приказы выполнять — Главного по независимому QA подразделению или Главного по проектной команде?? Возьмем случай, когда приказы этих двух Главных противоречат друг другу. Ась?

Здравствуйте, Аноним, Вы писали:

А>Смотря о каких тестировщиках речь.
**skipped**
А>Если о тех, которые тестируют законченный продукт («кликеры»), такие должны быть совершенно отдельными, и лучше не общаться с программистами вообще. Такие баги отправляются ПМу, он их фильтрует, приоритезирует, оценивает серьезность и т.п., и переправляет тим-лидеру, а он уже смотрит на них с программистской точки зрения и дает задания разработчикам как часть рабочего процесса.

Имелись в виду именно те тестировщики, которые тестируют законченный продукт. И, судя по вашему ответу:

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

идея кросс-функциональной команды неработоспособна в принципе? Но тогда как получается, что она является столь популярной в индустрии уже не первый год?

Здравствуйте, ned, Вы писали:

ned>Согласен. У нас, например, есть тестировщики в составе команды разработчиков и есть отдел quality assurance со своими тестировщиками, своим багтрекером и проч.

Интересно, какие преимущества дает такое дублирование? (не сарказм и не троллинг, действительно интересно)

Здравствуйте, _Dinosaur, Вы писали:

_D>Эти два мнения могут не противоречить друг другу:
_D>Тестировщики входят в состав независимого подразделения и выделяются для выполнения проектных работ.

ОК, кому они, в таком случае, подчиняются? Если руководителю своего подразделения, то как тогда ПМу/тимлиду управлять проектом, если часть проектной команды ему неподконтрольна?

Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>А чем конкретно будут заниматься тестировщики в вашем проекте?
ДФ>Тестируется ли постановка или нет (и есть ли вообще достаточно полная постановка)?

Не уверен, что понимаю, что такое постановка

ДФ>Тесты только автоматические или много ручных?

В большинстве случаев, только ручные.

ДФ>Делаете коробочный продукт или постоянно обновляемый сайт?

Скорее, второе (разработка Веб-приложений под заказ)

ДФ>Кто несет ответственность за качество результата (QA или PM или разработка)?

В конечном итоге — ПМ.

Здравствуйте, Vlad_SP, Вы писали:

V_S>Да не противоречить-то они могут... Но проблема неминуемо возникнет в тот момент, когда тестировщикам придется решать: чьи приказы выполнять — Главного по независимому QA подразделению или Главного по проектной команде?? Возьмем случай, когда приказы этих двух Главных противоречат друг другу. Ась?

В этом случае сотруднику целесообразно эскалировать проблему.
Уведомить двух начальников об отдаче противоречивых приказов. Пусть договариваются.

Здравствуйте, DmytroL, Вы писали:

DL>ОК, кому они, в таком случае, подчиняются? Если руководителю своего подразделения, то как тогда ПМу/тимлиду управлять проектом, если часть проектной команды ему неподконтрольна?

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

Здравствуйте, _Dinosaur, Вы писали:

_D>В этом случае сотруднику целесообразно эскалировать проблему.
_D>Уведомить двух начальников об отдаче противоречивых приказов. Пусть договариваются.

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

Здравствуйте, DmytroL, Вы писали:

DL>Не уверен, что понимаю, что такое постановка

Этим смешным слово русские менеджеры называют software requirements specification.

Здравствуйте, Аноним, Вы писали:

А>Идеальные сотрудники так и делают. А в реальной жизни, сотрудник забьет болт и предоставит начальникам разбираться между собой. Учитывая что начальники и та будут на ножах из-за конфликта интересов можно годами ничего не делать.

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

Здравствуйте, DmytroL, Вы писали:

ned>>Согласен. У нас, например, есть тестировщики в составе команды разработчиков и есть отдел quality assurance со своими тестировщиками, своим багтрекером и проч.
DL>Интересно, какие преимущества дает такое дублирование? (не сарказм и не троллинг, действительно интересно)

Было похожее разделение на внутренний отдел тестирования и на внешний. Внетренний тестировал части проекта, по мере их готовности, что сокращало цикл "разработка — тестирование — исправление".
Внешний отдел тестировал уже готовый продукт.

Здравствуйте, DmytroL, Вы писали:

DL>идея кросс-функциональной команды неработоспособна в принципе? Но тогда как получается, что она является столь популярной в индустрии уже не первый год?

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, DmytroL, Вы писали:

DL>>Не уверен, что понимаю, что такое постановка

А>Этим смешным слово русские менеджеры называют software requirements specification.

Да, SRS есть. Строгого requirements testing'а нет, но QA участвуют в SRS review.

Здравствуйте, Аноним, Вы писали:

DL>>Не уверен, что понимаю, что такое постановка

А>Этим смешным слово русские менеджеры называют software requirements specification.

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

DL>идея кросс-функциональной команды неработоспособна в принципе? Но тогда как получается, что она является столь популярной в индустрии уже не первый год?

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

Тогда как отдельная (от основной) команда тестировщиков представляет из себя ОТК. Ценность их мнения состоит в том, что они, не зная внутренней кухни, не будут пытаться оправдывать, например, кривизну пользователького интерфейса внутренней логикой программы, или нехваткой времени программистов.

Со стороны всегда виднее — см. пословицу про соринку и бревно в глазу.