Персональные инструменты
 

Как сервисному отделу не стать бутылочным горлышком (Юля Нечаева, AgileDays-2011)

Материал из CustisWiki

Перейти к: навигация, поиск

Аннотация

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

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

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

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

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

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

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

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

  • подавляющее большинство времени ребята в отделе заняты полезной работой
  • планирование практически отсутствует

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

Видео


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

  •  Да, многое понятно и без видео части, есть смысл его прослушать.
  •  Нет, аудиозапись бесполезна (не понять без видео или вообще мало смысла в докладе).

Презентация


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

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

  • Как сервисному отделу не стать бутылочным горлышком (Юля Нечаева, AgileDays-2011)

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

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

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



Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.