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ể nghiệ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ở soát
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 đề nghị 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í điể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 thẩm tra các hoạt động cấp thiết bảo đảm thực hiện 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 đề nghị 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 tuổi Xong sau khi thảy các mục trong danh sách kiểm tra DoD được hoàn thành. Một DoD được san sớt 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ể liên tưở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ể nghiệm
thẩm tra vùng phủ sóng
Tái cấu trúc
yêu cầu coi xét và phê duyệt
Ngoài DoD cho Câu chuyện của người dùng, DoD cũng được đề nghị
ở 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 tin soát
Người soát cần có thông tin kiểm tra sau
Câu chuyện của người dùng cần được rà
Tiêu chí ưng ý được liên kết
Giao diện hệ thống
Môi trường nơi Hệ thống được trông chờ sẽ hoạt động
Tính khả dụng của phương tiện
rà soát 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 kiểm tra
Có được thông báo rà soát cấp 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 hành tại các thời điểm phù hợp.
Thiết kế thử nghiệ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 sử dụng, nhưng trọng điể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ể sử 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ể nghiệm phi chức năng, vì các đề nghị 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 sử dụng để thiết kế các trường hợp kiểm tra có liên tưởng.
thể nghiệm dò la
Trong các dự án Agile, thời gian thường là nguyê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 rà dò hỏi có thể được phối hợp với các kỹ thuật thí điểm truyền thống.
rà dò hỏi (ET) được định nghĩa là học tập đồng thời, 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 thẩm tra khi chúng được thực hành và dùng thông tin thu được trong khi thể nghiệm để thiết kế các bài thẩm tra mới và tốt hơn.
rà soát Exploratory có ích để thích nghi với các đổi thay 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ử nghiệ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 sử 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 đề nghị thể nghiệm rộng rãi
Rủi ro thấp chỉ đề nghị rà soát Cursory
Các thí điểm được thiết kế bằng cách sử dụng các kỹ thuật thẩm tra ăn nhậ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.
thẩm tra hạp
Fit Tests là rà soát ưng tự động. phương tiện Fit và FitNesse có thể được dùng để tự động hóa các thí nghiệm hài lò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í điểm trên dự án đang được thí nghiệm.
0 nhận xét:
Đăng nhận xét