7 nguyên tắc kiểm thử 2018 đã được thay đổi như thế nào so với 2011
White

Thiên Hoàng Minh Vũ viết ngày 28/04/2019

Zero: Mở đầu

Bảy nguyên tắc kiểm thử vốn từ lâu đã được xem là kim chỉ nam cho nguyên tắc làm việc chuyên nghiệp và là cơ sở phương pháp luận của các kiểm thử viên trên thế giới.

Bước sang 2018, các nguyên tắc kiểm thử này đã được đúc rút và đưa vào lĩnh vực tròn 50 năm so với 40 năm như bản 2011. Các nguyên tắc được xem là ổn và trụ vững trong suốt một thời gian dài, nhưng để phù hợp hơn, ISTQB (International Software Testing Qualifications Board - tổ chức chứng nhận kiểm thử phần mềm quốc tế) cũng đã có những chỉnh nắn nhất định cho phù hợp với thời cuộc.

Xét nghĩ, những người đã có chứng chỉ ISTQB Foundation, dù không cần phải thi lại nữa, cũng nên cập nhật những thông tin mới nhất của quyển sách này.

1. Kiểm thử chỉ ra sự hiện diện của lỗi, chứ không phải sự vắng mặt của chúng

Tiêu đề của nguyên tắc đã thêm 1 chú thích not their absence (không phải sự vắng mặt của chúng - lỗi)

Về nội dung, không có thay đổi:
Kiểm thử có thể cho thấy phần mềm đang có lỗi gì , nhưng không thể chứng minh điều ngược lại (tức phần mềm không còn lỗi) . Kiểm thử làm giảm xác suất lỗi chưa tìm thấy vẫn còn trong phần mềm, thậm chí là không còn lỗi nào, nhưng nó không phải là bằng chứng của sự chính xác hoàn toàn.

KHÁC:
Lỗi trong sản phẩm luôn tiềm ẩn, kiểm thử cố gắng tìm kiếm ra nó, kiểm thử viên không cần thiết phải nỗ lực chứng minh rằng lỗi đó không xuất hiện hay biện minh cho bug phát sinh rằng chúng ... vắng mặt.

2. Kiểm thử toàn bộ là điều không thể

Bất cứ chủ doanh nghiệp nào cũng muốn sản phẩm của mình phải hoàn hảo không tỳ vết và tất nhiên chi phí phải ít, thời gian xong sớm. Thế cho nên, lĩnh vực kiểm thử cũng đưa ra quan điểm test rõ ràng về nguyện vọng không tưởng đó cho khách hàng/chủ doanh nghiệp.

Nguyên tắc này chỉ thay đổi một chút ở nội dung:

Kiểm thử mọi thứ (tất cả các tổ hợp của điều kiện input đầu vào) là không thể thực hiện được, trừ phi nó chỉ bao gồm một số trường hợp bình thường (ít trường hợp tổ hợp thì có thể test toàn bộ được). Thay vì cố gắng kiểm tra toàn diện, phân tích rủi ro, kỹ thuật kiểm tra và phân độ ưu tiên nên được áp dụng để ưu tiên công số test.

KHÁC:
Ở đây, ISTQB đã bổ sung thêm phần khuyến cáo, trước đây chỉ có phân tích rủi ro, phân độ ưu tiên, nhưng với việc áp dụng ngày nay, việc sử dụng thuần thục các kỹ thuật test, lúc nào dùng kỹ thuật nào cũng là một trong những biện pháp tăng thúc đẩy việc giảm thiểu bug xảy ra.

3. Test sớm giúp tiết kiệm thời gian và tiền bạc

Để sớm tìm ra lỗi, cả hai hoạt động test tĩnh (static test ) và test động (dynamic test) nên được bắt đầu càng sớm càng tốt trong vòng đời phát triển phần mềm. Test sớm đôi khi được gọi là Shift Left Testing. Test sớm trong vòng đời phát triển phần mềm giúp giảm hoặc loại bỏ các thay đổi tốn kém.

KHÁC:
Sự mềm mỏng và chỉ rõ vấn đề lợi ích được đề cập đến giúp cho nguyên tắc ngày hoàn thiện hơn. Có những tình huống không cần thiết phải test sớm vẫn đạt được những yêu cầu nhất định của khách hàng tại thời điểm. ISTQB cũng không nhất thiết phải đưa ra một yêu cầu mang tính gò bó, nhưng vẫn khuyến nghị nó nên được thực hiện sớm. Vì sao?

Để tiết kiệm thời gian và tiền bạc.

Có thể ở thời điểm hiện tại nó thoả mãn yêu cầu của Khách hàng, nhưng sản phẩm thì không chỉ dừng lại ở đó, nó còn phát triển và với việc thay đổi quá nhiều khi muốn cải thiện, việc test không được join vào sớm sẽ gây ra những hệ quả thiệt hại đến lợi ích của khách hàng hơn trong tương lai.

Tất nhiên, nếu khách hàng chấp nhận điều đó thì ổn thôi, chúng ta chấp nhận cuộc chơi nhưng đừng chấp nhận rồi quay ra đổ lỗi!

4. Lỗi gom lại với nhau thành nhóm

Một số lượng nhỏ các mô-đun thường chứa hầu hết các lỗi được phát hiện trong quá trình thử nghiệm trước khi phát hành hoặc chịu trách nhiệm cho hầu hết các lỗi vận hành. Các cụm khiếm khuyết được dự đoán và các cụm khiếm khuyết quan sát thực tế trong thử nghiệm hoặc vận hành, là một đầu vào quan trọng trong phân tích rủi ro được sử dụng để tập trung nỗ lực thử nghiệm

