qTrace—món ngon, bổ, rẻ cho tester

qTrace là một phần mềm miễn phí cho phép bạn chụp lại màn hình và các thao tác của tester trong quá trình kiểm tra, bao gồm các phím được bấm, các nút được click, v.v. Mục tiêu của qTrace là giúp giảm thiểu tối đa thời gian cho các hoạt động “thủ tục” của tester khi phát hiện defect như chụp màn hình, chú thích, nghĩ và viết mô tả các bước làm để reproduce defect. Ngoài ra, với khả năng ghi lại khá chính xác những thao tác mà tester đã thực hiện, qTrace giúp cho tester nhanh chóng tìm ra cách reproduce những defect ít xảy ra mà tester vô tình bắt gặp.

Một điểm mạnh của qTrace chính là giao diện đơn giản, làm một việc duy nhất là ghi lại hoạt động của tester (và làm rất tốt), không có những chức năng linh tinh làm sao nhãng tester.

qTrace lúc chạy:

Untitled5

Và tự động mở rộng khi bạn hover chuột:

Untitled

Để minh họa cho khả năng của qTrace, tôi đã làm theo các bước để reproduce lỗi của Google Chrome Bookmark Manager. Khi kéo thả một bookmark folder vào một folder khác, bạn sẽ thấy cây bên trái không thể hiện cấu trúc folder mới ngay, bạn có thể refresh lại Bookmark Manager để đối chiếu. Đây là kết quả ghi lại của qTrace:

Untitled4

Mỗi bước bên trái sẽ được minh họa bằng hình chụp màn hình với chú thích cụ thể.

chrome bug.5

Nếu cần ghi chú thêm, tester có thể chỉnh sửa vào kết quả mà qTrace tạo ra như thêm chú thích, làm mờ thông tin nhạy cảm, cắt hình, v.v. Những công cụ này được thiết kế cho tester, nên việc sử dụng sẽ nhanh chóng và thuận tiện hơn Paint trong Windows.

Untitled2

Cuối cùng, sau khi đã bổ sung chỉnh sửa theo ý mình, tester có thể submit defect trực tiếp từ qTrace lên các hệ thống tracker phổ biến một cách nhanh gọn—không còn chuyện lưu hình, mở trình duyệt, attach hình, v.v.

Untitled3

Tất nhiên, đây chỉ là những tính năng đơn giản nhất của qTrace. Vẫn còn nhiều tiện ích khác giúp cho tester hoàn thành công việc nhanh chóng. Nếu bạn là tester, tại sao không thử ngay qTrace miễn phí và tự khám phá?

Advertisements

Đừng “hack”

(Bạn có biết máy tính của Lunar Module và Command Module của tàu Apollo chỉ có 36K 16-bit words ROM và 2K 16-bit words RAM.)

Gần đây tôi gặp phải một vấn đề với Dojo trên IE9. Có một chức năng cần phải refresh DataGrid nằm trong một Dialog mỗi khi Dialog đó xuất hiện, nhưng Dialog này lại trống trơn khi chạy trên IE9. Nguyên nhân là vì DataGrid của Dojo sẽ không render đúng khi bị ẩn đi, nên việc refresh DataGrid phải được thực hiện sau khi Dialog đã xuất hiện. Đây không phải là bug, chỉ là cách mà DataGrid hoạt động. Tuy nhiên, có người đã debug và bỏ bớt một đoạn code của DataGrid để nó không gây ra lỗi, mặc dù họ không biết tại sao đoạn mã đó gây lỗi, và nó dùng để làm gì, nên cũng không thể đảm bảo việc này sẽ không gây lỗi ở chỗ khác. Đây không phải là lần đâu tiên tôi bắt gặp một cách “hack” như vậy, và không may nó lại là một trong những hướng giải quyết vấn đề thường gặp. Khi chuyện nảy sinh, đầu tiên lập trình viên sẽ nhìn quanh xem có method hay API nào đó giúp giải quyết khó khăn. Bước hai, họ tìm kiếm nguyên nhân từ các công cụ. Chậm là do đường truyền, tại trình duyệt, lỗi thì do framework, v.v. Bước ba, “đoán” rằng IE, Spring, Dojo, hay một công cụ nào khác là nguyên nhân (công cụ làm sao mà nói được), họ tìm kiếm các phương pháp để “trick” trình duyệt hay framework để che lấp phần hiện tượng của vấn đề, và thế là xong.

Thật ra, phải nói rằng cách giải quyết đã nói ở trên rất thông minh và có thể cho hiệu quả tốt. Tuy nhiên, rắc rối không nằm ở chuyện dùng cách “hack” hay không, mà là ở quan điểm của lập trình viên với những giải pháp kiểu này. Cần nhớ là đây chỉ đơn giản là cách thức cuối cùng, khi không còn con đường nào khác. Có thể nó thể hiện sự thông minh, nhanh trí của một lập trình viên, nhưng hơn hết, nên xem nó như là dấu hiệu cho thấy việc lựa chọn framework không phù hợp, thiết kế chương trình không tối ưu cho platform, hay sự thiếu hiếu biết của lập trình viên về hệ thống v.v. Mặt khác, giải pháp kiểu này sẽ góp phần couple hệ thống vào cơ chế hoạt động bên trong của framework, một runtime hay một phiên bản nào đó của chúng—những thứ vốn có thể thay đổi bất cứ lúc nào. Do vậy, nếu không tổ chức mã nguồn gọn gàng (và theo kinh nghiệm cá nhân thì thường là không) những người đi sau kế thừa tất nhiên sẽ phải rất vất vả nếu cần nắm bắt ý tưởng “sáng tạo” của người đi trước.

Nếu bạn là một người cẩn thận, hãy cố gắng thuyết phục bản thân rằng lỗi là điều bản thân khó tránh khỏi khi viết code. Và khi vấn đề xảy ra, thay vì giành thời gian để chê bai một library hay framework nào đó, hãy dùng nó để xem lại phần code của mình, cách mình hiểu và sử dụng các library hay framework, cũng như cơ chế hoạt động của chúng, để tìm ra một giải pháp gọn đẹp và hiệu quả.