Kỹ thuật thể nghiệm từ thử nghiệm truyền thống cũng có thể được dùng trong thí điểm Agile. Thêm vào đó, các kỹ thuật và thuật ngữ thí điểm cụ thể của Agile được sử dụng trong các dự án Agile.
|
|
|
ảnh minh họa : học kiểm thử |
Cơ sở thẩm tra
Trong các dự án nhanh, sản phẩm tồn đọng thay thế các tài liệu đặc tả đề nghị. Nội dung của việc tồn đọng sản phẩm thường là những câu chuyện của người dùng. Các yêu cầu phi chức năng cũng được chú ý trong các câu chuyện của người dùng. Do đó, cơ sở thể nghiệm trong các dự án Agile là câu chuyện của người dùng.
Để đảm bảo thẩm tra chất lượng, những điều sau đây cũng có thể được coi xét bổ sung làm cơ sở thử nghiệm
Trải nghiệm từ các lần lặp lại trước đó của cùng một dự án hoặc các dự án trước đây.
Các chức năng, kiến trúc, thiết kế, mã và đặc điểm chất lượng hiện có của hệ thống.
Lỗi dữ liệu từ các dự án hiện tại và quá vãng.
Phản hồi của khách hàng.
Tài liệu người dùng.
Định nghĩa của Done
Định nghĩa hoàn thành (DoD) là các tiêu chí được dùng trong các dự án Agile để đảm bảo hoàn tất một hoạt động trong phần tồn đọng của Sprint. DoD có thể thay đổi từ nhóm Scrum này sang nhóm Scrum khác, nhưng nó phải nhất quán trong một nhóm.
DoD là một danh sách kiểm tra các hoạt động cấp thiết bảo đảm thực hành các chức năng và tính năng trong một câu chuyện của người dùng cùng với các yêu cầu phi chức năng là một phần của câu chuyện của người dùng. Câu chuyện của người dùng đạt đến thời đoạn Xong sau khi thảy các mục trong danh sách rà DoD được hoàn thành. Một DoD được san sẻ giữa các nhóm.
Một DoD tiêu biểu cho một câu chuyện của người dùng có thể chứa
Tiêu chí chấp thuận rà soát chi tiết
Tiêu chí để bảo đảm tính nhất quán của User Story với những người khác trong Iteration
Tiêu chí cụ thể hệ trọng đến Sản phẩm
Các góc cạnh hành vi chức năng
Đặc điểm phi chức năng
Giao diện
đề nghị dữ liệu thí điểm
soát vùng phủ sóng
Tái cấu trúc
đề nghị coi xét và duyệt
Ngoài DoD cho Câu chuyện của người dùng, DoD cũng được yêu cầu
ở mọi cấp độ rà soát
cho từng tính năng
cho mỗi lần lặp lại
để phát hành
thông báo rà soát
Người kiểm tra cần có thông báo rà sau
Câu chuyện của người dùng cần được rà soát
Tiêu chí bằng lòng được liên kết
Giao diện hệ thống
Môi trường nơi Hệ thống được mong chờ sẽ hoạt động
Tính khả dụng của công cụ
kiểm tra vùng phủ sóng
DoD
Trong các dự án Agile, vì thử nghiệm không phải là một hoạt động lần lượt và kiểm thử được cho là hoạt động trong một chế độ hiệp tác, đó là nghĩa vụ của người rà soát
Có được thông tin soát cần thiết trên cơ sở liên tiếp.
Xác định khoảng trống thông báo ảnh hưởng đến thí nghiệm.
Giải quyết các khoảng trống cộng tác với các thành viên khác trong nhóm.
Quyết định khi nào đạt đến mức thể nghiệm.
đảm bảo các thí nghiệm thích hợp được thực hiện tại các thời khắc hiệp.
Thiết kế thí điểm chức năng và phi chức năng
Trong các dự án Agile, các kỹ thuật thể nghiệm truyền thống có thể được dùng, nhưng trọng tâm là thử nghiệm sớm. Các trường hợp thí nghiệm cần phải được đặt trước khi bắt đầu triển khai.
Đối với thiết kế thể nghiệm chức năng, người thử nghiệm và nhà phát triển có thể dùng các kỹ thuật thiết kế thể nghiệm Hộp đen truyền thống như
Phân vùng tương đương
phân tách giá trị ranh giới
Bảng quyết định
Chuyển tiếp tiểu bang
Class Tree
Đối với thiết kế thí điểm phi chức năng, vì các yêu cầu phi chức năng cũng là một phần của mỗi câu chuyện của người dùng, các kỹ thuật thiết kế thể nghiệm hộp đen chỉ có thể được dùng để thiết kế các trường hợp thẩm tra có liên quan.
thí điểm thăm dò
Trong các dự án Agile, thời gian thường là nhân tố giới hạn cho phân tách thử nghiệm và thiết kế thí nghiệm. Trong những trường hợp như vậy, các kỹ thuật soát dò hỏi có thể được phối hợp với các kỹ thuật thể nghiệm truyền thống.
rà dò hỏi (ET) được định nghĩa là học tập song song, thiết kế thí nghiệm và thực hành soát. Trong thí điểm Exploratory, người thí nghiệm chủ động kiểm soát thiết kế của các bài soát khi chúng được thực hiện và sử dụng thông báo thu được trong khi thí điểm để thiết kế các bài rà soát mới và tốt hơn.
rà Exploratory có ích để thích ứng với các thay đổi trong các dự án Agile.
thí nghiệm dựa trên rủi ro
thử nghiệm dựa trên rủi ro là thử nghiệm dựa trên nguy cơ thất bại và giảm thiểu rủi ro bằng cách sử dụng các kỹ thuật thiết kế thí điểm.
Rủi ro chất lượng sản phẩm có thể được xác định là một vấn đề tiềm tàng với chất lượng sản phẩm. Rủi ro chất lượng sản phẩm bao gồm
Rủi ro chức năng
Rủi ro hiệu suất phi chức năng
Rủi ro khả năng dùng phi chức năng
phân tách rủi ro phải được thực hành để đánh giá xác suất (khả năng) và tác động của từng rủi ro. Sau đó, các rủi ro được ưu tiên
Rủi ro cao yêu cầu thử nghiệm rộng rãi
Rủi ro thấp chỉ yêu cầu rà soát Cursory
Các thí điểm được thiết kế bằng cách dùng các kỹ thuật thẩm tra hợp dựa trên mức độ rủi ro và đặc điểm rủi ro của từng rủi ro. Các thí nghiệm sau đó được thực hành để giảm thiểu rủi ro.
rà ăn nhập
Fit Tests là rà chấp nhận tự động. công cụ Fit và FitNesse có thể được dùng để tự động hóa các thử nghiệm ưng.
FIT sử dụng JUnit, nhưng mở rộng chức năng thẩm tra. Các bảng HTML được dùng để hiển thị các trường hợp Kiểm thử. Lịch thi đấu là một lớp Java phía sau bảng HTML. Lịch thi đấu lấy nội dung của bảng HTML và chạy các trường hợp thể nghiệm trên dự án đang được thử nghiệm.
No comments:
Post a Comment