Phương thức kiểm thử phần mềm trong mô hình Agile

1. Agile là gì?

Agile là một triết lí (philosophy) cho việc phát triển phần mềm. Nói cách khác, đó là một cách “tư duy” về các dự án phần mềm. Các triết lí của Agile được cụ thể hóa bởi một số phương pháp phát triển phần mềm (method), chẳng hạn như Extreme Programming (XP) hay Scrum, gọi tắt là các phương pháp Agile. Mỗi phương pháp Agile bao gồm một tập hợp các quy tắc (pratice), chẳng hạn quy tắc về sử dụng công cụ quản lí mã nguồn, quy tắc về các chuẩn lập trình hay quy tắc chuyển giao sản phẩm hàng tuần cho khách hàng. Triết lí Agile được đưa ra trong một bản tuyên ngôn (manifesto) gồm 4 tiêu chí vàđược làm rõ hơn bởi 12 quy tắc.

a. 4 tiêu chí của Agile

• Cá nhân và các tương tác quan trọng hơn các quy trình và công cụ.
• Tập trung làm cho phần mềm chạy được hơn là viết các tài liệu mô tả
• Cộng tác với khách hàng hơn là chỉ dựa trên hợp đồng
• Phản ứng với các thay đổi hơn là chỉ tuân theo một kế hoạch định sẵn

b. 12 quy tắc trong Agile

• Thỏa mãn yêu cầu của khách hàng thông qua việc giao hàng sớm và liên tục
• Chào đón việc thay đổi yêu cầu, thậm chí là những thay đổi yêu cầu muộn
• Giao phần mềm chạy được cho khách hàng một cách thường xuyên (giao hàng tuần hơn là hàng tháng)
• Nhà kinh doanh và kỹ sư lập trình phải làm việc cùng nhau hàng ngày trong suốt dựán
• Các dựán được xây dựng xung quanh những cá nhân cóđộng lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc
• Trao đổi trực tiếp mặt đối mặt là phương pháp hiệu quả nhất để truyền đạt thông tin
• Phần mềm chạy được là thước đo chính của tiến độ
• Phát triển bền vững và duy trì được nhịp độ phát triển liên tục
• Liên tục quan tâm đến kĩ thuật và thiết kế để cải tiến sự linh hoạt
• Sự đơn giản là cần thiết – nghệ thuật tối đa hóa lượng công việc chưa hoàn thành
• Nhóm tự tổ chức
• Thích ứng thường xuyên với sự thay đổi

2. Quy trình kiểm thử phần mềm trong mô hình Agile

Kiểm thử (testing) trong dự án Agile yêu cầu một sự dịch chuyển mô thức (paradigm shift) cho vai trò kiểm thử truyền thống. Nó đòi hỏi một sự thay đổi trong thái độ của kiểm thử viên (tester) từ một phương pháp tiếp cận theo định hướng ca kíp thành một vai trò đượ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 nhận được những điều đúng đắn ngay từ đầu, làm giảm sự cần thiết phải có nhiều kiểm thử viên đảm bảo chất lượng (QA Tester) ở cuối quy trình để đạt được kết quả.

Vai trò kiểm thử viên QA trong Agile không bị giới hạn một tập hợp các quy trình được xác định trước, cũng như phương pháp luận sẽ chỉ ra vai trò dựa trên tình huống cụ thể.

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

• Tiền-Phân-đoạn (Pre-iteration): Đây là giai đoạn 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) được viết ra cho mỗi một story (user story). Và QA là những người 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.

• Xác minh Story (Xác minh Yêu cầu): Kiểm thử Agile thiên về việc đưa ra phản hồi sớm, không chỉ bằng cách kiểm tra các yêu cầu, mà còn là phải làm việc đó từ sớm. Các QA tester cần phải xem xét các yêu cầu / story từ sớm để 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

Để hiểu rõ hơn về giai đoạn này, chúng ta cùng tìm hiểu những phần sau:

• 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 . Nó thường được viết theo mẫu sau:

Với <vai trò một người dùng>, tôi muốn <một điều gì đó> vì <lý do nào đó>

Ví dụ: Với vai trò là người dùng website, tôi muốn có một chức năng tìm kiếm nâng cao để có thể tìm kiếm nhanh chóng và dễ dàng những quyển sách tôi cầ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? Là chìa khóa đưa ra các tiêu chí đánh giá có thể xác định
• 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...

Ví dụ: Với story như trên ta có các tiêu chí chấp nhận như sau:

• Tôi có thể giới hạn tìm kiếm theo định dạng / loại.
• Tôi có thể tìm kiếm theo phạm vi ngày.
• Tôi có thể giới hạn tìm kiếm thông tin nhà xuất bản như tiêu đề, tác giả, chủ đề, địa điểm, nhà xuất bản và số lượng xuất bản
• Tôi có thể giới hạn tìm kiếm bởi một tiêu chí cụ thể như danh mục, bộ sưu tập.
• Tôi có thể lọc (filter)

Để đạ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 của story phải được xem xét chi tiết để có thể kiểm thửđược story đó. 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 Việc có được các chi tiết này sớm sẽ giúp câu chuyện được ưu tiên đúng đắn hơn trong backlog, và cho phép việc thực hiện story đó suôn sẻ hơn trong phân đoạn (iteration).

QA tester cũng tham gia cuộc họp lập kế hoạch cho phân đoạn để cung cấp quan điểm kiểm thửđể nhóm có thểđưa ra được ước lượng phát triển. Tham gia trong việc lập kế hoạch phân đoạn đóng vai trò quan trọng, khi một số các yêu cầu tiềm ẩn thường được phát hiện bởi các QA Tester.

b. Các hoạt động Đảm bảo chất lượng Trong phân đoạn

Môt khi QA tester đã thấy thoải mái với các tiêu chí chấp nhận của một story nào đó, họ có thể giúp nhóm định nghĩa các kiểm thử chấp nhận (acceptance tests) cho Story đó. Kiểm thử chấp nhận là các yêu cầu về phương diện kiểm thử cần được thực hiện để hiểu các yêu cầu phần mềm. Các kiểm thử chấp nhận này được sinh ra tự động và dùng để hướng dẫn quá trình phát triển.

Các kiểm thử chấp nhận không nên bao gồm tất tần tật các tình huống (case scenarios) do điều này có thể tạo ra những sự ngưng trệ không cần thiết và có thể tạo ra quá nhiều bộ kiểm thử tự động (automated test) tương tự nhau.

Kiểm thử chấp nhận trong các dự án Agile là khác biệt so với các dự án truyền thống. Không giống như các dự án truyền thống, nơi kiểm thử chấp nhận xảy ra ở phần cuối của vòng đời phần mềm, trong dự án Agile kiểm thử chấp nhận được thực hiện trước khi phần mềm được chuyển giao. Kiểm thử chấp nhận cũng có xu hướng được tự động hóa để họ có thể chạy như là kiểm thử hồi quy (regression test).

Kiểm thử tự động rất quan trọng đối với mọi dựán Agile. Các bản build thường xuyên yêu cầu các chu kỳ phản hồi ngắn, do đó kiểm thử hồi quy phải nhanh chóng và chính xác.

Ví dụ: Trở lại với ví dụ ở phần mở đầu, khi khách hàng yêu cầu thực hiện tìm kiếm sách theo nhiều tiêu chí, trong trường hợp các tiêu chí tìm kiếm được chia nhỏ ra để thực hiện như sau:

• Sprint 1: Phát triển chức năng tìm kiếm theo tên sách và thể loại
• Sprint 2: Phát triển chức năng tìm kiếm theo tác giả và nhà xuất bản
• Sprint 3: Phát triển chức năng tìm kiếm theo ngày phát hành, tình trạng sách

Như vậy, khi kiểm thử chấp nhận chức năng tìm kiếm ở sprint 2, chúng ta sẽ phải kết hợp việc kiểm thử lại chức năng tìm kiếm theo các tiêu chíở Sprint 1, nếu không có các công cụ kiểm thử tựđộng hỗ trợ cho việc kiểm thử lại các chức năng ở sprint 1 thì người thực hiện kiểm thử sẽ mất thêm thời gian cho việc kiểm thử lại sprint 1

Trong các dựán Agile, kiểm thử tựđộng được thực hiện bởi tất cả các cấp độ - lập trình viên, kiểm thử viên bảo đảm chất lượng(QA tester) và các nhà phân tích nghiệp vụ (BA). Sự tham gia của tất cả mọi người làm gia tăng tính xác đáng của các phần kiểm thử và thường giúp xác định đúng các phần kiểm thử. Tuy nhiên, điều này không có nghĩa là tất cả mọi người phải đều phải viết mã kiểm thử.

3. Sử dụng tự động hóa có mục đích

Tự động hóa đồng nghĩa với việc cung cấp thông tin phản hồi sớm về những mã nguồn được tạo ra, và điều quan trọng là phải xác định những gì cần tự động hoá và những gì thì không. Tất cả các kiểm thử tự động đều mất chi phí. Chi phí của tự động hóa nên được so sánh với chi phí khi không thực hiện việc đó. Một chu kỳ phản hồi dài hơn đồng nghĩa với việc phải có nhiều người đóng góp nhiều thời gian hơn mới có được phản hồi tức thì.

Một hoạt động bảo đảm chất lượng điển hình trong phân đoạn là việc liên tục đo lường chất lượng của phần mềm. QA tester tham gia vào việc bàn giao các story cho các nhà phát triển. Điều này giúp họ hiểu được những yêu cầu kiểm thử của story để họ có thể triển khai được kĩ thuật Phát triển Định-hướng-Kiểm-thử (Test-Driven Development - TDD). Ngoài ra, việc bàn giao các kiểm thử chấp nhận và giúp cho các lập trình viên hiểu các khía cạnh khả kiểm (testability) của story để tránh được các lỗi (defect) phổ biến. Những hoạt động này đòi hỏi một mức độ cao của giao tiếp giữa các lập trình viên và các chuyên viên phân tích nghiệp vụđể làm rõ yêu cầu vàđảm bảo sản phẩm được xây dựng đúng đắn ngay từ đầu.

QA tester có thể giúp giải quyết các vấn đề trước hết bằng cách tích cực tham gia vào quy trình tổng thể. Ta thậm chí có thể kết hợp với các nhà phát triển làm việc trên một story hoặc các kiểm thử cho story để thể hiểu rõ hơn về các yêu cầu. Điều bắt buộc là một story khi được chuyển giao, nó phải được kiểm thử đúng cách, trong một môi trường thích hợp. Một khi các QA Tester hài lòng với những story, họ sẽ đưa nó vào các tiến trình kiểm thử tiếp theo.

Một điều quan trọng khác là phải suy nghĩ vượt ra ngoài các yêu cầu bằng văn bản và thử nghiệm với các kiểm thử thăm dò (exploratory testing) để thực hiện kịch bản ‘ngoài lề’ và thực hiện các kiểm thử tiêu cực đểđảm bảo chắc chắn phần mềm được viết ra là chất lượng. Kiểm thử thăm dò không phải là thực thi tất cả các kịch bản kiểm thửđược xác định trước, nó là nghệ thuật thăm dò phần mềm ngoài các trường hợp kiểm thử (test case) vàđồng thời giữ tập trung xung quanh các yêu cầu cụ thể.

Nguồn tham khảo: http://www.logigear.com/magazine/agile/a-tester’s-perspective-on-agile-projects/ http://agilemanifesto.org/ http://www.mountaingoatsoftware.com/agile