Quy trình kiểm thử là xương sống của cả quá trình test. Không phải để biến tester thành cái máy điền form, mà để cả team biết đang test dựa trên cái gì, đã cover tới đâu, còn risk nào và lúc nào cần đổi kế hoạch.
Test process nằm bên trong SDLC, nhưng các hoạt động của nó không xếp thành hàng một đi không trở lại. Analysis có thể làm lộ requirement thiếu rồi kéo planning thay đổi; execution tìm thấy risk mới thì team quay lại design thêm case. Monitoring và control chạy xuyên suốt chứ không ngồi chờ tới lượt.
Khái niệm
Test process là tập hợp hoạt động để planning, monitoring, analysis, design, implementation, execution và completion việc test. Tùy dự án, một người làm vài hoạt động hoặc cả team chia nhau làm.
Hiểu nôm na như vậy, và các bước cụ thể trong quy trình kiểm thử sẽ bao gồm:
| Hoạt động | Câu hỏi chính |
|---|---|
| Test Planning | Test cái gì, bằng cách nào, với người và thời gian nào? |
| Test Monitoring & Control | Thực tế đang lệch kế hoạch ở đâu và cần điều chỉnh gì? |
| Test Analysis | Có những test condition và risk nào cần kiểm tra? |
| Test Design | Cần test case, test data và coverage item nào? |
| Test Implementation | Tổ chức test procedure, suite, script, data và môi trường ra sao? |
| Test Execution | Actual result là gì, có failure nào và cần log thông tin gì? |
| Test Completion | Kết quả, work product và bài học nào cần tổng kết hoặc bàn giao? |
Tên gọi nghe như bảy ga tàu, nhưng thực tế chúng lặp và chồng lên nhau. Test process cũng không phải chuyện nội bộ riêng của tester: dev, BA, Product Owner và người vận hành đều tạo input hoặc dùng output từ nó.
Typical question: What is test process? - Quy trình kiểm thử là gì?
Typical question: What are the steps in the test process? - Các bước trong quy trình kiểm thử là gì?
Test process in a sprint
Đầu tiên, nếu bạn đã quên một sprint của Agile Scrum trông thế nào, có thể quay về Agile để đọc. Mình sẽ nêu lại một chút và cũng lồng ghép luôn quy trình kiểm thử
Planning phase
Planning Phase của sprint: Trong khâu lên kế hoạch, sẽ bao gồm việc quyết định khối lượng công việc và thời gian, nôm na là kế hoạch của sprint, vậy thì kế hoạch kiểm thử cũng sẽ được lên cùng lúc với project plan, hay ít nhất là trong khuôn khổ của planning phase.
Test Plan sẽ lấy vào Project Plan, Requirements và Acceptance Criteria, cấu trúc thì bạn có thể lội về bài viết Test Plan
Daily Scrum
Sau planning phase, bắt tay vào việc và các Daily Scrum sẽ diễn ra Test Monitor & Control cho tới Test Execution
Test Monitor & Control:
Đây thật ra là một bước cần thực hiện, nhưng vòng đời của nó không đi theo thứ tự cùng các bước khác, tức là không phải kết thúc rồi dẫn tới Test Analysis, mà nó là một hoạt động kéo dài, được triển khai từ sau Test Planning cho tới khi kết thúc quy trình kiểm thử
Lấy vào:
- Test Plan
- Kết quả đánh giá (reviews) và kiểm thử
- Exit Criteria (tạo ra trong Test Plan)
Trả ra:
- Báo cáo theo dõi, và có thể hoạt động chỉnh đốn các sai lệch khỏi quy trình kiểm thử ban đầu
Test Analysis
Đây là giai đoạn mà tester sẽ bắt đầu chính thức bước vào nghiên cứu các yêu cầu và đưa ra các câu hỏi để làm rõ các yêu cầu như đã nêu trong Clarify a requirement.
Test Analysis có thể bắt đầu rất sớm, ngay khi có test basis đủ để đọc. Test Monitoring & Control chạy song song để nhìn tiến độ và điều chỉnh; nó không phải cái cổng cấp phép cho tester kết thúc việc làm rõ requirement.
Lấy vào:
- SRS - Software Requirement Specification: Một doc được thường được viết bởi BA, tên tiếng việt của nó là tài liệu đặc tả, vì nhiều khi sản phẩm không phải là phần mềm, nên để "Software" ở đầu cũng chưa chuẩn lắm
- Detailed Design: Bản thiết kế sản phẩm phần mềm, là một doc viết về thiết kế của sản phẩm ở mức độ tổng quan (High Level Detailed Design) và mức độ chi tiết (Low Level Detailed Design), làm Dev thì sẽ rõ về thể loại doc này hơn
- Prototype (hoặc Mockup hoặc Sketch): Về cơ bản thì các BA đọc đến đây đã quá quen rồi, câu chuyện muôn thuở dùng Figma để vẽ Mockup. Mục này thật ra có thể là:
- Prototype : phiên bản có khả năng tương tác nhưng không có tính năng thực nào của sản phẩm, tức là ví dụ như tính năng thống kê chi tiêu của ứng dụng ngân hàng, khi làm prototype thì sẽ chỉ cần làm các màn hình code cứng chứ không cần phải cài đặt database, kéo data ra, thực hiện tính toán gì cả
- Mockup: Bản vẽ sử dụng phần mềm chuyên dụng như Figma, tay to thì có thể làm mockup có hoạt ảnh, sẽ thông qua với khách hàng. Mockup chịu ảnh hưởng rất lớn của business rule vì thiết kế Mockup sẽ gắn liền với branding của khách hàng. Mockup cũng không có tính năng, mà chỉ đơn giản là các bản vẽ có hoạt ảnh mô phỏng.
- Sketch: vẽ tay, có thể dùng phần mềm chuyên dụng nhưng không mất quá nhiều công sức như Figma, kết quả cũng đơn giản hơn, chủ yếu để khách hàng thấy được hướng đi về frontend của team dự án là đúng với tầm nhìn của khách hàng
Trả ra: Test Condition: Hiểu đơn giản là một danh sách các thứ có thể test của sản phẩm, ví dụ, nếu sản phẩm có một màn hình đăng nhập, thì các mục có thể test sẽ bao gồm ô điền username, ô điền password, ô captcha, nút ấn đăng nhập, v.v... và test conditions sẽ là danh sách gồm 3 yếu tố : UI (hiển thị), State (trạng thái), Function (chức năng) của từng mục.
Test Design
Đây là giai đoạn thiết kế các bài test theo ngôn ngữ của các tester, nhưng cụ thể ở đây chúng ta sẽ thiết kế các test case, khi đã có các test case thì nhóm chúng nó lại thành các bài test (test suite), đồng thời có thể nhóm các test case thành các kịch bản test (test scenario) theo góc nhìn của người dùng (actor).
Thiết kế ở đây có nghĩa là tạo ra test case một cách tổng quan, không đi cụ thể vào cách thực hiện test case, mà chỉ nêu ra một hành động suy rộng (general action) và kết quả của hành động này. Đây gọi là High Level Test Case, ví dụ một test case cao tầng
User successfully logins using correct username and password combination | Người dùng đăng nhập thành công sử dụng bộ username và password đúng
Trên chính là một High Level Test Case, cách viết High Level Test Case mình sẽ hướng dẫn cụ thể trong bài Requirement Traceability Matrix. Trong quá trình thiết kế test case cao tầng, cần áp dụng các kỹ thuật thiết kế test case (Test Design Technique) mà mình sẽ nói qua và hướng dẫn trong bài này và Test Design Technique.
Lấy vào
- SRS - Software Requirement Specification
- Detailed Design
- Prototype (hoặc Mockup hoặc Sketch)
- Test Conditions
Trả ra:
- High Level Test Case
Test Implementation
Đây là bước tạo ra test case thấp tầng (Low Level Test Case) bằng cách ứng dụng testcase, đưa vào cho test case cao tầng các thông tin cụ thể về cách thực hiện test case, thực hiện ở đâu, với cái gì, v.v...
Một test case thấp tầng sẽ cần tuân theo một bản mẫu (template) nhất định để đảm bảo người trong team test sẽ dễ dàng đọc và hiểu test case của nhau. Viết test case thấp tầng thế nào thì bạn có thể đọc trong bài này Low Level Test Case.
Lấy vào
- SRS - Software Requirement Specification
- Detailed Design:
- Prototype (hoặc Mockup hoặc Sketch)
- High Level Test Case
Trả ra
- Low Level Test Case
Test Execution
Rất đơn giản đây là bước thực hiện các test case. Log bug và gửi về cho Dev để sửa, làm việc với dev để test lại bug, và cuối cùng là đảm bảo bug đã được fix. Test Execution sẽ được làm cho tới khi nào tất cả các test case đã được thực hiện, hoặc đến khi nào hết thời gian kiểm thử, đấy là nếu theo kế hoạch
Để đảm bảo các test case là đúng trước khi được thực hiện, các test case sẽ phải đi qua quá trình review
Lấy vào
- Low Level Test Case
- Hệ thống hoặc sản phẩm hoàn thiện để test (System)
- Test Execution Tool
Trả ra
- Bug Log
- Test Report
Test Completion
Ở khâu cuối cùng này, thường thì các tester sẽ phải làm các báo cáo để gửi về cho lead. Báo cáo này sẽ bao gồm các loại:
- Test Summary Report: Báo cáo tổng kết về quá trình kiểm thử, bao gồm số lượng test case đã thực hiện, số lượng test case pass, số lượng test case fail, số lượng test case chưa thực hiện, v.v... Thường sẽ được quy vào là Milestone report, tức là report ở cuối các khâu kiểm thử, như Integration Test, System Test, Acceptance Test
- Task report: Thường sẽ có thể report theo ngày hoặc theo tuần, đã report theo tuần thì không report theo ngày. Report này sẽ là để các thành viên team test báo cáo về tiến độ công việc của mình, và cũng để lead biết được mình đã làm gì, đang làm gì, và sẽ làm gì.
Ở khâu Test Completion thì sẽ chỉ quan tâm đến Test Summary Report, Task report sẽ được làm ở trong quá trình kiểm thử, nó sẽ rất giống Daily scrum nhưng là nội bộ của team test.
Lấy vào
- Các reports
Trả ra
- Báo cáo hoàn thiện
- Software baseline - phiên bản cuối cùng của sản phẩm phần mềm
Review Phase
Công đoạn Review nôm na chính là bước Demo, đến đây thì phần việc của Tester con đã hết, chủ yếu là các lead và BA sẽ làm việc với khách hàng để demo sản phẩm. Nếu có vấn đề, tức là khách hàng không hài lòng với tình trạng hiện tại của sản phẩm, nó sẽ được đẩy sang Sprint sau để tiếp tục xử lý.
Tóm lại, cách mà một tester tham gia vào một sprint là như sau
-
Ở planning phase, các lead sẽ tham gia vào quá trình lên kế hoạch, test lead sẽ tạo ra test plan. Cùng lúc đấy, tester đọc và hiểu yêu cầu, đưa ra các câu hỏi cho BA và khách hàng.
-
Khi đã có test plan, tester sẽ bắt đầu làm việc theo quy trình phát triển, log task, báo cáo task cần làm,v.v... sau đó bắt đầu với viết test case.
-
Quá trình viết test case sẽ tốn thời gian và có thể gặp vấn đề, nên nó sẽ được báo cáo trong các Daily scrum. Sau khi test case đã được viết xong thì sẽ qua review, nếu không có vấn đề gì thì sẽ qua test execution.
-
Test execution cũng có thể gặp vấn đề, nên nó cũng sẽ được báo cáo trong các Daily scrum. Tester sẽ log bug, gửi cho dev, làm việc với nhau để cải thiện chất lượng sản phẩm.
-
Cho tới khi gặp deadline, hoặc đã đạt được exit criteria, thì tiến tới test completion, tạo ra các báo cáo và gửi về cho lead.
-
Cuối cùng là review, nếu không có vấn đề gì thì qua sprint tiếp theo, nếu có vấn đề thì sẽ được đẩy sang sprint sau, tester cần nắm được những gì đang tồn đọng để chuẩn bị cho sprint sau.
-
Retrospective là bước cuối cùng, nó sẽ giúp team test hiểu được những gì đã làm tốt, những gì đã làm không tốt, và cách để cải thiện. Tuy nhiên nó có thể được bỏ qua và thu gọn bằng trao đổi qua mail.
Typical question: What are the output of each step in test process? - Các output của mỗi bước trong quy trình kiểm thử là gì?
Typical question: How does a tester participate in a sprint? - Một tester tham gia vào một sprint như thế nào?
