Agile testing: 4 yếu tố cuối làm nên thành công của Agile testing

Có 7 yếu tố chính làm nên thành công của Agile testing, 4 yếu tố cuối cùng là
(4) Đưa ra và nhận phản hồi liên tục
(5) Xây dựng cơ sở cho các thực hành cốt lõi
(6) Hợp tác với khách hàng
(7) Nhìn vào bức tranh tổng thể

Yếu tố 4: Đưa ra và nhận lại phản hồi

Phản hồi là giá trị cốt lõi của Agile. Các vòng lặp ngắn của Agile được thiết kế để cung cấp các phản hồi liên tục để giữ nhóm trên đường đua. Các tester đang là vị trí duy nhất cung cấp phản hồi dưới hình thức các kết quả kiểm thử tự động, các khám phá trong kiểm thử thăm dò và các quan sát của người dùng thực của hệ thống.

Các tester cũng cần phản hồi. Làm thế nào để bạn biết bạn có các examples đúng với hành vi mong muốn của khách hàng? Làm thế nào để bạn biết nếu các trường hợp kiểm thử của bạn viết ra phản ánh chính xác các examples? Các lập trình viên có thể hiểu được phải viết mã gì, bằng cách nhìn vào các examples được bạn nắm bắt và các kiểm thử được bạn tạo ra không?

Một trong những kỹ năng có giá trị nhất mà bạn có thể học hỏi, là làm thế nào để yêu cầu phản hồi về công việc của bạn. Yêu cầu các lập trình viên nếu họ có đủ thông tin để hiểu về các yêu cầu và thông tin có hướng dẫn việc viết mã của họ không. Hỏi khách hàng nếu họ cảm thấy các tiêu chí chất lượng của họ đã được đáp ứng. Dành thời gian với các cuộc họp iteraction planning và retrospectives để nói về các vấn đề và đề nghị các cách cải tiến.

Yếu tố 5: Xây dựng cơ sở cho các thực hành cốt lõi

Câu nói cũ của nghiệp vụ kiểm thử là “Bạn không thể kiểm thử chất lượng ở trong sản phẩm”. Tất nhiên, đây là sự thật của phát triển Agile. Chúng tôi cảm thấy bạn không thể phân phối phần mềm chất lượng cao mà không tuân theo các thực hành cơ bản. Trong khi chúng tôi nghĩ về nó như các thực hành Agile, chúng đã tồn tại lâu hơn cả mục “Phát triển Agile”, và chúng là thực hành cốt lõi của phát triển phần mềm thành công.

1. Tích hợp liên tục

Mỗi nhóm phát triển cần quản lý mã nguồn và tích hợp liên tục để thành công. Bạn không thể kiểm thử hiệu quả nếu bạn không biết bạn đang kiểm thử cái gì, và bạn không thể kiểm thử toàn bộ nếu bạn không có mã nguồn có thể triển khai. Toàn bộ thành viên nhóm có thể kiểm tra công việc của bạn một lần môt ngày. Mỗi tích hợp nên được xác định bởi một build tự động mà nó bao hàm cả các kiểm thử để cung cấp phản hồi nhanh về tình trạng của phần mềm.

Thực hiện quy trình tích hợp liên tục sẽ là một trong những ưu tiên hàng đầu của bất kỳ nhóm phát triển phần mềm nào. Nếu nhóm của bạn không có ít nhất một verified build hằng ngày, dừng những cái bạn đnag làm và hãy bắt đầu với việc tạo nó. Điều này thực sự quan trọng. Nó không cần quá hoàn hảo để bắt đầu. Nếu bạn có một hệ thống lớn để tích hợp, nó chắc chắn khó khăn hơn. Tuy nhiên, nhìn chung nó không khó. Có nhiều công cụ tốt, cả về mã nguồn mở và thương mại, có sẵn cho mục đích này.

2. Các môi trường kiểm thử

Cạn không thể kiểm thử hiệu quả mà không có một môi trường kiểm thử có thể kiểm soát được. Bạn cần biết build gì đã được triển khai, schema dữ liệu nào đã được sử dụng, ai đang cập nhật schema đó, và các tiến trình nào đang chạy trên máy.

Phần cứng thì ít tốn kém nhất, và nhiều phần mềm mã nguồn mở luôn có sẵn để có thể sử dụng cho các môi trường kiểm thử. Nhóm của bạn nên đầu tư để bạn có thể tiến hành các kiểm thử tự động và thăm dò nhanh chóng và hiệu quả. Nếu có vấn đề với môi trường kiểm thử, hãy lên tiếng và để nó là vấn đề của cả nhóm để giải quyết nó một cách sáng tạo.

3. Quản lý các Technical Debt

Ngay cả các nhóm phát triển phần mềm tốt, đều cảm thấy áp lực thời gian, sao lãng tái cấu trúc (refactoring) hay dùng đến các cách sửa chữa nhanh và từ bỏ việc giải quyết một vấn đề nhanh chóng. Khi mã nguồn trở nên khó hiểu và khó duy trì, nhiều lỗi xảy ra, và nó không mất nhiều thời gian trước khi tốc độ của nhóm bị tiêu tan bởi việc sửa lỗi và cố gắng làm cho mã nguồn có nghĩa để thêm các tính năng mới. Nhóm của bạn nên đánh giá liên tục các khoản nợ kỹ thuật đang kéo nó xuống và làm việc để giảm thiểu và ngăn chặn nó.

Người ta thường nói, “Quản lý của chúng tôi không cung cấp cho chúng tôi thời gian để làm mọi thứ chính xác, chúng tôi không có thời gian để cấu trúc lại (refactor), và chúng tôi bị áp lực bởi các thời hạn (deadline) sít sao”. Tuy nhiên, không khó để làm rõ ràng một bài toán kinh doanh để cho thấy rằng cái gì đang làm tăng nợ kỹ thuật, mà nó chính là chi phí của công ty. Có rất nhiều cách để đo mã nguồn và tỷ lệ defects (nó chuyển nợ kỹ thuật thành các ảnh hưởng ở cuối chu kỳ). Chỉ đến việc tốc độ đang giảm có thể đủ. Các doanh nghiệp cần các nhóm phát triển phần mềm của họ vẫn hiệu quả như mong muốn. Họ có thể phải giảm phạm vi (scope) hay các tính năng mong muốn để đủ thời gian cho việc thiết kế mã nguồn hướng kiểm thử tốt và các thực hành hiệu quả như tái cấu trúc nhỏ liên tục.

Độ bao phủ tốt từ các kiểm thử hồi quy tự động là chìa khóa để giảm thiểu nợ kỹ thuật. Nếu thiếu, thời gian ngân sách trong mỗi vòng lặp để xây dựng các kiểm thử tự động, lên kế hoạch một “vòng lặp tái cấu trúc (refactoring interation)” để ngân cấp và thêm các công cụ cần thiết, và viết các kiểm thử, và thực hiện các khả năng tái cấu trúc chính. Trong mỗi vòng lặp, dành thời gian để điều hướng mã nguồn với các kiểm thử, tái cấu trúc mã nguồn mà bạn đang nắm bắt khi cần, và thêm vào các kiểm thử tự động ở những nơi chúng đang bị thiếu. Tăng ước tính của bạn để tính toán cho công việc này. Về lâu dài, nhóm sẽ có thể đi nhanh hơn.

4. Tăng trưởng công việc

Một lý do mà các nhóm Agile có thể tạo ra một sản phẩm chất lượng là họ làm việc với quy mô nhỏ. Các stories được đưa ra trong một vài ngày làm việc, và mỗi story có thể được chia thành vài lát mỏng hoặc những sợi thép và được xây dựng từng bước. Điều này cho phép kiểm thử từng mảnh nhỏ và sau đó kiểm thử tăng trưởng như các mảng được đặt lại với nhau.

Nếu các thành viên nhóm của bạn đang bị cán dỗ để đưa vào một mảng lớn các chức năng cùng một lúc, khuyến khích họ tìm kiếm một phương pháp tiếp cận từng bước. Đặt câu hỏi: “Giá trị thương mại tập trung vào cái gì với story này? Hướng cơ bản nhất thông qua mã nguồn là gì? Điều gì xảy ra tiếp theo?” Đề nghị viết các task card để viết mã và kiểm thử những phần nhỏ, có một bản mô tả nội dung thiết kế của bạn, và xác nhận chiến lược kiểm thử và tự động kiểm thử của bạn.

5. Viết mã và kiểm thử là một phần của quy trình

Những người mới với Agile thường hỏi Agile tester “Bạn làm cái gì cho đến khi toàn bộ stories hoàn thành và bạn có thể kiểm thử?” Các nhà thực hành Agile có kinh nghiệm nói “Testers nên tham gia vào toàn bộ vòng lặp, toàn bộ quá trình phát triển. Nếu không nó sẽ không làm việc.”

Các tester viết kiểm thử, dựa vào example được cung cấp bởi customer, để giúp programmers hiểu story và bắt đầu. Các kiểm thử và examples cung cấp một ngôn ngữ chung mà tất cả mọi người tham gia vào sản phẩm phần mềm đều hiểu được. Tester và programmer hợp tác chặt chẽ như mã nguồn tiếp diễn, và họ cũng hợp tác chặt chẽ với customer. Programmer cho tester thấy chức năng mà họ đã viết, và tester cho programmer thấy các hành vi không mong muốn mà họ tìm thấy. Tester viết nhiều kiểm thử như mã nguồn tiếp tiễn, programmer làm cho chúng pass, và tester thực hiện nhiều kiểm thử thăm dò (exploratory testing) để tìm xem giá trị được phân phối có đúng không. Mỗi vòng lặp Agile chứa hàng chục vòng lặp test-code-test-code-test liên tục, nhanh chóng và tăng trưởng.

Khi chu kỳ hợp tác và phản hồi này bị phá vỡ, và kiểm thử bị tách ra khỏi sự phát triển, những điều xấu sẽ xảy ra. Nếu một story được kiểm thử trong vòng lặp sau khi nó được viết mã và các lỗi được tìm thấy, programmer phải dừng công việc ở story mới, phải nhớ lại mã nguồn đã làm việc như thế nào với story của vòng lặp cũ, sửa nó và đợi ai đó kiểm thử việc sửa chữa đó. Một vài ảnh hưởng này trong phát triển phần mềm, nhưng chúng tôi biết chắc rằng các lỗi sẽ rẻ hơn khi chúng được sửa ngay khi chúng được tìm thấy.

Khi viết mã liên tục được điều hướng bởi các kiểm thử, và kiểm thử đi cùng với việc viết mã, chúng ta có khả năng đạt được hành vi mong muốn và cung cấp các giá trị thích hợp. Kiểm thử là trách nhiệm của toàn nhóm. Nếu nhóm bạn không chia sẻ quan điểm này, yêu cầu mọi người suy nghĩ về chất lượng, mong muốn của họ về việc phân phối sản phẩm tốt nhất có thể, và các bước để họ có thể đảm bảo nhóm có thể đạt được mục tiêu của mình.

6. Sự tương tác giữa các phần thực hành

Một thực hành phát triển Agile như tích hợp liên tục có thể có một chút khác biệt, nhưng sự kết hợp của nhiều thực hành Agile thì tuyệt vời hơn tổng các phần. Thiết kế điều hướng kiểm thử (test-driven design), tập hợp các mã nguồn riêng, và tích hợp liên tục cùng với nhau để đưa ra phản hồi nhanh chóng, liên tục cải tiến thiết kế mã và khả năng phân phối nhanh giá trị thương mại. Tự động hóa các kiểm thử là tốt, nhưng sử dụng các kiểm thử tự động để điều hướng phát triển, theo sau bởi các kiểm thử thăm dò để phát hiện những khoảng chống hoặc điểm điếu, là các mức độ to lớn hơn.

Một số thực hành không làm việc tốt khi cô lập. Tái cấu trúc thì không thể nếu không có kiểm thử tự động. Nó có thể nếu thực hiện các phát hành nhỏ với kiểu mini-waterfall và tránh toàn bộ lợi ích của phát triển nhanh. Nếu khách hàng tại chỗ không có năng lực để tạo các quyết định, giá trị của cô đối với nhóm bị giới hạn.

Các thực hành Agile được thiết kế để bổ sung cho nhau. Hãy dành thời gian để hiểu được mục đích của cái khác, xem xét những gì cần thiết để tận dụng lợi thế đầy đủ của mỗi thực hành và đưa ra các quyết định chu đáo về những việc làm cho nhóm bạn.

Yếu tố 6: Hợp tác với khách hàng

Một trong những giá trị tuyệt vời nhất mà tester đóng góp cho nhóm Agile là giúp khách hàng làm rõ và phân mức ưu tiên cho các yêu cầu, minh hoa yêu cầu bằng những examples về hành vi mong muốn và các kịch bản người dùng, và chuyển các examples đó vào các kiểm thử thực thi. Các tester nói ngôn ngữ lĩnh vực nghiệp vụ và ngôn ngữ kỹ thuật của nhóm phát triển. Chúng ta tạo ra các nhà hỗ trợ và dịch giả tốt.

Không bao giờ có được cách giao tiếp trực tiếp giữa các programmer và customer. Khuyến khích càng nhiều giao tiếp trực tiếp nhất có thể. Sử dụng “Năng lực của bộ ba – Power of Three” Khi các yêu cầu bị thiếu hoặc hiểu nhầm, một customer, programmer, tester phải làm cùng với nhau để đưa ra câu trả lời của các câu hỏi. Để customer nói chuyện trước một whiteboard hoặc thiết bị tương đương là cần thiết. Nếu customer nằm rải rác xung quanh khu đại học, quốc gia, hoặc toàn cầu, sử dụng mọi công cụ mà bạn tìm thấy để tăng cường giao tiếp và hợp tác. Teleconferences, instant messages, và wikis không phải là sự thay thế lý tưởng cho cuộc đối thoại face-to-face, nhưng chúng vượt qua cách gửi email hay không nói gì cả.

Yếu tố 7: Nhìn vào bức tranh tổng thể

Tất nhiên, đây là một sự tổng quát, nhưng chúng tôi thấy rằng các tester có xu hướng nhìn vào bức tranh lớn, và thường là từ điểm nhìn của khách hàng. Các programmer luôn phải tập trung vào việc phân phối story mà họ đang làm việc, và trong khi họ có thể sử dụng các kiểm thử để điều hướng chúng, thì họ phải tập trung vào việc thực hiện kỹ thuật của các yêu cầu.

Điểm nhìn bức tranh lớn này là sự đóng góp lớn đối với nhóm. Phát triển điều hướng kiểm thử (test-driven development), hoàn thành tốt, phân phối các đoạn mã chắc chắn, trong sự cô lập, tự do của của các defects. Điều gì xảy ra nếu chức năng mới làm cho một số phần không liên quan đến ứng dụng bị phá vỡ? Ai đó phải xem xét ảnh hưởng từ một hệ thống lớn và khiến cả nhóm phải quan tâm đến. Điều gì xảy ra nếu chúng ta bỏ qua một vài chi tiết nhỏ sẽ kích thích khách hàng? Giao diện người dùng mới có thể trở nên hoàn hảo để viết mã, nhưng nếu màu nền làm cho văn bản khó có thể đọc, nó sẽ làm cho người dùng cuối chú ý.

Sử dụng các Agile testing quadrants như một hướng dẫn để giúp bạn lên kế hoạch kiểm thử để bao phủ toàn bộ các góc. Sử dụng ý tưởng test pyramid để đảm bảo ROI tốt từ kiểm thử tự động của bạn. Điều hướng phát triển với các kiểm thử giúp đảm bảo bạn không quên bất cứ thứ gì lớn, nhưng nó thì không phải hoàn hảo. Sử dụng kiểm thử thăm dò để tìm hiểu nhiều hơn về ứng dụng sẽ làm việc như thế nào, và kiểm thử của bạn phải thực hiện theo hướng nào. Làm cho các môi trường kiểm thử tương tự với production nhất có thể, sử dụng dữ liệu được phản ánh từ thế giới thực. Hãy siêng năng để tạo lại trạng thái một production-style cho các hoạt động như với kiểm thử tải (load testing)

Thật dễ dàng cho mọi người trong nhóm để chỉ tập trung vào task hay story. Nó là nhược điểm của cách làm việc dựa trên các phần nhỏ của chức năng tại một thời điểm. Hãy giúp nhóm bạn đi từng bước một và sau đó đánh giá các stories hiện tại của bạn phù hợp như thế nào với lược đồ lớn của doanh nghiệp. Hãy hỏi bản thân, làm thế nào để bạn làm việc tốt hơn để cung cấp giá trị thực.

(Kết thúc)
Bài viết được dịch và biên soạn từ cuốn “Agile Testing A Practical Guide for Testers and Agile Teams” của Addison Wesley (năm 2009)