Thực trạng của quá trình kiểm thử phần mềm

d) Những lỗi được tìm thấy và những lỗi không thể tìm thấy (The More Bugs You Find, the More Bugs There Are)

Thậm chí, có rất nhiều điểm tương đồng giữa real bug và software bug. Cả hai loại này đều cần đưa vào một nhóm. Thường thì một tester sẽ chạy phần mềm như thể nó không có một lỗi nào. Sau đó, anh ta sẽ tìm ra một lỗi rồi những lỗi khác, lỗi khác nữa. Có một vài lý do cho điều này:

• Các lập trình viên có những ngày thật tội tệ: Giống như tất cả chúng ra, những người lập trình có thể có những lúc không được minh mẫm lắm. Vào một thời điểm này code có thể được viết rất hoàn hảo, nhưng lúc khác anh ta lại viết code rất cẩu thả. Một lỗi có thể là một dấu hiệu tell – tale rất quen thuộc.
• Một lập trình viên thường xuyên mắc những lỗi tương tự nhau: Ai cũng có những thói quen. Một lập trình viên thiên về một loại lỗi nào đó mà thường xuyên mắc đi mắc lại.
• Một số lỗi thật sự nguy hiểm như đỉnh của một tảng băng chôi: Thường thì trong các bản thiết kế và kiến trúc của phần mềm đều ẩn chứa một số vấn đề chưa được phát hiện. Tester đã tìm được một số lỗi mà dường như nó không liên quan đến nhau. Nhưng không hẳn thế, những lỗi này lại có những quan hệ mật thiết với nhau và đều xuất phát từ một lý do chính vô cùng quan trọng.

Vấn đề quan trọng bây giờ là cần chú ý rằng ngược với ý tưởng “bugs follow bugs” này cũng có thể coi là đúng. Nếu bạn không thể tìm ra lỗi của phần mềm thì cũng không có vấn đề gì. Sẽ rất thuận lợi nếu các đặc trưng mà bạn kiểm tra được viết một cách trong sáng và quả thực sẽ có một vài điều nếu như bất kỳ một lỗi nào được tìm ra.

e) Nghịch lý về thuốc trừ sâu (The Pesticide Paradox)

Vào năm 1990, Boris Beizer, trong cuốn sách Software Testing Techniques, tái bản lần 2, đã xây dựng thuật ngữ Pesticide Paradox để mô tả một hiện tượng bạn kiểm thử phần mềm. Những điều tương tự với hiện tượng này đã xảy ra khi bạn dùng pesticides để diệt sâu bọ (mô tả trong hình 3.3). Nếu bạn liên tục dùng một loại pesticide giống nhau, sâu bọ sẽ kháng cự lại thuốc, và pesticide không còn hiệu quả nữa.

Phần mềm đã phải trải qua những phép thử lặp đi lặp lại tương tự nhau để chống lại các lỗi

Hãy nhớ về mô hình xoắn ốc của quy trình phát triển phần mềm được mô tả trong bài 2. Quá trình kiểm thử cũng phải lặp đi lặp lại mỗi lần quanh vòng lặp. Với mỗi lần lặp lại, tester nhận phần mềm để kiểm tra và chạy các trường hợp kiểm thử của họ. Cuối cùng, ngoài một vài trường hợp phần mềm chạy đúng yêu cầu, thì các trường hợp kiểm tra của tester sẽ tìm ra và phơi bày các lỗi. Nhưng ở lần lặp sau, nếu tester vẫn tiếp tục chạy các trường hợp kiểm thử này, chúng sẽ không giúp tìm ra lỗi mới.

Để cách vượt qua pesticide paradox, tester phải viết thêm các trường hợp kiểm thử khác nữa, và tìm những cách tiếp cận mới để kiểm tra chương trình và tìm ra nhiều lỗi hơn.

f) Không phải tất cả các lỗi mà bạn phát hiện sẽ được sửa

Một trong những điều thật sự đáng buồn của kiểm thử phần mềm là sau tất cả những lỗ lực cố gắng làm việc của bạn, không phải tất cả các lỗi bạn phát hiện ra sẽ được sửa. Nhưng điều này cũng không gây thất vọng bởi vì nó không có nghĩa rằng bạn đã làm sai điều gì khi cố gắng thực hiện mục đích của mình, cũng không có nghĩa rằng bạn cùng với cả đội của bạn sẽ phải chấp nhận giao cho khách hàng một sản phẩm kém chất lượng. Tuy nhiên, nó có nghĩa rằng, bạn sẽ cần dựa trên những cặp tiêu chí về nghề tester đã được liệt kê trong bài 1. Bạn và đội của bạn cần mô tả lại những quyết định dựa trên sự rủi ro cho riêng từng lỗi và cho tất cả các lỗi, để đưa ra quyết định cái nào sẽ được sửa và cái nào thì không.

Có một số lý do khiến một số lỗi không được fix:

• Không đủ thời gian: Trong mọi dự án luôn có rất nhiều feature của phần mềm, nhưng bạn lại có quá ít người để viết mã và kiểm thử chúng, và cũng không đủ khả năng để thay đổi kế hoạch làm việc cho đến khi kết thúc. Nếu bạn đang làm việc cho một chương trình đòi hỏi những thử thách lớn, mà thời hạn hoàn thành đã sắp đến thì bạn buộc phải bỏ qua một số lỗi
• Nó không hẳn là một lỗi: Có lẽ bạn cũng đã từng nghe thấy thành ngữ sau: “it’s not a bug, it’s a feature!” Không phải là hiếm những trường hợp: hiểu sai, lỗi do quá trình kiểm tra, hoặc đặc tả thay đổi dẫn đến kết quả có thể phát sinh lỗi trong tương lai
• Có quá nhiều rủi ro khi sửa lỗi: Thật không may điều này là quá thường xuyên xảy đến. Phần mềm có thể rất dễ hỏng, các bộ phận gắn kết chặt chẽ với nhau, và đôi khi chúng giống như “món mì Ý”. Có thể bạn sửa một lỗi lại khiến một lỗi khác xuất hiện. Dưới áp lực về thời gian hoàn thành sản phẩm, dưới một lịch trình kín đặc, thì có lẽ thay đổi phần mềm là một quyết định chứa quá nhiều rủi ro. Có lẽ tốt hơn hết là bỏ qua những lỗi có thể chấp nhận được để tránh phát sinh những lỗi mới, những rủi ro mới.
• Nó không đáng để phải sửa: điều này nghe có vẻ bất hợp lý, nhưng nó là sự thật. Những lỗi hiếm khi xuất hiện hoặc những lỗi xuất hiện trong những feature ít sử dụng thì có thể bỏ qua được. Những lỗi “work- around”, tức là có cách để người sử dụng có thể ngăn chặn hoặc tránh được lỗi, thì thường không được sửa. Tất cả các quyết định phải mang tính chất thị trường dựa trên độ rủi ro.

Quá trình xử lý các quyết định này thường bao gồm các tester, các project manager, các coder. Mỗi người sẽ có những cách nhận định về một viễn cảnh xảy ra khi một số lỗi không được sửa. Nếu lỗi không được fix, tester hiểu khách hàng sẽ phải gánh chịu những hậu quả như thế nào. Project manager có tầm nhìn chiến lược và đoán nhận được những hậu quả có thể xảy ra với dự án khi lỗi không được giải quyết. Và coder hiểu được rằng nếu fix lỗi này thì chi phí cho việc đó sẽ lớn như thế nào. Dựa vào đó, họ sẽ đưa ra những lý do tại sao họ nên sửa hoặc không nên sửa các lỗi đó.

CHUYỆN GÌ SẼ XẢY ĐẾN KHI BẠN ĐƯA RA MỘT QUYẾT ĐỊNH SAI:

Hãy nhớ lại về lỗi mà hãng Intel Pentium mô tả trong bài 1. Hãng Intel đã tìm ra lỗi này trước khi sản phẩm được tung ra thị trường, nhưng đội phát triển sản phẩm đã quyết định rằng: nó là một lỗi quá nhỏ và không đáng để phải sửa. Họ có một lịch làm việc quá dày đặc và đã đến hạn hoàn thành sản phẩm. Vì vậy, họ đã quyết định việc sửa lỗi này sẽ được thực hiện trong phiên bản sau của chip.

Nhưng thật không may, lỗi này đã bị khách hàng phát hiện ra. Trong một số khía cạnh của phần mềm, có thể có tới hàng trăm lỗi không được sửa bởi vì họ nhận thấy rằng hiệu quả tích cực của nó là không lớn. Vậy rất khó để có thể nói rằng các quyết định này là đúng hay sai.

g) Một lỗi có tồn tại nhưng không ai phát hiện thì có phải là lỗi không? (When a Bug's a Bug Is Difficult to Say)

Nếu có một vấn đề trong phần mềm, nhưng không một ai phát hiện ra nó, không phải lập trình viên, không phải một tester, và thậm chí là một khách hàng nào đó, thì nó có được gọi là lỗi không?

Một nhóm các tester ở trong một phòng và hỏi chúng tôi câu hỏi này. Bạn sẽ phải thảo luận về vấn đề này. Ai cũng có ý kiến riêng của mình và có thể là bạn cũng thế. Vấn đề ở đây là không có câu trả lời xác định. Câu trả lời phụ thuộc vào bạn và đội phát triển của bạn với việc đưa ra những quyết định tốt nhất cho mình.

Với mục đích của cuốn sách này, bạn hãy tham khảo những quy tắc để xác định một lỗi trong bài 1:

1. Phần mềm không thực hiện một số thứ giống như mô tả trong bản đặc tả phần mềm
2. Phần mềm thực hiện một số việc mà bản đặc tả yêu cầu nó không được thực hiện
3. Phần mềm thực hiện một số chức năng mà bản đặc tả không đề cập tới
4. Phần mềm không thực hiện một số việc mà bản đặc tả không đề cập tới, nhưng là những việc nên làm
5. Trong con mắt của người kiểm thử phần mềm là khó hiểu, khó sử dụng, chậm đối với người sử dụng

Quy tắc này sẽ giúp chúng ra lọc ra những tình huống khó xử để đưa ra quyết định. Có một cách khác để suy xét nó. Không phải là hiếm những trường hợp mà 2 người sử dụng có những nhận xét hoàn toàn trái ngược nhau về vấn đề chất lượng phần mềm. Một người thì nói rằng chương trình như vậy là không thể chấp nhận và người còn lại thì quả quyết rằng chương trình này là hoàn hảo. Có thể cả hai đều đúng? Câu trả lời là một người sử dụng sản phẩm theo cách mà rất nhiều lỗi bị bộc lộ. Còn người kia thì không.

Chú ý: Lỗi không được khám phá hoặc chưa từng được chú ý thì thường được gọi là lỗi ngầm (latent bug)

Nếu điều này quá khó hiểu thì cũng đừng lo lắng. Hãy đem nó ra thảo luận với đồng nghiệp trong đội kiểm thử của bạn và cố gắng hiểu điều mà họ nghĩ. Hãy lắng nghe những ý kiến khác, kiểm tra ý tưởng của họ và định hình lại suy nghĩ của chính mình. Hãy nhớ lại một câu hỏi quen thuộc: “ nếu một cái cây đổ trong rừng và không ai nghe thấy gì cả, vậy nó có tạo ra âm thanh không?” ("If a tree falls in the forest and there's no one there to hear it, does it make a sound?").

h) Xây dựng bản đặc tả phần mềm là công việc không bao giờ kết thúc

Phát triển phần mềm có một vấn đề. Ngành công nghiệp này đang phát triển quá nhanh: năm ngoái nó có thể là một sản phẩm sắc bén, nhưng năm nay nó đã trở lên lỗi thời. Tại cùng một thời điểm, phần mềm có quy mô lớn hơn, có nhiều feature hơn và tương đối phức tạp, dẫn đến kế hoạch phát triển sẽ lâu ưhơn. Có 2 vấn đề đối lập nhau, và kết quả là liên tục phải thay đổi bản đặc tả sản phẩm.

Không có cách nào khác để phản ứng lại sự thay đổi mau lẹ của bản đặc tả. Bạn cho rằng, sản phẩm của bạn đã bị khóa và chúng ta tuyệt đối không thể thay đổi bản đặc tả sản phẩm. Bạn đã đi được nửa chặng đường trong kế hoạch phát triển 2 năm của sản phẩm, đối thủ chính của bạn thì đã tung ra thị trường một sản phẩm hoàn toàn tương tự với sản phẩm của bạn. Mà thậm chí một vài feature rất tuyệt vời mà sản phẩm của bạn không có được. Liệu bạn có nên tiếp tục với bản đặc tả của mình và giao cho khách hàng một sản phẩm thua kém hơn không? Hay đội phát triển dự án của bạn nên tập hợp lại, suy ngẫm lại về những feature của sản phẩm, viết lại bản đặc tả và làm việc trên một sản phẩm được sửa lại? Trong hầu hết các trường hợp, những nhà kinh doanh sáng suốt sẽ tuyên bố sau cùng.

