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

[barancev]

Там как раз про те тонны стандартов, которые тут maksiq и SALar приводят как то, чем является тестировщик. Про тот сабботаж, который называется в стандартах "perform as specified".

Сергей, тебе враги тестирования уже мерещатся всюду :)
Максим указал на то, что в стандартах (которые вроде бы ради всемирного порядка создаются) и то нет согласия относительно такой роли как "аналитик". Вы с Бахом не согласны с этим?

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

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

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

А вместо этого топикстартер предлагает прилепить ортогональную активность с совершенно другими целями.

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

[maksiq]

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

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

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

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

Успешность = agile прежде всего потому, что идея единого универсального процесса - безвозвратно похоронена. Даже на уровне "возьмите толстую книгу и выберете нужное" (это PMBOK)". Возобладала идея гибкого, адаптивного процесса, адекватного проектам и компании - то есть гибкого процесса. Agile-подход как раз в этом. Да, agile не гарантирует успеха, но отсутствие гибкости - почти гарантирует его отсутствие (хотя, конечно, в конкретном случае может повезти и методология окажется адекватной проекту.

И еще. Разработка ПО - это не "прежде всего Cost Center", тут уже вы начинаете говорить некоторыми баззвордами. Потому как компании разные, и цели - разные.

[maksiq]

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

Пруфлинк?

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

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

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

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

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

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

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

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

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

[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.

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

Это напоминает "После того, как я посмотрел этот дерьмовый детектив - в жизни не буду смотреть детективы. Боевики forever!" На www.satisfice.com автор предлагает различные подходы для организации тестирования уже внутри этой выделеной области. Подходы - разные и наверняка там много полезного. Но рамка - уже задана, он не пишет, чем тестирование отличается от других активностей. Я привел ссылку на документ, отделяющий тестирование от прочих активностей в процессе разработки (их там много). Можно использовать другие определения, если они достаточно распространены. Но это нужно определять, позиция "тестирование - это то, что я считаю тестированием, и оно ортогонально аналитике" - не перспективна.

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

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

Еще раз - тезис об ортогональности активностей тестирования и формулирования требований - это ваше личное мнение. Оно нуждается в обосновании. Практически формулировать требования можно по-разному. Один из эффективных способов постановки задачи - это задание How To Demo - екак будет показано, что задача сделана. А это - почти тоже самое что и How To Test - как проверить эту задачу. Или по-вашему How To Test - тоже аналитическая активность, а тестировщик - лишь исполнитель этого How?

[OVA]

Сергей, тебе враги тестирования уже мерещатся всюду :)
Максим указал на то, что в стандартах (которые вроде бы ради всемирного порядка создаются) и то нет согласия относительно такой роли как "аналитик". Вы с Бахом не согласны с этим?

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

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

И в то же время указал, что в стандартах вроде как есть согласие на счет того что такое тестировщик. Т.е., есть основание полагать что там вопросов у Максима нет. У меня есть.
Про баги...
Я фиксил баги. Более того, я их на горячую фиксил. Не вижу в этом ничего хорошего. Я это мог делать только потому что для этого хватало моих знаний на тот момент. Если бы проблема была более серьезной, то никак не справился бы. Я фиксил баги в софте для тестирования который сам же писал. Но это другое, потому что это система которую я писал, я знаю зачем она мне нужна и я знаю что там чинить. Фиксить баги в тестируемом софте на регулярной основе? Я боюсь у меня бы тогда времени на тестирование совсем не осталось.
Я не дизайнер. Но у меня есть свое мнение насчет дизайна. Только не думаю что мне стоит заниматься дизайном, т.к. моих знаний на это не хватит. Это не в моей компетенции. А чтобы это стало в моей компетенции мне придется очень долго заниматься тем, что сильно отличается от тестирования. Долго. В итоге получится морская свинка.
Могу про футбол добавить, но это будет уже совсем театр абсурда.

