Nào cùng tìm hiểu về Exploratory testing

Exploratory testing (Kiểm thử thăm dò) là gì?

Exploratory testing là một loại kiểm thử mà người thực hiện không dựa trên các test case đã được tạo trước mà khám phá, tìm hiểu một cách tự do, mô phỏng theo cách dùng của người dùng cuối để tự mình kiểm tra hệ thống và tìm ra lỗi.

Thông qua exploratory testing, bạn có thể đảm bảo rằng tất cả các lỗi đều được phát hiện và các developer có thể khắc phục lỗi kịp thời trước khi release sản phẩm.

Exploratory testing rất quan trọng và phải là một phần trong chiến lược kiểm thử của bạn vì nó cho phép bạn tìm ra các khiếm khuyết của hệ thống và có thể tập trung vào những phần có nhiều khả năng gặp sự cố nhất.

Ví dụ về exploratory testing

Sản phẩm Garoon của Cybozu có ứng dụng Scheduler, để quản lý các lịch họp. Bạn có thể đăng kí lịch họp với những người dùng khác cũng như đặt trước các thiết bị dùng trong buổi họp. 

Khi thực hiện exploratory testing cho ứng dụng Scheduler, bạn có thể tập trung vào việc kiểm tra “Nếu thực hiện thao tác này, điều gì sẽ xảy ra?”

Ví dụ, ban đầu bạn thực hiện các bước tương tự như khi thực hiện kiểm thử bằng test case. Trong quá trình đó, bạn có thể tự hỏi “Điều gì sẽ xảy ra nếu tạo một lịch với số lượng người tham gia lớn khoảng 100 người?”. Bạn làm thử và thấy rằng chỉ có thể được tạo lịch với số lượng 10 người tham gia. Nhưng kết quả này không đáp ứng được yêu cầu sử dụng của người dùng. Hoặc “Điều gì sẽ xảy ra nếu mở một lịch đã tạo, và xoá hết người tham gia họp rồi lưu lại?”. Khi đó, lịch đã tạo trước đó đã mất đi mà không có thông báo nào hiển thị cho bạn biết. Bạn vừa tìm thấy hai lỗi quan trọng bằng cách khám phá điều gì đó không phải là một bước trong test case.

Ưu điểm của exploratory testing

Exploratory testing giúp kiểm tra các kịch bản khác nhau bằng cách sử dụng chuyên môn riêng của QA để phát hiện các lỗi v lỗ hổng khó tìm.

• Kiểm tra hệ thống từ các góc độ khác nhau để phát hiện những rủi ro chưa biết

Với exploratory testing, bạn khám phá lặp đi lặp lại để tìm hiểu hệ thống, và đảm bảo bạn kiểm tra hệ thống từ tất cả các tình huống khác nhau.

• Sử dụng các kỹ năng, chuyên môn và kiến ​​thức của QA để kiểm tra hệ thống một cách trực quan

Bằng cách sử dụng exploratory testing, bạn sẽ học và lặp lại quá trình kiểm thử của mình, đồng thời nâng cao kiến ​​thức cũng như kỹ năng của mình. Cho đến nay, không có máy nào có thể sánh được với sự kết hợp độc đáo giữa kỹ năng, kiến ​​thức và kinh nghiệm mà con người mang lại.

• Chia sẻ những hiểu biết sâu sắc với cả nhóm để phát hiện những rủi ro mà bạn có thể không gặp phải một mình

Chia sẻ những hiểu biết sâu sắc của bạn từ các phiên exploratory testing để bổ sung kiến ​​thức chung của tất cả mọi người tham gia vào vòng đời phát triển phần mềm và giúp tạo ra sản phẩm tốt hơn, đáp ứng toàn diện nhu cầu của khách hàng. 

• Cần ít sự chuẩn bị hơn

Phương pháp kiểm thử này không yêu cầu nhiều tài liệu như các loại khác. Vì vậy, QA có thể bắt đầu thực hiện kiểm thử mà không cần chuẩn bị nhiều, trái ngược với việc tập hợp nhiều test case và tính năng như các hình thức kiểm thử khác.

Tất cả những gì cần cho exploratory testing là một test charter (một bản phác thảo về mục tiêu của việc kiểm thử)

• Có thể học real-time 

Người QA có kỹ năng cao có thể áp dụng kinh nghiệm và kiến ​​thức cá nhân để tìm hiểu về hoạt động của hệ thống đồng thời tiến hành kiểm thử, cho phép họ thiết kế, thực hiện và điều chỉnh các kịch bản kiểm thử một cách real-time.

• Hợp tác tốt hơn

Vì loại kiểm thử này tập trung vào những phần quan trọng, nên từ báo cáo của QA khi thực thi exploratory testing, các developer phản hồi sâu sắc về chất lượng của sản phẩm và trao đổi với QA về những khu vực mà họ nghi ngờ.

• Khám phá lỗi nghiêm trọng

