Поиск ошибок и информирование команды о статусе проекта – это лишь часть функций тестирования. Это необходимо, но недостаточно.

Поиск ошибок и информирование команды о статусе проекта – это лишь часть функций тестирования. Это необходимо, но недостаточно.

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

Выход – перенести выявление багов в полезное время. Ценность добавляет фикс бага, а не его нахождение. Продукт становится лучше, если в нем «не сделали» баг, а не «нашли и пофиксили». Хороший разработчик поставляет код без багов, а не фиксит найденные.

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

• - создание тестов нескольких уровней для Continuous Integration;
• - создание тестовых сред для разных стейкхолдеров продукта;
• - создание бета-версий продукта с автоматической сборкой информации.

Уровень аудитории: практикующие, эксперты

Направления: Engineering & Quality, Team

Докладчик

1. Юля Нечаева, Иннова (Москва)