• Тест-план (Test Plan)
• Оценка трудозатрат (Effort Estimation)
• Планирование трудозатрат на тестирование — доклад с SQA Days 15

Шаблоны тест-планов

• http://protesting.ru/documentation/test_plan_template_rup.zip

Тест план (Test Plan) = документ, описывающий весь объём работ по тестированию: описания объекта тестирования, стратегии, критериев начала и окончания тестирования, необходимое оборудование и знания, оценки рисков с вариантами их разрешения.

В общем случае тест-план призван ответить на следующие вопросы:

1. Что НАДО тестировать?
2. Что БУДЕМ тестировать? Привет, Тест-Аналитик.
3. КАК будем тестировать? Привет, Тест-Дизайнер.
   • На каких уровнях будем проводить тестирование?
   • Какие виды тестирования применим?
   • Каким образом будем тестировать — руками или автотестами?
4. КОГДА будем тестировать? Оценка трудозатрат и сроков.
5. Какие РИСКИ возможны? Какие затраты времени, средств и труда они могут повлечь. Степень их влияния на исход проекта, прописать мероприятия по нейтрализации последствий срабатывания рисков

1. Что оцениваем:
   • Человеческие умения: знания и опыт членов команды. Сильно влияют на оценку.
   • Ресурсы: людские, технические, и т.д.
   • Время
   • Стоимость: бюджет.
2. Кто может сделать оценку?
   • Тест-лид
   • Тест-аналитик
   • Ручной тестировщик / автоматизатор тестов
3. Методы оценки трудозатрат:
   1. Экспертный — тестировщик знает функции системы, знает архитектуру системы, имеет представление о сути доработки. Плюсы/минусы/время на оценку
   2. Метод трёх точек (3-point estimation) — метод, который был разработан в NASA для расчёта временных затрат в проектах с уникальными задачами в условиях неопределённости и при наличии нескольких типов рисков. Используется в IT достаточно широко.
      
      
      Для того, чтобы начать применять этот метод, нужно проанализировать предмет доработки и описание реализации:
      • При необходимости, если задача выглядит крупной — разбить задачу на подзадачи;
      • По каждой из подзадач провести аналогии с ранее выполненными задачами ("мы выполняли приблизительно похожую работу, и это заняло у нас столько-то времени);
      • Определить риски и описать мероприятия по устранению этих рисков (что будем делать, если сработал тот или иной риск).
      Предлагаемая формула: WM = (O + 4*BG + P) / 6
      , где:
      WM (weighted mean) — взвешенное значение с учетом рисков и последствий воздействия негативных и позитивных факторов;
      О (opitimistic) — оптимистичное время выполнения задачи, если все пойдет хорошо. Т.е. если не "сработали" ни предполагаемые ни неожиданные риски;
      BG (best guess) — наиболее вероятное по вашим представлениям время, или средняя продолжительность выполнения похожих задач;
      Р (pessimistic) — пессимистичное время выполнения задачи, если сработали все выявленные риски.

      Как видим, суть метода сводится к тому, что мы предполагаем, что с вероятностью 4/6 всё пойдёт так, как было и ранее в подобных случаях, с учётом менее вероятных (по 1/6) отклонений в стороны "всё будет плохо" и "всё пройдёт идеально".

      Чего позволяет добиться метод трех точек:

      • Точности (используется 3 оценки вместо одной)
      • Повышения ответственности членов команды за оценку, поскольку они должны учитывать риски
      • Получить описание рисков в каждой задаче

   3. Декомпозиция доработок — Тестировщик знает, какие модули (архитектурные компоненты) были затронуты доработкой.
      За неимением Аналитиков, требуется Тестировщикам и Разработчикам:
      1. составить список компонентов системы (скрипты, формы, плагины, веб-сервисы, JOBы и т.п.)
      2. составить список БП, проходящих по Системе
      3. составить список тест-кейсов, покрывающих БП, проходящих по Системе
      4. встретиться и построить матрицу соответствия БП <-> компонент
      Это даёт возможность при передачи Сборок в Тестирование — чётко понимать какие тест-кейсы надо пройти
   4. Оценка на основе затрат на Разработку:
      время на тестирование = время на разработку * 2K, где К — коэффициент функциональной сложности разрабатываемой фичи
   5. Прямые подсчёты с ипользованием пунктов "a" и "b" но без субъективных коэффициентов,
      требуется статистика по природе выявленных ошибок в предыдущих спринтах и соответствующему их количеству.

Допустим, Имяреку и Полуэкту поручили оценить свои работы по созданию автотестов по какой-то фиче / релизу.

#	Тип	Активность	Исполнитель работ	Оценка, дн.	Фактические затраты, дн.
1	Работа	Разработка заглушки / мока / синтетического приложения	Полуэкт	3	2
2	Работа	Развёртывание заглушки / мока / синтетического приложения	Полуэкт	2	2
3	Работа	Тест-анализ	Имярек	2	2
4	Работа	Настройка системы	Имярек	1	1
5	Работа	Разработка тест-кейсов + первичное их ручное прохождение	Имярек	2	2
6	Работа	Описать прекондишены (данные, настройки)	Имярек	1	2
7	Работа	Разработка скрипта для соблюдения прекондишенов	Полуэкт	0,5	2
8	Работа	Разработка автотестов	Полуэкт	7	3
9	Работа	Настройка джобов, запуски автотестов (Jenkins CI)	Полуэкт	1	1
10	Риск	Проблемы деплоя	Полуэкт	M	-
11	Риск	Некорректно составленные тест-кейсы, автотесты	Полуэкт , Имярек	N	-
12	Риск	Проблемы с инфраструктурой (k8s, OIDC provider, сеть, ...)	Полуэкт , Имярек	Y	0
13	Риск	Некорректное функционирование доработки, разбор падающих тестов, багрепортинг, консультации	Полуэкт , Имярек	Z	0

Итого:
Полуэкт = 13,5 + риски.
Имярек = 6 + риски.

Какие вообще "статьи расходов" времени у тестировщика

• разгребание авгиевых почт и мессенджеров
• вникание в ТЗ/ФТ Задачи
• составление вопросов и ожидание ответов от Составителей ТЗ/ФТ
• составление/актуализация/дополнение тест-кейсов к Задаче (в отсутствие Аналитиков)
• подготовка/проверка предусловий/предустановок Системы, набора систем на тестовых стендах (в отсутствие Администраторов Системы)
• тестирование Задачи
• создание автотестов по тест-кейсам
• разработка и поддержка в актуальном состоянии тестового фреймворка
• настройка инструментов для запуска автотестов, создание джобов (Jenkins и т.п.)
• запуск автотестовых прогонов
• составление багрепортов по выявленным ошибкам/недочётам
• ожидание фиксов по выявленным и зарепорченным ошибкам. (это время может идти параллельно, если затык по одной задаче — репортим и берём следующую пока та в режиме ожидания фиксов)
• тестирование пофикшенных багов
• оформление отчёта о тестировании
• помощь коллегам по цеху, консультации с ними по рабочим вопросам
• мероприятия внутри отдела тестирования — совещания, митинги, обучение, праздники и т.п.
• мероприятия вне отдела тестирования — совещания по другим проектам, демонстрации, обучение, праздники и т.п.

Без закладывания в свою оценку неизбежной ежедневной рутины, вы никогда не будете до конца честны и с собой и с тем, кому вы эту оценку даёте.