Business-facing Tests

Phát triển được dẫn dắt bởi kiểm thử nghiệp vụ

Trong chương trước, chúng ta đã nói về các bài kiểm thử do developer thực hiện, những bài kiểm thử cấp thấp đó giúp developer đảm bảo rằng họ đã viết code đúng. Nhưng làm thế nào để biết đúng thứ cần code? Trong các phương pháp quản lý dự án theo giai đoạn và theo cổng kiểm soát (phased, gated methodology), chúng ta cố gắng giải quyết vấn đề đó bằng cách thu thập các yêu cầu từ sớm và thêm càng nhiều chi tiết càng tốt. Trong các dự án agile, chúng ta đặt tất cả niềm tin vào các thẻ story (story card) và các bài kiểm thử mà khách hàng có thể hiểu để giúp viết code đúng. Các bài kiểm thử “khách hàng có thể hiểu được” chính là chủ đề của chương này.

Phát triển được dẫn dắt bởi kiểm thử nghiệp vụ

Chúng ta sẽ bắt đầu một iteration mà không có nhiều thông tin hơn ngoài những gì viết trên thẻ story, giống như ví dụ trong hình dưới đây.

Trên đó không có nhiều thông tin cho lắm, và mục đích thực sự của thẻ story cũng không phải là để chứa nhiều thông tin. User story là một bản ghi ngắn gọn về chức năng mong muốn và là một công cụ để lập kế hoạch và sắp xếp thứ tự ưu tiên cho công việc của dự án. Trong một dự án waterfall truyền thống, development team có thể nhận một tài liệu yêu cầu dài dòng bao gồm mọi chi tiết của tập các tính năng (feature). Trong một dự án agile, nhóm khách hàng và development team bắt đầu bằng một cuộc trò chuyện dựa trên user story. Team cần có các yêu cầu thuộc một dạng nào đó và cần chúng ở mức độ chi tiết vừa đủ cho phép họ bắt đầu viết code gần như ngay lập tức. Để làm được điều này, chúng ta cần các ví dụ (example) để chuyển thành các bài kiểm thử mà sẽ cho phép xác nhận những tính năng khách hàng thực sự muốn có.

Các bài kiểm thử nghiệp vụ này nhằm xác nhận sự thỏa mãn các yêu cầu nghiệp vụ. Những bài kiểm thử giúp cung cấp bức tranh toàn cảnh và đủ chi tiết để hướng dẫn viết code. Các bài kiểm thử nghiệp vụ thể hiện các yêu cầu dựa trên các ví dụ và sử dụng ngôn ngữ và định dạng mà cả khách hàng và development team đều có thể hiểu được. Các ví dụ tạo cơ sở cho việc hiểu được hành vi mong muốn của từng tính năng và chúng ta sử dụng các ví dụ đó làm cơ sở để viết các bài kiểm thử user story thuộc Quadrant 2.

Kiểm thử nghiệp vụ còn được gọi là “customer-facing test” hay “story test” hoặc “acceptance test” (kiểm thử chấp nhận). Thuật ngữ “acceptance test” đặc biệt dễ gây nhầm lẫn vì khiến người ta nghĩ đến “user acceptance test” (kiểm thử nghiệm thu bởi người sử dụng). Trong bối cảnh của phương pháp agile, các bài “user acceptance test” thường đề cập đến các bài kiểm thử nghiệp vụ, nhưng thuật ngữ này cũng có thể bao gồm các bài kiểm thử kỹ thuật thuộc Quadrant 4, chẳng hạn như tiêu chí của khách hàng về hiệu năng hoạt động hệ thống hoặc sự bảo mật thông tin. Trong chương này, chúng ta sẽ chỉ thảo luận về những bài kiểm thử nghiệp vụ hỗ trợ development team bằng cách dẫn dắt sự phát triển và cung cấp phản hồi nhanh chóng.

Các bài kiểm thử nghiệp vụ trong Quadrant 2 được viết cho mỗi user story trước khi bắt đầu viết code, vì chúng giúp development team hiểu về code cần viết. Giống như các bài kiểm thử trong Quadrant I, các bài kiểm thử này dẫn dắt sự phát triển, nhưng ở cấp độ cao hơn. Các kiểm thử ở Quadrant I, tức unit test và component test, đảm bảo chất lượng nội bộ, tối đa hóa năng suất của team và giảm thiểu nợ kỹ thuật (technical debt). Kiểm thử thuộc Quadrant 2 nhằm xác định và kiểm chứng chất lượng bên ngoài tức hành vi của phần mềm, đồng thời giúp chúng ta biết khi nào chúng ta hoàn thành.

Các bài kiểm thử nghiệp vụ dẫn dắt quá trình viết code thường được viết trong một file có thể chạy (executable file) và được tự động hóa, để các thành viên trong team có thể chạy các bài kiểm thử thường xuyên mỗi khi họ muốn xem liệu chức năng đang được code có hoạt động như mong muốn hay không. Các kiểm thử này, hoặc một số tập hợp con của chúng, sẽ trở thành một phần của bộ các bài kiểm thử hồi quy (regression test) chạy tự động để đảm bảo việc phát triển trong tương lai không vô tình gây ra các hành vi không mong muốn của hệ thống.

Khi chúng ta thảo luận về các user story và ví dụ về các hành vi mong muốn, chúng ta cũng cần phải xác định các yêu cầu phi chức năng như hiệu năng hoạt động, sự bảo mật và khả năng sử dụng. Chúng ta cũng sẽ lưu ý về các tình huống cho kiểm thử khám phá thủ công (exploratory test). Chúng ta sẽ bàn về các loại hoạt động thử nghiệm này trong các chương về Quadrant 3 và 4.

Chúng ta nghe thấy rất nhiều câu hỏi liên quan đến cách các agile team nhận được yêu cầu. Làm thế nào để biết code chúng ta viết phải làm được những gì? Bằng cách nào chúng ta có đủ thông tin để bắt đầu viết code? Làm thế nào để chúng ta khiến cho các khách hàng nói cùng một tiếng nói và trình bày rõ ràng nhu cầu của họ? Chúng ta bắt đầu từ đâu với mỗi user story? Làm thế nào để khách hàng cung cấp cho chúng ta các ví dụ? Làm thế nào để chúng ta sử dụng các ví dụ đó để viết các bài kiểm thử user story?

Chương này giải thích chiến lược của chúng ta để tạo ra các bài kiểm thử nghiệp vụ hỗ trợ team khi phát triển từng user story. Hãy cùng bắt đầu bằng cách thảo luận về các yêu cầu.

Yêu cầu vs user story

Đối với mọi development team, dù là agile hay không, đều phải mất công sức vật lộn với các yêu cầu. Các team thực hiện các dự án theo lối waterfall truyền thống có thể đầu tư hàng tháng trời để thu thập các yêu cầu để rồi các yêu cầu đó bị sai hoặc nhanh chóng bị lỗi thời. Các team ở các dự án thuộc dạng hỗn loạn (chaos projects) thậm chí có thể không có yêu cầu gì cả, và những developer chuyên nghiệp tự đưa ra dự đoán tốt nhất của họ về cách một tính năng sẽ phải hoạt động.

Phát triển kiểu agile trong một dự án bao hàm sự thay đổi. Nhưng điều gì sẽ xảy ra khi các yêu cầu thay đổi trong một iteration? Chúng ta không muốn một khoảng thời gian thu thập yêu cầu kéo dài trước khi bắt đầu viết code, nhưng làm thế nào chúng ta có thể chắc chắn rằng chúng ta (và các khách hàng của chúng ta) thực sự hiểu về các chi tiết của mỗi user story?

Trong quá trình phát triển agile, các tính năng mới thường xuất hiện dưới dạng các user story hoặc nhóm các user story, do nhóm khách hàng (customer team) viết ra. Viết user story không phải là tìm ra chi tiết triển khai, mặc dù các cuộc thảo luận sơ bộ trước đó có ảnh hưởng đến sự phụ thuộc lẫn nhau của các user story và số lượng user story được tạo ra. Sẽ rất hữu ích nếu một số thành viên của development team có thể tham gia vào các phiên viết user story để có thể cung cấp đầu vào cho các user story và giúp đảm bảo rằng các yêu cầu kỹ thuật (technical story) được gộp vào product backlog. Các developer và chuyên viên kiểm thử cũng có thể giúp khách hàng chia nhỏ các user story theo kích thước phù hợp, đề xuất các lựa chọn thay thế tốt hơn để triển khai và thảo luận về sự phụ thuộc giữa các user story.

Bản thân các user story không cung cấp nhiều chi tiết về chức năng mong muốn. Chúng thường chỉ là một câu thể hiện ai muốn tính năng, tính năng là gì và tại sao họ muốn tính năng đó. Ví dụ, “Là một người mua sắm trên Internet. Tôi cần một cách để xóa các mặt hàng khỏi giỏ hàng của mình để tôi không phải mua các món hàng không mong muốn” sẽ để lại rất nhiều chỗ trống cho trí tưởng tượng. User story chỉ nhằm mục đích khởi đầu cho một cuộc đối thoại sẽ diễn ra giữa các chuyên gia nghiệp vụ và development team. Nếu các thành viên trong development team hiểu vấn đề mà khách hàng đang cố gắng giải quyết, họ có thể đề xuất các giải pháp thay thế đơn giản hơn để sử dụng và triển khai.

Trong các cuộc đối thoại giữa khách hàng và developer, các agile team mở rộng các user story cho đến khi họ có đủ thông tin để viết code đúng. Người kiểm thử giúp khơi gợi ra các ví dụ và ngữ cảnh cho mỗi user story, và giúp khách hàng viết ra các bài kiểm thử user story đó. Những bài kiểm thử này hướng dẫn các developer khi họ viết code và giúp team biết khi nào thì code đã đáp ứng đủ các điều kiện cần thỏa mãn khách hàng. Nếu team của bạn có các trường hợp sử dụng (use case), họ có thể giúp bổ sung ví dụ, hoặc bài kiểm thử coaching test, để làm rõ chi tiết về chức năng cần thiết (xem hình dưới đây)

Trong phát triển agile, chúng ta chấp nhận thực tế rằng chúng ta sẽ không bao giờ hiểu được tất cả các yêu cầu của một user story ngay từ đầu. Sau khi hoàn tất đoạn code mà đã pass được các bài kiểm thử user story, chúng ta vẫn cần thực hiện thêm việc kiểm thử để hiểu rõ hơn về các yêu cầu và cách thức các tính năng sẽ hoạt động.

Sau khi khách hàng có cơ hội trông thấy những gì development team đang cung cấp, họ có thể nảy sinh những ý tưởng khác nhau về cách họ muốn tính năng đó hoạt động. Thông thường khách hàng có một ý tưởng mơ hồ về những gì họ muốn và rất khó xác định chính xác đó là gì. Development team dành cả một iteration làm việc với khách hàng hoặc đại diện cho khách hàng (customer proxy) để có thể chỉ cung cấp phần hạt nhân của một giải pháp. Nhóm tiếp tục tinh chỉnh chức năng qua nhiều iteration nữa cho đến khi xác định rõ và cung cấp được một tính năng (feature).

Đặc tính phát triển theo các vòng lặp (iteration) giải thích lý do vì sao phương pháp agile cổ súy cho các bản phát hành nhỏ (small release) và cho việc cung cấp từng phần chức năng nhỏ tại một thời điểm. Nếu khách hàng của chúng ta không hài lòng với hành vi của code mà chúng ta phân phối trong iteration này, chúng ta có thể nhanh chóng khắc phục điều đó trong iteration tiếp theo, nếu khách hàng cho rằng sự thay đổi là cần thiết. Thay đổi yêu cầu (từ khách hàng) là điều không thể tránh khỏi.

Các bài kiểm thử cần bao hàm phạm vi nhiều hơn là các yêu cầu của khách hàng. Chúng ta cần kiểm tra các hậu điều kiện (post conditions), kiểm tra sự tác động lên toàn bộ hệ thống và sự tích hợp với các hệ thống khác. Chúng ta cố gắng xác định các rủi ro và biện pháp giảm thiểu những rủi ro đó bằng các bài kiểm thử cần thiết. Tất cả các yếu tố này dẫn dắt quá trình viết code của chúng ta.

Ngôn ngữ chung

Chúng ta cũng có thể sử dụng các kiểm thử để cung cấp một ngôn ngữ chung mà cả development team và chuyên viên nghiệp vụ đều hiểu. Như Brian Marick (2001) đã chỉ ra, một ngôn ngữ chung giúp các chuyên viên nghiệp vụ hình dung ra các tính năng họ muốn. Nó giúp các developer tạo ra code được thiết kế tốt, dễ mở rộng. Các ví dụ thực tế về hành vi mong muốn và không mong muốn có thể được thể hiện để cả phía nghiệp vụ và kỹ thuật hiểu được. Những người có nền tảng và quan điểm khác nhau đều có thể truy cập hình ảnh, sơ đồ, bảng tính và nguyên mẫu. Chúng ta có thể sử dụng các công cụ này để tìm các ví dụ và sau đó dễ dàng biến các ví dụ đó thành các bài kiểm thử. Các bài kiểm thử cần được viết theo cách mà người dùng nghiệp vụ có thể hiểu được khi đọc chúng nhưng đồng thời nhóm kỹ thuật vẫn có thể hiểu để thực hiện viết code được.

Các bài kiểm thử nghiệp vụ cũng giúp xác định phạm vi để mọi người biết đâu là một phần của user story và đâu là không. Nhiều khuôn khổ thử nghiệm (test framework) hiện nay cho phép các team tạo một ngôn ngữ chuyên môn (domain language) và định nghĩa ra các bài kiểm thử bằng ngôn ngữ đó. FIT (Framework for Integrated Test) là một trong số framework như vậy.

Một khách hàng hoàn hảo

Andy Pols viết trong một blog kể về việc một khách hàng của anh đã yêu cầu một bài kiểm thử, viết nó và nhận ra rằng user story được yêu cầu té ra là nằm ngoài phạm vi.

Trong một dự án gần đây, khách hàng của chúng tôi rất nhiệt tình với các bài kiểm thử Fit của chúng tôi đến nỗi anh ấy đã vô cùng khó chịu khi tôi phát triển một user story mà không có bài kiểm thử Fit. Anh ấy từ chối để hệ thống go live cho đến khi chúng tôi có bài kiểm thử Fit.

Story được đề cập ở đây nặng tính kỹ thuật và liên quan đến việc gửi một thông điệp XML nhất định đến một hệ thống bên ngoài. Chúng tôi không tìm ra được bài kiểm thử Fit sẽ phải như thế nào đối với yêu cầu này. Việc cố gắng nhồi nhét XML message đó cùng với tất cả các chi tiết phức tạp của nó vào trong bài kiểm thử Fit sẽ không có chút ích lợi nào vì XML message chỉ là một sản phẩm kỹ thuật trung gian (technical artifact) không phục vụ gì cho nghiệp vụ. Khách hàng không có mặt để thảo luận về điều này, vì vậy tôi cứ tiếp tục và thực hiện user story (rất sai trái!). Điều khách hàng muốn là đảm bảo rằng chúng tô đang gửi thông tin sản phẩm chính xác trong XML message. Để giải quyết vấn đề, tôi đề xuất rằng nên có một bài kiểm thử Fit cho thấy cách thức mà các thông tin thuộc tính của sản phẩm được ánh xạ vào XML message bằng XPath, mặc dù thâm tâm tôi cho rằng điều này quá sâu về kỹ thuật đối với một người dùng nghiệp vụ.

Chúng tôi đã gửi cho khách hàng một vài đường link giải thích về XPath là gì, để anh ta có thể tự tìm hiểu xem liệu đây có phải là giải pháp tốt hay không. Trước sự ngạc nhiên của tôi, anh ấy rất vui mừng với XPath và tự tay điền nội dung vào bài kiểm thử Fit. Điều thú vị là ngay sau khi anh ấy biết nội dung thông điệp XML và cấu trúc của nó như thế nào, anh ấy đã nhận ra rằng nó không thực sự hỗ trợ cho nghiệp vụ – chúng tôi đã gửi thông tin nằm ngoài phạm vi và tính năng này nên được cung cấp bởi một hệ thống khác. Anh ấy cũng tỏ ra thận trọng về tốc độ thực hiện mà một team bên ngoài khác có thể bổ sung các sản phẩm mới do tính chất phức tạp của XML message. Hầu hết những người mà chúng tôi kể về kinh nghiệm này đều cho rằng chúng tôi đã gặp được một khách hàng hoàn hảo!

Ngay cả khi khách hàng của bạn không hoàn hảo, việc mời họ tham gia vào quá trình viết các bài kiểm thử nghiệp vụ sẽ cho họ cơ hội nhận biết được các chức năng nằm ngoài phạm vi của user story. Chúng ta nên cố gắng viết các bài kiểm thử nghiệp vụ mà khách hàng có thể đọc và hiểu đầy đủ. Đôi khi chúng ta đã đánh giá khả năng khách hàng quá thấp. Hãy cộng tác với khách hàng của bạn để tìm ra một công cụ và định dạng viết bài kiểm thử phù hợp với cả khách hàng và development team.

Có thể nói rằng khách hàng của chúng ta là người sẽ cung cấp cho chúng ta những ví dụ mà chúng ta cần có để chúng ta hiểu được giá trị mà mỗi user story sẽ mang lại. Nhưng nếu chính khách hàng không biết giải thích những gì họ muốn thì sao? Trong phần tiếp theo, chúng ta sẽ gợi ý các cách giúp khách hàng xác định các điều kiện cần thỏa mãn của họ.

Khơi gợi ra yêu cầu

Nếu bạn đã từng là khách hàng yêu cầu một tính năng phần mềm cụ thể, bạn sẽ biết khó khăn như thế nào để trình bày chính xác những gì bạn muốn. Thông thường bạn không biết chính xác những gì bạn muốn cho đến khi bạn có thể nhìn thấy, cảm nhận, chạm vào và sử dụng phần mềm. Chúng ta có nhiều cách để giúp khách hàng hiểu rõ những gì họ muốn.

Cách thứ nhất: đặt các câu hỏi

Bắt đầu bằng cách đặt câu hỏi. Người kiểm thử có thể đặc biệt giỏi trong việc đặt nhiều câu hỏi khác nhau bởi vì họ có ý thức về bức tranh toàn cảnh, các khía cạnh nghiệp vụ và kỹ thuật của user story, và luôn nghĩ đến sự xuất hiện của người dùng cuối. Các loại câu hỏi thông dụng để hỏi khách hàng là:

User story này có đang nhằm giải quyết một vấn đề không?
Nếu vậy, vấn đề chúng ta đang cố gắng giải quyết là gì?
Chúng ta có thể thực hiện một giải pháp mà tránh không cần giải quyết được vấn đề đó không?
User story sẽ mang lại giá trị cho doanh nghiệp như thế nào?
Người dùng cuối của tính năng này là ai?
Giá trị nào họ sẽ nhận được từ nó?
Người dùng sẽ làm gì ngay trước và ngay sau khi họ sử dụng tính năng đó?
Làm thế nào để chúng ta biết chúng ta đã hoàn thành user story này?

Một câu hỏi mà Lisa thích hỏi là “Điều tồi tệ nhất có thể xảy ra là gì?” Các tình huống xấu nhất có xu hướng làm nảy sinh ý tưởng mới. Chúng cũng giúp chúng ta xem xét rủi ro và tập trung thử nghiệm vào các lĩnh vực quan trọng. Một câu hỏi hay khác là, “Tình huống tốt nhất có thể xảy ra là gì?” Câu hỏi này thường tạo ra bài kiểm thử “happy path” của chúng ta, nhưng nó cũng có thể khám phá ra một số giả định ẩn.

Cách thứ hai: sử dụng các ví dụ

Quan trọng nhất, hãy yêu cầu khách hàng cung cấp cho bạn các ví dụ cụ thể về cách hoạt động của tính năng được yêu cầu. Giả sử một user story là về việc xóa các mặt hàng ra khỏi một giỏ hàng trực tuyến. Yêu cầu khách hàng vẽ một bức tranh trên bảng trắng giải thích về cách xóa mặt hàng khỏi giỏ. Họ có muốn những tính năng bổ sung nào đó, chẳng hạn như bước xác nhận lại hoặc cơ hội nhìn thấy mặt hàng đã xóa trong trường hợp họ muốn lấy lại sau này không? Họ sẽ mong đợi điều gì sẽ xảy ra nếu việc xóa không thể thực hiện được?

Các ví dụ có thể tạo cơ sở cho các kiểm thử của chúng ta. Thách thức của chúng ta là phải nắm bắt được các ví dụ, được diễn đạt bằng ngôn ngữ nghiệp vụ đặc thù (domain language), dưới dạng các bài kiểm thử thực sự có thể được thực hiện. Một số khách hàng cảm thấy thoải mái khi thể hiện bài kiểm thử bằng công cụ kiểm thử như Fit hoặc FitNesse miễn là họ có thể viết chúng bằng ngôn ngữ nghiệp vụ của họ.

Hãy cùng khám phá sự khác biệt giữa một ví dụ và một bài kiểm thử với một user story đơn giản (xem hình dưới đây). Mọi người thường bị nhầm lẫn giữa hai thuật ngữ này.

Một ví dụ tương ứng với user story này sẽ giống như sau:

“Có 5 món hàng (item) trên một trang. Tôi muốn chọn món số 1 với giá $20.25 và đặt nó vào giỏ hàng (shopping cart). Tôi sang trang tiếp theo, trong đó có 5 món hàng nữa. Tôi chọn một món thứ hai trên trang đó với giá $5.38 và đưa nó vào giỏ của tôi. Khi tôi xác nhận đã chọn xong, nó sẽ hiển thị cả món hàng tôi chọn ở trang trước, và món hàng tôi chọn ở trang hiện tại, với tổng số tiền của giỏ hàng là $25.63”

Bài kiểm thử có thể trông hơi khác một chút. Chúng ta sẽ sử dụng định dạng Fit trong Bảng dưới đây để bạn biết cách thể hiện một bài kiểm thử.

Bài kiểm thử sẽ nắm bắt ví dụ ở định dạng có thể thực thi. Nó có thể không sử dụng chính xác các input giống như trong ví dụ, nhưng nó chứa đựng các kịch bản người dùng (user scenario) mẫu. Bạn có thể viết thêm nhiều trường hợp kiểm thử (test case) để kiểm tra các điều kiện biên, trường hợp edge case và các kịch bản khác.

Cách thứ ba: nhiều góc nhìn khác nhau

Mỗi ví dụ hoặc bài kiểm thử có một góc nhìn tương ứng. Những người khác nhau sẽ viết các bài kiểm thử hoặc cho ví dụ khác nhau từ góc nhìn độc đáo của họ. Chúng ta muốn ghi lại nhiều góc nhìn khác nhau nhất có thể, vì vậy hãy nghĩ về các nhóm người dùng khác nhau của bạn.

Thu thập đúng các yêu cầu là một hoạt động mà các thành viên trong team với nhiều vai trò khác nhau có thể tham gia. Các chuyên gia phân tích nghiệp vụ, chuyên gia về nghiệp vụ, các developer và các thành viên khác nhau của nhóm khách hàng (customer team) đều có một số điều cần đóng góp. Hãy nghĩ về các bên liên quan khác, chẳng hạn như nhóm hỗ trợ sản phẩm (support team) của bạn. Họ có một góc nhìn rất độc đáo.

Chúng ta thường quên các yêu cầu phi chức năng như “Hệ thống cần hoạt động trong khung thời gian nào? Điều gì sẽ xảy ra nếu hệ thống bị sự cố? Nếu chúng ta có middleware để chuyển các message, chúng ta có dự kiến kích thước message đủ lớn để chúng ta phải tính đến sự mất mát trong quá trình truyền không? Hay chúng sẽ có kích thước cố định? Điều gì sẽ xảy ra nếu không có lưu lượng nào trong nhiều giờ? Hệ thống có cần gửi cảnh báo cho ai đó không? ” Danh sách các kiểm thử cho các loại yêu cầu này thường rơi vào Quadrant 3 và 4, nhưng chúng ta cần phải viết các bài kiểm thử để đảm bảo các yêu cầu như vậy được hoàn thành.

Các ví dụ mà khách hàng cung cấp cho nhóm dự án sẽ nhanh chóng được bổ sung theo thời gian. Chúng ta có thực sự phải biến tất cả những ví dụ này thành các bài kiểm thử có thể thực thi không? Không cần như vậy, nếu như khách hàng luôn có mặt bên cạnh để báo cho chúng ta biết liệu code được viết đã hoạt động đúng theo cách họ muốn hay chưa. Với kỹ thuật chẳng hạn như tạo nguyên mẫu trên giấy, các ý tưởng thiết kế giao diện người dùng có thể được thử nghiệm trước khi chúng ta viết code.

Kỹ thuật kiểm thử Wizard of Oz

Gerard Meszaros, một Certified ScrumMaster và Agile coach, đã kể kinh nghiệm sau đây về kỹ thuật kiểm thử Wizard of Oz trong các dự án Agile.

Chúng tôi nghĩ rằng chúng tôi đã sẵn sàng để phát hành phần mềm. Chúng tôi đã xây dựng nó theo từng increment cho mỗi iteration, dưới sự hướng dẫn của một khách hàng tại chỗ, người đã thực hiện sắp xếp ưu tiên các chức năng dựa trên nhu cầu để chuyển sang khâu kiểm thử tích hợp với sự tham gia của các đối tác kinh doanh. Chúng tôi cố tình trì hoãn thực hiện chức năng báo cáo và bảo trì master data trong các iteration muộn hơn để đảm bảo chúng tôi đã phát triển đủ các chức năng cần thiết để sẵn sàng kiểm thử tích hợp. Quá trình kiểm thử tích hợp diễn ra tốt đẹp, chỉ với một vài lỗi được ghi lại (tất cả đều liên quan đến việc bỏ lỡ hoặc hiểu nhầm chức năng). Tiếp đó chúng tôi đã triển khai việc bảo trì master data song song với việc thử nghiệm tích hợp cho những iteration gần nhất trước khi chuyển sang làm thử nghiệm chấp nhận của người dùng (UAT). Nhưng chúng tôi bị một cú sốc nặng. Khách hàng ghét chức năng bảo trì và báo cáo! Họ ghi lại quá nhiều lỗi và nhiều “bắt buộc phải cải tiến” đến mức chúng tôi phải trì hoãn việc phát hành một tháng, một sự chậm trễ rất lớn đối với kế hoạch “phát hành sớm” ban đầu!

Chúng tôi đang thực hiện lại bảo trì master data, thì tôi tham dự Agile Conference 2005 và được Jeff Patton hướng dẫn. Một trong những bài thực hành là xây dựng các nguyên mẫu giao diện người dùng (prototype of the UI) cho một ứng dụng mẫu. Sau đó, việc ‘kiểm thử’ các nguyên mẫu giấy được thực hiện bởi các thành viên của các nhóm khác (họ đóng vai người dùng của chúng tôi) để đánh giá xem các mẫu giao diện đó tệ đến mức nào. Khi quay trở lại với dự án của mình, tôi nói với người quản lý dự án mà tôi đang tư vấn rằng nếu thử với các nguyên mẫu giấy và áp dụng kỹ thuật kiểm thử “Wizard of Oz”. (Wizard of Oz là chỉ một người hoạt động như một máy tính — kiểu người “đứng đằng sau cánh gà sân khấu”) thì chúng ta có thể đã không bị trễ phát hành 1 tháng như vậy. Chúng tôi đi đến quyết định đưa thử nghiệm “Wizard of Oz” áp dụng cho lần release thứ hai. Chúng tôi làm muộn trong vài buổi tối và thiết kế giao diện người dùng bằng cách sử dụng ảnh chụp màn hình từ Release 1 cộng thêm các màn hình giao diện cho Release 2 được vẽ tay trên giấy và cắt dán.

Để làm kiểm thử Wizard of Oz, chúng tôi đã yêu cầu khách hàng chọn một số người dùng thực để họ thực hiện thử nghiệm. Khách hàng cũng đưa ra một số nhiệm vụ thực tế để người dùng thực hiện. Chúng tôi đưa dữ liệu mẫu vào bảng tính Excel và in ra một số bảng tổ hợp dữ liệu khác nhau để sử dụng trong thử nghiệm. Nhân dịp một số người dùng thực có mặt để tham dự một hội nghị, chúng tôi đã xin tranh thủ một vài giờ của họ và nhờ thực hiện thử nghiệm. Tôi đóng vai trò là người hướng dẫn. Khách hàng đã giới thiệu vấn đề với người dùng thực, và các developer đóng vai trò là người quan sát, ghi lại những bước thực hiện nhầm mà người dùng thực mắc phải, và ghi lại những “lỗi có thể xảy ra”. Chỉ mất vài giờ đồng hồ chúng tôi đã có trong tay một lượng lớn dữ liệu quý giá để biết phần nào trong thiết kế giao diện người dùng của chúng ta hoạt động tốt và phần nào của giao diện cần phải xem xét lại. Chúng tôi đã lặp lại thử nghiệm khả năng sử dụng với những người dùng khác khi chúng tôi có sẵn phiên bản alpha của ứng dụng và có được những thông tin chi tiết có giá trị hơn. Khách hàng của chúng tôi nhận thấy thực hành này rất có giá trị và do đó trong dự án tiếp theo, nhóm nghiệp vụ đã thực hiện việc tạo mẫu trên giấy và làm thử nghiệm Wizard of Oz mà không cần development team đề xuất.

Kỹ thuật Wizard of Oz có thể được thực hiện trước khi viết code. Team có thể kiểm tra sự tương tác của người dùng với hệ thống và thu thập được nhiều thông tin để hiểu hành vi mong muốn của hệ thống. Theo cách này chúng ta đã tạo điều kiện giao tiếp giữa khách hàng và development team.

Tóm lại, sự cộng tác liên tục giữa nhóm khách hàng và development team là chìa khóa để có được các ví dụ làm cơ sở cho các bài kiểm thử nghiệp vụ hỗ trợ viết code. Giao tiếp là một giá trị agile cốt lõi.

Giao tiếp với khách hàng

Trong một thế giới lý tưởng, khách hàng của chúng ta luôn sẵn sàng phục vụ chúng ta hàng ngày. Trong thực tế, nhiều team dự án chỉ có quyền tiếp cận hạn chế với các chuyên viên nghiệp vụ và trong nhiều trường hợp, khách hàng ở một vị trí hoặc múi giờ khác. Hãy cố gắng để bạn có thể để trò chuyện trực tiếp với khách hàng. Khi bạn không thể gặp mặt trực tiếp, cuộc gọi hội nghị, trò chuyện điện thoại, email, instant messaging, máy ảnh và các công cụ giao tiếp khác sẽ thay thế.

Ngay cả khi khách hàng sẵn sàng giao tiếp và các đường dây liên lạc rộng mở, giao tiếp cần được quản lý. Chúng ta muốn nói chuyện với từng thành viên của nhóm khách hàng, nhưng mỗi người đều có quan điểm khác nhau. Nếu chúng ta nhận được một số ý kiến khác nhau từ nhóm khách hàng về cách một phần chức năng sẽ hoạt động, chúng ta sẽ không biết phải viết code gì. Hãy xem xét các cách để khiến nhóm khách hàng nhất trí về điều kiện cần thỏa mãn cho mỗi user story.

Câu chuyện của Lisa

Tôi đã thành lập một nhóm mà các developer trải ra trên ba múi giờ và khách hàng ở một múi giờ khác. Chúng ta đã cử các developer, chuyên viên kiểm thử và chuyên gia phân tích nghiệp vụ khác nhau để gặp gỡ khách hàng cho mỗi iteration, để sao cho bất kỳ thành viên nhóm dự án nào đều có ít nhất một lần giao lưu đối mặt với khách hàng sau mỗi 3 iteration. Điều này đã tạo dựng niềm tin và sự tin cậy giữa các nhóm developer và khách hàng. Thời gian còn lại chúng tôi sử dụng các cuộc gọi điện thoại, video conference và tin nhắn tức thì để đặt câu hỏi cho khách hàng. Chúng tôi đã thành công trong việc đáp ứng và thậm chí làm vui lòng khách hàng.

