можете перейти, но сначала проверьте ссылку и будьте аккуратны: не вводите по ссылке пароли, номера телефонов и банковских карт, и другие личные данные
https://
уверены, что хотите выйти?
придется авторизоваться заново, а заполненные данные будут удалены
пост закреплён — пока закрепить можно только один пост
что-то пошло не так — попробуйте снова чуть попозже
· 27.10
А что подразумевается под «смоук-авторегрессами»?) Автоматизированный смоук и регресс или что-то другое? И в чем суть?)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 27.10
Это по сути выборочный регресс, то есть анализируем типовость багов, по историческим данным или экспертным путём. Соответственно я сейчас думаю покрыть основные ветки бизнес логики, исключая места , которые допустим методом белого ящика, автотестить не надо, маппинги например, схемы, настройки, параметризация, часть классов эквивалентности может еще что-то. Таким образом снизив скоуп регресса, чтобы укладываться в реально обозримые сроки, а не года на классические регрессы. Кстати вот вроде банальная мысль, а как все меняет подход.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.10
Наверное для этого есть название я просто не знаю
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.10
По описанию похоже на риск-ориентированное тестирование)
А какая вообще проблема сейчас с регрессом? Если долго проверять вручную, то лучше автоматизировать. Если долго выполняются автотесты, можно попробовать запускать их параллельно
Ещё интереснее автоматически подбирать тесты с учётом изменений в коде, а полный регресс запускать периодически
Просто сокращать покрытие на основе истории багов я бы не стал, ибо изменения могут сломать и то, с чем раньше проблем не было
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.10
Звучит разумно, но нас автотестеров мало, а сервисов и тестового покрытия на года работы, поэтому нужно критикал закрыть за пол года год, а потом уже причесывать остальное. Соглашусь история багов не подскажет все проблемные места, но по крайней мере подскажет куда можно копать.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.10
Ну и щас ai трансформация идет, может все и побыстрее будет
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.10
При таких вводных начинать с критичных бизнес-сценариев вполне логично)
А вот историю багов я бы не делал основным критерием. Если в функциональности постоянно находят ошибки, но ей почти никто не пользуется и последствия некритичны, зачем автоматизировать её в первую очередь? Можно когда-нибудь потом)
Я бы больше ориентировался на важность для бизнеса, частоту использования, риски и влияние на другие части системы
А повторяющиеся дефекты стоит отдельно разбирать с разработкой, ручниками и тд и искать причины их появления. Иначе вы просто научитесь быстрее находить одни и те же проблемы)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.10
Согласен, история багов, я планирую использовать в оценке покрытия только поскольку-постольку, в прошлом году особо инфы я из них не смог полезной особо вытащить, надеюсь может за этот год что-то найду.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.10
Ну вот, в целом получается одинаково смотрим на этот вопрос) Удачи с реализацией!)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.10
Спасибо!
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён