Liên tục kiểm thử trong Agile- nghĩa là gì ?

Trong thế giới Phát triển Agile nơi việc phát hành sản phẩm thường xuyên , làm thế nào chúng ta có thể đảm bảo rằng sẽ phát hành sản phẩm mà không có các lỗi chính và duy trì các chức năng được hoạt động. Kiểm thử liên tục là câu trả lời - nhưng kiểm thử liên tục chính xác là gì và làm thế nào chúng ta đạt được một trạng thái như vậy trong chiến lược phát triển ? Trong chiến lược kiểm thử Agile, dựa trên hai nguyên tắc cơ bản

Ngăn ngừa lỗi hơn là phát hiện khuyết tật

Vòng lặp phản hồi nhanh Chúng ta hãy cùng khám phá hai điểm này và xem nó liên quan đến việc kiểm thử liên tục như thế nào.

Nếu chúng ta giả định rằng mục tiêu cuối cùng của việc phát hành phần mềm là mô hình phát hành liên tục, thì chúng ta không thể mắc sai lầm lớn. Mục đích chính là để có thể phát hành phần mềm liên tục và thông suốt mà không cần phải đi lại nhiều lần để khắc phục các vấn đề.

Chúng ta đều biết rằng chi phí sửa lỗi sẽ tăng khi sản phẩm được phát hành. Sẽ mất rất nhiều thời gian để điều tra (các) vấn đề và cố gắng tìm ra nguyên nhân gốc rễ của sự thất bại. Vì vậy, nó là điều cần thiết để đảm bảo rằng chúng ta xây dựng sản phẩm đúng và xây dựng nó đúng ngay từ đầu.

Điều này có nghĩa là khi chúng ta chọn một tính năng của người dùng hoặc nhiệm vụ nhỏ để làm việc trong một sprint, chúng ta cần phải hiểu yêu cầu của nhiệm vụ. Nhiệm vụ nên được giữ gìn cẩn thận với tất cả các tiêu chí chấp nhận và mọi người đều cần phải có sự hiểu biết tương tự về cách tính năng. Chúng ta cũng cần có cơ chế phản hồi nhanh tại chỗ, để nếu có bất kỳ vấn đề nào với bản build mới, chúng ta sẽ tìm hiểu về nó và khắc phục ngay lập tức. Điều này thường được thực hiện thông qua kiểm tra tự động.

Một điều cần lưu ý là kiểm thử liên tục không phải là kiểm thử tự động.

Kiểm thử liên tục trong Agile

Hãy chia ra các giai đoạn phát triển một tính năng mới và phát hành sản phẩm. Chúng ta cần điều này để xem giai đoạn nào chúng ta cần phải kiểm tra và loại kiểm thử nào là bắt buộc.

1. Chuyện trò (Review)

Đây là giai đoạn đầu tiên có thể đưa ra các khuyết tật. Tối thiểu, chúng ta cần đảm bảo rằng các tính năng của người dùng có thể kiểm chứng được và có một bộ tiêu chí chấp nhận tốt. Điều này thường được thực hiện thông qua cuộc họp Three Amigos (Dev, QA, PO), nơi chi tiết của các tính năng của người dùng được xác định.

2. Thiết kế

Chúng ta có thể kiểm tra thiết kế / kiến trúc và đặt câu hỏi. Kiểm thử thiết kế của phần mềm có tính chất khai thác. Nó vẫn có thể dựa trên rủi ro, vì chúng ta dựa trên các rủi ro để tập trung điều tra .

Khi chúng ta đặt câu hỏi về thiết kế, nó sẽ giúp khám phá thêm thông tin. Thông tin sẽ giúp chúng ta tái cấu trúc lại thiết kế (hoặc kế hoạch) để làm cho nó tốt hơn. Bạn không muốn xây dựng một tính năng và sau đó phát hiện ra rằng nó có vấn đề hiệu suất nghiêm trọng!

3. Nhánh

Khi chúng ta bắt đầu làm việc với một tính năng mới, chúng ta thường tạo ra một nhánh mới ngoài nhánh hính. Điều này có thể trở nên khá phức tạp và dễ gây ra những sai lầm nghiêm trọng khi nhiều nhà phát triển tạo ra nhiều nhánh và sau đó tất cả cần phải hợp nhất các nhánh của họ với nhánh chính. Xem xét cho bất kỳ việc merge conflicts. Khi một số nhà phát triển làm việc cùng nhau để phát hành một tính năng, có nguy cơ hợp nhất các xung đột(merge conflicts). Chúng ta có thể kiểm thử nhánh để đảm bảo không gặp bất kỳ vấn đề nào hoặc hợp nhất xung đột(merge conflicts).

4. Mã (Code)

Có nhiều cách chúng ta có thể kiểm tra mã. TDD, lập trình cặp, đánh giá code, kiểm tra đơn vị là tất cả các hoạt động với mục đích ngăn ngừa các lỗi đưa vào hệ thống. Kiểm thử ở giai đoạn này mang lại lợi ích cao nhất. Kiểm thử đơn vị được thực hiện nhanh và nếu có bất kỳ lỗi nào, chúng có thể được sửa ngay.

Điều thú vị cần lưu ý là các khuyết tật được tìm thấy trong quá trình phát triển, đang mở ra cho cuộc tranh luận và phần lớn thời gian, những vấn đề không nghiêm trọng sẽ không được chấp nhận và bị lãng quên hoặc được đặt trong backlog để được sửa trong các sprint tương lai. Tuy nhiên, ở giai đoạn coding, ngay cả một kiểm thử đơn vị không thành công, sẽ là nguyên nhân của việc build thất bại, do đó, nó phải được sửa để có thể tiếp tục.

5. Build

Khi một bản build mới được tạo ra, trước hết chúng ta có thể kiểm tra xem nó đã được xây dựng và triển khai thành công hay không với một môi trường kiểm thử hoặc staging. Tự động kiểm tra hồi quy chức năng của các chức năng hiện tại phải là một phần của quá trình build để cho chúng ta sự tự tin rằng mọi thứ vẫn hoạt động tốt.

Kiểm thử tích hợp, kiểm thử người dùng cuối và kiểm thử khám phá các tính năng mới là tất cả các hoạt động thiết yếu và tất cả đều có các mục đích khác nhau.

Kiểm thử liên tục và cải tiến liên tục. Với các hoạt động trên, chúng ta bắt đầu hiểu được sản phẩm tốt hơn, thiết kế các trường hợp kiểm thử tốt hơn và tìm hiểu về các lĩnh vực rủi ro của ứng dụng để chúng ta có thể thông báo về nguy cơ tiềm ẩn trong các phát triển trong tương lai.

6. Phát hành

Việc phát hành sản phẩm nên trơn tru và không có các vấn đề mới, tuy nhiên, chúng ta có thể xác minh việc phát hành bằng cách chạy một số kiểm tra về tính minh mẫn để đảm bảo chúng ta đã phát hành những gì dự định phát hành. Không chỉ vậy, nên giám sát để xem nếu có bất kỳ cảnh báo nào trong các công cụ giám sát và nếu có bất kỳ lỗi mới nào báo cáo kể từ khi phát hành.

Kết luận

Như bạn thấy, để di chuyển nhanh và phát hành liên tục, chúng ta cần kiểm thử cùng với sự phát triển. Chúng ta cần đảm bảo rằng chúng ta đang xây dựng sản phẩm đúng ngay từ khi bắt đầu. Không bao giờ có thể kiểm tra lại một sản phẩm hoàn chỉnh vì các lỗi phát hiện sau này có thể rất tốn kém để sửa chữa. Thay vào đó, chúng ta nên kiểm thử liên tục.

Kiểm thử liên tục cho chúng ta sự tự tin rằng ở mỗi giai đoạn, chúng ta đang tìm kiếm tốt. Kiểm thử ở từng giai đoạn phục vụ cho một mục đích khác nhau, vì vậy có thể có được cái nhìn toàn diện về chất lượng của sản phẩm.