Chuyển từ kiểm thử trong mô hình thác nước sang mô hình Agile

Đây là bài viết được lấy ra từ link sau: http://www.testingexcellence.com/transitioning-waterfall-agile-testing/

Khi một công ty quyết định chuyển từ kiểm thử theo mô hình thác nước sang kiểm thử theo mô hình agile, điều gì là quan trọng nhất mà ta phải tập trung quan tâm để test theo mô hình agile được hiệu quả?

Điều gì tạo nên sự khác biệt của kiểm thử theo mô hình agile và mô hình thác nước? Một người tester cần biết và thực hiện các công việc quan trọng nào?

Kiểm thử trong suốt quá trình phát triển

Điều đầu tiên ta cần hiểu rằng trong mô hình phát triển agile, kiểm thử được thực hiện trong suốt vòng lặp nghĩa là kiểm thử phần mềm diễn ra liên tục trong suốt quá trình phát triển sản phẩm.

Trong mô hình thác nước truyền thống, kiểm thử rất tốn effort và là phần cuối cùng để kết thúc việc phát triển, trong khi theo mô hình Agile, kiểm thử là một phần nhỏ nhưng lặp lại thường xuyên và xảy ra trong suốt quá trình phát triển phần mềm.

Kiểm thử trong suốt quá trình phát triển cũng đồng nghĩa với việc phần mềm luôn được đặt trong điều kiện có thể release, do đó nó có thể được bàn giao sản phẩm bất cứ lúc nào.

Trong mô hình thác nước, chúng ta làm việc theo từng giai đoạn, cụ thể là giai đoạn thiết kế, giai đoạn code và giai đoạn kiểm thử. Phát triển theo agile ta sẽ không còn chia giai đoạn kiểm thử ra riêng biệt như vậy nữa. Các developer cũng sẽ có vai trò quan trọng hơn khi tham gia vào việc kiểm thử, viết unit test tự động để validate code.

Sự tham gia của developer trong kiểm thử

Với unit test tự động, việc kiểm thử có thể được hoàn thành như một phần trong việc xây dựng, đảm bảo rằng tất cả các feature được thực hiện chính xác mỗi khi build. Từ độ bao phủ tốt của unit test, developer sẽ cảm thấy tự tin hơn để refractor code.

Kiểm thử trong agile cũng sẽ bắt đầu sớm. Tức là QA sẽ phải tham gia ngay từ giai đoạn design, hiểu các feature và story và bắt đầu chuẩn bị viết tescase.

Cross Functional Teams (Nhóm liên chức năng)

Chuyển sang Agile nghĩa là các hoạt động của team trong project sẽ có chức năng như nhau. Việc cùng tham gia kiểm thử này không gây cản trở gì cho việc kiểm thử của tester. Các developer sẽ hỗ trợ bằng các test framework, các business analysts hỗ trợ bằng cách chỉnh lại các story cho chuẩn xác.

Mỗi thành viên trong team làm việc theo story cho tới khi toàn bộ story được thực hiện xong, điều đó có nghĩa là vừa code vừa kiểm thử. Các designer, developer và tester làm việc song song cùng nhau để đạt được mục tiêu chung và họ cần biết điều gì cần thiết phải làm để hoàn thành công việc (không có ai giao việc cho họ).

Làm việc theo đội là điểm đáng chú ý nhất khi chuyển từ mô hình kiểm thử thác nước sang mô hình agile. Các công ty có thể quyết định thay đổi để chuyển sang mô hình kiểm thử agile nhưng mỗi cá nhân trong team cần phải hỗ trỡ lẫn nhau cùng thực hiện thì sự thay đổi mới có thể thành công.

Mục tiêu ngăn ngừa lỗi hơn là phát hiện lỗi

Nhìn lên hình trên ta có thể nhận thấy ngay, lỗi được phát hiện càng muộn chi phí càng tăng cao. Với sự tham gia ngay từ lúc bắt đầu của tester trong dự án, họ có thể hỗ trợ trong việc xác định các kịch bản chính để kiểm thử một story. Các acceptance criteria (tiêu chí chấp nhận) sẽ thường xuyên được tạo bởi cả Product Owner, developer và tester.
Điều này đảm bảo rằng bất cứ điều gì đang được xây dựng thì tất cả các bên liên quan đều có thể kiểm thử và hiểu rõ ràng. Ngoài ra, càng nhiều người đang tham gia vào việc xác định các tiêu chí chấp nhận và "Định nghĩa thế nào là hoàn thành", lỗi có thể được sửa chữa sớm hơn và sản phẩm cuối cùng đảm bảo đúng các yêu cầu.

Mọi người đều có liên quan và chịu trách nhiệm về chất lượng của sản phẩm.

Ít tài liệu hơn, tăng tính cộng tác

Trong mô hình phát triển Agile, người ta chú trọng nhiều vào đối thoại và hợp tác để làm rõ yêu cầu hơn là dựa trên đặc tả và tài liệu như mô hình phát triển truyền thống .

Trong mô hình phát triển agile, mặc dù các yêu cầu có thể được làm sáng tỏ ở một mức độ nhất định, nó vẫn có thể có các yêu cầu không rõ ràng và không đầy đủ, dẫn đến các thành viên trong nhóm có sự hiểu biết khác nhau về yêu cầu.Điều đó có ý nghĩa như thế nào cho một Agile Tester? Một vấn đề chung cho các tester khi họ chuyển sang mô hình phát triển Agile là họ không biết chính xác những gì họ cần phải kiểm thử. Họ không có spec chi tiết để kiểm tra đối chiếu, vậy làm thế nào họ có thể có thể kiểm tra nó? Bạn không cần phải có tài liệu chi tiết để bắt đầu kiểm thử. Sẽ có rất nhiều trường hợp, tester phải tự xem xét và dùng cảm nhận chung để xác nhận sản phẩm. Việc có kiến thức rộng, có kinh nghiệm trở nên hết sức quan trọng. Tester cần có sự tự tin về kiến thức của mình nhiều hơn để làm việc hiệu quả.