Chúng ta vẫn cần thử nghiệm thủ công, nhưng không phải theo cách bạn nghĩ!
Quy trình quản lý dự án Waterfall phân tách việc phát triển và kiểm thử thành hai bước khác nhau: các nhà phát triển xây dựng một tính năng và “ném nó qua bên kia bức tường” cho nhóm đảm bảo chất lượng (QA) kiểm tra. Nhóm QA tạo và thực hiện các kế hoạch kiểm thử chi tiết. Họ cũng thực hiện kiểm thử hồi quy – kiểm tra lại các tính năng cũ và ghi nhận lại các lỗi mà công việc mới gây ra làm ảnh hưởng đến những tính năng này (nếu có). Agile Testing sẽ giúp bạn khám phá thêm ngay sau đây.
Nhiều nhóm áp dụng mô hình kiểm thử Waterfall này hoặc các mô hình kiểm thử truyền thống khác nhận thấy rằng, khi sản phẩm ngày càng phát triển, số lượng thử nghiệm cần thiết sẽ tăng lên theo cấp số nhân – và nhóm QA luôn phải vất vả để bắt kịp. Chủ sở hữu dự án phải đối mặt với một lựa chọn khó khăn: trì hoãn việc phát hành hoặc bỏ qua quá trình kiểm thử. Và trong lúc này, việc phát triển đã chuyển sang một giai đoạn khác. Do đó, không chỉ nợ kỹ thuật phát sinh mà việc giải quyết các khiếm khuyến cũng đòi hỏi việc chuyển đổi ngữ cảnh (context switch) tốn kém giữa hai phần của cơ sở mã nguồn.
Tồi tệ hơn, các nhóm QA thường được thưởng trên số lượng lỗi họ tìm thấy, điều này khiến các nhà phát triển rơi vào trạng thái phòng thủ. Vậy làm thế nào để tìm ra một cách tốt hơn cho cả nhà phát triển và QA để giảm số lượng lỗi trong mã, đồng thời loại bỏ những lựa chọn khó khăn mà chủ dự án phải thực hiện? Phương pháp đó liệu có tạo ra một phần mềm tốt hơn trên mọi phương diện không?
Chuyển đổi từ các phương pháp kiểm thử truyền thống sang Agile Testing
Mục tiêu của các nhóm Agile và DevOps là cung cấp các tính năng mới có chất lượng cao một cách đều đặn. Tuy nhiên, các phương pháp kiểm thử truyền thống không phù hợp với framework Agile hay DevOps. Tốc độ phát triển đòi hỏi một cách tiếp cận mới để đảm bảo chất lượng trong mỗi bản dựng (build). Hãy tìm hiểu cách kiểm thử nhanh chóng của Atlassian trong phần dưới đây, cùng Penny Wyatt, trưởng nhóm QA cấp cao của Jira Software.
Hãy làm rõ một điều: Kiểm thử thủ công theo kịch bản chính là nợ kỹ thuật.
Giống như nợ trong thẻ tín dụng, quả cầu tuyết bắt đầu với một khoản nhỏ, nhưng lăn với tốc độ nhanh và sẽ nhanh chóng làm mất đi sự nhanh nhẹn của nhóm. Để chống lại nợ kỹ thuật, Atlassian trao quyền và mong đợi các nhà phát triển trở thành những nhà vô địch vĩ đại về chất lượng. Họ tin rằng các nhà phát triển sở hữu những kỹ năng chính cần thiết để đưa ra một sản phẩm chất lượng cao:
- Các nhà phát triển rất giỏi trong việc giải quyết vấn đề bằng mã nguồn.
- Việc các nhà phát triển viết các kiểm thử của riêng họ được ưu tiên hơn việc sửa chúng khi kiểm thử thất bại.
- Các nhà phát triển hiểu các yêu cầu về tính năng và ý nghĩa của việc kiểm thử thường sẽ viết mã nguồn tốt hơn.
Atlassian tin rằng mỗi câu chuyện người dùng trong backlog yêu cầu cả mã nguồn tính năng và mã nguồn kiểm tra tự động. Mặc dù một số nhóm chỉ định các tính năng cho các nhà phát triển, còn việc kiểm tra tự động là nghĩa vụ của cả nhóm, nhưng Atlassian nhận thấy rằng việc để một kỹ sư duy nhất thực hiện toàn bộ quá trình sẽ hiệu quả hơn. Và sẽ cải thiện hơn nữa với Agile Testing.
Lưu ý: Hãy xử lý lỗi trong các tính năng mới và lỗi phát sinh trong các tính năng hiện có theo những cách khác nhau. Nếu một lỗi xuất hiện trong quá trình phát triển, hãy dành thời gian để hiểu lỗi, sửa nó và tiếp tục. Nếu một lỗi hồi quy xuất hiện (tức là một tính năng trước đây đã hoạt động nhưng hiện tại thì không), thì nó có khả năng sẽ xuất hiện lại. Hãy tạo một kiểm tra tự động để ngăn chặn vấn đề hồi quy đó trong tương lai.
Việc áp dụng mô hình này không có nghĩa là để các nhà phát triển làm việc một mình. Các kỹ sư QA vẫn đóng vai trò quan trọng trong nhóm, mang đến một góc nhìn quan trọng trong việc phát triển một tính năng. Các kỹ sư QA giỏi biết các lỗi thường ẩn náu ở đâu và có thể tư vấn cho nhà phát triển về các “lỗi” có khả năng xảy ra.
Sự tham gia của con người thông qua thử nghiệm thăm dò
Trong các nhóm phát triển tại Atlassian, các thành viên nhóm QA kết hợp với các nhà phát triển trong quá trình kiểm thử thăm dò (exploratory testing) – một phương pháp đáng giá trong quá trình phát triển nhằm chống lại các lỗi nghiêm trọng hơn. Giống như đánh giá mã nguồn (code review), Atlassian nhận thấy việc kiểm thử hỗ trợ chia sẻ kiến thức trong nhóm phát triển. Khi các nhà phát triển trở thành những tester tốt hơn, mã nguồn cải thiện hơn sẽ được phân phối ngay từ lần đầu tiên.
Agile Testing với việc kiểm thử thăm dò khiến cho mã nguồn, và nhóm, trở nên mạnh mẽ hơn.
Nhưng chẳng phải kiểm thử thăm dò cũng là kiểm thử thủ công sao? Không. Ít nhất không phải theo nghĩa giống như kiểm thử hồi quy thủ công. Agile Testing với kiểm thử thăm dò là một phương pháp tiếp cận dựa trên rủi ro, đòi hỏi người kiểm tra áp dụng kiến thức của họ về rủi ro, các chi tiết trong việc triển khai và nhu cầu của khách hàng. Nhận thức những điều này sớm hơn trong quá trình thử nghiệm cho phép nhà phát triển hoặc kỹ sư QA tìm ra các vấn đề một cách nhanh chóng và toàn diện mà không cần các trường hợp thử nghiệm theo kịch bản, kế hoạch thử nghiệm chi tiết hoặc các yêu cầu. Atlassian nhận thấy phương pháp này hiệu quả hơn nhiều so với kiểm thử thủ công truyền thông, bởi vì họ có thể hiểu rõ hơn từ các phiên kiểm thử thăm dò trở lại mã nguồn gốc và kiểm thử tự động. Thực hiện Agile Testing cũng mang đến những kiến thức về trải nghiệm sử dụng tính năng – điều mà kiểm thử theo kịch bản không làm được.
Việc duy trì chất lượng bao gồm cả kiểm thử thăm dò và kiểm thử tự động. Khi các tính năng mới được phát triển, kiểm thử thăm dò đảm bảo rằng mã mới đáp ứng tiêu chuẩn chất lượng theo nghĩa rộng hơn so với kiểm thử tự động. Điều này bao gồm tính dễ sử dụng, thiết kế trực quan đẹp mắt và tính hữu ích tổng thể của tính năng, bên cạnh các biện pháp mạnh mẽ do kiểm tra tự động cung cấp để chống lại các hồi quy.
Việc thay đổi có thể rất khó – thực sự khó
Penny Wyatt chia sẻ một câu chuyện cá nhân có thể tóm tắt hành trình Agile Testing của Atlassian như sau: “Tôi đã từng quản lý một nhóm kỹ sư ngay từ những ngày đầu trong sự nghiệp. Đó là những người có sức đề kháng mạnh mẽ trước việc viết các kiểm thử tự động, bởi vì ‘công việc đó là của QA’. Sau nhiều lần chứng kiến mã nguồn lỗi lặp lại và được nghe tất cả các lý do tại sao kiểm thử tự động sẽ làm nhóm chậm đi, tôi đã quyết định: Tất cả các mã nguồn mới phải được chứng minh bằng kiểm thử tự động.
Sau một quá trình lặp, mã nguồn đã bắt đầu được cải thiện. Và hoá ra, nhà phát triển kiên quyết nhất trong việc chống đối việc viết các kiểm thử tự động lại trở thành người bắt đầu hành động khi một kiểm thử không thành công! Trong vài quá trình lặp tiếp theo, các bài kiểm tra tự động đã phát triển, được mở rộng trên nhiều trình duyệt và cải thiện văn hoá phát triển của chúng tôi. Chắc chắn, việc phát hành một tính năng mới sẽ mất nhiều thời gian hơn. Tuy nhiên, các lỗi và thời gian làm lại đã giảm đáng kể, kết quả là chúng tôi đã tiết kiệm được rất nhiều thời gian.”
Thay đổi hiếm khi là một chuyện dễ dàng. Tuy nhiên, giống như hầu hết những thứ đáng giá khác, một khi bạn đã tạo ra một điều mới mẻ cho chính mình, câu hỏi duy nhất bạn sẽ phải đối mặt chỉ là “Tại sao chúng ta không làm điều này sớm hơn?!”
Theo Atlassian
