ĐẶC ĐIỂM KIỂM THỬ TRONG CÁC MÔ HÌNH PHÁT TRIỂN PHẦN MỀM

Quá trình kiểm thử có những quy tắc chung giống nhau, nhưng cũng sẽ có những sự khác biệt tùy thuộc vào mô hình vòng đời phát triển phần mềm. Sau đây, chúng ta sẽ xem xét các đặc điểm của kiểm thử trong hai mô hình phát triển chính: “Mô hình phát triển tuần tự” và “Mô hình phát triển lặp lại và tăng dần”.

Mô hình phát triển tuần tự (Sequential development model)

Mô hình phát triển tuần tự là một quá trình mà các hoạt động phát triển phần mềm được tiến hành theo thứ tự. Ví dụ, chỉ khi hoàn thành giai đoạn định nghĩa yêu cầu thì mới chuyển sang giai đoạn thiết kế tiếp theo. Thông thường, kiểm thử được bắt đầu sau khi hoàn tất việc lập trình, và thực hiện tuần tự từ kiểm thử đơn vị (unit test) đến kiểm thử tích hợp (integration test), tuy nhiên, các giai đoạn này có thể chồng chéo nhau. 

Ở đây, chúng ta sẽ xem xét mô hình Waterfall (thác nước) – mô hình cơ bản trong phát triển phần mềm, cùng với mô hình chữ V dựa trên Waterfall.

Mô hình Waterfall

Mô hình Waterfall là mô hình phát triển phần mềm truyền thống và phổ biến nhất. Mặc dù có nhiều mô hình phát triển khác, nhưng hầu hết đều được cải tiến từ mô hình Waterfall. Trong mô hình này, các giai đoạn như định nghĩa yêu cầu, thiết kế, lập trình và kiểm thử được tiến hành theo thứ tự, hoàn thành mỗi giai đoạn xong thì mới chuyển sang giai đoạn tiếp theo. Tên gọi “Waterfall” (thác nước) biểu thị sự chảy từ trên xuống dưới của các giai đoạn, với định nghĩa yêu cầu và thiết kế ở giai đoạn “thượng nguồn” và kiểm thử ở giai đoạn “hạ nguồn”.

Mô hình chữ V

Mô hình chữ V là một biến thể của mô hình Waterfall, trong đó các giai đoạn thượng nguồn và hạ nguồn được biểu diễn theo hình chữ “V”. Trong kiểm thử, hệ thống được kiểm tra để xác nhận rằng nó hoạt động đúng theo yêu cầu và thiết kế được định nghĩa ở giai đoạn thượng nguồn. Do đó, giai đoạn thượng nguồn của mô hình chữ V được coi là “quá trình xây dựng chất lượng” và giai đoạn hạ nguồn (kiểm thử) là “quá trình xác nhận chất lượng”.

Ưu điểm của mô hình chữ V nằm ở việc có thể làm rõ ràng các mức độ kiểm thử tương ứng với từng giai đoạn thượng nguồn. Ví dụ, trong mô hình chữ V, tài liệu thiết kế cơ bản được tạo ra ở giai đoạn thiết kế cơ bản sẽ được sử dụng làm cơ sở cho việc phân tích và thiết kế kiểm thử tích hợp.

Ngoài ra, các tài liệu sản phẩm đầu ra ở giai đoạn thượng nguồn sẽ được kiểm tra qua đánh giá để đảm bảo tính đúng đắn. Trong mỗi giai đoạn, các sản phẩm đầu ra được chi tiết hóa từ sản phẩm đầu ra của giai đoạn trước, qua đó kiểm tra tính nhất quán và nội dung mô tả nhằm nâng cao chất lượng. Đồng thời, cũng sẽ xác nhận tính phù hợp với yêu cầu của người dùng. Quá trình kiểm tra và xác nhận này gọi là “V&V” (Verification & Validation).

Nhược điểm của mô hình Waterfall

Trong mô hình Waterfall, sau khi kết thúc mỗi giai đoạn, các sản phẩm đầu ra sẽ được kiểm tra để đảm bảo không có vấn đề trước khi chuyển sang giai đoạn tiếp theo. Theo nguyên tắc đó, mô hình này không cho phép quay lại. Tuy nhiên, vẫn sẽ có trường hợp phát hiện vấn đề bị bỏ sót ở giai đoạn trước trong các giai đoạn sau. Trong trường hợp này, cần phải quay lại giai đoạn trước để sửa các sản phẩm đầu ra và các sản phẩm liên quan, quá trình này gọi là “lặp lại”.

