Đã 9h tối rồi mà một số bạn vẫn đang ở trong phòng lab loay hoay với với các antenna của các trạm phát sóng BTS cùng với khoảng chục chiếc điện thoại di động trên bàn. Khuôn mặt của các bạn đã thấm mệt, bụng đã đói cồn cào nhưng phải cố gắng hoàn thành bộ test case trước khi ra về. Đó là một dự án đã trễ deadline vài tháng trời, nhóm viết code vừa mới hoàn thành phần viết code và chuyển giao sang cho nhóm kiểm thử.
Đó là một dự án waterfall mà tôi biết có sự tham gia của nhóm viết code, kiểm thử ở cả Ấn Độ và Việt Nam, số lượng thành viên viết code đâu đó tầm 20 người và kiểm thử khoảng 5 người. Nhóm viết code và làm kiểm thử là tách bạch nhau và chỉ khi nhóm viết code hoàn thành thì nhóm kiểm thử mới bắt đầu được. Do đó, tiến độ của nhóm viết code sẽ ảnh hưởng đến tiến độ của nhóm kiểm thử.
Ở một dự án khác mà tôi tham gia theo mô hình Scrum, các thành viên viết code và kiểm thử cùng chung một nhóm gồm 7 người. Các bạn kiểm thử không phải ngồi đợi vài tháng trời mới có cái để kiểm tra mà phải tham gia vào từ rất sớm.
Khi có yêu cầu từ khách hàng, các bạn cùng với nhóm viết code phân tích, đưa ra nhận định về ảnh hưởng đến toàn hệ thống, lên kế hoạch cho mỗi phân đoạn ngắn 2 tuần, có tiêu chí chấp nhận và tiêu chí hoàn thành cùng với các kịch bản kiểm thử. Những công việc sau buổi lập kế hoạch được phân bổ theo độ ưu tiên, phân nhỏ và có thể hoàn thành nhanh trong vài tiếng hoặc dài nhất là 3 ngày, do đó, ngay trong ngày hôm sau, nhóm viết code đã có thể bàn giao những tính năng có thể kiểm thử được và khi đó, các bạn trong nhóm kiểm thử có thể bắt tay vào ngay vào việc kiểm thử mà không phải ngồi không xơi nước hết ngày ngày sang ngày khác.
Một điểm thú vị nữa trong việc tổ chức nhóm nhỏ theo Scrum đó là các bạn viết code cũng tham gia vào quá trình kiểm thử ngay khi lúc viết code và trước khi bàn giao.
Ngay khi viết code, nhóm ứng dụng kĩ thuật Test-driven development (TDD) hay Behavior-driven development (BDD) để viết code kiểm tra trước khi thực thi. Việc làm này giúp cho việc kiểm thử diễn ra rất sớm và tất nhiên chi phí cho việc phát hiện lỗi và sửa lỗi ở giai đoạn này là rất rẻ so với việc phát hiện lỗi và sửa lỗi khi sản phẩm đã lên bàn giao cho người dùng.
Đôi khi, 2 bạn viết code cùng bắt cặp với nhau để phát triển một tính năng. Việc làm như thế này đối với một số công ty khó diễn ra vì nhiều lý do nhưng với nhóm tôi thì nó phát huy hiệu quả rất cao. Khi làm việc với nhau, người này làm người kia đóng góp ý kiến và kiểm tra ngay luôn lúc đang làm nên lỗi được phát hiện rất sớm.
Trước khi bàn giao sản phẩm, nhóm viết code cùng với nhóm kiểm thử có thể có một phần kiểm thử hồi quy (regression test) tất cả các tính năng cũ và mới trước khi bàn giao vì lúc này, không có những tính năng mới cần phát triển. Chi phí cho việc phát triển lỗi và sửa lỗi ở giai đoạn này vẫn rẻ hơn sau khi đưa ra thị trường.
Chất lượng của sản phẩm được tăng lên theo thời gian khi cả nhóm có sự đồng thuận cũng như phối hợp tốt với nhau theo thời gian.
Xem chi phí của việc phát hiện lỗi và sửa lỗi qua từng công đoạn:
Một đặc điểm quan trọng của các nhân viên kiểm thử trong mô hình Scrum là cần có những kĩ năng để thích nghi với quá trình thay đổi liên tục đặc biệt là kĩ năng về giao tiếp với các thành viên trong nhóm phát triển, nhóm kinh doanh để cập nhật thông tin liên tục thay vì phải theo những tài liệu định trước và thường xuyên không được cập nhật như trong mô hình waterfall.
Như vậy, việc kiểm thử trong mô hình Agile/Scrum có những điểm thay đổi tích cực so với mô hình truyền thống đó là: việc kiểm thử diễn ra từ rất sớm, các thành viên trong nhóm đều có thể đóng góp vào quá trình kiểm thử và cần có kỹ năng giao tiếp tốt để thích nghi với quá trình thay đổi.
Author: Nguyễn Thế Nghị
Đăng ký nhận bộ tài liệu học Java trên 2 trang giấy tại đây
Xem thêm: Java Coding Bootcamp là gì? Tổng quan về Java Coding Bootcamp
0 Lời bình