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

Question

[vadik_kmv]

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

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

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

Буду рад любым советам по оценке своих задач

Answer 1

[kn0ckn0ck]

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

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

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

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

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

Comments

[vadik_kmv]

Большое спасибо за развёрнутый комментарий!

Система построена на Pega, поэтому бывает так, что с утра кнопка была button, потом вечером кто-то что-то замёрджил и в коде она превратилась в div'ы с пятикратной вложенностью. Нечего говорить и про остальные элементы.

[kn0ckn0ck]

У меня был случай более тяжелый - Dynamics CRM. Там каждую неделю меняется очень сильно структура и нет никаких ИД для привязки вообще, потому что этим заведуют разработчики Microsoft и им плевать на всех остальных :)

В итоге встал вопрос о целесообразности автоматизации тестирования. Руками было проще протестить, чем поддерживать автотесты. Ну это так, к слову.

Еще подумался вариант: не разрывать оценку отдельно по разработке и по автотестированию. Если оценивается история, то у в оценку нужно заложить как разработку, так и актуализацию автотестов. Тогда каждая новая история, которая будет ломать все, будет "стоить" аналитику целый спринт и он задумается об эффективности в первую очередь.