[QA] Hiệu ứng thuốc trừ sâu (Pesticide paradox)
QA
7
Testing
30
test
8
White

Thiên Hoàng Minh Vũ viết ngày 20/10/2017

alt text
Thù nghịch trên các cánh đồng là sâu bọ gây hại nông sản, cũng vậy thù nghịch trong các phần mềm là ... :bug: . Chúng đều chung đặc tính là làm ảnh hưởng đến chất lượng của sản phẩm. Con người đã nghĩ ra rất nhiều giải pháp trong công cuộc tìm và diệt những mối nguy hại ấy nhưng điều đáng lo ngại nhất lại không phải :bug: nhiều hay ít, mà là nó có thể "kháng thuốc". Ở đây, đối với kiểm thử phần mền chính là sự vắng mặt của bug.

Khi còn học Đại học, chúng tôi không được thầy giáo dạy về vấn đề nan giải này. Mục đích của kiểm thử ở trường chỉ gói gọn chỉ bày cho chúng tôi cách thức lập test planing và quản lý test, viết testcase theo chuẩn, 1 số phương pháp điển hình để test, function và 1 số tool test auto thông dụng. Khi tiếp xúc và buộc phải test trong thời gian đầu chính chúng tôi cũng không hề quan tâm đến vấn đề này. Điều đó cũng giống như nhân loại tìm ra .. thuốc trừ sâu vậy, họ chưa cần quan tâm đến vấn đề sâu có thể kháng thuốc vì lúc đó chưa xuất hiện sâu kháng thuốc. Đối với tester hạng thường thì việc test đạt chỉ tiêu của testcase ban đầu viết ra là đã cảm thấy bản thân xuất sắc rồi, cũng có thể là do chúng tôi chưa phải đổi mặt với cơn ác mộng hiện tiền, vào một ngày đẹp chúng tôi không phát hiện ra 1 bug nào qua bộ case cũ kĩ đi kèm với một cái mặt thẫn thờ.

Khi tự mình học xong ISTQB, tôi mới nhận ra một vấn đề :

"À hóa ra không phải lúc nào một bộ testcase có thể dùng được trọn đời trong vòng đời dự án".

Nhiều lúc, tôi cũng quên đi việc phải tiếp cận vấn đề từ nhiều hướng tiếp cận, nhiều góc nhìn, từ những tư duy stupid cho đến những tư duy siêu quái dị. Cũng có thể việc luyện tập Debate không biểu hiện ra ngoài với tôi nhiều, nhưng nó cũng ảnh hưởng ít nhiều lên tư duy, tôi vẫn có thể bắt được nhiều bug và chưa bao giờ tôi nghĩ là một task với độ phức tạp như thế này, như thế kia, với năng lực của DEV như thế này, thế nọ,... mà lại chỉ sinh ra 1 lượng bug "hời hợt". Tuy nhiên cũng vì thế mà nhiều khi tôi đã khinh địch nhiều để có thể mở thêm các góc nhìn khác mà đáng ra nếu cố gắng hơn tôi có thể làm được....
alt text

Định nghĩa hàn lâm

Nếu việc kiểm thử tương tự nhau được lặp đi lặp lại nhiều lần, thì cuối cùng sẽ có một số trường hợp kiểm thử (test case) sẽ không còn tìm thấy bất kỳ lỗi nào mới.

Cứ cho là testcase của dự án được xây dựng lên khá tốt. Phân lớn case đã được chú ý và ghi nhận lại trong testcase. Thì nó vẫn đối mặt với 1 số rủi ro.

1. Testcase được viết bởi con người.

Chúng ta đều là con người và vì thế chúng ta đều có thể có sai lầm hoặc thiếu xót, điều đó không chỉ riêng đối với DEV mà còn đúng với bất kì ai, kể cả QA / Tester.

2. Test toàn bộ là không thể (Exhaustive testing is impossible)

Testcase là tập hợp của toàn bộ dự án với các module nhỏ chia ra có thể ứng với từng chức năng/ màn hình. Cho nên để test được hết 1 lượt testcase trong 1 thời gian giới hạn là điều không thể, không kể nếu có làm thì nó cũng tốn effort.

Những lúc như thế thì việc test hồi quy (Regression testing) sẽ hữu dụng hơn. Tuy nhiên việc thiết lập tài liệu này cần phải có cái nhìn khái quát toàn hệ thống, có hiểu biết cả kĩ thuật lập trình và tài liệu.

3. Nguyên tắc vàng của test : 80/20

Nguyên tắc này được đội ngũ tester áp dụng khá triệt để do tính đặc thù của chúng là tiết kiệm thời gian và bao quát các "điểm nóng" về lỗi. Chính vì thế mà những lỗi còn lại (20%) dễ bị bỏ xót hơn do việc chỉ test qua loa các khu vực này.
alt text
...

Phương pháp giải quyết.

Nguyên tắc này giống như việc trừ sâu trong nông nghiệp, nếu chúng ta cứ phun một loại thuốc với nồng độ giống nhau trong một khoảng thời gian dài thì có một số con sâu sẽ quen dần và cuối cùng việc phun thuốc giống như là tắm chúng vậy (bị lờn thuốc) => lúc đó chúng ta không thể diệt sạch chúng được. Do vậy, để diệt sạch sâu một cách hiệu quả, người ta thường thay đổi loại thuốc trừ sâu, mỗi loại chỉ dùng trong khoảng thời gian ngắn.

Hoặc có thể rèn luyện với các tip cơ bản sau:
alt text

1. Đánh giá vấn đề tìm nguyên nhân

Mỗi người đều là những nhà nghiên cứu tiềm năng. Luôn đặt ra câu hỏi: "Cách test này còn hiệu quả không? Bộ testcase này đang tồn tại vấn đề gì?..." Bằng cách đặt ra các câu hỏi, chúng ta phải động não để tìm cho ra các câu trả lời mà mình cần.
Khi đã xác định testcase hay cách test không còn mang lại thế mạnh hay có khả năng tìm ra bug nữa cũng như nguyên nhân gây ra thì chúng ta sẽ tiến hành step 2

2. Xác định kết quả mong muốn nếu giải quyết được nguyên nhân

Mọi hành động cần phải có đích đến. Là vô ích nếu như chúng ta chỉ làm "hờ hững"
alt text

3. Hướng đi để đạt được kết quả

  • Đánh giá, gạn lọc lại tài liệu với những yêu cầu bổ sung.
  • Động não tư duy vào các hướng tiếp cận mới hoặc nhờ vào cách tư duy của một người khác (nếu có)
  • Xây dựng đánh gia các vùng ảnh hưởng từ yêu cầu mới để tiến hành cập nhật testcase.
  • Viết mới lại mảng testcase nếu như có yêu cầu lớn ==> Có thể tránh phụ thuộc vào case cũ cũng như khuyến khích các hướng tư duy mở rộng hơn.

Chúc các bạn bảo vệ "sản phẩm" của dự án mình thành công và nhanh chóng trở thành tỷ phú. :sweat_smile:

Kaopiz, 23/06/2017 , copy lại bài viết cá nhân!

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ũ

24 bài viết.
61 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
38 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 5 tháng trước
38 3
White
13 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 9 tháng trước
13 0
White
13 0
vietnamxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.vn Em, em, xem cho chị cái tên đặt thế này đủ hay chưa? =)) Bần mỗ nghẹn cmn lời luôn với vấ...
Thiên Hoàng Minh Vũ viết 9 tháng trước
13 0
Bài viết liên quan
White
4 0
1. Định nghĩa Một kế hoạch kiểm thử dự án phần mềm (test plan) là một tài liệu mô tả các mục tiêu, phạm vi, phương pháp tiếp cận, và tập trung vào...
Thiên Hoàng Minh Vũ viết 6 tháng trước
4 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

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


White
{{userFollowed ? 'Following' : 'Follow'}}
24 bài viết.
61 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á!