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