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.
Agile – Scrum
Nhiều bạn mới rơi vào tình huống khi nghe tới Agile/Scrum nhưng hoang mang và không biết nó là gì? Và nghĩ nó là một công cụ. Bài này mình viết để bạn không phải hoang mang và bất ngờ.
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.
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.
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
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.
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?”
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.
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.
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
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ì?”
Bài viết khác
Agile là gì?
Agile thực chất là một triết lý hay một khung tư duy để nhanh chóng thích ứng và phản hồi với thay đổi, từ đó đạt được thành công trong một môi trường liên tục biến động và không chắc chắn. Dễ hiểu hơn thì Agile là một phương pháp luận và tư duy quản […]
Git là gì ?
Git là gì ? Git còn được gọi là Distributed Version Control System (DVCS) hay VCS, là một hệ thống quản lý phiên bản phân tán ra đời vào năm 2005. Git giúp lập trình viên theo dõi và lưu trữ các phiên bản khác nhau của mã nguồn. Điều đặc biệt của Git là […]
Git & GitHub – Đừng nhầm Git với GitHub
Git và GitHub Khi mới bắt đầu học lập trình, đặc biệt là khi làm việc với source code, chắc hẳn bạn đã từng nghe đến hai cái tên Git và GitHub. Và một trong nhưng hiểu lầm phổ biến nhất của người mới là cho rằng Git và GitHub là một. Nghe qua thì […]
Lỗi bảo mật Zero Day trên .net framework và Office kb4041083
Lỗi này khiến cho hacker có thể sử dụng các file office để chiếm quyền điều khiển máy tính windows
Cập nhật bản vá chống tấn công krack ( key reinstall attack ) trên windows 7,8,10
Phương thức tấn công krack key reinstall attack mới được phát hiện có thể hack toàn bộ mạng wifi toàn cầu. Người dùng có thể bị mất các thông tin quan trọng như tài khoản email, mật khẩu, thông tin ngân hàng, bị chiếm quyền điều khiển và thậm chí bị đánh cặp dữ liệu […]
Khoá học lập trình game con rắn cho trẻ em 
