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

[barancev]

В библиотеку добавлена новая статья "Исследовательское тестирование: В поисках музыки исследования ПО" (перевод с английского языка статьи Jonathan Kohl "Exploratory Testing: Finding the Music of Software Investigation", выполненный Валерием Худобородовым). Автор проводит аналогию между исследовательским тестированием (exploratory testing) и исполнением музыки искусным музыкантом, способным на импровизацию.

В последнее время тема иследовательского тестирования привлекает всё более пристальное внимание русскоязычных тестировщиков. Появились выступления на конференциях, посвященные этому виду тестирования: мини-тренинг Алексея Баранцева на прошедшейTraining Labs, доклад Натальи Руколь на предстоящейTest Labs, весьма вероятно, что эта тема будет затронута и на SECR тоже. А вот статей на эту тему пока на русском языке крайне мало, можно даже сказать совсем нет.

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

Читайте статью...

[DrVal]

Как говорится, не бывает плохих или хороших методологий - бываю подходящие или не подходящие для конкретного проекта.

Для каких проектов эксплоративное тестирование подходит лучше скриптового, а для каких наоборот?
Вопрос неграмотного внедрения оставляем за скобками.

[rlabs]

Для каких проектов эксплоративное тестирование подходит лучше скриптового, а для каких наоборот?
Вопрос неграмотного внедрения оставляем за скобками.

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

Сообщение отредактировал rlabs: 30 августа 2009 - 08:52

[DrVal]

что-то желающих поспорить, что есть exploratory testing нашлось гораздо больше, чем область применения.

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

Т.е. там, где мы имее дело с:
- относительно небольшими проектами
- универсальнымиб квалифицированными и компактно расположенными командами
- некритичными продуктами
- отсутсвием долгосрочной поддержки продукта
- отсутсвием планов автоматизации

Сами гибкие методологие предлагаю здесь не обсуждать :-)

[rlabs]

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

Как суждение - забавно, но совершенно неправильно в каждом пункте. По крайней мере, пока не обосновано.

[barancev]

- относительно небольшими проектами

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

- универсальнымиб квалифицированными и компактно расположенными командами

А компактная расположенность-то зачем?

- некритичными продуктами

Почему? В чём разница между критичными и некритичными?

- отсутсвием долгосрочной поддержки продукта

Чем наличие поддержки мешает проведению исследовательского тестирования?

- отсутсвием планов автоматизации

Чем планы по автоматизации мешают проведению исследовательского тестирования?

[rlabs]

Вообще говоря, думается, такая путаница наблюдается из-за того, что ET принимают за стратегию тестирования, а не за одну из техник.

[Sapiens]

А я не буду вступать в дискуссию и скажу спасибо переводчику, перевод отличный :)

[DrVal]

1. В больших проектах приходится оперировать большими объемами информации. По своей природе отчеты исследовательского тестирования поддаются сруктурированию с большим трудом.
Т.е. консолидация отчета о тестировании проекта будет обходиться достаточно дорого.

2. Опять же, сводить отчетность в распределенных группах будет дорого.

3. В критичных проектах тестовая спецификация должна проходить многочисленные ревью и согласования - с целю выявления дефектов в ней.

4. На всякий случай - под поддержкой я понимал "maintenance". Оставляет ли исследовательское тестирование достаточно артефактов для регрессионого тестирования?

5. Планы автоматизации не мешают. Но в этом случае нужно увязывать скриптовое и исследовательское тестирование, чтобы одно не дублировало другое. Если человек что-то автоматизирует под себя (кто из нас этим не грешит :-)), то как это можно использовать в дальнейшем?

- относительно небольшими проектами

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

- универсальнымиб квалифицированными и компактно расположенными командами

А компактная расположенность-то зачем?

- некритичными продуктами

Почему? В чём разница между критичными и некритичными?

- отсутсвием долгосрочной поддержки продукта

Чем наличие поддержки мешает проведению исследовательского тестирования?

- отсутсвием планов автоматизации

Чем планы по автоматизации мешают проведению исследовательского тестирования?

[DrVal]

А разве техники, выбранные в рамках определенной стратегии, не накладывают на нее ограничения?

Например, из пункта А в пункт Б мы можем добаться на поезде или на машине.
Мы выбрали машину и на полпути встали в пробку. Бросить машину и пересеть на поезд мы уже не можем.

