Mô hình Agile trong phát triển và kiểm thử phầm mềm

I. Khái niệm

Phương thức phát triển phần mềm Agile là một tập hợp các phương thức phát triển lặp và tăng dần trong đó các yêu cầu và giải pháp được phát triển thông qua sự liên kết cộng tác giữa các nhóm tự quản và liên chức năng. Agile là cách thức làm phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt càng sớm càng tốt và được xem như là sự cải tiến so với những mô hình cũ như mô hình “Thác nước (waterfall)” hay “CMMI”.

Nguyên tắc áp dụng trong phương pháp Agile

1. Kiểm thử giúp dự án nhanh chóng được bàn giao

Ở dự án truyền thống, kiểm thử thường được xem là bước cuối kiểm tra chất lượng sản phẩm. Và việc ngăn chặn lỗi của phầm mềm bị coi như trách nhiệm của QA/tester. Bug được tìm thấy dù quan trọng hay không thì cũng sẽ làm chậm quá trình bàn giao sản phẩm.

Trong dự án Agile, chúng ta xây dựng một sản phẩm tốt ngay từ ban đầu, sử dụng kiểm thử để phản hồi trên ngay khi phát triển để làm thế nào cho sản phẩm tương đồng với yêu cầu.

Nghe có vẻ là thay đổi nhỏ, nhưng thực chất thì việc này có ý nghĩa lớn. Mối liên hệ giữa tester và dev cần là sự cộng tác, tương hỗ lẫn nhau.

2. Kiểm thử không chỉ là một giai đoạn của dự ánKiểm thử không phải là một giai đoạn trong quá trình phát triển Agile mà cần được tham gia sâu vào quy trình phát triển từ sớm.

Cách tiếp cận Agile tập trung vào việc xác nhận những điều đúng đắn ngay từđầu, giảm sự cần thiết phải có nhiều kiểm thử viên (QA Tester) ở cuối quy trình để đạt được kết quả. Đảm bảo tiến độ dự án được liên tục.

3. Cá nhân và sự tương hỗ quan trọng hơn quy trình

Với dự án truyền thống, tester làm việc độc lập và chịu trách nhiệm với toàn bộ hoạt động test.

Đối với Agile, các hoạt động test được thực hiện bởi toàn bộ dự án. Để thực hiện được hết test thì cần thực hiện lặp lại qua các sprint.

Tuy nhiên tới khi dự án lớn hoặc phức tạp lên thì sẽ có lúc không thể test hết các testcase đề ra và không thể thực hiện được mục tiêu ban đầu đề ra. Có nghĩa team không thể thực hiện nhanh như họ nghĩ. Vì nếu test chưa xong thì feature cũng không thể xong được, vì vậy để đẩy nhanh tốc độ thì cả team phải làm cùng nhau và đẩy nhanh phần chậm nhất, test cùng nhau.

5.Rút ngắn vòng lặp phản hồi

Thời gian từ khi viết code và thực hiện code tới khi biết được code vận hành như thế nào được gọi là feedback loop (vòng phản hồi).

Nếu một phần mềm không được thực hiện test cho tới khi kết thúc và được bàn giao thì vòng phản hồi này bị kéo dài tới cả tháng, như thế là quá dài.

Agile tạo nên một vòng phản hồi ngắn hơn bởi với dự án Agile, phần mềm được sẵn sàng để test ngay từ khi bắt đầu. Đặc thù của Agile là đội dự án có rất nhiều cấp độ kiểm thử để có thể tấn công được nhiều loại dữ liệu khác nhau.

Agile sử dụng nhiều test tự động vì nó trả lại phản hồi nhanh. Test hồi quy thủ công mất nhiều thời gian thực hiện hơn, cần có nhân lực và có thể không thực hiện ngay lập tức được. Kiểm tra thủ công vẫn còn quan trọng.

Tuy nhiên, đội Agile thường thấy rằng những thông tin phản hồi nhanh chóng tạo nên bởi hồi quy tự động là chìa khóa để phát hiện các vấn đề một cách nhanh chóng, do đó làm giảm rủi ro và giảm việc phải làm lại.

5. Thỏa mãn mong muốn của khách hàng

Cho dù là test tự động hay test thủ công thì kịch bản test cần phải khớp với yêu cầu và mong đợi của khách hàng. Trước khi tốn thời gian tìm bug nên đặt câu hỏi để làm sáng tỏ mong muốn của khách hàng đối với chức năng sản phẩm.

6. Giữ code rõ ràng

Nguyên tắc này là một ví dụ về một nguyên tắc mà đội Agile phải có. Sẽ mất nhiều công sức và thời gian để sửa lỗi khi chúng được tìm thấy.

Nếu đó là một lỗi chính đáng nó sẽ được sửa trong vòng lặp và đôi khi kết quả sau khi sửa sẽ không được tốt bằng làm từ đầu vì nó ảnh hưởng tới những phần khác.

7. Giản lược tài liệu kiểm thử

Thay vì viết dài dòng thì Agile test

• Tái sử dụng checklist
• Tập trung vào bản chất của các thử nghiệm chứ không phải là các chi tiết ngẫu nhiên
• Sử dụng các tài liệu hướng dẫn đơn giản
• Nắm bắt những ý tưởng thử nghiệm trong điều lệ kiểm nghiệm thăm dò

8. Chưa thể hoàn thành khi chưa qua giai đoạn kiểm thử

Trong dự án truyền thống có sự phân tách rõ ràng giữa dev và test, đó là đặc trưng cho việc dev nói “xong” với phần họ phát triển nhưng nó vẫn chưa được test. Do đó thực tế là phần phát triển ấy vẫn chưa xong cho tới khi test xong và bug được fix.

Đó là lý do vì sao mà phần mềm chỉ được để “90% done”. Agile không tính là “done” mà nó cần được sẵn sàng cho sự chấp nhận của Product Owner và khách hàng cho tới khi nó được thực thi và test.

9. Test-Last và Test-Driven

Trong môi trường phát triển truyền thống, test được lấy từ tài liệu yêu cầu. Yêu cầu và design đầu tiên, sau đó đến kiểm thử. Quá trình kiểm thử diễn ra ở cuối dự án. Tuy nhiên kiểm thử cung cấp một ví dụ về ý nghĩa của việc phát triển thỏa mãn yêu cầu. Test được định hướng từ các thành phần của project, trong đó có tài liệu dự án. Việc thực hiện test được tiến hành vào thời điểm cuối cùng của project. Đây gọi là cách tiếp cận “testlast” – Test sau cùng.

II. Các giai đoạn kiểm thử phần mềm tương ứng với các giai đoạn phát triển phần mềm trong mô hình Agile

1. Tiền-Phân-đoạn (Pre-iteration):

Yêu cầu được phân tích chi tiết bởi BA (Business Analyst – chuyên viên phân tích nghiệp vụ) và các tiêu chí chấp nhận (acceptance criteria). Và QA sử dụng các yêu cầu này ngay từ đầu, ta cần phải xác minh (verify) những yêu cầu đó từ sớm và thường xuyên.

2. Xác minh Yêu cầu:

Kiểm thử Agile thiên về việc đưa ra phản hồi sớm, và phải bắt đầu bằng việc kiểm tra các yêu cầu từ sớm bởi QA hoặc tester để làm sáng rõ ý nghĩa và tính khả-kiểm (testability). Việc này sẽ đảm bảo các yêu cầu luôn rõ ràng và có thể kiểm thử được.

• Yêu cầu cần đủ nhỏ để có ý nghĩa trong bối cảnh xác định
• Tiêu chí chấp nhận (acceptance criteria những story thường được sử dụng cho các tiêu chí chấp nhận) không nên bị trùng lặp, chồng chéo từ những story khác nhau

Các giai đoạn: 

• • user story: là một tóm tắt đơn giản, ngắn gọn về chức năng mà khách hàng mong muốn.
  • Tiêu chí chấp nhận (Acceptance Criteria): là những tiêu chí dùng để đánh giá sản phẩm, chức năng đã thực hiện đúng yêu cầu hay chưa? Có thể coi đó là các tiêu chí xác nhận hoàn thành story.Các tiêu chí đặt ra phải đáp ứng các đặc tính sau:
    • Tính khả dụng (usability): là tiêu chí trả lời cho câu hỏi: Có dễ sử dụng hay không?
    • Tính chức năng (Functionality)
    • Xử lý lỗi (error handing) : Liệt kê ra những lỗi có thể gặp phải trong quá trình sử dụng chương trình và phương thức để xử lý. Ví dụ người dùng có thể thực hiện sai thứ tự các bước và khi đó chương trình sẽ xử lý như thế nào?
    • Hiệu suất( Performance)
    • Stress tests: Là tiêu chí trả lời cho câu hỏi: Hệ thống sẽ hoạt động như thế nào dưới những áp lực như có nhiều người truy cập tại cùng 1 thời điểm, có quá nhiều request được gửi đến hệ thống…

    Để đạt được mục tiêu của giai đoạn này cần có sự giao tiếp chặt chẽ giữa các bên Đội Phát triển / Nhà phân tích nghiệp vụ/ Đảm bảo chất lượng.

    • Khả kiểm (Testable): Các khía cạnh có thể kiểm thử được phải được xem xét chi tiết. Những yếu tố này thường là:
      • Tìm kiếm các yêu cầu ẩn
      • Môi trường
      • Dữ liệu kiểm thử (test data)
      • Sự phụ thuộc vào các yêu cầu khác

3. Các hoạt động Đảm bảo chất lượng: