Mỗi lần nhấn nút phát hành một bản cập nhật, đội ngũ phát triển đều đặt cược vào niềm tin rằng họ không làm hỏng thứ gì đang chạy tốt. Khi không có một quy trình kiểm thử bài bản, niềm tin đó chỉ là hy vọng. Trên di động, hậu quả của một lỗi lọt lưới còn nặng nề hơn web, vì người dùng phải tải bản vá và đánh giá xấu rất khó gỡ bỏ. Bài viết này trình bày cách xây dựng một chiến lược kiểm thử cân bằng, thực tế và giúp bạn phát hành với sự tự tin.

Tháp kiểm thử và sự cân bằng

Một cách tư duy hữu ích là hình dung kiểm thử như một kim tự tháp. Ở đáy là số lượng lớn các kiểm thử đơn vị, kiểm tra từng mẩu logic nhỏ một cách độc lập. Chúng chạy rất nhanh, dễ viết và cho phản hồi tức thì khi có gì hỏng. Ở giữa là các kiểm thử tích hợp, kiểm tra nhiều thành phần làm việc cùng nhau. Trên cùng là số ít kiểm thử giao diện đầu cuối, mô phỏng người dùng thật thao tác qua các màn hình.

Sự cân bằng này quan trọng vì mỗi loại có chi phí và giá trị khác nhau. Kiểm thử giao diện đầu cuối gần với trải nghiệm thật nhất nhưng chạy chậm, dễ vỡ và tốn công bảo trì. Nếu dồn quá nhiều vào tầng này, bộ kiểm thử sẽ trở nên chậm chạp và hay báo lỗi giả, khiến cả nhóm dần bỏ qua nó. Ngược lại, một nền tảng vững chắc các kiểm thử đơn vị giúp bắt phần lớn lỗi sớm với chi phí thấp.

Kiểm thử cái gì là đáng giá nhất

Không thể và cũng không nên kiểm thử mọi thứ. Mục tiêu là tập trung công sức vào nơi rủi ro cao nhất. Những phần xứng đáng được kiểm thử kỹ thường là:

  • Logic nghiệp vụ cốt lõi, nơi một lỗi gây hậu quả nghiêm trọng.
  • Các phép tính liên quan đến tiền bạc, ngày tháng hay quyền hạn.
  • Những phần đã từng có lỗi trong quá khứ, vì chúng dễ tái phát.
  • Các luồng quan trọng như đăng nhập, thanh toán hay gửi dữ liệu.
  • Những đoạn xử lý trường hợp biên dễ bị bỏ sót khi viết tay.

Ngược lại, viết kiểm thử cho những đoạn code đơn giản, ít thay đổi và rủi ro thấp thường tốn công hơn giá trị nó mang lại. Kiểm thử là một khoản đầu tư, và như mọi khoản đầu tư, nó cần được phân bổ khôn ngoan.

Thử thách riêng của thiết bị di động

Kiểm thử ứng dụng di động khó hơn web ở chỗ sự phân mảnh thiết bị rất lớn. Hàng nghìn kiểu máy với kích thước màn hình, phiên bản hệ điều hành và năng lực phần cứng khác nhau. Một ứng dụng chạy hoàn hảo trên máy của lập trình viên có thể lỗi nặng trên một dòng máy phổ thông đời cũ. Vì vậy, kiểm thử trên nhiều cấu hình thiết bị, kể cả máy yếu, là điều không thể bỏ qua.

Bên cạnh đó còn vô số tình huống đặc thù di động cần được thử: ứng dụng bị gián đoạn bởi cuộc gọi đến, xoay màn hình, mất mạng giữa chừng, hệ điều hành thu hồi bộ nhớ khi ứng dụng ở nền, hay người dùng từ chối cấp quyền. Những kịch bản này hiếm khi được nghĩ đến khi viết code nhưng lại là nguồn lỗi thực tế rất phổ biến.

Tự động hóa và kiểm thử thủ công bổ trợ nhau

Kiểm thử tự động rất mạnh nhưng không thay thế hoàn toàn được con mắt con người. Tự động hóa giỏi trong việc bắt các lỗi hồi quy, tức là những thứ từng chạy đúng nay bị hỏng, và làm điều đó nhanh, lặp lại được mà không biết mệt. Tuy nhiên, nó khó đánh giá được cảm giác của trải nghiệm, sự mượt mà của hoạt ảnh, hay liệu một bố cục có thật sự dễ dùng hay không.

Vì vậy, một quy trình lành mạnh kết hợp cả hai. Tự động hóa lo phần kiểm tra lặp lại và bảo vệ chống hồi quy, còn kiểm thử thủ công khám phá tập trung vào trải nghiệm tổng thể và những tình huống bất ngờ mà không kịch bản tự động nào lường hết. Bên cạnh đó, đưa bản thử nghiệm đến tay một nhóm người dùng thật trước khi phát hành rộng rãi cũng giúp lộ ra những vấn đề mà cả đội ngũ lẫn máy móc đều bỏ sót.

Tổng kết

Kiểm thử bài bản không phải là viết thật nhiều kiểm thử cho có, mà là đầu tư đúng chỗ để giảm rủi ro một cách thông minh. Một tháp kiểm thử cân bằng, tập trung vào những phần quan trọng nhất, chú ý đến đặc thù phân mảnh của di động, và kết hợp hài hòa giữa tự động và thủ công sẽ cho bạn thứ quý giá nhất: khả năng phát hành thường xuyên mà không nơm nớp lo sợ. Đó chính là nền tảng để một sản phẩm di động phát triển nhanh và bền vững.