Là một tester, bạn phải thừa nhận rằng bản đặc tả sẽ thường xuyên thay đổi. Các feature sẽ được thêm vào mà nó không hề nằm trong kế hoạch kiểm thử. Các feature sẽ thay đổi và thậm chí là bị xóa hoàn toàn khi bạn đã kiểm tra và sẵn sàng báo cáo lỗi về nó. Điều này hoàn toàn có thể xảy ra. Bạn sẽ được tìm hiểu các kỹ thuật linh hoạt để lập kế hoạch và thực thi việc kiểm thử trong phần còn lại của cuốn sách.

k) Tester không phải là thành viên được mọi người chờ đợi trong một dự án

Hãy nhớ lại mục đích của quá trình kiểm thử phần mềm là gì? Mục đích của một tester là tìm ra lỗi, tìm thấy chúng sớm nhất có thể, và chắc chắn rằng chúng phải được sửa.

Công việc của bạn là xem xét thật kỹ lưỡng và phê bình công việc của các đồng nghiệp của bạn, phát hiện những vấn đề của công việc, và phải thực hiện công khai những gì bạn tìm thấy. Và bạn sẽ phải cố gắng chiến thắng trong các cuộc tranh luận với các đồng nghiệp.

Hãy giữ thái độ hòa bình với những đồng nghiệp trong đội của bạn:

• Phát hiện lỗi thật sớm: Dĩ nhiên, đây là công việc của bạn, và bạn phải kiên trì làm công việc này. Và dĩ nhiên, nếu bạn phát hiện một lỗi nguy hiểm trước 3 tháng thì tốt hơn là 1 ngày trước khi đến thời điểm tung sản phẩm ra thị trường.
• Giữ thái độ hăng hái, nhiệt tình: Tốt thôi, bạn thật sự yêu công việc của mình. Bạn sẽ cảm thấy phấn khích khi bạn tìm được một lỗi khủng khiếp. Nhưng nếu bạn huênh hoang dồn ép lập trình viên và nói với anh ta rằng bạn vừa mới tìm được một lỗi kinh khủng nhất (nastiest bug) trong suốt quá trình làm việc của bạn, thì chắc hẳn rằng anh ta sẽ cảm thấy khó chịu.
• Đừng chỉ báo cáo những thông tin xấu: Nếu bạn đã phát hiện ra một đoạn mã chứa đầy lỗi, hãy nói cho mọi người biết, dù bạn sẽ bị phản đối. Bởi vì nếu bạn chưa từng phát hiện ra lỗi của các lập trình viên, mọi người cũng sẽ tránh xa bạn.

i) Kiểm thử phần mềm là một công việc đòi hỏi tính kỷ luật

Kiểm thử phần mềm là công việc được thực hiện sau khi có sản phẩm. Các sản phẩm phần mềm và không phức tạp. Số lượng người với máy tính sử dụng phần mềm là bị giới hạn. Và, một số ít lập trình viên trong đội dự án của bạn có khả năng gỡ lỗi cho mỗi đoạn mã của người khác. Các lỗi là một vấn đề không tốt. Chúng xuất hiện và sớm được sửa chữa thì chi phí cho chúng sẽ không nhiều. Thường thì các tester không được huấn luyện và họ vẫn phát huy khả năng của họ trong các dự án sau để làm thay đổi nhiều thứ.

Hãy nhìn xem sản phẩm phần mềm cần được giúp đỡ và bạn sẽ nhìn thấy một danh sách các tester. Ngành công nghiệp phần mềm đang phát triển vượt bậc với mũi nhọn là đội ngũ tester chuyên nghiệp. Bởi vì hiện tại, người ta đã mất quá nhiều chi phí để xây dựng lên những phần mềm kém chất lượng.

Thật là tội tệ, không phải mọi công ty đều thống nhất quan điểm đó. Nhiều computer game và những công ty phần mềm nhỏ vẫn thường xuyên sử dụng những mô hình phát triển lỏng lẻo như big-bang hoặc code-and-fix. Nhưng bây giờ, nhiều phần mềm được phát triển và luôn tuân thủ kỷ luật. Các tester trở thành lực lượng lòng cốt, những thành viên sống còn trong nhiệm vụ của họ.

Đây sẽ là một vấn đề lớn, nếu bạn là thấy hứng thú với kiểm thử phần mềm. Nó đã trở thành một nghề nghiệp được nhiều người lựa chọn và cần phải được đào tạo, làm việc có kỷ luật và thúc đẩy sự tiến bộ.