Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

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

agile
tdd
scrum
development
process
bottle-neck
add
Теги: #<Tag:0x00007fedb9714810> #<Tag:0x00007fedb9714658> #<Tag:0x00007fedb97144c8> #<Tag:0x00007fedb97142e8> #<Tag:0x00007fedb9714158> #<Tag:0x00007fedb9714018> #<Tag:0x00007fedb971bea8>

(Tatyana Durova) #1

Коллеги, а кто что думает о том, как уменьшить дублирование работы в тестировании.

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

Мы работаем в одной смешанной команды. Автотестеры пошарены на две смешанных команды. И agile тренер сказал, что ручное тестирование сейчас в нашей ситуации bottle neck потому что делается лишняя работа.

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

Интересно, работал ли кто-то таким образом и что вы думаете о изначальной проблемы? Плохо или хорошо вообще дублировать тестирование, если плохо, то как этого избегать?


(Богдан Ткаченко) #2

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


(Евгений) #3

Тренер прав. Очевидно, что ручной тестировщик может облегчить себе работу и ускорить тестирование, если все или часть кейсов покрыты автотестами.
Поэтому, если порог вхождения в чтение кода автотестов не высок, то изучение базовых вещей ваших автотестов (открывать пулл реквесты, открывать среду разработки, делать код ревью, запуск тестов) окупится, делая жизнь проще :slight_smile:
Следующим левелом взаимодействия (если у вас еще не так) может быть рекомендации ручного тестировщика команде автоматизации относительно того, какие кейсы необходимо автоматизировать, чтобы упростить жизнь автоматизаторам :slight_smile: