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

Тим не менш, було б розумно пропустити деякі важливі кроки, якщо ви почнете проектування і розробку тестової системи зараз. Після завершення аналізу ризиків для якості ви зрозумієте, які ризики становлять загрозу для якості системи. Втім, на успішних проектах робоча група знаходить правильний баланс між якістю, можливостями системи, бюджетом і графіком. Якщо припустити, що результати аналізу ризиків якості висічені з каменю, і заявити, що всі рекомендовані дії з тестування і високопріоритетні ризики якості повинні бути покриті, то можна неприпустимо збільшити ризики для функцій, бюджету і графіка. Наприклад, якщо для завершення всіх видів тестування в проекті знадобиться занадто багато часу, проект вийде за рамки бюджету, обсягу і термінів. Якщо ви хочете платити менше за послуги із забезпечення якості та тестування ми запрошуємо до співпраці офшорних qa-спеціалістів. Ці люди здатні вирішити будь-яке технічне завдання, і при цьому ви отримаєте достовірний і точний результат.

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