5 lý do bạn thường bỏ sót lỗi và cách ngăn chặn

Bỏ sót lỗi, ở một mức độ nào đó, nó là điều tồi tệ đối với người kiểm thử.

Tại sao lại như vậy?

Nếu bạn đang kiểm thử phần mềm, bạn có biết rằng đã có một quan niệm sai lầm về kiểm thử, rằng người kiểm thử phải chịu trách nhiệm bắt tất cả các lỗi trong hệ thống. Người kiểm thử được coi là người gác cổng hoặc thủ môn. Khi có bất kỳ lỗi nào xảy ra khi sản phẩm đã đến tay khách hàng và gây ra tổn thất về doanh số, uy tín của công ty, khách hàng tiềm năng, v.v., người kiểm thử thường là người cuối cùng chịu trách nhiệm (với sự đồng thuận cao từ dự án). Mọi thứ trở nên tồi tệ hơn nếu việc bỏ sót lỗi trở thành một phần của "blame game" - một trò chơi đổ lỗi trên mạng.

Trong bài viết này, tôi muốn chỉ ra 5 lý do tại sao bạn thường bỏ sót lỗi và những gì bạn có thể làm để ngăn chặn nó xảy ra lần nữa.

1. Bạn đã bỏ sót lỗi vì bạn đã không kiểm tra nó

Điều này là hiển nhiên.

Nếu bạn đã không kiểm tra một tính năng, một thành phần hoặc bỏ qua các trường hợp kiểm thử, nhiều khả năng các lỗi sẽ được chuyển đến tay khách hàng. Tất nhiên, có một số lý do khiến bạn không thực hiện kiểm thử một tính năng, bạn có thể quên kiểm tra một tính năng hoặc test design của bạn không tốt. Nhưng đây là những lý do phổ biến :

  • Bạn có thể không nhận thức được những sự thay đổi "bí mật" mà đội Developers đã thực hiện. Developers có thể cố tình che giấu điều đó, hoặc họ chỉ đơn giản nghĩ rằng những thay đổi đó là nhỏ, không gây ra ảnh hưởng gì, do đó không cần kiểm thử hoặc báo cáo sự thay đổi.
  • Bạn có thể không nhận thức được tính năng đó đã thay đổi trong trường hợp người quản lý không nói với người kiểm thử.

Bạn có thể làm gì để ngăn chặn điều đó?

  • Theo dõi mọi thay đổi có thể có trong hệ thống trong mỗi bản release, đặc biệt là các thay đổi trên các thành phần quan trọng hoặc thay đổi vào phút cuối. Nếu bạn đang gặp rắc rối, hãy hỏi về những thay đổi và nếu có thể, hãy đưa ra những rủi ro nếu việc kiểm thử bị bỏ qua đối với những thay đổi đó.
  • Yêu cầu quản lý giao tiếp vấn đề với tất cả. Hãy lên tiếng và mạnh dạn để yêu cầu thông tin như vậy trong tương lai. Thông điệp quan trọng cần truyền tải ở đây không chỉ liên quan về việc kiểm thử của bạn mà còn nói thêm về rủi ro, chất lượng của hệ thống.

2. Bạn đã không bao quát được nhiều trường hợp

Lỗi rất "nhút nhát". Chúng thường trốn tránh những người kiểm thử, vì vậy không dễ để bắt chúng, đòi hỏi nhiều nỗ lực hơn để khám phá chúng.

Trong nhiều trường hợp, bạn cần thực hiện tập hợp các bước phức tạp hoặc các kết hợp khác nhau để tìm ra lỗi. Về mặt kỹ thuật, phần mềm ngày càng phức tạp hơn để phục vụ và đáp ứng nhu cầu kinh doanh hiện nay. Chỉ kiểm thử Blackbox, bạn có thể không nhận thức được mức độ phức tạp của hệ thống hoặc cách các thành phần của hoạt động cùng nhau. Kết quả là bạn đã không xác định được hết phạm vi kiểm thử hoặc các trường hợp mà lỗi thường khó tìm ra. Những loại lỗi này đôi khi khiến mọi người rơi vào tình huống khó khăn và thường tự hỏi "ai là người đã gây ra nó".

