Перейти к содержимому

Техники локализации плавающих дефектов
онлайн, начало 17 августа
Школа для начинающих тестировщиков
онлайн, начало 20 августа
Программирование на Python для тестировщиков
онлайн, начало 14 августа
Тестирование без требований
онлайн, начало 17 августа
Фотография

Тестирование в Agile


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 14

#1 Jazzyekim

Jazzyekim

    Новый участник

  • Members
  • Pip
  • 22 сообщений

Отправлено 08 января 2008 - 07:34

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

#2 dlg99

dlg99

    Специалист

  • Members
  • PipPipPipPipPip
  • 609 сообщений
  • ФИО:Andrey Yegorov
  • Город:Redmond, WA

Отправлено 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 недели для написания идальной бумаги про то, как нужно тестировать - это, как правило, потерянное время, а месяц на написание [автоматических] тестов - это польза для следующих итераций.
  • 0
Andrey Yegorov. Изображение

#3 Plut

Plut

    Новый участник

  • Members
  • Pip
  • 65 сообщений

Отправлено 09 января 2008 - 18:01

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



  • 0

#4 rain

rain

    Активный участник

  • Members
  • PipPip
  • 87 сообщений
  • ФИО:Anna
  • Город:Amsterdam, Kiev


Отправлено 11 января 2008 - 14:56

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

#5 Zaven

Zaven

    Новый участник

  • Members
  • Pip
  • 5 сообщений
  • ФИО:Mikhail Shchegolev


Отправлено 09 июня 2011 - 16:28

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

#6 SALar

SALar

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 279 сообщений
  • Город:Москва


Отправлено 09 июня 2011 - 17:23

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

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

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

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

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#7 lokostex

lokostex

    Новый участник

  • Members
  • Pip
  • 8 сообщений
  • Город:Москва


Отправлено 10 июня 2011 - 04:42

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

#8 Zaven

Zaven

    Новый участник

  • Members
  • Pip
  • 5 сообщений
  • ФИО:Mikhail Shchegolev


Отправлено 10 июня 2011 - 05:23

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

#9 Werewolfas

Werewolfas

    Новый участник

  • Members
  • Pip
  • 7 сообщений
  • ФИО:Дмитрий Пархоменко

Отправлено 27 ноября 2013 - 11:59

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


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


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

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

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


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


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

#10 Fame

Fame

    Новый участник

  • Members
  • Pip
  • 1 сообщений
  • ФИО:Смирнов Вячеслав

Отправлено 04 марта 2014 - 15:32

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

 

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


  • 0

#11 comolder

comolder

    Новый участник

  • Members
  • Pip
  • 26 сообщений
  • ФИО:Батыров Арсений Георгиевич


Отправлено 24 апреля 2014 - 13:11

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


  • 0

#12 SALar

SALar

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 279 сообщений
  • Город:Москва


Отправлено 24 апреля 2014 - 14:05

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

Можно так:

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

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

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

 

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


  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#13 comolder

comolder

    Новый участник

  • Members
  • Pip
  • 26 сообщений
  • ФИО:Батыров Арсений Георгиевич


Отправлено 24 апреля 2014 - 14:18

Поясню:

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

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

 

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


  • 0

#14 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 25 апреля 2014 - 05:20

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

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

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


  • 1

#15 ProQA_02

ProQA_02

    Новый участник

  • Members
  • Pip
  • 1 сообщений
  • ФИО:Смолов Владимир

Отправлено 24 августа 2015 - 09:09

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


  • 0


Школа Тест-Аналитика
онлайн
Организация автоматизированного тестирования
онлайн
Школа тест-менеджеров v. 2.0
онлайн
Тестирование юзабилити (usability)
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале