Kiểm tra nhanh - Kỹ thuật

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 dùng trong các dự án Agile.

 

ảnh minh họa : học kiểm thử 

 

Cơ sở kiể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 để ý 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 soát 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 ngày nay và quá khứ.

 

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 tất (DoD) là các tiêu chí được sử dụng trong các dự án Agile để đảm bảo hoàn thành một hoạt động trong phần tồn đọng của Sprint. DoD có thể đổi thay 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 rà soát các hoạt động cấp thiết đảm bảo 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 tuốt luốt các mục trong danh sách thẩ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 nhận rà chi tiết

 

Tiêu chí để đảm bảo 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 can đến Sản phẩm

 

Các khía cạnh hành vi chức năng

 

Đặc điểm phi chức năng

 

Giao diện

 

yêu cầu dữ liệu thí nghiệm

 

kiểm tra vùng phủ sóng

 

Tái cấu trúc

 

yêu cầu coi xét và thông qua

 

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 độ kiểm tra

 

cho từng tính năng

 

cho mỗi lần lặp lại

 

để phát hành

thông tin thẩm tra

Người rà soát cần có thông báo soát sau

 

Câu chuyện của người dùng cần được soát

 

Tiêu chí chấp nhận được liên kết

 

Giao diện hệ thống

 

Môi trường nơi Hệ thống được mong đợi sẽ hoạt động

 

Tính khả dụng của công cụ

 

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ế độ cộng tác, đó là nghĩa vụ của người rà

 

Có được thông báo kiểm tra cần thiết trên cơ sở liên tục.

 

Xác định khoảng trống thông tin ảnh hưởng đến thể nghiệm.

 

Giải quyết các khoảng trống hợp 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í điểm hiệp được thực hành tại các thời khắc 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í điểm truyền thống có thể được sử dụng, nhưng trung tâm là thí nghiệm sớm. Các trường hợp thí điểm cần phải được đặt trước khi bắt đầu khai triển.

 

Đố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ử nghiệ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 sử dụng để thiết kế các trường hợp thẩm tra có liên quan.

thí nghiệm dò la

Trong các dự án Agile, thời kì thường là nhân tố giới hạn cho phân tách thể nghiệm và thiết kế thí điểm. Trong những trường hợp như vậy, các kỹ thuật soát dò xét có thể được phối hợp với các kỹ thuật thử nghiệm truyền thống.

 

kiểm tra thăm dò (ET) được định tức là học tập đồng thời, thiết kế thể nghiệm và thực hành kiểm tra. Trong thử nghiệm Exploratory, người thí điểm chủ động kiểm soát thiết kế của các bài rà khi chúng được thực hiện và dùng thông báo thu được trong khi thí nghiệm để thiết kế các bài rà soát mới và tốt hơn.

 

rà soát Exploratory hữu dụng để thích ứng với các thay đổi trong các dự án Agile.

thí điểm dựa trên rủi ro

thử nghiệm dựa trên rủi ro là thí điể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 ẩn 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ị kiểm tra Cursory

 

Các thí điểm được thiết kế bằng cách sử dụng các kỹ thuật kiể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í điểm sau đó được thực hành để giảm thiểu rủi ro.

kiểm tra thích hợp

Fit Tests là kiểm tra bằng lòng tự động. phương tiện Fit và FitNesse có thể được dùng để tự động hóa các thể nghiệm chấp nhận.

 

FIT 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.