Testing to Pass vs. Testing to Fail

Có 2 hướng tiếp cận cơ bản khi kiểm thử phần mềm là: test – to – pass và test – to – fail. Khi bạn test – to – pass, bạn thực sự chỉ đảm bảo được rằng phần mềm thực hiện được các chức năng tối thiểu. Bạn đừng cố thúc đẩy những khả năng của nó. Bạn không biết rằng bạn có thể làm hỏng nó. Bạn xem xét nó với một kid gloves, áp dụng những testcase đơn giản nhất và rõ ràng nhất.

Thế nào gọi là thử nghiệm để vượt qua (test – to – pass)

Bạn có thể đang nghĩ rằng, nếu như mục đích của bạn là tìm ra lỗi, tại sao bạn lại lựa chọn test – to – pass? Bạn có nghĩ rằng bạn muốn tìm lỗi bằng một vài phương tiện có khả năng thực hiện được không? Câu trả lời là không. Một ví dụ có thể là: Nhấn nút A, sau đó nhấn nút B, sau đó nhấn vào nút Gửi. Test – to – pass thường được sử dụng khi một trong hai ứng dụng hoặc một trang web bản thân nó chứng minh các bước cơ bản của khái niệm trong spec hoặc là trong giai đoạn sản phẩm sơ khai khi xảy ra bất kỳ sai sót nào từ bước kiểm soát thì điều đó có khả năng xảy ra một lỗi nghiêm trọng.

Một ví dụ khác: Bạn được giao nhiệm vụ kiểm tra phiên bản đầu tiên của chiếc xe hơi mới sản xuất, mà bạn thì chưa từng lái xe bao giờ. Có lẽ bạn sẽ lái nó với tốc độ lớn nhất mà nó đạt được. Và có thể bạn sẽ bị đâm và chết. Với một chiếc xe car mới, có thể có tất cả các loại lỗi mà nó bộc lộ ra khi lái với tốc độ dưới mức bình thường. Có lẽ là những cái lốp xe có kích cỡ không đúng, hoặc những cái phanh không tương xứng, hoặc là bộ máy quá lớn. Bạn có thể phát hiện ra những vấn đề này và sửa chúng trước khi tung ra thị trường.

Chú ý: Khi thiết kế và chạy các test case, luôn luôn phải chạy trường hợp test – to – pass trước. Đây là điều quan trọng để kiểm tra những chức năng cơ bản của phần mềm trước khi bạn lún sâu vào nó. Bạn có thể sẽ phải ngạc nhiên về cái cách mà bạn tìm thấy rất nhiều lỗi khi sử dụng phần mềm một cách thông thường.

Thế nào gọi là thử nghiệm thất bại ( test – to – fail)

Các kiểm tra để không liên quan đến việc thử nghiệm một tính năng trong mọi cách có thể tưởng tượng có thể. Sau khi bạn kiểm tra những chức năng cơ bản, lúc này, bạn hãy kiểm tra những trường hợp lắt léo, bí ẩn, và cố gắng để bắt các lỗi. Thiết kế và chạy các test case với mục đích duy nhất là tìm ra lỗi thì được gọi là testing – to – fail hoặc error – forcing. Bạn sẽ được tìm hiểu trong bài này. Trường hợp test – to – fail thường không dễ dàng xuất hiện. Thường thì nhìn chúng cũng giống như các trường hợp test – to – pass, nhưng chúng được lựa chọn để thăm dò những điểm yếu phổ biến trong phần mềm.

Quay lại với ví dụ trên, ca kiểm thử có thể là nhấp vào nút A hoặc nút B hai lần sau đó nhấn Submit. Người sử dụng có thể nhấn vào nút không theo trật tự, nhấn vào nút đó một hay nhiều lần, hoặc chỉ cần đi đúng cho nút Submit mà không cần nhấp một trong hai nút đầu tiên. Khi một ứng dụng hoặc một trang web đã phát triển vượt ra ngoài bằng chứng ban đầu của giai đoạn khái niệm, trường hợp đó nên được thử nghiệm thất bại và tích cực.

CÁC THÔNG ĐIỆP VỀ LỖI: TEST – TO – PASS HOẶC TEST – TO – FAIL:

Một lớp các test case phổ biến cố gắng để bắt các lỗi. Các trường hợp này thực sự là nằm giữa 2 trường hợp test – to – pass và test – to – fail. Có lẽ bản đặc tả đã mô tả chắc chắn rằng với điều kiện đầu vào như vậy sẽ đưa ra kết quả là một thông báo lỗi. Dường như nó cũng rõ ràng như trường hợp test – to – pass. Nhưng bạn cũng sẽ bắt được một lỗi, vì vậy nó có thể được gọi là test - to – fail. Cuối cùng, có thể gọi theo cả 2 cách đều được. Đừng lo lắng về sự tương phản này. Cái quan trọng là cố gắng để bắt được lỗi và xây dựng các test case về các vấn đề chưa từng được xem xét tới.

Test-to-pass thường xuyên trở thành phương pháp tiếp cận đi-đến được sử dụng bởi kiểm thử viên, những người đang tìm cách tránh đối đầu hoặc để làm hài lòng các nhà quản lý dự án hoặc các nhà phát triển phần mềm và nó chỉ có thể dẫn đến mã thực hiện xấu.

Test-to-fail không tốn nhiều thời gian và khó khăn bởi nó sẽ hỏi những câu hỏi mà không được yêu cầu hoặc được chú thích. Nó làm nổi bật các lỗi và có thể phản đối cách làm của con người (dev), nhưng nó là điều cần thiết trong sản xuất một sản phẩm chất lượng. Nó là tốt hơn để phá vỡ các trang web hoặc ứng dụng trong một môi trường giai đoạn kiểm soát hơn là để có một vấn đề quan trọng được phát hiện bởi người dùng cuối khi ứng dụng hoặc trang web đã hoạt động.

Trong môi trường staging, vấn đề này có thể được quan sát, tất cả các dữ liệu liên quan về vấn đề này có thể được ghi nhận và đưa vào xem xét để giúp giải quyết vấn đề. Một lỗi được tìm thấy sau khi các ứng dụng hoặc các trang web đã được đưa ra một cách tự nhiên hiếm khi được báo cáo với tất cả các chi tiết cần thiết để khắc phục vấn đề. Điều này có thể cho kết quả trong giờ làm việc tốn kém chi tiêu trong việc theo dõi dữ liệu đó, chưa kể đến những tác động tiêu cực vấn đề này sẽ có vào người sử dụng. Và như chúng ta đều biết, rất khó để áp đặt giá trên bị mất uy tín.

Test-to-fail chi phí đắt hơn so với test-to-pass. Nhưng được tính vào chi phí bên bảo đảm chất lượng, việc theo dõi và chi phí bảo dưỡng của sản phẩm lại được giảm thiểu đáng kể. Về lâu dài, đưa test-to-fail vào quá trình test giúp cung cấp một sản phẩm chất lượng cao hơn, đưa ra một kết quả tích cực và thêm kinh nghiệm người dùng cuối, hơn hết là sẽ giúp nâng cao hình ảnh công ty. Refer: http://www.betabreakers.com/testing-to-pass-vs-testing-to-fail/ http://voer.edu.vn/c/test-va-kiem-tra/4c771e16/896649ef