Построение регрессионной тестовой модели
#1
Отправлено 21 декабря 2018 - 13:55
Кто и как строит регрессионную тестовую модель или не строит?
Интересуют подходы, когда модель ~1к параметризированных уникальных тесткесов, ручных.
BPT, чеклисты, классические кейсы, что-то ещё?
Интересуют только практические подходы!
"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс
#2
Отправлено 21 декабря 2018 - 14:45
тогда озвучьте и ваши проблемы, чтобы было понятнее что к чему
#3
Отправлено 21 декабря 2018 - 15:00
Думаю в основном - это актуализация и необходимость ведения такой модели с шагами и параметрами и т.п.
Как вариант, чеклисты под полную ответственность тестировщика или BPT (ALM) с переопределением шагов.
Хотелось бы услышать и другие варианты рабочие. Возможно, кто-то уже писал статью, как это было сделано у них)))
"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс
#4
Отправлено 21 декабря 2018 - 15:14
тут тоже важно какое отношение девелоперов к тестерам? в чем храните тесты?
у вас тестировщики встроены в команды? а команды универсальные либо у каждой своя область и часть продукта?
#5
Отправлено 21 декабря 2018 - 16:17
тут тоже важно какое отношение девелоперов к тестерам?
имею ввиду типа 3к1 или там 5к1, а не "хорошее" или "плохое" :)
#6
Отправлено 21 декабря 2018 - 20:42
"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс
#7
Отправлено 22 декабря 2018 - 10:30
модель ~1к параметризированных уникальных тесткесов, ручных.
как там у вас ситуация по багам? какова эффективность кейсов? находят ли тесты баги? либо баги находят в результате исследовательского тестирования?
подумайте, может там уже "эффект пестицида" и многие тесты уже морально устарели?
а точно ли нужна эта вся параметризация в тестах? можно попробовать переписать в виде облегченного чеклиста и посмотреть как дела пойдут? можно получить выигрыш по качеству за счёт снижения времени на регрессионное тестирование - так как у тестеров будет больше времени тестировать свои фичи, а не бесконечно повторять тесты которые может и багов уже не находят
Думаю в основном - это актуализация и необходимость ведения такой модели с шагами и параметрами и т.п.
содержание такой системы видимо дорого стоит. при соотношении девелоперов к тестерам 5к1 у них видимо и времени нет на актуализацию и ведение. Наверное в обязанности тестеров входит и тестирование новых фич, и багфиксов, плюс регрессионное тестирование - а плюс эти тесты. Был недавно в одном банке, у них тоже куча ручных тестов в майкрософтовской системе - так у них там отношение 3к1, оттуда и время на "посидеть-поредактировать тесты"
скорее универсальные
тогда тесты получаются тоже "ничьи". Если команда меняет какую-то фичу - тогда тестеру из той команды можно дать задание на апдейт соответствующей части регрессионных тестов
модель ~1к параметризированных уникальных тесткесов, ручных.
тут видно что тесты сложные - но ручные тесты не должны быть сложными. Регрессионное тестирование - просто проверить что система в общем работает
типа "работает фича? ну и отлично, тест прошёл". а вот что "фича работает полностью корректно, все поддерживаемые юскейсы" - это пусть юнит, интеграционные и е2е тесты делают. какое у вас покрытие кода авто-тестами?
то есть для регрессионных тестов можно построить облегченную модель, например в виде чек-листа. А вот ваша сложная модель пригодится когда меняют какую-то фичу, чтобы прогнать все эти сложные тесты и удостовериться что фича работает как надо
#8
Отправлено 22 декабря 2018 - 10:56
Поменять инструмент на какой-то другой политика партии не позволяет.
от инструмента особо ничего не меняется
С теоретиками понятно, а вот практиков не видел, тем более это все добро должно ложиться на автоматизацию, частично, естественно. Как строят автоматизацию и тесты статьи пишут, а вот как РТМ что-то не видел.
в том и дело, что хорошая автоматизация - это основа регрессионного тестирования, без неё никуда. Вот например кто-нибудь видел как на конференциях по тестированию компании как Яндекс, Баду и Гугл рассказывают об организации многотысячных параметризованных ручных тестов? Никто не видел... Да просто таких тестов там и нет, да и не надо при наличии нормального автоматизированного тестирования. Намного эффективнее вложить ресурсы компании в автоматизацию, чем в ручную регрессию
#9
Отправлено 22 декабря 2018 - 21:12
У кого есть практический опыт?
"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс
#10
Отправлено 23 декабря 2018 - 09:28
Не похвастаюсь большой практикой, но выскажусь.
В регрессию всегда собирал основной бизнес процесс и бизнес проверки.
Независимо есть автоматизация или нет.
Сейчас работаю с бэк-офисом и здесь с автоматизацией проще. Все основные проверки можно записать в скрипты и прогонять за короткий промежуток времени.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных