Xây dựng kế hoạch kiểm thử lý tưởng cho Mobile App

I. Introduction

Tôi đã từng cho rằng giai đoạn quan trọng nhất đối với bất kỳ dự án Mobile App nào là giai đoạn Testing. Tuy nhiên khi bắt đầu sự nghiệp QA của mình, tôi nhận thấy Test Plan là cần thiết và quan trọng, nó là một cách để nắm bắt và thực hiện xuyên suốt quá trình Testing. Kế hoạch là vô dụng nhưng lập kế hoạch thì không thể thiếu!

1. Test Plan là gì?

Test plan là tài liệu tổng quan về kế hoạch thực hiện của việc testing trong project plan và dựa vào project plan để xây dựng.

Test plan mô tả phạm vi của project, hướng tiếp cận, STLC (Software Testing Life Cycle), resource và nhân lực cần có, các features cần được test và không phải test, các tool test và môi trường test cần có. Có thể coi test plan là xương sống của một testing project và là cái cần được chuẩn bị đầu tiên khi có một project.

2. Tại sao phải viết test plan?

  • Để định hướng suy nghĩ cho tester khi bắt đầu tham gia dự án
  • Là phương tiện giao tiếp của nhóm test với đội dự án và là công cụ phân công công việc trong nhóm test.
  • Hỗ trợ quản lý và điều chỉnh khi có thay đổi.

3. Các loại test plan

  • Master test plan: Quản lý tiến độ, phân công trong việc trong toàn bộ dự án test.
  • Phase test plan: Quản lý tiến độ, phân công trong việc trong một phase cụ thể.

4. Mục tiêu cần đạt được trong test plan

  • Xác định được các yêu cầu
  • Tăng hiệu quả làm việc nhóm
  • Xác định loại test
  • Xác định chiến lược test
  • Chỉ rõ trách nhiệm
  • Xác định deadline
  • Thời điểm dừng test
  • Cập nhật liên tục

5. Khi nào cần tạo Test plan?

plan.PNG

Test plan cần được làm càng sớm càng tốt, ngay từ khi nhóm dự án có Project plan và Requiments spec. Sẽ là quá muộn nếu tạo Test plan khi cần bắt đầu thực hiện test.

6. Nội dung cơ bản của Test plan

Test Planning gồm nhiều hoạt động phụ thuộc vào đặc thù từng sản phẩm cũng như tính chất riêng của dự án ở mỗi công ty nên Test Plan có thể sẽ hơi khác nhau giữa các công ty và mỗi dự án. Test plan trong dự án mobile app về cơ bản sẽ gồm các phần như sau:

Screen Shot 2016-10-25 at 12.59.26 PM.png

II. Xây dựng Test Plan cho Mobile App

What?

1. Scopes

Đề ra đc scopes để test, tức là cái gì sẽ test và cái gì không cần test: functional hoặc non-functional nào sẽ được kiểm tra. Đừng quên đề cập đến một cách rõ ràng các tính năng hoặc yêu cầu ngoài phạm vi! Scopes phải phù hợp để tránh tình trạng test thiếu hay là test nhiều hơn mức cần thiết.

How?

2. Test Methodology

Tuỳ thuộc vào thời gian và ngân sách, mỗi mỗi công ty hoặc mỗi dự án sẽ lựa chọn các phương pháp khác nhau, có thể là Waterfall, Iterative, Agile hay Extreme Programming.

3. Testing Approach

test-approach.jpg

Do sự phức tạp của thiết bị và hệ điều hành, mỗi phần mềm sẽ có cách tiếp cận kiểm thử khác nhau. Nó có thể là một thử nghiệm trên Cloud, sử dụng device thật, Emulators hay cả hai. Nó được tiến hành manual hoàn toàn hay automation.

4. Testing Types

Cần cân nhắc lựa chọn những phương pháp test phù hợp với dự án như là test theo Black-box hay White-Box hay Gray-box. Cân nhắc các loại test nào và thứ tự ra sao sẽ được sử dụng để test sản phẩm. Chỉ ra sự khác nhau của các loại test với một mô tả ngắn cho nó. Các loại test cho mobile app: UI Testing, Usability Testing, Functional Testing, Security Testing, Performance Testing, Interruption Testing, Installation Testing, Certification testing, Compatibility Testing, Network Testing, Localization Testing, Synchronization Testing,...

mobile-app-testing-types.jpg

5. Test Levels

Test Levels chủ yếu phụ thuộc vào phạm vi của dự án, thời gian và ngân sách. Test Levels chỉ ra tất cả các cấp kiểm tra trong scope - Unit Testing, Component Testing, API Testing, Integration Testing, System Testing, Regression Testing & Acceptance Testing (A/B hay Beta Tests).

6. Testing Tools

Kiểm thử Mobile app không hề đơn giản như kiểm thử trên Web, nó đòi hỏi các tester cần phải có kỹ năng và kiến thức mobile, hiểu biết về thời gian sử dụng thực tế và một loạt các công cụ hỗ trợ. Cùng với mục đích kiểm thử, phần mềm cần sử dụng các tools hỗ trợ nào, phần này cần chỉ ra cụ thể: Requirements Tracking Tool, Bug Tracking Tool, Automation Tools, and Test execution Tools,...

tools1.png

Where?

7. Test Environment

Where: Môi trường test, cấu hình, server ra sao để test. Test trên bao nhiều device, bao nhiêu browser. Có thể vẽ diagram, topology các trường hợp cần test.