Ví dụ, nếu phát hiện lỗi trong định nghĩa yêu cầu ở giai đoạn kiểm thử hệ thống, không chỉ phải sửa định nghĩa yêu cầu mà còn phải sửa thiết kế và code liên quan. Ngoài ra, cũng cần kiểm thử lại từ kiểm thử đơn vị (unit test) và kiểm thử tích hợp (integration test) phù hợp với các nội dung đã sửa.

Như vậy, mô hình Waterfall có nhược điểm là khó thích ứng với việc thay đổi yêu cầu. Đặc biệt, đối với các dự án mà yêu cầu chưa ổn định trong giai đoạn đầu phát triển và có nhiều thay đổi yêu cầu ở các giai đoạn sau, mô hình này được xem là không phù hợp.

Mô hình chữ W và Shift Left

Mô hình chữ V có điểm cộng là làm rõ được sự tương ứng giữa các giai đoạn thượng nguồn và kiểm thử, nhưng lại có nhược điểm là kiểm thử có vẻ chỉ được thực hiện ở giai đoạn sau phát triển. Thực tế, một phần của kiểm thử thường cũng có thể được thực hiện ở giai đoạn thượng nguồn, nhưng mô hình này có thể dẫn đến nhiều hiểu lầm. Để làm rõ rằng hoạt động kiểm thử diễn ra song song với các giai đoạn thượng nguồn, mô hình chữ W đã được đề xuất. Trong mô hình này, việc lập kế hoạch và thiết kế kiểm thử diễn ra song song với các giai đoạn thượng nguồn, nhờ đó có thể cải thiện chất lượng sản phẩm đầu ra thông qua phản hồi từ hoạt động kiểm thử. Bằng cách thực hiện kiểm thử sớm, thời gian phát triển cũng có thể được rút ngắn lại. 

Ngoài ra, khi tích hợp điều tra mô hình chữ W, việc kiểm tra và thực thi mô hình ở giai đoạn thượng nguồn sẽ trở nên khả thi, giúp thực hiện kiểm thử ngay từ giai đoạn đầu như là một phần của phương pháp “Shift Left”.

Mô hình phát triển lặp lại (Iterative) và Mô hình phát triển gia tăng (Incremental)

Mô hình phát triển tuần tự nói trên có thể mất từ vài tháng đến vài năm để hoàn thành, gây ra vấn đề về thời gian hoàn thành dự án. Để giải quyết vấn đề này và cung cấp sản phẩm trong thời gian ngắn, mô hình phát triển lặp lại và mô hình phát triển gia tăng đã được ra đời. Mặc dù hai mô hình này khác nhau, chúng vẫn thường được kết hợp sử dụng trong thực tế.

Mô hình phát triển gia tăng (Incremental Development Model)

Từ “incremental” có nghĩa là “tăng dần” hoặc “theo từng bước”. Do đó, mô hình phát triển gia tăng là phương pháp phát triển mà các tính năng được bổ sung dần dần. Trong ngữ cảnh này, “tăng dần” ám chỉ các “tính năng” của phần mềm. Từ “feature” (tính năng) trong tiếng Anh có thể dịch là “chức năng” hoặc “đặc trưng”. Trong khi từ “function” thường chỉ các chức năng cụ thể như gửi email hay ghi hình, “feature” chỉ các đặc trưng cụ thể như “có thể đính kèm tập tin vào email” hoặc “gửi email cho nhiều người cùng lúc”.

Hệ thống phát triển sẽ được chia thành một số nhóm tính năng và tiến hành phát triển từ định nghĩa yêu cầu đến kiểm thử cho mỗi nhóm đó.

Mô hình phát triển lặp (Iterative Development Model)

“Iterative” có nghĩa là “lặp đi lặp lại”. Trong khi mô hình phát triển tuần tự thực hiện từ giai đoạn xác định yêu cầu đến kiểm thử chỉ một lần, thì mô hình phát triển lặp lặp lại các bước như đặc tả, thiết kế, xây dựng và kiểm thử. Quy trình này được gọi là “Iteration” (chu kỳ lặp), và sau mỗi chu kỳ lặp, phần mềm có thể hoạt động được sẽ được tạo ra. Các mô hình phát triển này thường được sử dụng kết hợp.

Dưới đây là bốn mô hình phát triển lặp chính:

