Nhiều doanh nghiệp dồn gần như toàn bộ ngân sách và thời gian vào việc lập trình tính năng, nhưng lại coi kiểm thử là bước phụ, làm cho có trong vài ngày cuối trước khi đưa app lên chợ ứng dụng. Hệ quả rất dễ đoán: bản phát hành đầu tiên đầy lỗi vặt, màn hình vỡ trên một số dòng máy, thao tác thanh toán treo giữa chừng, và người dùng gỡ app chỉ sau vài phút kèm theo một đánh giá một sao. Với sản phẩm di động, ấn tượng ban đầu gần như không có cơ hội làm lại. Vì vậy một công ty làm app chuyên nghiệp luôn coi kiểm thử là một phần cấu thành của quá trình phát triển, chạy song song với lập trình chứ không phải công đoạn dồn vào phút chót.

Vì sao kiểm thử ứng dụng di động khó hơn nhiều người tưởng

So với một trang web chạy trên vài trình duyệt phổ biến, ứng dụng di động phải sống trong một môi trường phân mảnh khắc nghiệt hơn hẳn. Riêng Android đã có hàng nghìn dòng máy với kích thước màn hình, mật độ điểm ảnh, phiên bản hệ điều hành và lớp giao diện tùy biến của từng hãng khác nhau. iOS đỡ phân mảnh hơn nhưng vẫn phải tính đến nhiều thế hệ iPhone, iPad, các kích thước tai thỏ và Dynamic Island.

Chưa hết, app còn phải xử lý những tình huống mà web hiếm khi gặp: cuộc gọi đến giữa lúc người dùng đang nhập liệu, thông báo đẩy chen ngang, mạng rớt từ 4G xuống 3G rồi mất hẳn khi vào thang máy, pin yếu khiến hệ điều hành đóng ứng dụng nền, người dùng từ chối cấp quyền vị trí hoặc máy ảnh. Mỗi biến số đó là một nhánh có thể phát sinh lỗi. Kiểm thử di động vì thế không phải là bấm thử vài nút, mà là kiểm soát một không gian trạng thái rất rộng.

Các tầng kiểm thử cần có trong dự án

Một quy trình lành mạnh thường được tổ chức theo hình kim tự tháp, với phần đáy rộng là những bài kiểm thử nhanh và rẻ, phần đỉnh hẹp là những bài chậm và tốn kém:

  • Kiểm thử đơn vị (unit test): kiểm tra từng hàm, từng lớp logic như tính toán giỏ hàng, định dạng ngày tháng, xử lý chuỗi. Chạy trong vài giây và bắt lỗi ngay khi lập trình viên vừa gõ xong.
  • Kiểm thử tích hợp: đảm bảo các module ghép với nhau đúng, ví dụ tầng gọi API trả về dữ liệu và tầng lưu trữ cục bộ ghi lại chính xác.
  • Kiểm thử giao diện đầu-cuối: mô phỏng thao tác thật của người dùng qua các công cụ như Espresso, XCUITest hoặc Appium, đi trọn một luồng như đăng ký, đăng nhập, đặt hàng.
  • Kiểm thử thăm dò thủ công: tester dùng app như một người thật, cố tình đi những đường vòng, nhập dữ liệu vô lý, để phát hiện những lỗi mà kịch bản tự động không nghĩ tới.

Sai lầm phổ biến là chỉ làm tầng trên cùng bằng tay. Cách đó vừa chậm vừa dễ bỏ sót, và mỗi khi sửa một dòng code lại phải kiểm tra lại thủ công toàn bộ. Đầu tư vào tầng đáy tự động hóa giúp đội ngũ dám thay đổi mã nguồn mà không nơm nớp lo phá vỡ tính năng cũ.

Ma trận thiết bị và điều kiện mạng

Không đội ngũ nào đủ ngân sách mua hết mọi dòng máy trên thị trường, nên cần một ma trận thiết bị hợp lý dựa trên dữ liệu người dùng thực tế của sản phẩm. Nếu phần lớn khách hàng dùng máy Android tầm trung, việc chỉ kiểm thử trên iPhone đời mới của lập trình viên là một sai lầm nguy hiểm. Nên chọn vài dòng máy phổ biến nhất, một máy cấu hình thấp để đo hiệu năng thực, một máy màn hình nhỏ và một máy màn hình lớn để bắt lỗi bố cục.

Với những cấu hình không có sẵn, các dịch vụ như Firebase Test Lab hay BrowserStack cho phép chạy kịch bản kiểm thử trên hàng trăm thiết bị thật đặt trên đám mây. Song song đó, cần chủ động mô phỏng điều kiện mạng kém: bật chế độ giới hạn băng thông, ngắt kết nối giữa chừng, để xem app hiển thị trạng thái chờ, báo lỗi thân thiện và tự thử lại hay chỉ treo trắng màn hình.

Beta thật với người dùng thật

Trước ngày phát hành chính thức, một vòng thử nghiệm với người dùng thật là bước không nên bỏ. TestFlight của Apple và kênh thử nghiệm nội bộ của Google Play cho phép phân phối bản dựng cho một nhóm giới hạn. Điều quý giá không chỉ là số lỗi tìm được, mà là cách người thật hiểu và sử dụng sản phẩm, thường khác xa hình dung của đội phát triển.

Kèm theo đó, cần cài sẵn công cụ báo cáo sự cố như Crashlytics để mỗi lần app sập đều gửi về ngăn xếp lỗi kèm thông tin thiết bị. Nhờ vậy nhóm kỹ thuật biết chính xác lỗi xảy ra ở dòng nào, trên máy nào, thay vì mò mẫm theo mô tả mơ hồ của người dùng. Kết hợp với công cụ phân tích hành vi, đội ngũ còn nhìn ra chỗ người dùng bỏ dở giữa luồng, một tín hiệu về trải nghiệm chứ không chỉ về lỗi kỹ thuật.

Tiêu chí để dám bấm nút phát hành

Cuối cùng, cần một danh sách tiêu chí phát hành rõ ràng để tránh tranh cãi cảm tính vào phút chót. Danh sách này nên bao gồm: không còn lỗi nghiêm trọng đang mở, các luồng quan trọng như đăng nhập và thanh toán đã chạy trơn trên toàn bộ ma trận thiết bị, tỷ lệ sập dưới ngưỡng cho phép, thời gian khởi động nằm trong mức chấp nhận được, và các quyền riêng tư đều có lời giải thích hợp lý. Khi mọi mục đều được đánh dấu hoàn thành, việc phát hành không còn là một canh bạc mà là một quyết định có cơ sở. Kiểm thử được làm nghiêm túc không kéo dài dự án, ngược lại nó giúp tránh những đợt vá lỗi khẩn cấp tốn kém và giữ được niềm tin của người dùng ngay từ ngày đầu tiên.