Сообщений в теме: 64

[OVA]

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

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

Угу. Как пример ведущей компании на agile и ее "успехов" предлагаю взять Nokia. Они до сих пор, кстати, сертифицированных scrum-мастеров набирают. Есть еще Skype, которому MS этот agile засаживает туда куда он привык (и это, о ужас(!), все еще будет называться agile). И обе конторы, о ужас(!), слушали ни много ни мало таких людей как Martin Fowler, например.

Вы уж простите, но для меня конструктивное общение обычно начинается когда я bullshit-детектор перестает зашкаливать от баззвордов и прочего best practices, а аргументация начинает блистать чем-то большим чем "ну гугль так делал, значит это правильно".

[barancev]

Сергей, а про совмещение ролей есть что сказать? :)
Или "аналитик" и "тестировщик" тоже признаны баззвордами? :)

[barancev]

Если честно, я ожидал совершенно противоположной реакции, типа "фу, V-модель ацтой, старьё, не работает", а оказалось вон оно как...

[OVA]

Сергей, а про совмещение ролей есть что сказать? :)
Или "аналитик" и "тестировщик" тоже признаны баззвордами? :)

Мне заранее не нравится аналитик-тестировщик-внедренец. Собственно аналитик-тестировщик так же вопросы вызывает, но тут все сильно зависит от того что люди понимают под аналитиком (зачастую редкий фарш) и тестировщиком (тут все очень печально, но это тема для другого большого холивара). Но в той формулировке, что обозначена топикстартером все больше похоже на такой термин как "разнорабочий", т.е. девальвация в пол всех трех ролей.
С другой стороны я прекрасно понимаю что роль тестировщика на просторох нашей необъятной зачастую и представляет из себя роль а-ля "разнорабочий" с припиской "по сверке документов с чем-нибудь", например.
С третьей стороны последние месяцы была довольно интересная дискусия касательно прошлого, настоящего и будущего профессии (искать спичи по фамилиям "Harthy-Bjedov-Whittaker-Savoia", Simo-Kaner-Barber-Bach-Bolton по желанию) из которой можно сделать несколько довольно интересных выводов. Часть из них я уже излагал вот тут, например: http://goblingame.bl...og-post_28.html
Бонус: Наши контекстные братья по профессии, например, приводили интересную аналогию со словом "аудитор".

[Pulsar]

3. Про богача вообще какое-то нелепое обвинение. Я вижу тут две возможных интерпретации, обе, с моей точки зрения равно нелепые :)
3.1. Есть у нас два сотрудника -- аналитик и тестировщик. Давайте сделаем "совмещение ролей", и тогда одного сотрудника можно будет уволить!
3.2. Если человек владеет двумя навыками (например, аналитика и тестировщика), значит он владеет ими обоими плохо.

По 3.2 согласен, т.к. из одного не обязательно следует другое.
Переформулирем:
3.2.1 Человек тестировщик, но не аналитик (не хочет, не интересно, не нравится ...), но согласно новой пропаганде тестировщик это тот же аналитик.
3.2.2 Человек аналитик, но не тестировщик (не хочет, не интересно, не нравится ...), но согласно новой пропаганде аналитик это тот же тестировщик.
Мышки станьте ежиками. Ежики станьте мышками (и быстрее, быстрее, побольше, побольше ;))
3.3. Есть у нас два объема работ -- для аналитика и для тестировщика. Давайте сделаем "совмещение ролей", и тогда можно взять на работу одного сотрудника, вместо двоих. Экономия!

[Pulsar]

Я вполне польщен приписываемым мне авторством ...

На здоровье ;) (хотя 'идет' это скорее к действию, то бишь пропаганде ...)
Кто же автор? (аналитика-тестировщика)

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

Не передергивание, а гипербола, для лучшей наглядности. И частично успешная - "не поместится в одну голову" (прямо как с шапками ;)). А если еще учесть, что вообще-то голова тестировщика не предназначена для одевания на аналитика (и наоборот), то совсем хорошо ;)

