REQUIREMENT KHÔNG “LÝ TƯỞNG” VÀ CÁCH XỬ LÝ

24/05/2021 240
web Requirement
CODEWELL TESTING

Requirement là một phần không thể thiếu của dự án, không chỉ giúp đội kỹ thuật phát triển các tính năng, giao diện một cách đúng hướng; mà còn giúp tester/ QA thực hiện công đoạn test một cách trơn tru, bàn giao được sản phẩm đúng yêu cầu. Vậy các vấn đề thường gặp với requirement là gì và tester/ QA phải xử lý ra sao với các trường hợp đó? Cùng CO-WELL Asia “giải mã” nhé!

I. Giới thiệu

requirement ly tuong

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

  • Đầy đủ
  • Rõ ràng
  • Chính xác
  • Nhất quá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 quan điểm test, tạo tài liệu thiết kế test case, test một cách chuẩn xác nhất,… mà không phải phân vân điều gì. Sản phẩm được tạo ra đảm bảo được chất lượng, đúng theo yêu cầu, mong đợi 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
  • Requirement mơ hồ
  • Requirement không thống nhất
  • Requirement bị thay đổi liên tục
  • Requirement đã cũ

→ 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 đề
1. Không có requirement

khong co requirement

Ví dụ:
Khách hàng đã có sẵn một ứng dụng trên smartphone
(SP) 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 SP.

→ Quan điểm để thực hiện dự án này cần:

  • Đảm bảo được toàn bộ logic từ ứng dụng SP sang website.
  • Phân tích việc cần điều chỉnh một số quan điểm (Ví dụ:GUI, chức năng…) để phù hợp với hệ thống website.

→ Đâ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 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ế test case,…Do đó tiềm ẩn nhiều rủi ro cao trong dự án, dẫn đến việc phát sinh nhiều bug từ khách hàng,…

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/ ứ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.
  • Để đả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.
  • 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,…

2. Requirement mơ hồ

req mo ho

Ví 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ì,…

→ 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. 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 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

requ khong thong nhat

Ví 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

requirement thay doi

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 chị em QA thì đó là cả một quá trình, nhiều khi khách hàng chỉ update lại một chỗ nhỏ, đôi khi các bạn dev chỉ thêm/sửa/xóa một dòng code nhưng chị em 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 đó.

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ũ

req da cu

 

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.

III. Kết luận

Những giải pháp cho từng trường hợp trên là kinh nghiệm của bản thân mình có được trong quá trình làm dự án, cũng như học hỏi từ kinh nghiệm làm việc của các anh chị đi trước. Nó 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.

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 – CO-WELL ASIA


Xem thêm bài viết chủ đề công nghệ tại đây.
Đọc thêm nhiều thông tin thú vị về CO-WELL Asia tại đây.