Rõ ràng trong sáng từ sớm

Nếu nhóm khách hàng của bạn bao gồm những người từ các bộ phận khác nhau của tổ chức, có thể có những ý kiến trái chiều giữa họ về chính xác những gì được đề xuất bởi một user story cụ thể. Trong công ty của Lisa, phòng phát triển kinh doanh muốn các tính năng tạo ra doanh thu, phòng vận hành muốn các tính năng cắt giảm các cuộc gọi hỗ trợ qua điện thoại và phòng tài chính muốn các tính năng hợp lý hóa kế toán, quản lý tiền mặt và báo cáo. Thật ngạc nhiên khi có nhiều cách diễn giải khác biệt về cùng một user story có thể xuất hiện từ những người có quan điểm khác nhau.

Câu chuyện của Lisa

Mặc dù đã có một product owner khi chúng tôi triển khai theo Scrum lần đầu tiên, nhưng chúng tôi đã nhận được các ý kiến chỉ dẫn khác nhau từ các đơn vị nghiệp vụ. Ban lãnh đạo quyết định bổ nhiệm một phó chủ tịch có kiến thức sâu rộng về lĩnh vực nghiệp vụ và vận hành làm Product Owner mới. Anh ta được giao trách nhiệm làm cho tất cả các bên liên quan sớm đạt sự thống nhất với nhau về những nội dung ngầm định của mỗi user story. Anh ấy và nhóm khách hàng gặp gỡ thân mật để thảo luận về các theme và các user story sắp được phát triển, đồng thời thống nhất về thứ tự ưu tiên và các tiêu chí nghiệm thu.

Product owner (Product Owner) là một vai trò trong Scrum. Anh ta không chỉ chịu trách nhiệm về sự rõ ràng trong sáng của các user story, mà còn đóng vai trò là “đại diện khách hàng” trong các phiên sắp xếp thứ tự ưu tiên các user story. Tuy nhiên, có một nhược điểm. Khi team của bạn phải đáp ứng nhu cầu của nhiều quan điểm khác nhau thông qua một người duy nhất, một số thứ quan trọng có thể bị bỏ sót. Lý tưởng thì development team nên ngồi cùng với nhóm các khách hàng và tìm hiểu cách thực hiện công việc của khách hàng. Nếu chúng ta hiểu nhu cầu của khách hàng đủ tốt để có thể tự mình thực hiện các công việc hàng ngày của khách hàng, chúng ta có cơ hội tốt hơn nhiều để làm ra phần mềm chuyên nghiệp hỗ trợ các công việc nghiệp vụ đó.

Câu chuyện của Janet

Nhóm của chúng tôi thoạt đầu không có ai giữ vai trò product owner khi kiểm thử và chỉ sử dụng các chuyên gia nghiệp vụ trong team để xác định thứ tự ưu tiên và độ rõ ràng. Dự án vẫn chạy, nhưng để đạt được sự đồng thuận cần nhiều cuộc họp vì mỗi người có kinh nghiệm khác nhau. Sản phẩm thì tốt hơn, nhưng vẫn có sự trả giá. Họp hành nhiều khiến một số chuyên gia nghiệp vụ không thể tham dự để trả lời các câu hỏi của team dự án, nên quá trình phát triển bị chậm trễ hơn dự kiến.

Có 4 nhóm dự án cùng tham gia phát triển một sản phẩm, mỗi nhóm dự án chỉ tập trung vào một số tính năng khác nhau. Sau một số phiên retrospective và rất nhiều phiên họp giải quyết vấn đề, mỗi nhóm dự án đã chỉ định ra một Product Owner. Nhờ đó số lượng các cuộc họp đã cắt giảm đáng kể vì hầu hết các quyết định nghiệp vụ đều do các chuyên gia nghiệp vụ (domain expert) của từng dự án đưa ra. Các cuộc họp chỉ được tổ chức với sự tham gia của tất cả các chuyên gia nghiệp vụ nếu có bất kỳ sự khác biệt nào về quan điểm, và Product Omer điều khiển phiên họp để đưa ra sự đồng thuận về một vấn đề. Các quyết định được đưa ra nhanh hơn, các chuyên gia nghiệp vụ sẵn sàng trả lời các câu hỏi của nhóm dự án và có thể theo kịp tiến độ làm các bài kiểm thử chấp nhận.

Điều quan trọng là làm sao chỉ có “một tiếng nói của khách hàng” được trình bày cho team dự án. Chúng ta nói rằng product owner cung cấp các điều kiện cần thỏa mãn. Hãy bàn kỹ hơn về những điều kiện này.

Các điều kiện cần thỏa mãn

Có các điều kiện cần thỏa mãn cho toàn bộ bản phát hành cũng như điều kiện cần thỏa mãn cho mỗi tính năng hoặc user story. Kiểm thử chấp nhận giúp xác định user story đã đáp ứng các yêu cầu khách hàng. Development team của bạn không thể thành công trong việc cung cấp những điều doanh nghiệp muốn trừ khi điều kiện cần thỏa mãn về một user story được thống nhất từ trước. Nhóm khách hàng cần “nói cùng một tiếng nói.” Nếu bạn nhận được các yêu cầu khác nhau từ các bên liên quan khác nhau, bạn có thể cần phải tạm trì hoãn user story cho đến khi bạn có một danh sách chắc chắn về các điều kiện cần thỏa mãn từ phía nghiệp vụ. Hãy yêu cầu người đại diện của khách hàng cung cấp lượng thông tin tối thiểu về từng user story để bạn có thể bắt đầu mỗi iteration bằng một cuộc trò chuyện có hiệu quả.

Cách tốt nhất để hiểu các yêu cầu của nhóm khách hàng là nói chuyện trực tiếp với khách hàng. Bởi vì mọi người đều phải vật lộn với các yêu cầu, nên có những công cụ để giúp nhóm khách hàng rà soát qua từng user story. Điều kiện cần thỏa mãn không chỉ bao gồm các tính năng mà user story cung cấp mà còn bao gồm cả sự tác động của user story đến hệ thống ứng dụng.

Product owner của nhóm của Lisa sử dụng một checklist để phân loại các vấn đề như:

Điều kiện cần thỏa mãn kinh doanh
Ảnh hưởng đến các chức năng hiện có như các website, tài liệu, hóa đơn, biểu mẫu hoặc báo cáo
Cân nhắc pháp lý
Tác động đến các quy trình được lên lịch chạy định kỳ
Tham khảo các mô phỏng cho các user story về giao diện người dùng
Help text, hoặc tên người sẽ cung cấp nội dung help text
Các trường hợp kiểm thử (test case)
Di chuyển dữ liệu (nếu cần)
Liên lạc nội bộ cần phải diễn ra
Giao tiếp bên ngoài với các đối tác kinh doanh và nhà cung cấp

Product owner sử dụng biểu mẫu để đưa thông tin này lên wiki của nhóm dự án để các thành viên trong nhóm dự án hiểu về các user story và bắt đầu viết bài kiểm thử.

Các điều kiện cần thỏa mãn này dựa trên các giả định và quyết định quan trọng do nhóm khách hàng đưa ra cho mỗi user story. Chúng là thành quả rút ra từ các cuộc thảo luận với khách hàng về các tiêu chí nghiệm thu (high-level) cho mỗi user story. Thảo luận về các điều kiện cần thỏa mãn giúp nhận dạng các giả định ít chắc chắn và tăng sự tự tin của nhóm dự án trong việc viết code và ước lượng đầy đủ các nhiệm vụ để hoàn thành user story.

Hiệu ứng gợn sóng

Trong phát triển agile, chúng ta tập trung vào một user story tại một thời điểm. Mỗi user story thường là một thành phần nhỏ của ứng dụng tổng thể, nhưng nó có thể gây ra một hiệu ứng gợn sóng lớn. Một user story mới xuất hiện giống như một viên đá nhỏ rơi vào mặt nước ứng dụng, và chúng ta có thể không nghĩ đến những chỗ mà các gợn sóng lan đến. Thật dễ dàng để mất dấu cả bức tranh lớn khi chúng ta chỉ tập trung vào một số lượng nhỏ các user story trong mỗi iteration.

Team của Lisa thấy hữu ích khi lập danh sách tất cả các bộ phận của hệ thống có thể bị ảnh hưởng bởi một user story. Nhóm có thể kiểm tra từng “điểm kiểm thử” để xem có những yêu cầu và trường hợp kiểm thử nào phát sinh từ các điểm kiểm thử đó. Một user story nhỏ và “hiền lành” có thể gây tác động trên phạm vi rộng và mỗi cấu phần của ứng dụng mà nó chạm đến có thể thể hiện một mức độ phức tạp khác nhau. Bạn cần nhận thức được tất cả các tác động tiềm ẩn của bất kỳ sự thay đổi code nào. Lập ra một danh sách là cách tốt để bắt đầu. Trong vài ngày đầu tiên của iteration, nhóm có thể nghiên cứu và phân tích thêm các khu vực bị ảnh hưởng và xem liệu có cần thêm thẻ nhiệm vụ nào để xử lý tất cả các ảnh hưởng phát sinh hay không.

—-

Câu chuyện của Janet

Trong một dự án tôi tham gia chúng tôi sử dụng một danh sách liệt kê tất cả các chức năng cấp cao của ứng dụng đang được thử nghiệm. Khi lập kế hoạch cho release (release planning) và khi bắt đầu mỗi iteration, chúng tôi xem xét lại danh sách và suy nghĩ về cách thức các chức năng mới hoặc các chức năng bị thay đổi sẽ ảnh hưởng đến các vùng chức năng đó. Hoạt động này là điểm khởi đầu để xác định mức độ kiểm thử cần thiết đối với mỗi vùng chức năng. Phân tích tác động/ảnh hưởng bổ sung thêm vào việc kiểm thử user story cho phép nhóm dự án nhìn thấy bức tranh toàn cảnh và hiểu tác động của các thay đổi đối với phần còn lại của hệ thống.

—

Những user story trông có vẻ nhỏ nhưng gây tác động không mong muốn đến các vùng chức năng của hệ thống có thể làm hại bạn. Nếu nhóm dự án quên xem xét tất cả các yếu tố phụ thuộc và nếu code mới viết có giao cắt với chức năng hiện có, user story có thể tốn nhiều thời gian hơn dự kiến. Đảm bảo rằng các bài kiểm thử user story của bạn đã tính đến cả những ảnh hưởng ít hiển nhiên gây ra bởi việc triển khai chức năng mới.

Chia thành lát mỏng, làm từng phần nhỏ

Viết user story là một công việc khó khăn. Khi development team ước lượng các user story mới, họ có thể thấy một số user story quá lớn, vì vậy họ sẽ yêu cầu khách hàng viết lại và chia chúng thành các user story nhỏ hơn. Các user story cũng có thể quá nhỏ và có thể cần được kết hợp với những user story khác hoặc đơn giản chỉ được coi là những nhiệm vụ (task).

Khi nhóm của bạn bắt tay vào một dự án mới hoặc một chủ đề (theme) mới, hãy yêu cầu product owner đưa tất cả các user story liên quan đến một phiên brainstorming trước khi vào iteration đầu tiên cho chủ đề đó. Yêu cầu product owner và các bên liên quan khác giải thích user story. Bạn có thể thấy rằng một số user story cần được chia nhỏ hoặc các user story bổ sung cần được viết.

Sau khi bạn hiểu được giá trị mà mỗi user story sẽ mang lại và cách nó phù hợp với bối cảnh của hệ thống, bạn có thể chia các user story thành những lát nhỏ hơn và có thể quản lý được. Bạn có thể viết các bài kiểm thử nghiệp vụ cho từng lát mỏng trong khi luôn nhận thức đầy đủ về tác động của user story lên toàn bộ ứng dụng.

Một cách tiếp cận thông minh để viết các bài kiểm thử nghiệp vụ hướng dẫn phát triển là bắt đầu với đường trục đi theo đường happy path (còn được gọi là happy flow, là kịch bản sử dụng mặc định không có điều kiện ngoại lệ hoặc lỗi) từ đầu đến cuối. Đường trục như vậy có thể được thực hiện ở cấp độ theme, nơi nó được sử dụng để xác minh sự đúng đắn của kiến trúc ứng dụng. Đường trục này kết nối tất cả các thành phần của kiến trúc với nhau và sau khi nó được kiểm thử thành công, team có thể thêm nhiều chức năng khác vào.

Chiến lược này cũng áp dụng ở cấp độ user story. Càng sớm xây dựng được đường trục thì bạn càng sớm thực hiện được các bài kiểm thử có ý nghĩa, nhận phản hồi, sớm tự động hóa kiểm thử và bắt tay làm exploratory test. Hãy bắt đầu với đường trục của một chức năng chạy xuyên suốt qui trình nghiệp vụ. Đối với giao diện người dùng, có thể bắt đầu bằng việc điều hướng đơn giản từ trang này sang trang khác. Chúng ta có thể hiển thị trình tự chuyển đổi giao diện cho khách hàng và xem liệu quy trình có hợp lý hay không. Chúng ta có thể viết một bài thử nghiệm GUI tự động đơn giản. Đối với user story về ngưỡng giao hàng miễn phí nêu ở đầu chương này, chúng ta có thể bắt đầu bằng cách xác minh logic được sử dụng để tính tổng đơn đặt hàng và đối chiếu xem tổng đơn hàng có đủ mức để được hưởng giao hàng miễn phí hay không mà không cần để ý về giao diện người dùng của chức năng này. Chúng ta có thể tự động hóa các bài kiểm thử bằng một công cụ kiểm thử chức năng như FitNesse.

Sau khi đường trục đã hoạt động tốt, chúng ta có thể viết các kiểm thử nghiệp vụ cho một phần nhỏ hoặc lát mỏng chức năng tiếp theo và viết code sao cho vượt qua các bài kiểm thử đó. Chúng ta cũng sẽ nhận được phản hồi cho phần phát triển gia tăng này. Có thể chúng ta thêm giao diện người dùng để hiển thị trang thanh toán cho thấy rằng đơn đặt hàng đủ tiêu chuẩn để được giao hàng miễn phí hoặc thêm lát chức năng để chốt các cập nhật vào cơ sở dữ liệu. Chúng ta có thể viết các kiểm thử bổ sung vào các bài kiểm thử tự động của lần kiểm thử đầu tiên đã thành công. Đây là một quá trình “viết kiểm thử – viết code – chạy kiểm thử – học” (write tests – write code – run tests – learn). Nếu bạn làm được điều này, bạn biết rằng tất cả code mà team của bạn tạo ra đều đáp ứng khách hàng và hoạt động tốt ở từng giai đoạn.

Câu chuyện của Lisa

Team của tôi nhận thấy rằng chúng tôi cần tập trung vào phát triển trọn vẹn một lát mỏng chức năng đơn giản và sẽ thêm dần vào đó các phần tính năng gia tăng. Trước đó chúng tôi có xu hướng bị mắc kẹt vào một phần của user story. Ví dụ: nếu chúng tôi có một luồng giao diện UI bao gồm bốn màn hình, chúng tôi sẽ dồn sức vào làm màn hình đầu tiên đến nỗi chúng tôi có thể không kịp hoàn thành màn hình cuối cùng và không làm xong được một happy path hoạt động từ đầu đến cuối. Bằng cách bắt đầu với một happy path hoạt động từ đầu đến cuối và thêm dần vào đó mỗi lần một chút chức năng chúng tôi có thể cung cấp trọn vẹn giá trị tối thiểu cần thiết.

