Đang tải...

Lửng Lọc Lõi

Đeo kính để soi Bug cho rõ, nhíu mày để nhắc Dev sửa cho kỹ. Với tôi, 'chạy được' thôi là chưa đủ! 🧐💻


0

Agile vs Waterfall cho Tester: Nên học gì trước khi xin việc?

Lửng Lọc Lõi
Lửng Lọc Lõi

7 tháng trước · 14 phút đọc

Agile và Waterfall khác nhau ở đâu?

Bạn đang chuẩn bị xin việc tester và nhà tuyển dụng hỏi: "Bạn có kinh nghiệm làm việc theo Agile không?" Câu trả lời của bạn lúc này là gì?

Nếu bạn còn mơ hồ, bài này viết đúng cho bạn. Mình sẽ không giải thích theo kiểu sách giáo khoa - mình sẽ chỉ bạn thấy hai phương pháp này khác nhau thế nào trong thực tế làm việc hằng ngày của tester.

342137 Hai luồng làm việc hoàn toàn khác nhau - một cái thẳng, một cái xoay vòng

Waterfall (thác nước) là mô hình tuyến tính: mỗi giai đoạn hoàn thành xong mới sang giai đoạn tiếp theo. Yêu cầu → Thiết kế → Phát triển → Kiểm thử → Ra mắt. Tester chỉ tham gia ở giai đoạn kiểm thử, sau khi dev đã code xong toàn bộ.

Agile thì khác hoàn toàn. Thay vì làm 6 tháng mới có gì để test, team chia nhỏ công việc thành các Sprint (vòng lặp ngắn, thường 2 tuần). Trong mỗi Sprint, tester làm song song với dev - vừa code vừa test, phát hiện bug sớm hơn nhiều.

Hiện nay {{fact:fact_0}} công ty phần mềm tại Việt Nam áp dụng Agile hoặc Scrum. Con số này cho thấy học Agile trước không phải là lựa chọn - đó là bắt buộc nếu muốn xin được việc.


Bảng so sánh Agile và Waterfall cho tester

Mình biết đọc lý thuyết dài dòng rất khó nhớ. Xem bảng này - mình chắt lọc đúng những gì tester cần phân biệt.

342138 In bảng này ra, ôn trước buổi phỏng vấn là đủ

Tiêu chí Waterfall Agile/Scrum
Khi nào test? Sau khi dev code xong hết Song song với dev, trong từng Sprint
Thời gian Sprint Không có Sprint, theo phase 1-4 tuần (thường 2 tuần)
Tài liệu test Test plan đầy đủ, chi tiết User story, acceptance criteria
Họp hành Ít họp, chủ yếu theo milestone Daily Standup mỗi sáng, Sprint Review, Retrospective
Phát hiện bug Muộn (cuối dự án) Sớm (trong Sprint)
Thay đổi yêu cầu Khó thay đổi giữa chừng Linh hoạt, mỗi Sprint điều chỉnh được
Tester làm việc với ai? Chủ yếu với QA lead Cả team: dev, BA, product owner
Phù hợp dự án nào? Dự án lớn, yêu cầu cố định (ngân hàng, chính phủ) Startup, app mobile, web platform

Nhìn vào cột "Khi nào test?", bạn thấy sự khác biệt lớn nhất: Waterfall để tester "đợi" đến cuối mới vào, Agile cho tester tham gia từ đầu.

Hệ quả? Dự án Waterfall có thể ra mắt sau 12 tháng mới phát hiện bug lớn. Dự án Agile phát hiện bug trong 2 tuần Sprint - chi phí fix thấp hơn nhiều.


Tester làm gì trong một Sprint Agile?

Đây là phần quan trọng nhất. Biết lý thuyết chưa đủ - bạn cần biết cụ thể tester làm gì mỗi ngày trong Sprint để trả lời phỏng vấn một cách thuyết phục.

Mình lấy ví dụ Sprint 2 tuần tại một công ty fintech ở Hà Nội đang xây dựng app ví điện tử.

Ngày 1-2: Sprint Planning

Toàn team ngồi lại lên kế hoạch cho Sprint. Tester đọc các user story - ví dụ: "Là người dùng, tôi muốn nạp tiền bằng thẻ ATM để thanh toán" - và bắt đầu viết test case ngay từ lúc này. Không đợi dev code xong mới viết.

Viết test case sớm giúp gì? Phát hiện yêu cầu mù ("Nếu ATM hết hạn thì sao? Nhập sai OTP 3 lần thì khoá tài khoản hay báo lỗi?"). Tester đặt câu hỏi này trước khi dev code, tránh fix sau tốn công hơn.

342139 Sprint 2 tuần: tester tham gia từ đầu đến cuối, không chỉ ngồi đợi dev

Ngày 3-8: Sprint Execution

Dev code tính năng nào xong trước, tester test ngay tính năng đó - không đợi toàn bộ hoàn thành. Cách này gọi là continuous testing (kiểm thử liên tục).

Bug tìm được? Raise lên Jira, gắn tag cho dev liên quan, theo dõi trạng thái fix. Tester trong Agile thường tự quản lý bug tracker, không cần QA lead duyệt từng bước.

Ngày 9: Sprint Review

Team demo tính năng đã làm cho product owner (người đại diện khách hàng). Tester tham gia để xác nhận feature chạy đúng theo acceptance criteria trước khi demo.

Ngày 10: Retrospective

Cả team nhìn lại Sprint vừa xong: cái gì tốt, cái gì cần cải thiện. Tester có thể nêu: "Lần này test case viết chậm vì yêu cầu chưa rõ - Sprint sau mình cần thêm thời gian refinement."


Daily Standup là gì và tester nói gì trong đó?

Daily Standup (còn gọi là Daily Scrum) là cuộc họp đứng 15 phút mỗi sáng. Đứng - không phải ngồi - đúng nghĩa đen để ai cũng muốn họp nhanh cho xong.

Mỗi người trả lời 3 câu hỏi:

  1. Hôm qua mình đã làm gì?
  2. Hôm nay mình sẽ làm gì?
  3. Có vướng mắc gì không?

Ví dụ tester trả lời:

"Hôm qua mình test xong flow nạp tiền ATM, tìm được 2 bug và đã raise lên Jira. Hôm nay mình sẽ test tiếp flow rút tiền và viết test case cho tính năng lịch sử giao dịch. Không có vướng mắc gì."

342140 15 phút mỗi sáng - ngắn nhưng giữ cả team đi đúng hướng

Nhiều bạn mới học lo lắng: "Họp mỗi ngày nghe có vẻ nhiều quá." Thật ra 15 phút thôi. Quan trọng hơn, họp này giúp bạn biết dev đang làm gì để ưu tiên test đúng thứ trước.

Mình từng gặp tình huống dev code xong tính năng từ chiều hôm trước nhưng quên báo - tester không biết, sáng hôm sau mới test, mất nửa buổi. Có Daily Standup, tình huống này không xảy ra nữa.


Ví dụ thực tế: Tester trong dự án Việt Nam

Mình kể 2 tình huống thực tế - một Waterfall, một Agile - để bạn thấy sự khác biệt rõ hơn.

Tình huống 1: Waterfall - Dự án phần mềm quản lý bệnh viện

Dự án cho một bệnh viện tuyến tỉnh tại miền Trung, timeline 8 tháng. Yêu cầu rõ ràng từ đầu, ít thay đổi. Tester nhận được bộ tài liệu đặc tả dày 200 trang, viết test case theo đó, test toàn bộ hệ thống sau tháng thứ 6.

Đây là Waterfall điển hình - phù hợp vì yêu cầu của bệnh viện cố định, quy trình phê duyệt kỹ lưỡng, không thể "thử nghiệm" trên môi trường thật.

Tình huống 2: Agile - Startup app đặt xe nội địa

Một startup Hà Nội ra mắt app đặt xe cạnh tranh với Be, Grab. Sprint 2 tuần, team 8 người gồm 3 dev, 1 tester, 1 BA, 1 product owner, 1 designer, 1 scrum master.

342141 Startup Việt thường chạy Agile vì cần ra tính năng nhanh và thay đổi liên tục

Tester trong team này làm gì? Mỗi Sprint ra 2-3 tính năng nhỏ: "đặt xe", "theo dõi tài xế", "thanh toán ví". Tester test xong trong Sprint, bug được fix ngay trước khi Sprint kết thúc. Không có chuyện tích bug đến cuối dự án mới xử lý.

Sau 3 tháng (6 Sprint), app ra mắt bản beta với core features đã test kỹ. Nếu dùng Waterfall, 3 tháng chưa có gì để test.

Bài học: Không có mô hình nào "tốt hơn tuyệt đối". Tester giỏi biết cả hai, và biết mô hình nào phù hợp với dự án nào.


Glossary: Thuật ngữ Agile/Scrum tester cần biết

Bạn thấy khó nhớ các thuật ngữ này bình thường lắm. Mình cũng mất gần một tuần mới nhớ hết khi mới vào nghề. Bookmark phần này lại, ôn trước khi phỏng vấn là đủ.

342142 Học thuật ngữ trong context thực tế dễ nhớ hơn học thuần lý thuyết

Sprint - Vòng làm việc ngắn, thường 1-4 tuần. Mỗi Sprint có đầu ra cụ thể (tính năng chạy được, không phải tài liệu).

Scrum - Một framework (khung làm việc) triển khai Agile. Có quy định rõ về vai trò, sự kiện, artifact.

Scrum Master - Người đảm bảo team làm việc đúng quy trình Scrum, gỡ vướng cho team. Không phải quản lý dự án.

Product Owner (PO) - Người đại diện cho khách hàng, quyết định tính năng nào ưu tiên.

User Story - Yêu cầu tính năng viết theo góc nhìn người dùng. Ví dụ: "Là người dùng, tôi muốn nhận thông báo khi tài xế đến để không phải chờ đợi."

Acceptance Criteria - Điều kiện để user story được coi là "hoàn thành". Tester dùng acceptance criteria để viết test case.

