6 quan điểm sai lầm khi thảo luận về kiểm thử phần mềm

Để nói về kiểm thử phần mềm quả là điều không dễ dàng. Kiểm thử không chỉ là một nhiệm vụ, mà còn là một nhiệm vụ tạo ra các nhiệm vụ mới (bằng cách tìm ra các lỗi cần được sửa hoặc tìm ra các rủi ro mới phải được kiểm tra). Do vậy, kiểm thử là một nhiệm vụ gần như không thể đạt đến định nghĩa "hoàn thành" được.

Sự nhầm lẫn về kiểm thử dẫn đến các cuộc bàn luận không đạt được hiệu quả, thường là do tập trung vào các vấn đề không quan trọng trong khi bỏ qua những điều quan trọng. Dưới đây là một số trường hợp cụ thể mà các cuộc trao đổi về kiểm thử bị thất bại:

1. Mọi người thường quan tâm đến việc họ có bao nhiêu trường hợp thử nghiệm thay vì số lượng trường hợp thử nghiệm mà họ thực sự làm.

Số lượng các trường hợp thử nghiệm (ví dụ: 500, 257, 39345) không chứng minh được việc bạn đang thực hiện bao nhiêu trường hợp thử nghiệm. Lý do mà các developer không muốn khoe khoang về việc họ đã tạo ra bao nhiêu tệp ngày hôm nay trong khi code sản phẩm của mình là vì mọi người đều biết rằng sẽ rất ngớ ngẩn khi đếm các tệp, các tổ hợp phím hoặc những thứ tương tự.

Do vậy, thật ngớ ngẩn khi đếm các trường hợp thử nghiệm. Một hoạt động kiểm thử có thể được biểu diễn dưới dạng một trường hợp thử nghiệm hoặc một triệu trường hợp thử nghiệm. Điều gì xảy ra nếu một người kiểm thử viết phần mềm tự động tạo ra 100.000 biến thể của một trường hợp kiểm thử duy nhất? Đó có thực sự là 100.000 trường hợp thử nghiệm hay không, hay đây là một trường hợp thử nghiệm lớn, hay chẳng cần một trường hợp thử nghiệm nào cả? Lần tới khi ai đó đưa cho bạn số lượng trường hợp kiểm thử, hãy thực hành nói với chính mình "cái này chẳng nói lên được điều gì với tôi đâu" . Sau đó đặt câu hỏi về những gì việc kiểm thử thực sự làm: Nó bao gồm những gì? Những lỗi nào có thể được phát hiện? Những rủi ro nào có thể được thúc đẩy ?

2 . Khi mọi người nói về kiểm thử như là một đối tượng chứ không phải là một hoạt động.

Việc kiểm thử không phải là một đối tượng vật lý, mặc dù những thứ vật lý như tài liệu, dữ liệu và code có thể là một phần của hoạt động kiểm thử. Việc kiểm thử là một sự thực hiện, một hoạt động. Bằng cách nói về một bài kiểm tra như một đối tượng chứ không phải là một hoạt động, bạn đã bỏ qua phần quan trọng nhất của việc kiểm thử : sự chú ý, động lực, tính toàn vẹn và kỹ năng của người kiểm tra. Không có hai kiểm thử viên nào lại đi thực hiện kiểm thử 1 tính năng giống nhau, cùng cách test giống nhau, cho dù là bất cứ cách nào. Về mặt kỹ thuật, bạn không thể lấy một trường hợp thử nghiệm và đưa nó cho người khác mà không thay đổi kết quả thử nghiệm theo một cách nào đó (giống như không có cầu thủ bóng chày hoặc cầu thủ bóng rổ nào sẽ thực hiện cùng một cách chơi hai lần) mặc dù các thay đổi không hoàn toàn là chuyện quan trọng.

3 . Khi mọi người không thể mô tả được chiến lược thử nghiệm của họ khi nó phát triển.

Chiến lược kiểm thử là tập hợp các ý tưởng được mô tả, hướng dẫn rằng thử nghiệm nào cần được thiết kế và thử nghiệm nào sẽ được thực hiện trong các tình huống được nêu ra. Chiến lược kiểm thử cũng có thể được gọi là lý do đằng sau các hành động thử nghiệm. Nó cũng là câu trả lời cho các câu hỏi như tại sao những trường hợp kiểm thử này đáng để làm? Tại sao không phải là trường hợp kiểm thử khác ? Chúng ta có thể thay đổi được gì muốn kiểm thử sâu hơn? Chúng ta có thể thay đổi được gì muốn kiểm thử nhanh hơn ? Tại sao chúng ta lại thử nghiệm theo cách này? Những câu hỏi này phát sinh không chỉ sau khi thử nghiệm, mà ngay khi bắt đầu quá trình. Khả năng thiết kế và thảo luận về chiến lược thử nghiệm là một đặc trưng của kiểm thử viên chuyên nghiệp. Nếu không, kiểm thử sẽ chỉ là vấn đề của thói quen và trực giác.

4. Khi mọi người nói chuyện như thể kiểm thử tự động có thể thay thế hoàn toàn con người.

Nếu các developer nói về việc code theo cách mà rất nhiều người nói về kiểm thử, họ sẽ nói rằng trình biên dịch của họ đã tạo ra sản phẩm và tất cả những gì họ làm là vận hành trình biên dịch. Họ sẽ nói rằng sản phẩm được tạo ra tự động, thay vì nó được làm ra bởi sự chăm chỉ và thông minh của các developer. Người quản lý sẽ trở nên bị ám ảnh với việc phát triển tự động hóa trên máy tính bằng cách sử dụng các công cụ tốt thay vì thuê và đào tạo các developer xuất sắc.

