Test Process

Duy Văn | 29/11/2024

  1. Khái niệm
  2. Test process in a sprint
    1. Planning phase
    2. Daily Scrum
      1. Test Monitor & Control:
      2. Test Analysis
      3. Test Designing
      4. Test Implementing
      5. Test Execution
      6. Test Completion
    3. Review Phase

Quy trình kiểm thử là xương sống của cả quá trình test, cái gì cũng phải làm theo quy trình, vấn đề tại sao phải làm theo quy trình:

  • Thứ nhất, hoạt động kiểm thử vốn là một phần của quá trình phát triển sản phẩm phần mềm, mà quá trình này như đã nêu ở bài SDLC, cũng là một cái có quy trình, vậy thì đã là một phần của quy trình thì kiểm thử cũng phải có quy trình.
  • Quy trình kiểm thử suy rộng sẽ lồng ghép vào quy trình phát triển phần mềm một cách không tuần tự, nếu việc của tester chỉ có làm system level test, thì đương nhiên, nó sẽ được thực hiện đúng theo thứ tự, tức là dev làm xong hết, deploy rồi mới nhảy vào test. Nhưng nếu chẳng may dự án cần tester làm unit test, nó sẽ được thực hiện song song với dev, không có quy trình thì các thứ sẽ loạn hết.
  • Tất cả các vị trí nhân sự dự án làm việc cũng có quy trình, vậy thì khi tester làm việc không có quy trình thì sẽ làm hỏng quy trình của các vị trí khác do với mô hình phát triển Agile, giao tiếp và hợp tác là cực kỳ quan trọng
  • Cuối cùng là nghiệp vụ của tester sẽ được đảm bảo chất lượng bởi một quy trình tốt, nếu không có quy trình thì tester sẽ làm việc theo cảm tính, không có cơ sở khoa học, không có cơ sở để đánh giá chất lượng công việc của mình.

Khái niệm

Quy trình kiểm thử là một chuỗi các bước có logic mà tester (hoặc nhóm tester) phải thực hiện để kiểm thử sản phẩm phần mềmTest process is the logical sequence of steps that the tester (or test team) must perform in order to test the software product properly

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:

Lên kế hoạch kiểm thử
Cụ thể kế hoạch thế nào, bạn có thể lội về Test Plan		1. Test Planning
Theo dõi và kiểm soát quy trình kiểm thử2. Test Monitor & Control
Phân tích kiểm thử3. Test Analysis
Thiết kế kiểm thử4. Test Designing
Ứng dụng kiểm thử5. Test Implementing
Vận hành kiểm thử6. Test Execution
Hoàn thành kiểm thử7. Test Completion

Cụ thể, đầu tiên chúng ta sẽ bóc tách quy trình này ra và ghép nối nó vào SDLC. Lý do là vì quy trình kiểm thử chỉ quan trọng đối với tester và hơi quan trọng đối với dev.

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 Clariy a requirement.

Bản chất Test Analysis đã có thể bắt đầu từ Planning Phase, như trong SDLC đã nêu, ở giai đoạn Planning phase thì team test đã có thể nghiên cứu và đưa câu hỏi lên cho BA và khách hàng, tuy nhiên, chỉ sau khi Test Monitor & Control đã được triển khai, thì team test mới được phép kết thúc việc nghiên cứu và làm rõ yêu cầu.

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à:
    1. 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ả
    2. 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.
    3. 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 Designing

Đâ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 combinationNgườ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 Designing Technique) mà mình sẽ nói qua và hướng dẫn trong bài này và Test Designing 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 Implementing

Đâ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?