Thay vì kiểm thử là gì, là một câu hỏi quan trọng đối với tất cả các nhóm. Kiểm thử là phương án cuối cùng và việc chọn cách ưu tiên kiểm thử các phần khác nhau của cơ sở mã có thể khó khăn.
Cách tốt nhất để ưu tiên là dựa trên cơ sở mã và mục tiêu của nhóm bạn. Tuy nhiên, điều quan trọng cần nhớ là mặc dù tốn ít thời gian và băng thông để viết nhiều chương trình kiểm thử nhỏ (ở cuối kim tự tháp kiểm thử, chẳng hạn như kiểm thử đơn vị) có nhiều mức độ sử dụng mã, nhưng không hẳn là giảm được rủi ro chung cho dự án.
Bạn có thể chọn nội dung cần kiểm thử trước tiên bằng cách cân nhắc các trường hợp sử dụng chính của ứng dụng, trang web hoặc thư viện. Điều này có thể là bằng cách viết mã kiểm thử thành phần trên các phần quan trọng của trang web (các thành phần cốt lõi làm nền tảng cho trải nghiệm của người dùng). Ví dụ: các nhà phát triển của một trang web cho phép người dùng tải lên và quản lý dữ liệu chuỗi thời gian nên hình dung và thử nghiệm các cách mà người dùng có thể thực hiện các thao tác đó.
Một phương pháp khác để sắp xếp mức độ ưu tiên là thu thập nhiều thông tin nhất. Nếu trong cơ sở mã của bạn có một phần "nguy hiểm", bị cũ hoặc được viết sai cách mà không ai trong nhóm muốn làm việc này, thì bạn nên xây dựng các bài kiểm thử liên quan đến phần đó để giúp hành vi của nó nhất quán hơn trước khi bạn bỏ qua thêm hoặc tái cấu trúc để khắc phục vấn đề. Hãy xem việc này giống như việc giàn giáo cho một toà nhà đã bị kết án nhưng vẫn chứa trung tâm dữ liệu của bạn.
Chiều rộng
Chúng tôi đã giới thiệu khái niệm về kim tự tháp kiểm thử hay một hình dạng kiểm thử khác, nhưng các phương pháp này có xu hướng chỉ thể hiện một phương diện kiểm thử duy nhất: một dòng đi từ phạm vi nhỏ, kiểm thử đơn vị đơn giản đến kiểm thử phức tạp, có phạm vi rộng, bao gồm kiểm thử đơn vị và kiểm thử tích hợp so với kiểm thử toàn diện.
Tuy nhiên, một số danh sách dài các loại kiểm thử có thể có không thể hiện mức độ phức tạp mà thay vào đó đại diện cho mục tiêu hoặc kỹ thuật kiểm thử. Ví dụ: kiểm thử khói là một danh mục kiểm thử khác, có thể là kiểm thử đơn vị, từ đầu đến cuối hoặc các loại kiểm thử khác, nhưng nhằm giúp người kiểm thử yên tâm tổng thể rằng dự án đang được kiểm thử đang ở trạng thái hợp lệ. Việc kiểm thử hình ảnh cũng có thể hữu ích khi áp dụng cho một thành phần nhỏ hoặc trên toàn bộ trang web của bạn.
Cơ sở mã của bạn sẽ có những yêu cầu riêng. Ví dụ: trong cơ sở mã của bạn, điều quan trọng hơn là cần phải điều chỉnh trên một tính năng duy nhất, đó là viết nhiều loại kiểm thử để đảm bảo hoạt động chính xác. Một tính năng mới cần kiểm thử hiếm khi là một thành phần, hàm hoặc phương pháp tiếp cận duy nhất. Đồng thời, tác động của nó đối với dự án của bạn có thể được phân phối rộng rãi và ở nhiều quy mô.
Các mức độ ưu tiên thử nghiệm cũng có thể phụ thuộc vào nhu cầu kinh doanh của bạn. Các hệ thống kỹ thuật cao có thể yêu cầu kiểm thử đơn vị phức tạp để xác nhận rằng một thuật toán riêng biệt hoạt động chính xác, trong khi các công cụ có tính tương tác cao có thể tập trung vào việc kiểm thử hình ảnh hoặc kiểm thử toàn diện để xác nhận rằng phương thức nhập bằng cách chạm phức tạp tạo ra phản hồi chính xác.
Phương pháp kiểm thử của bạn
Hãy cố gắng tập trung vào việc kiểm thử các trường hợp sử dụng trong cơ sở mã của bạn, bất kể quy mô của các trường hợp đó. Hãy hình dung cách người dùng có thể sử dụng bất kỳ phần nào trong dự án của bạn. Phần này có thể đại diện cho một thành phần duy nhất hoặc một hàm cấp thấp hơn hoặc một trường hợp sử dụng tổng thể từ đầu đến cuối. (Điều này cũng có thể cho thấy thiếu sót trong các thành phần trừu tượng ở bất kỳ quy mô nào, nếu bạn thấy rằng bài kiểm thử không thể tương tác gọn gàng với mã đang kiểm thử.)
Điều quan trọng là mỗi trường hợp kiểm thử có một mục tiêu được xác định rõ ràng. Các quy trình kiểm thử "toàn bộ" lớn có thể khó sử dụng, giống như trong mã không phải kiểm thử của bạn.
Bên cạnh quy trình phát triển dựa trên kiểm thử
Phát triển dựa trên kiểm thử (TDD) là một phương pháp độc đáo để kiểm thử (trực giao với quy mô hoặc kiểu) trong đó bao gồm việc viết các chương trình kiểm thử có khả năng sẽ thất bại (ít nhất là vào lúc đầu). Cách này có thể áp dụng cho cả kiểm thử thủ công và tự động: bạn mô tả mục tiêu mình muốn đạt được, tìm hiểu xem giải pháp hoặc mã hiện tại còn thiếu gì trong giải pháp hoặc đoạn mã hiện tại, rồi dùng lượt kiểm thử không thành công để tìm hướng giải quyết.
Tất nhiên là không nên thử nghiệm mọi tình huống có thể xảy ra trong một ứng dụng hoặc thành phần giả định ngay cả trước khi bạn bắt đầu xây dựng ứng dụng hoặc thành phần đó. TDD có vai trò riêng và có thể hữu ích khi cơ sở mã của bạn trở nên phức tạp hơn.
TDD cũng là một phương pháp hay khi sửa lỗi. Nếu có thể mã hoá trường hợp sinh sản của một lỗi, bạn có thể đưa quy trình này vào một quy trình kiểm thử tự động ban đầu sẽ không thành công. Khi bạn đã khắc phục lỗi, quy trình kiểm thử sẽ thành công, cho phép bạn xác định xem bản sửa lỗi có thành công hay không mà không cần xác nhận thủ công.
Hộp trong so với hộp trong
Đây là cách bạn kiểm thử bất kỳ phần nào trong hệ thống. Nếu nó mờ, bạn không thể nhìn thấy bên trong (chẳng hạn như khi sử dụng giao diện công khai của một lớp), thay vì kiểm tra bên trong.
Trừ phi có lý do cụ thể để không sử dụng, bạn nên bắt đầu kiểm thử hộp mờ để có thể thiết kế chương trình kiểm thử dựa trên cách sử dụng các thành phần và không bị phân tâm bởi cách hoạt động của các thành phần bên trong. Nếu chỉ dựa vào giao diện "công khai" của đường dẫn mã (không nhất thiết là công khai cho người dùng, nhưng có thể với các phần khác của mã), bạn có thể tuỳ ý tái cấu trúc và cải thiện mã đó khi biết rằng kiểm thử của bạn sẽ phát hiện mọi thay đổi.
Một cách để chuyển đổi mã "hộp rõ ràng" trở nên mờ hơn là đưa các phần tử có thể định cấu hình như các thành phần trừu tượng cho các phần phụ thuộc của mã hoặc lệnh gọi lại để quan sát trạng thái, thay vì trạng thái đó được kết nối chặt chẽ với các hệ thống khác. Điều này giúp mã được tách biệt hơn và cho phép bạn cung cấp các phiên bản "kiểm thử". Ngoài ra, bạn có thể mô phỏng vị trí mã tương tác với các hệ thống khác.