@vadik_kmv

Как оценить автотесты в стори-поинтах?

Коллеги, привет!

Занимаюсь автотестированием на проекте. Возник вопрос, что я, вероятно, занижаю оценку своей таске.

Но здесь есть проблемаы:
1) предположим автотест большой, много проверок элементов интерфейса, но они не сложные. Каким образом можно оценить эту задачу, в 1 СП или, может быть, 5, а может, больше? Что мне можно взять за эталон, какой-то стандартный средний автотест?;
2) Каждый спринт падает множество автотестов из предыдущих спринтов, т.к. функционал меняется просто на лету и я трачу огромное количество времени на их обновление и очень часто в ущерб текущим задачам, как быть здесь (обсудить с аналитиками необходимость более тщательного подбора сторей для автоматизации)?

Буду рад любым советам по оценке своих задач
  • Вопрос задан
  • 280 просмотров
Пригласить эксперта
Ответы на вопрос 1
@kn0ckn0ck
Продюсер
1. SP - это линейка для измерения сложности. Что-то совсем простое = 1, что-то сложное = 13. Это относительна шкала, поэтому у всех она своя. Оценки в SP эмпирические, то есть основанные на предыдущем опыте. Если что-то не понятно во сколько оценить, то нужно это разбить на кусочки и каждый оценить в отдельности.

2. У разработчиков есть такая же проблема, обсудите с ними. Она называется "технический долг". Каждое изменение в функциональности требует переписывания чего-то ранее написанного. Эта как-бы лишняя работа крадет время и снижает скорость команды. Очевидно, что с этим нужно бороться.

Я знаю два подхода, которые здесь можно применить:

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

б) Непрерывно улучшать дизайн (кода и тестов) с той целью, чтобы поддержка новых историй не требовала много времени. Это уже только в руках разработчика/тестировщика - делать гибкий дизайн. Банальный пример, в автоматических тестах привязываться не к названиям, и не расположению их внутри модели UI, а только к ИД элементам интерфейса.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы