Всем привет!
Сразу хочу извиниться за некий "поток сознания" на тему, но действительно очень хочется разобраться и разложить все по полочкам с вашей помощью.
Итак, есть два распространенных мнения на этот счет:
Тестировщики являются полностью независимым подразделением в организации или, в лучшем случае, подчинены непосредственно менеджеру проекта в обход тимлида
Тестировщики являются неотемлимой частью проектной команды и подчинены тимлиду (в понимании этой роли, описанной Gaperton'ом
)
Приверженцы первого подхода аргументируют его тем, что, таким образом, обеспечивается полная независимость тестирования от давления менеджмента проекта ("сроки горят, давайте забъем на тестирование и зарелизим, что есть"). С другой стороны, при таком подходе не приходится говорить о кросс-функциональной команде, т.к. команда, по сути, разделена на два "лагеря" — разработчики и тестировщики, с сопутствующими конфликтами, перебрасыванием дерьма через стену и т.п., что отнюдь не в положительную сторону влияет на продуктивность и мотивацию в команде.
В случае же второго подхода получается полноценная кросс-функциональная команда, но остается риск давления на тестировщиков, особенно — в случае незрелого тим лида, только недавно выросшего из разработчиков.
Я являюсь ярым приверженцем кросс-функциональных команд в НЕортодоксальном смысле (т.е. обязательно содержащих представителей всех дисциплин разработки ПО, но без жесткого требования "все должны уметь делать все") и, поэтому, для меня подход №2 гораздо предпочтительнее. Но — пока не получается найти убедительные аргументы для высшего руководства. Высшее руководство, в свою очередь, склоняется к первому подходу по следующим причинам:
"Работает — не трогай" — т.е. в прошлом были проекты, которые вполне успешно делались по "классической" схеме. Хотя, были и очень показательные примеры недостатков такого подхода, вплоть до конфликтов, когда девелопмент лид и тест лид разговаривали между собой только через посредника По моим личным ощущениям, высшее руководство, при всем моем к ним уважении, не совсем в курсе современных тендеций к формированию проектных команд (само-организация, отсутствие иерархии внутри команды). И если на само-организации я особо не настаиваю, т.к. не каждая команда к ней, увы, способна, то как минимум на "плоской" структуре команды (пм->тимлид -> все остальные представители всех дисциплин) настаиваю даже очень. По моим личным ощущениям, предпочтение первому подходу отдается еще и из-за дефицита по-настоящему зрелых тим лидов, которые бы понимали, что на программировании разработка ПО не заканчивается.
Может быть, сообщество что-то подскажет? Возможно, существует какая-то третья, гибридная модель, о которой я не подозреваю, и которая хорошо зарекомендовала себя на практике?
Смотря о каких тестировщиках речь. Если о тех, которые пишут юнит-тесты и другие автоматические тесты, а также утилиты и программные комплексы для тестирования, то они должны быть частью команды и активно участвовать в разработке архитектуры. Это серьезные разработчики, у которых квалификация и зарплата может быть выше, чем у обычных программистов — членов команды. К тому же, для TDD они играют ключевую роль.
Если о тех, которые тестируют законченный продукт («кликеры»), такие должны быть совершенно отдельными, и лучше не общаться с программистами вообще. Такие баги отправляются ПМу, он их фильтрует, приоритезирует, оценивает серьезность и т.п., и переправляет тим-лидеру, а он уже смотрит на них с программистской точки зрения и дает задания разработчикам как часть рабочего процесса.
Напрямую баги разработчикам отправляться не должны ни в коем случае, и тестеры-кликеры напрямую с разработчиками разговаривать не должны, так как, во-первых, программисты склонны смотреть на баги с точки зрения реализации, поэтому могут пропустить любое уродство и порнографию, оправдывая это логикой внутренней реализации, во-вторых, программист может убедить тестера, что бага нет, когда он есть, в-третьих, общение программистов и тестеров ведет к ненужному раздражению и ухудшению атмосферы в коллективе.
Здравствуйте, Аноним, Вы писали:
А>Смотря о каких тестировщиках речь. Если о тех, которые пишут юнит-тесты и другие автоматические тесты, а также утилиты и программные комплексы для тестирования, то они должны быть частью команды и активно участвовать в разработке архитектуры. Это серьезные разработчики, у которых квалификация и зарплата может быть выше, чем у обычных программистов — членов команды. К тому же, для TDD они играют ключевую роль.
Согласен. У нас, например, есть тестировщики в составе команды разработчиков и есть отдел quality assurance со своими тестировщиками, своим багтрекером и проч.
Здравствуйте, DmytroL, Вы писали:
DL>Итак, есть два распространенных мнения на этот счет: DL> DL>Тестировщики являются полностью независимым подразделением в организации DL>Тестировщики являются неотемлимой частью проектной команды 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>ОК, кому они, в таком случае, подчиняются? Если руководителю своего подразделения, то как тогда ПМу/тимлиду управлять проектом, если часть проектной команды ему неподконтрольна?
Области полномочий начальников не должны пересекаться.
Например, проектный руководитель отвечает за организацию и выполнение работ в срок. Функциональный — за соблюдение технологии выполнения работ.
Завидую людям, которые могут себе позволить никуда не спешить.
Re[4]: Кому должны быть подчинены тестировщики?
От:
Аноним
Дата:
21.06.12 11:25
Оценка:
Здравствуйте, _Dinosaur, Вы писали:
_D>В этом случае сотруднику целесообразно эскалировать проблему. _D>Уведомить двух начальников об отдаче противоречивых приказов. Пусть договариваются.
Идеальные сотрудники так и делают. А в реальной жизни, сотрудник забьет болт и предоставит начальникам разбираться между собой. Учитывая что начальники и та будут на ножах из-за конфликта интересов можно годами ничего не делать.
Re[3]: Кому должны быть подчинены тестировщики?
От:
Аноним
Дата:
21.06.12 11:32
Оценка:
Здравствуйте, DmytroL, Вы писали:
DL>Не уверен, что понимаю, что такое постановка
Этим смешным слово русские менеджеры называют software requirements specification.
Здравствуйте, Аноним, Вы писали:
А>Идеальные сотрудники так и делают. А в реальной жизни, сотрудник забьет болт и предоставит начальникам разбираться между собой. Учитывая что начальники и та будут на ножах из-за конфликта интересов можно годами ничего не делать.
Для предотвращения таких ситуаций, в организации целесообразно иметь более высокого начальника, который имеет полномочия настучать обоим по голове.
Завидую людям, которые могут себе позволить никуда не спешить.
Здравствуйте, DmytroL, Вы писали:
ned>>Согласен. У нас, например, есть тестировщики в составе команды разработчиков и есть отдел quality assurance со своими тестировщиками, своим багтрекером и проч. DL>Интересно, какие преимущества дает такое дублирование? (не сарказм и не троллинг, действительно интересно)
Было похожее разделение на внутренний отдел тестирования и на внешний. Внетренний тестировал части проекта, по мере их готовности, что сокращало цикл "разработка — тестирование — исправление".
Внешний отдел тестировал уже готовый продукт.
Re[3]: Кому должны быть подчинены тестировщики?
От:
Аноним
Дата:
21.06.12 12:16
Оценка:
Здравствуйте, DmytroL, Вы писали:
DL>идея кросс-функциональной команды неработоспособна в принципе? Но тогда как получается, что она является столь популярной в индустрии уже не первый год?
Она работоспособна, конечно, только качество результата и эффективность работы ниже. А популярна она просто потому, что эта идея получается сама собой, если не иметь опыта или не анализировать его. У меня просто есть богатый отрицательный опыт, поэтому я знаю, как не надо делать.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, DmytroL, Вы писали:
DL>>Не уверен, что понимаю, что такое постановка
А>Этим смешным слово русские менеджеры называют software requirements specification.
Да, SRS есть. Строгого requirements testing'а нет, но QA участвуют в SRS review.
Здравствуйте, Аноним, Вы писали:
DL>>Не уверен, что понимаю, что такое постановка
А>Этим смешным слово русские менеджеры называют software requirements specification.
Не всегда. Некоторые русские менеджеры старой закалки они этим смешным словом могут называть "техническое задание", которое есть куда более веселая штука, чем SRS.
DL>идея кросс-функциональной команды неработоспособна в принципе? Но тогда как получается, что она является столь популярной в индустрии уже не первый год?
Тестирование — многоступенчатый процесс. Тестировщики в составе команды, как правило, занимаются только автоматическим тестированием. В их задачи, в частности, входит автоматизация (скриптование, если угодно) воспроизведения определенных багов.
Тогда как отдельная (от основной) команда тестировщиков представляет из себя ОТК. Ценность их мнения состоит в том, что они, не зная внутренней кухни, не будут пытаться оправдывать, например, кривизну пользователького интерфейса внутренней логикой программы, или нехваткой времени программистов.
Со стороны всегда виднее — см. пословицу про соринку и бревно в глазу.
Здравствуйте, DmytroL, Вы писали:
DL>Интересно, какие преимущества дает такое дублирование? (не сарказм и не троллинг, действительно интересно)
Выше качество продукта на выходе, очевидно.
Еще у нас специфика такая, что QA тестирует конкретные настроенные решения перед поставкой клиенту, а тестеры в команде разработчиков отдельные модули и базовые конфигурации систем.
Re[5]: Кому должны быть подчинены тестировщики?
От:
Аноним
Дата:
22.06.12 07:44
Оценка:
Здравствуйте, Gaperton, Вы писали:
G>Не всегда. Некоторые русские менеджеры старой закалки они этим смешным словом могут называть "техническое задание", которое есть куда более веселая штука, чем SRS.
Ага. Веселая хотя бы тем что этим термином называют абсолютно разные вещи, от приказа на разработку до эскизного проекта. Еще, кстати, постановкой иногда называют deployment.
Re[4]: Кому должны быть подчинены тестировщики?
От:
Аноним
Дата:
22.06.12 08:13
Оценка:
Здравствуйте, DmytroL, Вы писали:
DL>Здравствуйте, ned, Вы писали:
ned>>Согласен. У нас, например, есть тестировщики в составе команды разработчиков и есть отдел quality assurance со своими тестировщиками, своим багтрекером и проч.
DL>Интересно, какие преимущества дает такое дублирование?
По-идее они занимаются разными вещами. Внутренние тестировщики занимаются smoke и automated тестированием, а внешний QA занимается обеспечением качества всего продукта: от инсталлятора и документации до программных уязвимостей и комментариев в коде.
Здравствуйте, Аноним, Вы писали:
G>>Не всегда. Некоторые русские менеджеры старой закалки они этим смешным словом могут называть "техническое задание", которое есть куда более веселая штука, чем SRS.
А>Ага. Веселая хотя бы тем что этим термином называют абсолютно разные вещи, от приказа на разработку до эскизного проекта. Еще, кстати, постановкой иногда называют deployment.
А что, это правда имеет такое большое значение, что кто-то называет что-то каким-то термином, значение которого точно закреплено десятком ГОСТ-ов? Не пофигу, не?
Здравствуйте, DmytroL, Вы писали:
DL>Приверженцы первого подхода аргументируют его тем, что, таким образом, обеспечивается полная независимость тестирования от давления менеджмента проекта ("сроки горят, давайте забъем на тестирование и зарелизим, что есть"). С другой стороны, при таком подходе не приходится говорить о кросс-функциональной команде, т.к. команда, по сути, разделена на два "лагеря" — разработчики и тестировщики, с сопутствующими конфликтами, перебрасыванием дерьма через стену и т.п., что отнюдь не в положительную сторону влияет на продуктивность и мотивацию в команде.
DL>В случае же второго подхода получается полноценная кросс-функциональная команда, но остается риск давления на тестировщиков, особенно — в случае незрелого тим лида, только недавно выросшего из разработчиков.
Сформулирум собственно саму исходную проблему: "Девелопер говорит, что все работает как надо, а тестировщик говорит, что баг".
Решается ли она первым подходом? Нет.
Решается ли она вторым подходом? Нет.
Почему? Потому что данная проблема является профессиональной (у среднестатистического девелопера убеждения о качестве ПО расходятся с оными среднестатистического тестера), а представленные тобой два подхода являются организационными, и решить эту проблему не могут в принципе.
DL>Может быть, сообщество что-то подскажет? Возможно, существует какая-то третья, гибридная модель, о которой я не подозреваю, и которая хорошо зарекомендовала себя на практике?
Одна модель, прекрасно работающая на практике, мне известна: заказчик организует качественное входное тестирование (своими ресурсами или нанимает сторонние фирмы), и не принимает ПО, пока оно по его мнению не готово. И тут происходит удивительное: по прошествии 3-4 месяцев несданного (и, соответственно, неоплаченного) проекта все проблемы с выходным тестированием на стороне производителя ПО вдруг решаются как будто сами собой
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
А>Сформулирум собственно саму исходную проблему: "Девелопер говорит, что все работает как надо, а тестировщик говорит, что баг".
Я бы все же сказал, что исходная проблема формулируется как "Если тестировщик говорит, что баг, а девелопер — что все работает как надо, то кто принимает окончательное решение о выпуске продукта?" А это уже ИМХО именно организационная проблема.
А>Одна модель, прекрасно работающая на практике, мне известна: заказчик организует качественное входное тестирование (своими ресурсами или нанимает сторонние фирмы), и не принимает ПО, пока оно по его мнению не готово. И тут происходит удивительное: по прошествии 3-4 месяцев несданного (и, соответственно, неоплаченного) проекта все проблемы с выходным тестированием на стороне производителя ПО вдруг решаются как будто сами собой
В таком контексте эта модель, конечно же, будет работать. Увы, в моей практике контекст нередко был совсем другим: никакого входного тестирования у заказчика нет, всяческие попытки заложить в эстимейт достаточное количество времени на обеспечение качества он нещадно давит, более того — никаких формальных критериев приемки сформулировать тоже не может, ограничиваясь расплывчатой формулировкой "good enough".
Обе проблемы — "тестировщик говорит, что баг, а девелопер — что все работает как надо", равно как и "более того — никаких формальных критериев приемки сформулировать тоже не может, ограничиваясь расплывчатой формулировкой "good enough" — решаются разработкой и согласованием с Заказчиком документа, который по советским ГОСТам называется Программа и методика испытаний (а в твоем случае может называться как-то иначе). Разрабатывать этот документ должен именно разработчик. ПиМИ должна включать методы контроля всех функциональных требований, указанных в ТЗ, и по каждому пункту содержать магическую фразу "Результат испытания считается успешным, если..." Чем раньше появится в проекте такой документ — тем лучше.
"Ни один ветер не будет попутным для корабля, капитан которого не знает, куда плыть." Вот ПиМИ — это как раз ориентир, "куда плыть". Нет?
почему же "новые"?
Заказчик в 99.99% случаев вообще не ориентируется в том, как испытывать изделие (программу). И в таком же примерно проценте случаев — не может грамотно составить документ. Зато разработчик — знает вполне (ну, по крайней мере, обязан знать).
On 09.07.2012 11:17, Vlad_SP wrote:
> почему же "новые"? > Заказчик в 99.99% случаев вообще не ориентируется в том, как > испытывать изделие (программу). И в таком же примерно проценте случаев — > не может грамотно составить документ. Зато разработчик — знает вполне > (ну, по крайней мере, *обязан* знать).
Если "разработчик" — это "компания-разработчик", то может быть и так. А
если "разработчик" — это "программист", то нет.
а, вот теперь понятно. У нас с тобой получилось разночтение в понимании термина "разработчик".
Нет, конечно же, я имел в виду не программиста (его дело — писать код), а скорее аналитика или руководителя проекта (нередко эти роли выполняет один человек) — вот именно в их функции входит взаимодействие с заказчиком, управление требованиями и обеспечение качества.
On 09.07.2012 12:45, Vlad_SP wrote:
> а, вот теперь понятно. У нас с тобой получилось разночтение в понимании > термина "разработчик". > Нет, конечно же, я имел в виду не программиста (его дело — писать код), > а скорее аналитика или руководителя проекта (нередко эти роли выполняет > один человек) — вот именно в их функции входит взаимодействие с > заказчиком, управление требованиями и обеспечение качества.
Акцент на парную работу девелопер-тестер. Т.е. тестер юнит- или компонент-тестирует фичу, над которой в данный момент работает девелопер, с соответствующим взаимодействием. При этом у тестеров своя иерархия подчинения, система грейдов и мотиваций и т.д (а у PM еще и своя, примерно все похоже на воинские звания, при этом все три роли — PM/тестер/девелопер — не есть начальники и подчиненные друг друга).
Кроме того, существуют test labs, в которых гоняют DTM и WLK (автоуправление тестовыми скриптами на многих "подопытных" компах с центрального контроллера) сразу на десятках (если не сотнях) компов разных вендоров.
Кроме того, есть команда сборки Windows как целого, это скорее релиз-инжиниринг, чем девелопмент, и там, как я понял, свои тестеры.
2) Многие компании поменьше, как довольно толковые российские, так и американские сходного размера (десятки человек).
Тестеры образуют скорее не отдел, а нечто вроде "пула". Иногда есть формальный нач. отдела, который занимается распределением людей по задачам, и работает в основном с календарями.
Самая главная задача, особенно перед релизом — тестирование продукта как целого. Вылезает куча мелочи типа "передвиньте кнопочку влево", все это идет в tracker, решения о приоритетах принимает PM. Естественно, девелопер не может закрыть issue, он может только заявить Resolved/Fixed или типа того (зависит от конкретного трекера). Закрыть как Fixed может только тестер, закрыть по иным причинам — PM.
Кроме того, делаются компонент-тесты отдельных компонент. При этом создается (распоряжением PMов) пара девелопер-тестер, девелопер пишет задание на тест. В нем должно быть:
а) исходная конфигурация платформы для теста
б) инструкция по инсталляции компонент
в) описание test run
г) матрица случаев, для которых гонять один и тот же test run
д) выходные данные, куда минимально входит отсутствие крахов, повисаний, сообщений об ошибках в UI и эвент логи, но кроме того могут входить и некие результаты в виде правильного содержимого файлов, реестра и т.д.
Также иногда бывает д1) валидация, т.е. исполнение валидационных тулов по файлам, созданным во время test run. Тулы зачастую разрабатываются девелопером, но иногда — тестером. В некоторых случаях валидация есть просто прогон другой компоненты продукта по результирующему файлу.
При наличии грамотных людей и правильной постановке тестеры умеют программировать на каких-то языках (от Питона до C#), и автоматизируют шаги б) и далее. При применении Hyper-V или VMWare ESX можно и шаг а) автоматизировать.
В некоторых случаях применяется еще и использование тестеров для разрешения текущих issues от support и от pre-sale, причем как правило этим issues идет максимум приоритета (там "живой" клиент с "живыми" деньгами).
Flow идет в виде:
— Support (возбуждение и контроль процесса, общение с клиентом, отсечка глупостей типа неумения клиента обращаться с Windows, а равно известных resolved issues из Support DB)
— Development (отсечка глупостей типа старой версии бинаря у клиента, не-включения оным правильного режима работы, указания на имеющийся workaround, далее попытки немедленно разобраться с багом на основе code review и полученных от клиента логов и т.д., которая не всегда удается, если не удается — то необходима разработка спецверсии одной из компонент для прогона исследовательских тестов)
— Testing (воспроизведение среды заказчика, далее см. выше а/б/в/г/д, с поправкой на то, что спецверсия компонента имеет не валидацию, а поиск ответа на вопрос, тестеру нужно собрать необходимые файлы результатов и отправить девелоперу)
— Development (поиск собственно ответа на вопрос, в конечном итоге — фикс или же возбуждение иного issue вида "мы не поддерживаем такой режим работы, это архитектурное ограничение нынешней версии" или же "это мелкий, но неприятный баг одного из компонент платформы", в этих случаях решение отдается PMу).
— Testing (тестирование фикса и регресс-тестирование).
Вот примерно так. Назначение тестера на взаимодействие с девелопером осуществляет PM, но оно опять же разовое на данную задачу.
Разговоры о том, что девелопер (по крайней мере старший девелопер, который иногда называется "архитектор") не знает о том, как тестировать свою фичу, меня так просто поражают
Разработка требований к фиче идет при активном участии девелопера, хотя лидирует при этом PM или аналитик требований. Девелопер дает feedback на тему "технически возможные варианты" и "их стоимость по срокам".
После принятия решения об объеме и содержании работ по данной фиче "здесь и сейчас" (т.е. за исключением того, что отнесли в будущий roadmap) как правило процедура тестирования фичи очевидна всем.
MSS>Разговоры о том, что девелопер (по крайней мере старший девелопер, который иногда называется "архитектор") не знает о том, как тестировать свою фичу, меня так просто поражают
Знать-то он может и знает. Но он — человек. А каждый человек подвержен всяким слабостям. Например, можно знать, что если передать вот такие-то комбинации параметров, то, скорее всего, что-то сработает не так, как хотелось бы. Разработчик об этом знает (и может даже коммент сделать в хедере), но тест на это дело он не напишет (а зачем, я и так помню, мне не до того).
Причем это не решается даже методом eat own dog food, т.е. когда разработчик сам своими продуктами вынужден пользоваться. Потому что он знает про грабли в том темном углу...
Re[2]: Кому должны быть подчинены тестировщики?
От:
Аноним
Дата:
15.08.12 17:33
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>После принятия решения об объеме и содержании работ по данной фиче "здесь и сейчас" (т.е. за исключением того, что отнесли в будущий roadmap) как правило процедура тестирования фичи очевидна всем.
Ну вы даете. Такое ощущение, что вы никогда не разрабатывали продукт для конечных пользователей. Знаете, как на самом деле будет выглядеть то, что вы сказали? Первый же пользователь найдет десять багов в таких местах и такими способами, о которых девелопер даже подумать не мог. Это железно.
Здравствуйте, DmytroL, Вы писали:
DL> DL>Тестировщики являются полностью независимым подразделением в организации или, в лучшем случае, подчинены непосредственно менеджеру проекта в обход тимлида DL>Тестировщики являются неотемлимой частью проектной команды и подчинены тимлиду (в понимании этой роли, описанной Gaperton'ом
) DL>DL>Может быть, сообщество что-то подскажет? Возможно, существует какая-то третья, гибридная модель, о которой я не подозреваю, и которая хорошо зарекомендовала себя на практике?
Могу поделиться опытом работы в СиБОССЕ. Пока в рамках одного отдела было два сектора: разработки и тестирования, все было замечательно. Начальник отдела ставил общую задачу "чтоб релиз был готов к такому-то", а кто зафейлит, разработка или тестирование — неважно, по шапке получат все. Отмазы "это не мы, это они" не катят. Одна лодка, так сказать. Поэтому разработка и тестирование работали в одной связке и жили на удивление дружно. Их руководители встречались регулярно на еженедельном совещании отдела и там же одновременно получали согласованные задачи.
Потом их разделил — сектор разработки ушел в департамент разработки, сектор тестирования — в департамент качества. Вот тут и началось. У тестировщиков задачи не только по проверки выпускаемых релизов, но и по проверке старых релизов для конкретного клиента. Поэтому их планы стали не совпадать с планами по разработке. "Нам надо срочно протестировать релиз 123 для клиента А, пофиксите ошибки" — "а у нас нет времени, мы работает над релизом 456". "Проверьте срочно наши правки в релизе 234" — "а теперь мы не можем, нам надо срочно протестировать релиза для клиента Б". Понятно, что в этом случае надо было эскалировать проблему выше, на руководителя, общего для обоих секторов. Но проблема в том, что сектора были в разных департаментах, а общий руководитель департаментов это сам президент компании. Котором, есс-но, нет дела до разбирательства каких-то там секторов. Вот так и жили...
Ни на чем не настаиваю (у вас может быть все по-другому), просто пример.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Разговоры о том, что девелопер (по крайней мере старший девелопер, который иногда называется "архитектор") не знает о том, как тестировать свою фичу, меня так просто поражают
Знать то он знает, но на практике обычно тестирует фигово.
Основные причины — девелопер слишком много знает о реализации и у него уже замылены глаза.
Независимое тестирование лучше.
Но девелопер конечно может дать дополнительную инфу, как сделать тестирование более эффективным.
Здравствуйте, DmytroL, Вы писали:
DL>Высшее руководство, в свою очередь, склоняется к первому подходу по следующим причинам:
С точки зрения высшего руководства, по-моему, все гораздо проще. Независимо организованные тестировщики часто могут обслужить несколько проектных команд и еще какие-то побочные задачи. То есть работать с большей отдачей и меньшими затратами. Пусть даже с некоторым ущербом качеству (из-за слабой интеграции с разработкой). Вот так банально.
На практике получается по-разному, иногда хорошо, иногда не очень, что подтверждает пример Basil2.
