Giải quyết vấn đề khi requirement không đầy đủ

Có rất nhiều trường hợp tồi tệ xảy ra khi project thiếu requirement. Nhưng không có gì là hoàn hảo do đó phải tìm cách đối mặt và giải quyết vấn đề thiếu yêu cầu hoặc yêu cầu dự án nghèo nàn

1. Không có requirement

Không có yêu cầu do đó không thể tự tin biết được sản phẩm làm ra sẽ như thế nào Rất khó để test một sản phẩm/ ứng dụng mà không có bất cứ một tài liệu, cơ sở nào để dựa theo. Và kết quả là khối lượng công việc sẽ nhiều hơn, nhiều bug từ phía khách hàng, do đó nhiều áp lực hơn cho đội dự án

• Làm thế nào để báo cáo một lỗi về hệ thống bị xâm nhập khi mà không tồn tại bất kì quy định khả dụng nào về việc nên xử lý trường hợp đó như thế nào
• Làm thế nào để xác định nếu thời gian mà trang chủ loading là 100 giây là không thể chấp nhận được khi mà không có yêu cầu cho hiệu năng

3 phương pháp để test mà không có requirement

Phương pháp 1:

Làm việc với bất cứ tài liệu nhỏ nào mà bạn có. Nó có thể là basic simple backlog (agile projects), help file, email, phiên bản cũ của BRD/FRD, hoặc test cases cũ. Điều tra, hỏi xung quanh có thể có những bản nháp của document. Nếu không hãy sử dụng kinh nghiệm của chính mình, coi mình là một end user. Không phải trong mọi trường hợp đều có thể áp dụng nhưng trong nhiều trường hợp thì vẫn mang lại kết quả.

Phương pháp 2:

Sử dụng phiên bản cũ và hiện tại của chính ứng dụng để đối chiếu test cho những phiên bản sau. Mặc dù trong trường hợp thông thường thì được khuyến cáo “Không được viết test case mà sử dụng ứng dụng như một sự chỉ dẫn hay tham khảo”

Phương pháp 3:

Nói chuyện với các thành viên trong dự án để hiểu hơn về sản phẩm đang phát triển Tham gia trong giai đoạn unit test và integration test hoặc yêu cầu họ cho xem kết quả của giai đoạn unit test và integration test

2. Requirement nghèo nàn

Thường thì hiểu vấn đề không hoàn chỉnh sẽ nguy hiểm hơn là không biết gì về nó. Điều này cũng đúng với trường hợp thiếu requirement, thực hiện trong điều kiện này có rất nhiều rủi ro

• Làm sao để xác nhận được pop-up hiển thị kết quả tìm kiếm là hợp lệ hay không khi mà yêu cầu chỉ đề cập đến “kết quả seach cần đúng”, nhưng không biết tiêu chí tìm kiếm là gì, và như thế nào được coi là đúng
• “Quên mật khẩu phải được thực hiện để tạo thuận lợi cho người sử dụng để dễ dàng lấy lại mật khẩu”. Trong trường hợp này rất khó để thực hiện vì không biết khách hàng muốn các bước thực hiện sẽ theo flow như thế nào, rất có thể có xung đột xảy ra khi mỗi người nghĩ theo một hướng. 3. Xung đột requirement Làm thế nào để test với requirement như sau
• ứng dụng luôn được mở ở trang chủ
• người dùng phải đăng nhập để vào được ứng dụng

hoặc ví dụ như

• Ứng dụng game nên cho người dùng được sang màn tiếp theo ngay khi đạt 1000 điểm
• Người dùng nên được chuyển hướng đến trang đăng kí miễn phí một lần nữa khi mà họ đạt 1000 điểm

Những xung đột trong yêu cầu này tạo nên rất nhiều rắc rối. Đôi khi chính khách hàng cũng không biết rõ được chính xác họ muốn gì, và cần diễn đạt nó như thế nào

Đối với tester làm thế nào để xử lý được trong trường hợp yêu cầu không đầy đủ

1. Thăm dò và học hỏi

Tìm hiểu từ các ứng dụng khác, hành vi được mong đợi chung của người dùng, hiểu về luồng công việc, nghĩ về các cách thức thuận tiện cho người dùng, logic của ứng dụng và cách để đối mặt với các tình cảnh khác nhau. Ngoài ra, dựa vào thử nghiệm thăm dò sẽ rất hữu ích trong tình huống yêu cầu không rõ ràng.

2. Sử dụng kinh nghiệm

Sử dụng kinh nghiệm test một phần hoặc toàn bộ, vấn đề đã từng đối mặt trong quá khứ có thể giúp giải quyết trong trường hợp yêu cầu gây khó hiểu.

3. Đối chiếu đến wireframes

Wireframes là một loại yêu cầu trực quan mà có thể tìm thấy chi tiết nhỏ và những chi tiết có thể rất hữu ích trong việc tạo ra các hình ảnh dự kiến của sản phẩm hoặc ứng dụng và hỗ trợ trong các khía cạnh thử nghiệm trong một cách tốt hơn.

4. Thảo luận

Sẽ không có nhầm lẫn nếu vấn đề được thảo luận với đúng người thì mọi việc sẽ được làm rõ. Mọi người đều có những kinh nghiệm, mong đợi khác nhau, có thể thảo luận với các thành viên trong dự án để cùng hiểu hơn về yêu cầu.

5. Lấy thông tin từ khách hàng

Khách hàng là người đưa ra yêu cầu, vì vậy luôn là khôn ngoan khi làm rõ yêu cầu từ phía khách hàng, tuy nhiên không nên đặt cho họ mọi câu hỏi, cần thử tìm hiểu thực tiễn có sẵn, hiểu lợi ích của việc thực hiện và sau đó liên hệ với khách hàng với câu hỏi và giải pháp có thể.

Kết luận

Yêu cầu lỏng lẻo hoặc không xác định là một phần trong cuộc sống tester, chúng ta cần phải chấp nhận chúng, nhưng hãy cố gắng lạc quan và xác định các giải pháp cho nó. Tester cần giữ cho ứng dụng trong tầm kiểm soát và tránh tối đa các lỗi có thể xảy ra.

Tham khảo

http://www.vectorcast.com/news/embedded-software-testing-news/software-testing-news/how-deal-bad-requirements-tester