Agile Scrum cơ bản cho Tester: Sprint, Daily Standup và vai trò thực tế trong dự án
16 giờ trước · 12 phút đọc
Mình từng không hiểu "Sprint" là gì suốt 2 tuần đầu đi làm
Hồi mới vào công ty đầu tiên, ngày đầu tiên mình được dẫn vào phòng họp lúc 9 giờ sáng. Mọi người đứng vòng tròn, mỗi người nói 3 câu rồi giải tán. Mình không hiểu gì cả - đây là họp gì? Sprint là gì? Tại sao không ai ngồi?
Nhiều bạn fresher tester rơi vào tình huống tương tự: vào công ty Agile mà chưa ai giải thích Agile là gì. Bài này mình viết để bạn không bị bất ngờ như mình.
Agile là một cách làm việc, không phải công cụ. Thay vì lên kế hoạch 6 tháng rồi làm, team Agile chia nhỏ công việc thành các vòng ngắn - thường 2 tuần - gọi là Sprint. Mỗi Sprint kết thúc, team có sản phẩm chạy được để demo và nhận phản hồi.
Scrum là framework (khung làm việc) phổ biến nhất trong Agile. Scrum quy định rõ: ai làm gì, họp gì, họp khi nào. Đây là thứ bạn sẽ gặp ở hầu hết công ty IT Việt Nam hiện nay.
Agile không phải lý thuyết - mỗi Sprint kết thúc là có sản phẩm thật để test
Tại sao Agile phù hợp với testing? Vì bug được phát hiện sớm hơn. Thay vì chờ 3 tháng mới test, bạn test liên tục mỗi 2 tuần. Bug nhỏ ở Sprint 1 dễ fix hơn bug phát hiện sau khi cả hệ thống đã build xong. Mình đã chứng kiến dự án Waterfall (làm tuần tự) mà tester chỉ được test ở giai đoạn cuối - áp lực kinh khủng, bug nhiều, deadline cận kề.
Scrum có 3 vai trò chính: Product Owner (PO) - người quyết định làm tính năng gì, Scrum Master - người hỗ trợ team làm việc đúng quy trình, và Development Team - bao gồm dev, tester, BA. Tester thuộc Development Team, không đứng ngoài nhìn vào.
Sprint là gì và tại sao tester cần hiểu rõ vòng đời Sprint
Sprint là khoảng thời gian cố định - thường 2 tuần - để team phát triển một tập tính năng xác định. Sprint không bao giờ kéo dài hoặc rút ngắn giữa chừng. Ngày kết thúc Sprint là ngày kết thúc, dù xong hay chưa.
Một Sprint điển hình có 4 sự kiện chính:
Sprint Planning (họp đầu Sprint, 2-4 tiếng): Team ngồi lại chọn user story từ Product Backlog - danh sách tính năng mà PO đã ưu tiên - và cam kết làm xong trong Sprint này. Đây là lúc tester cần tham gia tích cực, không phải ngồi im.
Daily Standup (họp hằng ngày, tối đa 15 phút): Mỗi người trả lời 3 câu. Chi tiết ở phần dưới.
Sprint Review (cuối Sprint, 1-2 tiếng): Demo sản phẩm cho PO và stakeholder xem. Tester thường hỗ trợ demo hoặc confirm tính năng nào đã pass.
Sprint Retrospective (sau Review, 1 tiếng): Team nhìn lại Sprint vừa rồi - làm tốt gì, làm chưa tốt gì, cải thiện gì. Không phải buổi trách móc, mà buổi cải tiến.
Bốn sự kiện này lặp lại mỗi 2 tuần - hiểu vòng này là hiểu Scrum
Lịch trình một Sprint 2 tuần trông như thế này:
- Ngày 1 (Thứ Hai): Sprint Planning - chọn việc làm
- Ngày 2-9: Dev code, tester viết test case và test song song
- Ngày 8-9: Test execution mạnh nhất, bug report liên tục
- Ngày 10 (Thứ Sáu tuần 2): Sprint Review - demo, rồi Retrospective
Lý do bạn cần hiểu vòng này: tester không chờ dev code xong mới bắt đầu làm. Ngay từ Sprint Planning, bạn đã phải đọc user story, hỏi câu hỏi, và bắt đầu lên kế hoạch test. Nếu chờ đến ngày 8 mới đọc requirement thì không đủ thời gian test kỹ.
Daily Standup: 15 phút mỗi sáng và tester nói gì
Daily Standup (kiểm tra nhanh hằng ngày) là buổi họp ngắn nhất nhưng nhiều người mới nhất hay lúng túng. Đứng, không ngồi - để họp ngắn thôi.
Mỗi người trả lời đúng 3 câu:
- Hôm qua làm gì?
- Hôm nay làm gì?
- Có vấn đề gì chặn không? (blocker)
Câu thứ 3 quan trọng nhất. Nếu bạn đang bị chặn - chờ dev fix bug, chờ môi trường test, chờ PO confirm requirement - nói ra ngay. Scrum Master sẽ giúp unblock. Giữ im lặng chờ tự giải quyết là cách làm mất thời gian của cả team.
Tester nói gì trong Daily Standup?
Ví dụ thực tế:
"Hôm qua mình test xong user story US-12 (tính năng đăng nhập Google), pass 8/10 test case, report 2 bug lên Jira: BUG-45 và BUG-46. Hôm nay mình test tiếp US-13 (quên mật khẩu). Hiện không có blocker."
Hoặc khi có blocker:
"Hôm qua test US-14, phát hiện môi trường staging bị lỗi database không connect được. Hôm nay chờ DevOps fix môi trường mới test tiếp. Blocker: cần DevOps hỗ trợ trước 10 giờ sáng."
Nói blocker ngay - đừng chờ tự giải quyết vì có thể mất cả ngày
Một lưu ý: Daily Standup không phải buổi báo cáo chi tiết cho manager. Không cần giải thích dài dòng tại sao bug xảy ra hay cách fix thế nào. Những thảo luận kỹ thuật sâu để sau standup, riêng với người liên quan.
Thấy lúng túng lần đầu là hoàn toàn bình thường. Mình cũng run run lần đầu đứng nói trước team. Sau vài ngày quen format, bạn sẽ nói tự nhiên không cần chuẩn bị.
Sprint Planning: Tester cần làm gì trong buổi họp quan trọng nhất
Sprint Planning là buổi họp mà nhiều tester mới nghĩ "dev và PO họp, mình ngồi nghe cho biết". Sai hoàn toàn.
Trong Sprint Planning, team đọc từng user story - mô tả tính năng theo góc nhìn người dùng, kiểu "Là user, tôi muốn đặt lại mật khẩu qua email để có thể đăng nhập lại khi quên". PO giải thích ý định, team đặt câu hỏi, rồi cam kết làm trong Sprint.
Tester cần hỏi gì trong Sprint Planning?
Hỏi về acceptance criteria (tiêu chí chấp nhận):
- "Email reset password có hết hạn sau bao lâu?"
- "Nếu user nhập email không tồn tại thì thông báo gì?"
- "Reset password có yêu cầu mật khẩu mới phải khác mật khẩu cũ không?"
Những câu hỏi này tưởng nhỏ nhưng ảnh hưởng trực tiếp đến test case. Nếu không hỏi lúc này, đến lúc test bạn sẽ phải đoán hoặc test xong rồi PO nói "không phải ý tôi".
Hỏi sớm trong Planning giúp bạn viết test case đúng ngay từ đầu
Hỏi về môi trường và dữ liệu test:
- "User story này cần dữ liệu test gì? Mình cần tạo account mẫu không?"
- "Tính năng này có dùng email thật không hay có email sandbox?"
Ước tính effort cho testing: Trong nhiều team, tester cũng tham gia ước tính (estimation) - thường dùng Story Points. Bạn cần cho ý kiến: "Tính năng này có nhiều edge case, mình cần ít nhất 2 ngày test". Đừng im lặng rồi sau bị thiếu thời gian.
Mình từng không hỏi gì trong Sprint Planning vì sợ hỏi câu ngớ ngẩn. Kết quả: viết test case xong mới biết thiếu 4 acceptance criteria, phải viết lại gần hết. Lần sau mình hỏi đủ - dù câu hỏi có "ngớ" thì vẫn hỏi.
Bạn không cần hiểu hết technical detail của dev. Nhiệm vụ của bạn là hiểu tính năng hoạt động thế nào từ góc nhìn người dùng và khi nào thì tính năng được coi là đúng.
Vai trò của tester trong Sprint: Làm gì từ ngày 1 đến ngày 10
Nhiều fresher nghĩ tester chờ dev code xong mới bắt đầu. Trong Scrum, không phải vậy.
Ngày 1-2 (sau Sprint Planning): Đọc kỹ user story và acceptance criteria. Bắt đầu viết test case (kịch bản kiểm thử). Hỏi BA (Business Analyst) hoặc PO những điểm chưa rõ. Chuẩn bị dữ liệu test.
Ngày 3-7: Dev đang code, tester viết tiếp test case và có thể test những phần dev đã xong. Nhiều team làm việc theo kiểu "dev xong phần nào, tester test phần đó" - gọi là testing liên tục (continuous testing). Không cần chờ toàn bộ tính năng hoàn chỉnh.
Ngày 7-9: Test execution (thực thi kiểm thử) - chạy test case, ghi kết quả pass/fail, viết bug report cho mỗi lỗi tìm được. Đây là giai đoạn bận nhất của tester.
Ngày 9-10: Test closure (đóng kiểm thử) - tổng hợp kết quả, xác nhận bug đã fix, chạy kiểm thử hồi quy (regression testing) - tức test lại các tính năng cũ để đảm bảo code mới không làm hỏng thứ đang hoạt động.
Tester bận nhất ở ngày 7-9 - đừng để dồn hết vào ngày cuối
Bug report viết thế nào trong Agile?
Bug report trong Scrum ngắn gọn hơn nhưng vẫn cần đủ thông tin để dev reproduce (tái hiện lỗi). Tối thiểu cần:
- Title: "[US-12] Đăng nhập Google - không redirect về trang trước đó sau khi login"
- Steps to reproduce: Bước 1, 2, 3 cụ thể
- Expected result: Đáng lẽ phải ra gì
- Actual result: Thực tế ra gì
- Severity: Critical / Major / Minor
- Screenshot/Video: Đính kèm bắt buộc
Mình luôn đính kèm screenshot và video ngắn cho mỗi bug. Lý do: dev không phải lúc nào cũng ngồi cạnh bạn để hỏi thêm. Bug report tự nói được, dev reproduce được ngay, fix nhanh hơn. Không đủ thông tin = mất 1-2 ngày qua lại clarify.
Sprint Review và Retrospective: Tester tham gia thế nào
Sprint Review là buổi demo cuối Sprint. Team show sản phẩm cho PO và đôi khi cho khách hàng xem. Tester thường:
- Confirm danh sách tính năng nào đã pass, nào còn bug chưa fix
- Hỗ trợ demo bằng cách chuẩn bị môi trường và dữ liệu test sạch
- Nếu PO hỏi "tính năng X có vấn đề không?", tester là người trả lời chính xác nhất
Không phải tester đứng demo, nhưng bạn là người nắm rõ nhất chất lượng của Sprint này.
Sprint Retrospective là buổi nhìn lại nội bộ team. Scrum Master thường hỏi:
- "Sprint này chúng ta làm tốt gì?"
- "Chúng ta cần cải thiện gì?"
- "Action item cụ thể cho Sprint tới là gì?"
Tester có nhiều thứ giá trị để đóng góp ở đây. Ví dụ:
- "Mình thấy requirement hay thay đổi giữa Sprint, gây khó khăn cho việc viết test case. Cần fix acceptance criteria sớm hơn trong Planning."
- "Bug report mình viết nhưng dev hay hỏi lại, có thể team mình thống nhất template bug report không?"
Retrospective không phải buổi phàn nàn - là nơi tester đề xuất cải tiến quy trình
Mình nhớ Sprint Retrospective đầu tiên, mình chỉ ngồi im vì nghĩ "tester mới góp gì được". Scrum Master hỏi thẳng: "Bạn thấy quy trình test có vấn đề gì không?" Mình nói thật: "Mình hay nhận requirement muộn, không đủ thời gian viết test case". Tuần sau PO chủ động gửi user story draft sớm hơn 2 ngày.
Những feedback từ tester về quy trình testing thường rất thiết thực. Đừng bỏ qua buổi Retrospective vì nghĩ mình chưa đủ kinh nghiệm để nói.
Tóm lại, tester không phải người ngồi ngoài chờ dev xong. Trong Scrum, bạn tham gia từ đầu Sprint đến cuối Sprint, từ câu hỏi acceptance criteria đến bug report, từ test execution đến feedback quy trình.