Тестирование в Agile
#1
Отправлено 08 января 2008 - 07:34
#2
Отправлено 08 января 2008 - 15:51
Подскажите пожалуйста где можно почитать о месте тестирования и тестеровщиков в 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 недели для написания идальной бумаги про то, как нужно тестировать - это, как правило, потерянное время, а месяц на написание [автоматических] тестов - это польза для следующих итераций.
#4
Отправлено 11 января 2008 - 14:56
#5
Отправлено 09 июня 2011 - 16:28
Как вести регресс при agile если меняется логика и некоторые модули начинают работать с точностью до наоборот, а описания нет?
Документировать или нет ?
Как должен вести себя QA в Agile?
#6
Отправлено 09 июня 2011 - 17:23
Любые документы.Подскажите пожалуйста где можно почитать о месте тестирования и тестеровщиков в Agile (SCRUM, XP). Для меня неясным остался вопрос какие документы создаются (требования, спецификации, тест-план, тест-кейс) и создаются ли они вообще. Сложилось впечатление, что "что" и "как" тестировать определяется только на текущий момент.
Agile подход не регламентирует:
* артефакты;
* роли;
* процессы.
В нем лишь говорится, что люди и коммуникации важнее процессов и артефактов. Так что может использовать даже ГОСТ 34 и водопад. это никак не противоречит Agile.
--
Но. Некоторые методологии из семейства Agile рекомендуют определенные практики, процессы и артефакты.
Так в расово верных SCRUM и XP тестировщиков нет и быть не может. Как только появились тестировщики - забудьте про SCRUM и XP. Вы можете остаться в рамках Agile подхода, но это будет другая методология. SCRUM и XP дико негибкие методологии. Что касается настройки процессов ГОСТ 34 и RUP многократно гибче их.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#7
Отправлено 10 июня 2011 - 04:42
Авторы: Лайза Криспин и Джанет Грегори
"Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд"
#8
Отправлено 10 июня 2011 - 05:23
#9
Отправлено 27 ноября 2013 - 11:59
Как покрыть тестами код, если нет ни единого документа как все должно работать?
Если нет документации "на бумаге" значит есть "документация" заложенная у разработчиков, product owner'ов, аналитиков в голове. Одна из задач Agile это тесное общение между членами команды для улучшения производительности самой команды. Вот и нужно этим пользоваться и спрашивать где не ясно.
Как можно менять логику не зная зачем это нужно и каких целей добиваются меняя логику? Должно быть как минимум описание проблемы. Это конечно не полная документация, но создает силуэт того что мы заполним общаясь с разработчиками, product owner'ами, аналитиками и возможно клиентом (если конечно такое возможно)Как вести регресс при agile если меняется логика и некоторые модули начинают работать с точностью до наоборот, а описания нет?
Документировать или нет ?
Зависит от компании, команды, методов. Лично для меня моя документация это Mind Map и чеклисты, чего вполне хватает для того что бы вспомнить некоторые моменты, которые могут быть подзабыты за истечением времени.
P.S. Извиняюсь не посмотрел на дату отправки последнего сообщения....
#10
Отправлено 04 марта 2014 - 15:32
Всем, добрый день, коллеги! )
Если интересно "Worlds most influential Agile tester 2013" Maркус Гартнер дает интервью в блоге: www.a1qa.com/blog
#11
Отправлено 24 апреля 2014 - 13:11
Коллеги, есть такой вопрос: что делать с задачами, которые взяты в итерацию, но "висят", т.к. мы ждём информации от заказчика? Для выполненных, но не подтверждённых задач у нас есть отдельный статус, а вот что делать с выполненными наполовину - непонятно.
#12
Отправлено 24 апреля 2014 - 14:05
Коллеги, есть такой вопрос: что делать с задачами, которые взяты в итерацию, но "висят", т.к. мы ждём информации от заказчика? Для выполненных, но не подтверждённых задач у нас есть отдельный статус, а вот что делать с выполненными наполовину - непонятно.
Можно так:
* Формируете задачу на заказчика,
* Создаете связь с типом "блокирует"
* Переводите исходную в статус заблокировано
PS. Непонятно, чего вы этот то пост написали. Agail здесь точно ни при чем.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#13
Отправлено 24 апреля 2014 - 14:18
Поясню:
Задача висит на скрамборде итерации и портит burndown chart (и остальную отчётность), т.к. не закрыта.
Предложенный подход не решает данной проблемы.
PS: не очень понял... вопрос, собственно, про то, как такие проблемы решаются с т.з. scrum.
#14
Отправлено 25 апреля 2014 - 05:20
С точки зрения скрам, такие задачи не могут висеть и портить доску.
От заказчика всегда присутствует человек способный быстро и без проволочек ответить на вопросы.
Иначе данная задача не должна попадать в разработку, так как не определены её критерии успешности и неверно оценён "вес" задачи в попугаях.
#15
Отправлено 24 августа 2015 - 09:09
Эту статью еще почитайте: http://qawebmart.ru/...a-v-gibkoe.html Из нее понятно, и место тестирования в гибкой разработке и как перейти от "водопада" к аджайлу.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных