Kiểm thử Agile

Một người kiểm thử viết cho tôi: “Chúng tôi có cần nhóm kiểm thử độc lập cho dự án agile không? Một số người nói nếu công ti dùng agile họ không cần người kiểm thử thêm nữa. Điều đó có đúng không?”

Đáp: Cách tiếp cận Agile có tác dụng tốt cho các dự án nhỏ (bốn tới mười người). Bởi vì tổ là nhỏ, nó có thể không cần có nhóm kiểm thử độc lập. Những người phát triển nên có khả năng kiểm thử phần mềm riêng của họ và trắc nghiệm kết quả kiểm thử trong cuộc họp hàng ngày. Những người phát triển phải làm kiểm thử đơn vị để đảm bảo rằng mã của họ làm việc đúng. Là một tổ, có thể để những người phát triển kiểm thử công việc của nhau, do đó có thể không cần có nhóm kiểm thử. Với Agile, những người phát triển cũng là người kiểm thử. Công ti thường có cả các dự án lớn và nhỏ. Với dự án lớn, vẫn có nhu cầu về nhóm kiểm thử độc lập cho nên công ti vẫn cần người kiểm thử.

Khi mã bị thay đổi có thể là lỗi lại được đưa vào. Bởi vì phát triển lặp của Agile, việc đưa ra mã lần tiếp được dựng bởi việc sửa đổi mã trước cho nên kiểm thử rà lại là rất quan trọng và phải được tiến hành cho từng lần lặp để đảm bảo rằng chức năng mới thêm sẽ làm việc đúng và rằng chức năng được đưa ra trước đây vẫn làm việc như mong đợi.

Để đảm bảo rằng sản phẩm phần mềm đáp ứng yêu cầu của khách hàng điều quan trọng là kiểm thử đủ được thực hiện và mọi kịch bản đều được kiểm thử. Điều được khuyến cáo là phần mềm cuối cùng có thể cần trải qua nhóm kiểm thử độc lập để chắc rằng mọi thứ làm việc tốt trước khi dự án chấm dứt. Trong trường hợp đó, nhóm kiểm thử độc lập vẫn quan trọng.

Có nhiều “cường điệu” về dùng Agile như nó có thể thay thế được các cách tiếp cận khác. Điều đó không đúng. Agile là cách tiếp cận tốt để xây dựng phần mềm nhỏ trong thời gian ngắn, phần mềm mà không có mọi yêu cầu được xác định rõ ràng. Với các dự án lớn hơn yêu cầu nhiều hơn mười hay hai mươi người, sẽ khó áp dụng cách tiếp cận Agile. Trong trường hợp đó, bạn có thể vẫn cần theo các cách tiếp cận khác. Yếu tố quan trọng khác là Agile yêu cầu người phát triển và khách hàng trao đổi chặt chẽ trong quá trình phát triển. Nếu khách hàng bận rộn và không thể tham gia vào trong dự án thì bạn không nên dùng Agile. Bởi vì bạn xây dựng phần mềm trong việc lặp ngắn và dựa trên phản hồi của khách hàng để cải tiến các tính năng cho lần lặp tiếp, sự tham gia của khách hàng là mấu chốt.

Tác phẩm, tác giả, nguồn

  • Tác phẩm: Quản lý dự án
  • Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
  • Wiki hóa: https://kipkis.com

Có thể bạn muốn xem