Мнение пользователей о продукте — основное мерило качества работы всей команды. В каждом спринте мы делаем все возможное, чтобы подготовить стабилизированный и соответствующий ожиданиям пользователей релиз. Хотя баги — часть нашей профессии, неприятно узнавать о том, что какие‑то из них проскользнули в продакшн.

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

Будем честны, регрессионное тестирование — не самая увлекательная часть работы. От спринта к спринту его объем растет, а время на прохождение увеличивается. Но необходимость регресса очевидна — достаточно взглянуть постфактум на все «криты и неотложки», от которых мы уберегли пользователя в своем последнем релизе. Оптимизация (пока вынесем автоматизацию за скобки и вернемся к ней позже) кажется логичным решением, но перспектива пересмотра сотен или тысяч кейсов может отпугнуть.

Меня зовут Михайлов Михаил, я работаю руководителем отдела тестирования в команде Polymatica BI. Недавно мне пришлось привести в порядок регрессионное тестирование, что позволило сделать его компактным и эффективным. Оказалось, что несколько простых действий кратно сократят время, необходимое на приведение в порядок регрессионного прогона. В этой статье разберем пять ключевых шагов.