Quỏ trỡnh kiểm tra được tiến hành ở mọi cụng đoạn phỏt triển của phần mềm và khụng thực hiện trờn chương trỡnh.
Quỏ trỡnh này được thực hiện theo cỏc mức khỏc nhau bao gồm:
Kiểm tra đơn vị (Unit test): được tiến hành cho mỗi đơn vị mó nhỏ nhất đảm bảo chỳng hoạt động tốt.
Kiểm tra tớch hợp (Subsystem integration test): kiểm tra mặt logic và xử lý phự hợp của cỏc khối, kiểm tra việc truyền tin giữa chỳng.
Kiểm tra hệ thống (System test): đỏnh giỏ xem cỏc đặc tả chức năng cú được đỏp ứng khụng, cỏc thao tỏc giao diện cú giống thiết kế khụng…
khi phần mềm được đưa vào sử dụng và thường được tiến hành trờn dữ liệu thực của khỏch hàng. Kiểm tra chấp thuận cú thể phỏt hiện ra cỏc lỗi bị bỏ qua trong cỏc giai đoạn trước do sự khỏc nhau giữa dữ liệu thực và dữ liệu kiểm tra.
Cú hai kiểu chiến lược kiểm tra được ỏp dụng bao gồm:
Kiểu thứ nhất: liờn quan đến logic được kiểm tra như thế nào trong ứng dụng. Chiến lược kiểm tra logic cú thể là black - box hoặc white - box. Chiến lược kiểm tra black - box cho rằng module liờn quan đến đầu vào và đầu ra cỏc chi tiết logic chi tiết được che dấu và khụng cần phõn tớch. Chiến lược black - box cú tớnh hướng dữ liệu. White - box hướng tới việc cho rằng logic đặc trưng là quan trọng và cần phải kiểm tra. White - box đỏnh giỏ một vài hoặc tất cả mặt logic để kiểm tra được tớnh đỳng đắn của chức năng. White - box hướng về logic (giải thuật).
Kiểu thứ hai: liờn quan tới việc kiểm tra được tiến hành thế nào, khụng quan tõm chiến lược kiểm tra logic. Nú là top - down hoặc bottom - up. Top - down coi chương trỡnh chớnh là quan trọng nhất nờn cần phải phỏt triển và kiểm tra trước và tiếp tục trong quỏ trỡnh phỏt triển. Bottom - up cho rằng cỏc module và chương trỡnh riờng rẽ cần được kiểm tra trước và sau đú được kết hợp lại để kiểm tra tổ hợp.
Cỏc chiến lược kiểm tra kể trờn khụng loại trừ lẫn nhau, chỳng cú thể được sử dụng độc lập đồng thời nhằm phỏt hiện hết cỏc lỗi tiềm ẩn.