Công ty mà bạn đang làm việc vừa tái cơ cấu các dự án theo mô hình Waterfall chuyển hết thành Agile? Trong tình huống đó, nếu là một QA, thì bạn có thể mong chờ điều gì? Để bắt đầu nói về vai trò của một QA trong mô hình Agile, trước hết có lẽ chúng ta nên bàn về những vai trò khác nhau trong những hệ phương pháp ăn theo Agile nhiều nhất như là XP và Scrum. Trong mô hình Agile, có 3 vai trò chính yếu: Scrum Master, Product Owner và Development Team.

Để bắt đầu nói về vai trò của một QA trong mô hình Agile, trước hết có lẽ chúng ta nên bàn về những vai trò khác nhau trong những hệ phương pháp ăn theo Agile nhiều nhất như là XP và Scrum. Trong mô hình Agile, có 3 vai trò chính yếu: Scrum Master, Product Owner và Development Team.

• Scrum Master là một trường nhóm (leader) của bên cung cấp dịch vụ, là người sẽ chỉ dẫn, lãnh đạo nhóm phát triển, giao tiếp với các bên liên quan (stakeholders), xử lí các chướng ngại của dự án và dọn đường cho team phát triển, ngoài ra cũng là một người quan sát và chỉnh đốn quy trình chuẩn, và hoạt động như một người hỗ trợ.
• Product Owner đóng vai trò cầu nối với khách hàng, phân tích yêu cầu và cho khách hàng tầm nhìn về sản phẩm, tạo ra và quản lí các thuộc tính cốt lõi của sản phẩm, và nắm giữ quyền đưa ra những quyết định quan trọng nhất về business của dự án.
• Development Team là một nhóm được tự chủ về mặt tổ chức, bao gồm nhiều người và thực hiện nhiều việc khác nhau với một mục đích duy nhất là "hoàn thành công việc". Chúng ta phải ghi chú ngay ở đây là không hề có một quy định chuẩn mực nào cho nhân sự của một Dev Team. Chính điều này dẫn đến việc nhiều người trong giới IT tin rằng một nhân sự QA chuẩn mực là không cần thiết trong một dự án Agile khi mà mọi việc có thể được hoàn thành chỉ bởi những thành viên còn lại. Dù vậy, hầu hết các Dev team theo mô hình Agile đều bao gồm các Kiến trúc sư hệ thống, Business Analysts, Lập trình viên, và QA Analysts. Sự phối hợp giữa QA và Development trong Agile là xóa bỏ ranh giới và nâng cao sự hợp tác trong môi trường làm việc. Khi người kiểm thử và nhà phát triển phần mềm hoạt động đồng bộ, bạn sẽ có thể tạo ra chất lượng công việc cao hơn trong thời gian ngắn hơn.

Vậy vai trò chính xác của QA trong agile là gì? Một tester có thể làm gì để giúp bắt đầu một mối quan hệ hợp tác với Development Team?

1. Giao tiếp / Tương tác / Hợp tác

Trong dự án theo mô hình Waterfall, một QA truyền thống phụ thuộc rất nhiều vào 3 thứ sau: Quy trình, Tài liệu, và Công cụ. Với 3 thứ này trong tay và sự chủ động tham gia vào dự án, bộ phận QA có thể kiểm thử sản phẩm đến tận các ngóc ngách sâu nhất, trên quy mô lớn để đảm bảo nó tuân thủ đúng các yêu cầu phát hành. Trong Agile, 3 thứ này mất đi tầm quan trọng vốn có bởi Agile ưu tiên các cá nhân và tương tác hơn là quy trình và công cụ, đề cao một phần mềm có thể hoạt động tốt hơn là một bộ tài liệu rõ ràng đầy đủ. Và sự tương tác giữa các team sẽ diễn ra trong các cuộc meeting, và cụ thể vai trò của QA trong các cuộc meeting để như sau:

• Trong Sprint Planning: QA hỗ trợ xác định phạm vi mục tiêu (scope) của sprint bằng cách đưa ra những tiêu chí chấp nhận cho kịch bản người dùng, dự kiến mức độ phức tạp của mỗi kịch bản, và làm rõ chi tiết một tập hợp các task dự trù cho từng kịch bản. Trong lúc Daily Stand-up, QA sẽ nêu ra những task nào đã hoàn thành hôm trước, task nào sẽ được tập trung xử lí trong hôm nay, và có những vấn đề trở ngại gì cần được giải quyết.
• Daily Stand-up: là hoạt động đều đặn tất yếu của một Sprint nơi mà cả team sẽ công bố tiến độ của mình và QA đóng một vai trò quan trọng bởi vì họ có thể xác định khi nào các kịch bản hoàn toàn hoàn thành, điều có ảnh hưởng rất lớn lên tiến độ tổng của team.
• Sprint Review: QA cũng nắm vai trò khá lớn trong Sprint Review. Thông thường thì QA sẽ là người chạy demo sản phẩm trong Sprint Review và sẽ cho khách hàng xem những chức năng được phát hành trong Sprint đó. Việc QA thể hiện được mức độ hiểu biết của mình về hệ thống và về mỗi kịch bản mà họ demo là rất quan trọng bởi vì nó chứng minh cho khách hàng và các bên liên quan biết rằng sản phẩm của họ đang thành hình theo đúng yêu cầu của họ.
• Sprint Retrospective: Trong các vòng đời phát triển hệ thống truyền thống, các hoạt động mổ xẻ sau dự án là lãnh địa riêng của QA team. Các QA team tập trung vào quy trình và phân tích xem cái gì hoạt động, cái gì không hoạt động, và gợi ý cách thức sửa chữa chúng. Trong Agile, việc review này là trách nhiệm của cả team trong Sprint Retrospective. Buổi họp này nên là nơi QA tỏa sáng bởi vì review lại quy trình chính là hoạt động mà QA đã gắn bó suốt thời gian trước đó.

