Làm thế nào để nhận diện tài liệu spec có "sạn" và cách xử lý?

I. Yêu cầu lý tưởng

Requirement được cho là lý tưởng khi nó:

• Đầy đủ 
• Phù hợp
• Rõ ràng
• Chính xác
• Nhất quán
• Không mâu thuẫn

Requirement “lý tưởng” như trên sẽ giúp cho công việc trở nên dễ dàng và hiệu quả hơn rất nhiều! Đặc biệt, đối với các bạn QA, việc có được requirement “lý tưởng” giống như một “bữa ăn thịnh soạn” vậy, nó giúp cho họ dễ dàng hơn trong việc phân tích requirement, đưa ra chiến lược test phù hợp, xây dựng bộ khung Test Case... Sản phẩm được tạo ra đảm bảo được chất lượng, đúng theo yêu cầu, kỳ vọng của khách hàng.

Tuy nhiên, chỉ có số ít dự án đạt được điều kiện requirement lý tưởng trên. Thông thường bạn sẽ gặp những trường hợp sau:

• Không có requirement, hoặc mã nghiệm thu không có.
• Requirement mơ hồ, mập mờ
• Requirement không thống nhất, không nhất quán
• Requirement bị thay đổi liên tục
• Requirement đã cũ (do dự án "ngâm" quá lâu mà không triển khai)
• Nghị định, chính sách thay đổi sau một năm thu thập requirement
• ...

Vậy bạn sẽ giải quyết những vấn đề đó như thế nào? Chúng ta cùng nhau đi tìm câu trả lời cho từng vấn đề nhé!!!

II. Giải quyết vấn đề với các yêu cầu không lý tưởng

1. Không có requirement

Thí dụ:
Khách hàng đã có sẵn một ứng dụng trên mobile và mong muốn phát triển thành hệ thống trên website để người dùng có thể dễ dàng truy cập và sử dụng nó.

Khách hàng giao task: Hãy thêm chức năng Quản lý lịch làm việc của nhân viên trên Website giống như bản mobile.

Để thực hiện dự án này cần:

• Đảm bảo được toàn bộ logic từ ứng dụng mobile sang Website.
• Phân tích việc cần điều chỉnh một số quan điểm và phương pháp tư duy (ví dụ:GUI, chức năng…) để phù hợp với hệ thống Website. Các tiêu chuẩn về thiết kế Website hoàn toàn khác với mobile.

Đây là một tình huống khó khăn, khách hàng không đưa bất kì tài liệu liên quan nào, khiến cho QA/BA gặp rất nhiều rắc rối, khó khăn và tốn nhiều thời gian công sức để tìm hiểu, điều tra, đưa ra quan điểm test, thiết kế TestCase, Test Scenario, Regression Test (kiểm thử lại)… Do đó tiềm ẩn nhiều rủi ro cao trong dự án, dẫn đến việc phát sinh nhiều "bug" (lỗi) xảy ra khi vận hành thực tế

Giải pháp:

