Agile Testing: khi mỗi Dev là một QA

Việc quản trị một dự án Waterfall truyền thống chia việc phát triển và kiểm thử thành hai bước riêng biệt: người lập trình xây dựng một tính năng và sau đó "ném qua bên kia rào" cho đội QA tiến hành kiểm thử. Đội ngũ QA viết và thực thi các test plan chi tiết. Họ cũng gửi lại các lỗi trong lúc kiểm tra lại những tính năng có sẵn mà rất có thể là được gây ra bởi những phần việc mới. Rất nhiều team đang sử dụng mô hình waterfall hoặc các mô hình kiểm thử truyền thống khác nhận thấy rằng dự án càng lớn lên thì khối lượng việc kiểm thử càng tăng theo cấp số nhân - và team QA phải chật vật để bám trụ kịp. Project owner phải đối mặt với một lựa chọn không mấy thích thú: delay phát hành hoặc gian dối trong kiểm thử. (Và đoán xem lựa chọn nào được chọn trong 99% trường hợp.) Tệ hơn nữa, team QA thường được đánh giá một cách tryền thống bằng số lượng bug mà họ tìm được, điều đó khiến lập trình viên phải đề phòng. Nhưng nếu như có một cách nào đó có lợi hơn cho cả dev và QA để giảm thiểu số lượng bug trong code mà có thể xoá đi sự đánh đổi mà project owner phải chọn thì sao? Liệu điều đó có giúp tạo nên một phần mềm hoàn thiện hơn không? Mời thử quy trình kiểm thử nhanh gọn - agile testing.

Chuyển đổi từ mô hình truyền thống sang phương thức agile testing

Mục tiêu của một team phát triển agile là deliver tính năng một cách bền vững với chất lượng đảm bảo. Các team mà chuyển qua mô hình agile thì thường gặp khó khăn trong việc kết hợp thời gian kiểm thử vào tốc độ của agile. Đây là một thử thách chính đáng, bởi vì phương pháp kiểm thử truyền thống đơn giản là không khớp với ngữ cảnh của agile. Tốc độ của việc phát triển yêu cầu có một hướng tiếp cận mới để đảm bảo chất lượng cho mỗi build. Khá giống nwh sự kết hợp giữa thẻ ghi nợ và thẻ tín dụng, nó bắt đầu với một chút khó khăn, nhưng tiến bộ rất nhanh và cho cả team sự nhanh nhạy cần thiết. Để khắc phục giới hạn kĩ thuật, chúng ta cần khuyến khích các lập trình viên tự đảm bảo chất lượng của mình bằng những kĩ năng sẵn có:

• Dev rất giỏi giải quyết vấn đề bằng code
• Dev mà tự viết testcase thì sẽ càng đầu tư sửa lỗi khi testcase fail.
• Dev mà hiểu rõ yêu cầu thiết kế và thông thạo quy trình kiểm thử thì thường code ngon hơn. Chúng ta cần tin rằng với mỗi userstory trong backlog thì đều cần cả code và automation test code. Mặc dù nhiều team phân công cho dev viết code tính năng và QA thực hiện automated test, chúng ta sẽ thấy rằng hiệu quả hơn rất nhiều nếu cùng một kĩ sư thực hiện cả 2 việc. Một gợi ý nhỏ: Hãy xử lý khác nhau đối với bug trong tính năng mới và bug tái diễn trong tính năng sẵn có. Nếu một bug xảy ra trong quá trình phát triển, hãy dành thời gian để hiểu lỗi nằm ở đâu, sửa nó và tiếp tục. Nếu một lỗi degrade xuất hiện nghĩa là nó có thể sẽ tái diễn thêm nữa. Vì thế hãy tạo ra một bài kiểm thử tự động để bảo vệ chống lại lỗi đó trong tương lai. Mô hình này không có nghĩa là lập trình viên làm việc độc lập. Việc có kỹ sư đảm bảo chất lượng ở trong team vẫn là rất quan trọng. QA mang đến những góc nhìn đặc biệt đối với việc phát triển trong tương lai, và một QA giỏi sẽ biết bug thường xảy ra ở đâu và sẽ có thể chỉ điểm cho dev về những bug tiềm tàng thậm chí trước khi chúng tự lộ diện.

Những ảnh hưởng của con người trong việc test chẩn đoán

Trong team phát triển, các thành viên của đội QA ghép cặp với lập trình viên trong quá trình kiểm thử chẩn đoán, một quá trình rất có ý nghĩa trong quá trình phát triển để chống lại các bug nguy hiểm. Khá giống với việc review code, chúng ta có thể chứng kiến những kiến thức về kiểm thử được phổ biến cho tất cả mọi người trong team thông qua hoạt động này. Khi Lập trình viên biết kiểm thử thì code của họ cũng ngon hơn trước đó. Nhưng việc kiểm thử chẩn đoán này có phải là thủ công không? Không hề. Ít nhất không đồng nghĩa với việc kiểm thử rà soát thủ công. Test chẩn đoán là cách tiếp cận kiểm thử bằng tư duy phản biện và quản lí rủi ro cho phép người kiểm thử sử dụng kiến thức của họ về rủi ro, triển khai chi tiết và những nhu cầu của khách hàng. Biết trước những yếu tố đó trong quy trình kiểm thử cho phép lập trình viên hay kỹ sư QA tìm thấy vấn đề nhanh và hiệu quả, mà không cần phải viết testcase, test plan chi tiết hay requirement. Việc đó hiệu quả hơn nhiều so với kiểm thử thủ công truyền thống, bởi vì ta có thể mang những hiểu biết sâu sắc từ quá trình kiểm thử chẩn đoán trước đó trở lại vào code và test tự động. Kiểm thử chẩn đoán cũng dạy cho chúng ta về những kinh nghiệm sử dụng tính năng bằng những cách mà test kịch bản thủ công không đề cập tới. Việc giữ vững chất lượng bao gồm sự phối hợp của cả chẩn đoán và test tự động. Trong lúc một tính năng được phát triển, kiểm thử chẩn đoán đảm bảo rằng code mới đạt chuẩn chất lượng một cách đúng nghĩa hơn là nếu chỉ dùng test tự động. Điều này bao gồm cả tính dễ sử dụng, giao diện đẹp mắt và tính hữu dụng chung của tính năng cộng với sự bảo vệ mạnh mẽ chống lại các bug degrade mà test tự động cung cấp.

Nhưng sự thay đổi có thể khó khăn - rất khó khăn

Hầu hết các dev đều chống lại việc viết test tự động, bởi vì "đó là việc của QA". Tuy nhiên sau nhiều năm làm việc với những đoạn code lỗi và tất cả những lời than phiền rằng kiểm thử tự động có thể làm chậm quá trình phát triển, nhiều Project owner đã nhất quyết bắt buộc mỗi đoạn code phải được đi kèm với một kịch bản automation test để tự chứng minh chất lượng. Chỉ ngay sau một lần áp dụng, code đã được cải thiện. Và lập trình viên mà chống lại việc viết automated test mãnh liệt nhất lại là người máu lửa lao vào sửa chữa nhất khi test fail! Qua một vài vòng lặp nữa những đoạn code automated test lớn dần lên, có thể áp dụng đa trình duyệt và trở thành văn hoá cả team phát triển. Tất nhiên, việc deliver một tính năng mất nhieef thời gian hơn nhưng lượng bug và công sức sửa chữa giảm xuống rõ rệt, tiết kiệm được rất nhiều thời gian khi dự án gần kết thúc. Thay đổi hầu như chẳng bao giờ dễ dàng. Nhưng giống như hầu hết những khía cạnh khác, nếu bạn quyết tâm và tạo ra những tiêu chuẩn mới cho bản thân, thì câu hỏi duy nhất còn lại chỉ là "Tại sao mình không làm nó sớm hơn nhỉ?"