Bạn có thể làm gì để ngăn chặn điều đó?

  • Là người kiểm thử, bạn cần đưa bạn vào vị trí người dùng để hiểu cách họ thường sử dụng sản phẩm. Đôi khi, hành vi của họ thật kỳ lạ, nhưng bạn biết không, đó chỉ là cách họ sử dụng phần mềm. Đừng đánh giá thấp mức độ sáng tạo của người dùng.
  • Tìm hiểu về cách hệ thống hoạt động. Trong nhiều trường hợp, bạn không cần phải biết cách các thành phần trong hệ thống giao tiếp với nhau, hoặc hiểu từng dòng code. Tuy nhiên, việc hiểu hệ thống dưới góc độ kỹ thuật sẽ giúp bạn tìm ra lỗi tốt hơn.
  • Nếu bạn có nhiều thời gian, hãy dành thời gian để thiết kế và bao quát nhiều điều kiện kết hợp nhất có thể. Tất nhiên, điều này sẽ tốn thời gian và công sức của bạn, nhưng nếu nó xứng đáng với những gì bạn bỏ ra, hãy thực hiện nó.

3. Bạn bỏ qua lỗi vì bạn đã bỏ qua những lỗi quá rõ ràng

Thật kỳ lạ, lỗi bỏ lỡ thường cũng là những lỗi rõ ràng. Bởi những lỗi quá rõ ràng, những lỗi ở trước mặt người kiểm thử nhưng họ lại không nhận ra đó là lỗi. Điều đó xảy ra mọi lúc mọi nơi. Tại sao lại như vậy?

Có một số lý do tại sao bạn không thấy các lỗi rõ ràng như vậy :

  • Bạn có thể quá tập trung vào việc kiểm thử một phạm vi cụ thể của hệ thống, và bạn thậm chí không quan tâm để tìm kiếm các vấn đề trong các phần khác.
  • Bạn có thể quá tập trung vào một nhiệm vụ khác mà tâm trí của bạn không được đặt trong chế độ phát hiện lỗi ( bug detection mode ). Ví dụ, khi bạn làm việc thiết kế các trường hợp thử nghiệm, bạn có thể đang tương tác với hệ thống nhưng tâm trí của bạn không ở chế độ "bug detection" và bạn có thể bỏ lỡ các lỗi rõ ràng.
  • Bạn đã thực hiện các hành động tương tự để kiểm tra một tính năng nhiều lần.

“Insanity is doing the same thing over and over again and expecting different results” – Albert Einstein.

(Làm đi làm lại cùng một thứ nhưng lại mong chờ nhận được những kết quả khác nhau là một điều điên rồ.)

Một phiên bản khác dành cho người kiểm thử : “Insanity is testing the same way over and over again and expecting bugs found”

(Kiểm thử theo một cách và lặp đi lặp lại nhiều lần nhưng lại mong chờ tìm thấy lỗi là một điều điên rồ.)

Bạn có thể làm gì để ngăn chặn điều đó?

  • Thành thật mà nói, tôi không chắc chắn làm thế nào để giải quyết vấn đề này, đặc biệt nếu bạn không phải là “multi-tasking” tester. Những gì tôi có thể đề xuất là luôn luôn giữ bản thân trong chế độ “bug detection” để bạn có thể chỉ ra vấn đề rõ ràng.
  • Bạn cũng có thể thử tiếp cận hệ thống từ một góc nhìn khác, áp dụng các kỹ thuật khác nhau để kiểm tra hệ thống.

4. Bạn bị sức ép về thời gian

Hiện nay, khách hàng đều muốn đưa sản phầm phần mềm của mình ra thị trường sớm. Tuy nhiên, mặt trái của việc này là đội kiểm thử bị áp lực về thời gian khi phải hoàn thành kiểm thử cho kịp thời gian. ĐIều đó đồng nghĩa việc họ phải làm thêm giờ hoặc chấp nhận bỏ qua một số trường hợp kiểm thử trong đợt release này. Khi đội kiểm thử đang "chạy" để kịp release, họ bỏ qua một số trường hợp, và bug lại nằm đúng trong các trường hợp mà họ đã bỏ qua.

Bạn có thể làm gì để ngăn chặn điều đó?

