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 sử dụng trong thử nghiệ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.

kiểm thử phần mềm

Cơ sở kiểm thử

Trong các dự án nhanh, sản phẩm tồn đọng thay thế các tài liệu đặc tả yêu cầu. 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 kiểm thử phần mềm chất lượng, những điều sau đây cũng có thể được xem 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á 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 thành (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ể 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 thử các hoạt động cần 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 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 giai đoạn Xong sau khi tất cả các mục trong danh sách kiểm thử  DoD được hoàn thành. Một DoD được chia sẻ giữa các nhóm.

Một DoD điển hình cho một câu chuyện của người dùng có thể chứa

Tiêu chí chấp nhận kiểm thử 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 quan đế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 thử vùng phủ sóng

Tái cấu trúc

Yêu cầu xem xét và phê 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 độ kiểm thử 

cho từng tính năng

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

để phát hành

Thông tin kiểm thử

Người kiểm thử cần có thông tin Kiểm thử sau

Câu chuyện của người dùng cần được kiểm thử 

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ụ

Kiểm thử 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 tuần tự và người thử nghiệm được cho là làm việc trong một chế độ cộng tác, đó là trách nhiệm của người kiểm thử

Có được thông tin kiểm thử  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 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 điểm thích 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 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ể 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 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 kiểm thử có liên quan.

Thử nghiệm thăm dò

Trong các dự án Agile, thời gian thường là yếu 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 kiểm thử thăm dò có thể được kết hợp với các kỹ thuật thử nghiệm truyền thống.

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

Kiểm thử 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ử 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 hiện để đá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 kiểm thử Cursory

Các thử nghiệm được thiết kế bằng cách sử dụng các kỹ thuật kiểm thử phù 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 hiện để giảm thiểu rủi ro.

Kiểm thử phù hợp

Fit Tests là Kiểm thử chấp nhận tự động. Công cụ Fit và FitNesse có thể được sử dụng để tự động hóa các thử nghiệm chấp nhận.

FIT sử dụng JUnit, nhưng mở rộng chức năng kiểm thử. Các bảng HTML được sử 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.