Dù đã xuất hiện và được sử dụng thành công ở nhiều lĩnh vực, nhưng ở Việt Nam mô hình kiểm thử Agile vẫn còn khá mới mẻ và áp dụng chưa triệt để. Hoặc có áp dụng nhưng là sự kết hợp giữa Agile và loại kiểm thử truyền thống. Sau đây hãy cùng tìm hiểu sự giống và khác nhau công việc của người kiểm thử trong mô hình Agile và mô hình Waterfall- một loại phổ biến cho mô hình truyền thống.

Hãy xem bức ảnh sau để thấy được các giai đoạn của 2 mô hình này: Việc dự án của bạn đang sử dụng mô hình nào thì mục đích cuối cùng của người kiểm thử là đảm bảo chất lượng của sản phẩm tới tay người sử dụng. Vẫn sẽ có những điểm giống và khác nhau giữa mô hình Agile và WaterFall.

A. Điểm tương đồng

• Lập kế hoạch, chuẩn bị cho công việc kiểm thử
• Lên checklist, viewpoint hay testcase cho các chức năng sẽ được kiểm thử
• Chuẩn bị môi trường, thiết bị và tạo các bộ dữ liệu kiểm thử
• Thực thi kiểm thử, báo cáo kết quả kiểm thử
• Hỗ trợ người dùng, tham gia các buổi họp với Khách hàng, nhóm dự án

B. Điểm khác nhau

1. Lập kế hoạch kiểm thử

Kiểm thử truyền thống: Việc lên kế hoạch kiểm thử cho dự án có thể kéo dài từ vài tuần cho đến vài tháng, thậm chí có thể vài năm sau khi đã tiến hành họp với các cấp để thu thập thông tin, làm rõ yêu cầu của hệ thống.

Kiểm thử theo Agile: Chấp nhận việc thay đổi yêu cầu từ phía khách hàng như một phần tất yếu để hoàn thiện sản phẩm. Do đó, việc lên kế hoạch và chuẩn bị kiểm thử trong một thời gian khá ngắn, thông thường là 1 sprint (1 sprint có thể là 1 tuần hoặc 2 tuần, không quá 4 tuần).

2. Tham gia vào quá trình kiểm thử

Kiểm thử truyền thống: Tester bắt tay vào khá muộn, sau khi design và dev đã hoàn thành xong hết các việc. Do vậy, sẽ không đảm bảo được tính chính xác đến từ yêu cầu của khách hàng vì chắc chắn sẽ xảy ra trường hợp cùng một yêu cầu nhưng suy nghĩ của người thiết kế, người lập trình và người kiểm thử khác nhau.

Kiểm thử theo Agile: Tất cả các bên đều tham gia vào ngay từ giai đoạn nhận yêu cầu của khách hàng, mỗi bước đều phải đảm bảo các bên tham gia có chung suy nghĩ, ko xảy ra tình trạng bất đồng ý kiến

3. Mô tả các trường hợp kiểm thử

Kiểm thử truyền thống: Thông thường, người kiểm thử sẽ dựa vào tài liệu chi tiết của hệ thống để lên checklist, viewpoint hoặc mô tả các trường hợp kiểm thử chi tiết (testcase). Nếu phát hiện sai sót trong tài liêụ yêu cầu hoặc thiết kế thì sẽ đặt câu hỏi tới trực tiếp người thiết kế hoặc với người viết tài liệu đặc tả dự án để làm rõ vấn đề.

Kiểm thử theo Agile: Đặc trưng của các dự án theo Agile là tài liệu đặc tả yêu cầu sẽ được chia nhỏ theo từng User story hay còn gọi là ticket hoặc task trong đó sẽ mô tả ngắn gọn về chức năng sẽ làm. Do vậy, trước khi bắt đầu sprint, người kiểm thử sẽ chỉ cần lên checklist cơ bản hay các tiêu chí chấp nhận (acceptance criteria). Trong buổi họp làm rõ vấn đề, Người kiểm thử sẽ trình bày lại ý hiểu và các tiêu chí chấp nhận cũng như các thắc mắc với Khách hàng hoặc PM, Dev. Đảm bảo được thống nhất suy nghĩ cũng như spec trong suốt sprint.

4. Chuẩn bị môi trường kiểm thử

Kiểm thử truyền thống: Vì tham gia vào quá trình kiểm thử khá là muộn nên người kiểm thử trong các dự án theo mô hình Waterfall có khác nhiều thời gian để tạo dữ liệu và chuẩn bị môi trường kiểm thử

Kiểm thử theo Agile: Đặc trưng của mỗi sprint thường chỉ kéo dài từ 1 tới 2 tuần. Cho nên, người kiểm thử sẽ không có quán nhiều thời gian để chuẩn bị môi trường cũng như dữ liệu. Do vậy, đòi hỏi người kiểm thử phải biết sắp xếp công việc, có kỹ năng, kiến thức và hiểu rõ về sản phẩm. Đồng thời, phải linh hoạt và vận dụng triệt để làm việc nhóm (teamwork) như một cách để tận dụng tối đa thời gian và bổ sung các kiến thức chưa biết từ đồng nghiệp trong nhóm.

5. Xác thực sản phẩm với khách hàng

Kiểm thử truyền thống: Việc xác thực, bàn giao sản phẩm tới khách hàng khá là muộn. Sau khi quá trình kiểm thử đã hoàn tất. Do vậy, nếu có bất cứ thay đổi hoặc sai khác với yêu cầu của khách hàng thì phải mất khác nhiều thời gian.

Kiểm thử theo Agile: Việc liên tục tương tác, nhận ý kiến và chấp nhận thay đổi yêu cầu của khách hàng giúp cho việc bàn giao sản phẩm trở nên nhanh chóng. Sản phẩm tới tay người dùng đúng theo mong muốn và ít xảy ra lỗi hơn khi có sự tương tác liên tục từ người dùng.

Link ảnh tham khảo: https://umangsoftware.files.wordpress.com/2014/06/agile.png