• Hãy hỏi khách hàng về những tài liệu liên quan đến nghiệp vụ, tài liệu thiết kế có sẵn (SRS, UI/UX,…), Test Case cũ,… Nếu không có bất kì tài liệu gì thì đối với dự án như thế này thì hệ thống hiện tại hoặc ứng dụng cũ chính là requirement.
• Hãy sử dụng kinh nghiệm của chính mình, coi mình là một end-user, điều tra hệ thống để hiểu về logic, luồng hoạt động để đưa ra các luồng hoạt động và kết quả mong đợi đúng theo logic của hệ thống cũ, từ đó đặt câu hỏi cho khách hàng cũng như đưa ra các đề xuất, phương án tối ưu cho khách hàng. Hãy thường xuyên đặt các câu hỏi 5Whys và vòng tròn vàng What-How-Why để thẩm định chất lượng và tiềm năng của các requirement.
• Để đảm bảo các hoạt động logic của hệ thống cũ được đưa ra đầy đủ và chính xác nhất, cần phải thao tác nhiều với hệ thống và sử dụng nhiều loại data, nghĩ ra nhiều tình huống theo nghiệp vụ của hệ thống. Lý do là, ngoài những gì được thấy dễ dàng trên hệ thống thì có những trường hợp, phải có điều kiện data rất phức tạp thì mới tái hiện được.
• Có thể dựa vào tài liệu mock, basic design mà dev tạo ra để tham khảo, từ đó có thể đưa ra các quan điểm test, thiết kế test case,… Tuy nhiên chỉ nên xem các tài liệu đó như là tài liệu tham khảo, vì nó chưa chắc đúng hoàn toàn, vẫn có thể chứa bug. Trong quá trình tìm hiểu, nếu phát hiện điểm bất hợp lý thì nên confirm ngay lập tức với các thành viên trong team và với khách hàng.
• Đặc biệt, nếu QA có thể đọc hiểu được source code của hệ thống/ ứng dụng có sẵn thì có thể lấy được đầy đủ logic xử lý của hệ thống cũ. Từ đó có thể tạo nên quan điểm test cho hệ thống/ ứng dụng hiện tại, đưa ra được các trường hợp test có thể xảy ra, hạn chế rủi ro nhất có thể. Ngoài ra, vì ứng dụng hoạt động trên nhiều môi trường khác nhau nên sẽ dựa theo môi trường vận hành của hệ thống mới kết hợp kỹ năng test để đưa ra thêm các quan điểm test, các test case phù hợp. Ví dụ về giao diện, các case theo các thuộc tính của item, môi trường test, thiết bị test…
• Có thể thực hiện test thăm dò, test ở những điểm thường hay có lỗi xảy ra. Sử dụng nguyên lý 80/20 để "khoan" trúng các vấn đề quan trọng cần giải quyết.
• Tổ chức các buổi meeting để cùng nhau thảo luận, confirm mức độ hiểu với tất cả thành viên trong team dự án, chia sẻ kiến thức về dự án, tham chiếu các dữ liệu lịch sử của doanh nghiệp đã từng triển khai (organization asset - tài sản kinh nghiệm của tổ chức)…

2. Requirement mơ hồ

Requirement mơ hồ do nhiều nguyên nhân. Đôi khi quá nhiều thông tin cũng có thể khiến requirement trở nên mơ hồ.

Thí dụ:
Khách hàng đưa ra requirement như sau: Thêm chức năng upload image vào màn hình thêm mới thông báo.

Một yêu cầu không rõ ràng, với rất nhiều vấn đề được đặt ra, ví dụ như: Không biết image có định dạng như thế nào, dung lượng tối đa là bao nhiêu, trường hợp xảy ra lỗi thì xử lý như thế nào, hiển thị message gì,… Thí dụ hiện nay đang có xu hướng sử dụng các định dạng ảnh .webp rất phổ biến do độ chính xác cao, ít nhiễu và dung lượng thấp. Tuy nhiên không phải công nghệ nào cũng hỗ trợ định dạng này. Nếu nhà thầu không đáp ứng được yêu cầu đặc thù này trong khi khách hàng rất khó tính thì rất dễ xảy ra xung đột khi nghiệm thu.

Khi khách hàng đưa ra yêu cầu mơ hồ, không rõ ràng, thiếu thông tin như vậy dẫn đến việc gây rất nhiều khó khăn trong việc xác nhận chính xác yêu cầu, mong đợi từ phía khách hàng. Nếu ngay từ đầu hiểu sai yêu cầu của khách hàng hoặc confirm không rõ ràng với khách hàng thì sẽ rất nguy hiểm, dẫn đến hiểu sai toàn bộ chức năng trong yêu cầu cũng như logic hoạt động, luồng xử lý của hệ thống/ứng dụng… Do đó gây ra nhiều rủi ro cao trong dự án.

Giải pháp:

