Có nhiều mô hình phát triển phần mềm khác nhau và mỗi mô hình đều có yêu cầu và quy trình kiểm thử riêng. Bài viết hôm nay mình sẽ trình bày về kế hoạch kiểm thử cho một số mô hình phát triển phần mềm phổ biến, bao gồm: Mô hình tuần tự – Sequential Models, Mô hình lặp lại -Iterative Models, Mô hình Agile – Agile Models, Mô hình xoắn ốc – Spiral Models.
Nào hãy bắt đầu tìm hiểu cùng mình nhé!
Kế Hoạch Kiểm Thử Trong Mô Hình Tuần Tự – Sequentail Models
Các mô hình tuần tự – Sequential models được gọi là tuần tự vì toàn bộ hệ thống được xây dựng cùng một lúc, trong một chuỗi các hoạt động liên tiếp xác định, sau đó thực hiện, sau đó kiểm tra. Tất cả các sản phẩm công việc và các hoạt động liên quan đến từng giai đoạn được hoàn thành trước khi giai đoạn tiếp theo bắt đầu. Hai mô hình phổ biến nhất là mô hình thác nước – Waterfall Model và mô hình chữ V – V models.
Bạn cũng có thể đã gặp phải mô hình W. Mô hình W mô tả các hoạt động phát triển kiểm thử cho từng cấp độ kiểm thử – được hiển thị trong mô hình chữ V dưới dạng các thanh chéo trên chữ V. Thay vào đó là một đường song song bên cạnh các hoạt động yêu cầu, thiết kế và triển khai, sau đó hiển thị rõ ràng việc sửa lỗi liên quan đến các cấp độ kiểm tra dưới dạng một đường song song bên cạnh các hoạt động kiểm tra. Một số người thấy nó rõ ràng hơn mô hình chữ V, nhưng một số khác thực sự thấy hình này khó hiểu hơn vì nó phức tạp hơn.
Kế hoạch kiểm thử trong mô hình tuần tự được xây dựng gồm các bước sau:
- Xác định yêu cầu kiểm thử từ tài liệu yêu cầu.
- Lập kế hoạch kiểm thử dựa trên các giai đoạn trong mô hình thác nước.
- Thiết kế kịch bản kiểm thử dựa trên yêu cầu và thiết kế.
- Thực hiện kiểm thử trong từng giai đoạn: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận.
- Đánh giá kết quả kiểm thử và tạo báo cáo.
Thách Thức Trong Quản Lý Kiểm Thử Của Mô Hình Tuần Tự
Việc sử dụng các mô hình phát triển tuần tự tạo ra một số vấn đề nhất định để kiểm thử mà người quản lý kiểm thử phải quản lý.
- Độ trễ thông tin phản hồi: Trong mô hình phát triển tuần tự, các giai đoạn kiểm thử tiếp theo chỉ bắt đầu sau khi giai đoạn trước hoàn thành. Điều này có thể gây ra độ trễ trong việc nhận thông tin phản hồi từ giai đoạn kiểm thử trước đó và từ đó kéo dài thời gian phát hiện và sửa lỗi.
- Khả năng thích ứng yếu: Mô hình kiểm thử tuần tự có tính tĩnh và ít linh hoạt. Nếu có sự thay đổi trong yêu cầu hoặc thiết kế, việc thích ứng và thay đổi các kịch bản kiểm thử trở nên khó khăn và tốn thời gian.
- Rủi ro về việc phát hiện lỗi muộn: Trong mô hình tuần tự, các giai đoạn kiểm thử bắt đầu sau khi giai đoạn phát triển tương ứng hoàn thành. Điều này có thể dẫn đến việc phát hiện lỗi muộn trong quá trình kiểm thử, khi lỗi đã lan rộng vào giai đoạn phát triển tiếp theo hoặc vào giai đoạn sản phẩm đã được triển khai.
- Hiệu suất không tối ưu: Trong mô hình tuần tự, các giai đoạn kiểm thử thường được thực hiện tuần tự, không chạy song song. Điều này có thể dẫn đến sự lãng phí về thời gian và tài nguyên, đồng thời làm giảm hiệu suất kiểm thử.
- Sự thiếu nhất quán giữa các giai đoạn: Mô hình tuần tự có thể dẫn đến sự thiếu nhất quán giữa các giai đoạn kiểm thử và phát triển. Có thể xảy ra trường hợp các yêu cầu thay đổi sau khi giai đoạn kiểm thử đã bắt đầu hoặc các thay đổi trong quá trình phát triển không được phản ánh đầy đủ trong giai đoạn kiểm thử.
Để vượt qua những khó khăn này, các tổ chức có thể xem xét áp dụng các phương pháp kiểm thử linh hoạt và kết hợp với các hình thức kiểm thử khác như kiểm thử tự động, kiểm thử liên tục và kiểm thử song song để nâng cao hiệu quả và độ chính xác của quá trình kiểm thử.
Kế Hoạch Kiểm Thử Trong Mô Hình Lặp Lại – Iterative Models
Các mô hình lặp lại – Iterative Models là những mô hình mà hệ thống được xây dựng và kiểm thử lặp đi lặp lại theo từng phần. Việc nhóm các chức năng và khả năng thành các khối có thể được thực hiện dựa trên rủi ro, trong đó các chức năng và khả năng có nhiều khả năng bị lỗi nhất được xây dựng trong đoạn đầu tiên, sau đó là khối tiếp theo có nhiều khả năng bị lỗi nhất, v.v. Việc nhóm thành các phần có thể được thực hiện dựa trên mức độ ưu tiên của khách hàng, trong đó các chức năng và khả năng mà khách hàng mong muốn nhất sẽ được xây dựng trước, phần ít mong muốn nhất sẽ được xây dựng sau cùng và các chức năng và chức năng khác ở một số phần ở giữa. Việc nhóm thành các khối cũng có thể bị ảnh hưởng bởi các yêu cầu quy định, yêu cầu thiết kế và các ràng buộc khác.
Có vô số ví dụ về các mô hình này, bao gồm cả Mô hình tiến hóa – Evolutionary model và Mô hình gia tăng – Incremental model. Có sự khác biệt rất lớn về kích thước của các khối, thời lượng của các lần lặp lại và mức độ hình thức. Yếu tố chung là các hệ thống làm việc được tích hợp đầy đủ và khả năng được tạo ra sớm hơn trong vòng đời so với khi chúng được tạo ra trong một dự án tuần tự.
Kế hoạch kiểm thử trong mô hình lặp lại được xây dựng gồm các bước sau:
- Xác định yêu cầu kiểm thử từ các vòng lặp phát triển.
- Thiết kế kịch bản kiểm thử dựa trên các yêu cầu và thiết kế hiện tại.
- Thực hiện kiểm thử trong từng vòng lặp.
- Kiểm tra và đánh giá kết quả kiểm thử trước khi tiến hành vòng lặp tiếp theo.
Thách Thức Trong Quản Lý Kiểm Thử Của Mô Hình Lặp Lại
Sự sẵn có của các hệ thống có thể kiểm tra sớm hơn trong vòng đời dường như là một lợi ích cho người quản lý kiểm thử. Tuy nhiên, các mô hình vòng đời lặp lại tạo ra một số vấn đề kiểm thử nhất định như:
- Quản lý yêu cầu thay đổi: Trên thực tế, yêu cầu có thể thay đổi trong suốt quá trình phát triển và kiểm thử. Việc quản lý và thay đổi các yêu cầu trong mô hình kiểm thử lặp lại có thể gây ra sự phức tạp và đòi hỏi sự linh hoạt trong việc điều chỉnh và cập nhật kịch bản kiểm thử.
- Đồng bộ giữa phát triển và kiểm thử: Mô hình kiểm thử lặp lại yêu cầu sự tương tác và đồng bộ giữa quá trình phát triển và quá trình kiểm thử. Điều này đòi hỏi sự cộng tác tốt giữa các thành viên trong nhóm phát triển và nhóm kiểm thử để đảm bảo rằng các vòng lặp kiểm thử được thực hiện đúng thời gian và đáp ứng yêu cầu thời gian của dự án.
- Hiệu suất kiểm thử không tối ưu: Mô hình kiểm thử lặp lại có thể đòi hỏi thời gian và nguồn lực lớn. Các vòng lặp kiểm thử đòi hỏi việc chuẩn bị lại môi trường kiểm thử và thực hiện các kịch bản kiểm thử. Điều này có thể làm giảm hiệu suất kiểm thử và tạo ra sự trùng lắp công việc.
- Rủi ro về việc phát hiện lỗi muộn: Mô hình kiểm thử lặp lại có thể gây ra rủi ro về việc phát hiện lỗi muộn. Nếu lỗi không được phát hiện trong giai đoạn kiểm thử hiện tại và lan truyền vào giai đoạn phát triển tiếp theo, việc sửa chữa lỗi và kiểm thử lại có thể trở nên tốn kém và ảnh hưởng đến lịch trình dự án.
- Đánh giá và kiểm soát tiến độ: Mô hình kiểm thử lặp lại đòi hỏi việc đánh giá và kiểm soát tiến độ của các vòng lặp kiểm thử. Điều này yêu cầu quản lý chặt chẽ và theo dõi tiến độ của mỗi vòng lặp để đảm bảo rằng quá trình kiểm thử được hoàn thành đúng thời gian và không gây trễ lịch trình dự án.
Để vượt qua các khó khăn này, các tổ chức có thể áp dụng các phương pháp quản lý dự án linh hoạt và kỹ thuật kiểm thử tự động để tối ưu hóa quá trình kiểm thử và giảm thiểu các vấn đề có thể xảy ra trong mô hình phát triển lặp lại.
Kế Hoạch Kiểm Thử Trong Mô Hình Agile
Mô hình Agile – Agile Models là một dạng vòng đời lặp đi lặp lại trong đó các lần lặp lại rất ngắn, thường chỉ từ hai đến bốn tuần. Ngoài ra, toàn bộ nhóm – bao gồm cả người kiểm thử – sẽ tham gia vào nỗ lực phát triển trong mỗi lần lặp lại. Các thay đổi được cho phép tại bất kỳ thời điểm nào trong dự án và các điều chỉnh sẽ được thực hiện trong phạm vi (nhưng không phải theo lịch trình) dựa trên các thay đổi.
Kế hoạch kiểm thử trong mô hình lặp lại được xây dựng gồm các bước sau:
- Xác định yêu cầu kiểm thử từ các cuộc họp lập kế hoạch sprints.
- Phân tích yêu cầu và thiết kế kịch bản kiểm thử.
- Thực hiện kiểm thử song song với quá trình phát triển.
- Sử dụng các kỹ thuật kiểm thử như kiểm thử tự động, kiểm thử liên tục.
- Đánh giá kết quả kiểm thử và cung cấp phản hồi liên tục
Một ví dụ về các mô hình Agile là quy trình Scrum, về cơ bản là một tập hợp các thực tiễn để quản lý các sprint. Scrum tổ chức các cuộc họp hàng ngày – daily metting để thảo luận về tiến độ trong một sprint bởi một team tự định hướng – self-directed team. Trong thực tế, các tổ chức khác nhau cho phép mức độ tự định hướng khác nhau.
Một ví dụ khác về các mô hình Agile là Extreme Programming hoặc XP. XP cung cấp một tập hợp các thực hành lập trình trong môi trường linh hoạt. XP tập trung vào việc cải thiện chất lượng phần mềm thông qua việc áp dụng một số nguyên tắc và phương pháp cụ thể như Lập trình cặp – Pair Programming, Kiểm thử liên tục – Continuous Testing, Quản lý code tập thể – Collective Code Ownership, Chu kỳ ngắn hạn – Short Iterations, Tích hợp liên tục – Continuous Integration. XP là một phương pháp Agile mạnh mẽ và linh hoạt, tập trung vào việc xây dựng phần mềm chất lượng cao.
Thách Thức Trong Quản Lý Kiểm Thử Của Mô Hình Agile
Các vấn đề kiểm thử với các phương pháp Agile cũng tương tự như các vấn đề với vòng đời lặp lại, mặc dù tốc độ lặp lại khiến các vấn đề trở nên nghiêm trọng hơn. Ngoài ra, mối quan hệ chính xác giữa những người kiểm thử, nhóm kiểm thử độc lập và các nhóm agile khác là thứ thay đổi đáng kể giữa các tổ chức.
- Sự thay đổi yêu cầu: Trong Agile, yêu cầu có thể thay đổi linh hoạt trong suốt quá trình phát triển. Điều này đòi hỏi khả năng thích ứng và linh hoạt từ phía nhóm phát triển để xử lý và thích nghi với sự thay đổi này một cách hiệu quả.
- Sự phụ thuộc vào sự tương tác và giao tiếp: Agile đặt sự tương tác và giao tiếp làm yếu tố quan trọng. Điều này có thể gặp khó khăn nếu các thành viên trong nhóm phát triển không có khả năng giao tiếp hiệu quả hoặc nếu tổ chức phát triển phần mềm phải làm việc với các đội phân tán địa lý.
- Quản lý phạm vi: Trong Agile, việc xác định và kiểm soát phạm vi là một thách thức. Sự thay đổi liên tục và yêu cầu không rõ ràng có thể dẫn đến việc mở rộng phạm vi không kiểm soát, gây ra sự trùng lặp công việc và làm ảnh hưởng đến khả năng hoàn thành dự án.
- Hiệu suất và tài nguyên: Agile yêu cầu tính linh hoạt và sự thích ứng nhanh chóng, tuy nhiên, điều này có thể gây ra áp lực lên hiệu suất và tài nguyên của nhóm phát triển. Các thành viên nhóm cần đảm bảo rằng họ có đủ tài nguyên và khả năng làm việc hiệu quả trong một môi trường Agile.
- Đảm bảo chất lượng: Với quy trình phát triển nhanh chóng và sự thay đổi liên tục, đảm bảo chất lượng phần mềm có thể trở thành một thách thức. Kiểm thử và đảm bảo chất lượng cần được tích hợp và thực hiện đồng thời với quá trình phát triển để đảm bảo rằng phần mềm được phát triển và triển khai một cách an toàn và ổn định.
- Quản lý thời gian và ưu tiên: Agile yêu cầu việc lập kế hoạch ngắn hạn và ưu tiên công việc theo giá trị kinh doanh. Điều này đòi hỏi khả năng quản lý thời gian và ưu tiên công việc một cách hiệu quả, đồng thời đảm bảo rằng các tính năng quan trọng nhất được hoàn thành đúng thời gian.
- Sự tham gia của khách hàng: Agile đề cao sự tham gia và phản hồi của khách hàng. Tuy nhiên, có thể gặp khó khăn trong việc liên kết và đồng bộ hóa với khách hàng, đặc biệt là khi khách hàng không có sẵn hoặc khó tiếp cận.
Để vượt qua các khó khăn này, cần có sự linh hoạt, sự tương tác tốt giữa các thành viên trong nhóm phát triển, khả năng quản lý tốt và sự thích ứng nhanh chóng với sự thay đổi.
Cơ Hội Trong Quản Lý Kiểm Thử Của Mô Hình Agile
Phương pháp Agile cũng mang lại cơ hội kiểm thử như:
- Kiểm thử đơn vị tự động – Automated unit testing. Khi nó được sử dụng đầy đủ, việc sử dụng kiểm thử đơn vị tự động dẫn đến mã chất lượng cao hơn nhiều được phân phối để kiểm thử.
- Phân tích mã tĩnh – Static code analysis. Ngày càng có nhiều nhóm Agile sử dụng các công cụ phân tích mã tĩnh và điều này cũng cải thiện chất lượng mã, đặc biệt là khả năng bảo trì của mã, điều đặc biệt quan trọng do rủi ro hồi quy gia tăng.
- Độ phủ mã code – Code coverage. Các nhóm Agile cũng sử dụng độ phủ mã code để đo lường mức độ đầy đủ của các bài kiểm tra đơn vị của họ và ngày càng tăng các bài kiểm tra chức năng tự động của họ, giúp định lượng mức độ tin cậy mà chúng tôi có thể có trong quá trình kiểm thử.
- Tích hợp liên tục – Continuous integration. Việc sử dụng các công cụ tích hợp liên tục, đặc biệt là khi được tích hợp với kiểm thử đơn vị tự động, phân tích tĩnh và phân tích độ phủ mã code, làm tăng chất lượng code tổng thể và giảm tỷ lệ các bản dựng không thể kiểm tra được phân phối để kiểm thử.
- Kiểm thử chức năng tự động – Automated functional testing. Các công cụ kiểm tra Agile bao gồm một số công cụ kiểm tra chức năng tự động, một số khá tốt và cũng miễn phí. Ngoài ra, các bài kiểm tra chức năng tự động cũng thường có thể được tích hợp vào các khung liên tục.
- Đánh giá yêu cầu (hoặc user stories) và đánh giá kiểm thử (acceptance criteria). Trong một nhóm Agile hoạt động đúng cách, các user stories và tiêu chí chấp nhận – acceptance criteria được toàn bộ nhóm cùng xem xét. Điều này có thể giúp ngăn chặn những bất ngờ về những gì sẽ được kiểm tra và cách thức hoạt động của phần mềm, nếu có thể tránh được rối loạn chức năng – dysfunction được đề cập trước đó.
- Khối lượng công việc hợp lý – Reasonable workload. Mặc dù một số nhóm Agile lạm dụng điều này, tuy nhiên một nhóm Agile được triển khai đúng cách sẽ cố gắng duy trì các tuần làm việc trong giới hạn 40 giờ, kể cả đối với người kiểm thử, hay ngay cả thời điểm kết thúc một sprint.
- Kiểm soát technical debt (thông qua “sửa lỗi trước”). Một số nhóm Agile có quy tắc rằng nếu các lỗi được phép thoát khỏi một sprint, thì chúng sẽ được sửa ngay lập tức trong sprint tiếp theo, trước khi triển khai bất kỳ user story mới nào, điều này thực hiện rất tốt công việc kiểm soát technical debt.
Kế Hoạch Kiểm Thử Trong Mô Hình Xoắn Ốc – Spiral Models
Mô hình xoắn ốc – Spiral Models được phát triển bởi Barry Boehm. Mô hình xoắn ốc sử dụng prototype để thiết kế hệ thống. Công việc phát triển được thực hiện thống qua một chuỗi các prototype được kiểm thử, thiết kế lại, rồi tạo lại prototype, kiểm thử lại, v.v.. đến khi tất các quyết định thiết kế rủi ro được kiểm chứng (hoặc bãi bỏ kiểm chứng, bãi bỏ thực hiện).
Mô hình Spiral chia quá trình phát triển phần mềm thành nhiều vòng lặp nhỏ được gọi là “vòng Spiral”. Mỗi vòng Spiral bao gồm bốn giai đoạn chính: xác định các mục tiêu, đánh giá và giảm rủi ro, phát triển và kiểm thử, và đánh giá của khách hàng. Mỗi vòng Spiral tạo ra một phiên bản phần mềm hoàn chỉnh, nâng cấp hoặc mở rộng từ phiên bản trước đó.
Quy trình trong mô hình Spiral bắt đầu bằng việc thu thập yêu cầu và thiết kế sơ bộ, sau đó tiến hành phân tích rủi ro. Tiếp theo, một kế hoạch chi tiết được xác định để phát triển và kiểm thử các tính năng. Sau mỗi vòng Spiral, sự phân tích và đánh giá từ khách hàng được thực hiện để xác định việc tiếp tục phát triển hoặc chỉnh sửa các tính năng.
Lợi Ích Của Mô Hình Xoắn Ốc
Lợi ích của mô hình Spiral bao gồm:
- Quản lý rủi ro tốt hơn: Bằng cách đánh giá và giảm thiểu rủi ro trong mỗi vòng Spiral, mô hình này giúp phát hiện và xử lý các vấn đề sớm hơn.
- Phản hồi từ khách hàng: Quá trình đánh giá của khách hàng sau mỗi vòng Spiral cho phép các điều chỉnh và cải tiến để đáp ứng yêu cầu của khách hàng.
- Linh hoạt và sáng tạo: Mô hình Spiral cho phép linh hoạt trong việc thay đổi yêu cầu và thiết kế trong quá trình phát triển.
- Độ tin cậy cao: Mô hình Spiral giúp kiểm soát chất lượng và đảm bảo sự tin cậy của phần mềm thông qua việc thực hiện kiểm thử và đánh giá từ khách hàng.
Thách Thức Trong Quản Lý Kiểm Thử Của Mô Hình Xoắn Ốc
Tuy nhiên, có những vấn đề kiểm tra do nó tạo ra mà trình quản lý kiểm tra thông minh phải quản lý.
- Các thiết kế của hệ thống sẽ thay đổi. Điều này có nghĩa là tính linh hoạt là tối quan trọng trong tất cả các quyết định về trường hợp kiểm thử, dữ liệu kiểm thử, công cụ kiểm thử và môi trường kiểm thử ngay từ đầu dự án. Ví dụ: nếu người quản lý kiểm tra cam kết quá nhiều với một cách cụ thể để tạo dữ liệu kiểm tra và cấu trúc của kho lưu trữ dữ liệu hệ thống thay đổi đáng kể, chẳng hạn như từ cơ sở dữ liệu quan hệ sang tệp XML, thì điều đó sẽ gây khó khăn nghiêm trọng khi thực hiện kiểm thử lại.
- Giai đoạn kiểm thử sớm độc đáo. Việc kiểm thử các prototype ban đầu nhằm tìm xem có những gì có thể không hoạt động. Việc xây dựng độ tin cậy không phải mục tiêu trong giai đoạn này. Vai trò của kiểm thử sẽ điển hình hơn ở những giai đoạn cuối. Điều này yêu cầu người quản lý kiểm thử có thể phải thay đổi kế hoạch và chiến lược trong quá trình phát triển dự án. Một lần nữa, tính linh hoạt là chìa khóa cho mô hình phát triển này.
- Lịch trình khó đoán. Với nỗ lực của mô hình xoắn ốc để giải quyết những điều chưa biết thông qua việc tạo prototype lặp đi lặp lại, lịch trình có thể khá khó đoán. Điều này có thể làm cho việc ước tính và lập kế hoạch cho công việc kiểm thử trở nên khó khăn, đặc biệt nếu các dự án khác đang hoạt động cũng một lúc.
Kiểm thử các nguyên mẫu ban đầu là để tìm ra những gì chúng ta không biết, đưa các thiết kế đáng ngờ vào kiểm thử nghiêm ngặt để xem những gì có thể không hoạt động. Thông thường, việc xây dựng lòng tin không phải là một mục tiêu. Các mục tiêu kiểm thử khác nhau này cho kiểm thử trước đó, phát triển thành vai trò kiểm thử điển hình hơn trong giai đoạn cuối, yêu cầu người quản lý kiểm thử thay đổi kế hoạch và chiến lược khi dự án tiến triển. Một lần nữa, tính linh hoạt là chìa khóa.
Kết Luận
Trên đây mình đã trình bày những đặc điểm điển hình của các mô hình phát triển phổ biến hiện nay. Cũng như những khó khăn gặp phải khi xây dựng kế hoạch kiểm thử cho từng loại.
Hẹn gặp lại các bạn vào những bài viết tiếp theo.
Happy Testing!