Tổng quan về Agile và Kiểm thử phần mềm trong mô hình Agile

Hiện nay, có rất nhiều các mô hình được áp dụng vào để phát triển dự án .Trong số các mô hình , được sử dụng rộng rãi và phổ biến hơn cả là mô hình Agile. Trong bài viết này, tôi sẽ đi tìm hiểu tổng quan về Agile và Agile Testing.

1.1 Khái niệm và đặc điểm của Agile

Khái niệm

Mô hình phát triển linh hoạt -Agile là một loại mô hình gia tăng, phát triển dựa trên quy trình phát triển lặp.

Đặc điểm

• Mỗi dự án được chia thành nhiều mảng nhỏ để dễ sử dụng và thay đổi khi khách hàng yêu cầu thay đổi
• Từng phần nhỏ của dự án sẽ được test ngay trong quá trình làm dự án
• Yêu cầu gặp mặt trao đổi thường xuyên vì trong Agile tại mỗi thời điểm cả nhóm phải cùng tập trung phát triển một mảng của dự án.

Điểm khác biệt giữa Agile với các mô hình truyền thống là:

• Mô hình truyền thống là mô hình theo kế hoạch.

• Agile không nhất thiết phải tuân theo kế hoạch, nó có thể có những bước đột phá riêng để tạo nên một phần mềm hoàn thiện nhất.

1.2 Tuyên ngôn và quy tắc trong Agile

1.2.1 Bốn tuyên ngôn của Agile

1. Cá nhân và sự tương tác quan trọng hơn là quy trình và công cụ Ý tưởng là đặt trọng tâm vào con người và sự tương hỗ giữa những thành viên trong nhóm. Cơ bản là nếu dự án có những thành viên có năng lực, chịu làm việc cùng nhau thì sẽ mang đến thành công cho dự án. Nếu dự án của bạn có quy trình làm việc tốt, được hỗ trợ những công cụ tốt nhất nhưng những thành viên không “cùng nhìn về một hướng” thì khả năng dự án thất bại là rất lớn. Nói điều này không có nghĩa là phủ nhận tầm quan trọng của quy trình và công cụ nhưng trong Agile nó được đặt sau yếu tố con người.

2. Phần mềm chạy tốt hơn là tài liệu đầy đủ Trong một số quy trình phát triển phần mềm, việc tạo ra và cập nhật các tài liệu về sản phẩm là bắt buộc. Nhóm Dev không thể hoặc không đồng ý tiến hành công việc nếu không có tài liệu đặc tả về yêu cầu, thiết kế hệ thống. Nhóm Test thì yêu cầu tài liệu về sản phẩm để có thể viết trường hợp kiểm thử và kiểm thử được. Nhóm QA đòi tất cả các tài liệu phải được viết trước khi sản phẩm được giao cho khách hàng nếu không thì không đủ điều kiện, chuẩn để giao sản phẩm cho khách hàng. Thực ra đứng với góc độ khách hàng thì khách hàng chỉ quan tâm đến sản phẩm có hoạt động được và tốt hay không. Trong khi việc tạo và cập nhật tài liệu mất nhiều thời gian và được cho là buồn tẻ. Vậy tại sao mình phải tập trung quá nhiều cho việc không cần thiết mà không dành thời gian đó để trao đổi để hiểu thêm về công việc phải làm. Mọi người đừng hiểu lầm là làm Agile là không viết tài liệu. Ý tưởng là chỉ viết những gì mà mọi người cần đọc.

3. Cộng tác với khách hàng hơn là đàm phán hợp đồng “Khách hàng là thượng đế” hay “khách hàng luôn luôn đúng”. Tuy nhiên thì khách hàng có đủ loại khách hàng. Có khách hàng am hiểu về công nghệ, có người không. Có người suy nghĩ nhất quán có người thay đổi xoành xoạch, có người lạnh lùng có người cười nói suốt ngày, v.v.... và cách duy nhất để có thể làm việc tốt là phải cộng tác với khách hàng để hiểu được khách hàng muốn gì và cần gì để có thể tư vấn và điều chỉnh thay vì chỉ dựa vào những điều đã quy định trong hợp đồng.

4. Phản hồi thay đổi hơn là bám sát kế hoạch Hầu hết những dự án, không có dự án nào không có sự thay đổi điều chỉnh khi thực thi. Sự thay đổi đó có thể là thay đổi về yêu cầu, thay đổi công nghệ, thay đổi nhân sự, thay đổi deadline, thay đổi phương thức làm việc, v.v mặc dù kế hoạch đã được định ra rõ ràng từ đầu. Agile không khuyến khích cho sự thay đổi nhưng khuyến khích chúng ta tập thích nghi với thay đổi.

1.2.2 Các nguyên tắc trong Agile

12 nguyên lí phía sau tuyên ngôn Agile:

• Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc chuyển giao sớm và liên tục các phần mềm có giá trị.
• Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển. Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng.
• Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn.
• Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án.
• Xây dựng các dự án 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.
• Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực tiếp.
• Phần mềm chạy tốt là thước đo chính của tiến độ.
• Các quy trình linh hoạt thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát triển, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn.
• Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt.
• Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản.
• Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức.
• Đội sản xuất sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp.

1.3 Ưu điểm và nhược điểm của mô hình Agile

1.3.1 Ưu điểm

• Agile là sự lựa chọn rất tốt cho những dự án nhỏ bởi những dự án nhỏ thường có những yêu cầu không được xác định rõ ràng và có thể thay đổi thường xuyên.

• Với Agile khách hàng có thể được xem trước từng phần dự án trong suốt quá trình phát triển vì Agile phát triển phần mềm theo hướng tăng dần, có thể đưa cho khách hàng xem từng phần đã thực hiện hoàn thành. Từ đó có thể bám sát dự án và luôn sẵn sàng cho bất kỳ thay đổi nào từ phía khách hàng yêu cầu về dự án.

• Agile chia dự án thành những phần nhỏ và giao cho mỗi người, hàng ngày tất cả mọi người phải họp với nhau trong khoảng thời gian ngắn để thảo luận về tiến độ và giải quyết những vấn đề nảy sinh nếu có nhằm đảm bảo đúng quy trình phát triển dự án.

• Tỉ lệ thành công của các dự án sử dụng Agile thường cao hơn các quy trình khác.

1.3.2 Nhược điểm

• Thiếu sự nhấn mạnh về thiết kế và tài liệu cần thiết

• Quy mô nhân lực thường giới hạn từ 7 đến 10 người, sẽ có trở ngại lớn nếu nguồn nhân lực yêu cầu vượt quá con số này ví dụ trong các cuộc họp trao đổi.

• Số lượng yêu cầu có thể nhiều và khó quản lý nếu như nó bao gồm nhiều khía cạnh khác nhau về dự án.

• Số lượng nhân lực càng tăng, chất lượng càng khó kiểm soát hơn. Việc kiểm tra mã thường xuyên và thiết lập các chỉ tiêu đánh giá năng lực của lập trình viên cho phép giảm thiểu nhược điểm này.

Những kiến thức cơ bản về kiểm thử Agile sẽ được trình bày trong 4 vấn đề sau:

• Test Plan trong Agile.
• Agile Testing Strategies.
• Agile Testing Quadrant.
• Những thách thức đối với QA trong Agile test.

2.1 Test Plan trong Agile

Không như trong mô hình WaterFall, test plan trong mô hình Agile được viết và update liên tục trong mỗi vòng lặp bao gồm:

• Phạm vi test
• Những chức năng mới sẽ cần test
• Test level và test type
• Load test và Performance test
• Phân tích cơ sở hạ tầng
• Các rủi ro và giải pháp
• Nguồn lực
• Sản phẩm bàn giao và mốc thời gian

2.2 Agile Testing Strategies

Quy trình kiểm thử trong mô hình Agile gồm 4 trạng thái sau:

(a) Iteration 0:

Trong giai đoạn đầu tiên của iteration 0, bạn sẽ thực hiện những task khởi tạo đã được thiết lập bao gồm xác định những người tham gia kiểm thử, cài đặt tool test, lên kế hoạch quản lý resource. Cụ thể bao gồm:

• Thành lập các business case cho project
• Thiết lập các boundary condition và phạm vi project
• Vạch ra những yêu cầu và use case quan trọng cần cân nhắc để triển khai
• Phác thảo một vài kiên trúc có thể áp dụng cho project
• Xác định các rủi ro
• Estimate chi phí và chuẩn bị một project phác thảo

(b) Construction Iterations

Pha thứ 2 trong quá trình kiểm thử đó là Construction Iterations, phần lớn các công việc kiểm thử sẽ được thực hiện trong giải đoạn này. Pha này được xem như là một tập các vòng lặp và tăng trưởng, qua đó giải pháp dần được xây dựng. Để làm được điều đó, trong mỗi một vòng lặp team sẽ thực thi một cách hiện thực Agile như XP, Scrum, Agile modeling, hay agile data. Trong Construction Iteration, team sẽ thực hiện các requirement được ưu tiên. Trong mỗi vòng lặp requirement thiết yếu nhất sẽ được chọn từ backlog và thực hiện. Construction Iteration được phân lớp thành 2 phần: Confirmatory tesing và Investigative tesing. Confirmatory tesing tập chung vào xác minh xem hệ thống có đáp ứng được mục đích của stakeholder giống như mô tả mà team nhận và thực hiện hay không? Investigative testing phát hiện ra các vấn đề mà team đã bỏ sót hoặc bỏ qua, ngoài ra Investigative testing còn kèn thêm integration testing, load/stress tesing và security testing.

(c) Release (End Game) Mục tiêu của “Release, End Game” là để deploy hệ thống một cách thành công lên production. Hoạt động trong pha này bao gồm training end user, support mọi người sử dụng sản phẩm. Ngoài ra, nó còn bao gồm maketing sản phẩm, back-up, restoration, hoàn thiện hệ thống và tài liệu. Giai đoạn kiểm thử cuối cùng bao gồm system testing và acceptance testing. Để giai đoạn này có thể kết thúc tốt đẹp, bạn cần đảm bảo đã kiểm thử một cách kĩ lưỡng sản phẩm khi nó còn ở trong các vòng lặp. (d) Production Sau giai đoạn release, sản phẩm sẽ chuyển sang giai đoạn production.

2.3 Agile Testing Quadrant

Agile Testing Quadrant tách tiến trình kiểm thử thành 4 góc giúp ta hiểu về cách thực hiện kiểm thử trong Agile

(a) Agile Quadrant I

Chất lượng cuả mã nguồn là mục tiêu chính cần quan tâm trong Quadrant này. Nó bao gồm các ca kiểm thử (theo hướng công nghệ) bao gồm:

• Unit tests
• Component Test

(b) Agile Quadrant II

Các ca kiểm thử phần này tập chung vào bussiness logic dựa trên requirement. Các loại kiểm thử trong Quadrant này bao gồm:

• Scenario và workflows testing
• User experience testing
• Pair testing

(c) Agile Quadrant III

Quadrant này cung cấp các phản hồi cho Quadrant I và Quadrant II. Các ca kiểm thử ở Quadrant này sẽ được sử dụng để là cơ sở thực hiện Automation test. Trong Quadrant này, việc kiểm thử của vòng lặp được review và thực hiện để đảm bảo tính tin cậy của sản phẩm. Các loại kiểm thử được thực hiện trong Quadrant này gồm có:

• Usability Testing
• Exploratory Testing
• Pair testing with customers
• Collaborative testing
• User acceptance testing

(d) Agile quadrant IV Quadrant này tập chung vào kiểm tra các yêu cầu phi chức năng của như performance, security, stability… Các loại kiểm thử trong Quadrant này bao gồm:

• Non-fucntion test như stress test, performance test
• Security test
• Infrastructure test
• Data migration test
• Scalability test
• Load test

2.4 Những thách thức đối với QA trong Agile Test

• Trong Agile, QA có cơ hội phát hiện lỗi sớm, tuy nhiên tài liệu lại ít được coi trọng hơn do đó phải mất nhiều effort để study Spec
• Các feature mới được đưa ra nhanh chóng, QA team không có đủ thời gian để xác định xem liệu tính năng này có đang tuân theo requirement và liệu rằng nó có giải quyết được các bussiness suit hay không
• Chu kì thực hiện execute test bị dồn lại rất nhiều
• Có rất ít thời gian để chuẩn bị test plan
• Chỉ có một khoảng thời gian tối thiểu để thực hiện test hồi qui
• Vai trò của QA cũng có sự thay đổi, từ một người quản lý chất lượng đơn thuần dưới những yêu cầu đã có sẵn sang một partner, một người tham gia vào phân tích, đóng góp ý kiến về chất lượng sản phẩm cùng khách hàng và đội phát triển.
• Luôn phải đối mặt với thay đổi và cập nhật liên tục

2.5 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 phải là một pha của dự án Kiể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à công cụ 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.
4. 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. Rút ngắn vòng lặp phản hồi 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õ 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ò

1. Giản lược tài liệu 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