[SALar]

3.2. Если человек владеет двумя навыками (например, аналитика и тестировщика), значит он владеет ими обоими плохо.

По 3.2 согласен, т.к. из одного не обязательно следует другое.
Переформулирем:
3.2.1 Человек тестировщик, но не аналитик (не хочет, не интересно, не нравится ...), но согласно новой пропаганде тестировщик это тот же аналитик.
3.2.2 Человек аналитик, но не тестировщик (не хочет, не интересно, не нравится ...), но согласно новой пропаганде аналитик это тот же тестировщик.
Мышки станьте ежиками. Ежики станьте мышками (и быстрее, быстрее, побольше, побольше ;))
3.3. Есть у нас два объема работ -- для аналитика и для тестировщика. Давайте сделаем "совмещение ролей", и тогда можно взять на работу одного сотрудника, вместо двоих. Экономия!

Господа. В этом вопросе я достаточно категоричен. Если аналитик не обладает навыками тестировщика, то он не выберется из категории "начинающий". Просто по тому, что эти навыки необходимы в повседневной работе аналитика.
Как вы себе представляете аналитика, который:
1. Не умеет идентифицировать дефекты.
2. Не умеет описывать дефекты.
3. Не умеет писать тестовые сценарии.
Смешно, правда? Как с таким ворохом неумений можно требования то писать?

Что же касается совмещения не навыков, но ролей, то совмещение ролей аналитика и тестировщика позволяет серьезно, а иногда и кардинально уменьшить трудозатраты на один и тот же объем работ. Если вместо недоаналитика и недотестировщика взять нормального кроссфункционального спеца, то часто можно еще и пару кодировщиков из проекта вывести и все равно сделать проект быстрее.
Экономия? Естественно, экономия. И особенно большая экономия получается не на зарплатах (что копейки), на на более раннем получении прибыли.

PS. Да еще момент. Тестировщик также не выберется из "начинающих", если не будет качать скилы в смежной профессии. И наиболее перспективно не кодирование, а системный анализ. Впрочем, проектирование GUI тоже очень перспективно.

[SALar]

От водопада к Agile

"Водопад" никак и ничем не противоречит "Agile". По определению

Сергей, Agile и водопад были антагонистами с самого начала, то есть с зарождения agile.

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

Тезис который я предлагаю: темы "совмещение vs разделения ролей аналитика и тестировщика" и "выбор жизненного цикла разработки" слабосвязаны между собой.
И разделение и совмещение могут быть и там, и там, и там, и там:
* непрерывная поставка
* упаковка по объему
* упаковка по времени
* что-то еще...
Нет смысла увеличивать scoup доклада и вызывать флейм в побочных ветках.
-----------------

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

ГОСТ 34.х никак не ограничивает кросфункциональность. Более того, как раз ГОСТ 34.602 и ГОСТ 34.603 молчаливо предполагает совмещение ролей аналитика и тестировщика.
И в то же время Agile ничего не говорит о необходимости кроссфункциональности. Другое дело такие частные случаи как SCRUM или XP. Но там ни аналитика, ни тестировщика быть не должно.

К ГОСТ-34 я лично отношусь очень несерьезно. Я его читал, и, в общем, не могу относиться иначе к стандарту, в котором разработка системы суть побочный процесс разработки документации на систему (это ГОСТ 34.601-90). Вообще они устарели на 20 лет, то есть навсегда. И если говорить о ролях, то когда они разрабатывались тестировщиков как таковых - не было. Agile сейчас в представлен в виде XP-SCRUM-Canban, о кросс-функциональности говорят они. А дальше, в реальных условиях. это кросс-функциональность получается ограниченной тем или иным образом. Например, таким как в докладе.

