Đơn giản hóa test plan bằng 5W2H

Đơn giản hóa test plan bằng 5W2H

Test plan rất quan trọng trong việc truyền tải các dự định và yêu cầu cho công việc test, nhưng quá nhiều tài liệu và chi tiết thừa mứa thì tạo ra sự khó hiểu - mọi người sẽ bỏ qua. Bài viết này giới thiệu phương thức 5W2H. Cái tên này tới từ 7 câu hỏi : why, what, where, when, who, how, and how much. Bảy câu hỏi này là đủ cho bạn có thể đưa ra các phản hồi giá trị và phát triển lên 1 phương án hành động tuyệt vời. Tài liệu test plan và các tài liệu liên quan ở các công ty khác nhau là khác nhau. Mức độ thông tin được cụ thể hóa khá là khác biệt từ viết lên bảng trắng đến từng bước có trong test case và test scenario. Đội phát triển sử dụng mô hình agile thường không có 1 hệ thống tài liệu nghiêm ngặt, nhưng 1 số công ty lại yêu cầu sử dụng 1 số template nhất định hoặc phải theo các tiêu chuẩn xác định nào đó.
KInh nghiệm của tôi trong việc tạo test plan và đánh giá kết quả là các bên liên quan không có thời gian để đọc hết được test plan một cách kĩ càng. Việc này gây nên scopte testing sẽ giảm xuống, tạo sự nhầm lẫn, thoái chí với các nhân viên kiểm thử, dẫn tới việc giảm thiểu chất lượng của việc kiểm thử và dẫn tới lãng phí tiền bạc và thời gian. Đây là lí do tại sao cần thiết tạo ra một test plan ngắn gọn, hiệu quả, đi ngay vào vấn đề là cần thiết cho một chu trình test trong dự án phần mềm.

Đánh giá những thứ bạn có thể bỏ đi

Tiêu chuẩn IEEE 829 định nghĩa 16 danh mục có thể được cho vào trong file test plan, tester kì cựu Peter Morgan đã nghĩ ra 1 từ viết tắt dễ nhớ SPACEDIRT: scope (vùng test), people (con người) , approach (cách tiếp cận), criteria (tiêu chí), environment (môi trường), deliverables (các biến số), incidentals (chi phí phát sinh) , risks (rủi ro), and tasks (các nhiệm vụ). Mặc dù danh sách này khá đầy đủ và dễ nhớ, thì 1 số nhân tố là bất biến qua nhiều tháng, nếu không muốn nói là qua nhiều năm, nên nếu bạn muốn giảm bớt tài liệu của bạn thì bạn chắc không cần cho hết các item trên vào mọi test plan và mọi dự án mà bạn tham gia. Ví dụ, trong dự án sử dụng agile (phát triển liên tục), ngưỡng đầu vào lúc nào cũng giống nhau cả: kiểm thử các chức năng đã sẵn sàng để kiểm thử, trong khi test hồi quy các chức năng cũ. Hơn nữa, ngưỡng đầu ra thường được xác định bởi scrum team, trong đó có tính tới công sức phát triển, các thay đổi của phần mềm, thời gian và nhân sự có sẵn. Các sản phầm cũng phải được xem xét, thường thì khi giao các sản phẩm cho khách thì đều sử dụng report như nhau, tài liệu như nhau và các kênh như nhau, nên không có lí gì mà phải copy paste các thông tin này lần này tới lần khác. Rủi ro không thay đổi từ sprint này tới sprint khác, các kế hoạch giảm thiểu hoặc dự phòng cũng vậy.
Nhiệm vụ test như tạo test case thì ở cấp độ quá thấp để có thể cho vào test plan, nên chúng có thể được link ở trong test plan và được review riêng rẽ ra, vì người khác sẽ xem chúng. Bởi vậy, chúng tôi có 1 kĩ thuật nhớ khác dành cho bạn. Đó là kĩ thuật 5W2H.

Kĩ thuật 5W2H   giúp bạn tạo kế hoạch thực hiên cho 1 vấn đề cụ thể. Ý nghĩa của kĩ thuật này là 7 câu hỏi mà bạn sẽ hỏi trong khi đi theo hướng tiếp cận của bạn: why, what, where, when, who, how, and how much. Trả lời các câu hỏi này có thể giúp bạn giải quyết bất kì dự án nào bằng cách đưa ra các chiến thuật và đưa ra đầy đủ dữ liệu cho 1 test plan. Hãy nhìn vào mỗi câu hỏi và trả lời khi lập 1 test plan.

Why?

Bắt đầu với câu hỏi Why, tại sao, để đưa ra mục tiêu của dự án và hoàn thiện đầy đủ requirement dự án. Câu trả lời Start with this question to specify the goal of the project and the set of requirements. Câu trả lời sẽ là biện chứng cho việc kiểm thử, từ mục tiêu của sprint cho tới phạm vi test của toàn dự án. Ví dụ: Mục tiêu của sprint này là để làm ổn định toàn bộ hệ thống. Chúng ta cần giải quyết 5 vấn đề mấu chốt, hạn cuối là ngày cuối của sprint.

What?

Sẽ test cái gì? Đưa ra các chức năng cần thiết để test, liệt kê chỗ nào cần phải test hồi quy. Đưa ra mô tả chính xác về phạm vi test, bao gồm cái gì không cần phải test, cái gì cần test. Ví dụ: Requirements X01 cho tới X09 sẽ được test bằng kiểm thử chức năng (function testing), các requirement khác sẽ cần performance test

Where?

Test cần được thực hiện ở đâu. Chỉ định ra 1 môi trường test và các dữ liệu có liên quan, ví dụ url hay việc truy cập. Đối với các team phân tán, bạn còn có thể chỉ định phòng, link chat, hay địa chỉ thành phố nữa. Ví dụ: Khi test thì phải dùng môi trường staging. Link dẫn tới môi trường staging là….

When?

Khi nào bạn bắt đầu test? Đưa ra thời gian cụ thể, ngày giờ, deadline. Cũng cần phải đưa ra thời gian OT là khi nào để mọi người còn có thể sắp xếp nữa. Ví dụ: Thời gian bắt đầu test là từ 25/7 và sẽ kết thúc cho tới cuối ngày 13/8. Có 1 ngày nghỉ là 1/8 ở giữa, vậy vi chi là có 13 ngày để test.

Who?

Ai sẽ kiểm thử? Đưa ra danh sách số người trong test team, cùng với phạm vi test bên cạnh, miêu tả ai có nhiệm vụ làm cái gì. Ngoài ra thêm vào các lịch làm việc đặc biệt nếu cần. Đây là 1 công cụ trực quan cho những ai liên quan tới testing 1 phần hay cần phải nhận thức được lịch test, môi trường test... Ví dụ: Test hồi quy sẽ được Nguyễn Văn Nam test, đây là mức ưu tiên số 1 khi test.

How?

Bạn sẽ test như thế nào? Phải đưa ra cách thức test cụ thể và qui trình cụ thể. Nhấn mạnh việc automation có cần thiết hay không? Liên kết các tài liệu về cách thức test riêng biệt và các test script với nhau. Đưa ra cụ thể các công việc cần test, liệt kê theo ngày và theo thứ tự ưu tiên nếu có thể. Đánh giá và ước tính mức độ bao phủ của việc kiểm thử. Ví dụ: Requirement X01 sẽ được test sử dụng automation test. Ngày test bắt đầu từ 29/7 bởi Nguyễn Thị B.

How much?

Có chi phí phát sinh gì đặc biệt không? Ví dụ, nếu có 1 phần cứng chả hạn như tablet, 1 máy trạm, hay chi phí đặc biệt nào đó, thì nó nên được cho vào đây. How much còn có thể được hiểu là task đó được thực hiện ở mức độ thường xuyên là như thế nào? nên hãy đưa ra kế hoạch kĩ càng nếu cần test hơn 1 vòng. Nếu đội của bạn đang tìm kiếm cách để tối giản hóa tài liệu test plan, thì tôi khuyên hãy theo 5W2H. Trả lời 7 câu hỏi này thật sự không tốn nhiều thời gian, nhưng vẫn cung cấp nhiều phản hồi có giá trị và giúp bạn phát triển 1 kế hoạch quản lý dự án hiệu quả.