REQUIREMENT KHÔNG “LÝ TƯỞNG” VÀ CÁCH XỬ LÝ | CO-WELL Asia

Requirement là một phần không hề thiếu của dự án Bất Động Sản, không riêng gì giúp đội kỹ thuật tăng trưởng những tính năng, giao diện một cách đúng hướng ; mà còn giúp tester / QA triển khai quy trình test một cách trơn tru, chuyển giao được mẫu sản phẩm đúng nhu yếu. Vậy những yếu tố thường gặp với requirement là gì và tester / QA phải giải quyết và xử lý ra làm sao với những trường hợp đó ? Cùng CO-WELL Asia “ giải thuật ” 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ẽ xử lý những yếu tố đó như thế nào ? Chúng ta cùng nhau đi tìm câu vấn đáp cho từng yếu tố 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 thi dự án Bất Động Sả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 trường hợp khó khăn vất vả, người mua không đưa bất kì tài liệu tương quan nào, khiến cho QA gặp rất nhiều rắc rối, khó khăn vất vả và tốn nhiều thời hạn công sức của con người để khám phá, tìm hiểu, đưa ra quan điểm test, phong cách thiết kế test case, … Do đó tiềm ẩn nhiều rủi ro đáng tiếc cao trong dự án Bất Động Sản, dẫn đến việc phát sinh nhiều bug từ người mua, …

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 nhu yếu không rõ ràng, với rất nhiều yếu tố được đặt ra, ví dụ như : Không biết image có định dạng như thế nào, dung tích tối đa là bao nhiêu, trường hợp xảy ra lỗi thì giải quyết và xử lý như thế nào, hiển thị message gì, …→ Khi người mua đưa ra nhu yế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 vất vả trong việc xác nhận đúng mực nhu yếu, mong đợi từ phía người mua. Nếu ngay từ đầu hiểu sai nhu yếu của người mua hoặc confirm không rõ ràng với người mua thì sẽ rất nguy khốn, dẫn đến hiểu sai hàng loạt tính năng trong nhu yếu cũng như logic hoạt động giải trí, luồng giải quyết và xử lý của mạng lưới hệ thống / ứng dụng … Do đó gây ra nhiều rủi ro đáng tiếc cao trong dự án Bất Động Sả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 người mua đang bị xung đột với nhau. Ở nhu yếu 1 thì user là Viewer, Guest thì không được phép truy vấn đến màn hình hiển thị Quản lý tổ chức triển khai. Tuy nhiên, ở nhu yếu 2 thì lại đang diễn đạt được cho phép user là Viewer, Guest truy vấn vào màn hình hiển thị đó .

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 Bất Động Sản, việc người mua biến hóa nhu yế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 Bất Động Sản. Riêng so với chị em QA thì đó là cả một quy trình, nhiều khi người mua chỉ update lại một chỗ nhỏ, nhiều lúc những 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 hàng loạt test case, test lại hàng loạt tính năng, màn hình hiển thị đã 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 tay nghề của bản thân mình có được trong quy trình làm dự án Bất Động Sản, cũng như học hỏi từ kinh nghiệm tay nghề thao tác của những anh chị đi trước. Nó góp thêm phần hạn chế được những rủi ro đáng tiếc, những lỗi không mong ước trong dự án Bất Động Sản, giúp cho dự án Bất Động Sản đạt chất lượng cao nhất, cung ứng được nhu yếu, sự hài lòng của người mua .

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.

Rate this post