Home

Автор: Маарет Пюхяярви (Maaret Pyhäjärvi)
Оригинал статьи
Перевод: Ольга Алифанова

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

На первой картинке был план по постепенному добавлению тестов, нормализованный через стори-пойнты (крайне не рекомендую эту практику) и распределенный во времени – это казалось реалистичным планом на много месяцев. В дополнение к линейной проекции он показывал достигнутый прогресс и проекцию реальности, которая демонстрировала, что мы отстаем.

На второй картинке был план распределения времени на тест-автоматизацию. Или, точнее, визуализация использованного времени – фиксированного плана не было, и это само по себе было проблемой. Однако можно было видеть, что у нас не только маловато времени на автоматизацию в целом – у нас еще и значительно гуляет концентрация на этой задаче.

Объяснить связь двух изображений было легко – отсутствие времени означает отсутствие прогресса. Ну, я так думала. Почему же тогда мы снова отвечали на вопрос столетней давности?

«Почему вы не добавили больше автотестов?»

Работа над тест-автоматизацией велась в команде с фиксированным количеством человек и множеством конфликтующих приоритетов.

• Они должны были работать с бэклогом багов (исправляя их), чтобы количество багов с сотен снизилось до десятков. Это значительные усилия тестирования на подтверждение, разработки на исправление, и снова тестирования на поиск побочных эффектов. Для каждого бага на тестировщиков ложилось две задачи, а на разработчиков – одна.
• Они должны были выпускать множество релизов с веток, в которых команда не вела непрерывную разработку. Это значительные усилия на проверку правильности исправлений и отсутствия побочных эффектов от двух базисов, которыми они обычно не пользовались при тестировании изменений.
• Они должны были изучить новую систему и задокументировать все изученное, чтобы после перехода в другую компанию максимум через год работы проект мог продолжать спокойно существовать.
• Имея фиксированный бюджет и подвергаясь просьбам поработать над новой фичей, они должны были справляться вдвоем там, где раньше работало трое. Начало работы над чем-то новым было обозначено, как важная задача.

Мы задавали неверный вопрос. Нужно было спрашивать, почему мы не выделили достаточных ресурсов на то, что считали важным, и все равно ожидали какого-то прогресса. Почему мы не осознали простую вещь – добавление работы замедляет сроки? Почему мы не поняли, что идеи дешевы, множеством идей можно жонглировать одновременно, но воплощение этих идей в жизнь требует обучения, и просто невозможно без временных затрат?

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

Если вы просите тех же людей делать «все остальное» помимо этой задачи, и эта задача не выполняется, кого, кроме своего отражения в зеркале, вы должны спрашивать, почему получены такие результаты?

Обсудить в форуме