QA Engineer (Tester) Roadmap – Các Mô Hình SDLC: Agile, V-Model, và Waterfall

Chào bạn, đồng nghiệp tương lai hoặc đã và đang trên con đường trở thành một Kỹ sư QA giỏi! 👋

Chào mừng bạn quay trở lại với chuỗi bài viết “QA Engineer (Tester) Roadmap“. Trong các bài trước, chúng ta đã cùng nhau khám phá “Đảm bảo Chất lượng là gì?” và rèn luyện “Tư duy của một Người Kiểm thử“. Hôm nay, chúng ta sẽ đào sâu vào một nền tảng kiến thức cực kỳ quan trọng mà bất kỳ ai làm trong lĩnh vực phát triển phần mềm, đặc biệt là QA, đều cần nắm vững: Các Mô hình Vòng đời Phát triển Phần mềm (SDLC – Software Development Life Cycle).

Tại sao QA cần hiểu về SDLC? Đơn giản là vì công việc của chúng ta – đảm bảo chất lượng phần mềm – diễn ra trong suốt vòng đời phát triển đó. Cách một dự án được tổ chức và thực hiện theo mô hình nào sẽ ảnh hưởng trực tiếp đến cách chúng ta lên kế hoạch kiểm thử, thời điểm chúng ta tham gia, cách chúng ta tương tác với các thành viên khác trong nhóm (개발자 – Developer, BA – Business Analyst, PM – Project Manager), và cuối cùng là hiệu quả công việc của chúng ta.

Hiểu rõ các mô hình SDLC phổ biến như Waterfall, V-Model và Agile không chỉ giúp bạn biết mình đang ở đâu trong quy trình làm việc, mà còn giúp bạn chủ động hơn trong việc đóng góp vào thành công chung của dự án. Hãy cùng bắt đầu khám phá nhé!

1. Mô Hình Waterfall (Thác nước) – Nền Tảng Cổ Điển

Mô hình Waterfall là một trong những mô hình SDLC lâu đời và cơ bản nhất. Như tên gọi “Thác nước”, nó mô tả một quy trình phát triển phần mềm tuần tự, tuyến tính. Các giai đoạn phát triển diễn ra theo một trình tự cố định, và mỗi giai đoạn phải hoàn thành hoàn toàn trước khi chuyển sang giai đoạn tiếp theo. Giống như nước chỉ chảy theo một hướng xuống dưới, việc quay ngược lại các giai đoạn trước thường rất khó khăn hoặc tốn kém.

Các Giai Đoạn Cơ Bản của Waterfall:

Một quy trình Waterfall điển hình bao gồm các giai đoạn sau:

1. Requirement Gathering and Analysis (Thu thập và Phân tích Yêu cầu): Đây là giai đoạn đầu tiên, nơi tất cả các yêu cầu về chức năng và phi chức năng của phần mềm được thu thập và ghi lại một cách chi tiết và đầy đủ. Đầu ra là tài liệu đặc tả yêu cầu phần mềm (SRS – Software Requirements Specification).
2. System Design (Thiết kế Hệ thống): Dựa trên tài liệu SRS, kiến trúc tổng thể của hệ thống được thiết kế. Giai đoạn này bao gồm thiết kế kiến trúc, thiết kế cơ sở dữ liệu, thiết kế giao diện người dùng, v.v.
3. Implementation (Triển khai/Code): Các lập trình viên bắt đầu viết mã (code) dựa trên tài liệu thiết kế. Các module nhỏ được phát triển và kiểm thử đơn vị (unit test).
4. Testing (Kiểm thử): Sau khi quá trình code hoàn thành, phần mềm được chuyển sang giai đoạn kiểm thử. Đây là lúc QA vào cuộc để tìm lỗi, xác minh rằng phần mềm đáp ứng đúng các yêu cầu đã đặt ra trong tài liệu SRS.
5. Deployment (Triển khai): Phần mềm đã được kiểm thử và chấp nhận được triển khai ra môi trường người dùng cuối.
6. Maintenance (Bảo trì): Sau khi triển khai, phần mềm được bảo trì, bao gồm sửa lỗi phát sinh, cập nhật và cải tiến nhỏ dựa trên phản hồi của người dùng.

