Как стать автором
Обновить

Чтобы сделать продукт качественнее, нужно каждое утро натощак… Кликбейта не будет: оптимизируем тестирование

Время на прочтение4 мин
Количество просмотров5.2K
Всего голосов 4: ↑4 и ↓0+4
Комментарии8

Комментарии 8

Интересная статья. Без воды, только процессы. Круто, жду 2 часть.

Привет! Спасибо, рад, что тебе понравилось. Над второй частью еще работаю. Обязательно опубликую её, как только закончу)

Полезная статья, про движение от хаоса к системе)

Спасибо за статью, жду продолжения)

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

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

Интересная статья. Спасибо!

Вопрос:
Встречали ли какое либо сопротивление внутри команд тестирования/разработки?

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий