Home

Автор: Аарон Ходдер (Aaron Hodder)

Оригинал статьи: https://testerkiwi.blogspot.ru/2013/12/thoughts-around-test-estimation-irony.html

Перевод: Ольга Алифанова

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

Тестирование – это эмпирическое техническое исследование, цель которого – позволить заинтересованным лицам принимать информированные решения, касающиеся качества (Кем Кейнер). Следовательно, вопрос «сколько времени уйдет на тестирование?» на самом деле звучит как «Сколько времени понадобится тем, кто принимает решения, чтобы получить достаточно информации для принятия информированного, основанного на рисках решения?»

Итак, первый оценочный вопрос: «Сколько информации нам нужно собрать для поддержки информированного, основанного на рисках решения, в контексте данного проекта?»

Второй оценочный вопрос: «Сколько времени мы потратим на сбор этой информации и ее передачу заинтересованным лицам?» Ответ, конечно, зависит от продукта, его сложности, понимания продукта тестировщиком, понимания продукта другими заинтересованными лицами, доступа к оракулам, присутствия препятствий для тестирования. То есть большое количество ключевых факторов, влияющих на время тестирования, находится абсолютно вне контроля тестировщика. А количество требуемой информации – это то, что может оценить человек, принимающий решение, но никак не тестировщик. Однако от нас требуют подобных оценок.

Как бороться с этой проблемой?

Вот один из способов, которым я проводил оценку времени на тестирование.

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

Ключевые факторы

Визуальная карта тестового покрытия: визуальное представление модели тест-покрытия (больше информации по ссылкам: тут & тут & тут.)

Области тест-покрытия: функции или возможности продукта, или тест-активности, на которые мы можем отвести тестовое время на основании нашей модели тестового покрытия.

Тест-сессия: ограниченная по времени непрерывная сессия тестирования, посвященная работе над областью тест-покрытия.

Предположим, я использую 90-минутные сессии:

ВКТП делится на тест-сессии, то есть на области покрытия, которые, с моей точки зрения, можно протестировать за 90-минутную сессию.

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

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

Продукт хорошо знаком команде, и у нас есть доступ к их знаниям (документация, общение).

Тест-окружение значимым образом отражает реальное окружение.

Детали логина, названия учетных записей, пароли, IP-адреса, ссылки, детали FTP, базы данных и вся прочая необходимая тестировщику информация доступны ему.

У тестировщика есть достаточные права в тест-окружении и внутри приложения, чтобы выполнять тестирование на приемлемом уровне (обычно это означает админ-доступ к приложению и компьютеру).

Если хорошее тестирование опирается на продакшн-данные или данные, похожие на реальные – эти данные должны быть предоставлены – или же возможность создать и сгенерировать такие данные.

Коммуникация между тестировщиками, ПМами, разработчиками, бизнес-аналитиками и другими участниками команды не затруднена из-за географических, политических или прочих ограничений.

Пример:

Это VTCM для программы Digg for Desktop, сделанный мною на недавнем Weekend Testers ANZ exercise:

Кликните на изображение для увеличения

Каждая затененная область представляет собой зону тестового покрытия для 90-минутной сессии. Следовательно, согласно модели, все затененные области эквивалентны в плане трудовых затрат. 12 сессий, 12/3=4, следовательно, чтобы покрыть эту модель, понадобится четыре рабочих дня…

…и в этой оценке мы должны немедленно усомниться.

Однако, теперь у нас есть точка отсчета, которую можно использовать при отслеживании тестирования, основанного на допущениях, которые мы сделали. Если реальность и оценка различаются, мы можем подправить нашу оценку на лету.

Я ни в коем случае не утверждаю, что этот метод точнее (если это вообще возможно), чем любой другой метод. Но он дает визуальную картину работы. По моему опыту, эту модель можно показать кому-то, и этот кто-то скажет «да ты офигел, если считаешь, что это можно проверить всего за 90 минут!». Моя оценка и модель, из которой я вывел эту оценку, едины.

«Как ты посчитал четыре дня?»  - «А давай покажу», могу ответить я. Люди затем смогут критиковать мою оценку, потому что зоны покрытия и модель продукта доступны и видимы любому. Когда мы начинаем тестирование, мы должны сразу же увидеть, если с оценкой что-то не так. В ПО больше багов, чем ожидалось, и мы успеваем провести только две сессии в день? Мы подстроимся. У меня есть карта, которую заинтересованные лица могут использовать для выбора областей, масштаб которых они хотят сократить, так как модель содержит и области, которые я собираюсь тестировать, и то, что я сознательно тестировать не буду. Это почти как меню с указанным ценником. Заинтересованные лица могут выбрать из меню то, что им нравится, и если их бюджет фиксирован, уложиться в него наилучшим образом.

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