Mỗi đội sản phẩm đều bắt đầu từ một ý tưởng. Nó khởi nguồn như một tia lửa, một cuộc trò chuyện bên tách cà phê, hoặc một ghi chú trên bảng trắng. Tia lửa này thường được gọi là một ý tưởng mơ hồ. Nó mang tiềm năng, nhưng lại thiếu cấu trúc. Không có cấu trúc, một ý tưởng không thể trở thành phần mềm giải quyết các vấn đề thực tế. Cầu nối giữa một khái niệm mờ nhạt và một tính năng hoạt động là câu chuyện người dùng có thể kiểm thử.
Nhiều đội ngũ gặp khó khăn ở đây. Họ viết các yêu cầu mở rộng khả năng diễn giải. Các nhà phát triển xây dựng theo một cách, người kiểm thử kiểm thử theo cách khác, và người sở hữu sản phẩm cảm thấy kết quả không đúng như mong đợi. Sự bất đồng này tốn kém về thời gian, tiền bạc và tinh thần. Giải pháp nằm ở sự chính xác. Bằng cách biến những ý tưởng mơ hồ thành các câu chuyện người dùng có thể kiểm thử, các đội ngũ đạt được sự rõ ràng, khả năng dự đoán và chất lượng.
Hướng dẫn này khám phá cách tinh chỉnh những khái niệm thô sơ thành các mục tiêu thực thi được. Chúng ta sẽ xem xét cấu trúc của một câu chuyện mạnh mẽ, vai trò của các tiêu chí chấp nhận, và tầm quan trọng của sự hợp tác. Ở đây không có công cụ phép màu nào, chỉ có những thực hành đã được chứng minh để mang lại hiệu quả giao hàng tốt hơn.
Câu chuyện Người dùng Có thể Kiểm thử là gì? 🧐
Một câu chuyện người dùng không chỉ là một vé trong hệ thống theo dõi. Đó là cam kết về một cuộc trò chuyện. Nó mô tả một khả năng từ góc nhìn của người dùng cuối. Tuy nhiên, một câu chuyện chỉ có giá trị nếu nó có thể được xác minh. Nếu bạn không thể viết một trường hợp kiểm thử cho nó, thì nó chưa sẵn sàng.
Khả năng kiểm thử có nghĩa là hành vi có thể quan sát và đo lường được. Nó loại bỏ sự mơ hồ. Khi một câu chuyện có thể kiểm thử, mọi người đều biết rõ điều gì được gọi là hoàn thành sẽ trông như thế nào ngay từ khi công việc bắt đầu. Điều này chuyển hướng sự tập trung từ đầu ra sang kết quả.
- Vai trò:Ai đang yêu cầu tính năng này?
- Mục tiêu:Họ muốn đạt được điều gì?
- Lợi ích:Tại sao điều này quan trọng đối với doanh nghiệp hoặc người dùng?
Không có những yếu tố này, một câu chuyện chỉ là một nhiệm vụ. Một nhiệm vụ là một chỉ dẫn. Một câu chuyện là một đề xuất giá trị. Mục tiêu là đảm bảo mỗi câu chuyện mang lại giá trị có thể xác minh được.
Chi phí của Sự Mơ hồ 📉
Khi yêu cầu mơ hồ, đội ngũ phải trả giá. Giá trị này không chỉ là tiền bạc; mà còn là gánh nặng nhận thức và thời gian. Hiểu rõ hậu quả sẽ giúp thúc đẩy sự chuyển dịch hướng đến sự chính xác.
1. Sửa lại và Lãng phí
Nếu một nhà phát triển cho rằng tính năng phải hoạt động theo một cách, nhưng người sở hữu sản phẩm lại có ý định khác, mã nguồn phải được viết lại. Đây là sự lãng phí. Nó tiêu tốn nguồn lực có thể dùng để phát triển tính năng mới. Sự mơ hồ dẫn đến những giả định, và giả định dẫn đến sai sót.
2. Khoảng trống Kiểm thử
Người kiểm thử không thể tạo ra một bộ kiểm thử vững chắc nếu yêu cầu không rõ ràng. Họ sẽ đoán mò. Nếu đoán sai, lỗi sẽ lọt vào môi trường sản xuất. Sau này, sửa lỗi tốn kém hơn nhiều so với việc viết mã đúng ngay từ đầu. Những câu chuyện rõ ràng cung cấp kịch bản cho kiểm thử.
3. Xung đột trong Đội ngũ
Mâu thuẫn nảy sinh khi kỳ vọng khác nhau. Các nhà phát triển đổ lỗi cho người sở hữu sản phẩm vì các yêu cầu không rõ ràng. Người sở hữu sản phẩm đổ lỗi cho các nhà phát triển vì không nắm được tầm nhìn. Một câu chuyện có thể kiểm thử đóng vai trò như một hợp đồng chung. Nó thống nhất đội ngũ xung quanh một định nghĩa duy nhất về thành công.
Mô hình INVEST cho Chất lượng 🏗️
Để đảm bảo các câu chuyện có thể kiểm thử được, chúng phải đáp ứng các tiêu chí chất lượng cụ thể. Mô hình INVEST cung cấp một danh sách kiểm tra. Mỗi chữ cái đại diện cho một đặc điểm của một câu chuyện tốt.
| Chữ cái | Ý nghĩa | Tại sao điều đó quan trọng |
|---|---|---|
| I | Độc lập | Các câu chuyện không nên phụ thuộc vào người khác để được giao. |
| N | Có thể thương lượng | Chi tiết được thảo luận, chứ không được cố định như đá. |
| V | Có giá trị | Nó phải mang lại giá trị cho người dùng hoặc doanh nghiệp. |
| E | Có thể ước lượng | Đội ngũ phải có khả năng xác định quy mô công việc. |
| S | Nhỏ | Các câu chuyện lớn rất khó kiểm thử và quản lý. |
| T | Có thể kiểm thử | Tiêu chí chấp nhận phải có thể xác minh được. |
Tập trung mạnh vào Nhỏ và Có thể kiểm thử. Các câu chuyện lớn che giấu tính phức tạp. Chúng thường quá lớn để kiểm thử trong một lần lặp duy nhất. Chia nhỏ chúng sẽ giảm thiểu rủi ro. Nếu một câu chuyện quá lớn, hãy chia nó ra. Chia theo chức năng, theo loại người dùng hoặc theo khối lượng dữ liệu.
Viết tiêu chí chấp nhận 📝
Tiêu chí chấp nhận là các rào chắn bảo vệ cho một câu chuyện người dùng. Chúng xác định ranh giới của tính năng. Chúng trả lời câu hỏi: Những điều kiện nào phải được đáp ứng để câu chuyện này được chấp nhận?
Có một số cách để viết chúng. Phương pháp phổ biến nhất sử dụng các tình huống. Cách tiếp cận này mô tả hành vi trong một bối cảnh cụ thể. Nó tránh ngôn ngữ trừu tượng.
Ví dụ xấu so với ví dụ tốt
So sánh các ví dụ sau để thấy sự khác biệt giữa ngôn ngữ mơ hồ và ngôn ngữ có thể kiểm thử.
| Tính năng | Mơ hồ (Tránh dùng) | Có thể kiểm thử (Sử dụng) |
|---|---|---|
| Tìm kiếm | Tìm kiếm phải nhanh. | Kết quả tìm kiếm xuất hiện trong dưới 2 giây đối với 100 mục. |
| Đăng nhập | Người dùng có thể đăng nhập. | Người dùng nhập thông tin xác thực hợp lệ và nhấn Gửi; bảng điều khiển sẽ tải lên. Thông tin xác thực không hợp lệ sẽ hiển thị thông báo lỗi. |
| Xuất | Xuất dữ liệu sang PDF. | Hệ thống tạo tệp PDF chứa hình ảnh bảng hiện tại. Tệp sẽ tự động tải xuống khi có yêu cầu. |
Lưu ý sự khác biệt ở cột Có thể kiểm thử cột. Nó bao gồm các điều kiện cụ thể, kết quả mong đợi và các chỉ số có thể đo lường. Từ nhanh là mang tính chủ quan. 2 giây là mang tính khách quan.
Các loại tiêu chí chấp nhận
Các câu chuyện khác nhau yêu cầu các loại tiêu chí khác nhau. Đừng ép buộc một định dạng lên mọi mục.
- Quy tắc kinh doanh: Logic hoặc phép tính cụ thể. (Ví dụ: Thuế là 10% đối với đơn hàng trên 50 đô la).
- Hành vi giao diện người dùng: Cách giao diện phản ứng. (Ví dụ: Nút chuyển sang màu xanh khi thành công).
- Hiệu suất:Tốc độ hoặc giới hạn tải. (Ví dụ: Trang tải trong 1 giây).
- Xử lý lỗi:Điều gì xảy ra khi có lỗi xảy ra. (Ví dụ: Hiển thị mã lỗi 404).
- Bảo mật:Yêu cầu kiểm soát truy cập. (Ví dụ: Chỉ người quản trị mới có thể xóa bản ghi).
Cấu trúc cú pháp Gherkin 📋
Đối với logic phức tạp, một định dạng có cấu trúc sẽ giúp ích.Gherkinlà một cách không phụ thuộc vào ngôn ngữ để mô tả hành vi. Nó sử dụng văn bản thuần túy để định nghĩa các tình huống. Điều này giúp nó dễ đọc đối với các bên liên quan không chuyên về kỹ thuật.
Cấu trúc tuân theo ba từ khóa chính:
- Cho rằng:Bối cảnh hoặc trạng thái ban đầu.
- Khi:Hành động hoặc sự kiện xảy ra.
- Thì:Kết quả hoặc kết quả mong đợi.
Cấu trúc này buộc người viết phải suy nghĩ về luồng. Nó ngăn ngừa việc bỏ sót các bước. Nó cũng phù hợp với các khung kiểm thử tự động.
Ví dụ tình huống
Hãy tưởng tượng một câu chuyện về việc đặt lại mật khẩu. Dưới đây là cách nó có thể trông như thế nào theo định dạng Gherkin:
Tính năng: Đặt lại mật khẩu Tình huống: Người dùng yêu cầu đặt lại mật khẩu Cho rằng người dùng đang ở trang đăng nhập Khi người dùng nhấp vào liên kết "Quên mật khẩu" Thì hệ thống gửi email đặt lại đến địa chỉ đã đăng ký của họ Tình huống: Người dùng nhập địa chỉ email không hợp lệ Cho rằng người dùng đang ở trang đăng nhập Khi người dùng nhấp vào liên kết "Quên mật khẩu" Và nhập một địa chỉ email không tồn tại Thì hệ thống hiển thị thông báo thành công chung
Định dạng này loại bỏ sự mơ hồ. Nó nêu rõ chính xác đầu vào nào dẫn đến đầu ra nào. Nó vừa đóng vai trò tài liệu, vừa là các trường hợp kiểm thử đồng thời.
Hợp tác là chìa khóa 🤝
Viết một câu chuyện một mình thường dẫn đến những khoảng trống. Những câu chuyện tốt nhất đến từ sự hợp tác. Điều này bao gồm việc tập hợp người sở hữu sản phẩm, nhà phát triển và người kiểm thử lại với nhau.
Ba người bạn
Thuật ngữ không chính thức này chỉ đến nhóm ba vai trò tham gia tinh chỉnh một câu chuyện. Họ gặp nhau trước khi phát triển bắt đầu.
- Người sở hữu sản phẩm:Xác định giá trị và các quy tắc kinh doanh.
- Nhà phát triển:Xác định các giới hạn kỹ thuật và chi tiết triển khai.
- Người kiểm thử:Xác định các trường hợp biên và các điểm có thể xảy ra lỗi tiềm tàng.
Trong buổi này, họ xem xét bản nháp câu chuyện. Họ đặt câu hỏi. Họ thách thức các giả định. Họ cùng nhau tinh chỉnh các tiêu chí chấp nhận. Quá trình này thường được gọi làtinh chỉnh danh sách chờ hoặc chỉnh sửa câu chuyện.
Những câu hỏi cần đặt ra
Trong quá trình tinh chỉnh, hãy đặt những câu hỏi này để phát hiện ra sự phức tạp ẩn giấu:
- Điều gì sẽ xảy ra nếu mạng bị lỗi trong hành động này?
- Tính năng này hoạt động thế nào trên thiết bị di động?
- Có quy định nào về bảo mật dữ liệu cần xem xét không?
- Phương án dự phòng là gì nếu dịch vụ bên ngoài không khả dụng?
- Thay đổi này có ảnh hưởng đến dữ liệu hoặc báo cáo hiện có không?
Trả lời những câu hỏi này sớm sẽ ngăn ngừa những bất ngờ sau này. Nó xây dựng sự hiểu biết chung.
Những sai lầm phổ biến cần tránh 🕳️
Ngay cả các đội có kinh nghiệm cũng mắc sai lầm. Nhận thức về những cái bẫy phổ biến sẽ giúp bạn tránh được chúng.
1. Câu tuyên bố giải pháp
Đừng viết các câu chuyện mô tả giải pháp. Một câu chuyện nên mô tả vấn đề hoặc nhu cầu. Đội ngũ sẽ quyết định giải pháp trong quá trình phát triển.
Xấu: “Thêm một nút để xuất sang Excel.”
Tốt: “Là một quản lý, tôi cần xuất dữ liệu của mình để có thể phân tích nó khi không kết nối mạng.”
2. Các nhiệm vụ kỹ thuật dưới dạng câu chuyện
Việc tái cấu trúc hay công việc hạ tầng không phải là một câu chuyện người dùng. Đó là nợ kỹ thuật hoặc bảo trì. Dù quan trọng, nhưng nó không mang lại giá trị trực tiếp cho người dùng như các câu chuyện khác. Hãy theo dõi chúng riêng biệt.
3. Bỏ qua các yêu cầu phi chức năng
Hiệu suất, bảo mật và khả năng truy cập không phải là tùy chọn. Chúng phải được bao gồm trong các tiêu chí chấp nhận. Đừng giả định hệ thống tự động an toàn.
4. Quá nhiều tiêu chí chấp nhận
Nếu một câu chuyện có 50 tiêu chí chấp nhận, thì có khả năng nó quá lớn. Hãy chia nhỏ câu chuyện. Tập trung vào giá trị cốt lõi trước. Thêm độ phức tạp từng bước một.
Đo lường chất lượng 📏
Làm sao bạn biết các câu chuyện của mình đang được cải thiện? Bạn cần các chỉ số đo lường. Theo dõi những chỉ số này theo thời gian.
- Tỷ lệ lỗi:Số lượng lỗi phát hiện trong quá trình kiểm thử có đang giảm dần không? Nếu các tiêu chí chấp nhận rõ ràng, thì số lượng lỗi trôi qua sẽ ít hơn.
- Tỷ lệ từ chối:Câu chuyện được trả lại trong quá trình xem xét bao nhiêu lần? Tỷ lệ từ chối cao cho thấy các tiêu chí chưa rõ ràng.
- Tính nhất quán về tốc độ:Liệu đội có ước lượng chính xác không? Các câu chuyện rõ ràng sẽ dẫn đến các ước lượng tốt hơn.
- Phạm vi tự động hóa:Bạn có thể tự động hóa các tiêu chí chấp nhận không? Phạm vi cao cho thấy các câu chuyện có thể kiểm thử được.
Xem xét các chỉ số này trong các buổi tổng kết. Thảo luận những gì đã hoạt động tốt và những gì chưa. Điều chỉnh quy trình của bạn cho phù hợp. Mục tiêu là cải tiến liên tục.
Các tình huống thực tế 🌍
Hãy cùng xem cách áp dụng điều này trong các bối cảnh khác nhau. Các nguyên tắc vẫn giữ nguyên, nhưng chi tiết sẽ thay đổi.
Tình huống A: Quy trình thanh toán thương mại điện tử
Đây là một luồng quan trọng. Lỗi sẽ tốn kém. Các câu chuyện phải bao quát từng bước.
- Câu chuyện:Áp dụng mã giảm giá.
- Tiêu chí:
- Hệ thống xác thực định dạng mã.
- Hệ thống kiểm tra ngày hết hạn của mã.
- Hệ thống tính toán tổng giá mới.
- Hệ thống hiển thị lỗi nếu mã không hợp lệ.
- Hệ thống ngăn chặn việc tái sử dụng mã đã hết hạn.
Tình huống B: Bảng điều khiển báo cáo
Độ chính xác dữ liệu là điều tối quan trọng ở đây.
- Câu chuyện:Lọc báo cáo theo khoảng thời gian ngày.
- Tiêu chí:
- Hệ thống mặc định là 30 ngày gần nhất.
- Hệ thống cho phép thiết lập ngày bắt đầu và kết thúc tùy chỉnh.
- Hệ thống loại bỏ dữ liệu nằm ngoài phạm vi đã chọn.
- Hệ thống xử lý đúng các ngày cuối tuần và ngày lễ.
Tình huống C: Quản lý hồ sơ người dùng
Bảo mật và tính toàn vẹn dữ liệu là điều quan trọng.
- Câu chuyện:Cập nhật hình đại diện hồ sơ.
- Tiêu chí:
- Hệ thống chấp nhận định dạng JPG và PNG.
- Hệ thống giới hạn kích thước tệp đến 5MB.
- Hệ thống hiển thị hình thu nhỏ trong chế độ xem lưới.
- Hệ thống xóa hình ảnh cũ khỏi bộ nhớ.
Tiêu chuẩn hoàn thành 🛑
Tiêu chí chấp nhận xác định câu chuyện cụ thể. NhữngTiêu chuẩn hoàn thànháp dụng cho tất cả các câu chuyện trong dự án. Đó là danh sách kiểm tra chất lượng luôn hoạt động.
Một câu chuyện không được coi là hoàn thành cho đến khi:
- Mã nguồn được viết.
- Mã nguồn được xem xét.
- Các bài kiểm thử đều đạt.
- Tài liệu được cập nhật.
- Các tiêu chuẩn hiệu suất được đáp ứng.
- Quét bảo mật không phát hiện lỗi.
Điều này đảm bảo tính nhất quán. Nó ngăn ngừa nợ kỹ thuật tích lũy. Nó đảm bảo rằng mỗi câu chuyện được giao đều có thể sử dụng được.
Tinh chỉnh theo từng vòng lặp 🔄
Các câu chuyện không cố định. Chúng phát triển theo thời gian. Khi bạn hiểu rõ hơn về hệ thống, bạn có thể cần cập nhật chúng. Điều này không phải là thất bại; đó là một phần của quy trình.
Giữ danh sách công việc sẵn sàng. Tinh chỉnh các câu chuyện thường xuyên. Đừng chờ đến khi sprint bắt đầu mới đặt câu hỏi. Thời điểm tốt nhất để làm rõ là sớm. Chi phí thay đổi tăng theo cấp số nhân khi bạn tiến gần đến mã nguồn.
Tóm tắt các thực hành tốt nhất ✅
Để kết thúc hành trình từ mơ hồ đến có thể kiểm thử, hãy nhớ những điểm cốt lõi này.
- Tập trung vào giá trị:Luôn liên kết trở lại nhu cầu của người dùng.
- Hãy cụ thể: Sử dụng số lượng và điều kiện rõ ràng.
- Hợp tác:Tham gia tất cả các vai trò trong việc tinh chỉnh.
- Xác minh:Đảm bảo mỗi câu chuyện đều có thể kiểm thử được.
- Lặp lại:Cải thiện các câu chuyện dựa trên phản hồi.
Việc áp dụng tư duy này thay đổi cách một đội làm việc. Nó xây dựng niềm tin. Nó cải thiện tốc độ. Nó dẫn đến phần mềm thực sự hoạt động hiệu quả cho những người sử dụng nó.