А тестировщик работающих только исходя из своих личных высших стандартов это плохой тестировщик.

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

Оценивать требования? Да. Все ли согласовано и нет ли там дыр? Arnold's Laws of Documentation вспоминаются. Все не согласуешь. Дыры будут. Надо другой вопрос задавать. Более того - есть люди вообще без документации работающие и ничего.
Соотносить то что делает программа с реальными потребностями пользователей? Опять же в меру. У меня нет потребности в рекламе в гугле. Более того - она меня порой раздражает. Баннеры - одна из причин по которым я не пользуюсь Яндексом, например. У меня опять нет однозначного ответа на этот вопрос. Надо еще вопросы. Мне их задать?

Меня как математика фраза "немного параллельная" вымораживает. Надо другую.

Активность пересекается.
Для составления требований совсем не нужен продукт, но нужна глубокая проработка кучи вопросов. Сам процесс разработки требований тестировщику пользы мало приносит. А вот результат может быть полезен.
Для тестирования нужно хоть что-то. Потому что нельзя тестировать ничто (хотя...). Требования это просто вспомогательный инструмент в тестировании. Причем в ряде случаев можно вообще без них обойтись. Опять же вспоминаем Arnold's Laws of Documentation, Five Orders Of Ignorance и прочее. система до разработки, в процессе и после это зачастую разные сущности. Разные знания. Внутренности готовой системы, выпущенной в мир и работающей, аналитику, для разработки дальнейших требований, нужны в довольно урезанном виде. У тестировщика исследование самой системы по сути основная деятельность.

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

[OVA]

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

Успешность = agile прежде всего потому, что идея единого универсального процесса - безвозвратно похоронена. Даже на уровне "возьмите толстую книгу и выберете нужное" (это PMBOK)". Возобладала идея гибкого, адаптивного процесса, адекватного проектам и компании - то есть гибкого процесса. Agile-подход как раз в этом. Да, agile не гарантирует успеха, но отсутствие гибкости - почти гарантирует его отсутствие (хотя, конечно, в конкретном случае может повезти и методология окажется адекватной проекту.

И еще. Разработка ПО - это не "прежде всего Cost Center", тут уже вы начинаете говорить некоторыми баззвордами. Потому как компании разные, и цели - разные.

Состояние MS прежде всего связано с юристами, продажниками, маркетингом и так далее и тому подобное. Bing может научиться читать мои мысли и всегда выдавать то что мне нужно прямо сейчас, но одного этого ему на захват 95% рынка уже не хватит. И мне почему-то кажется что юристы там по утрам в кружочек возле доски не встают.

Успешность != agile. Agile лишь средство оптимизации Cost Center под названием "Разработка ПО". Все. Есть еще средства - называются аутсорсинг, например. Дяденьке, который сидит, скажем, в Лондоне и считает деньги все равно как там аутсорсеры организовали себе производство, пока они обходятся в подходящую ему сумму. Как аутсорсеры будут с этим справляться - отдельная история. Наем местных специалистов по пять копеек пучок пока еще местами работает как успешная экономическая модель. Можно еще лучше - написание "единого школьного портала", например.

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

Есть.
Вот буквально сегодняшнее: http://www.satisfice...og/archives/652
Могу больше и из разных источников. Могу с дискуссией (довольно свежей, кстати) о роли тестирования от руководящих постов в тестировании Google, Facebook, eBay (раз уж вам так нравятся громкие названия) и далее по списку (я эту дискуссию ранее в этом топике уже упоминал, но все почему-то проигнорировали).

Встречные вопросы:
А вы искали?
Вы будете читать?