Một trong những khác biệt lớn giữa các web app và mobile app là môi trường kiểm thử. Với kiểm thử mobile app sẽ cần đề cập đến chi tiết về các thiết bị, firmware, emulators, hệ điều hành (OS), trình duyệt và phiên bản tương ứng được sử dụng trong khi thử nghiệm.

Tuỳ vào mỗi giai đoạn Unit test, Intergration test, System test, Acceptance test sẽ ứng với môi trường kiểm tra nhất định. Từ đó xác định các yếu tố để xây dựng môi trường kiểm tra, sử dụng như môi trường thật hay tạo môi trường giả lập gần giống với môi trường chạy thật của chương trình.

  • Khi test chạy chương trình bằng bản dịch hay chạy trên code. Thông thường, các giai đoạn System test, Acceptance test phải chạy trên bản dịch

  • Với CSDL thì thông thường, từ Intergration test, ta phải thiết lập CSDL riêng và thiết lập các thông số cho CSDL gần giống hoặc giống hệt như khi chương trình sẽ chạy thật.

  • Điều kiện về mạng: sẽ sử dụng mạng LAN hay Dial up… Thông thường, khi Unit test, có thể sử dụng mạng LAN nhưng khi System test trở đi thì nên sử dụng hệ thống đường truyền giống như hoặc gần giống như môi trường chạy thật.

  • Mô hình sẽ cài đặt chương trình test: số lượng máy chủ, máy trạm; việc chia tách các server, các máy trạm, việc cài đặt các domain … Thông thường, trong Unit test có thể sử dụng viếc thiết lập như khi lập trình, nhưng khi System test trở đi, phải chú ý thiết lập sao cho gần giống mô hình sẽ chạy trong thực tế nhất

device.jpg

When?

8. Test Schedule

Cần tạo timeline hay schedule cho mỗi quá trình test. Nếu là Agile có thể là Cycle & Sprint timeline.

schedule.jpg

9. Thủ tục kiểm soát (Control Procedures)

Mobile App có thể sẽ luôn cập nhật (dynamic), người dùng có thể sẽ muốn có những thay đổi và spec mới. Những thay đổi đã được đề xuất dựa trên Analytics & Feedback. Phần này sẽ nêu chi tiết các thủ tục khi có change requests, reviews & inspections, bug review,...

Who?

10. Vai trò và trách nhiệm (Roles and Responsibilities)

Who: Bao nhiêu người sẽ test, kinh nghiệm kỹ năng của từng người được chọn phải phù hợp với tính chất của sản phẩm và dự án. Mô tả chi tiết của các vai trò và trách nhiệm của các thành viên trong nhóm như Test Manager, SQA, QA,...

resources.jpg

What else?

11. Tiến hành test và quản lý lỗi (Test execution & Defect Management)

Mobile App thực hiện và quản lý lỗi có phần khác biệt so với cách truyền thống. Phần này sẽ nêu chi tiết cách thực hiện trên thiết bị có hệ điều hành, cấu hình khác nhau và quản lý bugs như thế nào. Khuyến khích đính kèm các file log, ảnh, tập tin đính kèm, link, hệ điều hành và phiên bản ứng dụng, device, browser & bước để tái hiện. Đảm bảo ưu tiên cho các lỗi và xác định schedule cho các bug “To Be Fixed Bugs’. Nó có thể sẽ được bước đánh số hoặc set độ ưu tiên.

test-metrics-graph-3.jpg

12. Chuyển giao (Test Deliverables)

Những tài liệu test cần thiết để chuyển giao vào cuối dự án test đó là Test Plan, TestCases và Test Report (bao gồm feedback/recommendations).

13. Rủi ro và giả định (Risks & Assumptions)

risks.png

Mỗi nhóm dự án có trách nhiệm xác định, giảm thiểu rủi ro trong phạm vi của mình. Do đó cần phải tiên đoán được những rủi ro có thể xảy ra trong quá trình test. Những rủi ro đó có thể có liên quan đến con người hay thiết bị, môi trường gây ảnh hưởng đến quá trình hay deadline của việc test. Đề cập đến bất kỳ công cụ sẽ được sử dụng để quản lý rủi ro.

Nêu ra tất cả các giả định trên cơ sở đó xây dựng kế hoạch kiểm thử hoàn chỉnh. Để bảo đảm chất lượng mỗi bản phát hành sẽ đi cùng một quy định phát hành chỉ ra các tính năng và tác động của nó trên các module. Tất cả các lỗi được tìm thấy trong một phiên bản sẽ được fix và được kiểm tra bởi nhóm phát triển trước khi phiên bản tiếp theo được phát hành, thiết bị, emulators và các công cụ hỗ trợ khác sẽ có đầy đủ chức năng trước khi dự án bắt đầu,... Test schedule phải được xem xét lại trong trường hợp có thay đổi.

14. Open Items & Version History

Phần này duy trì tất cả các mục cần giải quyết cùng với ngày hoàn thành, hoặc là ngay lập tức hoặc trong quá trình kiểm tra, như mua sắm devices, Analytics,... Phần này lưu lại lịch sử các phiên bản cho tài liệu để dễ theo dõi khi có bất kỳ thay đổi nào.

Kết luận: Giống như Apps Market & Enterprise Mobility đang có tốc độ tăng trưởng ổn định, kiểm thử Mobile App cũng sẽ tiếp tục là một phần quan trọng của nó. Hy vọng bài viết này sẽ giúp bạn xây dựng được một kế hoạch kiểm thử lý tưởng cho dự án Mobile App.

Nguồn: https://testingmobileapps.wordpress.com/2016/03/22/how-to-build-an-ideal-test-plan-for-mobile-apps/


All Rights Reserved