Tóm Tắt

Tầm quan trọng của việc xây dựng Test Plan (Part 1)

Xin chào các bạn,

Như mọi người đã biết, để đưa một dự án cán đích release thành công là kết quả lao động của cả một tập thể bao gồm thuyền trưởng là PM (Người đứng đầu sóng ngọn gió ý ^^) và toàn bộ các thành viên từ BrSE, Comtor, Developer, Tester… Với vai trò là 1 tester “nhỏ bé” trong dự án, để làm tốt công việc của mình cũng như là kết hợp được với các bộ phận khác trong dự án thì làm việc theo kế hoạch luôn là ưu tiên hàng đầu của mình vì dự án hay bị dí sát deadline lắm. Việc đưa ra một kế hoạch làm việc khi bắt đầu tới kết thúc dự án và trong suốt dự án mình theo sát được các công việc đã đề ra trong kế hoạch đó sẽ giúp mình làm việc có hiệu quả hơn và cũng là giúp mình có thể ứng phó kịp thời với những rủi ro xảy ra khi chạy dự án. Và vũ khí bí mật ấy chính là Test plan – Thuật ngữ không hề xa lạ với chúng ta, nhưng làm sao để xây dựng được một test plan hiệu quả thì mời các bạn cùng đi tìm hiểu với mình nhé:

Đầu tiên thì Test plan là một tài liệu mô tả chi tiết chiến lược test, mục tiêu (objective), lịch trình (schedule) , ước tính (estimation), các sản phẩm phân phối (deliverables) và nguồn lực cần thiết (resources required) để thực hiện kiểm thử cho một sản phẩm phần mềm.

Test plan giúp cho chúng ta xác định được effort cần để kiểm tra chất lượng của ứng dụng muốn kiểm tra.

Test plan đóng vai trò như một bản thiết kế để tiến hành các kế hoạch kiểm thử phần mềm như một quy trình đã được xác định, giám sát và kiểm soát một cách chi tiết bởi Test lead.

ISTQB định nghĩa Test plan như sau: “Test Plan is A document describing the scope, approach, resources, and schedule of intended test activities.” – “Test plan là một tài liệu mô tả phạm vi, cách tiếp cận nguồn lực, lịch trình của các hoạt động test dự kiến”

Ví dụ: Trong cuộc họp nhóm QA, anh Hoàng muốn thảo luận về Test Plan với mọi người trong nhóm nhưng lại không ai care. Nếu bạn là a Hoàng trong tình huống này, bạn sẽ làm gì? Chọn câu trả lời của bạn trong 2 đáp án dưới đây nhé!

Tầm quan trọng của Test Plan

Giúp những người nằm ngoài nhóm Test như developers, business managers, customers hiểu chi tiết về kiểm thử
Test Plan dẫn dắt suy nghĩ của chúng ta. Nó giống như một cuốn sách quy tắc cần được tuân theo
Các khía cạnh quan trọng như Test estimation, Test scope, Test Strategy được ghi lại trong Test Plan, do đó, Management team có thể xem xét và tái sử dụng cho các dự án về sau.

Cách viết một Test Plan hiệu quả

Lập Test plan là nhiệm vụ quan trọng nhất của Quy trình quản lý Test (Test Management Process). Làm theo 7 bước dưới đây để có thể tạo một Test Plan theo IEEE 829 (một tiêu chuẩn thử nghiệm phần mềm bởi IEEE)

Analyze the product – Phân tích sản phẩm
Design the Test Strategy – Thiết kế chiến lược Test
Define the Test Objectives – Xác định mục tiêu Test
Define Test Criteria – Xác định tiêu chí Test
Resource Planning – Hoạch định nguồn lực
Plan Test Environment – Lên kế hoạch môi trường Test
Schedule & Estimation – Lên lịch & ước tính
Determine Test Deliverables – Xác định phân phối Test

Bước 1: Analyze the product

Làm thế nào để có thể test một dự án mà không có bất kỳ thông tin nào về nó? Câu trả lời là không thể. Bạn cần phải tìm hiểu kỹ một dự án trước khi test.

Dự án đang được test là trang Web ngân hàng. Bạn nên nghiên cứu khách hàng và người dùng cuối để biết nhu cầu và mong đợi của họ từ ứng dụng.

Ai sẽ sử dụng trang Web này?

Trang Web này được dùng để làm gì?

Nó làm hoạt động như thế nào?

Phần mềm/phần cứng sẽ sử dụng?

Bạn có thể sử dụng cách tiếp cận sau để phân tích trang Web

Bước 2 : Develop Test Strategy

Test Strategy là một bước quan trọng trong việc lập Test Plan trong kiểm thử phần mềm. Tài liệu Test Strategy là một tài liệu cấp cao, thường được phát triển bởi Test Manager. Tài liệu này định nghĩa:

Các đối tượng Test của dự án và phương tiện để đạt được chúng

Xác định effort và costs

2.1 Define Scope of Testing

Trước khi bắt đầu bất ký hoạt động Test nào, chúng ta cần phải biết được phạm vi Test. Bạn cần phải suy nghĩ kỹ về nó.

Các phần của hệ thống được test (phần cứng, phần mềm, phần mềm trung gian,..v..v..) được xác định là “in scope” – trong phạm vi.

Các phần của hệ thống sẽ không được test cũng cần phải được xác định rõ ràng, chúng được gọi là “out of scope” – ngoài phạm vi.

Xác định Scope (phạm vi) của dự án bạn Test là rất quan trọng với tất cả các bên liên quan. Một Scope chính xác sẽ giúp bạn:

Cung cấp cho mọi người sự tự tin và thông tin chính xác về thử nghiệm bạn đang thực hiện.

Tất cả các thành viên dự án sẽ hiểu rõ ràng về những gì sẽ được kiểm tra, những gì sẽ không được kiểm tra.

Làm thế nào để xác định được Scope dự án của bạn?

Để xác định Scope, bạn phải:

Tóm lược được chính xác yêu cầu của khách hàng

Ngân sách dự án

Đặc điểm kỹ thuật của sản phẩm

Kỹ năng và tài năng của nhóm test

Tình huống sự cố

Khách hàng muốn bạn kiểm tra API của họ. Nhưng ngân sách dự án lại không cho phép làm như vậy. Trong trường hợp này bạn sẽ làm gì?

Trong trường hợp đó, bạn cần thuyết phục khách hàng rằng kiểm tra API là công việc bổ sung và sẽ tiêu tốn nhiều tài nguyên. Cung cấp chọ họ dữ liệu hỗ trợ làm bằng chứng. hãy cho họ biết nếu Test API được bao gồm trong Scope, ngân sách sẽ tăng thêm XYZ.

Khách hàng đồng ý và theo đó các Scope mới, các mục Out of Scope sẽ là:

In-scope items: Functional Testing, Api Testing

Out of scope items: Database Testing, hardware & bất kỳ giao diện bên ngoài nào khác

2.2 Identify Testing Type

Testing Type là một quy trình test tiêu chuẩn mang lại kết quả test mong đơi.

Mỗi loại Testing Type được xây dựng để xác định một loại lỗi sản phẩm cụ thể. Tuy nhiên, tất cả các Test Type đều nhằm đạt được một mục tiêu chung là “Phát hiện sớm tất cả các Defects trước khi đưa sản phẩm đến tay khách hàng”

Các Test Type thường được sử dụng được mô tả như hình dưới đây:

Các Test Type thường dùng

Có rất nhiều Test Type để test sản phẩm phần mềm. Nhóm của bạn không thể có đủ lực để áp dụng tất cả các Test Type. Với tư cách là Test Manager, bạn phải đặt mức độ ưu tiên cho Test Type.

Test Type nào nên được tập trung cho test ứng dụng web?

Nên bỏ qua Test Type nào để tiết kiệm chi phí?

2.3: Document Risk & Issues

Risk (rủi ro) là sự kiện không chắc chắn trong tương lai với xác suất xảy ra và khả năng mất mát. Khi rủi ro thực sự xảy ra, nó sẽ trở thành “issue” – “vấn đề”

Trong QA Test Plan, bạn sẽ ghi lại những rủi ro đó.

Risk

Mitigation

Thành viên trong nhóm thiếu các kỹ năng cần thiết để Test Web

Lên kế hoạch cho khóa đào tạo để nâng cao kỹ năng cho các thành viên

Tiến độ dự án quá chặt chẽ, thật khó để hoàn thành dự án này đúng hạn

Đặt mức độ ưu tiên Test cho từng hoạt động test

Test Manager có kỹ năng quản lý kém

Lập kế hoạch đào tạo Leader cho người quản lý

Sự thiếu hợp tác ảnh hưởng tiêu cực đến năng suất của nhân viên

Khuyến khích mỗi thành viên trong nhóm, truyền cảm hứng cho họ để họ có động lực cố gắng và nỗ lực hơn nữa

Dự toán ngân sách sai, chi phí vượt quá

Thiết lập phạm vi trước khi bắt đầu công việc, chú ý nhiều đến việc lập kế hoạch dự án và liên tục theo dõi, đo lường tiến độ

2.4 Create Test Logistics

Trong Test Logistics, Test Manager phải trả lời các câu hỏi sau:

Ai sẽ test?

Khi nào thì test?

Ai sẽ test?

Bạn có thể không biết tên chính xác của Tester, nhưng type of tester thì có thể được xác định.

Để chọn tester phù hợp cho nhiệm vụ cụ thể, bạn cần xem xét kỹ năng của người đó có đủ tiêu chuẩn cho nhiệm vụ đó hay không, đồng thời ước tính ngân sách dự án. Việc chọn sai thành viên cho nhiệm vụ có thể khiến dự án thất bại hoặc chậm trễ.

Người có những kỹ năng sau là lý tưởng nhất để thực hiện Software testing:

Khả năng hiểu quan điểm của khách hàng

Mong muốn mạnh mẽ về chất lượng

Chú ý đến chi tiết

Hợp tác tốt

Trong dự án của bạn, thành viên sẽ chịu trách nhiệm thực hiện test là tester. Dựa trên ngân sách dự án, bạn có thể chọn thành viên trong nguồn – in source hoặc thuê ngoài – outsource làm tester.

Khi nào thì test?

Các hoạt động test phải phù hợp với các hoạt động dev

Bạn sẽ bắt đầu test khi bạn có tất cả các mục cần thiết được hiển thị trong hình sau

Bước 3: Define Test Objective

Test Objective (mục tiêu kiểm tra) là mục tiêu tổng thể và kết quả hướng tới của việc thực hiện test. Mục tiêu của test là tìm ra càng nhiều lỗi phần mềm càng tốt, đảm bảo rằng phần mềm đang được kiểm tra không có lỗi (bug free) trước khi phát hành.

Để xác định Test Objective, bạn nên thực hiện 2 bước sau:

1. Liệt kê tất cả các tính năng phần mềm (FN, performance, GUI…) có thể cần test

2. Xác định mục tiêu hoặc mục tiêu của bài test dựa trên các tính năng trên

(còn nữa)

Nguồn bài viết: https://www.guru99.com/what-everybody-ought-to-know-about-test-planing.html

Nguyen Anh Phuong

Among with QuynhNT

Recommended for you

QA/QC

Buổi 3: Cách xác định Locators của elements trên website

mysql

(SQL Injection)