Yêu cầu (requirement) là một phần khá nhỏ, nhưng kỹ năng đọc hiểu và phân tích lại to. Vì sẽ có rất nhiều nội dung công việc của tester là liên quan đến yêu cầu, nên kiểu gì thì kiểu, mình sẽ phải viết một bài cho riêng nó.
Khái niệm
Có nhiều thể loại phát biểu Requirements, nào thì requirement là các yêu cầu của khách hàng, nào thì là yêu cầu của người dùng, nào thì là yêu cầu của hệ thống, nào thì là yêu cầu của khách hàng,... Nhưng chung quy lại, đâu thể nào dùng "yêu cầu" để giải thích "Thế nào là yêu cầu?" phải không ạ?.
Yêu cầu là phát biểu, hoặc ràng buộc lên thiết kế của một sản phẩm phần mềm nhằm mục đích phục vụ nhu cầu của khách hàng | Requirement is a statement or constraint on the design of a software product to serve the needs of the customer
Đó, hiểu nôm na chính là như thế. Ví dụ nếu nói là Người dùng có thể đăng nhập sử dụng tài khoản Google, nó là một yêu cầu, vì nó đang ám chỉ rằng khách hàng muốn tính năng đăng nhập bằng tài khoản Google, và anh phải làm cho họ cái đấy.
Một kiểu yêu cầu khác là Người dùng chỉ có thể đăng nhập khi đã tích captcha, đây là một yêu cầu, do chúng ta có thể dễ thấy bản thân nó là một ràng buộc về tính năng đăng nhập, nó ám chỉ tính năng đăng nhập của các anh phải có captcha. Hay một kiểu khác Trang web phải vận hành trên backend NodeJS, đây cũng là một yêu cầu dạng ràng buộc, anh không thể nào làm backend bằng các framework khác được, anh phải làm bằng NodeJS, vì đội ngũ maintainer bên khách hàng chỉ biết mỗi NodeJS thôi.
Typical question: What is requirement? - Yêu cầu là gì?
Statement and Constraint
Một yêu cầu khi tồn tại ở dạng một phát biểu thường sẽ nêu lên một điều gì đó mà sản phẩm cần phải có, thường sẽ là tính năng, hoặc một hành vi cụ thể. Khi nhìn vào một yêu cầu được diễn đạt ở dạng phát biểu, câu từ của nó sẽ tuân theo một kiểu cấu trúc nhất định:
Là một người dùng, tôi muốn... | As a user, I want... Khi tôi làm..., tôi muốn... | When I do..., I want...
Còn khi yêu cầu được diễn đạt ở dạng ràng buộc, thì nó sẽ nêu lên một điều kiện cần phải được đáp ứng ở thiết kế của sản phẩm, thường sẽ là một điều kiện để một tính năng hoặc hành vi hoạt động đúng như mong muốn, hoặc một hạn chế. Câu từ của nó thường sẽ tuân theo một kiểu cấu trúc nhất định:
Người dùng phải... | User must... Hệ thống phải... | System must... Hệ thống cần... | System needs...
Typical question: What is the difference between statement and constraint? - Sự khác biệt giữa statement và constraint là gì?
Typical question: How does a requirement look like? - Một yêu cầu trông như thế nào?
Types of constraint
Nôm na thì các ràng buộc sẽ có một số loại cơ bản:
- Ràng buộc về chất lượng / Quality Constraint : Là các ràng buộc về chất lượng của sản phẩm, tỉ lệ lỗi, tỉ lệ downtime, khả năng phát triển,
- Ràng buộc về môi trường / Environment Constraint : Ràng buộc về môi trường làm việc của sản phẩm, như là hệ thống phải chạy trên môi trường nào đó
- Ràng buộc về thiết kế / Design Constraint: Ràng buộc về thiết kế, ví dụ như hệ thống phải sử dụng một framework nào đó cho backend
- Ràng buộc về hiệu năng / Performance Constraint: Ràng buộc về hiệu năng, như là hệ thống phải xử lý được 100 người dùng đồng thời, phải xử lý được yêu cầu trong vòng bao nhiều giây, v.v...
Typical question: What are the types of constraint? - Có những loại ràng buộc nào?
Levels of Requirement
Yêu cầu cũng có các tầng (Level), nhìn vào sơ đồ dưới đây:
Hiểu đơn giản thế này:
- Business Level Requirement: Đây là yêu cầu của khách hàng, tất cả những cái gì kinh khủng, vĩ mô, xịn xò về sản phẩm. Ví dụ như Ứng dụng sẽ mở rộng hoạt động của doanh nghiệp đến khách hàng phổ thông, len lỏi vào cuộc sống thường ngày hay là Trang web sẽ quảng bá, tăng cường sức ảnh hưởng và độ phủ của thương hiệu rồi thì ABCXYZ. Thường thì tester chúng ta không cần quan tâm đến cái này, vì cái này thuộc về kinh tế, marketing, v.v... nếu có thì có thể cần nắm sơ sơ để biết sản phẩm là về cái gì.
- User Level Requirement: Đây là yêu cầu của người dùng, nói chung là cái mà người dùng muốn, cái mà người ta muốn sử dụng trên sản phẩm, muốn nhìn thấy, muốn tương tác với nó. Về cơ bản đây là các yêu cầu về tính năng đầu cuối (end-user function), hay các yêu cầu về chất lượng (quality)
- System Level Requirement: Đây là yêu cầu của hệ thống, nói chung là cái mà hệ thống cần phải có, những gì nằm ở sau cái lớp frontend, cái mà người dùng không thấy, nhưng lại góp phần quan trọng vào hỗ trợ các yêu cầu người dùng.
Ví dụ, User Level Requirement có thể có : Người dùng có thể theo dõi chi tiêu trong tháng trong một ứng dụng ngân hàng, thì System Level Requirement có thể có: Hệ thống phải lưu trữ dữ liệu chi tiêu của người dùng trong 365 ngày gần nhất và cho phép truy vấn thống kê của tháng
Typical question: What are the levels of requirements? - Có những tầng yêu cầu nào?
Functional and Non-Functional Requirement
Cũng chính trên cái sơ đồ kia mà chúng ta nhìn thấy cái gọi là "Functional" và "Non-Functional". Đây là hai loại yêu cầu cơ bản của một sản phẩm phần mềm:
- Yêu cầu chức năng (Functional Requirement): Là những yêu cầu về các chức năng, hành vi của sản phẩm, về cơ bản nó trả lời cho câu hỏi Sản phẩm làm được những gì?
- Yêu cầu phi chức năng (Non-Functional Requirement): Là những yêu cầu về chất lượng, hiệu suất, bảo mật, v.v... của sản phẩm, về cơ bản nó trả lời cho câu hỏi Sản phẩm làm như thế nào? hay Sản phẩm làm ... tốt đến đâu ?
Một ví dụ cơ bản về yêu cầu chức năng là : Người dùng có thể đăng nhập vào hệ thống bằng tài khoản Google, chính ví dụ ở trên, còn một ví dụ về yêu cầu phi chức năng là: Hệ thống phải xử lý được 100 người truy cập và sử dụng đồng thời
Typical question: What are functional and non-functional requirements? - Yêu cầu chức năng và phi chức năng là gì?
Study and clarify requirement
Để "học" một requirement, tức là đọc, phân tích, xác minh cách hiểu của bản thân về một yêu cầu, tester đi qua một chuỗi hành động như sau:
- Đọc requirement đưa ra bởi khách hàng, các requirement document, các tài liệu liên quan, lấy ra các diễn đạt yêu cầu ở dạng lời văn
- Bóc tách ý tứ của các lời văn, xác định các đặc điểm của yêu cầu theo một logic thống nhất
- Phân tích đặc điểm, tìm những vấn đề bản thân không hiểu, hoặc không thể hiểu - dường như là lỗi logic hoặc lỗi diễn đạt của yêu cầu
- Lập ra các câu hỏi giúp xác minh yêu cầu, hoặc giúp hiểu rõ hơn về yêu cầu và gửi cho các bên liên quan
Đầu tiên, chúng ta sẽ đi 2 hạng mục ở trên, đọc và bóc tách. Phần đọc thì dễ rồi, trừ khi bạn không biết chữ, nhưng phụ thuộc vào cách viết requirement, đôi khi cách diễn đạt của chúng nó rất tối nghĩa, rất mông lung (ambiguous), vậy thì ngay lúc này cần phải note lại và đưa về phía BA để giúp làm rõ ý tứ của yêu cầu.
Sau đấy, cứ coi như yêu cầu khá dễ hiểu, chúng ta mường tượng ra khách hàng muốn cái gì, đi đến bước phân tích yêu cầu. Bản chất vấn đề ở đây là chúng ta sẽ không phân tích yêu cầu như kiểu Dev làm, vì Dev phân tích yêu cầu là để hiểu rõ về yêu cầu tính năng, từ đấy xây dựng tính năng. Còn chúng ta hiểu rõ yêu cầu để biết từ phía người dùng, một tính năng sẽ được sử dụng như thế nào, từ đấy lập ra phương án kiểm thử tính năng đấy khi Dev nhả hàng.
Typical question: What are the steps to study a requirement? - Các bước để học yêu cầu là gì?
Study a functional requirement
Để có thể nghiên cứu một yêu cầu chức năng, chúng ta thực hiện việc bóc tách thông tin từ yêu cầu ở dạng lời văn và điền vào những mục sau:
- Mục đích / Purpose: Mục đích tồn tại của chức năng, nó giúp người dùng cái gì, người dùng sử dụng nó cho việc gì
- Nhân tố / Actor: Những người sử dụng chức năng, những người tương tác với chức năng
- Tiền điều kiện / Precondition: Những điều kiện cần phải đạt được trước khi chức năng có thể được sử dụng
- Kích hoạt / Trigger: Sự kiện hoặc hành động mà người dùng thực hiện để kích hoạt chức năng
- Chuỗi hành động / Workflow: Các bước thực hiện của chức năng, những gì xảy ra khi chức năng vận hành
- Chuỗi phụ / Alternate Flow: Các bước thực hiện khác, khi một số điều kiện phụ xảy ra, hoặc người dùng thực hiện chức năng thông qua một kích hoạt khác, hoặc khi chức năng thất bại
- Hậu điều kiện / Postcondition - Result: Kết quả của việc sử dụng chức năng, những gì người dùng nhận được sau khi sử dụng chức năng
- Luật nghiệp vụ / Business Rules: Những quy tắc, luật lệ, điều kiện mà chức năng phải tuân thủ
Typical question: What are the steps to study a functional requirement? - Các bước để học yêu cầu chức năng là gì?
Study an UIUX requirement
Cái này thì mình sẽ nói nhanh thôi, tóm lại là để nghiên cứu một yêu cầu giao diện, chúng ta đi qua 3 phần:
- Mockup / Design / Prototype: Để biết được nôm na thiết kế giao diện trông như thế nào
- Element Description: Để biết được cụ thể các thành phần của UI như thế nào, nó làm gì, nó tương tác với người dùng như thế nào
- Style: Để biết được cách thiết kế, màu sắc, font chữ, v.v... của giao diện Và khi thực hiện kiểm thử giao diện, thì chỉ cần giao diện sản phẩm đúng với thiết kế ở cả 3 mặt trên là xong.
Typical question: What are the steps to study an UIUX requirement? - Các bước để học yêu cầu giao diện là gì?
Clarify requirement
Để xác minh yêu cầu, chúng ta cần phải lập ra các câu hỏi, câu hỏi này sẽ giúp chúng ta hiểu rõ hơn về yêu cầu, hoặc giúp xác minh yêu cầu.
Trước khi đưa câu hỏi đi, cần phải đảm bảo rằng:
- Câu hỏi thật sự chuẩn, tức là nó thật sự là những cái khó hiểu, không thể hiểu, dường như có vấn đề. Chúng ta cần động não trước, chứ không phải cứ thấy hơi chuối là đưa câu hỏi lên.
- Xác thực câu hỏi chưa được trả lời trong các tài liệu cứng mà chỉ đơn giản là chúng ta lướt qua không để ý thấy
- Câu hỏi đúng trọng tâm, không lan man, không hỏi lấy cảm tính
- Các câu hỏi về kỹ thuật, nên đi qua chị Google trước, để đảm bảo đây không phải là kiến thức chung mà đơn giản là chúng ta không biết
- Nếu là các câu hỏi về lựa chọn, chúng ta nên gợi ý lựa chọn cho khách hàng / BA thay vì bắt họ lựa chọn và bỏ thời gian ra nghiên cứu, chúng ta nên nêu ra luôn chúng ta mạnh ở mảng này mảng kia
Bình thường thì khi chúng ta đặt ra các câu hỏi, chúng ta cần đưa nó lên cho Lead trước, lý do là vì:
- Đầu tiên cần phải xác minh với team trước, rằng câu hỏi này thật sự không ai trả lời được, hoặc là do không ai biết, hoặc là do có quá nhiều khả năng, và một cái quan trọng là chúng ta không được đoán bất cứ cái gì
- Lead sẽ giúp chúng ta giao tiếp với khách hàng và BA, đồng thời, đặt ra deadline cho các câu trả lời, vì không thể đợi câu trả lời mãi đâu, cái gì cũng có lịch của nó, khách hàng / BA mà không bị dí thì họ cứ kề cà
Typical question: What are the thing we should do when raising a question? - Cần làm gì khi đặt câu hỏi?