Các loại kiểm thử theo kịch bản có thể bị hạn chế phần nào việc này vì QA chỉ thiết kế test case dựa trên những vấn đề mà họ nghĩ có thể xảy ra hoặc dựa trên các lỗi giả định. 

Người thực hiện exploratory testing thì suy nghĩ bên ngoài những khái niệm đã định sẵn, cho phép họ khám phá chương trình hoặc hệ thống và phát hiện ra những khiếm khuyết mà những QA khác có thể đã bỏ qua.

Khi nào nên sử dụng kiểm thử thăm dò?

• Khi kiểm tra các yêu cầu không rõ ràng, không đầy đủ hoặc thường xuyên thay đổi

Loại kiểm thử này là một cách tiếp cận tuyệt vời khi xử lý các yêu cầu không rõ ràng, không đầy đủ hoặc thay đổi thường xuyên.

• Khi kiểm tra các khu vực phức tạp, có rủi ro cao trong hệ thống phần mềm

Exploratory testing có thể giúp xác định các khiếm khuyết trong các khu vực phức tạp, có rủi ro cao của phần mềm.

• Khi cần tiết kiệm thời gian và chi phí kiểm thử

Loại kiểm thử này yêu cầu ít thời gian và lập kế hoạch hơn so với các quy trình kiểm thử chính thức, khiến nó trở thành một cách tiếp cận lý tưởng cho các tình huống mà nguồn lực khan hiếm và có ít thời gian.

• Khi cần đảm bảo sự hài lòng của người dùng cuối

Exploratory testing giúp hiểu các tính năng và giá trị của sản phẩm phần mềm, xác định các lỗi tiềm ẩn có thể tác động tiêu cực đến sự hài lòng của người dùng cuối.

Khi nào nên nói không với exploratory testing?

Exploratory testing không nên được sử dụng trong các dự án nhạy cảm về thời gian với thời hạn chặt chẽ, vì phương pháp này có thể tốn thời gian và khó dự đoán. 

Loại kiểm thử này cũng không nên được sử dụng cho các dự án yêu cầu mức độ chi tiết và độ chính xác đặc biệt cao.

Các loại exploratory testing

• Dựa trên kịch bản 

Trong loại kiểm thử này, QA kiểm tra đánh giá sản phẩm theo từng kịch bản của người dùng, cố gắng khớp kịch bản theo mọi cách và kiểm tra càng nhiều kịch bản càng tốt.

• Dựa trên chiến lược 

Trong loại kiểm thử này, người QA kiểm thử bằng cách dựa trên các chiến lược khác nhau như  phân tích giá trị biên, kỹ thuật tương đương và kỹ thuật dựa trên rủi ro để tìm ra các lỗi khó hơn. Loại kiểm thử này chủ yếu được thực hiện bởi người QA có kinh nghiệm, đã sử dụng phần mềm lâu năm và hiểu rõ về phần mềm.

• Tự do 

Trong  loại kiểm thử này, QA nhanh chóng di chuyển qua một hệ thống hay ứng dụng mà không theo quy tắc nào. Có thể chọn số lượng hoặc khu vực nào sẽ kiểm thử, tự do sử dụng bất kỳ kỹ thuật nào để kiểm tra chức năng và hoạt động của phần mềm. Loại kiểm thử này cũng có lợi thế khi bạn cần xác thực công việc của một số QA khác, điều tra lỗi hoặc thực hiện smoke test.

Cách cấu trúc exploratory testing

Cách tiếp cận của loại kiểm thử này được thực hiện nhanh chóng, không có nghĩa là nó không được thực hiện theo cấu trúc nào cả.

Người quản lý của quá trình thực hiện kiểm thử thăm dò cần đảm bảo những điều sau đây:

• Thiết lập nhiệm vụ rõ ràng.
• Ghi chú rõ ràng về những gì cần được kiểm tra, tại sao và chất lượng được đánh giá của ứng dụng.
• Các vấn đề và câu hỏi được nêu ra trong quá trình kiểm thử đều được theo dõi.
• Phân công hai người phụ trách một cách phù hợp dựa trên kinh nghiệm của họ.
• Điều này được thực hiện thông qua 5 giai đoạn:

Bước 1. Phân loại lỗi

• Cách tiếp cận phổ biến để phân loại lỗi là nhóm các lỗi theo danh mục, ví dụ như lỗi về chức năng, vấn đề về lỗ hổng bảo mật hoặc performance. 

  • Trong mỗi loại sẽ có một số danh mục phụ, ví dụ như giao diện người dùng, điều hướng, nhập dữ liệu, hoặc thời gian phản hồi.

• Một cách tiếp cận khác là phân loại lỗi theo mức độ nghiêm trọng, từ lỗi nghiêm trọng đến lỗi có độ ưu tiên thấp 

• Hoặc phân loại theo tác động, chẳng hạn như gây mất dữ liệu hoặc sự cố hệ thống.

• Bạn cũng có thể phân loại theo tần suất xuất hiện của lỗi. 

Một hệ thống phân loại lỗi tốt là phải linh hoạt và có khả năng thích ứng với các yêu cầu của dự án. Cho phép QA ghi lại và báo cáo lỗi một cách dễ dàng. 

Ngoài ra trong phân loại lỗi cần có phần phân tích nguyên nhân gốc rễ của các lỗi để giúp nhóm phát triển triển khai các giải pháp thiết thực nhằm ngăn ngừa các vấn đề tương tự trong tương lai.

Phân loại lỗi hiệu quả là một công cụ thiết yếu để thực thi exploratory testing thành công.

Bước 2. Tạo một điều lệ kiểm tra (test charter)

Điều lệ kiểm tra là một tài liệu nêu rõ các mục tiêu, phạm vi và các ràng buộc của phiên kiểm thử thăm dò. Điều lệ kiểm tra thường bao gồm các yếu tố sau:

• Mục tiêu: những mục đích mà phiên kiểm thử hướng tới, chẳng hạn như xác định các vấn đề về khả năng sử dụng của ứng dụng.
• Phạm vi: xác định các tính năng, chức năng và thành phần cần được kiểm tra cũng như bất kỳ lĩnh vực nào nằm ngoài phạm vi.
• Ràng buộc: bất kỳ hạn chế hoặc ràng buộc nào phải được tuân thủ, ví dụ như hạn chế về thời gian, ngân sách hoặc nguồn lực.
• Môi trường: chỉ định cấu hình hệ thống và phiên bản phần mềm được sử dụng để kiểm thử.
• Dữ liệu kiểm thử: phác thảo các dữ liệu mẫu hoặc kịch bản cần được kiểm thử.
• Thực hiện kiểm thử: xác định các kỹ thuật, cách tiếp cận và phương pháp kiểm thử mà người kiểm thử nên sử dụng.
• Mức độ bao phủ: hệ thống sẽ được kiểm thử dựa trên thời gian và nguồn lực sẵn có với mức độ kiểm thử như thế nào.

Bước 3. Giới hạn thời gian

Giới hạn thời gian là một khía cạnh quan trọng của exploratory testing. Việc thiết lập thời gian cần hoàn thành thực hiện kiểm thử sẽ giúp người QA nỗ lực trong thời gian cho phép để tìm ra các khiếm khuyết và những khu vực cần được cải thiện.

Ví dụ:

• Hai người chịu trách nhiệm kiểm thử sẽ cùng làm việc với nhau trong ít nhất 90 phút 
• Sự gián đoạn không xảy ra trong suốt 90 phút.
• Việc kéo dài hoặc giảm bớt 45 phút đều được chấp nhận.

Bước 4. Xem lại kết quả

QA có thể xem lại kết quả bằng cách phân tích các số liệu kiểm thử. Việc xem xét lại kết quả cho phép QA tính toán hoặc ước tính hiệu quả của quá trình kiểm thử.

Ngoài ra kết quả này cũng có thể giúp cho các công việc như sau:

• Nhận biết những lỗ hổng trong quy trình kiểm thử.
• Tạo các yêu cầu và user story mới dựa trên kết quả.
• Đôi khi có thể sửa đổi lại phạm vi phát triển hoặc kiểm thử hệ thống.
• Kết quả cũng giúp các nhà quản lý và các stakeholder đưa ra quyết định sáng suốt về vòng đời phát triển phần mềm và tiến trình của nó.
• Phân tích này cho phép QA xác định các mô hình và xu hướng trong kết quả kiểm thử, điều này có thể giúp họ dự đoán và giải quyết các vấn đề tiềm ẩn trong tương lai.

Bước 5. Phỏng vấn

Phỏng vấn là cho phép QA chia sẻ những gì họ tìm kiếm được với các stakeholder và các cá nhân có liên quan. Các QA tham gia kiểm thử sẽ cùng tập hợp lại để thảo luận về kinh nghiệm, những gì họ quan sát được và các phản hồi của họ về quy trình kiểm thử, cũng như các stakeholder đưa ra các quyết định sáng suốt hơn về tiến độ dự án và giai đoạn kiểm thử tiếp theo. 

Trong cuộc họp phỏng vấn, những QA chia sẻ kinh nghiệm và ý tưởng của họ có thể giúp cải thiện quy trình kiểm thử cho các dự án hoặc chu kỳ trong tương lai. Phản hồi thu được trong phiên phỏng vấn có thể bao gồm bản tóm tắt các lỗi quan trọng nhất đã được tìm ra, chi tiết về các kỹ thuật kiểm thử hiệu quả nhất được sử dụng và đánh giá tiến trình kiểm thử.

Sự khác nhau giữa kiểm thử thăm dò và kiểm thử adhoc (adhoc testing)

Thoạt nhìn, exploratory testing và adhoc testing có vẻ giống nhau. Tuy nhiên, hai phương pháp kiểm thử này khác nhau bởi các phương pháp thực hiện của riêng mình. Adhoc testing thu thập kiến thức trước khi kiểm thử phần mềm. Còn exploratory testing thì giúp cho người thực thi có kiến thức về ứng dụng thông qua quá trình thực hiện kiểm thử.