Vai trò của Kỹ sư QA trong các Phương pháp Phát triển Agile: Scrum, Kanban, XP và SAFe

Xin chào các bạn! Chào mừng các bạn quay trở lại với chuỗi bài viết “Roadmap Lộ trình học Kỹ sư QA (Tester) 2025”. Ở những bài trước, chúng ta đã cùng nhau tìm hiểu về Đảm bảo Chất lượng (QA) là gì, cách phát triển tư duy của một người kiểm thử, các kỹ thuật kiểm thử cơ bản như Black Box, White Box, Gray Box, và một cái nhìn tổng quan về các mô hình SDLC phổ biến như Waterfall, V-Model và Agile.

Ngày nay, mô hình Agile đã trở thành phương pháp phát triển phần mềm phổ biến nhất trong ngành công nghiệp. Với tính linh hoạt, khả năng phản hồi nhanh với thay đổi và sự tập trung vào việc mang lại giá trị liên tục, Agile đã thay đổi cách các đội làm việc. Nhưng chính xác thì vai trò của Kỹ sư QA (Tester) trong môi trường Agile này là gì? Nó có khác biệt nhiều so với các mô hình truyền thống không? Làm thế nào chúng ta có thể đóng góp hiệu quả trong các framework Agile cụ thể như Scrum, Kanban, Extreme Programming (XP) và Scaled Agile Framework (SAFe)?

Bài viết này sẽ đi sâu vào trả lời những câu hỏi đó, giúp các bạn, đặc biệt là các bạn QA mới, hiểu rõ hơn về vị trí và tầm quan trọng của mình trong thế giới Agile năng động.

Agile và Sự Thay Đổi Đối với QA

Nhắc lại một chút từ bài viết về SDLC, Agile đề cao sự tương tác giữa các cá nhân và quy trình hơn là các công cụ, phần mềm chạy được hơn là tài liệu đầy đủ, hợp tác với khách hàng hơn là đàm phán hợp đồng, và phản hồi với thay đổi hơn là tuân thủ kế hoạch. Điều này tạo ra một sự chuyển dịch lớn so với các mô hình tuần tự như Waterfall, nơi kiểm thử thường là một giai đoạn riêng biệt diễn ra ở cuối chu kỳ phát triển.

Trong Agile, chất lượng không phải là trách nhiệm riêng của đội QA ở cuối dự án. Chất lượng được xây dựng vào từng bước của quy trình, từ khi bắt đầu cho đến khi hoàn thành. Vai trò của QA trong Agile chuyển từ việc “tìm lỗi” ở cuối chu kỳ sang việc “ngăn ngừa lỗi” ngay từ đầu và “đảm bảo chất lượng” xuyên suốt quá trình.

Điều này đòi hỏi Kỹ sư QA Agile phải:

• Tích cực cộng tác với các thành viên khác trong đội (Developer, BA, PO…).
• Hiểu rõ yêu cầu và mục tiêu kinh doanh ngay từ sớm.
• Tham gia vào việc định nghĩa “Hoàn thành” (Definition of Done).
• Thực hiện kiểm thử liên tục và cung cấp phản hồi nhanh chóng.
• Đóng góp vào việc cải tiến quy trình của đội.

Sự thay đổi này có thể ban đầu gây thách thức, nhưng cũng mở ra nhiều cơ hội để Kỹ sư QA có tác động lớn hơn đến chất lượng sản phẩm cuối cùng.

Vai trò của Kỹ sư QA trong Scrum

Scrum là framework Agile phổ biến nhất. Scrum tổ chức công việc thành các chu kỳ ngắn gọi là “Sprint” (thường từ 1-4 tuần). Mỗi Sprint nhằm mục đích tạo ra một Increment (phần tăng trưởng) có khả năng phát hành.

Trong Scrum, không có vai trò “Tester” hay “QA” riêng biệt chính thức trong mô hình gốc. Tất cả thành viên trong đội phát triển (Development Team) đều chia sẻ trách nhiệm tạo ra Increment. Tuy nhiên, trên thực tế, hầu hết các đội Scrum đều có các chuyên gia kiểm thử là một phần không thể thiếu của Development Team.

Vai trò của QA trong một đội Scrum bao gồm:

1. Tham gia vào Lập kế hoạch Sprint (Sprint Planning)

• Hiểu rõ các mục tiêu của Sprint (Sprint Goal) và các Product Backlog Items (PBI) sẽ được đưa vào Sprint.
• Tham gia vào việc ước lượng công việc (Estimation) của các PBI, bao gồm cả công sức cho việc kiểm thử.
• Đặt câu hỏi để làm rõ yêu cầu, xác định các tiêu chí chấp nhận (Acceptance Criteria).
• Lập kế hoạch kiểm thử sơ bộ cho Sprint.

Ví dụ, khi thảo luận về một tính năng “Đăng nhập”, QA sẽ đặt câu hỏi về các trường hợp thành công, thất bại (sai mật khẩu, sai username), các ràng buộc (độ dài tối thiểu mật khẩu), các kịch bản đặc biệt (tài khoản bị khóa), và làm thế nào để kiểm thử hiệu quả những điều này trong thời gian Sprint.

2. Tham gia vào Họp Hàng ngày (Daily Scrum)

• Chia sẻ tiến độ công việc kiểm thử đã hoàn thành, công việc sẽ làm tiếp theo.
• Thông báo các trở ngại (Impediments) ảnh hưởng đến việc kiểm thử (ví dụ: môi trường test chưa sẵn sàng, bug chặn test).
• Đồng bộ hóa với Developer để biết khi nào các phần công việc sẵn sàng để kiểm thử.

3. Thực hiện Kiểm thử trong Sprint

Đây là hoạt động cốt lõi. QA không chờ đến cuối Sprint. Ngay khi Developer hoàn thành một phần công việc và đã tự kiểm thử đơn vị (Unit Test), QA sẽ bắt đầu kiểm thử tích hợp (Integration Test), kiểm thử hệ thống (System Test), kiểm thử hồi quy (Regression Test) trong phạm vi Sprint.

• Thực hiện kiểm thử theo các tiêu chí chấp nhận đã thống nhất.
• Phát hiện và báo cáo lỗi kịp thời.
• Làm việc chặt chẽ với Developer để gỡ lỗi.
• Kiểm thử lại các lỗi đã được sửa.
• Góp phần vào việc tự động hóa kiểm thử (nếu có).

4. Đóng góp vào Định nghĩa Hoàn thành (Definition of Done – DoD)

DoD là một tập hợp các tiêu chí mà một PBI phải đáp ứng để được coi là “Hoàn thành”. QA đóng vai trò quan trọng trong việc định nghĩa DoD, đảm bảo các khía cạnh chất lượng được xem xét. DoD có thể bao gồm:

- Code đã được Review.
- Unit Tests đã được viết và pass.
- Acceptance Criteria đã được kiểm thử thủ công và pass.
- Automated Acceptance Tests đã được viết và pass.
- Documentation đã được cập nhật.
- Không có bug P0, P1 còn tồn đọng.
- Đã triển khai lên môi trường Staging/Integration.

5. Tham gia vào Đánh giá Sprint (Sprint Review)

• Cùng với đội demo Increment cho Stakeholders.
• Giúp trả lời các câu hỏi liên quan đến chất lượng hoặc cách hoạt động của tính năng.
• Thu thập phản hồi về chất lượng sản phẩm.

6. Tham gia vào Cải tiến Sprint (Sprint Retrospective)

• Chia sẻ những gì đã làm tốt, những gì chưa tốt từ góc độ kiểm thử.
• Đề xuất các hành động cải tiến quy trình làm việc, đặc biệt là các hoạt động liên quan đến chất lượng và kiểm thử.

