Scrum là một quy trình quản lý và kiểm soát được áp dụng trong các dự án phát triển phần mềm giúp loại bỏ những công đoạn phức tạp và chỉ tập trung vào việc cung cấp các tính năng nghiệp vụ cốt lõi (Business features) trong thời gian phát triển ngắn từ 2-4 tuần. Đội Scrum có hai đặc tính rõ nét:

1. Đa kỹ năng: Các thành viên trong đội có tất cả các kỹ năng cần thiết để hoàn thành công việc.

2. Tự tổ chức: Các thành viên trong đội phải có kỹ năng tự tìm hiểu cũng như tổ chức bản thân để hoàn thành công việc một cách tốt nhất.
Sau khi làm việc trong gần hai năm với vai trò là kỹ sư đảm bảo chất lượng (Quality Assurance – QA) trong một nhóm Scrum, tôi nhận ra vai trò của QA trong nhóm Scrum không chỉ dừng lại ở việc viết các trường hợp kiểm thử (test cases) và báo cáo lỗi (bugs reporting).

Đối nghịch với các hoạt động đồng bộ của mô hình Thác nước (Waterfall) truyền thống, các hoạt động phát triển của Scrum diễn ra theo thứ tự không đồng nhất. Việc phá vỡ sự phát triển đồng nhất đặt ra câu hỏi chung cho các khách hàng (Clients), đội ngũ lập trình viên (Developers) và các bên liên quan – những người lần đầu tham gia vào mô hình Agile: “Làm thế nào đội ngũ QA có thể kiểm tra sản phẩm trong suốt một Sprint ngay cả trước khi ứng dụng được dựng lên?”. Bài chia sẻ này tập trung vào việc giải thích vai trò quan trọng của QA trong mô hình Agile và trong một nhóm Scrum, chúng đến từ những gì tôi đã học được trong suốt quá trình làm việc tại vị trí QA trong những năm vừa qua.

Không đơn thuần chỉ là viết Test Cases

Trong mô hình phát triển Waterfall, QA chỉ bắt tay vào công việc tại thời điểm gần cuối của dự án, khi giai đoạn lập trình đã hoàn tất. Thông thường, các QA sẽ nhận được một bộ tài liệu đặc tả yêu cầu (Requirements document) và một ứng dụng gần như hoàn chỉnh, để dựa vào đó, QA sẽ viết và thực thi các Test Cases nhằm đảm bảo ứng dụng hoạt động đúng với những gì được đặc tả. Tuy nhiên, vai trò QA trong mô hình Scrum là một khái niệm hoàn toàn khác.

Trong một nhóm Scrum, QA tham gia và thực hiện một loạt các công việc ngay từ đầu cùng với các kỹ sư phân tích yêu cầu (Business Analyst) và các Developers. Như đã đề cập ở trên, Scrum yêu cầu tất cả các thành viên trong đội phải là những người đa kỹ năng, cho nên các QA đôi khi cũng giúp người nắm giữ sản phẩm (Product Owner) viết các Test Cases cho kiểm thử chấp nhận (Acceptance Test) trên vai trò của chính Product Owner. Việc này sẽ giúp thúc đẩy tiến độ phát triển của cả nhóm ngay cả khi Product Owner không có mặt tại thời điểm đó. Ngoài ra QA cũng có thể đặt ra những câu hỏi và đưa ra các tình huống giả định cho Product Owner để làm rõ các yêu cầu nghiệp vụ (Business requirements).

Ước lượng cho các User Stories

QA rất giỏi trong việc tạo ra các tình huống kiểm thử đứng trên vai trò của người dùng. Họ cũng rất xuất sắc trong việc nhận định và nắm bắt các trường hợp kiểm thử phức tạp có khả năng sinh ra lỗi rất cao. Có QA trong giai đoạn lập kế hoạch (Planning) là một lợi thế khá lớn, vì trong khi các Developers tập trung nhiều hơn vào các luồng happy path của User Stories, các QA sẽ đưa ra các luồng unhappy path để việc ước lượng (Estimation) cho các User Stories trở nên chính xác hơn rất nhiều (do có cả happy lẫn unhappy path), giảm thiểu tình trạng làm thêm giờ (Overtime work) khi Sprint đã được bắt đầu. Ước lượng luôn là một công việc khó nhưng độ chính xác sẽ cao hơn rất nhiều khi cả nhóm Scrum đều tham gia vào công việc này.

Giúp tầm nhìn và mục tiêu của dự án được rõ ràng

