Kiểm thử Agile - Yes or No ?

Với những ai đang làm trong môi trường phát triển phần mềm, chắc chắn không dưới một lần đã nghe qua từ “Agile“.

Ngày nay, từ “Agile” được sử dụng một cách rộng rãi (đôi khi còn bị sử dụng sai nữa). Nó là một phương thức mới về quản lý dự án, nơi mà thiết lập những nguyên tắc nhất định của sự hợp tác, tính linh hoạt và minh bạch. Nó nhấn mạnh tầm quan trọng của việc phản hồi trong suốt quá trình phát triển của dự án.

Mặc dù vậy, khi đến giai đoạn kiểm thử, nhóm phát triển thường quay lại cách tiếp cận truyền thống hơn là đi theo con đường Agile.

Trong bài này, tôi sẽ mô tả sơ về kiểm thử Agile cũng như đưa ra vài hướng dẫn làm sao để bắt đầu việc kiểm thử theo Agile.

Một cách cơ bản, kiểm thử Agile là chúng ta ứng dụng cách tiếp cận Agile xuyên suốt quá trình kiểm thử và theo dõi lỗi.

Khi nói về kiểm thử Agile, chúng ta cũng cần xem lại nền tảng cơ bản cúa việc phát triển phần mềm. Từ buổi sơ khai của phần mềm, hầu hết tất cả đều theo một mô hình chung nhất, được gọi là Water Fall.

Cách tiếp cận theo hướng Water Fall, về cơ bản, là mỗi bước của dự án đều đi theo một chu trình tuyến tính, từng bước một nối tiếp nhau. Mô hình có thể vẽ cơ bản như sau:

Sự khác biệt trong kiểm thử Agile với kiểm thử Water Fall là bản thân việc kiểm thử không phải là một bước trong quá trình phát triển. Ngược với mô hình Water Fall, kiểm thử Agile yêu cầu việc hợp tác liên tục giữa tất cả thành viên trong nhóm phát triển và tất cả các bên liên quan đến dự án.

Xuyên suốt quá trình phát triển, kiểm thử trở thành một thành phần cơ bản của các giai đoạn của dự án. Do đó, mô hình của nhóm phát triển theo Agile giống như:

Mô hình kiềm thử Agile được phát triển trái ngược với mô hình truyền thống (Thác Nước). Mặc dù, nhóm Agile vẫn cần đến các qui trình làm việc cơ bản, nhưng tôi muốn nhấn mạnh rằng, bản thân Agile không tập trung quá nhiều vào qui trình làm việc.

Hay, như Martin Fowler đã nói:

    **Phương pháp Agile là hướng đến con người, chứ không phải hướng đến phương pháp.**

Qui trình làm việc thì tĩnh và chống lại sự thay đổi, còn con người thì dễ thích nghi và tiến nhanh hơn với sự thay đổi. Một vài người, thậm chí còn tự thay đổi bản thân nữa.

Tính cách đặc thù của Thay Đổi yêu cầu chúng ta phải đưa việc lấy phản hồi một cách liên tục làm nền tảng của dự án và nổ lực của các thành viên. Đề trở nên Agile nghĩa là chúng ta phải cung cấp các mối liên lạc, tiếp xúc dành cho việc lấy phản hồi.

Mặc dù nó không phải là gì quá mới khi nói “Phản hồi là vấn đề cốt lõi“. Việc liên tục hỏi và lấy các phản hồi xuyên suốt dự án đòi hỏi một nền văn hóa phản hồi, nơi mà mọi thành viên được yêu cầu đánh giá công việc hằng ngày của từng người.

Cách tiếp cận kiểm thử theo hướng Water Fall truyền thống là: xác định các yêu cầu, viết phần mềm và cuối cùng là kiểm thử nó. Thực thi kiểm thử được tiến hành ở giai đoạn cuối của quá trình phát triển. Cách tiếp cận này thường được gọi là “test-last“.

Mặt khác, tiến hành kiểm thử trước mang lại nhiều lợi ích. Đó là lý do mà tôi khuyết khích nên kiểm thử cùng thời điểm mà chúng ta xác định các yêu cầu.

Nó không chỉ mang đến cho chúng ta một cái nhìn rõ ràng về những thứ cần làm và mục tiêu cần đạt được, mà nó còn giúp chúng ta xác định yêu cầu một cách chi tiết hơn.

Agile thực sự đang giành chiến thắng trong việc phát triển phần mềm. Vậy, tại sao kiểm thử theo Agile lại không được như thế. Phát triển và kiểm thử liên tục đang trở thành một chuẩn mực mới. Do đó, kiểm thử phần mềm cần phải chuyển đổi vai trò của mình để trở nên linh hoạt và hiệu quả hơn khi một thứ gì đó cần được kiểm thử.

Kiểm thử đã không còn là một giai đoạn của quá trình phát triển phẩn mềm. Đảm bảo sự phát triển liên tục của sản phẩm có nghĩa là đảm bảo quá trình kiểm thử và phản hồi được thực thi một cách liên tục.

Nguồn : Agile Zone