Вовсе нет. В ГОСТ-ах 34 серии неплохо дано целеполагание. Включая декомпозицию целей и проверку достижимости. Я бы сказал обратное. Общая культура разработки ПО на текущей момент очень сильно не дотягивает до ГОСТ-ов. Нам (и мне тоже) достаточно тяжело их использовать ввиду общей деградации культуры в последние 10-15 лет. Впрочем, это еще одна тема для настоящего полноценного холивара, слабосвязанная с исходной темой доклада.

Предлагаю не трогать Canban. Это система управления работами, созданная для V-цепочек (не имеет никакого отношения к v-модели в вашем докладе) и цепоцек смешанного типа. Созданного для производства, в котором очень много ролей, но часть производственных участков могут выполнять более одной технологической операции (аналог совмещения ролей). Система создавалась на смену системе управления Форда, которая идеально подходила для производственных цепочек A-типов и, естественно, дала сбой при расширении модельного ряда.
Тот же псевдоканбан, о котором рассказывают консультанты имеет такое же отношение к системе Таичи Оно, какое имеет морская свинка к свиньям и морю. Псевдо "канбан-доски" могут применяться для производственных цепочек только I-типа и то с некоторыми ограничениями. Впрочем, это еще одна тема для настоящего полноценного холивара, слабосвязанная с исходной темой доклада.

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

[OVA]

Господа. В этом вопросе я достаточно категоричен. Если аналитик не обладает навыками тестировщика, то он не выберется из категории "начинающий". Просто по тому, что эти навыки необходимы в повседневной работе аналитика.
Как вы себе представляете аналитика, который:
1. Не умеет идентифицировать дефекты.
2. Не умеет описывать дефекты.
3. Не умеет писать тестовые сценарии.
Смешно, правда? Как с таким ворохом неумений можно требования то писать?

...

PS. Да еще момент. Тестировщик также не выберется из "начинающих", если не будет качать скилы в смежной профессии. И наиболее перспективно не кодирование, а системный анализ. Впрочем, проектирование GUI тоже очень перспективно.

А аналитик это что?
Человек который пишет требования? Простите, но тестировщик который пишет требования это оксюморон. Напоминает "знаешь, а ведь были какие-то причины, по которым программисты не делают дизайн графического интерфейса" (с)
Человек который рисует флоучарты, юз-кейсы и прочие описания вплоть до архитектуры системы? См. предыдущий пункт. К тому же надо различать use case/scenario и test case/scenario.

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

И про "начинающих" подробнее можно? Какие смежные навыки кровь из носа нужны тестировщику?

ЗЫ: "scoup" это почти по Фрейду получается.

[OVA]

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

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

[maksiq]

Угу. Как пример ведущей компании на agile и ее "успехов" предлагаю взять Nokia. Они до сих пор, кстати, сертифицированных scrum-мастеров набирают. Есть еще Skype, которому MS этот agile засаживает туда куда он привык (и это, о ужас(!), все еще будет называться agile). И обе конторы, о ужас(!), слушали ни много ни мало таких людей как Martin Fowler, например.

Текущее состояние Nokia в принципе не связано с разработкой ПО, там работают другие, макроэкономические причины. Если вам нужен успешный пример для флейма, можно взять MS, который перешел на agile - естественно, оригинальный, но на то agile и гибкий. Или внутреннюю разработку Дойча, также использующую agile для достижения вполне конкретных результатов. Skype, кстати, тоже вполне успешен. Контекст предложения про Мартина Фаулера я не понял.

Вы уж простите, но для меня конструктивное общение обычно начинается когда я bullshit-детектор перестает зашкаливать от баззвордов и прочего best practices, а аргументация начинает блистать чем-то большим чем "ну гугль так делал, значит это правильно".

В общем-то, мне - не слишком интересно убеждать. Есть тренды IT-отрасли, они отражают реальное положение дел в мире. Можно утверждать, что это - баззворды, а мир, как обычно, идет не туда и люди просто не понимают, что делают. А можно разбираться в происходящем и извлекать полезные выводы.

[maksiq]

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

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

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

Если же брать мировой опыт, то, например, SFIA выделяет тестировщика как 45 TEST - Testing: The concurrent lifecycle process of engineering, using and maintaining testware (test cases, test scripts, test reports, test plans, etc) to measure and improve the quality of the software being tested. Testing embraces the planning, design, management, execution and reporting of tests, using appropriate testing tools and techniques and conforming to agreed standards (such as ISO 29119), to ensure that new and amended systems, configurations, packages, or services, together with any interfaces, perform as specified.

А вот единого аналитика там нет, вместо этого имеем 36 DTAN - Data analysis, 37 REQM - Requirements definition and management, 32 BSMO - Business modelling, 38 DESN - Systems design, 40 DBDS - Database/repository design и некоторые другие.

[maksiq]

3. Про богача вообще какое-то нелепое обвинение. Я вижу тут две возможных интерпретации, обе, с моей точки зрения равно нелепые :)
3.1. Есть у нас два сотрудника -- аналитик и тестировщик. Давайте сделаем "совмещение ролей", и тогда одного сотрудника можно будет уволить!
3.2. Если человек владеет двумя навыками (например, аналитика и тестировщика), значит он владеет ими обоими плохо.

По 3.2 согласен, т.к. из одного не обязательно следует другое.
Переформулирем:
3.2.1 Человек тестировщик, но не аналитик (не хочет, не интересно, не нравится ...), но согласно новой пропаганде тестировщик это тот же аналитик.
3.2.2 Человек аналитик, но не тестировщик (не хочет, не интересно, не нравится ...), но согласно новой пропаганде аналитик это тот же тестировщик.
Мышки станьте ежиками. Ежики станьте мышками (и быстрее, быстрее, побольше, побольше ;))

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

3.3. Есть у нас два объема работ -- для аналитика и для тестировщика. Давайте сделаем "совмещение ролей", и тогда можно взять на работу одного сотрудника, вместо двоих. Экономия!

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

[maksiq]

Я вполне польщен приписываемым мне авторством ...

На здоровье ;) (хотя 'идет' это скорее к действию, то бишь пропаганде ...)
Кто же автор? (аналитика-тестировщика)

Новое - хорошо забытое старое :) Мне уже указали в начале обсуждения, что в 90-х многие так и работали. А в статье я писал, что о тех же подходах говорил Пауль Тернер на REQ-labs как о достаточно известной практике. Наша компания уже много лет работает таким образом.

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

Не передергивание, а гипербола, для лучшей наглядности. И частично успешная - "не поместится в одну голову" (прямо как с шапками ;)). А если еще учесть, что вообще-то голова тестировщика не предназначена для одевания на аналитика (и наоборот), то совсем хорошо ;)

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

[maksiq]

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

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

P.S. Про Canban. Я подозреваю, что IT-Canban сильно отличается от производственного оригинала, но IT-вариант уже достаточно распространился как набор практик и в некоторой ограниченной области - вполне успешен. Как и другие практики.

[maksiq]

...
PS. Да еще момент. Тестировщик также не выберется из "начинающих", если не будет качать скилы в смежной профессии. И наиболее перспективно не кодирование, а системный анализ. Впрочем, проектирование GUI тоже очень перспективно.

Полностью присоединяюсь.

[OVA]

Текущее состояние Nokia в принципе не связано с разработкой ПО, там работают другие, макроэкономические причины. Если вам нужен успешный пример для флейма, можно взять MS, который перешел на agile - естественно, оригинальный, но на то agile и гибкий. Или внутреннюю разработку Дойча, также использующую agile для достижения вполне конкретных результатов. Skype, кстати, тоже вполне успешен. Контекст предложения про Мартина Фаулера я не понял.

Текущее состояние MS тоже напрямую с разработкой ПО никак не связано, потому что разработка ПО это, как ни крути, Cost Center. Те или иные методики могут помочь снизить затраты напрямую или косвенно, а могут не помочь. Но оно как было Cost Center так и останется. Можно взять, например SAP. Он не успешный? Я думаю вполне успешный. Или Oracle.

Я видел как продают за сумасшедшие деньги (удачно, с хорошим таким ростом продаж) плохой софт, разработанный по RUP. И видел как уходят вникуда agile-стартапы. Корелляция "успешности" того или иного продукта и "agile" для меня мягко говоря не очевидна (там все сложнее, чем просто знак "="). А то что вы пишите это как раз попытка сделать "успешность=agile". По крайней мере оно так выглядит и вы не делаете ничего, чтобы говорить о том что на самом деле, вместо чрезмерного рекламного упрощения.

[OVA]

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

Простите, но вот то что вы привели как контрпример это и есть тот самый пресловутый fake testing по James Marcus Bach (уже больше десяти лет с этим вредным явлением борется). Это вообще не совсем то, чем тестирование должно заниматься.

Если же брать мировой опыт, то, например, SFIA выделяет тестировщика как 45 TEST - Testing: The concurrent lifecycle process of engineering, using and maintaining testware (test cases, test scripts, test reports, test plans, etc) to measure and improve the quality of the software being tested. Testing embraces the planning, design, management, execution and reporting of tests, using appropriate testing tools and techniques and conforming to agreed standards (such as ISO 29119), to ensure that new and amended systems, configurations, packages, or services, together with any interfaces, perform as specified.

Простите, но после того как я увидел IEEE 1044 я эти ваши стандарты читать серьезно уже не могу. Почитайте www.satisfice.com (а лучше сразу Jerry Weinberg "Perfect Software And Other Illusions About Testing"), мне такой мировой опыт сильно ближе чем тот удаленный от реальности бред, что пишут в стандартах.

А вот единого аналитика там нет, вместо этого имеем 36 DTAN - Data analysis, 37 REQM - Requirements definition and management, 32 BSMO - Business modelling, 38 DESN - Systems design, 40 DBDS - Database/repository design и некоторые другие.

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

[barancev]

Простите, но вот то что вы привели как контрпример это и есть тот самый пресловутый fake testing по James Marcus Bach (уже больше десяти лет с этим вредным явлением борется). Это вообще не совсем то, чем тестирование должно заниматься.

Пруфлинк?

И вообще, с чем именно борется товарищ Бах? Я вижу в Вашей дискуссии с Максимом вот что:
М: Тестирование должно обеспечивать результат для заказчика, а не просто стремиться к "умозрительному высокому качеству"
С: Бах считает иначе, называя стремление обеспечить результат для заказчика ругательным словом "fake testing"

Предполагаю, что просто в пылу спора утрачена логическая связь, давайте постараемся восстановить её.

[OVA]

Простите, но вот то что вы привели как контрпример это и есть тот самый пресловутый fake testing по James Marcus Bach (уже больше десяти лет с этим вредным явлением борется). Это вообще не совсем то, чем тестирование должно заниматься.

Пруфлинк?

И вообще, с чем именно борется товарищ Бах? Я вижу в Вашей дискуссии с Максимом вот что:
М: Тестирование должно обеспечивать результат для заказчика, а не просто стремиться к "умозрительному высокому качеству"
С: Бах считает иначе, называя стремление обеспечить результат для заказчика ругательным словом "fake testing"

Предполагаю, что просто в пылу спора утрачена логическая связь, давайте постараемся восстановить её.

Пруф на поржать, например: http://www.satisfice...ations/fake.pdf
Там как раз про те тонны стандартов, которые тут maksiq и SALar приводят как то, чем является тестировщик. Про тот сабботаж, который называется в стандартах "perform as specified".

Контрпример это:
"отвечать за пуговицы" и "Который отличен от умозрительно 'высокого качества покрытого тестами продукта'".

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

"Приемлемое качество", да, хорошая концепция. Но опять же - тестировщик не обеспечивает его. Его обеспечивает процесс/команда/менеджер принимающий решения.

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