Это напоминает "После того, как я посмотрел этот дерьмовый детектив - в жизни не буду смотреть детективы. Боевики forever!" На www.satisfice.com автор предлагает различные подходы для организации тестирования уже внутри этой выделеной области. Подходы - разные и наверняка там много полезного. Но рамка - уже задана, он не пишет, чем тестирование отличается от других активностей. Я привел ссылку на документ, отделяющий тестирование от прочих активностей в процессе разработки (их там много). Можно использовать другие определения, если они достаточно распространены. Но это нужно определять, позиция "тестирование - это то, что я считаю тестированием, и оно ортогонально аналитике" - не перспективна.

На www.satisfice.com автор пишет о том чем тестирование отличается от других активностей. Много. Но это уже надо вглубь его статей и презентаций закапываться.

Что касается определений - в тестировании вообще плохо с этим. Их распространение весьма неоднородно и часто в разных сообществах одни и те же термины означают разные вещи. Особенно в таких изолированных как постсоветское пространство.

Про ортогональность Леше ответил.

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

[Pulsar]

Как вы себе представляете аналитика, который:
1. Не умеет идентифицировать дефекты.
2. Не умеет описывать дефекты.
3. Не умеет писать тестовые сценарии.
Смешно, правда? Как с таким ворохом неумений можно требования то писать?

Легко, как если бы аналитик не умел запрограммировать алгоритм поиска или не умел управлять ... космическим бомбардировщиком ;)
Это не его задачи. Его задача требования - как это должно работать.

[Pulsar]

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

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

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

С чего вдруг? Аналитик определяет как должно работать, а не проверяет работает ли оно как должно. Если аналитик не "продает билеты в метро" или не печет пирожки, так он уже и не аналитик? ;)

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

Где-то возьмут двух(меньшинство), а где-то не так поймут, а где-то сэкономят ... Хотели как лучше, а получится как всегда ...

А еще, люди исторически шли к специализации (вот странные, да? ;)), пирожные не делает сапожник, сапоги не делает пирожник ...

PS
Что хотел я вроде сказал, а дальше, вобщем похоже здесь моя точка зрения близка к точке OVA.

[maksiq]

Состояние MS прежде всего связано с юристами, продажниками, маркетингом и так далее и тому подобное. Bing может научиться читать мои мысли и всегда выдавать то что мне нужно прямо сейчас, но одного этого ему на захват 95% рынка уже не хватит. И мне почему-то кажется что юристы там по утрам в кружочек возле доски не встают.

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

Успешность != agile. Agile лишь средство оптимизации Cost Center под названием "Разработка ПО". Все. Есть еще средства - называются аутсорсинг, например. Дяденьке, который сидит, скажем, в Лондоне и считает деньги все равно как там аутсорсеры организовали себе производство, пока они обходятся в подходящую ему сумму. Как аутсорсеры будут с этим справляться - отдельная история. Наем местных специалистов по пять копеек пучок пока еще местами работает как успешная экономическая модель. Можно еще лучше - написание "единого школьного портала", например.

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

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

ко дороже, но и дольше, так как
Есть.
Вот буквально сегодняшнее: http://www.satisfice...og/archives/652

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

Могу больше и из разных источников. Могу с дискуссией (довольно свежей, кстати) о роли тестирования от руководящих постов в тестировании Google, Facebook, eBay (раз уж вам так нравятся громкие названия) и далее по списку (я эту дискуссию ранее в этом топике уже упоминал, но все почему-то проигнорировали).

Встречные вопросы:
А вы искали?
Вы будете читать?

Конкретно Google, Facebook, eBay в разрезе тестирования - мне не слишком интересны. Потому как это сильно другой сегмент отрасли, чем тот в котором я работаю. А на общем уровне представление об устройстве в таких крупных компаниях - у меня есть - из общения на конференциях и прочее. Читать интересные вещи - я буду, правда они будут конкурировать с другими, не менее интересными вещами - технологическими. аналитическими и прочими.

Что касается определений - в тестировании вообще плохо с этим. Их распространение весьма неоднородно и часто в разных сообществах одни и те же термины означают разные вещи. Особенно в таких изолированных как постсоветское пространство.

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

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

Тут я согласен. Вообще самое большое достижение agile в моем понимании - он поставил крест на стандартном unify process, даже в варианте "выберите нужное". Но есть другие стандарты, таксономии - в которых люди договариваются о терминах, например, проводят границы между деятельностями. Они - полезны, чтобы называть одним словом одинаковые вещи, а разные вещи - разными.

[maksiq]

Активность пересекается.
Для составления требований совсем не нужен продукт, но нужна глубокая проработка кучи вопросов. Сам процесс разработки требований тестировщику пользы мало приносит. А вот результат может быть полезен.
Для тестирования нужно хоть что-то. Потому что нельзя тестировать ничто (хотя...). Требования это просто вспомогательный инструмент в тестировании. Причем в ряде случаев можно вообще без них обойтись. Опять же вспоминаем Arnold's Laws of Documentation, Five Orders Of Ignorance и прочее. система до разработки, в процессе и после это зачастую разные сущности. Разные знания. Внутренности готовой системы, выпущенной в мир и работающей, аналитику, для разработки дальнейших требований, нужны в довольно урезанном виде. У тестировщика исследование самой системы по сути основная деятельность.

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

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

[maksiq]

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

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

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

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

С чего вдруг? Аналитик определяет как должно работать, а не проверяет работает ли оно как должно. Если аналитик не "продает билеты в метро" или не печет пирожки, так он уже и не аналитик? ;)

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

А еще, люди исторически шли к специализации (вот странные, да? ;)), пирожные не делает сапожник, сапоги не делает пирожник ...

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

[OVA]

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

Я к тому что напрямую разработка денег не приносит, т.к. сама себя она не продает.
Касательно agile в MS и теперь уже в Skype у меня есть свое весьма предвзятое мнение сложившееся на инсайдерской информации. Если коротко - оно крайне негативное и вашего воодушевление я не разделяю. У них очень много тяжелого наследия, которое в организациях такого масштаба очень сложно преодолеть. Это касается не только процессов, но и легасевого кода и т.п.

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

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

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

Ну нет. Barclays считает, что это работает более чем (их собственно Satisfice Inc. и консультировали на тему тестирования). Thoughtworks по аналогичным принципам аутсорсят сами и предоставляют услуги по консалтингу. Список их клиентов можно посмотреть на сайте. Moolya testing работают по тем же принципам, причем аутсорсят именно тестирование. Вышли в плюс в первый же год своего существования. Я могу еще продолжать долго, вы только скажите когда остановиться :)

Вот, кстати, хорошие примеры в живую и с картинками:

Возможно это то, что вы называете тестировщик + аналитик. Возможно нет.

Про средства автоматического тестирования отдельная история. Можно посмотреть keynote от Julian Harthy на PNSQC 2011, там весьма подробно область применимости изложена. Она достаточно узкая. То что многие пытаются заменить автоматическим тестированием вообще все, это, по моему опыту, от непонимания возможностей этих средств и целей тестирования в принципе. А как писал Jerry Weinberg - "лучше никакого тестирования, чем плохое".

Конкретно Google, Facebook, eBay в разрезе тестирования - мне не слишком интересны. Потому как это сильно другой сегмент отрасли, чем тот в котором я работаю. А на общем уровне представление об устройстве в таких крупных компаниях - у меня есть - из общения на конференциях и прочее. Читать интересные вещи - я буду, правда они будут конкурировать с другими, не менее интересными вещами - технологическими. аналитическими и прочими.

О, тогда предлагаю начать с просмотра keynote "Testing is dead" с GTAC 2011, keynote Whittaker'а с аналогичными предпосылками с STARWest 2011, keynote от Julian Harthy на PNSQC 2011 "The Future of Quality". Потом поискать дискуссии на эту тему. Понятно, что это разные школы тестирования, там разные подходы. На мой взгляд это как раз хорошо, потому как вопрос освещают со многих сторон сразу и очень хорошо видно, что несмотря на разницу в подходах

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

