Hình vẽ ở trên là sơ đồ của các Quadrant kiểm thử agile (Agile Testing Quadrants) cho thấy cách thức của từng loại trong bốn Quadrant phản ánh những lý do khác nhau mà chúng ta kiểm tra. Trên một trục, chúng ta chia thành các bài kiểm thử hỗ trợ development team và các bài kiểm thử đánh giá sản phẩm. Trục còn lại chia thành nhóm các bài kiểm thử về nghiệp vụ và về công nghệ.

Thứ tự mà chúng ta đã đánh số các Quadrant này không liên quan đến thời điểm các loại thử nghiệm khác nhau được thực hiện. Ví dụ: phát triển agile bắt đầu bằng các bài kiểm thử của khách hàng, các bài kiểm thử này sẽ cho team biết phải viết code gì. Thời gian của các loại thử nghiệm khác nhau tùy thuộc vào rủi ro của từng dự án, mục tiêu của khách hàng đối với sản phẩm, team đang làm việc với code kế thừa hay dự án hoàn toàn mới, và khi nào có sẵn nguồn lực để thực hiện thử nghiệm.

• Nhóm các kiểm thử hỗ trợ development team

Các Quadrant bên trái bao gồm các bài kiểm thử hỗ trợ development team khi phát triển sản phẩm. Khái niệm kiểm thử để hỗ trợ các developer còn mới mẻ đối với nhiều người kiểm thử và là sự khác biệt lớn nhất giữa kiểm thử trên một dự án truyền thống và kiểm thử  dự án agile. Thử nghiệm được thực hiện trong Quadrant 1 và 2 là về đặc tả yêu cầu và hỗ trợ thiết kế nhiều hơn những gì chúng ta thường nghĩ về thử nghiệm.

Quadrant 1

Quadrant  1 thể hiện thực hành test-driven development, là một thực hành cốt lõi của phương pháp phát triển agile. Unit testing xác minh chức năng của một tập hợp nhỏ của hệ thống, chẳng hạn như một đối tượng (object) hoặc phương pháp (method). Component testing xác minh hành vi của một phần lớn hơn của hệ thống, chẳng hạn như một nhóm các class cung cấp một số dịch vụ. Cả hai loại kiểm tra thường được tự động hóa nhờ sử dụng một trong số công cụ tự động kiểm thử tự động. Chúng ta gọi các bài kiểm thử này thuộc loại các bài kiểm thử của developer, bài kiểm thử đối mặt với developer hoặc bài kiểm thử về công nghệ. Chúng cho phép các developer biết chắc điều mà Kent Beck gọi là chất lượng code nội bộ.

Mục đích chính của các bài kiểm thử trong Quadrant 1 là thực hành test-driven deveopment hoặc test-driven design. Quá trình viết các bài kiểm thử trước hết giúp các developer thiết kế tốt cho code của họ. Những thử nghiệm này cho phép các developer tự tin viết code để cung cấp các tính năng của user story mà không phải lo lắng về việc thực hiện các thay đổi ngoài ý muốn đối với hệ thống. Họ có thể xác minh rằng thiết kế và phân tích kiến trúc của họ là phù hợp. Các bài unit test và component test được tự động hóa và được viết bằng ngôn ngữ lập trình giống như ngôn ngữ lập trình của ứng dụng. Một chuyên gia nghiệp vụ có lẽ không thể hiểu chúng bằng cách đọc trực tiếp, nhưng những bài kiểm thử này không nhằm mục đích sử dụng cho khách hàng. Trên thực tế, chất lượng code nội bộ không được thương lượng với khách hàng: nó được định nghĩa bởi các developer. Kiểm thử bởi developer thường là một phần của quy trình tự động chạy với mỗi lần check-in code, cung cấp cho nhóm phản hồi liên tục, tức thì về chất lượng code nội bộ.

Quadrant 2

Các bài kiểm thử trong Quadrant 2 cũng hỗ trợ công việc của nhóm phát triển, nhưng ở cấp độ cao hơn. Các thử nghiệm về nghiệp vụ này, còn được gọi là kiểm tra định hướng customer, xác định chất lượng bên ngoài và các tính năng mà khách hàng muốn có. Giống như các bài kiểm thử Quadrant 1, chúng cũng thúc đẩy sự phát triển, nhưng ở cấp độ cao hơn. Với phương pháp phát triển agile, các bài kiểm thử này được lấy từ các ví dụ về chức năng nghiệp vụ do nhóm khách hàng cung cấp. Họ mô tả chi tiết của từng user story. Các bài kiểm thử về nghiệp vụ chạy ở cấp độ chức năng, mỗi bài kiểm thử xác minh sự thỏa mãn yêu cầu nghiệp vụ. Chúng được viết theo cách mà các chuyên gia nghiệp vụ có thể dễ dàng hiểu bằng ngôn ngữ nghiệp vụ. Trên thực tế, các chuyên gia nghiệp vụ sử dụng các bài kiểm thử này để xác định chất lượng bên ngoài của sản phẩm và thường giúp viết chúng. Quadrant này có thể sao chép lại một số thử nghiệm đã được thực hiện ở cấp đơn vị; tuy nhiên, các bài kiểm thử Quadrant 2 hướng tới việc minh họa và xác nhận hành vi hệ thống mong muốn ở cấp độ chức năng nghiệp vụ.

Hầu hết các bài kiểm thử về nghiệp vụ hỗ trợ development team phát triển cũng cần được tự động hóa. Một trong những mục đích quan trọng nhất của các bài kiểm thử ở hai Quadrant 1 và 2 là cung cấp thông tin phản hồi nhanh chóng và cho phép xử lý sự cố nhanh chóng. Chúng phải được chạy thường xuyên để cung cấp cho nhóm phát triển các phản hồi sớm khi có bất kỳ hành vi nào thay đổi ngoài dự kiến. Có thể các bài kiểm thử tự động này sẽ chạy trực tiếp trên business logics trong code mà không cần phải trải qua một lớp trình bày (presentation layer). Tuy nhiên, một số thử nghiệm tự động phải xác minh giao diện người dùng và bất kỳ API nào mà client application có thể sử dụng. Tất cả các thử nghiệm này nên được chạy như một phần của quá trình tích hợp, xây dựng và thử nghiệm liên tục tự động (continuous integration, build and test process).

Có một nhóm thử nghiệm khác cũng thuộc về Quadrant này. Các chuyên gia thiết kế giao diện người dùng sử dụng mô hình mô phỏng (mock-up) và wireframes để giúp xác thực các thiết kế GUI (giao diện đồ họa người dùng) được đề xuất với khách hàng và truyền đạt những thiết kế đó cho developer trước khi họ bắt đầu viết code. Các bài kiểm thử trong nhóm này là các bài kiểm thử hỗ trợ development team xây dựng đúng sản phẩm nhưng không được tự động hóa. Các Quadrant này giúp chúng ta xác định tất cả các loại kiểm tra khác nhau mà chúng ta cần sử dụng để thúc đẩy viết code.

Một số người sử dụng thuật ngữ “acceptance tests” để mô tả các kiểm thử trong Quadrant 2, nhưng chúng tôi tin rằng acceptance tests cần bao gồm một phạm vi rộng hơn gồm các bài kiểm tra trong Quadrant 3 và 4. Acceptance tests xác minh rằng tất cả các khía cạnh của hệ thống, bao gồm cả khả năng sử dụng và hiệu suất, đáp ứng yêu cầu của khách hàng.

Sử dụng các bài kiểm thử để hỗ trợ development team

Phản hồi nhanh được cung cấp bởi các bài kiểm thử tự động, được chạy mỗi khi có thay đổi hoặc bổ sung code, tạo thành nền tảng của một agile team. Các thử nghiệm này đầu tiên là để hướng dẫn sự phát triển các chức năng và khi được tự động hóa sẽ cung cấp một mạng lưới an toàn để ngăn việc đưa vào code mới có thể gây ra các kết quả không mong muốn.

Các bài kiểm thử ở Quadrant 1 và 2 được viết để giúp team cung cấp giá trị (business value) theo yêu cầu của khách hàng. Họ xác minh rằng business logics và các giao diện người dùng hoạt động theo các ví dụ về chức năng nghiệp vụ được cung cấp bởi customers.

Có những khía cạnh khác nữa đối với chất lượng phần mềm, một số khía cạnh mà các customers không nghĩ đến nếu không có sự trợ giúp từ nhóm kỹ thuật. Sản phẩm có cạnh tranh không? Giao diện người dùng có trực quan như nó cần phải có không? Ứng dụng có an toàn không? Người dùng có hài lòng với cách hoạt động của giao diện người dùng không? Chúng ta sẽ cần các bài kiểm thử khác để trả lời các loại câu hỏi này.

Câu chuyện của Lisa

Chúng tôi chạy các thử nghiệm tự động của mình để hỗ trợ development team (nửa bên trái của Quadrant) trong các quy trình xây dựng riêng biệt. Các bài unit test và component test sẽ chạy bản dựng (build) ‘đang diễn ra’ của chúng tôi, mất khoảng tám phút để hoàn thành. Mặc dù các developer chạy các bài unit test mỗi khi họ check-in, bản dựng vẫn có thể không thành công do sự cố tích hợp hoặc sự khác biệt về môi trường. Ngay sau khi chúng tôi thấy email cảnh báo “xây dựng không thành công”, developer sẽ kiểm tra code vi phạm để khắc phục sự cố. Các thử nghiệm chức năng về nghiệp vụ chạy trong bản dựng của chúng ta, cũng chạy liên tục, bắt đầu mỗi khi check-in code. Quá trình này kết thúc trong chưa đầy hai giờ. Đó là vòng phản hồi nhanh và lỗi build có nghĩa là phải có hành động ngay lập tức để khắc phục.

• Các kiểm thử đánh giá sản phẩm

Nếu bạn đã từng ở vai trò khách hàng và phải phát biểu các yêu cầu của mình đối với một tính năng phần mềm, bạn sẽ biết khó khăn như thế nào để biết chính xác những gì bạn muốn cho đến khi bạn nhìn thấy nó. Ngay cả khi bạn tự tin về cách thức hoạt động của tính năng này, thì khó có thể mô tả để các developer hiểu đầy đủ về nó.

Từ ” đánh giá phê bình” không có ý nghĩa tiêu cực. Một lời phê bình có thể bao gồm cả khen ngợi và gợi ý để cải thiện. Thẩm định một sản phẩm phần mềm bao gồm cả nghệ thuật và khoa học. Chúng ta đánh giá phần mềm theo cách xây dựng với mục tiêu tìm hiểu cách chúng ta có thể cải thiện nó. Khi chúng ta tìm hiểu, chúng ta có thể cung cấp các yêu cầu và thử nghiệm hoặc ví dụ mới về quy trình hỗ trợ development team và hướng dẫn quá trình phát triển.

Quadrant 3

Các ví dụ về chức năng nghiệp vụ giúp team thiết kế sản phẩm mong muốn, nhưng ít nhất một số ví dụ của chúng ta có thể sẽ sai. Các chuyên gia nghiệp vụ có thể bỏ qua chức năng hoặc không hiểu đúng nếu nó không phải là lĩnh vực chuyên môn của họ. Nhóm có thể hiểu nhầm một số ví dụ khác. Ngay cả khi các developer viết code để vượt qua các bài kiểm thử về nghiệp vụ, họ có thể không cung cấp những gì khách hàng thực sự muốn.

Đó là lúc các bài kiểm thử đánh giá sản phẩm trong Quadrant thứ ba và thứ tư phát huy tác dụng. Quadrant 3 phân loại các bài kiểm thử về nghiệp vụ nhằm đánh giá khả năng hoạt động của phần mềm liệu nó có hoàn toàn đáp ứng được kỳ vọng hoặc đủ sức cạnh tranh hay không. Khi chúng ta thực hiện các bài kiểm thử  usability test để đánh giá sản phẩm, chúng ta cố gắng mô phỏng cách người dùng thực làm việc trên ứng dụng. Đây là thử nghiệm thủ công mà chỉ con người mới có thể làm. Chúng ta có thể sử dụng một số tập lệnh tự động để giúp chúng ta thiết lập dữ liệu mà chúng ta cần, nhưng chúng ta phải sử dụng các giác quan, bộ não và trực giác của mình để kiểm tra xem nhóm phát triển có mang lại giá trị kinh doanh mà khách hàng yêu cầu hay không.

Thông thường, người dùng và khách hàng thực hiện loại thử nghiệm này. Kiểm thử chấp nhận của người dùng (UAT) giúp khách hàng có cơ hội thực hành cho các tính năng mới và xem họ có thể muốn thay đổi gì trong tương lai, và đây là một cách tốt để thu thập ý tưởng về những user story mới. Nếu team của bạn đang phân phối phần mềm trên cơ sở hợp đồng cho khách hàng, UAT có thể là một bước bắt buộc để phê duyệt các user story đã hoàn thành.

Kiểm thử khả năng sử dụng (usability test) là một ví dụ về một loại kiểm thử có toàn bộ khoa học của riêng nó. Các nhóm người dùng chuyên biệt (focus group) có thể được sử dụng, nghiên cứu khi họ sử dụng ứng dụng và phỏng vấn để thu thập phản ứng của họ. Kiểm tra khả năng sử dụng cũng có thể bao gồm việc điều hướng chuyển từ trang này sang trang khác hoặc thậm chí làm một cái gì đó đơn giản như thứ tự tab. Kiến thức về cách mọi người sử dụng hệ thống là một lợi thế khi kiểm tra khả năng sử dụng.

Exploratory test là trọng tâm của Quadrant này. Trong các phiên exploratory test, chuyên gia kiểm thử đồng thời thiết kế và thực hiện các bài kiểm thử, sử dụng tư duy phản biện để phân tích kết quả. Điều này mang lại cơ hội tốt hơn nhiều để tìm hiểu về ứng dụng so với các bài kiểm thử theo tập lệnh. Chúng ta không nói về thử nghiệm đặc biệt (ad-hoc testing) là sự kiểm thử ngẫu hứng. Exploratory test là một cách tiếp cận chu đáo và phức tạp hơn so với thử nghiệm đặc biệt. Nó được hướng dẫn bởi một chiến lược và hoạt động trong những ràng buộc xác định. Khi bắt đầu mỗi dự án và user story, người thử nghiệm nghĩ đến các kịch bản mà họ muốn thử. Khi các đoạn code nhỏ có thể kiểm tra trở nên khả dụng, chuyên gia kiểm thử sẽ phân tích kết quả kiểm tra và khi họ học, họ tìm thấy các lĩnh vực mới để khám phá. Exploratory test hoạt động trên hệ thống theo cách giống như cách mà người dùng cuối sẽ làm. Người thực hiện exploratory test sử dụng khả năng sáng tạo và trực giác của họ. Kết quả là, thông qua loại thử nghiệm này, nhiều lỗi nghiêm trọng nhất thường được tìm thấy.

Quadrant 4

Các loại kiểm thử rơi vào Quadrant thứ tư cũng rất quan trọng đối với phương pháp phát triển agile cũng như đối với bất kỳ loại phát triển phần mềm nào khác. Những thử nghiệm này mang tính chất công nghệ và chúng ta thảo luận về chúng theo khía cạnh kỹ thuật hơn là nghiệp vụ. Các bài kiểm thử về mặt công nghệ trong Quadrant 4 nhằm đánh giá các đặc điểm đặc trưng của sản phẩm như hiệu suất, độ mạnh mẽ và bảo mật. Các developer có thể tận dụng các bài unit test thành các bài kiểm thử hiệu suất với một công cụ đa luồng (multiple-thread tool). Tuy nhiên, việc tạo và chạy các thử nghiệm này thường đòi hỏi sử dụng các công cụ chuyên dụng và kiến thức chuyên môn bổ sung.

Có những lời phàn nàn rằng phương pháp phát triển agile dường như bỏ qua các bài kiểm thử về mặt công nghệ để đánh giá sản phẩm. Những lời phàn nàn này có thể một phần là do agile nhấn mạnh vào việc để khách hàng viết các user story. Các thành viên trong nhóm khách hàng không am tường kỹ thuật thường cho rằng sẽ có những người khác quan tâm đến vấn đề như tốc độ và bảo mật, và rằng các developer chỉ có ý định phát triển các chức năng được khách hàng ưu tiên.

Nếu chúng ta biết các yêu cầu về hiệu suất, bảo mật, sự tương tác với các hệ thống khác và các thuộc tính phi chức năng trước khi bắt đầu viết code, thì việc thiết kế và viết code sẽ thuận lợi hơn. Một số yêu cầu phi chức năng có thể thậm chí còn quan trọng hơn các chức năng người dùng thực tế. Ví dụ, nếu một trang web bán lẻ trên Internet có thời gian phản hồi là một phút, khách hàng sẽ không chờ đợi để đánh giá cao tất cả các tính năng hoạt động bình thường. Các bài kiểm thử về mặt công nghệ đánh giá sản phẩm phải được xem xét ở mọi bước của quá trình phát triển và không nên để đến cuối cùng mới thực hiện. Trong nhiều trường hợp, việc kiểm tra như vậy thậm chí nên được thực hiện trước khi kiểm tra chức năng.

Trong những năm gần đây, chúng ta đã thấy nhiều công cụ mới phù hợp với một dự án phát triển agile được cung cấp để hỗ trợ các thử nghiệm. Các công cụ tự động hóa có thể được sử dụng để tạo dữ liệu thử nghiệm, thiết lập các kịch bản thử nghiệm thủ công, thúc đẩy các thử nghiệm tự động liên tục và giúp hiểu kết quả. Tự động hóa là bắt buộc đối với một số nỗ lực như kiểm tra tải và hiệu suất (load test, performance test).

Khi  team của bạn lên kế hoạch cho một bản phát hành hoặc dự án mới, hãy thảo luận về loại thử nghiệm nào từ Quadrant 3 và 4 mà bạn cần và khi nào chúng nên được thực hiện. Đừng để các hoạt động thiết yếu như kiểm tra tải hoặc khả năng sử dụng đến cuối, khi đó có thể đã quá muộn để khắc phục sự cố.

Sử dụng các bài kiểm thử đánh giá sản phẩm

Thông tin được tạo ra trong quá trình thử nghiệm để đánh giá sản phẩm phải được đưa trở lại phía bên trái của ma trận Agile testing và được sử dụng để tạo các thử nghiệm mới nhằm thúc đẩy sự phát triển trong tương lai. Ví dụ: nếu máy chủ bị lỗi khi tải bình thường, sẽ cần các user story và thử nghiệm mới để thúc đẩy một kiến trúc có khả năng mở rộng hơn. Sử dụng các Quadrant sẽ giúp bạn lập kế hoạch các bài kiểm thử đánh giá sản phẩm cũng như các bài kiểm thử thúc đẩy sự phát triển. Hãy suy nghĩ về lý do tại sao bạn kiểm thử để đảm bảo rằng các bài kiểm thử được thực hiện ở giai đoạn phát triển phù hợp.

Các iteration rất ngắn của phương pháp phát triển agile mang lại cho team của bạn cơ hội học hỏi và thử nghiệm với các Quadrant thử nghiệm khác nhau. Nếu bạn phát hiện rằng thiết kế của mình không có khả năng mở rộng, hãy bắt đầu thử nghiệm tải sớm hơn với các user story hoặc dự án tiếp theo trong tương lai. Nếu việc demo cuối iteration tiết lộ rằng nhóm đã hiểu sai các yêu cầu của customer, có thể bạn chưa làm tốt công việc viết các bài kiểm thử khách hàng để hướng dẫn phát triển. Nếu nhóm phải thực hiện refactoring cần thiết, có thể các unit test và component test không cung cấp đủ phạm vi kiểm tra. Sử dụng các Quadrant kiểm thử agile để giúp đảm bảo tất cả các thử nghiệm cần thiết được thực hiện vào đúng thời điểm.

• Khi một user story “Done”

Đối với hầu hết các sản phẩm, chúng ta sẽ cần tất cả bốn hạng mục thử nghiệm để cảm thấy tự tin rằng chúng ta đang cung cấp đúng giá trị. Không phải mọi user story đều yêu cầu kiểm tra bảo mật, nhưng bạn không nên bỏ qua nó chỉ vì bạn không nghĩ ra.

Các bài kiểm thử về công nghệ và về nghiệp vụ nhằm thúc đẩy quá trình phát triển là trọng tâm của phương pháp phát triển agile, cho dù bạn có thực sự viết task card cho chúng hay không. Kiểm thử cung cấp cho team của bạn cơ hội tốt nhất để hoàn thành từng user story. Các bài kiểm thử từ cả bốn Quadrant sẽ cho nhóm biết khi nào mỗi tính năng đã đáp ứng các tiêu chí của khách hàng về chức năng và chất lượng.

Câu chuyện của Lisa

Nhóm của tôi sử dụng “stock” cards để đảm bảo rằng chúng tôi luôn xem xét tất cả các loại kiểm tra khác nhau. Khi unit testing còn chưa trở thành thói quen, chúng tôi đã viết thẻ Unit testing cho mỗi user story trên bảng. Thẻ kiểm tra “end to end” nhắc nhở các developer hoàn thành công việc kiểm tra tích hợp (integration test) và đảm bảo tất cả các phần của code hoạt động cùng nhau. “Security” cards cũng được xem xét cho mỗi user story và nếu phù hợp, hãy đưa lên bảng (task board) để mọi người có ý thức giữ dữ liệu an toàn. Các thẻ tác vụ (task cards) về code giao diện người dùng đảm bảo rằng chúng tôi không quên thực hiện việc này. Nó cũng giúp chúng tôi bắt đầu thử nghiệm khám phá (exploratory test) cùng với khách hàng từ sớm. Tất cả những cards này giúp chúng tôi giải quyết các khía cạnh khác nhau của chất lượng sản phẩm. Từng bài kiểm thử về công nghệ có phạm vi kiểm thử vượt ngoài một user story duy nhất chiếm một hàng riêng trên Story board. Chúng tôi sử dụng các user story để thể hiện công việc đánh giá các công cụ kiểm tra tải và thiết lập các đường cơ sở về hiệu suất.

Chia sẻ trách nhiệm

Development team cần có nhiều chuyên môn khác nhau để bao quát tất cả các Quadrant kiểm thử agile. Các developer nên viết các bài kiểm thử liên quan đến công nghệ hỗ trợ lập trình, nhưng họ có thể cần trợ giúp vào những thời điểm khác nhau từ chuyên gia kiểm thử, nhà thiết kế cơ sở dữ liệu, quản trị viên hệ thống và cấu hình đặc biệt. Chuyên gia kiểm thử chịu trách nhiệm chính về các bài kiểm thử về nghiệp vụ song song với khách hàng, nhưng các developer tham gia thiết kế và tự động hóa các bài kiểm thử, trong khi các usability test cần đến các chuyên gia khác. Quadrant thứ tư, với các bài kiểm thử về mặt công nghệ đánh giá sản phẩm, có thể yêu cầu chuyên gia trong lĩnh vực này từ bên ngoài. Bất kể nguồn nhân lực nào phải được đưa vào từ bên ngoài nhóm phát triển, nhóm vẫn chịu trách nhiệm hoàn thành tất cả bốn Quadrant của thử nghiệm.

Chúng tôi tin rằng một team thành công là team mà tất cả mọi người đều tham gia vào quá trình tạo ra sản phẩm và rằng mọi người đều chia sẻ trách nhiệm chung khi có sự cố cần khắc phục. Việc thực hiện đầy đủ các phương pháp và công cụ cho phép chúng ta giải quyết cả bốn Quadrant của thử nghiệm agile có thể khá khó khăn, nhưng niềm vui khi triển khai một sản phẩm thành công là điều đáng để nỗ lực.

• Quản lý technical debt

Ward Cunningham đã đặt ra thuật ngữ “technical debt” vào năm 1992, nhưng chúng ta chắc chắn đã trải nghiệm nó trong suốt sự nghiệp phát triển phần mềm của mình! Technical debt sẽ tích tụ dần khi nhóm phát triển sử dụng các phím tắt, hack các bản sửa lỗi nhanh hoặc bỏ qua viết các bài kiểm thử tự động hóa vì bị sức ép của lịch release. Code base lớn dần sẽ ngày càng khó bảo trì hơn. Giống như nợ tài chính, các “lãi suất nợ kỹ thuật” ở dạng chi phí bảo trì cao hơn và khả năng định vị lỗi của team càng thấp hơn. Các developer sợ thực hiện bất kỳ thay đổi nào, không cố gắng thực hiện refactoring để cải thiện code, vì lo ngại code bị phá vỡ. Đôi khi sự sợ hãi này tồn tại bởi vì họ không thể hiểu được code, và đôi khi là do trong tay không có sẵn bài kiểm thử để phát hiện lỗi.

Mỗi Quadrant trong ma trận kiểm thử Agile đóng một vai trò trong việc giữ technical debt ở mức có thể quản lý được. Các bài kiểm thử về công nghệ hỗ trợ viết code và thiết kế giúp giữ cho code có thể bảo trì được. Quá trình tích hợp và xây dựng tự động chạy các bài unit test là điều bắt buộc để giảm thiểu technical debt. Việc nắm bắt các lỗi ở cấp độ đơn vị trong quá trình viết code sẽ giúp chuyên gia kiểm thử tập trung vào các bài kiểm thử về nghiệp vụ để hướng dẫn nhóm và cải thiện sản phẩm. Stress test và load test kịp thời sẽ cho phép team biết liệu kiến trúc sản phẩm có phù hợp với đòi hỏi của tải vận hành thực tế hay không.

Dành thời gian và áp dụng các nguồn lực và thực tiễn để giảm thiểu technical debt, một team sẽ có thời gian và nguồn lực để thực hiện việc kiểm tra cần thiết đảm bảo chất lượng sản phẩm. Việc áp dụng các nguyên tắc agile để thực hiện tốt từng loại thử nghiệm ở mỗi cấp độ sẽ giảm thiểu technical debt.

• Kiểm thử trong bối cảnh cụ thể

Cần lưu ý rằng mỗi tổ chức, sản phẩm và team đều có tình huống riêng biệt và mỗi tổ chức cần phải làm những gì phù hợp với tình huống riêng của mình. Agile testing matrix là một công cụ, không phải một quy tắc. Nhu cầu của một sản phẩm hoặc dự án cụ thể có thể phát triển nhanh chóng theo thời gian. Các Quadrant là một cách hữu ích để đảm bảo team của bạn đang xem xét tất cả các khía cạnh khác nhau của thử nghiệm để đạt đến trạng thái “Done”

Chúng ta có thể mượn các nguyên tắc quan trọng sau đây của trường phái kiểm thử theo ngữ cảnh khi lập kế hoạch kiểm thử cho từng user story, iteration và release.

■ Giá trị của bất kỳ thực hành nào phụ thuộc vào ngữ cảnh của nó.

■ Có những thực hành tốt trong từng ngữ cảnh cụ thể, nhưng không có thực hành tốt nhất.

■ Mọi người, làm việc cùng nhau, là yếu tố quan trọng nhất trong bối cảnh của bất kỳ dự án nào.

■ Các dự án diễn ra theo thời gian theo những cách thường không thể đoán trước được.

■ Sản phẩm là một giải pháp. Nếu sự cố không được giải quyết, sản phẩm sẽ không hoạt động.

■ Kiểm thử phần mềm là một quá trình trí tuệ đầy thử thách.

■ Chỉ thông qua khả năng phán đoán và kỹ năng, được thực hiện một cách hợp tác trong toàn bộ dự án, chúng ta mới có thể làm những việc phù hợp vào đúng thời điểm để kiểm tra hiệu quả sản phẩm của mình.

Các Quadrant giúp cung cấp bối cảnh cho các phương pháp agile testing, nhưng team của bạn sẽ phải thích ứng. Chuyên gia kiểm thử giúp cung cấp phản hồi mà nhóm cần để điều chỉnh và làm việc tốt hơn. Sử dụng các kỹ năng của bạn để thu hút khách hàng trong mỗi iteration và mỗi lần phát hành. Nhận thức rõ khi nào nhóm của bạn cần kỹ năng hoặc kiến thức ngoài những gì hiện có.

Bộ tứ Quadrant thử nghiệm agile cung cấp một checklist để đảm bảo bạn đã tính đến tất cả các cơ sở thử nghiệm của mình. Hãy trả lời những câu hỏi như sau khi lên kế hoạch kiểm thử sản phẩm:

■ Chúng ta có đang sử dụng các bài unit test và component test để giúp chúng ta tìm ra thiết kế phù hợp cho ứng dụng đang phát triển hay không?

■ Chúng ta có quy trình xây dựng tự động chạy các bài unit test tự động để có được phản hồi nhanh không?

■ Các thử nghiệm về nghiệp vụ của chúng ta có giúp làm ra một sản phẩm phù hợp với nhu cầu khách hàng không?

■ Chúng ta có nắm bắt được các ví dụ về chức năng nghiệp vụ phù hợp về hành vi mong muốn của hệ thống ứng dụng không? Chúng ta có cần bổ sung không? Chúng ta có đang xây dựng các bài thử nghiệm của mình trên những ví dụ này không?

■ Chúng ta có hiển thị các nguyên mẫu UI (giao diện người dùng) và báo cáo cho người dùng trước khi chúng ta bắt đầu viết code cho chúng không? Người dùng có thể liên hệ các giao diện này với cách thức phần mềm hoàn thiện sẽ hoạt động không?

■ Chúng ta có dành đủ thời gian cho exploratory test không? Làm thế nào để chúng ta giải quyết bài toán về usability testing? Chúng ta có thu hút được sự tham gia tích cực của khách hàng không?

■ Chúng ta có xem xét các yêu cầu công nghệ như hiệu suất và bảo mật đủ sớm trong chu kỳ phát triển không? Chúng ta có các công cụ phù hợp để thực hiện các bài “ility” test không (security, maintainability, interoperability, compatibility, reliability, installability)?

Bạn hãy sử dụng ma trận Agile testing để bắt đầu. Làm thí nghiệm (experiments) và các buổi retrospective để tiếp tục cải thiện nỗ lực của bạn trong việc hướng dẫn phát triển bằng các thử nghiệm và dựa trên những gì bạn học được về sản phẩm của mình thông qua thử nghiệm.

• Tóm lược

Bốn Quadrant đóng vai trò là sự hướng dẫn để đảm bảo rằng tất cả các khía cạnh của chất lượng sản phẩm đều được đề cập trong quá trình thử nghiệm và phát triển.

■ Các bài kiểm thử hỗ trợ development team có thể được sử dụng để thúc đẩy các yêu cầu.

■ Các bài kiểm thử đánh giá sản phẩm giúp chúng ta suy nghĩ về tất cả các khía cạnh của chất lượng.

■ Sử dụng các Quadrant để biết khi nào bạn hoàn thành và đảm bảo cả nhóm cùng chịu trách nhiệm về việc bao gồm cả bốn Quadrant của ma trận.

■ Quản lý  technical debt là nền tảng cần thiết cho bất kỳ nhóm phát triển phần mềm nào.

■ Bối cảnh cụ thể phải luôn là yếu tố dẫn dắt các nỗ lực thử nghiệm của chúng ta.

Theo Lisa Crispin

Agile Testing