QA_Bible
  • Введение
  • FAQ для новичков
    • Ответы на самые популярные вопросы новичков в чатах
    • Качества и навыки, которыми нужно обладать тестировщику?
    • Что должен знать и уметь Junior? Что спросят на собеседовании?
    • С чего начать обучение и куда развиваться?
    • Как составить резюме?
    • Где искать работу?
    • Как происходит процесс найма?
    • Как проходить собеседование?
    • Начало работы Junior-тестировщика
    • Ошибки в работе у начинающих тестировщиков
    • Как взаимодействовать с коллегами?
    • Перспективы профессии
  • Полезные ссылки
    • Список полезных ресурсов на разных платформах
    • Список ресурсов по инструментам тестировщика
  • Общее
    • QA/QC/Testing
    • Почему требуется тестирование ПО?
    • Качество ПО (Software Quality)
    • Принципы тестирования
    • Верификация и валидация (Verification and Validation)
    • Дефекты и ошибки
    • Серьезность и приоритет Дефекта (Severity & Priority)
    • Альфа- и бета- тестирование (Alpha Testing and Beta Testing)
    • Процесс тестирования (test process) (draft)
    • Техники оценки тестов/оценка трудозатрат на тестирование (Test Estimation)
    • Экономика тестирования/стоимость качества (Cost of quality)
    • Подход к тестированию (Test Approach)
    • Импакт анализ (анализ влияния, Impact Analysis)
    • Анализ первопричин (RCA - Root Cause Analysis)
    • Тестирование со сдвигом влево (Shift left testing)
    • Модель зрелости возможностей (CMM - Capability Maturity Model)
    • Тестовая среда и тестовый стенд (Test Environment/Test Bed)
    • Бизнес-логика (Business logic)
    • Политика отсутствия багов (ZBP - Zero Bug Policy)
    • Независимое тестирование (Independent testing)
    • Роли/должности в команде
    • Эвристики и мнемоники
  • Виды-методы-уровни тестирования
    • Методы тестирования (White/Black/Grey Box)
    • Тестирование методом черного ящика (Black Box Testing)
    • Тестирование методом белого ящика (White Box Testing)
    • Тестирование методом серого ящика (Grey Box Testing)
    • Статическое и динамическое тестирование (Static Testing, Dynamic Testing)
    • Пирамида / уровни тестирования (Test Pyramid / Testing Levels)
    • Модульное/юнит/компонентное тестирование (Module/Unit/Component testing)
    • Интеграционное тестирование (Integration testing)
    • Системное тестирование (System Testing)
    • Приемочное тестирование (AT - Acceptance testing)
    • Основные виды тестирования ПО
    • Функциональное тестирование (Functional/Behavioral testing)
    • Нефункциональное тестирование (Non-Functional testing)
    • Тестирование производительности (Performance testing)
    • Тестирование емкости (Capacity testing)
    • Нагрузочное тестирование (Load testing)
    • Стрессовое тестирование (Stress testing)
    • Тестирование масштабируемости (Scalability testing)
    • Объемное тестирование (Volume testing)
    • Тестирование выносливости/стабильности (Endurance/Soak/Stability testing)
    • Тестирование устойчивости (Resilience testing)
    • Тестирование надежности (Reliability Testing)
    • Тестирование на отказ и восстановление (Failover and Recovery testing)
    • Эталонное и базовое тестирование (Benchmark and Baseline Testing)
    • Тестирование хранилища (Storage testing)
    • Одновременное / многопользовательское тестирование (Concurrency/Multi-user testing)
    • Тестирование сервиса (Service Testing)
    • Тестирование безопасности (Security and Access Control testing)
    • Оценка уязвимости/защищенности (Vulnerability Assessment)
    • Фаззинг-тестирование (Fuzz testing)
    • Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тести
    • Тестирование совместимости/взаимодействия (Compatibility/Interoperability testing)
    • Конфигурационное тестирование (Configuration testing)
    • Инсталляционное тестирование (Installation Testing)
    • Тестирование на соответствие (Conformance/Compliance testing)
    • Тестирование удобства пользования (Usability testing)
    • Тестирование доступности (Accessibility testing)
    • Тестирование локализации, глобализации и интернационализации (Localization/ globalization/internatio
    • Исследовательское тестирование (Exploratory testing)
    • Свободное / Интуитивное тестирование (Adhoc, Ad-hoc Testing)
    • Тестирование поддержки (Maintenance testing)
    • Регрессионные виды тестирования (Regression testing)
    • Тестирование клиентской части и серверной (Frontend testing Vs. Backend testing)
    • Тестирование графического интерфейса/визуальное тестирование (GUI - Graphical User Interface testing
    • Тестирование API (API - Application Programming Interface)
    • A/B тестирование (A/B Testing)
    • Деструктивное и недеструктивное тестирование (DT - Destructive testing and NDT - Non Destructive tes
    • Выборочное/хаотическое тестирование (Random/monkey testing)
    • Тестирование рабочего процесса/воркфлоу (Workflow testing)
    • Тестирование документации (Documentation testing)
    • Как протестировать продукт без требований?
    • Кроссбраузерное тестирование (Cross-browser testing)
    • Тестирование, основанное на рисках (Risk-Based Testing)
    • Разница тестирования ПО и железа (Software Vs. Hardware testing)
    • Тестирование качества данных (Data Quality Testing)
  • Тест дизайн
    • Тест-дизайн и техники тест-дизайна (Test Design and Software Testing Techniques)
    • Static - Reviews
    • Static - Static Analysis
    • Dynamic - White box
    • Dynamic - Black box
    • Dynamic - Experience based
  • Тестовая документация и артефакты (Test Deliverables/test artifacts)
    • Виды тестовой документации
    • Политика качества и политика тестирования (Quality policy and Test policy)
    • Стратегия тестирования (Test strategy)
    • План тестирования (Test plan)
    • Тестовый сценарий (Test scenario)
    • Тест-кейс (Test case)
    • Чек-лист (Check List)
    • Баг-репорт (Defect/bug report)
    • Требования (Requirements)
    • Пользовательские истории (User stories)
    • Критерии приемки (Acceptance Criteria)
    • Виды отчетов (Reports)
    • Базис тестирования (Test basis)
    • Матрица трассируемости (RTM - Requirement Traceability Matrix)
    • Метрики тестирования (Software Test Metrics)
    • Тестовый оракул (Test oracle)
  • Мобильное тестирование
    • Android
      • Архитектура Android OS
      • Архитектура Android Application
      • Тестирование покупок в Android-приложениях
      • Android Developer Settings
      • Android Debug Bridge (ADB)
      • Android Studio для QA
    • iOS
      • Архитектура iOS
      • Архитектура iOS Application
      • Тестирование покупок в iOS-приложениях
      • iOS Developer Settings
    • Особенности в тестировании мобильных приложений
    • Покрытие девайсов
    • Типы мобильных приложений
    • Симуляторы и эмуляторы
    • Основные различия Android/iOS
    • Последнее обновление Android/iOS, что нового?
    • Основные проверки при тестировании мобильного приложения
    • Каким образом тестировщик получает приложение на тест?
    • Как успешно зарелизить продукт в App Store и Google Play
    • Тестирование требований к мобильным приложениям
    • Тестирование push-уведомлений
    • Тестирование дип линков (mobile deep links)
    • Тестирование сохраненных поисков
    • Тестирование рекламы
    • Тестирование просмотренных товаров
    • Middleware
    • Как проверить использование ресурсов на Android
    • Как протестировать приложение для другой страны?
  • Тестирование в разных сферах-областях (testing different domains)
    • Тестирование веб-сайта или веб-приложения (Web application)
    • Тестирование интернет-магазина (eCommerce)
    • Тестирование платежного шлюза (Payment Gateway)
    • Тестирование игр (Game testing)
    • Тестирование VR программного обеспечения
    • Тестирование мессенджера (Messenger)
    • Тестирование чат-бота (Chatbot)
    • Тестирование электронных писем (E-mail)
    • Тестирование интернета вещей (IoT - Internet of Things)
    • Тестирование облачных решений (Cloud testing)
    • Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture)
    • Тестирование микросервисной архитектуры (MSA/Microservices)
    • Тестирование платформы электронного обучения (E-learning platform)
    • Тестирование систем розничной торговли (POS - Point Of Sale)
    • Тестирование банковского ПО (Banking domain applications/BFSI)
    • Тестирование страхового ПО (Insurance)
    • Тестирование в сфере телекоммуникаций (Telecom)
    • Тестирование планирования ресурсов предприятия (ERP - Enterprise Resource Planning)
    • Тестирование миграции данных (ETL)
    • Тестирование баз данных (Database)
    • Другое
  • SDLC и STLC
    • Жизненный цикл разработки ПО (SDLC - Software Development Lifecycle)
    • Жизненный цикл тестирования ПО (STLC - Software Testing Lifecycle)
    • Модели разработки ПО
    • Agile
    • Scrum
    • Подходы к разработке/тестированию (... - driven development/testing)
  • Сети и около них
    • База по сетям
    • Клиент - серверная архитектура (Client-Server Architecture)
    • Микросервисная архитектура (Microservice Architecture)
    • Эталонные модели OSI и TCP/IP
    • HTTP
    • Идентификация ресурсов в сети (Identifying resources on the Web)
    • Веб-сервис (WS - Web service)
    • REST/SOAP/gRPC
    • Socket / WebSocket
      • Сокет/веб-сокет (socket/websocket)
      • Тестирование WebSocket на клиентах
    • Хранилище на стороне клиента (Client-side storage)
    • Кэш (Cache)
    • Аутентификация и авторизация (Authentication and authorization)
    • Рендеринг в интернете (Rendering on the Web)
  • Практическая часть
    • Логические задачи
    • Тестирование полей и форм
    • Примеры задач на собеседованиях и тестовых заданий
    • Платформы для тренировок и квизы
  • Автоматизация (beta)
    • Общее
    • Полезные ссылки
    • Как стать автоматизатором и вопросы с собеседований
    • Что нужно автоматизировать?
    • Виды и инструменты автоматизации
    • Инфраструктура и пайплайн (CI/CD)
    • Процессы и автоматизация проекта с нуля
    • Лучшие практики автоматизации
    • Что такое flaky tests?
    • Мутационное тестирование (Mutation testing)
    • Параллельное тестирование (Parallel testing)
    • Подкожный тест (Subcutaneous test)
    • Разница между coupling и cohesion
    • Другое (ссылки)
  • Контакты
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
  1. Общее

Экономика тестирования/стоимость качества (Cost of quality)

PreviousТехники оценки тестов/оценка трудозатрат на тестирование (Test Estimation)NextПодход к тестированию (Test Approach)

Last updated 3 years ago

Was this helpful?

Стоимость качества (cost of quality): Общая стоимость затрат на задачи обеспечения и проблемы качества, часто разделяемая на стоимость предотвращения, стоимость оценки, стоимость внутренних отказов и стоимость внешних отказов. (ISTQB)

Стоимость качества разработки программного обеспечения - это метрика, которая может помочь превратить программное обеспечение в прибыльный инструмент для компаний. Компании смотрят на ROI, т. е. на прибыль организации от инвестиций в разработку программного обеспечения.

Качество достигается за счет цены, и эта стоимость называется COQ или Cost of Quality.

Чтобы понять, как обстоят дела с тестированием на проекте, нужно проанализировать его эффективность с точки зрения качества создаваемого продукта и процессов. Тут можно рассчитывать плотность дефектов, разрывы, утечки, эффективность тест-кейсов, RC, FDP, DDP, PTC, MTTD, TDE и десятки других метрик тестирования. Но, чтобы определить рентабельность такого тестирования, необходимо считать деньги. Деньги и их возрастающий поток - основная цель заказчика в большинстве случаев разработки ПО.

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

Цена и ценность

Любое качество имеет свою цену. Формально стоимость качества представляют так:

https://s.dou.ua/storage-files/1_715laWF.png
  • COQ = Cost of control + Cost of failure of control или

  • COQ = Cost of Good Software Quality + Cost of Poor Software Quality;

  • Стоимость хорошего качества (COGQ) = Затраты на предотвращение + Затраты на обнаружение;

  • Стоимость низкого качества (COPQ) = Внутренние затраты на отказ + Внешние затраты на отказ.

Если же рассматривать стомость качества в глобальном смысле, то она складывается и из более практических аспектов:

  • Контекст проекта:

    1. Размер, объем и нагрузка. Тут к гадалке не ходи, чем масштабнее продукт, чем больше у него пользовательская аудитория и сложнее начинка, тем больше времени/ресурсов необходимо на его разработку, а значит и на тестирование и поддержку.

    2. Сфера/область. Разработка и тестирование простого веб-сайта и медицинского IT-продукта требуют разного количества времени и ресурсов. Последний продукт обладает более сложным функционалом, поэтому для него, как правило, нужно несколько видов тестирования, больше времени и хороший уровень специалистов.

    3. Качество разработки. Качество кода, его валидность, масштабируемость - все это влияет на стабильность функциональности, а значит и на то, сколько ресурсов понадобится на обеспечение качества и поддержку.

    4. Наличие тестовой документации. Тестовая документация - это такой плацдарм для тестирования. Если она уже есть, то это сократит сроки на погружение и работу. Если нет - это увеличит сроки и бюджет, потому что придется потратить на нее время.

  • Цифры и вводные проекта:

    1. Сколько людей пользуются сервисом;

    2. Сколько людей жалуются на сервис;

    3. Сколько проблем у нас появляется после релиза;

    4. Происходит ли рост/падение бизнеса/денег после релиза;

    5. Какие сроки и успеваем ли мы со сроками релиза;

    6. Насколько довольны ТОПы бизнеса в работе IT-отдела (правда, это не измерить цифрой, но показатель тоже важный).

  • Динамика:

    1. Насколько динамичен продукт - частота обновлений и релизов.

Общая стоимость тестирования достаточно велика, но стоит лишь оценить стоимость плохого тестирования, как она уже кажется вполне приемлемой. Уоррен Баффет как-то сказал, что цена - это то, что вы платите, а ценность - то, что получаете. И не всегда они совпадают. Качество ещё не означает ценность. Попробуйте сегодня продать очень качественную печатную машинку либо убедить заказчика, что для него ценнее будет зарелизить фичу не послезавтра, а через год, ведь за это время вы ещё лучше всё протестите и качество будет выше. Не получится. Дорога ложка к обеду, и time to market никто не отменял.

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

Как происходит оценка проекта

Работа считается в часах, которые рассчитываются по критериям, исходя из контекста и вводных проекта:

  • количество браузеров/устройств для проверки;

  • сложность фич/верстки;

  • документация;

  • сроки;

  • количество человек, которые будут участвовать в проекте и т.д.

Назовем такой подход, в основе которого лежит анализ ценности и экономической целесообразности тестирования, value based, или value driven testing, и рассмотрим его на примере.

QA team состоит из трех Manual QA. Это не Fixed Price проект, и ценообразование тут а-ля Time&Materials. У нас 826 мануальных тестов, нехватка времени и целый вагон проблем с качеством. И стоит задача улучшить и оптимизировать тестовый процесс.

Начнем с масштабной ревизии костов. Не прибегая ни к ПСБУ, ни к МСФО, расходы можно поделить на: капитальные, или CAPEX (покупка серверов, лицензий для софта, виртуалки и так далее), операционные (расходы на прогон нагрузочных и автотестов, работу серверов, репортинг и настройку окружения), прямые (зарплата, расходы на обучение) и косвенные (дебаггинг, повторное тестирование, обновление и исправление тест-кейсов). Для себя также фиксируем постоянные и переменные расходы. Вовсе не обязательно следовать боэмовской COCOMO, всё намного прозаичнее.

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

W = I*T, где

W - трудозатраты, I - постоянная интенсивность труда или наш перформанс, а T - время работы QA.

Краткий стиль оформления, чёткая приоритезация, уменьшение повторений в шагах и прочая оптимизация тест-кейсов помогла сократить их количество с 826 до 611, что, в свою очередь, снизило затраты времени на их прохождение в три раза. Эта активность и выработанные правила игры для всей команды экономили время на проектирование и выполнение тестов на будущее. Пример оптимизации теста:

Аналогичные меры коснулись и активностей по написанию документации (наполнение Wiki-проекта), репортинга и внутренних коммуникаций. Но несмотря на то, что затраты труда (времени) снижались, они достигли своего предела (см. график). Скоуп регрессии увеличивался, и хотя освободившееся часы давали некий запас прочности, нужно было что-то ещё.

Экономия от масштаба

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

Преимущество достигается за счет скорости и снижения простоев - чем быстрее мы получаем деньги и находим дефекты, тем лучше. Увеличение количества проверок при одновременном снижении себестоимости одной проверки неминуемо приводит к экономии на масштабе. Да здравствует её величество автоматизация! Рассмотрим этот процесс через призму экономики:

c = (TFC/Q) + AVC, где

с - себестоимость выполнения одного теста, TFC - общая величина постоянных издержек, Q - количество запускаемых тестов, AVC - средние переменные издержки.

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

Добавление QA Auto в команду увеличило постоянные расходы QA Team, однако в перспективе обещало компенсировать это ростом производительности.

Точка безубыточности автоматизации была достигнута не сразу, а лишь когда значительная часть тестов уже ранилась автоматически. Расчет критического объема тестов для автоматизации можно вычислить, вновь применив экономический анализ:

Критический объем = Постоянные затраты в целом на автоматизацию / (себестоимость выполнения одного мануального теста - переменные затраты на выполнение одного автотеста).

Эффект операционного левериджа начал снижаться, как и средние переменные затраты на тестирование, а у QA Manual стало больше времени на experience-based тестирование. Это позволило повысить оборачиваемость регрессионных ранов и значительно увеличить скоуп спринтов.

Такой положительный тренд говорил о том, что целесообразно увеличить темпы прироста автоматизации, но добавление еще одной единицы QA Auto не вытягивало ROI из-за связанного с этим увеличения постоянных прямых расходов (оплаты труда). Решение было простым и быстрым - взять QA Auto Trainee с испытательным сроком три месяца. При отсутствии дополнительных прямых расходов (оплаты труда второго QA Auto) затраты на онбординг незначительно снизили производительность первого QA Auto, но не изменили общую тенденцию к росту.

Стадо бизонов

Стадо бизонов бежит со скоростью самого медленного бизона, и если ваши автоматизаторы работают быстро, но вынуждены ждать мануальных тестов от QA Manual, то вся их скорость теряет смысл. Это bottleneck проекта, и его нужно срочно исправлять.

Если увеличить контроль за написанием мануальных тестов и привести формат их написания к единому стандарту, значительно уменьшиться время QA Auto на их разбор и конвертацию. Конечно, не нужно бросать все силы на срочную подготовку бессмысленных мануальных тестов для автоматизаторов для галочки. Тесты должны быть надежными сетями для ловли багов, а их поток должен лишь с небольшим запасом покрывать производительность Automation Team.

В противном случае излишнее нагромождение тестов будет бессмысленным, а потери времени на их «простой» экономически необоснованными. Это касается всего процесса тестирования от планирования до составления summary-репорта. Никаких ботлнеков.

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

Недостаточно делать все, что от тебя зависит. Как говорил Деминг, сначала нужно знать, что делать, а тогда уже делать всё, что от тебя зависит, улучшая процессы. А из всех моделей по улучшению мне больше всего нравится TMMi, пятый уровень которой, как говориться, имеет много общего с идеальным мужчиной: все слышали, но мало кто видел.

Но стремится к этому нужно, и если мы намерены нести ценность заказчику, то самое время определиться, где мы сейчас и куда идём. Ведь обычно, как пела группа «Кино», «Все говорят, что мы в-месте, все говорят, но немногие знают, в каком». Внедрение модели по улучшению тестирования - тоже желательная часть вашего value driven testing.

Риск или холодный расчет

Бывает, что, несмотря на найденные баги, принимается решение релизить версию. Такие новости часто демотивируют тестировщиков. Начинаются рассуждения по типу «ну, сами виноваты, что хотят, пусть и делают», «как можно с этим релизить», «смысл было проверять» и так далее. Есть и обратная ситуация, когда тестили-тестили, а багов не нашли особо. Все знают, что ПО, как и человек, не бывает абсолютно здоровым, а бывает недообследованным, поэтому и вопросы возникают «почему мало багов», «как именно проверяли». Но если посмотреть на эти ситуации с точки зрения ценности, то всё станет на места.

Рассмотрим пример. Вы собираетесь релизить фичу, которая принесёт условно $75K. С вероятностью в 40% в этой версии может содержаться критический баг, и если этот дефект просочится к пользователям, то связанные с этим расходы составят $150K. Можно не рисковать - ничего не релизить, но и профита тогда не будет.

Если релизим сразу, то с учетом вероятности появления критического бага ожидаемая чистая выгода составит: $75K - ($150K * 40%) = $15K

Решение

Нет бага

Есть баг

Релизим

75

-75

Не релизим

0

0

Можно потратить деньги на тестирование, пускай тоже $15K. Тестирование может найти баг, а может и не найти, пускай 50/50, или 40% делим на 2. В таком случае вероятность того, что баг попадёт в релиз, снизится с 40% до 20%. Теперь давайте считать деньги:

Решение

Нет бага

Есть баг

Не найден нами

Найден нами

Релизим без тестирования

75k

-75k

-75k

Не релизим

0

0

0

Тестируем и релизим, если только дефект исправлен

-15k

-15k

60k

Тестируем и релизим в любом случае

60k

-90k

60k

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

  • Не релизим вообще: $0K

  • Релизим сразу без тестирования: $15K (это мы уже определили выше)

  • Тестируем и релизим, если только дефект исправлен: −15K * 60% + (-15K * 20%) + 60K * 20% = $0K

  • Тестируем и релизим в любом случае: 60K * 60% + (-90K * 20%) + 60K * 20%= 30K

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

Как следствие, намного важнее величина тестового покрытия (вероятности обнаружения дефектов), чем фактическое количество обнаруженных багов. Это как морской бой. Выигрывает тот, кто добьется большего покрытия поля соперника первым, это важнее, чем просто подбитые корабли.

Тестовые активности будут иметь еще большую ценность, если применять любую из моделей Risk-Based Testing, будь это FMEA, PRA, PRISMA. Тестирование, основанное на рисках, грамотно приоритезирует ваши тесты, научит всю команду и заказчика правильно их искать и оценивать, а в качестве результата обезопасит будущие релизы. Подверженность риску можно найти, перемножив вероятность использования функционала на вероятность фейла и, собственно, цену его последствий. Имплементация такого подхода потребует затрат, однако качество продукта и спокойный сон того стоят.

Теперь, когда риски известны, оценены и нашли выражение в соответствующих приоритетах тестов, наиболее рисковые фичи будут проверены детальнее и в первую очередь.

Леверидж рисков

Использовать результаты финансового анализа при принятии управленческих решений я рекомендую в разных ситуациях.

Рассмотрим пример. На вашем проекте существует вероятность потери данных на тестовом сервере 20%. Если это произойдет, стоимость такой потери (сроки + стоимость восстановления данных) составит $20K.

Оценим риск: 20% * $20K = $4K

Рисков можно избегать, их можно принимать, снижать и передавать. Но что из этого выбрать? Есть вариант внедрить механизм бэкапа и уменьшить риск до 5%. Влияние будет прежним, так как в случае сбоя на сервере мы также потеряем, а стоимость работ по бэкапу составит $2K. Итак:

Вероятность - 5% (после предпринятых мер)

Потери - $20K (такие же)

Оценка риска после 5% * $20K = $1K

Расходы на уменьшение риска - $2K

Risk Reduction Leverage = (Risk Estimation (до) - Risk Estimation (после))/Risk Reduction Cost

Рассчитаем леверидж уменьшения риска: ($4K - $1K) / $2K = 1.5

Полученная величина (>1) говорит о том, что такие меры целесообразны.

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

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

ROI = ((Savings - Costs)/Costs) * 100%

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

Проблема выбора

Допустим, у вас два проекта или две отдельные команды тестировщиков A и Z.

Кому направить средства на развитие и как не ошибиться в расчетах? Ставка дисконтирования проекта A 10%, а проекта Z 12% (из-за более продолжительного срока его реализации).

Показатели

Проекты по тестированию

A

Z

Объем планируемых вложений

70K

68K

Количество периодов эксплуатации

2

4

Сумма планируемого чистого денежного потока

100k

110k

в том числе:

1-й период

60k

20k

2-й период

40k

30k

3-й период

-

30k

4-й период

-

30k

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

Но доллар сегодня дороже, чем будет стоить завтра, поэтому следует определить чистый приведенный доход по каждому проекту:

Тут Fn - объём денежного потока за период n, а r - ставка дисконтирования.

Рассчитав итоговую настоящую стоимость чистых денежных потоков за минусом запланированных вложений, получим:

NPV (A) = 54545 + 33057 - 70000 = 17603

NPV (Z) = 17860 + 23910 + 21360 + 19080 - 68000 = 14210

Еще до расчета внутренней нормы доходности (IRR) очевидно, что более выгодно предоставить бюджет развития тестировщикам проекта A.

Все эти примеры не столько о финансах, как о мировоззрении в тестировании, о понимании смысла своей работы. Какую бы тестовую активность команда не начинала, неплохо бы думать о том, какую ценность она имеет для заказчика и конечных пользователей. Такой подход одинаково полезен всем как директору по тестированию, так и вновь испеченному джуну. Порой стереотипы о том, что созидателем является только разработчик, мешают тестировщику также любить и заботится о продукте как о своём детище. Это как обида злой феи, которую не пригласили на крестины принцессы. Вместо заботы она злорадно ожидает, когда малышка уколется веретеном, а потом скажет: «Я же говорила, тут баг на баге». Но мы не разрушаем, а создаём. Быть лишь хорошим исполнителем, регулярно осваивать бюджет и делать ровно столько, сколько сказали, можно, но и ценность этого соответствующая. Соответствовать ожиданиям - ещё не предвосхищать их.

Источники:

Доп. материал:

https://s.dou.ua/storage-files/2_9xYXzbF.png
https://s.dou.ua/storage-files/3_Av7XUYJ.png
https://s.dou.ua/storage-files/4_F8TVuP2.png
https://s.dou.ua/storage-files/Untitled_design_BWbzhU0.png
https://s.dou.ua/storage-files/11_MHRm7Cu.png

Что нужно знать о Value Driven Testing. Анализируем ценность и экономическую целесообразность тестирования
А чо так дорого: сколько стоит качество IT-продукта
Экономика тестирования
Value Driven Testing
Leadership in test: how much testing is enough?
What Is Cost Of Quality (COQ): Cost Of Good And Poor Quality