- vừa được xem lúc

Kỹ thuật 5W1H và 30 mẫu câu hỏi phân tích yêu cầu mà mọi tester nên biết

0 0 29

Người đăng: Dang Thi Duyen

Theo Viblo Asia

1. Tư duy phân tích

Tư duy phân tích là khả năng tư duy về một đối tượng, sự vật, hiện tượng để tìm ra các mối liên kết giúp xác định các đặc điểm, tính chất, vai trò đặc trưng của đối tượng đó trong mối quan hệ với các đối tượng khác. Tư duy phân tích có xu hướng tư duy theo chiều sâu và mức độ chiều sâu được thể hiện qua các yếu tố, đặc điểm, tính chất, vai trò mà tư duy phân tích tìm được.

2. Tại sao tư duy phân tích lại quan trọng đối với Tester ?

Hay chúng ta có thể đặt một câu hỏi khác “Nếu Tester không có tư duy phân tích yêu cầu chi tiết, cặn kẽ thì sẽ có vấn đề gì xảy ra?”

Hiểu chưa đầy đủ hoặc hiểu sai về yêu cầu Không nắm hết được các thành phần chức năng có liên quan Thiết kế thiếu nhiều quan điểm test cần thiết Từ đó dẫn tới nhiều trường hợp không được kiểm thử, có thể tiềm ẩn lỗi nghiêm trọng của hệ thống khi bàn giao tới người dùng cuối (ảnh hưởng tới việc mất thời gian, tiền bạc, sức khỏe thậm chí tính mạng con người) Không những thế có thể gây tổn thất như mất uy tín với khách hàng, mất niềm tin về sản phẩm, ảnh hưởng tới kinh doanh.

3. Giới thiệu về kỹ thuật 5W1H

Có nhiều cách để giúp tester nâng cao năng lực tư duy phân tích. Ở đây mình chia sẻ với các bạn 1 kỹ thuật thường được áp dụng và cũng không quá khó để thực hiện. Đó là kỹ thuật 5W1H

5W1H là kỹ thuật mà Tester có thể áp dụng để phân tích yêu cầu W là viết tắt của các từ What, Why, Who, When, Where

H và viết tắt của từ How

Đây là kỹ thuật hỗ trợ tư duy giúp tester đặt ra các câu hỏi để làm sáng tỏ yêu cầu.

4. Hơn 30 câu hỏi áp dụng kỹ thuật 5W1H trong phân tích yêu cầu mọi tester nên biết

WHAT question

What is the problem? Vấn đề gì cần được giải quyết?

What features are? Các tính năng gì cần làm?

What is the output when input is default/empty/long/max/color/specials? Kết quả đầu ra như thế nào khi đầu vào là giá trị mặc định, bỏ trống, giá trị dài, giá trị tối đa, các giá trị đặc biệt,…?

What is the input: size/type/ways/default? Loại đầu vào, kích thước, giá trị mặc định là gì?

What should be the precondition? Có tiền điều kiện gì không?

What should be the post condition? Điều kiện gì xảy ra sau thực hiện hành động?

What is the impact on other features? Có vùng ảnh hưởng gì lên các tính năng khác không?

What is the scope? Phạm vi chức năng là gì?

What is the schedule? Thời gian thực hiện, thời gian bàn giao?

What information should we save? Thông tin gì chúng ta nên có, nên cần thêm?

What color is that? Màu sắc gì?

What will happen for positive scenarios/ Negative scenarios? Điều gì sẽ xảy ra cho các trường hợp hợp lệ, không hợp lệ?

WHERE question

Where should it be displayed? Hiển thị tính năng ở đâu?

Where will the feature be used? Tính năng này được sử dụng ở đâu?

Where should it be started? Nên bắt đầu từ đâu?

Where should it be completed? Hoàn thành/Kết thúc ở đâu?

WHEN question

When the idea is established? Khi nào ý tưởng này được thiết lập?

When will the feature be used? Khi nào tính năng này được sử dụng?

When will the features fail? Khi nào tính năng này thất bại?

When do we need to elicit the detail requirement? Khi nào chúng ta cần đào sâu yêu cầu chi tiết hơn?

WHO question

Who will use this feature/product? Tính năng này dành cho ai? Hay ai sẽ là người sử dụng tính năng này?

Who will provide the information? Ai sẽ cung cấp thêm thông tin ?

Who needs the information? Ai cần thông tin?

Who can edit the information? Ai có thể edit thông tin?

Who is the administrator? Ai sẽ là admin?

Who will benefit from this feature? Ai sẽ được lợi ích từ tính năng này?

HOW question

How is this feature working? Tính năng này hoạt động như thế nào?

How does this feature interact with other features/systems? Tính năng này tương tác với các tính năng/hệ thống khác như thế nào?

How will we gain money from this product? Chúng ta có thể kiếm tiền từ sản phẩm này như thế nào?

How does the product contribute to society positively? Sản phẩm này đóng góp tích cực cho xã hội như thế nào?

How can we release the product on-time? Làm thế nào để chúng ta có thể bàn giao sản phẩm đúng tiến độ

Xem thêm các bài viết chia sẻ về kiến thức kiểm thử phần mềm tại đây

Bình luận

Bài viết tương tự

- vừa được xem lúc

Một số câu hỏi tình huống khi đi phỏng vấn Tester

1. Expected(kết quả mong đợi) trong testcases dựa vào đâu. . Dựa vào SRS: Software Requirement specification Document(tài liệu đặc tả).

0 0 827

- vừa được xem lúc

Leverage Quality Software Testing Services in USA

Testrig Technologies providers Worldwide Software Testing services for small to large size startups and organizations. Since 2015, Team Testrig has specialized in offering End to End QA and Software Testing services including Well-optimized QA Techniques, Use of the latest automation tools and techn

0 0 42

- vừa được xem lúc

Hiểu biết của bạn về Software Testing? Mock Test và lý giải chi tiết

Cùng kiểm tra hiểu biết của bạn về Software Testing qua Mock Test dưới đây. Q #1) Verification is:. a. Checking that we are building the right system.

0 0 59

- vừa được xem lúc

Tìm hiểu về SDLC – Software Development Life Cycle

Một trong những kiến thức cần thiết của một kỹ sư kiểm thử phần mềm chuyên nghiệp đó là hiểu biết và nắm rõ SDLC (Software Development Life-cycle/chu kỳ phát triển phần mềm), bởi vì kiểm thử phần mềm

0 0 60

- vừa được xem lúc

Quy trình kiểm thử phần mềm - Software testing life cycle( STLC)

1. Định nghĩa quy trình kiểm thử phần mềm.

0 0 97

- vừa được xem lúc

System Testing - Kiểm thử hệ thống

Trong kiểm thử phần mềm, người kiểm thử thực hiện nhiều cấp độ kiểm thử khác nhau. Từ unit testing đến acceptance testing, đảm bảo rằng tất cả các thành phần của sản phẩm được kiểm tra kỹ lưỡng, không

0 0 60