Tập trung kiểm thử bằng việc hiểu khách hàng sử dụng sản phẩm như thế nào

Tóm tắt: Nếu bạn không chắc chắn về việc tập trung kiểm thử ở đâu hoặc nên thực hiện loại thử nghiệm nào, hãy nhìn vào những gì người dùng của bạn đang nói với bạn. Hiểu được phân tích về cách khách hàng của bạn sử dụng ứng dụng của bạn có thể giúp bạn cải thiện nỗ lực thử nghiệm của mình. Bài viết này khám phá các trường hợp về cách các dữ liệu này có thể thông báo cho tự động hóa giao diện người dùng, kiểm tra tính tương thích và kiểm tra dịch vụ web. Một vài năm trước đây, tôi là leader một nhóm thử nghiệm cho một ứng dụng client-server cho một hệ thống quản lý mạng trong lĩnh vực viễn thông. Chúng tôi đã tự động hóa tất cả các bài kiểm thử xung quanh các API và cảm thấy rằng chúng tôi đã khai thác tất cả các giao diện đó; Đã đến lúc bắt đầu tự động hoá thông qua giao diện người dùng (UI).

Sử dụng dữ liệu người dùng để đưa ra chiến thuật test

Thứ nhất, công nghệ mà chúng tôi chọn để thực hiện khách hàng không tương thích với bất kỳ công cụ kiểm tra tự động nào trên thị trường. Để tự động hóa thông qua giao diện người dùng, chúng tôi đã phải xây dựng kết nối tương đối đắt tiền.

Thứ hai, chúng tôi đã có 150 tính năng như là một phần của giao diện người dùng. Đầu nối đắt tiền, lần 150, là rất nhiều để giải quyết.

May mắn thay, sản phẩm của chúng tôi đã có nhật ký hoạt động của người dùng theo dõi người đã thực hiện hành động trong giao diện. Chúng tôi đã tập hợp được nhật ký hoạt động trong vòng 90 ngày trước đó từ những khách hàng hàng đầu của chúng tôi. Nó chỉ ra rằng 93% khách hàng sử dụng chỉ tham gia ba trong số các tính năng, và ba tính năng khác chỉ chiếm 2 phần trăm sử dụng. Đoán được đó là ba tính năng nào chúng tôi đã tự động hóa chúng.

Ngoài việc giúp chúng tôi tập trung nỗ lực tự động hóa thử nghiệm của mình, việc hiểu cách khách hàng của chúng tôi sử dụng ứng dụng của chúng tôi thì nó còn là những thông tin giá trị cho từng team. Nhóm quản lý sản phẩm sau đó đã biết thiết kế lại các tính năng này để giúp chúng tối ưu hơn. Nhóm quản lý chương trình có thể sắp xếp lịch trình của chúng tôi, biết nơi mà hầu hết các rủi ro nằm trong ba tính năng này. Và nhóm tiếp thị biết rằng đối thủ cạnh tranh cũng có thể xây dựng một ứng dụng đơn giản chỉ thực hiện ba tính năng này và có thể làm chúng ta thất bại.

Xem phân tích người dùng trước khi xây dựng chiến lược kiểm thử có chất lượng. Các bài kiểm tra tự động, kiểm tra smoke, kiểm tra hiệu năng và giám sát giao dịch đều có lợi từ việc nắm rõ các tính năng của khách hàng.

Tập trung kiểm thử vào những thiết lập cần thiết

Sau đó, tôi tiếp tục sử dụng một ứng dụng web tài chính dựa trên người tiêu dùng, nơi mà khách hàng không thực sự hiểu biết về công nghệ và đã tiêu tốn ứng dụng của chúng tôi thông qua trình duyệt. Một câu hỏi quan trọng cho việc kiểm thử của chúng tôi là, chúng tôi nên kiểm thử trên trình duyệt nào và phiên bản bao nhiêu?

Nhìn vào dữ liệu khiến chúng tôi rất đau đầu vì việc đó. Các trình duyệt đã được sử dụng: Internet Explorer, Chrome, Firefox, Safari và Opera. Thậm chí đã có một vài khách hàng truy cập vào ứng dụng tài chính của họ thông qua trình duyệt trên bảng điều khiển trò chơi của họ.

Chúng tôi đã chọn nhiều trình duyệt quan trọng nhất có thể kiểm tra, cover được khoảng 85% việc sử dụng, nhưng vẫn còn 15% người dùng có cấu hình trình duyệt chưa được kiểm thử. Với một triệu người dùng, có 150.000 người đang tự chịu rủi ro. Trước khi yêu cầu mở rộng phạm vi, chúng tôi tự hỏi liệu chúng tôi có thể làm ảnh hưởng đến hành vi của khách hàng trong các trình duyệt họ đã chọn.

