Kế hoạch kiểm thử hoạt động như một hướng dẫn cho quá trình thử nghiệm để có phạm vi kiểm thử hoàn chỉnh.
Chiến lược kiểm thử
Môi trường thử nghiệm
Kiểm thử vùng phủ sóng
Phạm vi kiểm thử
Kiểm thử nỗ lực và lịch trình
Công cụ kiểm thử
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ử là tốt.
Nội dung tiêu biểu của Kế hoạch kiểm thử là
Chiến lược kiểm thử
Môi trường thử nghiệm
Kiểm thử vùng phủ sóng
Phạm vi kiểm thử
Kiểm thử nỗ lực và lịch trình
Công cụ kiểm thử
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ử là tốt.
 |
| kiểm thử phần mềm |
Trách nhiệm của người kiểm thử là cung cấp hướng dẫn cần thiết và cố vấn cho phần còn lại của đội với chuyên môn kiểm thử của họ.
Câu chuyện người dùng không kiểm thử sản phẩm làm việc trên nguyên tắc. Tuy nhiên, trong Dự án Agile, những người thử nghiệm tham gia vào Tạo câu chuyện người dùng. Người kiểm thử viết Câu chuyện người dùng mang lại giá trị cho khách hàng và bao gồm các hành vi khác nhau có thể có của hệ thống.
Người kiểm thử 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ử được và đảm bảo Tiêu chí chấp nhận.
Trong lần chạy thử đầu tiên, Kiểm thử thủ công được sử dụng. Chúng bao gồm -
Bài kiểm thử đơn vị
Kiểm thử tích hợp
Kiểm thử chức năng
Các xét nghiệm phi chức năng
Xét nghiệm nghiệm thu
Các bài kiểm thử phần mềm sau đó được tự động cho các lần chạy tiếp theo.
Trong Phát triển hướng thử nghiệm, các thử nghiệm đơn vị được viết trước tiên để thất bại, Mã được phát triển và thử nghiệm để đảm bảo các Thử nghiệm vượt qua.
Trong thử nghiệm chấp nhận hướng phát triển , các thử nghiệm chấp nhận được viết trước tiên để thất bại, Code được phát triển và thử nghiệm để đảm bảo các thử nghiệm vượt qua.
Trong các phương pháp Phát triển khác, Người kiểm thử cộng tác với các thành viên còn lại trong Nhóm để đảm bảo Phạm vi kiểm thử .
Trong tất cả các loại phương thức, tích hợp liên tục diễn ra, bao gồm kiểm thử tích hợp liên tục.
Nhóm có thể quyết định khi nào và những bài kiểm thử nào sẽ được tự động hóa. Ngay cả khi tự động hóa các thử nghiệm đòi hỏi nỗ lực và thời gian, các thử nghiệm tự động kết quả sẽ giảm đáng kể nỗ lực và thời gian thử nghiệm lặp đi lặp lại trong các lần lặp của Dự án Agile.
Câu chuyện của người dùng
Câu chuyện người dùng không kiểm thử sản phẩm làm việc trên nguyên tắc. Tuy nhiên, trong Dự án Agile, những người thử nghiệm tham gia vào Tạo câu chuyện người dùng. Người kiểm thử viết Câu chuyện người dùng mang lại giá trị cho khách hàng và bao gồm các hành vi khác nhau có thể có của hệ thống.
Người kiểm thử 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ử được 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ử đầu tiên, Kiểm thử thủ công được sử dụng. Chúng bao gồm -
Bài kiểm thử đơn vị
Kiểm thử tích hợp
Kiểm thử chức năng
Các xét nghiệm phi chức năng
Xét nghiệm nghiệm thu
Các bài kiểm thử phần mềm sau đó được tự động cho các lần chạy tiếp theo.
Trong Phát triển hướng thử nghiệm, các thử nghiệm đơn vị được viết trước tiên để thất bại, Mã được phát triển và thử nghiệm để đảm bảo các Thử nghiệm vượt qua.
Trong thử nghiệm chấp nhận hướng phát triển , các thử nghiệm chấp nhận được viết trước tiên để thất bại, Code được phát triển và thử nghiệm để đảm bảo các thử nghiệm vượt qua.
Trong các phương pháp Phát triển khác, Người kiểm thử cộng tác với các thành viên còn lại trong Nhóm để đảm bảo Phạm vi kiểm thử .
Trong tất cả các loại phương thức, tích hợp liên tục diễn ra, bao gồm kiểm thử tích hợp liên tục.
Nhóm có thể quyết định khi nào và những bài kiểm thử nào sẽ được tự động hóa. Ngay cả khi tự động hóa các thử nghiệm đòi hỏi nỗ lực và thời gian, các thử nghiệm tự động kết quả sẽ giảm đáng kể nỗ lực và thời gian thử nghiệm lặp đi lặp lại 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 được đóng hộp theo thời gian. Do đó, nếu không thể hoàn thành kiểm thử Câu chuyện người dùng trong một Sprint cụ thể, người kiểm thử có thể báo cáo trong cuộc họp chờ hàng ngày rằng câu chuyện của người dùng không thể đạt đến Trạng thái đã hoàn thành trong Sprint đó và do đó cần phải chờ đến Sprint tiếp theo.
Vì hầu hết các Thử nghiệm trong Dự án Agile đều được tự động, Công cụ tạo Nhật ký kết quả kiểm thử cần thiết. Người kiểm thử xem lại Nhật ký kết quả kiểm thử . Các kết quả kiểm thử cần được duy trì cho mỗi lần chạy nước rút / phát hành.
Tóm tắt kiểm thử cũng có thể được chuẩn bị có chứa
Phạm vi thử nghiệm (Những gì đã được thử nghiệm và những gì chưa được thử nghiệ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ử hồi quy sau khi sửa lỗi
Các vấn đề và Nghị quyết tương ứng
Vấn đề đ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
Kiểm thử số liệu
Trong các dự án Agile, Số liệu kiểm thử bao gồm các số liệu sau cho mỗi Sprint
Nỗ lực kiểm thử
Kiểm thử độ chính xác dự toán
Kiểm thử vùng phủ sóng
Bảo hiểm kiểm thử tự động
Số khuyết tật
Tỷ lệ lỗi (Số lỗi trên mỗi điểm câu chuyện của người dùng)
Khiếm khuyết nghiêm trọng
Thời gian để khắc phục một lỗi trong cùng một Sprint (Chi phí phải trả là 24x để sửa một lỗi thoát khỏi nước rút hiện tại)
Số lỗi được sửa trong cùng một Sprint
Hoàn thành kiểm thử chấp nhận của khách hàng trong Sprint
Những người thử nghiệm cũng đóng góp vào Báo cáo Hồi cứu và Hồi cứu của Sprint. Các nội dung tiêu biểu là
Kiểm thử phần mềm số liệu
Kết quả kiểm thử Nhật ký kết quả xem xét
Điều gì đã đúng và những gì có thể được cải thiện từ Quan điểm thử nghiệm
Thực hành tốt nhất
Bài học kinh nghiệm
Các vấn đề
Phản hồi của khách hàng
Trong Scrum , các lần lặp được đóng hộp theo thời gian. Do đó, nếu không thể hoàn thành kiểm thử Câu chuyện người dùng trong một Sprint cụ thể, người kiểm thử có thể báo cáo trong cuộc họp chờ hàng ngày rằng câu chuyện của người dùng không thể đạt đến Trạng thái đã hoàn thành trong Sprint đó và do đó cần phải chờ đến Sprint tiếp theo.
Kết quả kiểm thử phần mềm.
Vì hầu hết các Thử nghiệm trong Dự án Agile đều được tự động, Công cụ tạo Nhật ký kết quả kiểm thử cần thiết. Người kiểm thử xem lại Nhật ký kết quả kiểm thử . Các kết quả kiểm thử cần được duy trì cho mỗi lần chạy nước rút / phát hành.
Tóm tắt kiểm thử cũng có thể được chuẩn bị có chứa
Phạm vi thử nghiệm (Những gì đã được thử nghiệm và những gì chưa được thử nghiệ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ử hồi quy sau khi sửa lỗi
Các vấn đề và Nghị quyết tương ứng
Vấn đề đ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
Kiểm thử số liệu
Kiểm thử phần mềm số liệu báo cáo
Trong các dự án Agile, Số liệu kiểm thử bao gồm các số liệu sau cho mỗi Sprint
Nỗ lực kiểm thử
Kiểm thử độ chính xác dự toán
Kiểm thử vùng phủ sóng
Bảo hiểm kiểm thử tự động
Số khuyết tật
Tỷ lệ lỗi (Số lỗi trên mỗi điểm câu chuyện của người dùng)
Khiếm khuyết nghiêm trọng
Thời gian để khắc phục một lỗi trong cùng một Sprint (Chi phí phải trả là 24x để sửa một lỗi thoát khỏi nước rút hiện tại)
Số lỗi được sửa trong cùng một Sprint
Hoàn thành kiểm thử chấp nhận của khách hàng trong Sprint
Báo cáo hồi cứu và hồi cứu của Sprint
Những người thử nghiệm cũng đóng góp vào Báo cáo Hồi cứu và Hồi cứu của Sprint. Các nội dung tiêu biểu là
Kiểm thử phần mềm số liệu
Kết quả kiểm thử Nhật ký kết quả xem xét
Điều gì đã đúng và những gì có thể được cải thiện từ Quan điểm thử nghiệm
Thực hành tốt nhất
Bài học kinh nghiệm
Các vấn đề
Phản hồi của khách hàng
Không có nhận xét nào:
Đăng nhận xét