Я не думаю, что наличие единого мнения и "договорились" это вообще плюс. Очень хорошо когда разных мнений много. По крайней мере для меня, как тестировщика. Для человека принимающего решения моэет быть проблемой, да.

Тут я согласен. Вообще самое большое достижение agile в моем понимании - он поставил крест на стандартном unify process, даже в варианте "выберите нужное". Но есть другие стандарты, таксономии - в которых люди договариваются о терминах, например, проводят границы между деятельностями. Они - полезны, чтобы называть одним словом одинаковые вещи, а разные вещи - разными.

Да, но в то же время все те же люди теперь стараются сделать ортодоксальный Agile, что само по себе плохо. Это явление в последних статьях от авторов Agile Manifesto принято называть Agile Slaves. В итоге все та же проблема популярности - ортодоксальность, соблюдение ритуалов, а не формы.

[OVA]

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

Первое и самое главное - это "их число все увеличивается" это ваше субьективное мнение или у вас есть хорошая такая статистика с указанием источников и так далее?

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

Третье - это все, как я понимаю, про аутсорсинг?

[maksiq]

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

Первое и самое главное - это "их число все увеличивается" это ваше субьективное мнение или у вас есть хорошая такая статистика с указанием источников и так далее?

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

Третье - это все, как я понимаю, про аутсорсинг?

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

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

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

Тоже нагрузочное тестирование часто превращается в отдельный поток задач подобных обычным задачам в проекте: надо сформулировать сценарии, обеспечивающие нагрузку (это - аналитическая работа), воспроизвести этот поток (при наличии инструментов это близко к созданию тестовых скриптов, а без инструментов - это близко к разработке), а потом - оценивать результаты и разбираться с проблемами. Ну и сделав раз - включить в цикл continious integration. Таким образом, я воспринимаю это как некоторую комплексную активность, требующую разных специалистов. При этом - да, есть специфическая активность специалиста по нагрузочному тестированию, и для ряда проектов она также незаменима, как опытный DBA. Но вот доля таких проектов, на мой взгляд. не велика, и не увеличивается (как и потребность в DBA). Как-то так.

[maksiq]

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

Я к тому что напрямую разработка денег не приносит, т.к. сама себя она не продает.
Касательно agile в MS и теперь уже в Skype у меня есть свое весьма предвзятое мнение сложившееся на инсайдерской информации. Если коротко - оно крайне негативное и вашего воодушевление я не разделяю. У них очень много тяжелого наследия, которое в организациях такого масштаба очень сложно преодолеть. Это касается не только процессов, но и легасевого кода и т.п.

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

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

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

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

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

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

Ну нет. Barclays считает, что это работает более чем (их собственно Satisfice Inc. и консультировали на тему тестирования). Thoughtworks по аналогичным принципам аутсорсят сами и предоставляют услуги по консалтингу. Список их клиентов можно посмотреть на сайте. Moolya testing работают по тем же принципам, причем аутсорсят именно тестирование. Вышли в плюс в первый же год своего существования. Я могу еще продолжать долго, вы только скажите когда остановиться :)

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

Вот, кстати, хорошие примеры в живую и с картинками: ...
Возможно это то, что вы называете тестировщик + аналитик. Возможно нет.
...

Увы, 1.5 часа видео - это не сейчас. Я запомнил, и когда появится время - посмотрю. Тоже касается следующих ссылок - там тоже немаленькие вещи. В любом случае, за ссылки - спасибо.

Про средства автоматического тестирования отдельная история. Можно посмотреть keynote от Julian Harthy на PNSQC 2011, там весьма подробно область применимости изложена. Она достаточно узкая. То что многие пытаются заменить автоматическим тестированием вообще все, это, по моему опыту, от непонимания возможностей этих средств и целей тестирования в принципе. А как писал Jerry Weinberg - "лучше никакого тестирования, чем плохое".

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

