Có thể câu trả lời của mọi người là Trời ơi, nó dễ ẹc mà. Ai mà chẳng test được. Nhưng có bao nhiêu người đã từng nghĩ là làm thế nào để test API cho đúng, cho đủ, phòng tránh và hạn chế ít nhất những sai lầm tới product. Trong bài này tôi sẽ liệt kê ra những cách suy nghĩ mà tôi đã áp dụng, những công viêc mà tôi đã làm cho việc test một API, làm sao đảm bảo API đó mang lại chất lượng tốt nhất cho khách hàng.
Đầu tiên, để testing hiệu quả thì bạn phải đặt cho việc test đó nằm một ngữ cảnh cụ thể. Như nó phục vụ cho yêu cầu, nhiệm vụ nào, ai là khách hàng của bạn, khách hàng đó muốn đạt được cái gì?
Ví dụ như ngữ cảnh của tôi, tôi đang phục vụ cho developer hay cho stackholders nào, người nào trong dự án có thể đánh giá chất lượng product và tôi phải quan tâm họ cần gì ở mình.
Thêm nữa, trước khi làm bất cứ cái gì, tôi cần chỉ ra bao nhiêu thời gian để tôi có thể hoàn thành yêu cầu đó. Và tôi sẽ hỏi những câu hỏi liên quan để tìm câu trả lời cho bản thân mình: Ví dụ như có bao nhiêu deadlines tôi cần hoàn thành? Bao nhiêu lâu sẽ ra 1 bản build? Tôi có bao nhiêu thời gian để chuẩn bị một báo cáo?
Đã có ai test product này chưa? Họ là ai? Họ ở đâu? Tôi có thể nói chuyện với họ không? Nếu không thì họ có thể cung cấp những thứ giúp cho công việc của tôi được không? Tôi có nằm trong team nào? Những skill nào mà các thành viên trong team có? Skill nào mà team chúng tôi cần?
Cái gì mà khách hàng cần tôi cung cấp? Một bản báo cáo, một danh sách bugs, nhưng chúng dưới dạng nào? Chỉ cần chat thông báo với họ, hay chỉ là những tóm tắt sơ lược? Tôi sẽ muốn làm rõ những thứ này trước vì tôi biết tôi có thể nhanh chóng đưa feedback tới khách hàng của tôi hoặc tới các developer trong team tôi. Liệu khách hàng ưu tiên các cách trang trọng, ví dụ như phải dùng cụ thể một mẫu báo cáo nào đó, hay phải là một tool như họ mong đợi để quản lý những báo cáo đó? Khách hàng càng quan tâm tới bất cứ gì, tôi sẽ ghi chú lại ngay cả khi tôi thấy chúng sẽ tốn nhiều chi phí của khách hàng hơn
Vậy còn những thứ nào khác mà khách hàng, developer, hay những stackholder muốn xem, bây giờ hay sau này? Dữ liêu đầu vào mà tôi tạo ra cho testing? Script cho automation? Kết quả test? Những test result này cần mô hình hóa ra hay không? Các tools mà tôi tạo ra hay những tài liệu tôi làm cho nó? Một mô tả ngắn về product? Những bản báo cáo chi tiết cho một số đối tượng cụ thể? Qua những câu hỏi đó, tôi sẽ tiếp tục nhiệm vụ của mình và mong muốn đáp ứng hết tất cả chúng trong quá trình thực hiện dự án.
Sau khi đã liệt kê những cái tôi cần làm. Tôi sẽ bắt đầu bằng những thứ nhỏ nhất bằng việc học về product mà tôi đang làm, đồng thời thực hiện 1 hoặc 2 hạng mục trong danh sách đó một cách song song. Tôi nói chuyện với developer nếu tôi có thể. Tôi tham gia meeting trong các buổi design và planning nếu tôi có thể. Công việc của tôi trong các meeting đó là học, nghiên cứu, đánh giá khả năng có test được chức năng đó không, nêu những ý tưởng và hỏi những câu hỏi để đánh giá vấn đề và rủi ro có thể xảy ra. Tôi sẽ hỏi về những testing mà developer đã làm, và nếu có thể tôi sẽ kiểm tra chúng đã có được thực hiện hay chưa.
Nếu tôi được mời tới một meeting nào đó muộn hay cả khi không được mời, tôi sẽ ghi chú lại nó. Tôi muốn trở thành người hữu dụng nhiều nhất có thể, và tôi cũng muốn ghi chú và lưu giữ lại những thứ làm cho việc testing của tôi khó hơn hoặc dễ hơn vì tôi biết mình có thể học được một thứ gì từ những điều đó. Tôi cũng sẽ nói ra những cái tôi đã test một cách dễ hiểu và dễ hình dung nhất với sản phẩm, với dự án và tới team mà tôi đang làm.
Tôi nghiên cứu tài liệu cho những API liên quan tới product ngay cả khi tôi không làm trong vùng đó. Tôi muốn phát triển sự hiểu biết của mình về sản phẩm: những service nào mà hệ thống đang sử dụng, chúng được control như thế nào, chúng đang đóng vai trò gì trong hệ thống. Khi tìm ra những thứ đang thắc mắc, tôi note lại để có thể tìm hiểu và nghiên cứu về nó sau. Và cứ tiếp tục như vậy, tôi quan tâm tới những thứ đang gây khó hiểu và không đồng bộ trong sản phẩm mà tôi đang làm.
Trong khi tôi đọc tài liệu, tôi sẽ tự hỏi mình rằng: Có cách nào đơn giản, dễ và tiện mà tôi có thể làm với product này? Nếu như tôi có sản phẩm trên tay, tôi sẽ thử nó bằng những yêu cầu đơn giản nhất, như dùng 1 tool cung cấp khả năng tương tác trực tiếp API đó với product. Có thể nó là 1 tool của công ty, hoặc là 1 bên thứ ba như Postman hay SOAPUI. Và tôi sẽ tự phát triển từ những script đơn giản trước. Tiếp theo, tôi sẽ xem cách ghi log từ những tool đó. Vì tôi biết, cách test hiệu quả nhất là phải kiểm tra API mà tôi đã test đã đúng hay chưa.
Nếu như tôi tìm được bug, hoặc bất cứ sự mơ hồ nào đang ảnh hưởng tới product. Tôi sẽ báo cáo nó đúng cách. Nếu như bug đó, tôi đã thử nhiều lần và nó thực sự ảnh hưởng nghiêm trọng. tôi sẽ báo cáo ngay lập tức. Có khi chúng chỉ là những vấn đề liên quan đến khả năng test, hoặc chỉ là tính dễ dàng sử dụng sản phẩm của user. Nhưng tại thời điểm đó của dự án, tôi lựa chọn phương án tiếp cận như vậy để giải quyết vấn đề, vì nó là cách nhanh nhất, ít tốn kém nhất, và đơn giản nhất trong những kiểu báo cáo mà tôi có thể làm.
Mục tiêu duy nhất của tôi lúc này, không phải là tìm bug, mà chỉ ra làm thế nào mà 1 người có thể dùng API đó để truy cập tới product, làm cách nào để họ thấy giá trị từ API đó, và những vấn đề đó đang đe dọa tới chất lượng của product như thế nào. Tôi cũng sẽ xây dựng những mô hình mà tôi có thể nhớ về product đó, cách mà chúng work ra sao, cách dùng chúng thế nào, cách mà mình có thể test được chúng. Tìm hiểu về sản phẩm là cách tốt nhất giúp tôi tìm ra những bugs tốt hơn, sâu hơn, khó tìm hơn, thường xuyên hơn và hạn chế gây hại tới product hơn.
Tóm lại, để có thể test tốt, tôi muốn trở thành 1 nhà nghiên cứu giỏi với những khả năng sau: ghi chép, tạo sơ đồ, xây dựng danh sách các chức năng, đánh giá vấn đề và rủi ro, xây dựng bản đồ tư duy, chú thích tài liệu. Và định kỳ thường xuyên, tôi sẽ work với developer, managers hay những bạn cùng team tôi để hỗ trợ cho việc tìm hiểu của tôi về product.
Bài viết được lược dich từ developsense.com – exploratory testing in api , bạn có thể xem toàn bộ bài viết bằng tiếng anh và nguyên series liến quan đến chủ đề exploratory của tác giả Michael Bolton
"You're on your own. And you know what you know. And YOU are the guy who'll decide where to go." 