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

[Stasde]

Кто использует Agile Testing?
Интересует следущее:
1. Роль документации. В частности - объем, детализация, поддержка требований к системе (спецификаций) и тест-документации.
2. В каких типах проектов применение выгодно, и в каких - нет?
3. Были ли проблемы, неудачи?

[van]

А что это такое? Agile Testing.

[Stasde]

Agile Testing (гибкое, быстрое тестирование) - это из области eXtreme Development.
Используется, наколько я понимаю, если команда применяет eXtreme Programming.

Приветствуется экспертами в области тестирования Bret Pettichord, James Bach, авторами книги "Lessons Learned in Software Testing".

Также, насколько я понимаю, подобное тестирование в большинстве своем основывается на unit testing.

[van]

Есть ли какая - то литература об этом в инете?

[PavelB]

Вот что по поводу Agile Testing первым делом нашёл Гугл
http://www.testing.c...ting-essay.html

[dlg99]

Testing Extreme Programming
by Lisa Crispin, Tip House

ISBN: 032111355

где-то в и-нете есть e-book B)

[van]

Не нашел...
Может намекнете, гд тепло, где холодно :)

[MKay]

Отвечаю на исходные вопросы:

Кто использует Agile Testing?
Интересует следущее:
1. Роль документации. В частности - объем, детализация, поддержка требований к системе (спецификаций) и тест-документации.

По теории исходная требования предоставляется в форме user stories. В нашем проекте на каждый user story разрабатываются фрагменты спецификаций, детализирующие некоторые элементы пользовательского интерфейса, ключевые моменты функционирования и.т.п. Для каждого user story разрабатываются acceptance criteria. Документация дополняется и уточняется одновременно с разработкой. В конечном итоге, эти фрагменты будут оформлены как официальные use cases.
Тестирование подразделяется на 2 этапа: неформальное (exploratory) тестирование на девелоперских daily билдах и формальное на QC билдах.
Тестовая документация разрабатывается на этапе неформального тестирования, одновременно с выполнением exploratory testing. На окончательной стадии неформального тестирования, когда закончены все девелоперские таски, выполняются acceptance tests, составленные на основе ассеptance criteria, завершается эта стадия, когда эти тесты будут успешными. Тесты на данном этапе представляют из себя наброски сценариев будущих функциональных тестов, а результаты тестирования и регистрация дефектов происходит за пределами баг-трекинговой системы.
После того, как в системе реализованы все user stories, относящиеся к одной функциональности, формальное тестирование. На этом этапе завершается написание функциональных тестов, результаты их выполнения и дефекты заносятся в баг-трекинговую систему.

2. В каких типах проектов применение выгодно, и в каких - нет?

Когда наш проект перевели на Agile, пришлось прочитать массу статей и блогов на эту тему.
Исходя из прочитанного, а также из здравого смысла, следует, что Agile можно с успехом применять в небольших проектах, но можно и провалить, если не выполняются ключевые принципы Agile.
Возможно также успешной применение Agile в крупных проектах и аутсорсинговых проектах. При этом требуется некоторая адаптация процесса к специфике проекта.
Риск провала в крупных проектах значительны выше.
Личного опыта работы в проектах разного класса не имею, но исходя из опыта нашего проекта (см. ответ на следующий вопрос), могу только сказать, что для успеха крайне необходимо, чтобы все участники процесса очень хорошо понимали сам процесс, преследуемые цели и свою роль в этом процессе.
Если вы хотите попробовать Agile в стартапном проекте с небольшой командой единомышленников вы скорее всего добьетесь успеха.
Если вы работаете по любому другому процессу, вашей команде скорее всего придется перестраиваться, привыкать и подлаживаться, и, если вам это удастся, вы скорее всего тоже добьетесь успеха, но это будет нелегко.
И в том и в другом случае важно, чтобы вы хорошо понимали для чего это нужно и не копировали существующие best practices, а адаптировали их к нуждам своего проекта и своей команды, не нарушая при этом основополагающих принципов.

3. Были ли проблемы, неудачи?

Проблем - масса. Описывать можно очень и очень долго.
Работаю в крупном аутсорсинговом проекте (ПМ и разработка у них, QC у нас).
После нескольких лет работы по водопадной модели наш проект перевели на Agile. До этого в проекте все шло не лучшим образом (отодвигание дедлайнов по 2 - 3 раза, огромное количество отложенных дефектов, участившиеся жалобы кастомеров на качество продукта и т.п).
Для улучшения ситуации руководство приняло решение о переходе на новый процесс.
К настоящему моменту нет ни одного принципа Agile, который не был бы нарушен. Состояние разработки - катастрофическое. Повлиять на что-либо с нашей стороны почти невозможно. На данный момент риск провала мне видится как огромный, но как оно будет на самом деле пока не могу сказать, время покажет.
Хотя все это демонстрирует не столько недостатки Agile, сколько невозможность команды его выполнить.

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

Для остальных участников данной дискуссии прикладываю файл.

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

•  Agile_Software_Development___ISBN_0201699699.pdf   3,65МБ   172 Количество загрузок:

[AntuanMark]

Кто использует Agile Testing?
Интересует следущее:
1. Роль документации. В частности - объем, детализация, поддержка требований к системе (спецификаций) и тест-документации.
2. В каких типах проектов применение выгодно, и в каких - нет?
3. Были ли проблемы, неудачи?

У нас используеться scrum, что тоже попадает под определение agile.
Тестовая документация упрощена до минимума - используються user stories для каждой итерации, где описываеться какой функционал будет реализован в этой итерации. По каждому пункуту пишуться тест кейсы.
Выгодно применять в условиях, когда часты случаи постоянных изменений требований и нужно быстро реагировать на это.
Проблемы на первых этапах постоянно, до того времени как весь процесс не устаканиться. Но и потом проблемы с постоянным изменением требований, оно хоть и аджайл но всё равно сегодня надо одно, а завтра уже другое. как всегда :)
Ну а ещё, что характерно дял скрама, каждый день проводиться 15-20 минутное собрание - скрам митинг - где каждый рассказывает что сделал вчера, что планирует делать сегодня и какие есть проблемы. после обсуждения и согласования объёмов работ начинаеться рабочий день :)
Вообще я работал и на очень формализованных процессах и на гибких методологиях. И я думаю что будующее за agile всё таки, и это видно по тому скоклько компаний сейчас работают и начинают работать по гибким методологиям.