Khi cả nhóm làm việc trong suốt quá trình testing cũng như các công việc khác, QA nên đi đầu trong việc lập kế hoạch, tổ chức team vào trong các hoạt động testing và giữ “lửa” cho tất cả các thành viên. Vì rất ít các Developers thích thú với công việc testing cho nên QA, cùng với Scrum Master, phải làm cho tầm nhìn và mục tiêu testing được rõ ràng và giúp giữ vững và nâng cao tinh thần cho các đồng nghiệp. Nó có thể đến từ nhiều cách và không nhất thiết phải gò bó vào một khuôn khổ. Ví dụ: những kịch bản testing thú vị, những dữ liệu testing hài hước, các cuộc thi nhỏ mang tính chất khích lệ, v.v.

Cộng tác với Clients và Developers

Một trong những trách nhiệm chính của QA là đưa ra cũng như thu thập những phản hồi cho Product Owner. QA sẽ phối hợp rất chặt chẽ với Product Owner để giúp họ phát triển các tiêu chí chấp nhận cho các User story. Dựa vào những bài học rút ra trong suốt mỗi Sprint, QA có thể giúp Product Owner chỉnh sửa cũng như cải tiến các User Story sẵn có để mô tả chính xác các yêu cầu.
Đôi khi, QA cũng sẽ được yêu cầu thay thế vai trò cho Product Owner. Lúc này, QA và Developers sẽ ngồi lại để nâng cao chất lượng của dự án bằng cách viết những test cases cho kiểm thử đơn vị (Unit test) và trao đổi về tiêu chí chấp nhận. Bằng cách này, các yêu cầu sẽ trở nên rõ ràng hơn, giảm thiểu số lượng câu hỏi và thắc mắc đến từ Developers trong suốt quá trình coding, đồng thời nâng cao hiệu quả và tiết kiệm thời gian/chi phí cho cả đội Developers lẫn QA.
Toàn bộ nhóm nên sẵn sàng tham gia hỗ trợ công việc testing bất cứ khi nào dựa trên nhu cầu và sự sẵn có của các thành viên trong nhóm. Việc này cũng giúp tạo sự cân bằng trong nhóm và nâng cao tinh thần chia sẻ trách nhiệm để hoàn thành công việc. Nó cũng giúp tăng tốc độ làm việc với những phản hồi đến từ việc testing sớm cũng như gia tăng chất lượng của dự án.

Phản hồi nhanh chóng

Chu kỳ phát triển – kiểm thử – sửa lỗi trong mô hình Waterfall truyền thống tốn rất nhiều thời gian cũng như công sức cho cả nhóm khi sự lặp lại của nó dường như là vô tận. Chu kỳ này đơn giản hơn rất nhiều trong Scrum khi QA và Developers làm việc cùng nhau trong suốt cả dự án. Developer có thể hỏi ý kiến của QA về các tiêu chí chấp nhận hoặc kết quả mong đợi của bất kì tính năng nào trên phương diện người dùng một cách nhanh chóng, giúp tiết kiệm rất nhiều thời gian và loại bỏ rất nhiều lượt sửa lỗi.

Kiểm thử tự động

Sự ổn định, hiệu suất cao và độ bao phủ lớn là những ưu điểm không thể chối cãi của kiểm thử tự động (Automation Testing). Điều này luôn đúng trong một dự án Scrum nơi chu kỳ của một sprint chỉ từ 2 tới 4 tuần, vốn rất hạn chế thời gian testing của QA. Trong suốt 2 tuần đó, QA phải thực hiện kiểm thử hồi quy (Regresion Test) cho tất cả các tính năng đã hoàn thiện trước đó. Và điều này trở nên kinh khủng hơn khi mà cứ mỗi sprint qua đi, số lượng tính năng lại càng nhiều thêm. Automation testing là cứu cánh cho các QA trong trường hợp này.
Automation testing rất hữu ích khi nó liên tục phản hồi kết quả testing khi team thiết lập các công cụ Tích hợp liên tục (Continuous Integration). Cứ mỗi khi có một build mới, automation test lại được thực thi và lập tức trả những kết quả kiểm tra những tính năng mới cũng như những tính năng đã hoàn thiện trước đó có hoạt động đúng hay không. Nếu không có automation testing, QA phải làm những công việc này một cách thủ công một cách nhàm chán và dễ sai sót. Automation Testing còn giúp phát hiện lỗi sớm và cho phép các QA có thêm thời gian để thực hiện test các khía cạnh liên quan của chức năng đó.

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!


References: https://viblo.asia