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

[Jazzyekim]

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

[dlg99]

Подскажите пожалуйста где можно почитать о месте тестирования и тестеровщиков в Agile (SCRUM, XP).

http://www.io.com/~w...our_schools.pdf

http://www.context-driven-testing.com/
"Lessons Learned in Software Testing" by Kaner, Bach, and Pettichord

http://testobsessed....alk-nov2006.pdf
http://video.google....974855576235846

http://www.testobses...mination/agile/

http://www.testingre.../node/view/5144

http://www.google.co...G=Google Search

Для меня неясным остался вопрос какие документы создаются (требования, спецификации, тест-план, тест-кейс) и создаются ли они вообще.

use cases, user stories
checklists / brief plans for automated and manual testing (for context-driven style of testing, read about it using links above above)
automated tests (functional/performance/..)
unit tests

Сложилось впечатление, что "что" и "как" тестировать определяется только на текущий момент.

по-моему - неправильное впечатление.
одни из основных целей (с точки зрения тест-инженера) - освободить тест инженера от рутинной работы и дать ему возможность больше думать, убрать разделение "аналитик-дизайнер-тестировщик-...." и расширить обязанности/зону ответсвенности (рутина-то уходит), ускорить взаимодействие с девелоперами.

определятся не на текущий момент, а с учетом того, что на следующей итерации (через 2-3-6 месяцев) будут изменения, новые use cases, новое понимание того, как сделать лучше. Поэтому 3 недели для написания идальной бумаги про то, как нужно тестировать - это, как правило, потерянное время, а месяц на написание [автоматических] тестов - это польза для следующих итераций.

[Plut]

Вот небольшая презентация Scrum vs XP

[rain]

QA в SCRUM
Scrum and XP from the Trenches Chapter 14.How we do testing

[Zaven]

Как покрыть тестами код, если нет ни единого документа как все должно работать?
Как вести регресс при agile если меняется логика и некоторые модули начинают работать с точностью до наоборот, а описания нет?
Документировать или нет ?
Как должен вести себя QA в Agile?

[SALar]

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

Любые документы.
Agile подход не регламентирует:
* артефакты;
* роли;
* процессы.

В нем лишь говорится, что люди и коммуникации важнее процессов и артефактов. Так что может использовать даже ГОСТ 34 и водопад. это никак не противоречит Agile.

--
Но. Некоторые методологии из семейства Agile рекомендуют определенные практики, процессы и артефакты.
Так в расово верных SCRUM и XP тестировщиков нет и быть не может. Как только появились тестировщики - забудьте про SCRUM и XP. Вы можете остаться в рамках Agile подхода, но это будет другая методология. SCRUM и XP дико негибкие методологии. Что касается настройки процессов ГОСТ 34 и RUP многократно гибче их.

[lokostex]

Есть хорошая книга:
Авторы: Лайза Криспин и Джанет Грегори
"Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд"

[Zaven]

Уже заказал, спасибо огромное. Почитаем.

[Werewolfas]

Как покрыть тестами код, если нет ни единого документа как все должно работать?

Если нет документации "на бумаге" значит есть "документация" заложенная у разработчиков, product owner'ов, аналитиков в голове. Одна из задач Agile это тесное общение между членами команды для улучшения производительности самой команды. Вот и нужно этим пользоваться и спрашивать где не ясно.

Как вести регресс при agile если меняется логика и некоторые модули начинают работать с точностью до наоборот, а описания нет?

Как можно менять логику не зная зачем это нужно и каких целей добиваются меняя логику? Должно быть как минимум описание проблемы. Это конечно не полная документация, но создает силуэт того что мы заполним общаясь с разработчиками, product owner'ами, аналитиками и возможно клиентом (если конечно такое возможно)

Документировать или нет ?

Зависит от компании, команды, методов. Лично для меня моя документация это Mind Map и чеклисты, чего вполне хватает для того что бы вспомнить некоторые моменты, которые могут быть подзабыты за истечением времени.


P.S. Извиняюсь не посмотрел на дату отправки последнего сообщения....

[Fame]

Всем, добрый день, коллеги! )

 

Если интересно "Worlds most influential Agile tester 2013" Maркус Гартнер дает интервью в блоге: www.a1qa.com/blog

[comolder]

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

[SALar]

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

Можно так:

* Формируете задачу на заказчика, 

* Создаете связь с типом "блокирует"

* Переводите исходную в статус заблокировано

 

PS. Непонятно, чего вы этот то пост написали. Agail здесь точно ни при чем.

[comolder]

Поясню:

Задача висит на скрамборде итерации и портит burndown chart (и остальную отчётность), т.к. не закрыта. 

Предложенный подход не решает данной проблемы.

 

PS: не очень понял... вопрос, собственно, про то, как такие проблемы решаются с т.з. scrum. 

[BadMF]

С точки зрения скрам, такие задачи не могут висеть и портить доску.

От заказчика всегда присутствует человек способный быстро и без проволочек ответить на вопросы.

Иначе данная задача не должна попадать в разработку, так как не определены её критерии успешности и неверно оценён "вес" задачи в попугаях.

[ProQA_02]

Эту статью еще почитайте: http://qawebmart.ru/...a-v-gibkoe.html Из нее понятно, и место тестирования в гибкой разработке и как перейти от "водопада" к аджайлу.