Đây là một ví dụ về quy trình phát triển của chúng tôi. User story đề cập ở đây là thêm một bước điều kiện mới vào qui trình lên kế hoạch hưu trí của một công ty. Bước điều kiện này cho phép người dùng chọn danh mục đầu tư quỹ tương trợ, nhưng không phải người dùng nào cũng có quyền truy cập vào tính năng chọn danh mục đầu tư này. Chức năng thiết lập kế hoạch hưu trí vốn được viết bằng code cũ thiết kế tồi. Chúng tôi lên kế hoạch viết trang mới sử dụng một kiến trúc mới, nhưng việc liên kết code mới và code cũ với nhau rất khó và dễ xảy ra lỗi. Chúng tôi chia nhỏ user story thành những lát nhỏ hơn nhưng cho phép quản lý được rủi ro và giảm thiểu thời gian để viết code và kiểm thử story.

Lát số 1 là chèn một trang trống mới dựa trên một thuộc tính. Mặc dù không có nhiều thứ có ích cho khách hàng xem, nhưng nó cho phép chúng tôi kiểm tra cầu nối giữa code cũ và code mới, sau đó xác minh rằng chức năng điều hướng lập kế hoạch vẫn hoạt động đúng cách. Lát số 2 giới thiệu một số business logic. Nếu không có danh mục đầu tư quỹ nào cho công ty, thì bỏ qua bước lựa chọn danh mục, bước này vẫn chưa có thay đổi gì. Nếu có danh mục đầu tư, hãy hiển thị chúng ở bước số 3 mới. Trong lát số 3, chúng tôi thay đổi bước chọn quỹ, thêm logic để hiển thị các danh mục đầu tư. Lát số 4 là thêm các phần tử điều hướng giữa các bước khác nhau trong quá trình xác lập danh mục đầu tư.

Chúng ta đã viết các bài kiểm thử cho từng lát. Khi các developer hoàn thành từng lát một, chúng tôi đã kiểm thử thủ công và cho khách hàng xem. Mọi lỗi được tìm thấy đều được khắc phục ngay. Chúng tôi đã viết một bài thử nghiệm GUI tự động cho lát số 1 và viết thêm nội dung bài kiểm thử đó khi các bước còn lại đã hoàn tất. Làm user story này khó khăn vì code cũ phải kết nối với kiến trúc mới, nhưng cách tiếp cận theo từng bước như trên giúp việc triển khai diễn ra suôn sẻ và tiết kiệm thời gian.

Sau khi vẽ sơ đồ thể hiện việc chia nhỏ user story thành từng lát, chúng tôi đăng ảnh chụp sơ đồ lên trang wiki để các thành viên từ xa của team có thể nhìn thấy chúng. Khi mỗi lát đã hoàn thành, chúng tôi sẽ làm kiểm thử để cung cấp phản hồi trực quan tức thì cho cả team.

Nếu nhiệm vụ viết các bài kiểm thử nghiệp vụ cho một user story có vẻ khó hiểu hoặc quá sức, nhóm của bạn có thể cần phải chia user story thành các bước nhỏ hoặc phần nhỏ. Phát triển user story theo từng bước nhỏ tại một thời điểm giúp dàn trải khối lượng kiểm thử để việc kiểm thử không bị đẩy hết đến cuối iteration. Nó cũng cung cấp cho bạn bức tranh rõ ràng hơn về tiến triển công việc và giúp bạn biết đã hoàn thành xong chưa – một chủ đề được thảo luận trong phần tiếp theo.

Khi nào chúng ta xong việc?

Chúng ta có các bài kiểm thử nghiệp vụ để hỗ trợ team — những bài kiểm thử được viết để đảm bảo code đáp ứng các điều kiện cần thỏa mãn. Những bài kiểm thử bắt đầu với happy path và xác nhận rằng user story đáp ứng yêu cầu đã định. Chúng bao gồm các kịch bản người dùng (user scenario) khác nhau và đảm bảo rằng các phần khác của hệ thống không bị ảnh hưởng xấu. Các bài kiểm thử này đã được chạy và chúng đã pass (hoặc ít nhất chúng đã chỉ ra được các lỗi cần được khắc phục).

Đến đây liệu chúng ta đã làm xong chưa? Có thể, nhưng không chắc chắn. Bài kiểm thử thực sự là liệu người dùng phần mềm có thể thực hiện hành động mà user story được cho là phải cung cấp hay không. Các hoạt động kiểm thử thuộc Quadrant 3 và 4, chẳng hạn như kiểm thử khám phá, kiểm thử khả năng sử dụng, và kiểm thử hiệu năng sẽ giúp chúng ta tìm ra câu trả lời chắc chắn. Tạm thời đến lúc này, chúng ta chỉ cần thực hiện một số bài kiểm thử nghiệp vụ để đảm bảo rằng chúng ta đã nắm bắt được tất cả các yêu cầu. Người dùng doanh nghiệp hoặc product owner là người phù hợp để quyết định xem mọi yêu cầu đã được thực hiện hay chưa, vì vậy họ cũng chính là người phù hợp để thực hiện khám phá ở giai đoạn này.

Khi tất cả các bài kiểm thử nghiệp vụ đều pass và những yêu cầu bị bỏ sót đã được nhận diện, chúng ta đã hoàn thành mục tiêu hỗ trợ các developer trong nhiệm vụ phát triển đúng code cần thiết (the right code). Điều này không có nghĩa là chúng ta đã xong công tác kiểm thử. Trong các chương tiếp theo chúng ta sẽ bàn kỹ hơn ý này.

Một mục tiêu khác của các bài kiểm thử nghiệp vụ là xác định các khu vực có nguy cơ cao và đảm bảo code được viết để gia cố những khu vực có rủi ro đó. Quản lý rủi ro là một thực hành thiết yếu trong bất kỳ phương pháp phát triển phần mềm nào và người kiểm thử đóng vai trò trong việc nhận diện và giảm thiểu rủi ro.

Kiểm thử để giảm thiểu rủi ro

Các bài kiểm thử khách hàng được viết không chỉ để xác định hành vi mong đợi của code mà còn để quản lý rủi ro. Dẫn dắt phát triển bằng các bài kiểm thử không có nghĩa là xác định rõ ràng mọi yêu cầu đơn lẻ từ trước hoặc có thể dự đoán hoàn hảo khi chúng ta hoàn thành. Thực hành này cung cấp cho chúng ta cơ hội xác định rủi ro và giảm thiểu chúng thông qua các trường hợp kiểm thử được chạy. Phân tích rủi ro không phải là một kỹ thuật mới. Phát triển agile vốn đã giảm thiểu rủi ro bằng cách sắp xếp ưu tiên giá trị doanh nghiệp theo các chức năng nhỏ có thể được kiểm thử, và thông qua việc khách hàng nghiệm thu từng increment. Tuy nhiên chúng ta vẫn nên suy nghĩ về các sự kiện rủi ro tiềm năng, cân nhắc xác suất và tác động của chúng đến hoạt động của tổ chức nếu chúng xảy ra, và có thể áp dụng chiến lược giảm thiểu rủi ro phù hợp.

Viết code để vượt qua các bài kiểm thử xác định từ trước sẽ không hoạt động tốt nếu như các bài kiểm thử nhằm vào các tình huống (edge case) không phù hợp. Happy path là điểm khởi đầu tốt, nhưng chỉ như vậy không đủ. Sau khi happy path được xác nhận, chúng ta phải tính đến các kịch bản rủi ro nhất — các trường hợp không chỉ cho ra hậu quả xấu mà còn có khả năng cao xảy ra.

Ngoài câu hỏi cho nhóm khách hàng như “Trường hợp tồi tệ nhất có thể xảy ra là gì?”, bạn hãy hỏi developer những câu hỏi như: “Hậu điều kiện (post condition) của đoạn code này là gì? Thông tin gì cần được lưu lại trong cơ sở dữ liệu? Những hành vi nào ẩn dưới dòng code?” Hãy viết các kiểm thử để bao gồm cả các hậu quả tiềm ẩn rủi ro của một hoạt động (action).

Câu chuyện của Lisa

