Деякі менеджери з тестування створюють структуру розбиття робіт на основі результатів аналізу ризиків для якості. У проєктах з розробки менеджери з розробки створюють структуру розбиття робіт на основі дизайну та вимог. Вони називаються висхідними або ” знизу вгору“висхідних” і “низхідних” методів оцінювання. Висхідні оцінки можна перевірити, використовуючи правила низхідних оцінок. У компаніях, де процеси досягли достатнього рівня формалізації, такі метрики, як функціональні точки і прогнозовані рядки коду, дають низхідні оцінки. Однак у більшості компаній тест-менеджерам доводиться покладатися на прості емпіричні правила, які порівнюють відносні розміри різних фаз проекту розробки. Однак ці емпіричні правила неминуче є неточними і повинні застосовуватися разом зі структурою розбиття, якщо потрібна точна оцінка трудовитрат на проект.

До речі, послуги з тестування електронної комерції доступні кожному, хто хоче зробити свій сайт привабливим для клієнтів. Вони допомагають ритейлерам підготуватися до високих купівельних сезонів.

Одним з найбільш поширених і раціональних методів оцінки вартості тестування програмного забезпечення є визначення оптимального співвідношення кількості тестувальників і розробників. Ми рекомендуємо вам завантажити з Інтернету дві статті про методи, засновані на оцінці співвідношення. Одна з чудових статей була написана Johanna Rothman і називається так: ” Це залежить: Визначення правильного співвідношення розробників і тестувальників“. У ній Ротман представляє підхід до пошуку правильного співвідношення тестувальників і програмістів, заснований на аналізі ризиків, і наводить три контрастні приклади. Вона аналізує зони ризику, пов’язані з продуктом, проектом, його процесами та робочою групою. Ризики продукту включають підвищену складність і великий розмір.

Процесні та проектні ризики включають стислі терміни, відсутність прийнятного процесу розробки, тестування та управління проектом, а також необхідність забезпечення високої якості. Ризики, пов’язані з робочою групою, включають недосвідчених тестувальників, розробників, маркетологів, менеджерів проектів та інших ключових учасників проекту. У статті описано метод аналізу цих ризиків, щоб зрозуміти, чи може збільшення співвідношення тестувальників до програмістів призвести до зменшення ризиків для якості системи. Цей підхід чудово поєднується з багатьма популярними спеціалізованими методиками. На додаток до статті Ротмана можна прочитати ґрунтовну статтю Kathleen A. Iberle та Susan Bartlett ” Як оцінити співвідношення тестувальників і розробників (чи ні)“.