Giải quyết các vấn đề xung quanh Requirement.

• Bài viết được đúc kết từ các dự án thực tế tôi đã làm và tham khảo những ý kiến/bài viết trên mạng khác. Nội dung có thể không đúng hoàn toàn với dự án của bạn nhưng bạn có thể ứng dụng một phần nào đó.
• Những phương pháp (nằm trong từng vấn đề) mà tôi đề cập dưới đây sẽ luôn có phương pháp: "Trao đổi với khách hàng để làm rõ vấn đề" (Vì đây là phương pháp luôn luôn sử dụng, nên ta hãy coi đó là mặc định nhé)

Có rất nhiều vấn đề xung quanh "vấn đề" này. Trong thực tế, nhất là khi làm dự án với khách hàng là người Nhật, do rào cản về ngôn ngữ khiến requirement thường không rõ ràng. Ngoài ra còn một số lý do khác khiến cho không chỉ dự án với khách hàng Nhật Bản nói riêng mà tất cả khách hàng nói chung như: thiếu thời gian, không có khả năng giao tiếp tốt, lấy yêu cầu chỉ từ một người, người dùng thực sự không hiểu mình muốn gì, có định kiến...

Vậy tóm lại, những vấn đề về requirement có thể phân thành 4 loại (mà tôi có thể nói đến):

• Không có requirement
• Requirement nghèo nàn
• Xung đột requirement
• Requirement đã quá cũ

1. Không có requirement

1.1 Khó khăn

Đây là vấn đề hay gặp phải nhiều nhất. Ví dụ như khách hàng chỉ trao đổi với Br-SE rằng "Tôi muốn thêm tính năng A có các chức năng xyz" hoặc "Tính năng B đang hoạt động, hãy thêm chức năng xyz vào cho tôi". Không có yêu cầu khiến bạn không thể tự tin biết được sản phẩm làm ra sẽ như thế nào.

Điều này khiến tester gặp rất nhiều khó khăn:

• Không có tài liệu dựa vào để design TCs
• Phát sinh nhiều bug từ khách hàng
• .....

VD: 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

1.2. Cách giải quyết

Phương thức 1

• Điều tra, đặt câu hỏi xung quanh vấn đề và luôn luôn có một số tài liệu thử nghiệm (dù là nhỏ nhất)

VD: Một số tài liệu: backlog cơ bản (trong alige project ), một help file, một email, một phiên bản cũ của BRD/FRD hoặc các testcase cũ…

• Trong trường hợp xấu nhất là không có hoàn toàn bất kỳ một tài liệu nào thì bạn hãy sử dụng kinh nghiệm của mình. Coi bản thân là end user.

Phương thức 2

Sử dụng các phiên bản cũ / hiện tại của ứng dụng như một tài liệu tham khảo để kiểm tra các phiên bản tương lai của một sản phẩm phần mềm. Mặc dù trong trường hợp thông thường thì được khuyến cáo “Never write test cases using the application as a reference”

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

Tuy nhiên chúng ta cần phải chú ý rằng: Ứng dụng đang làm có thể chứa bug. VD: Sau khi đăng ký tài khoản thành công, ứng dụng tự động đưa ta đến một màn hình mặc định nào đó.

• -> Không bao giờ được coi đó là hành vi đúng đắn. Không dùng ứng dụng như một tài liệu mong muốn.
• -> Ứng dụng có thể giúp bạn bắt đầu nhưng hãy luôn đặt câu hỏi: Nó có đang làm việc đúng?

Phương thức 3

Trao đổi với các thành viên trong dự án để có thể hiểu thêm về sản phẩm.

• Đề nghị họ tham gia các buổi meeting của dự á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
• Sắp xếp thời gian để có thể truyền lại kiến thức về dự án khi bạn có thể

2. Requirement không rõ ràng

1.1 Khó khă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.

Nếu không biết gì về nó, bạn có thể tiếp cận vấn đề từ đầu và rõ ràng nhất. Tuy nhiên, khi bạn đã hiểu sơ qua vấn đề thì có thể bạn sẽ có định kiến về điều đó, khiến bạn hiểu sai hoàn toàn chức năng mà khách hàng yêu cầu; khách hàng và bạn có thể sẽ nghĩ theo hai chiều hướng khác nhau với cùng một tính năng:

VD: Requirement: “Tính nă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.

1.2. Cách giải quyết

Phương thức 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.
• Dựa vào relying on exploratory testing (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.

Phương thức 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.

Phương thức 3: 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.

Phương thức 4: 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 cùng giải pháp có thể tương ứng.

3. Xung đột Requirement

1.1 Khó khăn

Đôi khi chính khách hàng cũng không hiểu họ muốn gì nên có thể đưa ra những yêu cầu xung đột nhau. Điều này khiến cho ta không hiểu khách hàng muốn gì và mất thời gian confrim (có thể nhiều lần) với họ.

VD: Khách hàng đưa ra yêu cầu:

• Req1: Ứng dụng game cho phép người dùng được sang màn tiếp theo ngay khi đạt 1000 điểm
• Req2: Người dùng sẽ đượ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

1.2 Cách giải quyết

Trước khi hỏi lại khách hàng, với từng yêu cầu hãy đưa ra ưu/nhược điểm (VD: Làm theo Req1 thì sẽ tốn ít thời gian hơn, dễ làm hơn, hợp lý với người dùng hơn) của từng Req. Đồng thời, bạn hãy diễn giải ý hiểu của bản thân với từng yêu cầu trước khi confirm với KH. Hoặc bạn có thể đề xuất cho khách hàng theo hướng của mình.

4. Requirement đã quá cũ

1.1 Khó khăn

Có nhiều dự án đã có requirement nhưng vì nhiều lý do (thiếu nhân sự, thay đổi người làm,...) khiến cho nó không được update. Điều này sẽ khiến chúng ta bị rơi vào trạng thái "hỗn loạn". Tính năng A có đúng với như requirement không? Tính năng B có trong requirement chưa?...

1.2 Cách giải quyết

Nếu rơi vào tình trạng này, việc đầu tiên bạn hãy xem bản requirement này phiên bản cũ nhất là vào thời gian nào? Sau khoảng thời gian đó có những functions nào được thêm mới/chỉnh sửa/xóa bỏ. Từ đó bạn có thể đối chiếu với requirement và biết được những thông tin nào có thể sử dụng được.

Kết luận

Chúng ta - những tester sẽ không thể tránh được việc gặp phải những vấn đề như trên. Điều quan trọng là với mỗi vấn đề, ta biết cách giải quyết hợp lý. 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.

Nguồn tham khảo

1. http://www.softwaretestinghelp.com/how-to-deal-with-bad-requirements-as-a-tester/
2. http://www.softwaretestinghelp.com/how-to-test-an-application-without-requirements/