Viblo Code
+3

Kiểm thử quả lắc/Kiểm thử thăm dò

Kiểm thử quả lắc/Kiểm thử thăm dò

"Kiểm thử thăm dò nên được thực hiện chi tiết như thế nào?". Trong bài viết này chúng ta sẽ cùng nhau tìm hiểu về nó nhé !

Kiếm thử quả lắc

Hãy tưởng tượng một con lắc khi nó dừng lại. Không gian mà con lắc giao động là cách tiếp cận thử nghiệm của chúng ta. Ở đỉnh trái chúng ta sẽ test "rất sâu" và ở đỉnh bên phải chúng ta sẽ test ở mức độ "rất nông". Ban đầu, con lắc sẽ đứng ở trung tâm, giữa hai cực:

Khi tester bắt đầu tham gia 1 tổ chức mới hoặc một dự án mới, ta áp dụng chuyển động đầu tiên cho quá trình kiểm thử quả lắc của chúng ta. Đầu tiên, hãy làm như sau, ta kéo con lắc đến điểm cao nhất và thả tay ra. Giao động sẽ bắt đầu ở phía bên phải (nông) nó phản ánh những kiến thức hạn hẹp mà chúng ta có cũng như khi chúng ta bước vào một tính huống mới. Theo kinh nghiệm của tôi thì đó cũng chính và vấn đề chúng ta gặp phải trong quá trình thực hiện test.

Ở lần thả tay đầu tiên, [con lắc] giao động (trái, phải) ở một biên độ không đổi, tuy nhiên, do lực cản của không khí nên biên độ dao động của chúng giảm dần.

Tương tự như vậy trong quá trình testing, con lắc sẽ giao động về phía sau và phía trước. Khi việc test trở nên quá chuyên sâu, thì sẽ chuyển hướng. Khi việc test trở nên không hiệu quả, thì sẽ chuyển đổi lại.

Các kỹ năng nhận biết việc test sẽ chi tiết như thế nào là nhận ra các chỉ số, các chỉ số mà nói cho bạn biết khi nào thì con lắc sẽ đạt đến điểm cao nhất trong quá trình giao động. Bạn cần phải có khả năng xác định khi nào việc test đi quá sâu hoặc ở quá nông, để bạn có thể điều chỉnh cách tiếp cận của mình một cách hợp lý.

Các chỉ số

Các chỉ số giúp chúng ta xác định vị trí của con lắc trong quá trình test. Tôi thấy có 3 loại chỉ số sau đây: số lượng bug, phản hồi của team, và quản hồi về việc quản lý.

  • Số lượng bug: Nếu bạn không tìm thấy nhiều bugs trong quá trình bạn test, nhưng khách hàng của bạn đang báo cá rất nhiều vấn đề về sản phẩm, tức là quá trình test của bạn đang rất nông. Mặt khác, nếu bạn raise rất nhiều bugs, nhưng chúng lại không được fix, hoặc khách hàng của bạn đang báo cáo là không có vấn đề gì cả thì có nghĩa là quá trình test của bạn đang rất sâu rồi. Giống như sự báo trước, nếu sản phẩm không có vấn đề gì có thể sẽ không ứng dụng được trong một số ngành công nghiệp. Một ứng dụng web-based khi release có thế chấp nhận một số vấn đề về giao diện người dùng mà việc sửa chữa những vấn đề này là không cần thiết cho lắm. Nhưng mà 1 công ty sản xuất phần cứng y tế có thể tìm cách release 1 sản phẩm mà họ tin rằng nó hoàn hảo cho dù nó phải test trong bao lâu đi nữa. Việc release này thì tùy theo cách nhìn của công ty đó thôi.

  • Phản hồi của team Cho dù bạn đang làm việc trong một team test theo mô hình waterfall hoặc 1 team theo mô hình agile, bạn có thể nhận được phản hồi từ những người xung quanh bạn. Hãy cởi mở và điều chỉnh hành vi của mình cho phù hợp. Nếu đồng nghiệp của bạn thường xuyên phải đưa ra scope cho việc test của bạn, hãy đặt câu hỏi là bạn đã dành đủ thời gian vào việc test của bạn hay chưa, hoặc là họ thực hiện các việc test của họ mà bạn nghĩ không cần thiết cho lắm, thì tức là bạn thức hiện test quá nông. Mặt khác, nếu động nghiệp của bạn thường xuyên bỏ các scope trong việc test của bạn, thử đặt câu hỏi là bạn có thể làm gì với thời gian bạn dành để test? hoặc họ không thực hiện bất kỳ việc test nào của họ thì việc test của bạn rất sâu.

Về quan điểm của các QA dự án bạn, việc phản hồi là một chỉ số đặc biệt hữu ích trong agile team. Trong trường hợp , nếu không có testcase unit nào được viết và các dev đang outsource việc testing của họ cho bạn, hoặc nếu như doanh nghiệp tin tưởng bạn để thực hiện việc user acceptance test, thì có nghĩa là việc test của bạn đang rất sâu. Nếu bạn muốn luyện tập trong một môi trường được chia sẻ quyền sở hữu chất lượng thì bạn phải chấp nhận cho điều đó xảy ra.

  • Phản hồi về quản lý Nếu việc test của bạn đang ở tại một điểm mà cả team đều đang unhappy, điều đó có nghĩa là người quản lý của bạn sẽ phải có các cuộc nói chuyện trực tiếp với bạn về quá trình tiếp cận test của bạn. Nếu bạn đang test quá nhiều, người quản lý sẽ có thể cảm thấy thoải mái khi nói chuyện trực tiếp với bạn về điều này. Nếu bạn test quá sơ sài, thì có thể bạn sẽ bị hỏi nhiều câu hỏi hơn về việc tiếp cận test của bạn, về các bugs được raise lên bởi người dùng, hoặc phải giải thích là thời gian bạn dùng để làm gì mà không test. Các chỉ số mang tính tương đối, không phải là quy tắc. Chúng bao gồm các từ như là "many", "not many", "frequently" or "a lot", điều này sẽ có các ý nghĩa khác nhau trong các tình huống khác nhua. Như thường lệ, áp dụng một bối cảnh của tổ chức vào quá trình ra quyết định Các chỉ số mà tôi đã mô tả có thể được tóm tắt bằng bảng so sánh sau đây:
QUÁ SÂU QUÁ NÔNG
Bạn log rất nhiều bug, nhưng chúng không được fix Bạn không tin được nhiều bug
Sản phẩm không có bug nào SẢn phẩn rất nhiều bug
Khi review chéo, đồng nghiệp của bạn thường xuyên bỏ scope test của bạn Khi review chéo, đồng nghiệp thường hay thêm scope test của bạn
Team của bạn hoặc bạn cùng dự án đặt câu hỏi về chi phí cơ hội mà bạn dành để test Team hoặc bạn bè đặt câu hỏi bạn có dùng đủ thời gian cho việc test không
Team hoặc bạn cùng dự án không tự thực hiện bất kỳ việc test nào Team hoặc bạn cùng dự án thực hiện việc test mà bạn nghĩ là không cần thiết
Quản lý của bạn nói chuyện trực tiếp với bạn rặng bạn đang test quá nhiều Quản lý hỏi bạn chi tiết về những gì bạn đang test

Tìm sự cân bằng

Cuối cùng, hầu hết các tester sẽ kết thúc ở 1 điểm cân bằng, nơi con lắc dừng lại, giữa 2 cực. Sự thoải mái của điều này có thể là 1 vấn đề. 1 khi chúng ta quá tự tin trong cách tiếp cận, thì chúng ta có thể trử nên mù quáng trong quá trình điều chỉnh. Tôi tin rằng, cái mà chúng ta muốn phấn đấu, nằm ở bên trái của con lắc ( "quá sâu"). Để giữ một con lắc nằm ngoài vị trí cân bằng, chúng ta phải thường xuyên tạo ra các va chạm (tác dụng lực vào con lắc).

Nếu bạn đã từng test 1 sản phẩm trong một thời gian dài và muốn tránh trở nên lỗi thời, thì hãy tạo ra các va chạm (tác dụng lực vào con lắc). Áp dụng một số thử nghiệm bất quy tắc. Khám phá các khách hàng khác nhau. Thay đổi dữ liệu test. Bầy kì biến thể nào cũng đều có thể cho bạn một loạt các vấn đề mới mà team bạn có thể khám phá và làm cho nó mới mẻ.

Bạn có thể sử dụng kết quả của của quá trình tác động lực vào để hiệu chỉnh cách tiếp cận trong một phạm vi chuyển động nhỏ của con lắc. Thay đổi nào là nhiều? Cái gì nên được bổ sung vào việc test của bạn? Các thực nghiệm nho nhỏ sẽ giúp xác định rằng bạn đang đi đúng đường.

Kết luận

Kiểm thử quả lắc là một ví dụ hữu ích để mô tả làm cách nào để tìm sự cân bằng trong quá trình tiếp cận test. Khi tham gia vào 1 dự án hoặc 1 team mới, nó có thể được sử dụng để minh họa cách mà chúng ta experience large initial swings in the depth of our testing giống như chúng ta học về các chỉ số về môi trường của chúng ta. Đôi vói những người đã từng test cùng 1 sản phẩm trong cùng 1 thời gian, thì nó có thể nhắc nhở chúng ta liên tục rà soát cách tiếp cận thông qua việc tác động lực. Không có 1 câu trả lời chính xác nào cho câu hỏi "Kiểm thử thăm dò nên được thực hiện chi tiết như thế nào?". Tuy nhiên tôi hi vọng rằng kiểm thử quả lắc sẽ giúp bạn xác định và mô tả đúng mức độ chi tiết cho bạn.

Nguồn: http://katrinatester.blogspot.ch/search/label/Testing


All Rights Reserved

Viblo
Let's register a Viblo Account to get more interesting posts.