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

Программирование на C# для тестировщиков
онлайн, начало 6 декабря
Python для начинающих
онлайн, начало 11 декабря
Школа для начинающих тестировщиков
онлайн, начало 12 декабря
Комплексная система подготовки к сертификации ISTQB FL (КСП ISTQB)
онлайн, начало 9 декабря
Фотография

Тестирование в 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 256 сообщений
  • Город:Москва


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

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

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

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

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

-- 

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

Блог 255 ступеней

 


#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 256 сообщений
  • Город:Москва


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

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

Можно так:

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

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

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

 

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


  • 0

-- 

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

Блог 255 ступеней

 


#13 comolder

comolder

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

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


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

Поясню:

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

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

 

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


  • 0

#14 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 808 сообщений
  • ФИО: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 анонимных

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