Программа / Заявки на доклады / Создание инструментов повышения качества со стороны тестирования.

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

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

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

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

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

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

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

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

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

Докладчики

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

2. Наталья Курашкина , Иннова

На доклад идут: 427 Зарегистрируйтесь, чтобы проголосовать
Назад к списку докладов

Комментарии

Организаторы конференции

Scrumtrek.ru
Agilerussia.ru
 

Платиновый партнер

SkillTrek
Microsoft
 

Золотой партнер

Рамблер
Devprom
Positive Technologies
Luxoft
Deutsche Bank
 

Креативный партнер

ИКРа
 

Серебряный партнер

INNOVA
 

Технический партнер

ЦВеТ
 

Региональный партнер

ScrumGuides