Всем привет! Работаю QA аналитиком на достаточно крупном проекте в области WEB и мобильных приложений. Программистом не являюсь, но периодически скрипты для себя пишу, поэтому за качество кода прошу строго не судить. Но сегодня хочется принести немного data science в жизнь тестировщиков и показать, что если не куплены средства автоматического анализа, то кое-что можно написать и самому.

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

С точки зрения команды QA же было интересно узнать больше о нашем процессе регрессионного тестирования. Трудность проекта состоит в большом количестве подключаемых функций и кастомизаций. Количество Feature Flags подключающих те или иные опции стремится к 700. Регресс выполняется еженедельно, успеть протестировать всё возможности нет.

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