Bạn có thể hình dung luồng công việc như sau:

Yêu cầu -> Thiết kế -> Triển khai -> Kiểm thử -> Triển khai -> Bảo trì

Vai trò của QA trong Mô hình Waterfall:

Trong mô hình Waterfall, vai trò chính của QA tập trung vào giai đoạn “Testing”. QA nhận sản phẩm đã hoàn thành từ giai đoạn “Implementation” và bắt đầu thực hiện các hoạt động kiểm thử. Các loại kiểm thử phổ biến trong giai đoạn này có thể là kiểm thử hệ thống (System Testing), kiểm thử tích hợp (Integration Testing), và kiểm thử chấp nhận (Acceptance Testing).

Tuy nhiên, việc kiểm thử chỉ diễn ra ở cuối quy trình là nhược điểm lớn. Nếu phát hiện lỗi ở giai đoạn này, việc sửa chữa thường tốn kém hơn rất nhiều vì có thể liên quan đến việc thay đổi thiết kế hoặc cấu trúc đã xây dựng từ trước. Việc quay lại các giai đoạn trước để sửa lỗi giống như cố gắng bơi ngược dòng thác vậy!

Ưu điểm của Waterfall:

• Đơn giản, dễ hiểu và dễ quản lý: Với cấu trúc tuần tự rõ ràng, mô hình này dễ dàng cho các dự án nhỏ, yêu cầu ổn định và được xác định rõ ràng ngay từ đầu.
• Các giai đoạn được xác định rõ ràng: Mọi người đều biết nhiệm vụ của mình và khi nào cần hoàn thành.
• Phù hợp với các dự án có yêu cầu cố định: Nếu yêu cầu không thay đổi trong suốt quá trình phát triển, Waterfall có thể là lựa chọn khả thi.

Nhược điểm của Waterfall:

• Thiếu linh hoạt: Rất khó khăn khi yêu cầu thay đổi giữa chừng.
• Kiểm thử diễn ra muộn: Việc phát hiện lỗi muộn làm tăng chi phí sửa lỗi và rủi ro dự án.
• Khó nhận phản hồi từ người dùng sớm: Người dùng chỉ có thể nhìn thấy sản phẩm hoạt động ở giai đoạn cuối.
• Không phù hợp với các dự án phức tạp, lớn hoặc có yêu cầu không rõ ràng/thay đổi liên tục.

Ngày nay, mô hình Waterfall ít được sử dụng trong phát triển phần mềm hiện đại, đặc biệt là các dự án web, mobile hoặc sản phẩm có tính cạnh tranh cao, yêu cầu phản hồi nhanh từ thị trường.

2. Mô Hình V-Model – Kiểm Thử Song Song Với Phát Triển

Mô hình V-Model là một sự mở rộng của mô hình Waterfall, nhưng nhấn mạnh vào mối quan hệ giữa các giai đoạn phát triển và các giai đoạn kiểm thử tương ứng. Tên gọi V-Model xuất phát từ hình dạng chữ “V” của nó, biểu thị rằng các hoạt động kiểm thử bắt đầu sớm trong vòng đời phát triển, song song với các hoạt động thiết kế và phát triển.

Mục tiêu chính của V-Model là cải thiện hiệu quả kiểm thử bằng cách tích hợp kiểm thử vào quy trình phát triển từ đầu, giúp phát hiện lỗi sớm hơn.

Cấu trúc và Các Giai Đoạn của V-Model:

Mô hình V-Model bao gồm hai nhánh chính, tạo thành hình chữ V:

Nhánh trái (Verification – Xác minh): Các hoạt động thiết kế và đặc tả.

1. Business Requirements (Yêu cầu Kinh doanh): Thu thập yêu cầu cấp cao. Liên quan trực tiếp đến Kiểm thử Chấp nhận (Acceptance Testing) ở nhánh phải.
2. System Design (Thiết kế Hệ thống): Thiết kế kiến trúc tổng thể. Liên quan trực tiếp đến Kiểm thử Hệ thống (System Testing).
3. Architecture Design (Thiết kế Kiến trúc/Cao cấp): Thiết kế các thành phần, module chính. Liên quan trực tiếp đến Kiểm thử Tích hợp (Integration Testing).
4. Module Design (Thiết kế Module/Chi tiết): Thiết kế chi tiết từng module nhỏ. Liên quan trực tiếp đến Kiểm thử Đơn vị (Unit Testing).

Đáy chữ V: Giai đoạn Triển khai (Coding), nơi mã nguồn được viết dựa trên thiết kế module chi tiết.

Nhánh phải (Validation – Xác nhận): Các hoạt động kiểm thử tương ứng.

5. Unit Testing (Kiểm thử Đơn vị): Kiểm thử từng module code riêng lẻ, thường do lập trình viên thực hiện, dựa trên thiết kế module chi tiết.
6. Integration Testing (Kiểm thử Tích hợp): Kiểm thử sự tương tác giữa các module đã được kiểm thử đơn vị, dựa trên thiết kế kiến trúc.
7. System Testing (Kiểm thử Hệ thống): Kiểm thử toàn bộ hệ thống tích hợp để xác minh nó đáp ứng các yêu cầu chức năng và phi chức năng của hệ thống, dựa trên thiết kế hệ thống.
8. Acceptance Testing (Kiểm thử Chấp nhận): Kiểm thử để xác minh rằng hệ thống đáp ứng các yêu cầu kinh doanh của người dùng cuối và sẵn sàng để triển khai. Thường do người dùng cuối hoặc đại diện của họ thực hiện, dựa trên yêu cầu kinh doanh.

Mối liên kết giữa các giai đoạn ở hai nhánh cho thấy rằng, ngay từ giai đoạn thiết kế yêu cầu/hệ thống, các kế hoạch và trường hợp kiểm thử tương ứng đã có thể được xây dựng. Ví dụ, khi thiết kế hệ thống, QA đã có thể bắt đầu suy nghĩ về cách kiểm thử toàn bộ hệ thống đó.

Vai trò của QA trong Mô hình V-Model:

Trong V-Model, vai trò của QA mở rộng hơn so với Waterfall. QA không chỉ tham gia vào giai đoạn kiểm thử ở cuối, mà còn tham gia vào các hoạt động “xác minh” (verification) ở nhánh trái. Điều này có nghĩa là QA có thể bắt đầu xem xét, phân tích và đóng góp vào tài liệu yêu cầu, thiết kế hệ thống, thiết kế kiến trúc ngay từ các giai đoạn đầu.

Cụ thể, QA có thể:

• Tham gia vào việc xem xét (review) các tài liệu yêu cầu và thiết kế để phát hiện các vấn đề, sự không rõ ràng hoặc mâu thuẫn ngay từ sớm.
• Bắt đầu viết các kế hoạch kiểm thử (Test Plan) và trường hợp kiểm thử (Test Case) tương ứng với từng cấp độ kiểm thử (System, Integration, Acceptance) ngay khi các tài liệu thiết kế liên quan được hoàn thiện.
• Làm việc chặt chẽ với các lập trình viên để hỗ trợ kiểm thử đơn vị và tích hợp (mặc dù lập trình viên thường là người thực hiện chính).
• Thực hiện kiểm thử hệ thống và kiểm thử chấp nhận khi code hoàn thành.

Việc tham gia sớm giúp QA hiểu sâu hơn về sản phẩm và chuẩn bị tốt hơn cho giai đoạn thực thi kiểm thử. Quan trọng hơn, nó giúp phát hiện và sửa lỗi sớm hơn, giảm chi phí.

Ưu điểm của V-Model:

• Nhấn mạnh việc kiểm thử sớm: Các hoạt động kiểm thử được tích hợp từ các giai đoạn đầu, giúp phát hiện lỗi sớm hơn.
• Các giai đoạn được xác định rõ ràng: Tương tự Waterfall, các bước tuần tự giúp quản lý dễ dàng.
• Phù hợp với các dự án có yêu cầu tương đối ổn định: Nếu yêu cầu không thay đổi quá nhiều.
• Tập trung vào xác minh và xác nhận: Đảm bảo rằng sản phẩm được xây dựng đúng cách (verification) và xây dựng đúng sản phẩm (validation).

Nhược điểm của V-Model:

• Vẫn còn thiếu linh hoạt: Mặc dù tốt hơn Waterfall, việc thay đổi yêu cầu vẫn gặp khó khăn.
• Ít phù hợp với các dự án phức tạp, lớn hoặc có yêu cầu thay đổi nhanh.
• Không cung cấp phản hồi sớm từ người dùng cuối về sản phẩm hoạt động thực tế.

3. Mô Hình Agile – Sự Linh Hoạt và Phản Hồi Liên Tục

Agile không chỉ là một mô hình SDLC mà còn là một triết lý, một tập hợp các nguyên tắc và giá trị về cách phát triển phần mềm. Khác biệt hoàn toàn với cách tiếp cận tuần tự của Waterfall hay V-Model, Agile tập trung vào phát triển lặp đi lặp lại (iterative) và tăng trưởng (incremental), sự hợp tác chặt chẽ, phản hồi nhanh chóng và khả năng thích ứng với sự thay đổi.

Trong Agile, toàn bộ vòng đời phát triển được chia thành các chu kỳ ngắn, lặp đi lặp lại, thường gọi là Sprint (trong Scrum) hoặc Iteration. Mỗi Sprint/Iteration thường kéo dài từ 1 đến 4 tuần, và mục tiêu là cuối mỗi chu kỳ, nhóm phát triển (bao gồm cả QA) sẽ cho ra một phiên bản phần mềm nhỏ, hoạt động được, có thể kiểm thử và trình diễn cho khách hàng để lấy phản hồi.

Các Nguyên Tắc Cốt Lõi của Agile (theo Tuyên ngôn Agile):

• Ưu tiên con người và sự tương tác hơn quy trình và công cụ.
• Phần mềm chạy được hơn tài liệu đầy đủ.
• Hợp tác với khách hàng hơn đàm phán hợp đồng.
• Phản hồi với sự thay đổi hơn tuân thủ kế hoạch ban đầu.

Các Framework Agile Phổ Biến:

Agile là một khái niệm rộng, có nhiều framework cụ thể triển khai các nguyên tắc Agile. Phổ biến nhất là:

• Scrum: Framework có cấu trúc rõ ràng với các vai trò (Product Owner, Scrum Master, Development Team – bao gồm cả Dev và QA), các sự kiện (Sprint Planning, Daily Stand-up, Sprint Review, Sprint Retrospective) và các vật phẩm (Product Backlog, Sprint Backlog, Increment).
• Kanban: Tập trung vào trực quan hóa luồng công việc, giới hạn công việc đang tiến hành (WIP – Work In Progress) và cải tiến liên tục hiệu quả.

Vai trò của QA trong Mô hình Agile:

Đây là điểm khác biệt lớn nhất và cũng là vai trò phổ biến nhất của QA trong các công ty công nghệ hiện đại. Trong Agile, QA là một thành viên không thể thiếu của nhóm phát triển (Development Team) ngay từ đầu dự án. Vai trò của QA trong Agile mang tính chủ động, liên tục và hợp tác chặt chẽ:

1. Tham gia vào các buổi lập kế hoạch Sprint (Sprint Planning): Hiểu rõ các User Story (mô tả chức năng từ góc nhìn người dùng) sẽ được phát triển trong Sprint, đặt câu hỏi để làm rõ yêu cầu và ước lượng công sức kiểm thử.
2. Tham gia viết và tinh chỉnh User Story, Acceptance Criteria: Cùng với Product Owner và Developer, QA đóng góp vào việc định nghĩa chi tiết yêu cầu và các tiêu chí chấp nhận (Acceptance Criteria) – điều kiện để coi User Story là “Done”.

       User Story: Với vai trò là Người dùng, tôi muốn có thể đăng nhập vào hệ thống bằng email và mật khẩu của mình để truy cập tài khoản cá nhân.
   
       Acceptance Criteria:
       - Hệ thống cho phép đăng nhập thành công khi nhập đúng email và mật khẩu đã đăng ký.
       - Hệ thống hiển thị thông báo lỗi phù hợp khi nhập sai email hoặc mật khẩu.
       - Hệ thống hiển thị thông báo khi người dùng chưa kích hoạt tài khoản.
       - Người dùng bị khóa tài khoản sau N lần đăng nhập sai liên tiếp.
       - Sau khi đăng nhập thành công, người dùng được chuyển hướng đến trang Dashboard.
       

3. Tham gia vào Daily Stand-up: Cập nhật tiến độ công việc, chia sẻ các khó khăn, đồng bộ với các thành viên khác trong nhóm.
4. Thực hiện Kiểm thử Liên tục (Continuous Testing): Kiểm thử diễn ra *song song* và *liên tục* với quá trình phát triển. Ngay khi developer hoàn thành một phần nhỏ của User Story, QA đã có thể bắt đầu kiểm thử.
5. Phát triển Kiểm thử Tự động (Test Automation): Tự động hóa là chìa khóa trong Agile để duy trì tốc độ và đảm bảo hồi quy (regression) không bị ảnh hưởng bởi các thay đổi liên tục. QA xây dựng và duy trì bộ test tự động cho các chức năng quan trọng.
6. Hợp tác chặt chẽ với Developer: Làm việc “pair” (cặp đôi) hoặc trao đổi thường xuyên với developer để hiểu sâu hơn về cách triển khai, tìm lỗi hiệu quả hơn và sửa lỗi nhanh chóng.
7. Tham gia vào Sprint Review: Cùng nhóm trình diễn các tính năng đã “Done” cho khách hàng/Product Owner và thu thập phản hồi.
8. Tham gia vào Sprint Retrospective: Cùng nhóm nhìn lại Sprint vừa qua để tìm cách cải thiện quy trình làm việc.

Trong Agile, QA không chỉ là người “tìm lỗi” ở cuối, mà là người đồng hành, đóng góp vào chất lượng sản phẩm từ khâu lên ý tưởng đến khi sản phẩm được triển khai. Điều này đòi hỏi QA không chỉ có kỹ năng kiểm thử mà còn cả kỹ năng giao tiếp, hợp tác và khả năng thích ứng cao. Việc hiểu rõ các kỹ thuật kiểm thử như Black Box, White Box, Gray Box Testing cũng rất quan trọng để áp dụng linh hoạt trong Agile.

Ưu điểm của Agile:

• Linh hoạt cao: Dễ dàng thích ứng với sự thay đổi yêu cầu.
• Phản hồi nhanh từ khách hàng: Khách hàng được xem và sử dụng các phiên bản nhỏ của sản phẩm thường xuyên, giúp đảm bảo sản phẩm đi đúng hướng.
• Phát hiện lỗi sớm: Kiểm thử liên tục giúp tìm lỗi nhanh và giảm chi phí sửa lỗi.
• Chất lượng sản phẩm tốt hơn: Nhờ vòng phản hồi ngắn và sự hợp tác chặt chẽ.
• Tinh thần đồng đội cao: Các thành viên trong nhóm làm việc cùng nhau để đạt mục tiêu chung.

Nhược điểm của Agile:

• Khó áp dụng cho các dự án lớn, phân tán: Đòi hỏi sự giao tiếp và hợp tác rất chặt chẽ.
• Yêu cầu khách hàng phải tham gia tích cực: Nếu khách hàng không sẵn sàng hoặc không có thời gian, Agile có thể gặp khó khăn.
• Yêu cầu nhóm phải tự quản lý và có kỷ luật cao.
• Việc lập kế hoạch dài hạn có thể gặp thách thức hơn.

4. So Sánh Các Mô Hình SDLC: Waterfall, V-Model, và Agile

Để giúp bạn có cái nhìn tổng quan và dễ so sánh, đây là bảng tóm tắt các điểm khác biệt chính giữa ba mô hình này:

5. Tại Sao Việc Hiểu Các Mô Hình Này Lại Quan Trọng Đối Với QA?

Nắm vững các mô hình SDLC giúp bạn định vị vai trò của mình trong quy trình làm việc của dự án. Bạn sẽ biết:

• Khi nào bạn được mong đợi tham gia vào dự án? (Ngay từ đầu trong Agile, hay sau khi code xong trong Waterfall?)
• Bạn cần làm việc với ai và như thế nào? (Hợp tác chặt chẽ với dev/PO trong Agile, hay nhận sản phẩm từ dev và làm việc độc lập hơn trong Waterfall?)
• Loại tài liệu nào bạn cần tham khảo hoặc đóng góp? (SRS trong Waterfall/V-Model, User Story/Acceptance Criteria trong Agile?)
• Áp lực về thời gian và tính linh hoạt của quy trình như thế nào?

Hiểu rõ ngữ cảnh làm việc giúp bạn chuẩn bị tốt hơn, giao tiếp hiệu quả hơn với các thành viên khác trong nhóm và đóng góp tối đa vào mục tiêu chung là tạo ra sản phẩm chất lượng cao. Đặc biệt, khi chuyển từ môi trường Waterfall/V-Model sang Agile (hoặc ngược lại), bạn sẽ dễ dàng thích nghi hơn nếu hiểu rõ sự khác biệt trong cách làm việc.

Kết Luận

Waterfall, V-Model, và Agile là ba trong số các mô hình SDLC phổ biến nhất, mỗi mô hình có ưu điểm và nhược điểm riêng, phù hợp với các loại dự án và bối cảnh khác nhau. Mặc dù Waterfall ít phổ biến hơn trong phát triển phần mềm hiện đại, hiểu về nó giúp bạn nắm được nền tảng và sự tiến hóa của các mô hình sau này như V-Model và đặc biệt là Agile.

Đối với Kỹ sư QA, việc nắm vững các mô hình này không chỉ là kiến thức lý thuyết suông, mà là yếu tố then chốt để bạn hiểu rõ công việc của mình được thực hiện như thế nào, tương tác với ai và đóng góp vào quy trình chung ra sao. Ngày nay, Agile là mô hình chiếm ưu thế trong ngành công nghiệp phần mềm, và việc làm QA trong môi trường Agile đòi hỏi sự chủ động, linh hoạt và khả năng hợp tác cao.

Hy vọng bài viết này đã cung cấp cho bạn cái nhìn rõ ràng về ba mô hình SDLC quan trọng này. Việc tìm hiểu và áp dụng kiến thức này vào thực tế sẽ là một bước tiến quan trọng trên con đường trở thành một Kỹ sư QA chuyên nghiệp. Đừng quên theo dõi chuỗi “QA Engineer (Tester) Roadmap” để khám phá những kiến thức và kỹ năng cần thiết tiếp theo nhé!

Hẹn gặp lại trong bài viết tiếp theo!