Agile Testing: Làm sao để test mà không stress?

1. 4 Giá trị cốt lõi của Agile (Agile Manifesto)

Nếu bạn thấy khó nhớ, thì hãy nhớ đến công thức:
“Con người trên quy trình, Hợp tác hơn hợp đồng, Phần mềm chạy được là vua, và Linh hoạt là chân ái.”

📌 Tester cần nhớ gì?

• Không phải cứ có tài liệu đầy đủ là test được ngay! Agile tester cần giao tiếp liên tục với dev, BA, PO để hiểu yêu cầu thực tế.
• Tập trung vào kiểm thử sản phẩm chạy được, không chỉ là xác nhận tài liệu.

2. 12 Quy tắc vàng trong Agile (Agile Principles)

Một số nguyên tắc quan trọng ảnh hưởng trực tiếp đến tester:

• Test sớm, test liên tục – Fix bug ở production đau hơn thất tình.
• Khách hàng là trung tâm – Feedback của họ giúp điều chỉnh test case đúng hướng.
• Phát hành thường xuyên – Tester phải đảm bảo Regression Test ổn định để không “toang” ở mỗi lần release.

3. 🤝 Whole-Team Approach – Đừng để Tester cô đơn!

Bạn đã bao giờ rơi vào tình huống này chưa?

🛠 Dev: “Tôi code xong rồi, test giúp tôi với!”
🧐 Tester: “Ủa, sao test case này fail rồi nè?”
🙃 Dev: “Thôi chết, để tôi sửa… mà cái này chắc không phải do code tôi đâu!”

Nếu bạn thấy quen thuộc, thì xin chúc mừng – bạn vừa trải nghiệm một quy trình làm việc đầy “căng thẳng” của mô hình truyền thống. Nhưng trong Agile, mọi thứ không diễn ra như vậy!

Whole-Team Approach là gì?

Agile Testing không phải là công việc của riêng Tester, mà là trách nhiệm chung của cả đội. Điều đó có nghĩa là:

✔ Dev không chỉ viết code, mà còn tham gia vào kiểm thử (code review, unit test).
✔ Tester không chỉ tìm bug, mà còn giúp phát hiện vấn đề ngay từ lúc phân tích yêu cầu.
✔ BA và PO làm việc chặt chẽ với Tester để đảm bảo hiểu đúng mong muốn của khách hàng.
✔ Scrum Master/PM hỗ trợ team duy trì môi trường làm việc hiệu quả, giúp Agile Testing diễn ra suôn sẻ.

💡 Ví dụ thực tế: Trong một sprint, Tester không phải chờ đến khi Dev hoàn thành rồi mới test. Ngay từ khi lập kế hoạch, Tester đã tham gia vào các buổi Three Amigos (Dev, BA, Tester) để hiểu rõ user story, xác định rủi ro, lên kế hoạch test sớm.

📌 Tóm gọn:
❌ Truyền thống: “Tester lo test, bug là do tester không test kỹ!”
✅ Agile: “Mọi người cùng nhau kiểm thử, cùng nhau đảm bảo chất lượng sản phẩm!”

4. 🔄 Early & Frequent Feedback – Test sớm, Test thường xuyên!

Bạn có biết rằng sửa một bug ở production có thể tốn chi phí gấp 100 lần so với sửa nó ngay từ giai đoạn thiết kế?

Tại sao phải kiểm thử sớm?

“Càng sớm, càng tốt!” – Nguyên tắc vàng trong Agile Testing. Nếu trong mô hình truyền thống, tester phải đợi đến cuối mới kiểm thử, thì trong Agile, kiểm thử diễn ra ngay từ khi user story còn là một ý tưởng trên giấy.

Lợi ích của kiểm thử sớm:
✔ Giảm thiểu rủi ro: Phát hiện bug sớm giúp giảm chi phí sửa lỗi.
✔ Hiểu đúng yêu cầu: Tránh trường hợp “Sếp nói A, team làm B, khách hàng muốn C”.
✔ Tăng tốc phát triển: Test liên tục giúp tránh việc dồn bug vào phút chót.

📌 Ví dụ thực tế:
Trong một dự án Scrum, Tester có thể tham gia ngay từ giai đoạn Backlog Grooming để giúp phân tích rủi ro, viết test case sớm, thậm chí áp dụng TDD (Test-Driven Development) hoặc ATDD (Acceptance Test-Driven Development) để đảm bảo yêu cầu rõ ràng trước khi Dev code.

5. 🏗 Aspects of Agile Approaches – Agile không chỉ có Scrum!

Nhiều người khi nhắc đến Agile thường chỉ nghĩ ngay đến Scrum, nhưng thực tế Agile có rất nhiều phương pháp khác nhau, mỗi phương pháp có ưu và nhược điểm riêng.

Một số phương pháp Agile phổ biến:

💡 Ví dụ thực tế: Một công ty phát triển sản phẩm phần mềm có thể áp dụng Scrum để lập kế hoạch và quản lý sprint, nhưng dùng Kanban để theo dõi lỗi và công việc đang làm trong nhóm Tester.

6. 🔥 User Story – Viết sao cho team hiểu và dev code không lệch?

User Story là gì?

User Story là cách diễn đạt yêu cầu ngắn gọn, dễ hiểu từ góc nhìn của người dùng.

📌 Cấu trúc của User Story:
“Là [loại người dùng], tôi muốn [chức năng] để có thể [giá trị nhận được].”

