arrow

назад

ask

Вопрос

А делаете ли вы смоук-авторегресы

repost

160

input message

напишите коммент


10 комментов

А что подразумевается под «смоук-авторегрессами»?) Автоматизированный смоук и регресс или что-то другое? И в чем суть?)

0

ответить

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

0

ответить

Наверное для этого есть название я просто не знаю

0

ответить

По описанию похоже на риск-ориентированное тестирование)

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

Ещё интереснее автоматически подбирать тесты с учётом изменений в коде, а полный регресс запускать периодически

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

0

ответить

Звучит разумно, но нас автотестеров мало, а сервисов и тестового покрытия на года работы, поэтому нужно критикал закрыть за пол года год, а потом уже причесывать остальное. Соглашусь история багов не подскажет все проблемные места, но по крайней мере подскажет куда можно копать.

0

ответить

Ну и щас ai трансформация идет, может все и побыстрее будет

0

ответить

При таких вводных начинать с критичных бизнес-сценариев вполне логично)

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

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

А повторяющиеся дефекты стоит отдельно разбирать с разработкой, ручниками и тд и искать причины их появления. Иначе вы просто научитесь быстрее находить одни и те же проблемы)

0

ответить

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

0

ответить

Ну вот, в целом получается одинаково смотрим на этот вопрос) Удачи с реализацией!)

0

ответить

Спасибо!

0

ответить

еще контент автора

пост закреплён — пока закрепить можно только один пост

trash bin
перейти к нему не получится