• Rational Unified Process (RUP): Đây là phương pháp do IBM đề xuất, bao gồm toàn bộ vòng đời phát triển ứng dụng. Chu kỳ lặp thường kéo dài từ 2 đến 3 tháng.
• Scrum: Là một trong những phương pháp phát triển Agile, với mục tiêu để cả nhóm cùng hướng đến mục đích chung. Chu kỳ lặp kéo dài từ vài ngày đến vài tuần, được gọi là “Sprint”.
• Kanban: Là phương pháp dựa trên hệ thống sản xuất của Toyota, giúp hiển thị và quản lý các công việc một cách hiệu quả. Chu kỳ lặp không bắt buộc phải có.
• Spiral (Prototyping): Tạo ra các nguyên mẫu ở giai đoạn ban đầu và xác định yêu cầu dựa trên phản hồi nhận được. Đặc trưng của phương pháp này là dần dần bổ sung các tính năng.

Mô hình phát triển lặp lại / gia tăng và Shift Left

Khi sử dụng các mô hình phát triển này, phần mềm sẽ được chia thành các đơn vị nhỏ, và các đơn vị này sẽ được phát triển lặp đi lặp lại. Do kiểm thử được thực hiện trong mỗi chu kỳ lặp, thời điểm kiểm thử được đẩy sớm hơn (Shift Left). Trong thực tế, có những trường hợp như sau:

• Yêu cầu, thiết kế, code và kiểm thử được thực hiện đồng thời.
• Kiểm thử đơn vị và kiểm thử tích hợp được thực hiện song song hoặc lặp lại.
• Kiểm thử hệ thống và kiểm thử chấp nhận được thực hiện như một chu kỳ lặp độc lập.

Do kiểm thử được thực hiện lặp lại trong các chu kỳ lặp ngắn hạn, việc tự động hóa kiểm thử là cần thiết, và môi trường tích hợp liên tục và phân phối liên tục cũng cần được thiết lập. Sau khi kết thúc mỗi chu kỳ lặp, một số tính năng sẽ được tạo ra, nhưng thời điểm phát hành không nhất thiết phải cố định. Có thể phát hành khi đã có đủ các tính năng tối thiểu hoặc chờ đến khi tất cả các tính năng hoàn thiện. Tuy nhiên, khuyến khích thực hiện phát hành sớm và nhận phản hồi từ khách hàng.

Mô hình vòng đời phát triển phần mềm tùy theo tình huống

Trong phần trước, chúng ta đã giải thích về các mô hình phát triển tuần tự, lặp đi lặp lại và gia tăng. Vậy khi quyết định lựa chọn mô hình nào, cần phải xem xét những yếu tố sau:

• Mục tiêu của dự án
• Loại sản phẩm cần phát triển
• Ưu tiên trong kinh doanh (thời gian ra thị trường)
• Rủi ro của sản phẩm đã được nhận diện
• Rủi ro của dự án đã được nhận diện

Các hệ thống có mức độ rủi ro thấp (ví dụ: hệ thống quản lý trong công ty) và các hệ thống có mức độ rủi ro cao (ví dụ: hệ thống điều khiển phanh xe ô tô) sẽ có cách tiếp cận kiểm thử khác nhau. Khi áp dụng mô hình phát triển lặp đi lặp lại, việc giao tiếp hiệu quả giữa các thành viên trong nhóm rất quan trọng, nhưng văn hóa công ty và hình thức hợp đồng có thể cản trở điều này.

Kết hợp các mô hình vòng đời phát triển phần mềm

Trong mô hình phát triển gia tăng đã được giải thích trước đó, có thể sử dụng kết hợp cả hai mô hình trong một dự án. Ví dụ, trong phát triển ứng dụng di động, có thể sử dụng mô hình lặp đi lặp lại và gia tăng cho giao diện người dùng (UI) của phần mềm, để phát hành nhanh chóng, nhưng sẽ áp dụng mô hình tuần tự cho hệ thống backend quy mô lớn.

Ngoài ra, trong hệ thống IoT (Internet of Things – Mạng lưới vạn vật), các thiết bị và dịch vụ khác nhau sẽ được phát triển riêng biệt và mô hình phát triển sẽ được chọn tùy theo từng mục tiêu phát triển. Do đó, một số thiết bị có thể được nâng cấp phiên bản thường xuyên, trong khi các sản phẩm khác có thể không thay đổi trong thời gian dài. Điều này có thể gây ra các vấn đề về khả năng tương thích giữa các phiên bản khác nhau và cần chú ý đến sự tương thích khi vận hành, cập nhật và ngừng sử dụng trong các giai đoạn sau.

※Câu hỏi luyện tập:

https://exam-site.briswell-vn.com/startTest/jstqb-4-vn