Да, но в то же время все те же люди теперь стараются сделать ортодоксальный Agile, что само по себе плохо. Это явление в последних статьях от авторов Agile Manifesto принято называть Agile Slaves. В итоге все та же проблема популярности - ортодоксальность, соблюдение ритуалов, а не формы.

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

[OVA]

Воооот.

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

Промежуточный вывод у меня как и прежде:
1. Говорят много
2. Говорят практически все
3. У кого-то действительно работает и очень похоже на agile как оно и задумывалось
4. Никаких других выводов касательно КПД перевода количества разговоров в качество процесса мы сделать не можем, т.к. нужных данных нет и ближайшее время не предвидится. Т.е. ставить равенство между словами "agile" и "успешность" по меньшей мере спекуляция

Собственно то, о чем я с самого начала и говорил.



Теперь про тестирование.

Автоматические тесты хороши для одной цели - повышение продуктивности. unit->api->gui Тесты это стандартная пищевая цепочка, которая в купе с нормально поставленной работой с CI позволяет на выходе получить более качественный код. Меньше будет тратиться времени на неработающие билды и билда, где почти вся функциональность заблокирована. Экономия налицо, как говорится: "If you think test-first is expensive, try debug-later".
Второй полезный тренд, это вещи типа Continuous Deployment/Delivery + модные на западе (и еще не очень докатившиеся до нас) DevOps. Там очень много практик по раннему обнаружению дефекта не только через тесты, но и через нормальные логи, мониторинги, обработку ошибок и все то, что раньше называлось словом Testability. Обнаружению в том числе на продакшене, т.к. для ряда компаний типа Google это оправданное поведение. Им дешевле чинить баги по мере обнаружения их пользователем.

Это все отличная практика, позволяющая практически избавиться от того тестирования, которое в context-driven school принято называть словом "checking". Т.е. сверка того, что по заявленным сценариям приложение работает, что соответствие требованиям соблюдено (тут я люблю приводить в пример итальянскую забастовку).

Они хороши, когда мы прекрасно понимаем с чем имеем дело. Т.е. делаем все это правильно. Как делать правильно? Это найти очень сложно. Об этом практически нигде не говорят и не пишут. Пишут о том как сделать миллиарды тестов в секунду в облачную пустоту. Это технически не очень трудно, кстати.
Одно из проявлений проблем связанных с непониманием цели и области применения автоматических проверок - Automation Bias. Почитать можно тут: http://citeseerx.ist...p=rep1&type=pdf
Это проблема не только автоматических тестов. Поэтому в Штатах, например, есть целые институты, которые ею занимаются.

Для того чтобы избегать этого и многих других рисков и нужны тестировщики (согласно context-driven school, опять же). Так как для решения проблем Automation Bias, например, нужны люди понимающие все риски автоматических экспериментов, то чего они показывают и что нужно еще проверять. Нужны люди, которые будут заниматься дизайном автоматических тестов (не той детской шалостью под названием "комбинаторные методы", а реальным дизайном). Нужны эксперименты, которые полностью автоматически провести никак нет возможности.

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

В том же нагрузочном тестирование постановка теста и прогон его занимают довольно мало времени (спросите граждан из Яндекса, они про это часто рассказывают), а вот анализ результатов и всякий performance tuning - существенно больше. Делать его автоматически не получится, увы.


Если вы считаете, что у вас нет никаких рисков, которые вы не можете выявить автоматическими проверками, то вам эти эксперименты не понадобятся. Тогда вам не понадобится тестировщик, который будет ставить несколько более сложные эксперименты и проводить исследования (о том какие это могут быть исследования можно поговорить отдельно, но коротко наброшу еще - ux testing, security testing). Так это или нет - решать тому, кто рулит проектом. Нужна ли ему эта информация или нет - так же решать ему.

Это, в кратце, то что я понимаю под тестированием. Сверка продукта с требованиями по заранее заготовленному чеклисту это не тестирование.