• Hãy thử tìm hiểu, tham khảo từ các hệ thống/ ứng dụng khác tương tự để hiểu được logic hoạt động, cách thức xử lý khi thao tác với hệ thống/ ứng dụng đó hoặc có thể sử dụng kinh nghiệm, sự từng trải trong các dự án từ đó giúp cho các bạn có thể xác định logic, luồng làm việc, nhận ra những điểm đang bị thiếu sót. Cần làm rõ, từ đó đặt ra tất cả câu hỏi, vấn đề liên quan cũng như đưa ra đề xuất tương ứng cho khách hàng để làm rõ và hiểu chính xác nhất về yêu cầu mà khách hàng mong muốn.
• Tổ chức các buổi họp cùng với các thành viên trong team để cùng nhau xem xét vấn đề gặp phải và tìm hướng giải quyết, ví dụ các buổi họp brainstorming (tư duy sâu), họp chuyên đề (focus group). Trong cuộc họp đó, mọi người có thể chia sẻ thông tin mà mình đã tìm hiểu được, từ đó cùng nhau thảo luận cũng như xác nhận mức độ hiểu của tất cả thành viên, sau đó cùng nhau xem xét danh sách Q&A (hỏi đáp sâu) trước chuyển sang phía khách hàng để làm rõ hơn yêu cầu.

3. Requirement không thống nhất

Thí dụ: Khách hàng đưa ra yêu cầu sau:
– Yêu cầu 1: User là Admin, Editor của tổ chức thì có quyền truy cập đến màn hình Quản lý tổ chức. Đối với User là Viewer, Guest khi truy cập thì chuyển đến màn hình lỗi 403.
– Yêu cầu 2: Trường hợp user là Admin, Editor khi truy cập vào màn hình Quản lý tổ chức thì hiển thị button Thêm mới tổ chức. Trường hợp user là Viewer, Guest khi truy cập vào màn hình Quản lý tổ chức thì button Thêm mới tổ chức sẽ bị ẩn đi.

Requirement của khách hàng đang bị xung đột với nhau. Ở yêu cầu 1 thì user là Viewer, Guest thì không được phép truy cập đến màn hình Quản lý tổ chức. Tuy nhiên, ở yêu cầu 2 thì lại đang mô tả cho phép user là Viewer, Guest truy cập vào màn hình đó.

Giải pháp:

• Hãy xem xét, phân tích, đánh giá, đưa ra quan điểm về từng yêu cầu đó, đặt mình ở vị trí là end-user để đưa ra logic xử lý, luồng hoạt động hợp lý, từ đó chỉ ra những điểm bất hợp lý, mâu thuẫn hoặc chưa phù hợp trong các yêu cầu đó, từ đó đưa ra giải pháp tối ưu, sát với thực tế và phù hợp nhất với mong đợi của người dùng.
• Chỉ rõ sự xung đột này với khách hàng bằng cách phân tích rõ từng yêu cầu, chỉ ra những điểm bất hợp lý, mâu thuẫn hoặc chưa phù hợp, từ đó đưa ra đề xuất với khách hàng theo hướng mà mình dự định làm.

4. Requirement bị thay đổi liên tục

Trong mỗi dự án, việc khách hàng thay đổi yêu cầu liên tục là điều khó tránh khỏi, là chuyện “cơm bữa” của cả team dự án. Riêng đối với QA thì đó là cả một quá trình "đau đớn" (painful), nhiều khi khách hàng chỉ update một chỗ nhỏ, hoặc khi các bạn Dev chỉ thêm/sửa/xóa một dòng code theo rule do PM đưa ra, nhưng QA phải sửa lại toàn bộ Test Case, test lại toàn bộ chức năng, màn hình đã test xong trước đó. Nếu requirement thay đổi mất kiểm soát, hoặc PM không thực sự "On top of things" (bao quát mọi thứ), hoặc quy trình "follow-up" không hiệu quả, thì cả hệ thống sẽ giống như "quả bom nổ chậm". Rất có thể "bug" chỉ phát hiện khi QA team sang demo/nghiệm thu bên khách hàng, đó là điều hết sức nguy hiểm như câu thơ sau thay lời muốn nói:

Bao năm xây chùa không ai biết.
Nửa viên gạch vỡ, cả làng hay.

Giải pháp:

• Trong giai đoạn phân tích yêu cầu, khi phát hiện thấy những điểm bất thường, không hợp lý… thì phải confirm với khách hàng ngay lập tức, nếu có thể hãy đưa ra các đề xuất về hướng xử lý cho khách hàng, nhằm giảm thiểu sai sót ngay từ giai đoạn đầu và tránh dẫn đến nhiều thay đổi sau này.
• Khi có bất kì một sự thay đổi nào từ phía khách hàng thì hãy tổ chức các buổi họp để các thành viên trong team cùng nắm được vấn đề, cùng nhau đánh giá, phân tích về yêu cầu thay đổi để xem nó có đúng đắn và hợp lý hay không, điều tra, phân tích về mức độ ảnh hưởng.
• Update tài liệu test ngay sau khi yêu cầu thay đổi đã được xác nhận để đảm bảo test case đúng với yêu cầu mới nhất của khách hàng.

5. Requirement đã cũ

Giải pháp:

• Hãy kiểm tra tất cả tài liệu liên quan được tạo vào thời gian nào, hãy confirm với khách hàng xem đó có phải là phiên bản mới nhất hay chưa. Nếu đã có sẵn hệ thống/ứng dụng thì hãy đối chiếu với các thông tin có trong tài liệu, từ đó xem xét thông tin nào có thể sử dụng.
• Confirm với khách hàng để họ có thể cung cấp tài liệu, thông tin mới nhất hoặc có thể update lại tài liệu cho mình hay không.
• Trong trường hợp requirement đã cũ do nghị định, chính sách thay đổi. Cần có hình thức swap (hoán đổi) để ưu tiên các requirement mới. Ưu tiên cắt các requirement ít quan trọng, chưa đủ luồng để vận hành thực tế và các requirement "nice-to-have", "could-have" (có cũng được, không có cũng được).

III. Kết luận

Sự mơ hồ và thiếu các tiêu chí khách quan là hai đặc điểm phổ biến của các yêu cầu gây khó chịu. Bất kỳ sự đánh giá, đo lường nào cũng nên được đưa ra trong bối cảnh của một tình huống cụ thể. 

Những giải pháp cho từng trường hợp trên là một trong nhiều bí quyết  góp phần hạn chế được những rủi ro, những lỗi không mong muốn trong dự án, giúp cho dự án đạt chất lượng cao nhất, đáp ứng được yêu cầu, sự hài lòng của khách hàng.

Ngoài ra, khi có tranh chấp xảy ra về phạm vi requirement hoặc khó khăn trong nghiệm thu giữa các bên, một lời khuyên hữu ích là "thẩm định lại tài liệu Spec". Mục đích không phải đào bới lỗi hay "bới bèo ra bọt", mà các bên cùng nhìn ra khiếm khuyết của quy trình đầu vào.  Theo nguyên tắc đường ống (pipeline), đầu vào chất lượng như nào thì đầu ra sẽ phản ánh như vậy.

Tham khảo: Thẩm định chất lượng tài liệu yêu cầu phần mềm diễn ra như thế nào?

Trong quá trình làm việc với dự án, bạn sẽ phải gặp nhiều trường hợp, tình huống khó khăn, éo le và bắt buộc bạn phải tìm hướng giải quyết và thích nghi với nó. Dù trong trường hợp như thế nào đi chăng nữa, bạn cũng phải bình tĩnh xem xét, phân tích kĩ vấn đề, đưa ra hướng giải quyết hợp lý để đạt được mục tiêu cuối cùng là phát triển dự án và đảm bảo được chất lượng tốt nhất cho sản phẩm.

Trần Tươi