KHÁC:
Ở bản 2011, người ta chắc chắn rằng cụm lỗi là có và nó có tồn tại, nhưng họ lại không hề chỉ ra làm thế nào để xác định được cụm lỗi đó mà thực hiện test. Chính vì thế, ở bản 2018 này, một thay đổi cần thiết được thiết lập:
Khi chúng ta thực hiện test, một lượng defects đủ lớn sẽ giúp chúng ta dễ dàng phân tích và tìm ra cụm lỗi cho những lần regression test sau.
Như vậy, để base trên nguyên tắc này, chúng ta phải có 3 yếu tố đầu vào:
1. Số defects đã bắt được trước đó.
2. Số defects có thể đoán được.
3. Tester cần kiểm soát và phân tích rủi ro liên tục để xác định cụm lỗi.

5. Đề phòng nghịch lý thuốc trừ sâu

Nếu các bài test tương tự được lặp đi lặp lại nhiều lần, cuối cùng các bài test này không còn tìm thấy bất kỳ khiếm khuyết mới nào.
Để phát hiện các lỗi mới, các test hiện tại và dữ liệu test có thể cần thay đổi và các bài test mới có thể cần phải được viết. (Các bài test không còn hiệu quả trong việc tìm ra lỗi, giống như thuốc trừ sâu không còn hiệu quả trong việc tiêu diệt côn trùng sau một thời gian.). Trong một số trường hợp, chẳng hạn như test hồi quy tự động, nghịch lý thuốc trừ sâu có kết quả có lợi, đó là số lượng khuyết tật hồi quy tương đối thấp.

KHÁC:
Cũng giống như nguyên tắc 4, nguyên tắc nghịch lý thuốc trừ sâu không còn quá gò bó và thô cứng. Có những dự án có xảy ra nghịch lý thuốc trừ sâu, cũng có dự án không, và cũng có người viết testcase quá hoàn hảo đến mức lỗi khó lòng thoát khỏi tay họ.

Chính vì vậy, ở mức đó chỉ khuyến cáo tester nên đề phòng. Và với các TH đó, cũng nên thử tìm thêm cách tiếp cận mới để có thể tối ưu khả năng khai thác lỗi lên.

6. Kiểm thử phụ thuộc vào ngữ cảnh

Kiểm thử được thực hiện khác nhau trong các bối cảnh khác nhau.

Ví dụ: phần mềm kiểm soát an toàn công nghiệp quan trọng được kiểm thử khác với ứng dụng di động thương mại điện tử. Một ví dụ khác, kiểm thử trong dự án Agile được thực hiện khác với kiểm thử trong dự án vòng đời tuần tự (sequential lifecycle project)

KHÁC
Không có gì khác, chỉ đơn thuần là thêm ví dụ làm rõ thôi!

7. Sự vắng mặt của lỗi là một ảo tưởng

Một số tổ chức hy vọng rằng tester có thể chạy tất cả các case có thể và tìm thấy tất cả các lỗi có thể, nhưng nguyên tắc 2 và 1, tương ứng, cho chúng tôi biết rằng điều này là không thể. Hơn nữa, đó là một sai lầm (tức là một niềm tin sai lầm/ảo tưởng sức mạnh) để mong đợi rằng chỉ cần tìm và sửa chữa một số lượng lớn các lỗi sẽ đảm bảo sự thành công của một hệ thống.

Ví dụ, test kỹ lưỡng tất cả các yêu cầu đã được chỉ định và sửa tất cả các lỗi được tìm thấy vẫn có thể tạo ra một hệ thống khó sử dụng, không đáp ứng nhu cầu và mong đợi của người dùng, hoặc kém hơn so với các hệ thống cạnh tranh khác.

KHÁC
Nội dung của nguyên tắc 7 đã được làm rõ hơn trước đây, các bạn có thể đọc thêm phần nội dung bên trên, trong đó phạm vi của nguyên tắc đã được ISTQB mở rộng thêm ra thay vì trước đây đưa ra ví dụ như 1 hình thức chắc chắn và chỉ có trường hợp đó thôi.

Đề thi ISTQB Foundation hiện nay đã thay đổi toàn bộ, cấp độ câu hỏi cũng đã khác trước nhiều, tăng K2, K3 lên, giảm K1 xuống, đây là 1 trong những thử thách lớn hơn cho các bạn thi, chúc các bạn may mắn!

Thân ái và quyết thắng!

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Thiên Hoàng Minh Vũ

26 bài viết.
73 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
45 3
(Ảnh) Người dẫn lại bài này cũng được phen lao đao khi lục lọi lại mớ kiến thức cơ bản cũ. Đối với sự nghiệp của một coder thì phải được thực hiện...
Thiên Hoàng Minh Vũ viết hơn 1 năm trước
45 3
White
15 0
Xưa, giang hồ đồn đại rằng: "Tin học và ngoại ngữ, trong thiên hạ ai nắm được 1 trong 2 thì có thể có được thiên hạ" :v Ấy mà nay, tiểu mỗ đang có ...
Thiên Hoàng Minh Vũ viết gần 2 năm trước
15 0
White
15 0
Nhắc đến công cuộc bảo vệ chất lượng phần mềm, tôi lại nhớ đến các bài viết về đất Nhật cũng như những chia sẻ của các đồng nghiệp đang sống và làm...
Thiên Hoàng Minh Vũ viết gần 2 năm trước
15 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
26 bài viết.
73 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!