HomeOur Team
TEST PLAN - What is, How to Create?
Testing
TEST PLAN - What is, How to Create?
giang.ha
giang.ha
October 28, 2020
6 min

TEST PLAN - Chuyện không chỉ riêng ai!

Hello, xin chào 500 anh em ^^. Nhân dịp tuần vừa rồi có bạn hỏi kinh nghiệm để viết test plan, nên hôm nay mình xin phép được viết đôi dòng chia sẻ, hi vọng sẽ nhận được đóng góp của mọi người. Trong bài viết mình xin giữ nguyên một số từ keyword tiếng anh vì mình chả biết dịch ra tiếng việt nó là gì.

OK, bắt đầu nha!!!

1. Test plan là gì?

Sương sương thì bạn chỉ cần search trên Google cũng ra vô số định nghĩa về test plan, mình chỉ nêu lại vài ý như sau:

  • Test plan là một tài liệu chi tiết mô tả toàn bộ chiến lược kiểm thử (test strategy), mục tiêu (objectives), kế hoạch chi tiết, các ước tính cả về mặt thời gian, nguồn lực, và các tài liệu cần deliver trong quá trình test, xin lỗi mọi người không biết phải diễn tả từ deliver ở đây như nào, nó chính là output đầu ra của test (test result, test report, test signoff).
  • Test plan giúp chúng ta xác định toàn bộ những yêu cầu cần thiết để đảm bảo chất lượng của ứng dụng đang thử nghiệm. Test plan có vai trò như một kế hoạch chi tiết để tiến hành các hoạt động kiểm thử phần mềm như một quy trình xác định, được giám sát và kiểm soát từng bước bởi test member/test lead.

2. Tầm quan trọng của test plan

Ok, giờ chúng ta thử tưởng tượng mình đang là test lead đi, mình cần phải thảo luận với cả team kiểm thử về test plan mà thực chất thì chả ai muốn nghe cả :))) Thế thì bạn phải làm thế nào? Bạn sẽ nói kiểu: “Ok, tôi là manager, tôi nói như này thì tất cả mọi người phải nghe theo lời tôi bla bla…“? Cách nói này make no sense bởi vì toàn bộ thành viên trong team bạn không thấy cái tài liệu ấy có ý nghĩa gì cả, việc quái gì phải follow theo. Tôi đây cứ test đã, test cái gì là việc của tôi,… Thay vào đó, nếu bạn có thể cho mọi người thấy được tầm quan trọng của Test Plan, nó sẽ là xương sống, là kim chỉ nam cho toàn bộ quá trình kiểm thử của team bạn.

Vậy test plan quan trọng như thế nào:

  • Giúp tất cả thành viên trong dự án, không chỉ đội kiểm thử hiểu chi tiết về cách test cũng như hiểu phạm vi kiểm thử. Test Plan cũng là một trong những tài liệu chứng minh cho chất lượng kiểm thử phần mềm của bên B trong quá trình thực hiện dự án. Một test plan tốt thậm chí còn có thể được khách hàng dùng làm reference trong quá trình tiến hành UAT, đấy là một trong những lợi thế trong quá trình triển khai.
  • Test Plan giúp cho mọi người trong team cùng nhìn về một hướng, từ chiến lược cho tới cách thực hiện. Nó giống như một bộ quy tắc, cần phải được tuân theo. Điều đó tạo nên tính đồng bộ trong quá trình kiểm thử, giúp test lead hay PM có thể dễ dàng kiểm soát được tiến độ kiểm thử hay xử lý sự cố khi có vấn đề xảy ra.
  • Các khía cạnh quan trọng khác trong test plan như estimation, test scope, test strategy được ghi lại, do đó, team lead/PM/công ty có thể xem xét và sử dụng lại cho các dự án khác.

Tóm cái, trong quá trình làm việc nhóm, chỉ khi mọi người nhìn chung một đường, chúng ta mới có thể kéo nhau đi nhanh được. Chứ mỗi người đi một nhánh đến lúc tụ nhau lại mà để làm report có khi còn cãi nhau to.

3. Làm thế nào để tạo được test plan hiệu quả?

Giờ mọi người đã hiểu được tầm quan trọng của nó rồi thì chúng ta đi vào bước thực hiện đó là làm thế nào để tạo test plan.Nếu bạn đã học qua về kiểm thử phần mềm thì bạn đã biết rằng lập Test Plan là nhiệm vụ quan trọng nhất của Test Management Process. Chúng ta sẽ thực hiện theo bảy bước dưới đây để tạo một test plan theo IEEE 829. ( IEEE 829 là gì thì wiki đây: https://en.wikipedia.org/wiki/Software_test_documentation Đây là một bộ chuẩn standard cho các tài liệu kiểm thử phần mềm, đại khái thế :)))) )

  1. Analyze the product
  2. Design the Test Strategy
  3. Define the Test Objectives
  4. Define Test Criteria
  5. Resource Planning
  6. Plan Test Environment
  7. Schedule & Estimation
  8. Determine Test Deliverables

Giờ mình đi vào từng bước xem là cần làm gì nào ^^:

Bước 1: Analyze the product - Nghiên cứu sản phẩm.

Khi test một sản phẩm nào đó thì bạn phải hiểu rõ về nó, phải biết nó là cái gì đã, có cấu tạo thành phần như nào, vân vân và mây mây các thông tin về sản phẩm. Không hiểu sản phẩm thì test làm sao được. Đây là một trong những bước research đầu tiên rất quan trọng.

Đối với mỗi sản phẩm phần mềm ít nhất bạn cần hiểu:

+ Sản phẩm này cho ai sử dụng (actor)? Các chức năng chính của sản phẩm này là gì? Quy trình nghiệp vụ xử lý như nào?
+ Về mặt kĩ thuật cần nắm được kiến trúc tổng thể của sản phẩm, vị trí của sản phẩm này trong tổng quan kiến trúc của cả một hệ thống lớn. VD như bên bank chẳng hạn, sản phẩm hệ thống quản trị thẻ nó nằm trong tổng quan kiến trúc hệ thống thông tin của bank (có thể kể ra như core banking, report, switch, terminal,...)
+ Các vấn đề cần lưu ý về front-end, back-end...

Một số tip bạn có thể dùng khi nghiên cứu sản phẩm:

+ Hỏi người làm ra sản phẩm ý - chính là BA(Business Analysis), đội dev, đội designer (nếu bạn test front-end), ...
+ Nghiên cứu tài liệu thiết kế hệ thống.
+ Thử dùng qua vài tính năng của sản phẩm như end-user để xem nó như nào

Đó phải hiểu được hệ thống đã rồi ta mới chuyển sang bước tiếp theo.

Bước 2 : Design the test strategy - Xây dựng chiến lược kiểm thử.

Ông cha ta có câu: “Biết người biết ta, trăm trận trăm thắng” Bắt đầu vào giai đoạn kiểm thử cũng như đánh trận vậy, đánh lung tung là vỡ trận, vỡ dự án ngay. Vì vậy, vạch ra chiến lược kiểm thử đúng đắn là điều tối quan trọng, thường là Test Lead (với dự án nhỏ có thể là PM- Project Manager) sẽ phải vạch ra được cho mọi người vấn đề này.

Chiến lược kiểm thử phải chỉ rõ ra được:

+ Đối tượng cần kiểm thử, nội dung cần kiểm thử, output mong muốn sau cả quá trình kiểm thử cho đối tượng đó.
+ Xác định rõ chi phí (cost) và effort (tiếng việt thì là nỗ lực nhưng như mình thường làm thì nó gần như độ khó để thực hiện)

Thế thì để xây được chiến lược kiểm thử, ta cần làm:

  1. Xác định Test Scope
    
  2. Xác định cách tiến hành kiểm thử (UnitTest/API/System Test,...)
    
  3. Xác định các rủi ro và các vấn đề có thể gặp phải trong quá trình kiểm thử
    
  4. Chi tiết quá trình kiểm thử (Ai test? Test cái gì? Test như nào)
    
    Để đi vào chi tiết từng bước trên thì dài lắm, anh em google search nhé, không thì bài sau mình sẽ viết thêm.

Bước 3 : Defind Test Objective - Các vấn đề cần phải test.

Để xác định các mục tiêu cần kiểm tra :

  1. Liệt kê tất cả các tính năng phần mềm (UI, Hardware, functionality, performance, security,...) có thể cần kiểm tra.
    
  2. Xác định mục tiêu dựa trên các tính năng trên.
    
    Đấy chỉ cần xác định rõ các mục tiêu, tính năng thì sẽ không có vấn đề khó khăn nào có thể cản trở bạn và còn tuỳ dự án mà mình sẽ xác định cụ thể nữa ra nhé.

Bước 4 : Define test criteria - Xác định các tiêu chí kiểm thử.

Đến đây thì dễ rồi, thế nào là đạt, thế nào là không đạt? Khi nào thì cần kiểm tra lại, khi nào cần thực hiện regression lại. Tiêu chí kiểm tra là một tiêu chuẩn hoặc quy tắc dựa vào đó một quy trình kiểm tra hoặc đánh giá kiểm tra. Có 2 loại tiêu chí kiểm tra như sau:

+ Suspension Criteria: 
Example: Nếu các thành viên trong nhóm của bạn báo cáo rằng có 40% trường hợp thử nghiệm không thành công, bạn nên tạm dừng thử nghiệm cho đến khi nhóm phát triển khắc phục tất cả các trường hợp không thành công.
+ Exit Criteria: Nó chỉ định các tiêu chí biểu hiện sử hoàn thành thành công của một giai đoạn kiểm thử.
Example: 95% tất cả các trường hợp kiểm tra quan trọng phải vượt qua

Bước 5 : Resource Planning - Hoạch định nguồn lực.

Đến đây là bài toán con người/thiết bị rồi, dự án thì có deadline nhưng con người thì chỉ có hạn. Cái này thường là Test Lead/PM phải làm, đưa ra các đánh giá về năng lực của các thành viên liệu có đáp ứng đủ tiến độ hay không? Có cần thêm người không? Nếu thêm thì là lấy nhân sự khác trong công ty hay thuê thêm outsource hay tuyển hẳn thêm người mới bla bla… Đấy mới là bên test, còn bên hỗ trợ hệ thống, các dự án khác cần hỗ trợ của nhiều bên, thậm chí là cả hỗ trợ của khách hàng thì cũng cần được xác định rõ trong bước này. Rồi nào thì cả thiết bị cần thiết trong quá trình test cũng nằm ở đây. Nhiều lắm, vẽ nữa thì tùy dự án.

Bước 6 : Test Enviroment - Môi trường test.

Dự án bên nào không rõ chứ dự án bên bank dựng môi trường test phải chuẩn bị cả tháng, công văn các kiểu, xin mở port kết nối đến các hệ thống các kiểu. Về nội tại thì phải estimate được thời gian cái ông Tech Consultant ông ý dựng được môi trường test lên và đảm bảo thông kết nối đến các hệ thống xung quanh. Nói chung là dự án mới thì bước này rất mất thời gian.

Bước 7 : Schedule and Estimation _ Lên kế hoạch và các ước tính.

Đấy, toàn bộ thông tin thì phân tích bên trên rồi, đưa ra kế hoạch và dự tính để đảm bảo thời gian test đúng tiến độ dự án thôi. Lên kế hoạch thì dùng excel hay gantt cũng được.

Bước 8 : Test deliverables.

Bước này xác định toàn bộ các tài liệu cần đưa ra trước/trong/sau khi test thôi.

  1. Before testing:
+ Test plans document.
+ Test cases documents
+ Test Design specifications.
  1. During testing:
+ Test Scripts
+ Simulators.
+ Test Data
+ Test Traceability Matrix
+ Error logs and execution logs.
  1. After the testing:
+ Test Results/reports
+ Defect Report
+ Installation/ Test procedures guidelines
+ Release notes

Tất cả những thông tin trên đóng gói lại sẽ thành 1 document tên là Test Plan.Lý thuyết là thế ^^. Chúc anh chị em áp dụng thành công! Link tham khảo chi tiết cho ace: https://www.guru99.com/what-everybody-ought-to-know-about


Tags

#testplan#testing#102020
giang.ha

giang.ha

Tester / iOS Developer

Expertise

tester
ios

Related Posts

Học cách học
Softskills
Học cách học
October 30, 2020
6 min
Android Studio 4.1 có gì mới?
News
Android Studio 4.1 có gì mới?
October 29, 2020
3 min
Sign In with Apple - Backend (Java)
Solutions
Sign In with Apple - Backend (Java)
October 29, 2020
3 min
Android Studio - Một số tips, tricks
Tips / Tricks
Android Studio - Một số tips, tricks
October 27, 2020
2 min
© 2021, All Rights Reserved.

Quick Links

HomeOur Team

Social Media