Trong Scrum, QA là một thành viên toàn diện của đội, không phải là một cổng kiểm soát ở cuối. Sự chủ động, giao tiếp tốt và khả năng làm việc đa nhiệm (testing, viết test case, automation, phân tích yêu cầu) là rất quan trọng.

Vai trò của Kỹ sư QA trong Kanban

Kanban khác với Scrum ở chỗ nó không có các chu kỳ cố định (Sprint) và không có các sự kiện (events) cố định như Planning, Review. Kanban tập trung vào việc hình dung luồng công việc (Work In Progress – WIP), giới hạn WIP và tối ưu hóa luồng để giảm thời gian chu kỳ (Cycle Time).

Trong môi trường Kanban, vai trò của QA thường tập trung vào việc trở thành một phần của luồng công việc liên tục (Continuous Flow). Thay vì kiểm thử theo Sprint, QA kiểm thử ngay khi một hạng mục công việc (Work Item) sẵn sàng di chuyển sang cột kiểm thử trên bảng Kanban.

Vai trò của QA trong Kanban bao gồm:

1. Trở thành một phần của Luồng Công việc

• Công việc của QA (ví dụ: “Kiểm thử Tính năng X”) được coi là một bước trong luồng từ lúc yêu cầu đến khi “Xong” (Done).
• QA kéo các Work Item vào cột kiểm thử ngay khi chúng sẵn sàng, không chờ đợi.
• Mục tiêu là giữ cho luồng công việc di chuyển trơn tru, không bị tắc nghẽn tại bước kiểm thử.

2. Giảm thiểu Thời gian Chờ đợi tại bước Kiểm thử

• Nếu bước kiểm thử thường xuyên bị tắc nghẽn (Work In Progress ở cột Test quá cao), QA cần làm việc với đội để hiểu nguyên nhân (ví dụ: thiếu môi trường, cần thêm người, công việc đến quá dồn dập).
• Tìm cách tối ưu hóa quy trình kiểm thử, có thể thông qua tự động hóa hoặc cải thiện môi trường.

3. Kiểm thử Liên tục

• Thực hiện kiểm thử chức năng, kiểm thử hồi quy,… ngay khi Work Item hoàn thành giai đoạn phát triển.
• Cung cấp phản hồi nhanh chóng cho Developer để sửa lỗi kịp thời, giữ cho lỗi không bị tích tụ.

4. Đóng góp vào Cải tiến Quy trình (Kaizen)

• Kanban đề cao cải tiến liên tục. QA tham gia vào các cuộc họp định kỳ (ví dụ: Kanban Meeting) để thảo luận về các nút thắt cổ chai (bottlenecks) và tìm cách cải thiện luồng công việc.
• Đóng góp ý kiến về cách tổ chức công việc để việc kiểm thử trở nên hiệu quả hơn.

5. Đảm bảo Chất lượng được Xây dựng trong Luồng

• Giống như trong Scrum, QA làm việc với đội để định nghĩa các tiêu chí chất lượng ở từng bước.
• Thúc đẩy các thực hành “Shift-Left Testing” (đưa kiểm thử về sớm hơn trong quy trình) ngay cả khi không có Sprint cố định.

Trong Kanban, sự chủ động trong việc kéo công việc, khả năng xử lý nhiều hạng mục nhỏ và liên tục, cùng với việc tập trung vào hiệu quả luồng công việc là những yếu tố then chốt đối với Kỹ sư QA.

Vai trò của Kỹ sư QA trong Extreme Programming (XP)

Extreme Programming là một framework Agile với các thực hành kỹ thuật rất mạnh mẽ, tập trung vào việc mang lại phần mềm chất lượng cao một cách nhanh chóng. Các thực hành cốt lõi của XP bao gồm Pair Programming (Lập trình cặp), Test-Driven Development (TDD), Continuous Integration (CI), Refactoring (Tái cấu trúc code), và Customer On-site (Khách hàng làm việc trực tiếp với đội).

Trong XP, vai trò của QA (hoặc người kiểm thử) thường được tích hợp sâu sắc đến mức ranh giới giữa Developer và Tester có thể mờ đi. QA làm việc cực kỳ chặt chẽ với Developer.

