Agile Scrum cho fresher tester: Daily standup, sprint và vai trò trong dự án thật

3 tháng trước · 9 phút đọc

Bối cảnh: Tester mới vào team Agile thường thấy gì?

Bạn mới nhận offer, ngày đầu tiên đi làm, sếp bảo: "9 giờ có daily standup, chiều có sprint review, cuối tuần có retrospective." Bạn gật đầu như đã hiểu, nhưng thực ra đang tự hỏi "mấy cái này là gì và mình phải làm gì trong đó?"

Mình đã qua giai đoạn đó. Tuần đầu ngồi họp mà không biết nói gì, sprint thứ hai mới dám phát biểu một câu, sprint thứ tư mới thật sự hiểu mình cần chuẩn bị gì trước mỗi buổi.

Bài này mình viết lại toàn bộ những gì tester cần biết để không bị "lạc nhịp" khi làm việc trong môi trường Agile Scrum - từ thuật ngữ tối thiểu cho đến việc bạn cần làm gì trong từng buổi họp.

344886 Agile không phức tạp - chỉ cần biết đúng vai trò của mình

Quan trọng nhất: Agile không phải quy trình cứng nhắc. Mỗi team làm hơi khác nhau. Bài này dùng Scrum làm nền, vì đây là framework phổ biến nhất bạn sẽ gặp khi đi làm.

Thuật ngữ tối thiểu cần biết trước khi vào team

Trước khi nói đến từng buổi họp, có một số từ bạn sẽ nghe đi nghe lại mỗi ngày. Không biết những từ này, bạn sẽ không theo kịp conversation.

Sprint - Một chu kỳ phát triển ngắn, thường 1-2 tuần (có team làm 3 tuần). Mỗi sprint team cam kết làm xong một số tính năng nhất định. Tester test trong sprint đó.

Backlog - Danh sách tất cả tính năng, bug, cải tiến cần làm. Có hai loại: Product Backlog (danh sách toàn bộ dự án) và Sprint Backlog (những việc được chọn để làm trong sprint này). Tester quan tâm nhiều hơn đến Sprint Backlog.

User Story - Cách team mô tả tính năng từ góc nhìn người dùng. Format thường là: "Là [ai], tôi muốn [làm gì], để [mục đích]." Ví dụ: "Là người mua hàng, tôi muốn lọc sản phẩm theo giá, để tìm hàng phù hợp túi tiền."

Acceptance Criteria (AC) - Tiêu chí chấp nhận. Đây là phần tester phải đọc kỹ nhất. AC định nghĩa "làm xong" nghĩa là gì với mỗi User Story. Nếu AC mơ hồ, hỏi ngay - đừng để đến lúc test mới phát hiện.

Definition of Done (DoD) - Thỏa thuận của cả team về điều kiện để gọi một task là "hoàn thành". Thường bao gồm: code review xong, unit test pass, tester sign-off. Tester có vai trò quan trọng trong bước sign-off này.

344887 Acceptance Criteria mơ hồ là nguồn gốc của 80% hiểu nhầm giữa dev và tester

Velocity - Tốc độ trung bình team hoàn thành công việc mỗi sprint, đo bằng Story Points (điểm ước lượng độ phức tạp). Bạn không cần lo về cái này nhiều ở giai đoạn fresher.

Scrum Master - Người faciliate (hỗ trợ) các buổi họp, remove blockers cho team. Không phải manager, không giao việc cho bạn.

Product Owner (PO) - Người quyết định ưu tiên, định nghĩa User Story và Acceptance Criteria. Khi có câu hỏi về yêu cầu business, hỏi PO hoặc BA (Business Analyst - hai vai trò này đôi khi trùng nhau).

Nắm được 7 khái niệm trên là đủ để bắt đầu. Những từ còn lại sẽ tự học trong quá trình làm.

Sprint planning: Buổi họp tester thường bị quên nhất

Sprint planning là buổi họp đầu mỗi sprint, team ngồi lại chọn User Story từ Product Backlog để đưa vào sprint này và ước tính effort.

Nhiều team không mời tester vào sprint planning, hoặc mời nhưng tester ngồi im. Đó là sai lầm. Tester có thể đóng góp rất nhiều trong buổi này.

Tester cần làm gì trong sprint planning?

Đọc Acceptance Criteria của từng User Story được đề xuất. Nếu thấy AC thiếu hoặc mơ hồ, raise ngay. Câu hỏi kiểu như:

"AC này chưa đề cập trường hợp user nhập dữ liệu sai - handle thế nào?"
"Tính năng này có test trên mobile không?"
"Performance requirement là gì - bao nhiêu giây là acceptable?"

Những câu hỏi này không phải phá đám. Đây chính xác là lý do tester nên có mặt trong sprint planning - phát hiện ambiguity trước khi dev bắt tay vào code.

344888 Hỏi sớm trong planning tiết kiệm hơn fix muộn sau release

Mình từng im lặng trong một sprint planning, không hỏi gì về AC của tính năng upload file. Kết quả: dev hiểu một cách, mình test theo cách khác, đến cuối sprint mới phát hiện. Mất thêm 2 ngày để clarify và test lại.

Ngoài ra, tester cũng nên ước tính effort cho công việc test. Đừng để dev ước tính thay. Bạn hiểu test case cần viết bao nhiêu, regression cần cover những gì - bạn mới là người ước tính chính xác nhất.

Refinement (còn gọi là Grooming) là buổi team ngồi lại để làm rõ các User Story chuẩn bị cho sprint tiếp theo - trước khi nó vào sprint planning.

Từ góc độ tester, đây là buổi quan trọng nhất. Lý do đơn giản: ở đây bạn có thể tác động vào yêu cầu, không phải chỉ nhận yêu cầu và đi test.

Tester cần chuẩn bị gì trước buổi refinement?

Đọc trước các User Story trong agenda. Ghi lại những câu hỏi về:

Edge cases: "Chuyện gì xảy ra nếu..."
Negative cases: "User nhập sai thì thông báo gì?"
Integration: "Tính năng này tương tác với module nào khác?"
Non-functional: "Load bao nhiêu request/second vẫn ổn?"

344889 Refinement tốt = ít bug sau release, không phải ngẫu nhiên

Trong buổi refinement, tester làm gì?

Đặt câu hỏi. Liên tục. Đây không phải buổi họp mà bạn ngồi nghe. BA hoặc PO trình bày User Story, dev hỏi về technical, tester hỏi về behavior và edge cases.

Nếu AC chưa rõ, đề xuất viết thêm. Nhiều team để tester tự viết test scenario ngay trong buổi refinement - đây là cách hay để đảm bảo AC cover đủ cases.

Bạn không cần nói nhiều. Nhưng 2-3 câu hỏi đúng chỗ có thể cứu cả sprint khỏi bug nghiêm trọng.

Daily standup: 15 phút mà tester hay không biết nói gì

Daily standup (hay daily scrum) diễn ra mỗi sáng, kéo dài đúng 15 phút. Mỗi người trả lời 3 câu:

Hôm qua làm gì?
Hôm nay làm gì?
Có blocker (vật cản) nào không?

Nghe đơn giản. Nhưng fresher tester hay bị lúng túng vì không biết nói gì cho "đúng format" và không lan man.

Cách tester nói trong daily - ví dụ cụ thể:

❌ Không nên: "Hôm qua mình test tính năng đăng nhập. Hôm nay test tiếp. Không có blocker."

✅ Nên nói: "Hôm qua mình hoàn thành test case cho US-12 (đăng nhập). Tìm được 2 bug, đã raise trên Jira - BUG-45 và BUG-46. Hôm nay mình bắt đầu test US-14 (quên mật khẩu). Blocker: đang chờ dev fix BUG-43 trước khi test được luồng thanh toán - Minh (dev) có thể fix trước 10h không?"

Sự khác biệt: version thứ hai nói rõ User Story ID, bug ID, và blocker cụ thể kèm người liên quan. Thông tin đó có ý nghĩa với cả team.

344890 Nêu blocker ngay trong standup, đừng để im đến chiều

Nguyên tắc vàng của daily:

Những gì bạn nói phải có ích cho cả team, không chỉ cho bản thân. Nếu có blocker mà không raise trong daily, team không biết để giúp - bạn tự mình làm chậm sprint.

Và một điều quan trọng: daily không phải buổi báo cáo cho sếp. Scrum Master faciliate, không đánh giá. Nói thật, nói thẳng, nói ngắn.

Sprint review: Tester có vai trò gì khi demo sản phẩm?

Sprint review là buổi cuối sprint, team demo những gì đã làm xong cho stakeholders (người liên quan, đôi khi là khách hàng). Mục tiêu: lấy feedback, xác nhận team đang đi đúng hướng.

Nhiều fresher tester nghĩ đây là buổi của dev - dev demo, tester ngồi xem. Không hẳn.

Tester đóng vai trò gì trong sprint review?

Thứ nhất, tester là người xác nhận tính năng đủ điều kiện để demo. Nếu một tính năng chưa pass test, nó không nên được demo cho stakeholders. Bạn có quyền (và trách nhiệm) nói: "US-15 vẫn còn bug critical, chưa sẵn sàng để demo."

Thứ hai, trong lúc demo, tester chú ý quan sát. Stakeholders có thể phát hiện behavior lạ mà bạn chưa test đến. Ghi chú lại, raise bug sau buổi nếu cần.

344891 Sign-off của tester là điều kiện để tính năng lên production

Thứ ba, đây là lúc tốt để nghe feedback về expected behavior. PO hoặc khách hàng nói "Ồ, mình tưởng nó hoạt động thế này" - thông tin đó có thể thay đổi AC cho sprint sau, và tester cần biết sớm.

Không cần phát biểu nhiều trong sprint review. Nhưng đừng ngồi im hoàn toàn - vai trò của bạn là quality gate, không phải khán giả.

Lửng Lọc Lõi