Содержание

Аннотация

Докладчик
Юля Нечаева

Основной идеей Agile является увеличение ценности разработки для бизнеса. Ваш Капитан.

Тестирование никогда не было созидательной службой. Если тестирование хорошее – оно уменьшает расходы бизнеса. Но дополнительное «value» в продукт тестированием привнести очень трудно.

А вот помешать – очень легко. Неграмотно построенная организация работы может сделать тестирование бутылочным горлышком в проекте, а то и в компании.

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

Если тестировщики являются частью команды разработки – это просто: планируй тестирование как часть задачи на разработку – да и все. Но что делать, если отдел тестирования обслуживает несколько потоков задач? И у всех заказчиков разные процессы? И все они одинаково требовательные!

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

Ничего необычного, если не уточнить, что:

Я не открою вам секреты, не расскажу про серебряные пули. Я лишь расскажу, какой микс из agile практик и принципов мы используем, чтобы быть успешным отделом тестирования. И буду рада, если это Вам пригодится в работе.

Видео


Для этого доклада нужен подкаст (аудиозапись)?

Презентация


Примечания и отзывы

Обсуждение доклада в блоге докладчицы + посты разъясняющие тему доклада:

Слушал частично. Юля возглавляет не слишком давно созданный отдел тестирования, общий для нескольких команд разработки, которые живут каждая в своем ритме. Судя по всему, до этого были большие проблемы с качеством, которые сейчас их отдел решает. А она делилась опытом организации этого процесса. К сожалению, в докладе было много о проблемах, но не так много о решениях. Кроме того, относительно четкое противопоставление «мы-они» — про разработчиков и тестеров, а не про «мы вместе». И, соответственно, договоренности, как у сторон, которым надо отстроить приемлемые правила взаимодействия в условиях противоречащих требований, а сотрудничество для выпуска продукта — оно где-то за рамками. Наверное, оно есть, но в докладе его видно не было.

Из забавного. С точки зрения разработчика, хороший тестер должен заранее знать не только время тестирования, но и количество найденых багов — чтобы разработчики могли заранее запланировать их исправление. И не проверяет повторно — ведь исправили наверняка хорошо.

Из позитивных практик — выявлять те тесты, где работа наиболее неустойчива и начинать с них. Например, web тестировать под chrome.

Максим Цепков - AgileDays-2011/Как сервисному отделу не стать бутылочным горлышком



Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Как сервисному отделу не стать бутылочным горлышком (Юля Нечаева, AgileDays-2011)»