Мета тестування - знайти дефекти. Проте, процес не обмежується лише виявленням дефектів. Інформація про ці дефекти повинна бути належним чином передана розробникам, щоб вони могли їх виправити, а звіти про виправлення надані зацікавленим сторонам, щоб не порушити графік розробки програмного продукту. Будь-які неефективні дії, вжиті під час повідомлення, відстеження, виправлення та управління дефектами, призводять до втрати часу. У зв’язку з вищезазначеним, наступні два заходи довели свою ефективність у виявленні дефектів. Перший полягає у виконанні тестів на основі плану тестування, щоб визначити, чи є відмінності між очікуваними та фактичними результатами тестування. Другий вид діяльності пов’язаний з документуванням недоліків, виявлених під час тестування, в системі відстеження проблем. Якість документації має вирішальне значення з двох причин: по-перше, розробникам потрібна достовірна і надійна інформація про дефекти, щоб виправити їх і усунути всі проблеми, викликані ними, а по-друге, тестувальники повинні мати можливість відтворити проблеми, щоб переконатися, що дефект був успішно виправлений. Система, що використовується для документування та відстеження дефектів, є важливим інструментом тестування програмного забезпечення. Служби бета-тестування призначені для того, щоб дати роботу різним людям, які готові виконувати поставлені завдання. Тому для того, щоб стати бета-тестером, не обов’язково володіти спеціальними знаннями в галузі програмного забезпечення. Дефект - це помилка в робочому продукті, такому як технічні вимоги, програмний код або план тестування. Дефект залишається невиявленим до тих пір, поки робочий продукт не буде переглянутий або програма не буде виконана таким чином, щоб отримати очікувані результати. Після виявлення дефект досліджується, щоб визначити, чи викликаний він збоєм у тестуванні, помилкою в програмному коді або помилкою в проектних специфікаціях. Якщо причиною проблеми є тест, а не програмний код, то тест слід виправити, але тоді виявлений дефект слід “проігнорувати”. Також оцінюється ступінь серйозності дефекту: чи відноситься дефект, що тестується, до категорії катастрофічних дефектів, які підлягають обов’язковому усуненню до здачі програмного продукту? Чи проблема настільки серйозна, що суттєво знижує функціональність програмного продукту, але при цьому залишаються відкриті обхідні шляхи, які дозволяють продовжувати процеси тестування та розробки? Або ця проблема не настільки критична, що її вирішення не можна відкласти до майбутніх релізів програмного продукту?