Сообщений в теме: 9

[Сергей]

Коллеги, делитесь опытом.

Кто и как строит регрессионную тестовую модель или не строит?

Интересуют подходы, когда модель ~1к параметризированных уникальных тесткесов, ручных.

BPT, чеклисты, классические кейсы, что-то ещё?

Интересуют только практические подходы!

[Spock]

тогда озвучьте и ваши проблемы, чтобы было понятнее что к чему

[Сергей]

Думаю в основном - это актуализация и необходимость ведения такой модели с шагами и параметрами и т.п.

Как вариант, чеклисты под полную ответственность тестировщика или BPT (ALM) с переопределением шагов.

Хотелось бы услышать и другие варианты рабочие. Возможно, кто-то уже писал статью, как это было сделано у них)))

[Spock]

тут тоже важно какое отношение девелоперов к тестерам? в чем храните тесты?

 

у вас тестировщики встроены в команды? а команды универсальные либо у каждой своя область и часть продукта?

[Spock]

 

 

тут тоже важно какое отношение девелоперов к тестерам?

имею ввиду типа 3к1 или там 5к1, а не "хорошее" или "плохое" :)

[Сергей]

Соотношение 5к1, скорее универсальные, разбиться на команды не получается, модульности и микросервисрв нет, инструмент ALM (есть вариант Jira, но кроме тормознутости ALM меня все устраивает). Поменять инструмент на какой-то другой политика партии не позволяет. С теоретиками понятно, а вот практиков не видел, тем более это все добро должно ложиться на автоматизацию, частично, естественно. Как строят автоматизацию и тесты статьи пишут, а вот как РТМ что-то не видел.

[Spock]

 

 

модель ~1к параметризированных уникальных тесткесов, ручных.

как там у вас ситуация по багам? какова эффективность кейсов? находят ли тесты баги? либо баги находят в результате исследовательского тестирования?

подумайте, может там уже "эффект пестицида" и многие тесты уже морально устарели? 

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

 

 

 

Думаю в основном - это актуализация и необходимость ведения такой модели с шагами и параметрами и т.п.

содержание такой системы видимо дорого стоит. при соотношении девелоперов к тестерам 5к1 у них видимо и времени нет на актуализацию и ведение. Наверное в обязанности тестеров входит и тестирование новых фич, и багфиксов, плюс регрессионное тестирование - а плюс эти тесты. Был недавно в одном банке, у них тоже куча ручных тестов в майкрософтовской системе - так у них там отношение 3к1, оттуда и время на "посидеть-поредактировать тесты"

 

 

 

скорее универсальные

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

 

 

 

модель ~1к параметризированных уникальных тесткесов, ручных.

тут видно что тесты сложные - но ручные тесты не должны быть сложными. Регрессионное тестирование - просто проверить что система в общем работает

типа "работает фича? ну и отлично, тест прошёл". а вот что "фича работает полностью корректно, все поддерживаемые юскейсы" - это пусть юнит, интеграционные и е2е тесты делают. какое у вас покрытие кода авто-тестами?

 

то есть для регрессионных тестов можно построить облегченную модель, например в виде чек-листа. А вот ваша сложная модель пригодится когда меняют какую-то фичу, чтобы прогнать все эти сложные тесты и удостовериться что фича работает как надо

[Spock]

 

 

Поменять инструмент на какой-то другой политика партии не позволяет. 

от инструмента особо ничего не меняется

 

 

 

С теоретиками понятно, а вот практиков не видел, тем более это все добро должно ложиться на автоматизацию, частично, естественно. Как строят автоматизацию и тесты статьи пишут, а вот как РТМ что-то не видел. 

в том и дело, что хорошая автоматизация - это основа регрессионного тестирования, без неё никуда. Вот например кто-нибудь видел как на конференциях по тестированию компании как Яндекс, Баду и Гугл рассказывают об организации многотысячных параметризованных ручных тестов? Никто не видел... Да просто таких тестов там и нет, да и не надо при наличии нормального автоматизированного тестирования. Намного эффективнее вложить ресурсы компании в автоматизацию, чем в ручную регрессию

[Сергей]

Яндекс, Баду, Гугл - не убедил. Ко мне с яндекса приходили на собеседование, на авто/ручное, ну ни черта не знают, кроме модных фреймворков и крауд-тестинга. В теории все очевидно.

У кого есть практический опыт?

[Vasiliy]

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