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

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

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

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

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

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

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

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

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

DL>Интересно, какие преимущества дает такое дублирование?
По-идее они занимаются разными вещами. Внутренние тестировщики занимаются smoke и automated тестированием, а внешний QA занимается обеспечением качества всего продукта: от инсталлятора и документации до программных уязвимостей и комментариев в коде.

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

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

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

А что, это правда имеет такое большое значение, что кто-то называет что-то каким-то термином, значение которого точно закреплено десятком ГОСТ-ов? Не пофигу, не?

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

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

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

Сформулирум собственно саму исходную проблему: "Девелопер говорит, что все работает как надо, а тестировщик говорит, что баг".
Решается ли она первым подходом? Нет.
Решается ли она вторым подходом? Нет.
Почему? Потому что данная проблема является профессиональной (у среднестатистического девелопера убеждения о качестве ПО расходятся с оными среднестатистического тестера), а представленные тобой два подхода являются организационными, и решить эту проблему не могут в принципе.

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

Одна модель, прекрасно работающая на практике, мне известна: заказчик организует качественное входное тестирование (своими ресурсами или нанимает сторонние фирмы), и не принимает ПО, пока оно по его мнению не готово. И тут происходит удивительное: по прошествии 3-4 месяцев несданного (и, соответственно, неоплаченного) проекта все проблемы с выходным тестированием на стороне производителя ПО вдруг решаются как будто сами собой

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

А>Сформулирум собственно саму исходную проблему: "Девелопер говорит, что все работает как надо, а тестировщик говорит, что баг".

Я бы все же сказал, что исходная проблема формулируется как "Если тестировщик говорит, что баг, а девелопер — что все работает как надо, то кто принимает окончательное решение о выпуске продукта?" А это уже ИМХО именно организационная проблема.

А>Одна модель, прекрасно работающая на практике, мне известна: заказчик организует качественное входное тестирование (своими ресурсами или нанимает сторонние фирмы), и не принимает ПО, пока оно по его мнению не готово. И тут происходит удивительное: по прошествии 3-4 месяцев несданного (и, соответственно, неоплаченного) проекта все проблемы с выходным тестированием на стороне производителя ПО вдруг решаются как будто сами собой

В таком контексте эта модель, конечно же, будет работать. Увы, в моей практике контекст нередко был совсем другим: никакого входного тестирования у заказчика нет, всяческие попытки заложить в эстимейт достаточное количество времени на обеспечение качества он нещадно давит, более того — никаких формальных критериев приемки сформулировать тоже не может, ограничиваясь расплывчатой формулировкой "good enough".

Как минимум вы опишите , какой результат вы хотите получить?

Здравствуйте, DmytroL,

Обе проблемы — "тестировщик говорит, что баг, а девелопер — что все работает как надо", равно как и "более того — никаких формальных критериев приемки сформулировать тоже не может, ограничиваясь расплывчатой формулировкой "good enough" — решаются разработкой и согласованием с Заказчиком документа, который по советским ГОСТам называется Программа и методика испытаний (а в твоем случае может называться как-то иначе). Разрабатывать этот документ должен именно разработчик. ПиМИ должна включать методы контроля всех функциональных требований, указанных в ТЗ, и по каждому пункту содержать магическую фразу "Результат испытания считается успешным, если..." Чем раньше появится в проекте такой документ — тем лучше.

"Ни один ветер не будет попутным для корабля, капитан которого не знает, куда плыть." Вот ПиМИ — это как раз ориентир, "куда плыть". Нет?

On 09.07.2012 10:42, Vlad_SP wrote:

> Разрабатывать этот документ должен именно разработчик.

Новое время- новые веяния?

--
WBR,
Serge.

Здравствуйте, hrensgory,

почему же "новые"?
Заказчик в 99.99% случаев вообще не ориентируется в том, как испытывать изделие (программу). И в таком же примерно проценте случаев — не может грамотно составить документ. Зато разработчик — знает вполне (ну, по крайней мере, обязан знать).

On 09.07.2012 11:17, Vlad_SP wrote:

> почему же "новые"?
> Заказчик в 99.99% случаев вообще не ориентируется в том, как
> испытывать изделие (программу). И в таком же примерно проценте случаев —
> не может грамотно составить документ. Зато разработчик — знает вполне
> (ну, по крайней мере, *обязан* знать).

Если "разработчик" — это "компания-разработчик", то может быть и так. А
если "разработчик" — это "программист", то нет.

--
WBR,
Serge.

Здравствуйте, hrensgory,

а, вот теперь понятно. У нас с тобой получилось разночтение в понимании термина "разработчик".
Нет, конечно же, я имел в виду не программиста (его дело — писать код), а скорее аналитика или руководителя проекта (нередко эти роли выполняет один человек) — вот именно в их функции входит взаимодействие с заказчиком, управление требованиями и обеспечение качества.

On 09.07.2012 12:45, Vlad_SP wrote:

> а, вот теперь понятно. У нас с тобой получилось разночтение в понимании
> термина "разработчик".
> Нет, конечно же, я имел в виду не программиста (его дело — писать код),
> а скорее аналитика или руководителя проекта (нередко эти роли выполняет
> один человек) — вот именно в их функции входит взаимодействие с
> заказчиком, управление требованиями и обеспечение качества.

Да, в такой постановке — согласен.

--
WBR,
Serge.

1) Microsoft

Акцент на парную работу девелопер-тестер. Т.е. тестер юнит- или компонент-тестирует фичу, над которой в данный момент работает девелопер, с соответствующим взаимодействием. При этом у тестеров своя иерархия подчинения, система грейдов и мотиваций и т.д (а у 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, т.е. когда разработчик сам своими продуктами вынужден пользоваться. Потому что он знает про грабли в том темном углу...

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>После принятия решения об объеме и содержании работ по данной фиче "здесь и сейчас" (т.е. за исключением того, что отнесли в будущий roadmap) как правило процедура тестирования фичи очевидна всем.

Ну вы даете. Такое ощущение, что вы никогда не разрабатывали продукт для конечных пользователей. Знаете, как на самом деле будет выглядеть то, что вы сказали? Первый же пользователь найдет десять багов в таких местах и такими способами, о которых девелопер даже подумать не мог. Это железно.

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

DL>

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

DL>Может быть, сообщество что-то подскажет? Возможно, существует какая-то третья, гибридная модель, о которой я не подозреваю, и которая хорошо зарекомендовала себя на практике?
Могу поделиться опытом работы в СиБОССЕ. Пока в рамках одного отдела было два сектора: разработки и тестирования, все было замечательно. Начальник отдела ставил общую задачу "чтоб релиз был готов к такому-то", а кто зафейлит, разработка или тестирование — неважно, по шапке получат все. Отмазы "это не мы, это они" не катят. Одна лодка, так сказать. Поэтому разработка и тестирование работали в одной связке и жили на удивление дружно. Их руководители встречались регулярно на еженедельном совещании отдела и там же одновременно получали согласованные задачи.

Потом их разделил — сектор разработки ушел в департамент разработки, сектор тестирования — в департамент качества. Вот тут и началось. У тестировщиков задачи не только по проверки выпускаемых релизов, но и по проверке старых релизов для конкретного клиента. Поэтому их планы стали не совпадать с планами по разработке. "Нам надо срочно протестировать релиз 123 для клиента А, пофиксите ошибки" — "а у нас нет времени, мы работает над релизом 456". "Проверьте срочно наши правки в релизе 234" — "а теперь мы не можем, нам надо срочно протестировать релиза для клиента Б". Понятно, что в этом случае надо было эскалировать проблему выше, на руководителя, общего для обоих секторов. Но проблема в том, что сектора были в разных департаментах, а общий руководитель департаментов это сам президент компании. Котором, есс-но, нет дела до разбирательства каких-то там секторов. Вот так и жили...

Ни на чем не настаиваю (у вас может быть все по-другому), просто пример.

Чаще тестировщики — это отдельный отдел.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Разговоры о том, что девелопер (по крайней мере старший девелопер, который иногда называется "архитектор") не знает о том, как тестировать свою фичу, меня так просто поражают

Знать то он знает, но на практике обычно тестирует фигово.
Основные причины — девелопер слишком много знает о реализации и у него уже замылены глаза.
Независимое тестирование лучше.
Но девелопер конечно может дать дополнительную инфу, как сделать тестирование более эффективным.