Cách tốt hơn để nói về thử nghiệm cũng giống như cách chúng ta nói về phát triển: thử nghiệm là một hoạt động do con người trực tiếp làm, không phải từ công cụ. Công cụ có thể trợ giúp, nhưng công cụ không thực hiện kiểm thử. Không có thứ gọi là kiểm tra tự động. Hầu hết điều mà các công cụ có thể làm là vận hành một sản phẩm theo một kịch bản có sẵn và kiểm tra đầu ra cụ thể theo kịch bản đó. Đó không phải là kiểm thử, mà chỉ đơn giản là kiểm tra thực tế sản phẩm. Công cụ có thể trợ giúp kiểm tra thực tế sản phẩm rất tốt, nhưng kiểm thử không chỉ là kiểm tra thực tế, bởi vì người kiểm tra phải sử dụng óc phán đoán kỹ thuật và sự khéo léo để tạo ra các trường hợp và đánh giá chúng, duy trì và cải thiện chúng. Tên gọi cho toàn bộ quá trình được thực hiện bởi con người (bao gồm sự hỗ trợ bởi các công cụ) mới gọi là thử nghiệm. Khi bạn tập trung vào "kiểm thử tự động", bạn thực chất không tập trung vào các kỹ năng phán đoán, giải quyết vấn đề và động lực (những thứ thực sự kiểm soát chất lượng của việc kiểm thử). Và do vậy, bạn không thể xử lý các yếu tố quan trọng kiểm soát chất lượng của việc thử nghiệm.

5. Khi mọi người nói chuyện như thể chỉ có một loại kiểm thử độ bao phủ.

Có nhiều cách bạn có thể kiểm thử độ bao phủ sản phẩm khi thực hiện test. Mỗi phương pháp đánh giá một phạm vi bao phủ khác nhau. Không có một cách nói cụ thể nào có thể cung cấp cho bạn đủ câu thông tin về loại kiểm thử này. Cũng giống như ví dụ sau, nếu bạn kiểm thử một trang cung cấp kết quả tìm kiếm cho một truy vấn, bạn đã bao hàm chức năng được biểu thị bằng loại truy vấn mà bạn vừa thực hiện (bao phủ chức năng) và bạn đã bao hàm nó với tập dữ liệu cụ thể của các mục tồn tại vào thời điểm thực hiểm thử nghiệm (bao phủ dữ liệu). Nếu bạn thay đổi truy vấn để gọi một loại tìm kiếm khác, bạn sẽ nhận được phạm vi bao phủ chức năng mới. Nếu bạn thay đổi tập dữ liệu, bạn sẽ nhận được phạm vi bao phủ dữ liệu mới. Dù bằng cách nào, bạn có thể tìm thấy một lỗi mới với phạm vi bao phủ mới đó.

6. Khi mọi người nói chuyện như thể kiểm thử là một nhiệm vụ tĩnh, dễ dàng được chính thức hóa.

Kiểm thử là một nhiệm vụ học tập; về cơ bản là học tập. Nếu bạn nói với tôi rằng bạn đang kiểm thử nhưng không học được gì, tôi sẽ nói bạn không hề kiểm thử được gì cả. Bản chất thực sự của bất kỳ việc học nào là bạn không thể biết những gì bạn sẽ khám phá ra sau đó. Cũng giống như nhiều con đường chúng ta đã lựa chọn làm trong cuộc sống, từ lái xe đến quản lý công ty. Thực sự có những điều mà chúng ta có thể dự đoán sẽ xảy ra và các kế hoạch chúng ta có thể sử dụng để thực hiện những hành động của mình, nhưng không có gì trong số đó chứng minh rằng là bạn có thể mơ hồ thực hiện nó bằng cách cúi đầu xuống và làm theo một kịch bản có sẵn. Để kiểm thử thì chúng ta phải liên tục đặt câu hỏi về những gì chúng ta đang làm và đang nhìn thấy.

Quá trình thử nghiệm chuyên nghiệp không phải là thiết kế trường hợp thử nghiệm rồi sau đó làm theo đúng các trường hợp thử nghiệm. Một kiểm thử viên có trách nhiệm sẽ không làm việc theo cách này. Kiểm thử một cách có trách nhiệm là một quá trình liên tục điều tra và thiết kế các trường hợp thử nghiệm. Điều này có thể liên quan đến quy trình thiết kế và tự động hóa, nhưng tất cả những điều đó phải được thực hiện với sự hiểu biết rằng chúng ta sẵn sàng phản ứng với bất cứ tình huống nào xảy ra. Chúng ta thường xuyên đi chệch khỏi các quy trình chúng ta thiết lập vì phần mềm rất phức tạp và nhiều tình huống bất ngờ xảy ra; bởi vì tổ chức có nhu cầu thay đổi; và bởi vì chúng ta học được những cách tốt hơn để kiểm thử khi chúng ta thực hiện nó.

Thông qua những điều này và những thất bại khác trong các cuộc thảo luận về thử nghiệm, mọi người vẫn kiên định với niềm tin rằng thử nghiệm tốt chỉ là vấn đề viết được bao nhiêu "trường hợp thử nghiệm" (bất chấp việc họ làm gì); tự động hóa chúng (bất kể tự động hóa sẽ không thể làm được gì); chuyển chúng từ người kiểm tra chưa được huấn luyện này sang người chưa được huấn luyện khác; tất cả tôn sùng các tập tin và tập lệnh thay vì nhìn vào những gì người kiểm thử đang làm hàng ngày.