Sprint Backlog - Danh sách công việc cần làm trong một Sprint.

Product Backlog - Toàn bộ tính năng cần làm của cả dự án, do PO quản lý.

Definition of Done (DoD) - Tiêu chí để một task được coi là xong. Ví dụ: code đã review, test đã pass, deploy lên staging thành công.

Velocity - Tốc độ làm việc của team, đo bằng số story points hoàn thành mỗi Sprint.

Story Point - Đơn vị đo độ phức tạp của task, không phải giờ làm việc.

Retrospective - Họp cuối Sprint để team nhìn lại: tốt gì, chưa tốt gì, cải thiện gì.

Tải glossary đầy đủ ở đây để dùng khi ôn phỏng vấn: {{resource:resource_0}}


Cách trả lời phỏng vấn: "Bạn biết Agile không?"

Câu hỏi này xuất hiện trong {{fact:fact_1}} buổi phỏng vấn tester tại Việt Nam. Đây là câu mà nhiều bạn trái ngành trả lời chung chung, mất điểm không đáng.

Mình chia sẻ cách trả lời theo 3 cấp độ kinh nghiệm.

Nếu bạn chưa có kinh nghiệm thực tế (fresher):

"Mình chưa có cơ hội làm việc trong môi trường Agile thực tế, nhưng mình đã tự học về Scrum framework - biết về Sprint 2 tuần, Daily Standup, Sprint Review và Retrospective. Mình hiểu tester trong Agile phải viết test case sớm từ user story, test song song với dev và tham gia họp Scrum đầy đủ. Mình rất muốn được thực hành thực tế tại công ty."

Trả lời thế này tốt hơn nhiều so với "Có, mình biết Agile" rồi im lặng.

342143 Phỏng vấn thật ra kiểm tra tư duy, không chỉ thuộc định nghĩa

Nếu bạn đã có dự án thực hành/internship:

"Mình có làm dự án nhỏ theo mô hình Agile - team 4 người, Sprint 1 tuần. Mình phụ trách viết test case từ user story, test tính năng khi dev code xong từng phần, và tham gia Retrospective để cải thiện quy trình. Trong Sprint đầu mình hay viết test case muộn, từ Sprint 2 mình điều chỉnh: viết test case ngay khi Sprint Planning xong."

Câu trả lời có ví dụ cụ thể + bài học rút ra - nhà tuyển dụng thích điều này.

3 điều tuyệt đối không nói trong phỏng vấn:

  • ❌ "Agile là làm việc linh hoạt" (quá chung chung)
  • ❌ "Mình chưa biết Agile" (thừa nhận không chuẩn bị)
  • ❌ "Agile thì không cần tài liệu" (sai - vẫn cần, chỉ nhẹ hơn)

Không cần nhớ thuộc lòng mọi thuật ngữ trước khi đi phỏng vấn. Hiểu luồng làm việc thực tế + có 1-2 ví dụ cụ thể là đủ để gây ấn tượng tốt.


Nên học Agile hay Waterfall trước?

Câu trả lời ngắn: Học Agile trước.

Không phải vì Waterfall lỗi thời - nó vẫn được dùng trong dự án chính phủ, ngân hàng lớn, hệ thống y tế. Nhưng phần lớn công ty tuyển fresher tester hiện nay - startup, công ty product, agency phần mềm - đều chạy Agile.

Hơn nữa, nếu bạn hiểu Agile, Waterfall dễ học hơn nhiều. Chiều ngược lại không đúng bằng.

342144 Lộ trình học đúng giúp bạn sẵn sàng xin việc nhanh hơn

Lộ trình gợi ý cho người mới:

Tuần 1-2: Đọc về Scrum framework cơ bản - hiểu Sprint, các vai trò (Scrum Master, PO, Dev Team), 5 sự kiện Scrum. Tài liệu chính thức: {{resource:resource_1}}

Tuần 3-4: Thực hành viết user story và acceptance criteria. Lấy app bất kỳ bạn đang dùng (Shopee, Zalo, Be), tưởng tượng bạn là PO và viết user story cho 5 tính năng. Sau đó viết test case theo acceptance criteria đó.

Tuần 5-6: Tìm hiểu Waterfall - đặc biệt là quy trình kiểm thử theo V-model, cách viết test plan đầy đủ, test report. Đây là kỹ năng cộng điểm khi phỏng vấn dự án ngân hàng/chính phủ.

Tuần 7-8: Kết hợp - tự làm 1 dự án nhỏ nhóm 2-3 người theo Agile. Dùng Jira free (hoặc Trello) để quản lý Sprint, Notion để viết test case. Có project thực hành ghi vào CV là điểm cộng lớn.

Mình tin nếu bạn đọc đến đây, bạn đã hiểu: học methodology không phải để thuộc lòng định nghĩa mà để biết mình sẽ làm gì trong môi trường thực tế.

Test kỹ 1 lần, hiểu đúng 1 lần - còn hơn học nhiều mà không áp dụng được. Comment bên dưới nếu bạn còn thắc mắc về Agile hay Waterfall - mình trả lời từng bạn!