Team của tôi xem xét các kịch bản xấu nhất để xác định ra các bài kiểm thử nghiệp vụ. Chẳng hạn, chúng tôi phải làm một user story có mục đích viết lại bước đầu tiên của quá trình tạo tài khoản người dùng gồm nhiều bước với một số option mới. Chúng tôi tự hỏi những câu hỏi như: “Khi người dùng gửi trang đầu tiên, những dữ liệu nào cần được ghi vào cơ sở dữ liệu? Có những cập nhật CSDL nào được kích hoạt sau đó không? Chúng tôi có cần thực hiện kiểm thử hồi quy (regression test) cho toàn bộ quá trình tạo tài khoản đã được xây dựng hay không? Có những hoạt động nào mà người dùng mới có thể thực hiện ngay sau khi tài khoản người dùng được thiết lập?” Chúng ta có thể cần phải kiểm tra toàn bộ vòng đời của tài khoản người dùng. Chúng ta không có thời gian để kiểm thử nhiều hơn mức cần thiết, vì vậy quyết định về những gì cần kiểm thử là rất quan trọng. Các bài kiểm thử phù hợp giúp chúng ta giảm thiểu rủi ro do thay đổi mang lại.

Developer có thể nhận diện được các đoạn code nào dễ đổ gãy. Liệu user story đó có liên quan đến việc gắn kết code di sản vào một kiến trúc mới không? Liệu code đang được thay đổi có tương tác với hệ thống khác hay phụ thuộc vào một phần mềm của bên thứ ba không? Bằng cách thảo luận với developer và các thành viên khác trong nhóm về các tác động tiềm ẩn và các khu vực rủi ro, chúng ta có thể lập kế hoạch cho các hoạt động thử nghiệm phù hợp.

Có một rủi ro khác nữa. Khi tập trung vào việc viết các trường hợp kiểm thử chi tiết chúng ta có thể thấy cây mà không thấy rừng. Nghĩa là, chúng ta có thể quên bức tranh toàn cảnh trong khi chúng ta tập trung vào những chi tiết riêng rẽ.

Hiểm họa khi quên đi bức tranh toàn cảnh

Rất dễ để bạn nhiễm thói quen chỉ kiểm thử từng user story riêng lẻ, hoặc chỉ dựa vào những gì developer nói với bạn về code khi bạn xác định và viết các test case. Nếu bạn tự mình tìm thấy những vấn đề tích hợp giữa các user story vào quãng thời gian cuối đợt phát hành, hoặc nhận ra những yêu cầu nghiệp vụ đã bị bỏ sót sau khi user story đã “done”, thì bạn cần thực hiện các hành động khắc phục mối nguy này.

Luôn xem xét từng user story riêng lẻ tác động như thế nào đến các bộ phận khác của hệ thống. Sử dụng dữ liệu thử nghiệm sát thực tế, sử dụng các ví dụ cụ thể làm cơ sở cho các kiểm thử của bạn và làm nhiều cuộc thảo luận để đảm bảo mọi người trong team đều hiểu user story. Đảm bảo rằng các developer không bắt tay viết code trước khi các bài kiểm thử đã sẵn sàng, và hãy sử dụng kiểm thử khám phá (exploratory test) để tìm kẽ hở giữa các user story. Hãy luôn nhớ đến mục tiêu cuối cùng và bức tranh toàn cảnh.

Là một agile team, chúng ta làm việc trong các iteration ngắn, vì vậy điều quan trọng là phải sắp xếp thời gian để viết các bài kiểm thử trước khi chúng ta bắt đầu viết code. Sau khi mỗi iteration hoàn thành, hãy dành thời gian để đánh giá xem liệu làm chi tiết từ đầu có ích lợi gì không. Liệu có đủ các bài kiểm thử để hỗ trợ team đi đúng hướng chưa? Phải chăng có nhiều thời gian lãng phí chỉ vì nội dung user story bị hiểu nhầm? Team của Lisa nhận thấy tốt nhất là viết các bài kiểm thử nghiệp vụ ở mức cao cho user story trước khi viết code, viết các bài kiểm thử chi tiết khi code bắt đầu được viết, và thực hiện kiểm thử khám phá sau khi code được giao để cung cấp cho team thêm thông tin và giúp thực hiện các điều chỉnh cần thiết.

Janet đã làm việc trong một dự án đòi hỏi những bài tính toán rất sâu rộng. Thời gian dành cho việc tạo ra các ví dụ và bài kiểm thử chi tiết trước khi bắt đầu viết code, để đảm bảo rằng các phép tính toán được thực hiện chính xác, là rất cần thiết. Hiểu rõ lĩnh vực nghiệp vụ và hiểu tác động của từng user story có ý nghĩa quan trọng để đánh giá rủi ro và lựa chọn biện pháp giảm thiểu phù hợp.

Trong khi các kiểm thử nghiệp vụ có thể giúp giảm thiểu rủi ro, các loại thử nghiệm khác cũng rất quan trọng. Những vấn đề nghiêm trọng nhất thường không được phát hiện trong quá trình kiểm thử khám phá thủ công. Hiệu năng, tính bảo mật, sự ổn định và khả năng dễ sử dụng cũng là những nguồn rủi ro. Các kiểm thử để giảm thiểu những loại rủi ro này được trình bày trong các chương về Quadrant 3 và 4.

Bạn nên thử và tìm ra cách để team có thể cân bằng giữa việc làm chi tiết từ sớm với sự tập trung vào bức tranh toàn cảnh. Vẻ đẹp của các iteration trong agile là bạn có cơ hội thường xuyên để đánh giá lại quy trình của team đang hoạt động ra sao, cho phép bạn có cơ hội thực hiện các cải tiến liên tục.

Thiết kế có thể kiểm thử và tự động hóa kiểm thử

Khi các developer trong một agile team sẵn sàng thực hành phát triển được dẫn dắt bởi kiểm thử (TDD test-driven development), họ sẽ sử dụng các bài kiểm thử nghiệp vụ cho user story để biết phải viết code gì. Bắt đầu với các bài kiểm thử có nghĩa là mọi người đều suy nghĩ tìm cách tốt nhất để thiết kế code sao cho kiểm thử trở nên dễ dàng hơn. Các bài kiểm thử nghiệp vụ trong Quadrant 2 được diễn tả như các bài kiểm thử tự động. Chúng cần được hiểu rõ ràng, dễ chạy và cung cấp phản hồi nhanh chóng; nếu không, chúng sẽ không được team sử dụng.

Có thể viết các kịch bản kiểm thử thủ công để các developer tự thực thi trước khi họ check in code để đảm bảo rằng họ đã thỏa mãn các điều kiện của khách hàng, nhưng sẽ không thực tế nếu bạn trông đợi các developer chấp nhận cách làm rắc rối như vậy trong thời gian dài. Khi giá trị kinh doanh có ý nghĩa phải được bàn giao sau mỗi 2 tuần hoặc 4 tuần một lần, thông tin phải trực tiếp và tự động. Các agile team có ít kinh nghiệm có thể chấp nhận thực hành viết code được dẫn dắt bởi các bài kiểm thử tự động ở cấp độ unit test (được viết bởi chính các developer) dễ dàng hơn là chấp nhận thực hành TDD ở cấp độ kiểm thử nghiệp vụ. Tuy nhiên, nếu không có các bài kiểm thử nghiệp vụ, các developer sẽ rất khó để xác định xem cần phải viết các bài unit test nào.

Mỗi agile team phải tìm ra quy trình viết và tự động hóa các bài kiểm thử nghiệp vụ để thúc đẩy sự phát triển. Các team chỉ tự động hóa các bài kiểm thử kỹ thuật (unit test, component test) nhận thấy rằng họ có thể viết code không lỗi nhưng lại không thực hiện được những gì khách hàng muốn. Các team không tự động hóa bất kỳ bài kiểm thử nào sẽ mắc kẹt trong đống bùn nợ kỹ thuật (technical debt).

Quadrant 2 chứa nhiều loại kiểm thử và hoạt động khác nhau. Chúng ta cần các công cụ phù hợp để tạo điều kiện cho việc thu thập, thảo luận và truyền đạt các ví dụ và bài kiểm thử. Các công cụ đơn giản như giấy hoặc bảng trắng phù hợp để thu thập các ví dụ nếu team được ngồi cùng nhau trong một không gian. Các công cụ phức tạp hơn giúp các team viết các bài kiểm thử nghiệp vụ dẫn dắt phát triển có thể chạy tự động.

Tóm lược

Trong chương này, chúng ta đã xem xét các cách để hỗ trợ team trong quá trình viết code nhờ các kiểm thử nghiệp vụ.