Trên thực tế, giải pháp duy nhất là tìm cách để bạn không cảm thấy bị áp lực dưới sức ép về thời gian, khi đó bạn có thể đảm bảo được chất lượng phần mềm và hạn chế số lỗi nhiều nhất có thể. Ở đây tôi có một vài gợi ý : Nếu thời gian bàn giao cố định, hãy giao tiếp nhiều hơn với mọi người để phân tích rủi ro và hạn chế lỗi ở một số trường hợp kiểm thử đơn giản mà bạn dự định bỏ qua. Hãy nói suy nghĩ của bạn với người quản lý về tiến độ kiểm thử, những rủi ro có thể gặp phải khi bạn không thực hiện kiểm thử cho trường hợp đó.

5. Bạn nhìn thấy vấn đề nhưng bạn không báo cáo nó

Người khôn ngoan thường nói : "Bất cứ khi nào bạn nhìn thấy vấn đề, hãy báo cáo ngay lập tức". Điều đó được coi là quy tắc của ngón tay cái, một câu thần chú khi nói đến kiểm thử. Tuy nhiên, đôi khi những người kiểm thử đã không làm theo điều đó.

Đã bao nhiêu lần khi bạn tìm thấy một lỗi, bạn tự hứa sẽ báo cáo nó sau. Nhưng sau đó bạn chuyển sang một công việc, nhiệm vụ khác, và rồi “sau” (later) đã trở thành “không bao giờ” (never). Bạn hoàn toàn quên việc báo cáo lỗi và thật đáng buồn là lỗi đó sẽ quay lại và gây ra rắc rối cho bạn.

Trong các trường hợp khác, có thể bạn không đủ tự tin để báo cáo nó (Ví dụ: Tôi không muốn làm phiền Dev vì chưa chắc nó đã là lỗi, cần kiểm tra thêm) hoặc bạn đánh giá thấp tầm quan trọng của lỗi (Ví dụ: lỗi này có mức độ nghiêm trọng thấp, không ai quan tâm, vì vậy hãy bỏ qua nó). Kết quả, bạn quyết định không báo cáo về lỗi đó. Hóa ra, lỗi đó có thể không quan trọng (với bạn) nhưng lại là một lỗi nghiêm trọng (với ai đó).

Hãy nhớ điều này. “A bug is something that bug someone that matters” (Yes, from James Bach).

Một lỗi không quan trọng với bạn, điều đó không có nghĩa là nó không quan trọng với người khác.

Bạn có thể làm gì để ngăn chặn điều đó?

Nếu bạn nghĩ rằng nó là một lỗi, hãy báo cáo (tất nhiên, luôn luôn giải thích trong báo cáo lỗi của bạn lý do tại sao bạn nghĩ rằng đó là một lỗi). Lưu ý rằng việc này không chỉ là hoạt động CYA (Cover Your Ass). Đó là một hành động tốt mà người kiểm thử nên thực hiện thường xuyên hơn.

Kết luận

Là một người kiểm thử, việc của chúng ta là kiểm thử sản phẩm và cung cấp thông tin có giá trị cho người quản lý về sản phầm phần mềm. Trong một số trường hợp, người kiểm thử đóng vai trò là cánh cổng cuối cùng để đánh giá chất lượng sản phẩm trước khi nó đến tay khách hàng. ĐIều đó có nghĩa là áp lực sẽ đè lên chúng ta nếu bỏ lỡ một lỗi. Tuy nhiên, những người thử nghiệm cũng là con người và cũng không hoàn hảo. AI cũng sẽ phạm sai lầm lúc này hay lúc khác. Một số có thể mắc nhiều lỗi hơn những người khác và nó không sao cả.

Ở đây, điểm quan trọng cần lưu ý :

Bỏ qua lỗi là không tốt và nó trở nên tồi tệ hơn khi mọi người tận dụng cơ hội đó để bắt đầu trò chơi đổ lỗi cho những người xung quanh.

Đừng làm điều đó.

Với tư cách là những người thử nghiệm, hãy để tình huống này là cơ hội để xem xét quá trình thử nghiệm, rút ra bài học và xem liên kết yếu ở đâu để ngăn chặn nó xảy ra lần nữa. Là một nhóm, tất cả đội dự án đều phụ trách chất lượng, không chỉ là người kiểm thử.

" That’s it! No more missed bugs, no more nightmare, sleep tight testers! "

Tài liệu tham khảo :

https://www.asktester.com/5-simple-reasons-missed-bugs-prevent/