Kiểm tra Agile - Kỹ thuật

Các Kỹ thuật Kiểm tra từ kiểm thử truyền thống cũng có thể được sử dụng trong kiểm thử Agile. Ngoài những điều này, các thuật ngữ và kỹ thuật thử nghiệm cụ thể của Agile được sử dụng trong các dự án Agile.

Cơ sở thử nghiệm

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 sản phẩm tồn đọng thường là câu chuyện của người dùng. Các yêu cầu phi chức năng cũng được quan tâm 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 người dùng.

Để đảm bảo thử nghiệm chất lượng, những điều sau đây cũng có thể được coi là cơ sở thử nghiệm bổ sung:

Kinh nghiệm từ các lần lặp trước của cùng một dự án hoặc các dự án trong quá khứ.
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 về Hoàn thành

Định nghĩa Hoàn thành (DoD) là 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 Sprint tồn đọng. 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à danh sách kiểm tra các hoạt động cần thiết đảm bảo việc triển khai các chức năng và tính năng trong câu chuyện 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 người dùng. Câu chuyện của người dùng đạt đến giai đoạn Hoàn tất sau khi tất cả các mục trong danh sách kiểm tra DoD được hoàn thành. Một DoD được chia sẻ trong nhóm.

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

Tiêu chí chấp nhận chi tiết có thể kiểm tra
Các tiêu chí để đảm bảo tính nhất quán của Câu chuyện người dùng với những người khác trong Lặp lại
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
Interfaces
Yêu cầu dữ liệu thử nghiệm
Kiểm tra vùng phủ sóng
Refactoring
Yêu cầu xem xét và phê duyệt

Ngoài DoD cho Câu chuyện người dùng, DoD cũng được yêu cầu -

ở mọi cấp độ kiểm tra
cho mỗi Tính năng
cho mỗi Lặp lại
để phát hành

Thông tin kiểm tra

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

Câu chuyện của người dùng cần được kiểm tra
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 dự kiến 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 tuần tự và người kiểm thử phải làm việc trong chế độ cộng tác, nên người kiểm thử có trách nhiệm -

Thu thập thông tin thử nghiệm cần thiết trên cơ sở liên tục.
Xác định các lỗ hổng thông tin ảnh hưởng đến thử nghiệm.
Hợp tác giải quyết các khoảng cách với các thành viên khác trong nhóm.
Quyết định khi nào đạt đến cấp độ kiểm tra.
Đảm bảo các thử nghiệm thích hợp được thực hiện vào các thời điểm thích hợp.

Thiết kế kiểm tra chức năng và phi chức năng

Trong các dự án Agile, các kỹ thuật kiểm thử truyền thống có thể được sử dụng, nhưng trọng tâm là kiểm thử sớm. Các trường hợp kiểm thử cần phải có 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 đổi trạng thái
Cây lớp

Đối với thiết kế kiểm thử 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 người dùng, các kỹ thuật thiết kế kiểm thử hộp đen chỉ có thể được sử dụng để thiết kế các trường hợp kiểm thử liên quan.

Thử nghiệm thăm dò

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

Thử nghiệm khám phá (ET) được định nghĩa là học đồng thời, thiết kế thử nghiệm và thực hiện thử nghiệm. Trong Thử nghiệm khám phá, người thử nghiệm chủ động kiểm soát thiết kế của các thử nghiệm 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 thử nghiệm mới và tốt hơn.

Thử nghiệm Khám phá rất hữu ích để đáp ứng các thay đổi trong các dự án Agile.

Kiểm tra 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 rủi ro 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 về chất lượng sản phẩm có thể được định nghĩa là một vấn đề tiềm ẩn đối với chất lượng sản phẩm. Rủi ro về chất lượng sản phẩm bao gồm -

Rủi ro chức năng
Rủi ro hoạt động phi chức năng
Rủi ro về khả năng sử dụng phi chức năng

Phân tích rủi ro được thực hiện để đánh giá xác suất (khả năng xảy ra) 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 mở rộng
Rủi ro thấp chỉ yêu cầu Kiểm tra Cursory

Các thử nghiệm được thiết kế bằng các Kỹ thuật Kiểm tra thích 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 tra phù hợp

Kiểm tra phù hợp là Kiểm tra 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 thử nghiệm. Bảng HTML được sử dụng để hiển thị các trường hợp Kiểm tra. Fixture là một lớp Java phía sau bảng HTML. Vật cố định 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.