Kiểm thử nhanh - Sản phẩm công việc

Kế hoạch kiểm thử phần mềm được chuẩn bị tại thời điểm lập kế hoạch phát hành và được sửa đổi tại mọi quy hoạch Sprint. Kế hoạch kiểm thử phần mềm hoạt động như một hướng dẫn cho quá trình thử nghiệm để có phạm vi kiểm thử phần mềm hoàn chỉnh.

kiểm thử phần mềm

Nội dung điển hình của một kế hoạch thử nghiệm là

Chiến lược kiểm thử phần mềm 

Môi trường thử nghiệm

Kiểm thử phần mềm vùng phủ sóng

Phạm vi thử nghiệm

Kiểm thử phần mềm nỗ lực và lịch trình

Công cụ kiểm thử phần mềm 

Trong các dự án Agile, tất cả các Thành viên Nhóm chịu trách nhiệm về chất lượng của sản phẩm. Do đó, tất cả mọi người tham gia vào kế hoạch kiểm thử phần mềm là tốt.

Trách nhiệm của người kiểm thử phần mềm là cung cấp hướng đi cần thiết và cố vấn cho các thành viên còn lại của nhóm với chuyên môn kiểm thử phần mềm của họ.

Câu chuyện của người dùng

Câu chuyện của người dùng không thử nghiệm sản phẩm công việc theo nguyên tắc. Tuy nhiên, trong các Dự án Agile, những người thử nghiệm tham gia vào Tạo Câu chuyện của Người dùng. Người thử nghiệm viết Câu chuyện của người dùng mang lại giá trị cho khách hàng và bao gồm các hành vi có thể khác nhau của hệ thống.

Người thử nghiệm cũng đảm bảo rằng tất cả các Câu chuyện của người dùng đều có thể kiểm thử phần mềm và đảm bảo Tiêu chí chấp nhận.

Kiểm thử thủ công và tự động

Trong lần chạy thử nghiệm đầu tiên, các xét nghiệm thủ công được sử dụng. Chúng bao gồm -

Bài kiểm thử phần mềm đơn vị

Kiểm thử phần mềm tích hợp

Kiểm thử phần mềm chức năng

Kiểm thử phần mềm phi chức năng

Kiểm thử phần mềm chấp nhận

Các thử nghiệm sau đó được tự động cho các lần chạy tiếp theo.

Trong Test Driven Development , Unit Test được viết đầu tiên thất bại, Code được phát triển và thử nghiệm để đảm bảo các bài kiểm thử phần mềm vượt qua.

Trong Kiểm thử phần mềm chấp nhận phát triển theo hướng , Kiểm thử phần mềm chấp nhận được viết đầu tiên không thành công, Mã được phát triển và kiểm thử phần mềm để đảm bảo các bài  vượt qua.

Trong các phương pháp Phát triển khác, các Testers cộng  tác với các thành viên khác của Nhóm để đảm bảo Kiểm thử phần mềm Bảo hiểm.

Trong tất cả các loại phương thức, việc tích hợp liên tục diễn ra, bao gồm thử nghiệm tích hợp liên tục.

Nhóm có thể quyết định khi nào và những thử nghiệm nào sẽ được tự động hóa. Ngay cả khi tự động hóa các bài kiểm thử phần mềm đòi hỏi nỗ lực và thời gian, kết quả kiểm thử phần mềm tự động làm giảm đáng kể nỗ lực thử nghiệm lặp đi lặp lại và thời gian trong các lần lặp của dự án Agile. Điều này lần lượt tạo điều kiện cho nhóm chú ý hơn đến các hoạt động cần thiết khác, chẳng hạn như Câu chuyện người dùng mới, Thay đổi, v.v.

Trong Scrum , các lần lặp lại được đóng khung thời gian. Do đó, nếu không thể hoàn thành việc kiểm thử phần mềm Câu chuyện của người dùng trong Sprint cụ thể, người kiểm thử phần mềm có thể báo cáo trong cuộc họp standup hàng ngày mà câu chuyện của người dùng không thể đạt được Trạng thái đã hoàn thành trong Sprint đó và do đó cần được giữ cho Sprint tiếp theo.

Kết quả kiểm thử

Vì hầu hết các thử nghiệm trong các dự án Agile được tự động hóa, các công cụ tạo ra các bản ghi kết quả kiểm thử phần mềm cần thiết. Người thử nghiệm xem lại Nhật ký kết quả thử nghiệm. Các kết quả kiểm thử phần mềm cần phải được duy trì cho mỗi lần chạy nước rút / giải phóng.

Bản tóm tắt thử nghiệm cũng có thể được chuẩn bị có chứa -

Phạm vi kiểm thử phần mềm (Điều gì đã được kiểm thử phần mềm và những gì không được kiểm thử phần mềm )

Phân tích lỗi cùng với Phân tích nguyên nhân gốc nếu có thể

Trạng thái kiểm thử phần mềm hồi quy sau khi sửa lỗi

Các vấn đề và độ phân giải tương ứng

Các sự cố đang chờ xử lý, nếu có

Bất kỳ sửa đổi nào được yêu cầu trong Chiến lược thử nghiệm

Chỉ số kiểm thử phần mềm 

Báo cáo chỉ số thử nghiệm

Trong các dự án Agile, các chỉ số kiểm thử phần mềm a bao gồm những điều sau cho mỗi Sprint -

Nỗ lực thử nghiệm

Kiểm thử phần mềm độ chính xác ước tính

Kiểm thử phần mềm vùng phủ sóng

Phạm vi kiểm thử phần mềm tự động

Số lỗi

Tỷ lệ lỗi (Số lỗi trên mỗi điểm câu chuyện của người dùng)

Lỗi nghiêm trọng

Thời gian để khắc phục lỗi trong cùng một Sprint (Chi phí càng nhiều càng nhiều để khắc phục lỗi thoát khỏi chạy nước rút hiện tại)

Số lỗi được khắc phục trong cùng Sprint

Hoàn thành kiểm thử phần mềm chấp nhận của khách hàng trong Sprint

Báo cáo đánh giá và hồi tưởng Sprint

Những người kiểm thử phần mềm cũng đóng góp cho Báo cáo đánh giá và hồi tưởng Sprint. Các nội dung điển hình là

Chỉ số kiểm thử

Nhật ký kết quả kiểm thử phần mềm kết quả đánh giá

Điều gì đã đúng và những gì có thể được cải thiện từ Điểm kiểm thử phần mềm xem

Thực hành tốt nhất

Bài học kinh nghiệm

Vấn đề

Phản hồi của khách hàng