TỐI ƯU HÓA PHÂN TÍCH YÊU CẦU VÀ TẠO TESTCASE
15/03/2022 853
Tối ưu hóa phân tích yêu cầu và tạo testcase sẽ giúp tối ưu hóa công việc cho cả QA và DEV
Khi đọc hiểu yêu cầu một dự án, thông thường chúng ta sẽ đọc từ các tài liệu mà khách hàng cung cấp. Nếu có chỗ nào không hiểu, ta sẽ xác nhận lại thông tin với team, nếu vẫn không hiểu thì sẽ tạo Q&A để hỏi khách hàng.
Đây là một cách làm nhanh và phổ biến mà nhiều người, trong đó có cả QA và DEV, vẫn đang thực hiện. Cách xử lý thông tin kiểu này rất khiến dự án nắm bắt thông tin một cách bị động, mỗi cá nhân chỉ hiểu yêu cầu một cách mơ hồ. Từ đó, rất dễ dẫn đến tình trạng bỏ sót thông tin, gây ảnh hưởng đến chất lượng sản phẩm cuối.
Vậy làm thế nào để có thể phân tích yêu cầu hiệu quả, từ đó xây dựng được bộ testcase chính xác, tối ưu hóa hiệu quả test? CO-WELL Asia xin chia sẻ đến các bạn một số BÍ KÍP khi phân tích yêu cầu và tạo testcase.
1. PHÂN TÍCH YÊU CẦU
Việc phân tích yêu cầu (requirement) kỹ càng, toàn diện giúp QA cũng như DEV hiểu rõ mong muốn của khách hàng về sản phẩm và luồng nghiệp vụ của dự án.
Mặt khác, sau khi xác định được yêu cầu của khách hàng và xác định được đối tượng test thì việc đọc-hiểu tài liệu dự án (specs) cũng trở nên nhanh chóng và hiệu quả hơn.
Để phân tích yêu cầu hiệu quả, ta sẽ thực hiện theo 3 bước sau:
Bước 1: Xác định yêu cầu của khách hàng:
Các requirement cần được tổng hợp một cách chính xác, cụ thể. Tại các buổi giải thích tài liệu hệ thống mà phía khách hàng tổ chức, bất kỳ ai cung cấp thông tin yêu cầu đều rất quan trọng. Ngược lại, đội dự án khi tiếp nhận thông tin phải đưa ra những giải thích rõ ràng, phù hợp để hiểu được mong đợi của các bên liên quan.
Bước 2: Xác định được đối tượng test:
Đối tượng có thể là 1 màn hình, 1 chức năng, 1 item, 1 chuỗi xử lý, 1 batch hoặc có thể liên quan tới API, GUI,… Dù đối tượng là gì, chúng ta đều cần làm rõ để có kế hoạch test rõ ràng.
Việc xác nhận được chính xác yêu cầu của khách hàng và đối tượng test sẽ giúp QA sớm tìm được phạm vi ảnh hưởng và phạm vi test 1 cách nhanh chóng. Ngoài ra, còn giúp đưa ra quan điểm chính xác, tăng độ bao phủ khi tạo testcase.
Có nhiều trường hợp, sau khi nhận được spec thì đội dự án sẽ lao vào đọc và phân tích, rồi liên tục gửi Q&A cho khách hàng. Trong khi đó, chính nội bộ dự án cũng chưa hiểu hết và có những bất đồng về quan điểm. Điều này yêu cầu phải có bước 3, tổ chức buổi họp phân tích spec để thống nhất độ hiểu spec cho toàn bộ thành viên.
Bước 3: Tổ chức buổi họp nội bộ phân tích specs
Trong buổi họp này, đội dự án có thể cùng nhau phân tích trước những Q&A định gửi cho khách hàng. Điều này sẽ giúp tăng hiệu quả làm việc, giảm thời gian chờ khi gửi Q&A cho khách hàng.
Cụ thể dưới đây là các điểm cần chú ý khi phân tích requirement:
- Chức năng/màn hình đó dùng để làm gì?
- Đối tượng liên quan tới những chức năng/màn hình nào?
- Dữ liệu được lấy từ đâu? Tạo dữ liệu liên quan từ màn hình nào?
- Điều kiện để hiển thị màn hình này là gì?
- Màn hình này sẽ dẫn tới những màn hình nào?
- Output của màn hình/chức năng này là gì? Lưu ở bảng nào?
- Chức năng/màn hình này có cần sắp xếp không? Quy tắc sắp xếp là gì?
- Chức năng màn hình này có hình ảnh không? Quy tắc lưu trữ và get ảnh như thế nào?
- Màn hình có phân trang không? Sẽ có bao nhiêu record trên 1 trang?
- Có phải tính toán gì không? Công thức tính toán như thế nào?
- Khi không có dữ liệu thì xử lý như thế nào?. Khi nhiều dữ liệu xử lý như thế nào?
- Trạng thái mặc định sẽ hiển thị những gì?
- Các trường cần validate là những trường nào? Quy tắc validate như thế nào?
- Các case kiểm thử không hợp lệ là gì? (với mỗi trường, với cả màn hình).
- XSS, SQL injection và các case dị thường.
- Các trường trong màn hình input có mâu thuẫn với nhau hay không?
Sau khi đã làm rõ vấn đề theo các điểm trên, QA có thể hiểu rõ được flow nghiệp vụ cũng như chức năng của dự án. Từ đó viết được testcase theo 1 quan điểm chính xác.
2. TẠO TESTCASE
Khi tạo testcase, điều quan trọng là phải đảm bảo QA đã xem xét đến mọi khía cạnh trong yêu cầu ban đầu của khách hàng. Để làm điều này, chúng ta sẽ sử dụng một công cụ hỗ trợ vô cùng mạnh mẽ, đó là ma trận Requirement Traceability Matrix (RTM).
RTM là gì?
Requirement Traceability Matrix hay còn gọi là Ma trận truy xuất yêu cầu (viết tắt là RTM) là một tài liệu nhằm thể hiện mối quan hệ giữa các yêu cầu và những yếu tố liên quan. Nó nhằm xác nhận xem một yêu cầu đã được đáp ứng hay chưa. Một tài liệu RTM thường bao gồm: yêu cầu của khách hàng, test case, kết quả test và các issue.
RTM là một công cụ không thể thiếu khi muốn tối ưu hóa phân tích yêu cầu và tạo testcase. Một số lợi ích khi sử dụng RTM:
- Ma trận giúp liên kết các yêu cầu với các testcase, các defect một cách chính xác.
- Giúp quản lý chất lượng tốt hơn, giữ defect ở mức tối thiểu, các yêu cầu về chức năng và phi chức năng đều được thỏa mãn.
- Hỗ trợ cho execution test được test trong khoảng thời gian quy định, scope của dự án được xác định rõ ràng, việc thực hiện RTM đạt được theo yêu cầu của khách hàng và chi phí của project được kiểm soát tốt.
- Sử dụng làm bằng chứng để chứng minh độ bao phủ toàn diện (tất cả requirement đã được tính đến trong testcase) và tất cả các rủi ro đã được tìm thấy trong dự án.
Có rất nhiều loại ma trận RTM. Trong phạm vi bài viết, chúng ta hãy cùng tìm hiểu cơ bản về ma trận Bi-Directional Traceability
Ma trận Bi-Directional Traceability là sự kết hợp giữa Forward và Backward. Sẽ có các tham chiếu từ testcase đến requirement và ngược lại. Mục đích để đảm bảo tất cả testcase tuân thủ theo requirement, và mỗi requirement cụ thể đều có testcase chính xác và valid cho chúng.
Công dụng của Bi-Directional Traceability Matrix
1. Biết được requirement được thực thi ở đâu trên ứng dụng.
Ví dụ:
- Requirement: Thực hiện chức năng ‘Soạn thư’ trong ứng dụng thư.
- Implementation: nút ‘Soạn thư’ nên được đặt và truy cập được ở trang chính.
2. Xác định requirement đó có cần thiết hay không.
Ví dụ:
- Requirement: Yêu cầu chức năng ‘Soạn thư’ chỉ cho một số người dùng nhất định.
- Implementation: Theo quyền truy cập của người dùng, nếu hộp thư đến email là “Chỉ đọc” thì sẽ không cần điều kiện cho nút “Soạn thư” nữa.
3. Diễn giải chi tiết các requirement.
Ví dụ:
- Requirement: Chức năng ‘Soạn thư’ trong ứng dụng có lựa chọn phông chữ và tệp đính kèm.
- Implementation: Khi nhấp vào “Soạn thư”, tất cả các tính năng có được hiển thị hay không?
- Trong text body để viết email và chỉnh sửa bằng các loại phông chữ khác nhau và cũng in đậm, in nghiêng, gạch chân chúng
- Các loại tệp đính kèm (Hình ảnh, tài liệu, email khác, v.v.)
- Kích thước của tệp đính kèm (Kích thước tối đa cho phép)
Trường hợp này, requirement chính sẽ được chia nhỏ thành các yêu cầu phụ.
4. Những quyết định về thiết kế nào ảnh hưởng tới việc thực thi requirement?
Ví dụ:
- Requirement: tất cả các phần tử Hộp thư đến, Thư đã gửi, Thư nháp, Spam, Thùng rác, v.v. phải hiển thị rõ ràng.
- Implementation: Các phần tử được hiển thị phải ở định dạng cây hoặc thành các Tab.
5. Các requirement đã được phân bổ hợp lý hay chưa?
Ví dụ:
- Requirement: cung cấp tính năng “Trash” (thùng rác)
- Implementation: nếu có Trash, thì tính năng “Xóa” phải được phát triển trước và phải hoạt động chính xác. Nếu ‘Xóa’ hoạt động bình thường, thì những mail đã bị xóa sẽ được tập hợp trong Trash. Khi đó việc phát triển tính năng “Trash’” theo yêu cầu mới hữu ích.
Ưu điểm của Bi-Directional Traceability Matrix
Dưới đây là một số ưu thế của Bi-Directional Traceability Matrix so với các hình thức ma trận khác:
1. Đảm bảo các chức năng bắt buộc đều được phát triển và kiểm thử, đáp ứng được mong đợi của khách hàng.
2. Nếu 1 DEV ứng dụng ma trận này, thì sẽ dễ nhìn thấy những requirement có mức độ ưu tiên cao để sắp xếp kế hoạch phát triển phù hợp. Điều này đảm bảo sản phẩm cuối cùng được đưa tới khách hàng theo yêu cầu hàng đầu và đúng tiến độ.
3. Nếu QA/tester thực thi ma trận này, thì QA/tester sẽ xác nhận được các function nào trọng nhất đang được ưu tiên phát triển. Nó sẽ giúp xác định thời điểm khi nào hệ thống sẵn sàng để release.
4. Việc đối chiếu requirement với test case giúp đảm bảo không có defect lớn bị lọt, tăng chất lượng sản phẩm theo mong đợi của khách hàng
5. Khi có requirement thay đổi từ phía khách hàng, các yếu tố bị ảnh hưởng bởi yêu cầu đó sẽ được sửa đổi ngay và không bị bỏ sót. Điều này giúp nâng cao việc đánh giá về effort cần sử dụng trước khi đồng ý thực hiện thay đổi, ảnh hưởng của thay đổi tới sản phẩm hiện tại.
6. Traceability Matrix sẽ làm rõ được các khoảng trống. Theo nguyên tắc chung, bất kỳ khoảng trống nào trong ma trận đều tiềm ẩn vấn đề cần điều tra. Nguyên nhân có thể do QA đã bỏ sót 1 chức năng nào đó, hoặc nó đã bị pending/bị xóa. Khi đó QA sẽ phải tiến hành cập nhật lại tài liệu.
Vì những lý do trên, RTM là một công cụ hữu dụng và mạnh mẽ để giúp QA thấy được những lỗ hổng trong testcase. Từ đó có phương án để xử lý khắc phục, đảm bảo bộ test case đã bao phủ toàn bộ các phương diện cần thiết.
KẾT LẠI
Traceability Matrix không chỉ là một công cụ hữu hiệu dành cho QA. Team DEV cũng có thể sử dụng nó để đối chiếu các requirement với phần code đã phát triển. Từ đó đảm bảo các requirement cơ bản đều đã được đáp ứng.
Ngoài ra, để giảm thời gian và tăng hiệu quả test, chúng ta cũng cần chú ý đến một vài lưu ý sau:
- Khi log Q&A thì cần có KEYWORD như là: tên chức năng chính, tên màn hình liên quan,… ở đầu dòng để member trong dự án dễ theo dõi việc thay đổi spec.
- Nội dung Q&A cần đưa ra trường hợp cụ thể và có đề xuất giải quyết, hoặc xác nhận cách hiểu của mình về vấn đề đang hỏi. Điều này giúp khách hàng trả lời nhanh chóng hơn và tăng hiệu quả log Q&A.
Chúc các bạn tối ưu hóa phân tích yêu cầu và tạo testcase thành công!
CO-WELL ASIA
Tham khảo các bài viết khác của CO-WELL Asia tại đây.
