Làm thế nào tối đa hóa việc Test Coverage trong thời gian ngắn và đạt được kết quả kiểm thử tốt hơn

Bài đăng này đã không được cập nhật trong 2 năm

Kiểm thử phần mềm là một hoạt động thiết yếu trong chu trình phát triển phần mềm. Đó là một thực tế thường được sử dụng để quyết định và nâng cao chất lượng phần mềm.

Ngày nay, Development có hệ thống hơn và tổ chức tìm kiếm các biện pháp cho testing completeness and effectiveness để cho ra các tiêu chí hoàn thiện kiểm thử. Trong số tất cả chúng, coverage được coi là đặc biệt có giá trị.

Đặt câu hỏi đơn giản, Coverage là khi "chúng ta đang kiểm thử cái gì và chúng ta kiểm thử như thế nào?"

Test coverage sẽ giúp giám sát chất lượng của kiểm thử, và hỗ trợ các tester để tạo ra các case test nhằm cover tối đa các khu vực bị thiếu hoặc không hợp lệ.

Test Coverage và Code Coverage

Test Coverage thường bị nhầm lẫn với Code coverage. Mặc dù các nguyên tắc cơ bản là như nhau, nhưng đây là hai vấn đề khác nhau.

Code coverage nói về thực hành kiểm thử đơn vị ( unit test) đó phải nhắm mục tiêu tất cả các khu vực của các mã code ít nhất một lần và được thực hiện bởi các developer.

Test Coverage, mặt khác, được test mọi yêu cầu ít nhất một lần và rõ ràng là một hoạt động của nhóm QA.

Điều gì thực sự đủ điều kiện để có một yêu cầu được Coverage phụ thuộc vào việc giải thích của mỗi đội.

Ví dụ: Một số nhóm gọi một yêu cầu được Coverage nếu có ít nhất một trường hợp kiểm thử chống lại nó. Đôi khi, nó được bao phủ nếu ít nhất một thành viên trong nhóm được assign cho nó. Hoặc, nếu tất cả các trường hợp kiểm tra liên kết với nó được thực thi.

Nếu có 10 yêu cầu và 100 kiểm thử tạo ra - khi mà những 100 kiểm tra mục tiêu tất cả 10 yêu cầu và không bỏ qua bất kỳ - chúng ta gọi là test Coverage đầy đủ này ở cấp độ thiết kế.
Khi chỉ có 80 trong số các bài kiểm tra tạo ra được thực hiện và chỉ nhắm mục tiêu 6 yêu cầu. Chúng ta nói rằng 4 yêu cầu không được cover mặc dù 80% xét nghiệm được thực hiện. Đây là thống kê Coverage ở một mức độ thực hiện.
Khi chỉ có 90 bài kiểm tra liên quan đến 8 yêu cầu phải xét nghiệm và phần còn lại của họ không được cover, chúng ta nói phạm vi nhiệm vụ kiểm tra là 80% (8 trong số 10 yêu cầu).

Nó cũng quan trọng như khi tính toán Coverage.

Nếu bạn làm điều này quá sớm trong quá trình này, bạn sẽ nhìn thấy rất nhiều khoảng trống bởi vì những điều vẫn còn chưa đầy đủ. Vì vậy, nó thường được khuyên nên chờ đợi cho đến khi xây dựng cuối tức là cuối cùng hồi quy tích xây dựng. Điều này sẽ cung cấp cho một vùng phủ sóng chính xác của các xét nghiệm thực hiện cho các yêu cầu nhất định.

Làm thế nào để áp dụng phương pháp Test Coverage thích hợp?

Nhận thức: Trước tiên, nhóm nghiên cứu QA phải biết được tham gia bao nhiêu công việc và nơi mà các nhiệm vụ thiết kế đang ở. Bằng cách này, họ sẽ phải nhận thức được nếu có nhiều thử nghiệm sẽ được thêm vào. Để làm điều này, bạn có thể sử dụng một RTM (Requirements Traceability Matrix) như là thực hành điển hình. Bài viết tìm hiểu về RTM (Requirements Traceability Matrix): http://www.softwaretestinghelp.com/requirements-traceability-matrix/

Thứ hai, kiểm tra phân công resource và quá trình thực hiện test để xem nếu tất cả mọi thứ được kiểm tra một cách hiệu quả hơn.

Làm thế nào để đảm bảo mọi thứ được kiểm tra và theo cách tốt nhất có thể?

Mỗi người thử cần phải nhận thức được các yêu cầu và phương pháp thử nghiệm
Ưu tiên yêu cầu của bạn và tập trung năng lượng của bạn vào nơi mà cần thiết nhất
Được thông báo về một bản release nhất định để bạn có thể xác định các yêu cầu quan trọng chính xác hơn và tập trung vào tin tức có lợi tối đa
Thích ứng kiểm thử tự động hóa
Sử dụng các công cụ quản lý kiểm thử
Sự phân công công việc thông minh của chính bạn
Có một checklist cho tất cả các tasks và hoạt động khác
Tương tác nhiều hơn với các đội Dev / BA / Scrum của bạn để có được cái nhìn sâu ứng dụng
Theo dõi tất cả bản builds và fixes của bạn từ đầu đến cuối
Xác định vấn đề lớn nhất tác động vào các bản builds, giúp các bản builds có tính ổn định hơn khi các vấn đề đã được ngăn chặn.

Các tiêu chí quan trọng và phương pháp để kiểm thử hiệu quả là:

Jumbling Resource: nhiệm vụ trao đổi giữa những thành viên trong nhóm của bạn. Điều này giúp cải thiện sự tham gia và ngăn chặn sự tập trung kiến thức.
Coverage tương thích: Hãy chắc chắn rằng bạn nhận thức được và bao gồm cả các trình duyệt khác nhau và nền tảng để kiểm tra ứng dụng của bạn.
Quyền sở hữu: Làm cho các tester có trách nhiệm cung cấp cho họ mộtsự thoải mái với các module / công việc mà họ đang làm việc. Điều này giúp xây dựng trách nhiệm và cho phép họ thử những cách sáng tạo.
Thời gian deadlines: Biết được thời gian release cuối cùng trước khi bắt đầu giai đoạn kiểm thử giúp lập kế hoạch hiệu quả hơn
Communication : Giữ liên lạc với các dev và các đội khác ở giữa chu kỳ phát hành phải biết những gì đang xảy ra.
Duy trì một RTM: đóng vai trò như một dẫn xuất tốt để các đối tác hoặc khách hàng , trên cơ sở đó lịch release có thể được xác nhận

Ưu điểm của Test Coverage cho một Tester:

Nó chủ yếu giúp với kiểm thử những tasks ưu tiên
Nó giúp đạt được 100% Coverage yêu cầu hay nói cách khác, nó ngăn chặn rò rỉ yêu cầu
Phân tích tác động trở nên dễ dàng hơn
Hữu ích trong việc xác định các tiêu chí EXIT
Cho phép test lead chuẩn bị một test closure report rõ ràng

Phần kết luận:

Nó không phải là luôn luôn đúng là khi bạn kiểm thử nhiều hơn, kết quả là tốt hơn. Trong thực tế, khi bạn kiểm thử nhiều hơn khi không có chiến lược rõ ràng, bạn có lẽ sẽ tốn rất nhiều thời gian.

Bài viết được tham khảo từ: http://www.softwaretestinghelp.com/maximize-test-coverage-in-less-time/