Vai trò của QA trong XP bao gồm:

1. Cộng tác Sâu sắc và Lập trình Cặp (Pair Programming/Testing)

• Một trong những thực hành mạnh mẽ nhất là việc Tester làm việc theo cặp với Developer (Pair Testing hoặc thậm chí Pair Programming).
• Tester có thể ngồi cùng Developer khi họ viết code, đưa ra các trường hợp kiểm thử, suy nghĩ về các kịch bản lỗi ngay lập tức.
• Ngược lại, Developer cũng có thể hỗ trợ Tester trong việc tự động hóa hoặc gỡ lỗi môi trường test.

2. Phát triển Dẫn dắt bởi Kiểm thử Chấp nhận (Acceptance Test-Driven Development – ATDD)

• Trong XP, các tiêu chí chấp nhận thường được viết dưới dạng các bài kiểm thử chấp nhận (Acceptance Tests) trước khi code được viết.
• QA làm việc với Customer (hoặc Product Owner) và Developer để định nghĩa các Acceptance Tests này. Chúng thường được viết bằng một ngôn ngữ dễ hiểu cho cả kỹ thuật và kinh doanh (ví dụ: Gherkin).
• Sau đó, Developer sẽ viết code sao cho các Acceptance Tests này पास (pass).

Ví dụ về một Acceptance Test (using Gherkin):

Feature: Tìm kiếm sản phẩm

  Scenario: Người dùng tìm kiếm sản phẩm tồn tại
    Given tôi đang ở trang chủ
    When tôi nhập "laptop" vào ô tìm kiếm
    And nhấn Enter
    Then tôi thấy danh sách các sản phẩm có tên "laptop"
    And số lượng sản phẩm lớn hơn 0

QA giúp định nghĩa, viết và sau đó tự động hóa các bài kiểm thử này. Chúng trở thành “đặc tả sống” của hệ thống.

3. Tự động hóa Kiểm thử là Cốt lõi

• Với thực hành TDD (Developer viết Unit Test trước) và ATDD (Đội viết Acceptance Test trước), tự động hóa kiểm thử không phải là một lựa chọn mà là một yêu cầu bắt buộc.
• QA đóng vai trò dẫn dắt hoặc tham gia mạnh mẽ vào việc xây dựng và duy trì bộ kiểm thử tự động ở các cấp độ khác nhau (Unit, Integration, Acceptance, UI…).
• Bộ kiểm thử tự động này chạy liên tục nhờ Continuous Integration.

4. Tích hợp Liên tục (Continuous Integration – CI) và Phản hồi Nhanh

• Mỗi khi code mới được commit, hệ thống CI sẽ tự động build và chạy toàn bộ bộ kiểm thử (bao gồm cả Unit Tests và Automated Acceptance Tests).
• Nếu bất kỳ kiểm thử nào thất bại, cả đội sẽ nhận được phản hồi ngay lập tức. QA giúp phân tích nguyên nhân thất bại của các Acceptance Tests hoặc Integration Tests.
• Phản hồi nhanh giúp phát hiện và sửa lỗi chỉ vài phút hoặc vài giờ sau khi chúng được đưa vào, giảm thiểu chi phí sửa lỗi.

Trong XP, QA không chỉ là người kiểm thử, mà là người đồng tạo ra chất lượng ngay từ đầu. Sự am hiểu kỹ thuật để làm việc cùng Developer và tham gia vào tự động hóa là cực kỳ quan trọng.

Vai trò của Kỹ sư QA trong Scaled Agile Framework (SAFe)

SAFe là một framework được thiết kế để mở rộng các nguyên tắc và thực hành Agile cho các tổ chức lớn, bao gồm nhiều đội Agile làm việc trên các sản phẩm, giải pháp phức tạp. SAFe hoạt động ở nhiều cấp độ (Team, Program, Large Solution, Portfolio).