Вообще говоря, думается, такая путаница наблюдается из-за того, что ET принимают за стратегию тестирования, а не за одну из техник.

[barancev]

Например, из пункта А в пункт Б мы можем добаться на поезде или на машине.
Мы выбрали машину и на полпути встали в пробку. Бросить машину и пересеть на поезд мы уже не можем.

Что за предрассудки! Несколько раз ровно так и поступал, пересаживался на метро, чтобы успеть. Или туда на машине, а обратно на метро, потому что встреча оказалась неформальной :)

Меняется контекст -- меняются планы. Не человек для стратегии, а стратегия для человека. Она должна помогать, а не мешать. Если мешает -- меняйте.

[rlabs]

А разве техники, выбранные в рамках определенной стратегии, не накладывают на нее ограничения?

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

Я не буду комментировать "необходимую отчетность", пожалуй, поскольку конкретная техника тестирования и конкретный объем отчетности слабо связаны.

[DrVal]

Но это же по сути рестарт проекта, разве нет? :-)
Потом придется выпускать сервис пак - ехать и забирать машину :-)

Что за предрассудки! Несколько раз ровно так и поступал, пересаживался на метро, чтобы успеть. Или туда на машине, а обратно на метро, потому что встреча оказалась неформальной :)

[DrVal]

А можно все-таки поподробнее - как организовать эффективный drill-down результатов тестирования при исследовательском тестировании?

Я не буду комментировать "необходимую отчетность", пожалуй, поскольку конкретная техника тестирования и конкретный объем отчетности слабо связаны.

[Clauster]

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

[Clauster]

А я не буду вступать в дискуссию и скажу спасибо переводчику, перевод отличный :)

спасибо-пожалуйста! :)

[DrVal]

Я и пришел за форум за пониманием, как можно вписать ET в свой процесс тестирования :-)
И ключевой вопрос для меня - как его можно масштабировать и сочетать с валидацией.

Если верить источникам, то в MS ET используется для вполне локальной задачи - тестирование совместимости с third-party софтом.

Источники:
Alan Page; Ken Johnston; Bj Rollison, How we test software at Microsoft (http://www.microsoft...ooks/11240.aspx)
James Bach, Exploratory Testing Explained (http://www.satisfice.../et-article.pdf)

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

[rlabs]

Я и пришел за форум за пониманием, как можно вписать ET в свой процесс тестирования :-)

Для начала надо понять, а нужно ли его (ET) вписывать? "Нужно" - значит есть какие-то проблемы, которые не решают скрипты и спецификации, или которые можно решить лучше.

Когда понимание "нужно" сформировано, можно уже подумать, как адаптировать ET под свой процесс - как масштабировать и какое testware получать в результате.

[Clauster]

Я и пришел за форум за пониманием, как можно вписать ET в свой процесс тестирования :-)

Вам тут вряд ли кто-то поможет вписать ЕТ в ваш процесс тестирования. Может запросто и не вписаться.

[Quality lab.]

Я не буду комментировать "необходимую отчетность", пожалуй, поскольку конкретная техника тестирования и конкретный объем отчетности слабо связаны.

О как! :) Хорошо, есть задача: детальная отчётность о работающем и неработающем функционале, с traceability с другими проектными артефактами (аналитикой, багами и т.д.ю). Как это сделать при использовании эксплоративного тестирования?

Вам тут вряд ли кто-то поможет вписать ЕТ в ваш процесс тестирования. Может запросто и не вписаться.

О чём и речь.

Иногда адепты контекстной школы передёргивают с уникальностью каждого конкретного проекта, ИМХО. Есть обобщения, которые делать можно и нужно. Я видела успешные agile проекты, где баги ВООБЩЕ не заводятся, а тест-планы вообще не пишутся. И продукты на выходе - супер. Но это были маленькие по срокам и ресурсам проекты (где-то до тысячи человекодней) с идеально подобранными командами. Но при этом я верна концепции, что такие подходы не применимы в проектах-гигантах, не применимы в проектах с высокими требованиями к надёжности (военные, медицинские и т.д.), не применимы в проектах где заказчик предъявляет высокие требования к прозрачности и "согласумости" процесса и т.д.
http://alistair.cock...l light methods
И создание подобных обобщений, как и любое типирование, накладывает риск ошибки, зато существенно экономит ресурсы. В большинстве случаев это более чем оправдано.

Natalya Rukol