Аннотация
- Докладчик
- Юля Нечаева
Основной идеей Agile является увеличение ценности разработки для бизнеса. Ваш Капитан.
Тестирование никогда не было созидательной службой. Если тестирование хорошее – оно уменьшает расходы бизнеса. Но дополнительное «value» в продукт тестированием привнести очень трудно.
А вот помешать – очень легко. Неграмотно построенная организация работы может сделать тестирование бутылочным горлышком в проекте, а то и в компании.
Значит, помимо поиска багов, ключевой задачей тестирования является сделать этот поиск настолько гармонично вписанным в общий процесс, чтоб не увеличивать операционные расходы.
Если тестировщики являются частью команды разработки – это просто: планируй тестирование как часть задачи на разработку – да и все. Но что делать, если отдел тестирования обслуживает несколько потоков задач? И у всех заказчиков разные процессы? И все они одинаково требовательные!
У нас получилось построить такой отдел тестирования, который принимает большинство задач принимает в работу сразу же после их постановки.
Ничего необычного, если не уточнить, что:
- подавляющее большинство времени ребята в отделе заняты полезной работой
- планирование практически отсутствует
Я не открою вам секреты, не расскажу про серебряные пули. Я лишь расскажу, какой микс из agile практик и принципов мы используем, чтобы быть успешным отделом тестирования. И буду рада, если это Вам пригодится в работе.
Видео
Для этого доклада нужен подкаст (аудиозапись)?
Презентация
Примечания и отзывы
Обсуждение доклада в блоге докладчицы + посты разъясняющие тему доклада:
- Как сервисному отделу не стать бутылочным горлышком (Юля Нечаева, AgileDays-2011)
Слушал частично. Юля возглавляет не слишком давно созданный отдел тестирования, общий для нескольких команд разработки, которые живут каждая в своем ритме. Судя по всему, до этого были большие проблемы с качеством, которые сейчас их отдел решает. А она делилась опытом организации этого процесса.
К сожалению, в докладе было много о проблемах, но не так много о решениях.
Кроме того, относительно четкое противопоставление «мы-они» — про разработчиков и тестеров, а не про «мы вместе». И, соответственно, договоренности, как у сторон, которым надо отстроить приемлемые правила взаимодействия в условиях противоречащих требований, а сотрудничество для выпуска продукта — оно где-то за рамками. Наверное, оно есть, но в докладе его видно не было.
Из забавного. С точки зрения разработчика, хороший тестер должен заранее знать не только время тестирования, но и количество найденых багов — чтобы разработчики могли заранее запланировать их исправление. И не проверяет повторно — ведь исправили наверняка хорошо.
Из позитивных практик — выявлять те тесты, где работа наиболее неустойчива и начинать с них. Например, web тестировать под chrome.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