Nhóm của tôi đã tìm ra rằng nếu họ đang sử dụng các trình duyệt mới nhất, khách hàng của chúng tôi sẽ được hưởng lợi từ trải nghiệm tốt hơn trên toàn bộ việc sử dụng Internet, không chỉ với sản phẩm của chúng tôi. Sử dụng chuỗi người dùng-agent để xác định xem khách hàng nào đang truy cập vào trình duyệt ưu tiên thấp, chúng tôi đã hiển thị một hộp thoại cho thấy họ sử dụng một trình duyệt mới. Sau hai tháng, 15% trên các trình duyệt chưa được kiểm tra trở thành 10%. Chúng ta đã tăng mức độ khẩn cấp của tin nhắn, cho rằng trải nghiệm người dùng sẽ tốt hơn với một trình duyệt được support và việc sử dụng những trình duyệt không được support sẽ có những rủi ro. 10 phần trăm đã giảm xuống còn 5 phần trăm. Hầu hết những khách hàng của chúng ta đã sử dụng các trình duyệt mà ta đã test mà không phải mở rộng phạm vi test.

Mặt khác, chiến thuật này không thực hiện được đối với mobile app. Việc yêu cầu khách hàng đổi thiết bị mobile của họ không phải là một lựa chọn tốt, vì thế ta cần thử trên càng nhiều thiết bị mà khách hàng sử dụng càng tốt. Nhưng việc đưa ra đánh giá về khách hàng cũng rất có ích. Ta sẽ test trên những loại thiết bị phổ biến nhất. Lựa chọn khác là ta có thể sử dụng máy giả lập. Và để cân bằng, ta bao quát các phần này bằng sự kết hợp của các nhà cung cấp dịch vụ crowd-testing và các cloud-based device farms.

Theo dõi tình trạng sử dụng của khách hàng để test ưu tiên

Có rất nhiều hệ thống được tạo nên bởi các back-end service, và việc hiểu tình trạng sử dụng của khách hàng cũng đem đến lợi ích cho việc test của bạn. Biết được mức độ của những lần gọi dịch vụ, thiết lập của các lần gọi đó, và mối quan hệ giữa dịch vụ web và các customer flow quan trọng đều sẽ có ích.

Ví dụ trong trường hợp test tự động UI, biết được mức độ của các lần gọi dịch vụ sẽ giúp bạn điều chỉnh sự tự động. Mức độ gọi của mỗi dịch vụ có thể được thu thập từ log của server production cho hệ thống theo dõi tình trạng của dịch vụ của bạn. Bên cạnh việc đánh giá được tình trạng sử dụng của khách hàng, bạn có thể biết được các dịch vụ nào là thiết yếu, được gọi nhiều lần từ nhiều hoạt động của khách hàng.

Một vấn đề mà team của tôi gặp khi test web service đó là sự hoán vị của các case test mà chúng tôi có thể tạo. Đầu tiên, chúng tôi có nhiều lượt gọi service khác nhau, và mức độ service được mở rộng. Kiến trúc của chúng tôi đã được chuyển từ một mô hình dịch vụ đã được sắp sếp, nơi có ít dịch vụ hơn cung cấp nhiều tính năng hơn, sang mô hình microservice, nơi nhiều dịch vụ cung cấp nhiều task nhỏ. Trong quá trình chuyển giao, chúng tôi đã hỗ trợ cả 2 dịch vụ.

Bên cạnh nhiều dịch vụ đó, yêu cầu của mỗi dịch vụ bao gồm nhiều tham số, một số cần thiết và một số là tuỳ chọn. Ví dụ, một dịch vụ có ba tham số bắt buộc và hai tham số tuỳ chọn, như vậy ta sẽ có bốn cách để gọi dịch vụ (không có tham số tuỳ chọn, chỉ bao gồm tham số tuỳ chọn thứ nhất, chỉ bao gồm tham số tuỳ chọn thứ hai, bao gồm cả hai tham số tuỳ chọn).

Test toàn bộ tầng dịch vụ sẽ tốn nhiều code. Một lần nữa, phân tích khách hàng lại trở nên cần thiết.

Việc gọi dịch vụ xảy ra ở production thường được theo dõi bằng một phần mềm theo dõi, phần mềm này sẽ theo dõi hiệu năng, xác suất lỗi, và thiết lập gọi của mỗi lần gọi dịch vụ. Chúng tôi sử dụng những dữ liệu này để đánh giá độ ưu tiên của bài test.

Chúng tôi sử dụng mức độ của mỗi lần gọi để quyết định dịch vụ nào được sử dụng nhiều nhất, và để chắc chắn rằng những dịch vụ được sử dụng nhiều sẽ được test tự động trước. Chúng tôi cũng xem xét xác suất lỗi để tìm cơ hội cải thiện các dịch vụ này và để giúp đánh giá độ ưu tiên của việc test. Cuối cùng, chúng tôi nhìn vào cấu trúc của các lần gọi để xem các tham số tuỳ chọn nào thực sự được sử dụng trong thực tế, giúp chúng tôi biết được các thiết lập mà mình phải test.

Kiến thức là sức mạnh

Team của chúng tôi đạt được ba lợi ích từ việc áp dụng đánh giá khách hàng vào việc test: Các hoạt động của người dùng ảnh hưởng đến chiến thuật test tự động của chúng tôi; tập trung test vào những phần hay được sử dụng; và sử dụng việc theo dõi dịch vụ để cho phép chúng tôi test dựa cơ sở trên dữ liệu thực thay vì dữ liệu lý thuyết.

Năm bắt được hành vi của khách hàng đem lại lợi ích cho tất cả các bên - team của bạn, stakeholders và cuối cùng là chính khách hàng của bạn.

Tham khảo

https://www.stickyminds.com/article/focus-your-testing-understanding-how-customers-use-your-product?page=0%2C0