# БИБЛИОТЕКА Статистика Redmine Управление Критическая цепь Требования и IT Системная инженерия Стейкхолдеры Информация Социальные связи Экономика и общество Саморазвитие Логика, интеллект Сумма технологии ТЕСТИРОВАНИЕ Книги и ссылки QA и QC Цикл тестирования Тест план Тест-дизайн и покрытие Баг-репорт Уровни тестирования Виды тестирования Шаблоны документов XPATH Безопасность Нагрузочное Android Автоматизация Selenium WebDriver Генератор ИНН и т.п. РАЗРАБОТКА Ресурсы Цикл разработки ПО Continuous Integration OOP - базис Frontend HTTP/REST основы Apache web-server Регулярные выражения git Javascript Perl Python Полезности в Windows LINUX Ресурсы права, юзеры и группы crontab IP tables SSH консоль (терминал) tips & tricks useful apps БАЗЫ ДАННЫХ SQL MongoDB
Эта страница:
- Расчёт Тестирование->Приёмка
Ещё в этом разделе:
ТЕСТИРОВАНИЕ XPATH Безопасность Нагрузочное Android Автоматизация Selenium WebDriver Генератор ИНН и т.п. Различные расчёты
Другие разделы:
# MONGO DB SQL РАЗРАБОТКА БИБЛИОТЕКА LINUX ТЕСТИРОВАНИЕ
Различные расчёты
Re-invent the Wheel
Расчёт Тестирование->Приёмка

Сам расчёт

Экспериментальный набросок формулы по расчёту времени, необходимого на тестирование Сборки, исправление ошибок к ней, перетестирование и передачу Сборки на установку в Пром:
Часть формулы Результаты
расчёта,
раб.ч.
Результаты
расчёта,
раб.дн.
Чьё время Время,
раб.ч.
Доля
от общего
(округляется вверх до ближайшего целого)
Общее время T =
Время Тестировщика
Та + Ттк + Тт(1 + Кр)
Время Администратора
+ Кт(То + Аа + Ра)
Время Разработчика
+ Ка(То + Аа + Ра + Аи + Те)
+ Кр(То + Аа + Ра + Ри + Ау + Те)
где:
Что Суть Значение, раб.ч.
Та время Тестировщика на анализ документации (ФТ, ТЗ et cetera), получение ответов от Заказчика и Аналитика
Ттк время Тестировщика на составление тест-кейсов
Тт время Тестировщика на прохождение всех кейсов задачи
То время Тестировщика на регистрацию Обращения (потенциального бага)
Те время Тестировщика на проверку фикса ошибки
Аа время Администратора на анализ Обращения от Тестировщика
Аи время Администратора на исправление настроек на тестовой зоне
Ау время Администратора на установку Сборки с фиксом ошибки
Ра время Разработчиков на анализ Обращения от Тестировщика/Администратора
Ри время Разработчиков на исправление Ошибки и передачи Сборки с фиксом
Кт среднее количество ошибок (за последние 2 релиза) на задачу,
причиной которых стало, то что не потребовало каких-либо исправлений со стороны Администратора и Разработчика:
  • невнимательность Тестировщика, неправильные настройки на машине Тестировщика, дубликат Обращения/Ошибки
  • нечёткие непроработанные функциональные требования и/или ТЗ (Тестировщик принял за ошибку то что работает as designed)
Ка среднее количество ошибок (за последние 2 релиза) на задачу,
причиной которых стала ошибка в настройке тестовой среды, что потребовало привлечение Администратора к перенастройке оной.
Кр среднее количество ошибок (за последние 2 релиза) на задачу,
причиной которых стала ошибка в коде

Откуда такая формула

Предположим, что у нас существуют три субъекта воздействия на Задачу

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

Также, предположим, что мы имеем статистику по предыдущим, например, двум релизам в отношении причин Обращений Тестировщика.

Оценка на провод задачи от условного статуса "Тестирование" до "Передано Администраторам на установку на Пром" даётся с попыткой учесть следующие временные затраты:

  • времени Тестировщика на тестирование ФТ и ТЗ, взаимодействие с Аналитиком (задать ему вопрос по непонятным моментам ФТ и в ТЗ, дождаться ответа, указать на ошибки в ФТ/ТЗ, дождаться исправления) и Заказчиком
  • времени Тестировщика на составление тест-кейсов
  • времени Тестировщика на прохождение основных кейсов, достаточных для убеждённости в том что исправленные/добавленные функционал соответствует Техническому Заданию и Функциональным Требованиям.
    Количество прохождений этих проверок принимаем равным 1+N, где N = количество Сборок с исправлениями по задаче.
  • времени Тестировщика на проверку базового функционала системы, затронутого изменёнными/добавленными компонентами Сборки.
    Количество прохождений этих проверок принимаем равным 1+N, где N = количество Сборок с исправлениями по задаче.
  • времени Тестировщика на регистрацию Обращения (0+X, где X - количество Обращений по Задаче), где Обращение это
    • вопрос по ФТ, ТЗ, логике работы системы и т.п.
    • запрос на настройку тестовой среды
    • сообщение об ошибке, которая, вследствие анализа Администратором и/или Разработчиком, может оказаться
    • не ошибкой, а поведением as designed
    • ошибкой настройки тестовой среды
    • ошибкой, требующей исправления в коде, т.е. поставкой новой Разработчиком Сборки
  • времени Тестировщика на проверку Ошибки, исправленной настройками тестовой среды Администратора или новой Сборкой Разработчика
  • времени Администратора на анализ Обращения от Тестировщика
  • времени Разработчика на анализ Обращения от Тестировщика и/или Администратора
  • времени Администратора на исправление перенастройкой тестовой среды
  • времени Разработчика на исправление ошибки
  • времени Администратора на установку Сборки с исправлением ошибки
пока, однако, не учитываются следующие моменты:
  • время на пересогласование Задачи с Заказчиком, ведущие прямо во время релиза к новым Сборкам, хотя такие случаи очень имели место быть в каждом Релизе
  • частые случаи, когда ошибка одной задачи аффектит несколько задач разных Тестировщиков
  • то, когда тестировщик откладывает одну задачу, ожидая деятельности Администраторов/Разработчиков/Аналитика/Заказчика и берёт следующую
  • то, что иногда базовый функционал совпадает по нескольким задачам, а значит не обязательно его тестировать каждому Тестировщику в своей задаче
  • время на "переключение" Тестировщика между задачами (вхождение в контекст), сейчас оно принято за 0
  • ещё что-то о чём я не подумал