✅ Ví dụ:
“Là người dùng, tôi muốn có chức năng đặt hàng online để có thể mua sản phẩm mà không cần đến cửa hàng.”

🚀 Lợi ích của User Story:

• Giúp team tập trung vào nhu cầu của người dùng, không phải chỉ là đặc tả kỹ thuật.
• Dễ hiểu với tất cả mọi người (Dev, QA, PO, BA…).
• Linh hoạt và có thể thay đổi khi yêu cầu sản phẩm thay đổi.

3C – Công thức tạo User Story dễ hiểu, dễ làm!

Để User Story thực sự hiệu quả, bạn cần nhớ nguyên tắc 3C:

Ví dụ 3C thực tế:

• Card: “Là khách hàng, tôi muốn có chức năng thanh toán bằng thẻ để có thể mua hàng online tiện lợi hơn.”
• Conversation: PO, Dev, Tester họp với nhau để làm rõ các trường hợp đặc biệt (thẻ hết tiền, giao dịch lỗi…).
• Confirmation: Tester viết Acceptance Criteria như:
  • Khi nhập thẻ hợp lệ → Thanh toán thành công.
  • Khi nhập thẻ hết tiền → Hiển thị thông báo lỗi.

INVEST – Công thức đánh giá User Story có tốt không?

📌 Một User Story tốt phải tuân theo nguyên tắc INVEST:

Ứng dụng INVEST khi viết User Story:

• Nếu một User Story quá lớn (không Small), hãy chia nhỏ nó ra.
• Nếu một User Story không thể kiểm thử (không Testable), hãy thêm Acceptance Criteria.
• Nếu một User Story không mang lại giá trị (không Valuable), hãy xem xét có cần làm không.

🎯 Hãy nhớ: Viết User Story tốt không khó!

• 3C để đảm bảo User Story có thể giao tiếp, thảo luận và kiểm thử được.
• INVEST để đánh giá xem một User Story có tốt hay chưa.
• Luôn tập trung vào giá trị cho người dùng, chứ không chỉ là yêu cầu kỹ thuật.

7. Retrospective – Học từ quá khứ để tốt hơn!

Trong Agile, sau mỗi Sprint, team sẽ tổ chức Retrospective để nhìn lại những gì đã làm được và chưa làm được. Đây là thời điểm tester có thể đề xuất các cải tiến trong quy trình kiểm thử để giảm thiểu bug và tối ưu việc kiểm thử.

Mô hình 4 câu hỏi phổ biến trong Retrospective:

1. Chúng ta đã làm tốt điều gì?
2. Chúng ta có thể cải thiện điều gì?
3. Những cản trở nào cần loại bỏ?
4. Chúng ta sẽ thử nghiệm điều gì mới trong Sprint tiếp theo?

Tester cần làm gì trong Retrospective?

• Đề xuất cải tiến quy trình test.
• Chia sẻ các vấn đề gặp phải (ví dụ: thiếu thời gian kiểm thử, backlog test case ngày càng dài).
• Góp ý với Dev, BA về những yêu cầu chưa rõ ràng, dễ gây lỗi.

8. CI/CD là gì và tại sao Tester phải quan tâm?

💡 CI/CD (Continuous Integration & Continuous Deployment) giúp tự động hóa kiểm thử và phát hành phần mềm.

📌 Tester cần làm gì?

• Viết test automation để tích hợp vào pipeline CI/CD.
• Phối hợp với dev để đảm bảo test chạy ổn định.

9. Lập kế hoạch phát hành và vòng lặp (Release & Iteration Planning)

💡 Vì sao tester cần quan tâm?

• Nếu không tham gia từ đầu, tester có thể bị động, test không kịp.
• Xác định rủi ro kiểm thử ngay từ giai đoạn lập kế hoạch.

📌 Vai trò của tester trong lập kế hoạch
✅ Xác định phạm vi kiểm thử (Test Scope).
✅ Dự đoán các vấn đề tiềm ẩn (ví dụ: nếu release gấp, có thể bỏ qua một số test nào?).
✅ Đề xuất tài nguyên cần thiết (test data, môi trường test, automation test).

🚀 Agile Testing – Không chỉ là một phương pháp, mà là một tư duy!

Qua bài viết này, chúng ta đã cùng nhau khám phá những nền tảng cơ bản của Agile Testing – từ tư duy Whole-Team Approach, kiểm thử sớm và liên tục, đến các phương pháp Agile phổ biến như Scrum, Kanban, XP. Nhìn chung, Agile Testing không chỉ là một bộ kỹ thuật, mà là một cách tiếp cận linh hoạt để đảm bảo chất lượng phần mềm ngay từ khi nó chỉ là một ý tưởng trên giấy.

💡 Và đây mới chỉ là Mùa 1 của loạt blog về Agile Testing!

Ở Mùa 2, chúng ta sẽ tiếp tục đào sâu hơn vào sự khác biệt giữa kiểm thử trong mô hình truyền thống và Agile, hiểu về trạng thái kiểm thử trong dự án Agile, và đặc biệt là vai trò thực sự của một Agile Tester trong team. Nếu bạn còn thắc mắc “Làm tester trong Agile có khác gì so với truyền thống?”, hãy chờ đón những phân tích thú vị ở bài tiếp theo!

Bạn có câu hỏi hay chia sẻ gì về trải nghiệm của mình với Agile Testing không? Hãy để lại bình luận nhé! ⬇️🚀