Nghề QA trong thế giới Agile (End)

Tham gia vào các buổi họp Sprint/Demo sản phẩm

Tại thời điểm cuối của mỗi Sprint, nhóm sẽ tổ chức một buổi họp Sprint Review để trình bày các User Stories đã hoàn thành cho Product Owner và các bên liên quan khác. Cuộc họp này khuyến khích việc trình bày của tất cả thành viên trong nhóm và động viên họ hoàn thành càng nhiều User Stories càng tốt.

Với chu kỳ từ 2-4 tuần cho mỗi Sprint, tất cả các thành viên trong nhóm cần phải tập trung trong công việc để hoàn thành chúng đúng hạn. Trong khi developers bận rộn với những User Stories và sửa lỗi thì QA cũng “ngập đầu” trong Test Cases, trả lời câu hỏi từ Product Owner và kiểm thử tự động các Stories của sprint trước. Chu kỳ ngắn đồng nghĩa với việc Developers có ít thời gian hơn để khám phá những chức năng đã hoàn thiện của chính User Stories mà họ đang làm. Cho nên, Developer thường xuyên tham khảo ý kiến với QA để hiểu rõ hơn về các Stories mà họ đang làm đồng thời cùng với QA thực hiện demo trong buổi Sprint Review, giúp giải phóng Developers khỏi những câu hỏi kỹ thuật không cần thiết.

Phân tích yêu cầu người dùng

QA là Product Owner ủy quyền của nhóm Scrum. QA khá thuần thục trong việc hiểu các yêu cầu kinh doanh từ quan điểm của người sử dụng (End-user) vì họ luôn được yêu cầu sử dụng ứng dụng như người dùng cuối. QA có thể giúp cung cấp thông tin phản hồi cho Product Owner dựa trên kinh nghiệm kiểm thử của họ và có thể giúp Product Owner hiểu được ứng dụng từ quan điểm của người sử dụng cuối.

Thi hành Định nghĩa hoàn thành (Definition of Done)

Có một bản Định nghĩa hoàn thành (Definition of Done) luôn rất quan trọng với Scrum team. Một Định nghĩa hoàn thành không gì khác ngoài một danh sách các tiêu chí cần phải xong trước khi User Story hoàn thành. Danh sách này thường bao gồm những việc như viết code, kiểm thử chức năng, kiểm thử hồi quy và nhận được sự chấp thuận từ Product Owner. Một Definition of Done (DoD) đơn giản bao gồm: • Hoàn thiện code • Hoàn tất Unit test • Hoàn tất kiểm thử chức năng/UI • Chấp thuận từ Product Owner

Tuy không phải là trách nhiệm của QA trong việc tạo DoD, nhưng QA cần phải kiểm soát tiến độ công việc của cả team để mỗi User Story hoàn thiện đều phù hợp với với DoD. Một team Scrum hiệu quả sẽ xem lại DoD trước khi bắt đầu một User Story mới để biết chắc họ biết được những gì đang được mong đợi từ phía Product Owner lẫn khách hàng.

Luôn luôn lập kế hoạch với chiến lược kiểm thử

Khi không có một test lead hoặc cả một team test trong mô hình Scrum, việc xây dựng một test plan hoặc bám theo một chiến lược test cụ thể nào đó có thể là một vấn đề trong Scrum team. Scrum tin rằng việc chuẩn bị đủ tài liệu sẽ hỗ trợ các nhu cầu trước của cả team. Như vậy, QA sẽ chuẩn bị đủ tài liệu cấp cao cho các chiến lược và kế hoạch test để hướng dẫn nhóm. Vì không có QA Lead trong Scrum, các QA thường quyết định các chiến lược test.

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.

Kết luận

Trong khi QA vẫn tiếp tục viết các trường hợp test và báo cáo lỗi, họ cũng hỗ trợ nhiều vai trò và trách nhiệm khác nhau trong dự án. Họ là một thành phần quan trọng trong nhóm và tham gia vào nhóm ngay từ ban đầu. Làm việc trong vai trò QA trong nhóm Scrum trong bốn năm vừa qua là một trải nghiệm tuyệt vời và học hỏi được rất nhiều thứ. Tôi đã đảm đương nhiều vai trò và trách nhiệm khác nhau trong suốt quá trình đó và nó đã giúp tôi hoàn thiện nhiều kỹ năng. Và quan trọng nhất, tôi đã hiểu cách đặt câu hỏi hơn là việc chỉ đi theo tài liệu và làm mọi thứ để giúp cho team thành công!