2. Hội tụ QA và BA

Ở các team Scrum, chúng ta thường thấy trách nhiệm của QA và Bussiness Analyst (BA) bắt đầu hội tụ. BA thường chịu trách nhiệm cho việc tạo ra và duy trì các sprint và backlogs, phân tích những User Story từ quan điểm kinh doanh, và đánh giá độ ưu tiên cho các backlogs từ các dữ liệu đầu vào của Product Owner. Mặt khác, QA thường có trách nhiệm xác định / tinh chỉnh các tiêu chí chấp nhận cho mỗi User Story, kiểm tra các chức năng đã hoàn thành của mỗi Sprint từ quan điểm của end-user, và đảm bảo tất cả các chức năng hoàn thành trước đó không gặp các vấn đề khác. Khi QA kiểm tra mỗi User Story và xác minh các tiêu chuẩn chấp nhận đã được đáp ứng từ quan điểm của end-user, họ cũng đang phân tích những User Story từ quan điểm kinh doanh như là các BA. Nên, trong nhiều phương diện, QA và BA chia sẻ chung nhiều trách nhiệm, kỹ năng và mục tiêu chung. Thông thường, team Scrum nhận User Story của họ và phạm vi dự án được xác định trước từ Product Owner lúc bắt đầu một dự án. Tuy nhiên, team Scrum được khuyến khích đề xuất tính năng mới hoặc thay đổi các tính năng hiện tại nếu nó sẽ cải thiện trải nghiệm người dùng. Nhóm cũng được khuyến khích đề xuất thay đổi mức độ ưu tiên / trình tự của các User Stories trong backlogs khi họ thấy thực hiện theo một trật tự khác sẽ hiệu quả hơn. Cho dù là việc xác định yêu cầu, phân tích User Stories, xác định / làm rõ các tiêu chí chấp nhận, xây dựng trường hợp kiểm thử chấp nhận, hoặc làm việc chặt chẽ với khách hàng, ta có thể thấy vai trò của QA và BA đang hội tụ rõ ràng. Tuy vậy, việc QA và BA chia sẻ chung công việc với nhau chỉ mang lại lợi ích cho các nhóm nhỏ, còn đối với các nhóm lớn thì cần có sự phân định rõ ràng hai vai trò ở trên để tránh sự thắc mắc hoặc nhầm lẫn từ các thành viên trong team.

Trong các vòng đời phát triển hệ thống truyền thống, QA team chịu trách nhiệm cho việc cung cấp thường xuyên những báo cáo số liệu thống kê đầy đủ về tình trạng của dự án. Tuy nhiên, trong Agile, khi mà ưu tiên trên hết là sản phẩm hoạt động được chứ không phải là tài liệu chuẩn tắc, QA team sẽ không bắt buộc phải cung cấp các báo cáo số liệu chi tiết và dài dòng thường xuyên nữa. Scrum Master sẽ là người chịu trách nhiệm cung cấp các báo cáo đó cho team cùng với một bảng tiến độ của mỗi Sprint và một bảng tiến độ chung sẽ phản ánh tình trạng tổng thể của cả Dự án. Nếu QA team được yêu cầu làm các báo cáo chi tiết như vậy, hãy tìm tới Scrum Master và nói chuyện thẳng thắn về giá trị báo cáo đó cũng như việc giá trị đó có ảnh hưởng đến việc hoàn thành mục tiêu của Sprint hay không. Trong phần lớn trường hợp, các báo cáo hầu như không cung cấp được thông tin gì đáng kể hơn những gì đã được biết đến và kể cả nếu các báo cáo là cần thiết, thì việc thảo ra nó cũng là trách nhiệm của Scrum Master hơn là của QA team.

3. Kết luận

Những gì QA team phảil làm trong mô hình Agile không có khác biệt gì đáng kể so với trong các mô hình truyền thống; sự khác biệt nằm trong cách mà QA team hoàn thành nhiệm vụ của mình.

• QA team cần phải tập trung vào các quy trình, công cụ và tài liệu gọn gàng, linh hoạt - rất khác so với các mô hình truyền thống.
• Thứ nhì, QA team cần phải tập trung vào một môi trường làm việc hợp tác, tin cậy lẫn nhau và cùng phối hợp làm việc để gia tăng giá trị của team.
• QA team cần phải nắm chắc ý tưởng rằng, việc hoàn thành các nhiệm vụ sớm nhất có thể buộc họ phải luôn tự vấn giá trị mà mỗi nhiệm vụ mang lại. Nếu một đầu việc có ít giá trị hay không đẩy team tới gần mục tiêu chung hơn, thì hãy trao đổi với Scrum Master và cả team để quyết định xem đầu việc đó có nên bị loại bỏ hay không. Trên hết là, để trở thành một Agile QA năng suất chỉ yêu cầu một chút đào tạo lại về mục tiêu quan trọng nhất của dự án: nhanh chóng đạt được sản phẩm có chất lượng có thể phát hành.

Reference: https://www.softwaretestingmaterial.com/how-to-succeed-as-agile-qa/ https://techblog.vn/nghe-qa-trong-the-gioi-agile-end