[maksiq]

To OWA.

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

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

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

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

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

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

[OVA]

В таком ключе анализ можно притянуть практически к любой деятельности. Вопрос простой - зачем плодить лишние сущности?

Тестирование на выполнение требований != тестирование. Подмножество да, но довольно небольшое и далеко не всегда обязательное. И ограничивать тестировщика тестированием на выполнение требований действительно не стоит, потому что в итоге получается вот такое:

Мы должны проверить, что продукт удовлетворяет тому, что заявлено в требованиях.

Я же считаю что тестирование это скорее вот так:

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

Выявление потенциальных проблем (или их отсутствия) и есть работа тестировщика. Предоставление достаточно полной информации о проблемах тем, кто будет оценивать сопутствующие риски.
Есть требования, есть неявные требования, которых никогда нигде не будет, но которые можно выявить. Аналитик не может написать неявные требования чисто физически.
Есть заказчик. Есть пользователь. Это далеко не всегда одни и те же лица. Более того, хороший продукт это далеко не все множество того чем доволен заказчик. К тому же есть другие лица, которые так или иначе важны для продукта (для детских игр пользователи это дети, но родители так же весьма важны для создателей программы). Их выявление это так же активность тестировщика. Общение со всеми ними зачастую невозможно, а в общении во многом и заключается работа аналитика составляющего требования. Аналитик это зачастую своего рода агент бизнеса, агент заказчика. Это уже небольшое противоречие.
Grounded Theory во многом похожа на тот подход, который приходится использовать. Поиск информации из различных источников и попытки выявлять в собранных данных шаблоны, потенциальные проблемы и просто интересные наблюдения.
Failure Models, цели бизнеса, данные, готовый код, используемые технологии, результаты предыдущих тестов характеристики качества и многое другое - это объекты с которыми приходится работать. Они частично пересекаются с объектами с которыми приходится работать аналитику при составлении требований, но пересечение далеко не полное.
Характеристики качества от продукта к продукту могут меняться. Есть внутренние характеристики качества, до которых аналитику, как правило, нет дела и работа над которыми может вестись только при наличии готового продукта.

Это все тестирование. Не вижу чем оно ограничивает. Там очень много работы.



А вот это мне просто не нравится:

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

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

[maksiq]

Тестирование на выполнение требований != тестирование. Подмножество да, но довольно небольшое и далеко не всегда обязательное. И ограничивать тестировщика тестированием на выполнение требований действительно не стоит...

Естественно. Тестирование на выполнение требований - лишь часть тестирования. А размер этой части - зависит от проекта. И во многих проектах он как раз довольно велик.

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

А определение - мне безусловно нравится.

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

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

А вот это мне просто не нравится:

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

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

Тут вот какая ситуация. Размер эффективно работающей команды для сложных задач - 5-7 человек. Это выявлено на опыте и проверено экспериментально, например, Белбиным. При большем количестве человек - возрастают накладные расходы на коммуникации, при меньшем - не хватает разнообразия личностей. Потому что команда действительно должна работать автономно, не нуждаясь во внешнем вмешательстве, что, в том числе, означает дублирование, достаточное чтобы болезнь или отпуск одного человека не сказались на автономности команды (а в идеале - если при двух отсутствующих она все равно работала). При таком ограничении сверху внутри команды не может быть слишком много специализаций, и они должны касаться тех активностей, которых много. Собственно, поэтому мы пришли к тому, что роли аналитика и тестировщика совмещаются - тогда в команде есть разработчики, аналитики-тестировщики и еще руководитель, для которого тоже обычно есть дублер.

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

[SALar]

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

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



Из статистики Путнэма следует, что 7 кросфункциональных разработчиков сделают такой проект быстрее, чем 3 аналитика + 7 программистов + 4 тестировщика.

Прикрепленные файлы

•  макконел.PNG   245,57К   13 Количество загрузок: