Vai trò của QA trong Agile - góc nhìn của một newbie

Bạn vừa nhảy từ một tập đoàn công nghệ chuyên làm những thứ hoành tráng như Microsoft xuống một công ty chuyên làm web và app như Framgia, hay 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.

• 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.

Giờ đây khi chúng ta đã phân tích sơ qua vai trò của QA trong mô hình Agile, hãy cùng điểm lại một vài nguyên tắc chính yếu của mô hình này và những ảnh hưởng của chúng lên vai trò của QA. Trong quá khứ, 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 đủ. Điều đó không có nghĩa là Agile loại trừ 3 yếu tố trên bởi vì Agile tập trung vào khả năng đáp ứng với thay đổi hơn là các kế hoạch, quy trình, tài liệu cứng nhắc, và các công cụ phải đủ linh hoạt để có thể khiến mô hình Agile hiệu quả và nhanh gọn. Nói thẳng ra, điều đó có nghĩa là quy trình, tài liệu và công cụ có thể bị loại bỏ khi cần thiết, chứ không phải khóa chặt ở đó mọi lúc mọi nơi. Việc thay đổi điểm nhìn của một QA trong mô hình Agile bắt buộc thậm chí những QA già dặn nhất phải thay đổi hướng tiếp cận quen thuộc của mình trong việc đảm bảo chất lượng từ mô hình phụ thuộc vào quy trình và tài liệu thành một mô hình gắn chặt với tương tác và khả năng thành phẩm. Hãy bàn về việc làm thế nào việc đảm bảo chất lượng áp dụng được mô hình tương tác và phát hành để đáp ứng những trách nhiệm mà nó kế thừa như là một phần của team Agile. Cụ thể hơn, cùng nói về vai trò của QA trong 4 loại meeting của Agile: Sprint Planning, Daily Stand-up, Sprint Review và Sprint Retrospective.

• 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.
• 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ọ.
• 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 đó.

Giờ thì cùng soi kĩ hơn xem những công việc hàng ngày của QA team trong môi trường Agile sẽ như thế nào nhé. Hầu hết các hoạt động đảm bảo chất lượng trong mô hình Agile đều KHÔNG KHÁC GÌ ở các mô hình khác. Agile QA team vẫn phân tích yêu cầu (gồm các kịch bản người dùng và tiêu chí chấp nhận), tạo test cases, thực hiện các test cases, tham gia vào quy trình xử lí bug và nghiên cứu cách để áp dụng automation test. Sự khác biệt của Agile QA đến từ cách mà các hoạt động kể trên diễn ra. Trong khi làm những việc đó, QA team không ngồi riêng biệt; họ ngồi cùng và hợp tác cùng với Dev team để hoàn thành nhiệm vụ càng hiệu quả càng tốt. Ví dụ, khi QA team phát hiện ra vấn đề, trách nhiệm của họ là triệu tập tất cả những chi tiết cần thiết và log lên một hệ thống quản lí bug nhưng trách nhiệm của họ còn mở rộng ra tới việc phải ngay lập tức nói chuyện với cả BA và Dev để chỉ ra vấn đề. Trong nhiều trường hợp, giải pháp cho vấn đề được xác định ngay trong cuộc thảo luận đó và toàn bộ team được thông báo về chi tiết sự thay đổi sớm nhất có thể. Mọi thứ mà QA team làm trong mô hình Agile được dựa trên một ý tưởng về vòng lặp phản hồi tức thì. Nếu mọi hoạt động của QA team làm trong mô hình Agile được dựa trên một ý tưởng về vòng lặp phản hồi tức thì, thì nhu cầu về số liệu chi tiết có còn quan trọng không? 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. Tóm lại, 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.

• Thứ nhất, 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.
• Cuối cùng, 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.