Trong SAFe, vai trò của QA tồn tại ở các cấp độ khác nhau và đòi hỏi sự phối hợp lớn hơn.

1. Cấp độ Đội (Team Level)

• Giống như trong Scrum hoặc XP, QA trong đội SAFe thực hiện các hoạt động kiểm thử trong các Iteration (tương tự Sprint) và đóng góp vào Định nghĩa Hoàn thành của đội.
• Thúc đẩy các thực hành Lean-Agile Quality Practices như BDD/ATDD, Test Automation, Exploratory Testing trong đội.

2. Cấp độ Chương trình (Program Level)

Nhiều đội Agile tạo thành một Agile Release Train (ART), là một tập hợp các đội phối hợp để mang lại giá trị lớn hơn trong các chu kỳ gọi là Program Increments (PI – thường kéo dài 8-12 tuần).

• QA tham gia vào Lập kế hoạch PI (PI Planning), nơi các đội đồng bộ hóa, lập kế hoạch và cam kết cho PI tiếp theo. QA giúp xác định các rủi ro liên quan đến chất lượng và phụ thuộc giữa các đội.
• Tham gia vào các sự kiện đồng bộ hóa cấp độ ART (ví dụ: Scrum of Scrums, PO Sync) để phối hợp các hoạt động kiểm thử liên đội.
• Đóng góp vào việc định nghĩa và thực hiện các kiểm thử tích hợp cấp độ Chương trình.
• Tham gia vào System Demo (Demo hệ thống tích hợp của toàn bộ ART) ở cuối mỗi Iteration và ở cuối PI.
• Thúc đẩy “Quality In” xuyên suốt ART, không chỉ trong từng đội.

3. Cấp độ Giải pháp Lớn (Large Solution Level – nếu có)

Đối với các giải pháp cực kỳ phức tạp đòi hỏi nhiều ART, có cấp độ Large Solution.

• QA làm việc với các đội và ART khác để phối hợp kiểm thử tích hợp và kiểm thử end-to-end cho toàn bộ giải pháp.
• Tham gia vào Solution Demo và các sự kiện đồng bộ hóa cấp Solution.

4. Cấp độ Danh mục Đầu tư (Portfolio Level – ít trực tiếp hơn)

• Ở cấp độ này, QA có thể đóng góp vào việc định nghĩa các tiêu chuẩn chất lượng chung cho toàn tổ chức, các chỉ số chất lượng (metrics) cấp cao.

Trong SAFe, QA không chỉ lo cho đội mình mà còn phải nhìn bức tranh lớn hơn, phối hợp kiểm thử giữa các đội và ART, đảm bảo chất lượng được duy trì khi mở rộng quy mô. Khả năng giao tiếp và phối hợp ở nhiều cấp độ là rất quan trọng.

So Sánh Vai Trò QA qua các Framework Agile

Mặc dù có những điểm khác biệt, tất cả các framework Agile đều nhấn mạnh sự cần thiết của QA trong việc đảm bảo chất lượng liên tục. Dưới đây là bảng so sánh tóm tắt:

Điểm Chung của QA trong Mọi Môi Trường Agile

Dù làm việc trong Scrum, Kanban, XP hay SAFe, có những nguyên tắc và thực hành chung mà một Kỹ sư QA Agile hiệu quả cần nắm vững:

1. Shift-Left Testing

Đưa các hoạt động kiểm thử và đảm bảo chất lượng về sớm hơn trong quy trình. Tham gia vào giai đoạn thu thập yêu cầu, phân tích, thiết kế để tìm và ngăn ngừa lỗi ngay từ đầu.

2. Tự động hóa Kiểm thử (Test Automation)

Đây không còn là một kỹ năng “có thì tốt” mà là “phải có”. Trong môi trường Agile tốc độ cao, việc lặp lại kiểm thử hồi quy thủ công là không khả thi. Tự động hóa ở các cấp độ (Unit, API, UI) là chìa khóa để cung cấp phản hồi nhanh và duy trì chất lượng. Các bạn có thể xem lại bài viết về các kỹ thuật kiểm thử để thấy sự liên quan của tự động hóa với các kỹ thuật này.

3. Cộng tác và Giao tiếp

Làm việc chặt chẽ với Product Owner, Business Analyst, Developer, và các thành viên khác trong đội/ART. Giao tiếp rõ ràng, minh bạch về trạng thái kiểm thử, các rủi ro và vấn đề chất lượng.

4. Tập trung vào Giá trị Kinh doanh

Hiểu rõ mục tiêu kinh doanh và ưu tiên kiểm thử dựa trên rủi ro và giá trị mà tính năng mang lại. Đảm bảo rằng các kịch bản quan trọng nhất đối với người dùng cuối và doanh nghiệp được kiểm thử kỹ lưỡng.

5. Tư duy Chất lượng (Quality Mindset)

Trở thành người ủng hộ chất lượng cho toàn đội, không chỉ là người thực thi kiểm thử. Giúp đội hiểu tại sao chất lượng lại quan trọng và làm thế nào để xây dựng chất lượng ngay từ đầu. Hãy nhớ lại bài viết về phát triển tư duy QA.

6. Phản hồi Liên tục

Cung cấp phản hồi sớm và thường xuyên về chất lượng cho đội và các bên liên quan. Điều này giúp đưa ra quyết định kịp thời và sửa chữa vấn đề trước khi chúng trở nên lớn hơn.

Thách Thức và Cơ Hội

Làm QA trong Agile không phải lúc nào cũng dễ dàng. Thách thức bao gồm:

• Áp lực về tốc độ: Phải kiểm thử nhanh chóng trong các chu kỳ ngắn.
• Thay đổi liên tục: Yêu cầu có thể thay đổi trong Sprint hoặc trong luồng.
• Đòi hỏi kỹ năng đa dạng: Cần hiểu biết về kỹ thuật, công cụ tự động hóa, cũng như kỹ năng mềm về giao tiếp và cộng tác.
• Đảm bảo kiểm thử hồi quy: Với code thay đổi liên tục, việc đảm bảo các tính năng cũ vẫn hoạt động là rất quan trọng.

Tuy nhiên, cơ hội cũng rất lớn:

• Có tác động lớn hơn: Tham gia vào toàn bộ vòng đời phát triển, không chỉ ở cuối.
• Cộng tác chặt chẽ: Xây dựng mối quan hệ tốt hơn với Developer và các thành viên khác.
• Phản hồi nhanh: Nhìn thấy kết quả công việc của mình được đưa đến người dùng nhanh chóng.
• Phát triển kỹ năng: Cơ hội học hỏi về tự động hóa, CI/CD, và các khía cạnh kỹ thuật khác.
• Trở thành một chuyên gia chất lượng thực thụ: Không chỉ là người tìm lỗi, mà là người định hình và thúc đẩy chất lượng sản phẩm.

Kết Luận

Vai trò của Kỹ sư QA trong môi trường Agile là vô cùng quan trọng và đã thay đổi đáng kể so với các mô hình truyền thống. Dù bạn đang làm việc trong đội Scrum, Kanban, XP hay SAFe, sự đóng góp của bạn không chỉ giới hạn ở việc thực thi test case. Bạn là người đồng hành cùng đội, giúp xây dựng chất lượng vào sản phẩm từ những giai đoạn sớm nhất.

Để trở thành một Kỹ sư QA Agile xuất sắc, hãy tập trung vào việc nâng cao kỹ năng cộng tác, học hỏi về tự động hóa kiểm thử, trau dồi tư duy phân tích và không ngừng tìm cách cải tiến quy trình làm việc của đội mình.

Hy vọng bài viết này đã cung cấp cho các bạn một cái nhìn rõ nét về vai trò của mình trong thế giới Agile. Đây là một phần không thể thiếu trong hành trình Roadmap Lộ trình học Kỹ sư QA (Tester) 2025 của bạn.

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