Impact Cross-Browser Testing With Minimum Effort

Cross-browser testing là một công việc tốn thời gian và đòi hỏi chăm chỉ. Dù vậy, các developers thì đều lười làm công việc này, dựa trên nguyên tắc DRY, họ viết ra các script hoặc sử dụng thư viện bên thứ ba để tự động thực hiện những công việc phải làm bằng tay chạy được cho tất cả các browser, điều đó làm chúng ta lười nhưng cũng khiến ta trở thành good developer!

Cách tiếp cận truyền thống của cross-browser testing có lẽ là test trên tất cả các trình duyện chính được sử dụng với người dùng, dần dần từ version cũ đến mới, từ nổi tiếng cho đến ít người sử dụng. Hoặc, nếu thời gian và nhân lực có hạn, chỉ test một vài browser tiêu biểu và hy vọng sự vắng mặt của bug đủ thể hiện cho sự "sạch sẽ" của cả hệ thống. Có thể thấy cách đầu tiên đại diện cho một quy trình "tốt" nhưng thiếu hiệu quả, trong khi cách thứ hai đại diện cho sự "lười biếng" nhưng không đáng tin cậy.

Context

Ở một khía cạnh, đáng để kể ra rằng chúng ta phải làm nhiều thứ hơn là test thủ công trong team. Cross-browser testing không thay thế cho unit test(Jasmine/QUnit), functional tests (Cucumber), thức tế, tự động hóa test tiết kiệm hơn khi chạy trong thời gian dài cũng như là phần thiết yếu khi hệ thống phình to lên. Mặc dù vậy, một số lỗi chỉ xuất hiện trên một số trình duyệt cụ thể và test tự động chắc chắn chưa thể bước chân được vào khu vực của cross-browser testing. Làm sao máy móc có thể biết sự kiện tự động cuộn trang che đi một nửa tiêu đề trên iPhone 4 ? Làm sao nó có thể nhận ra đó là một vấn đề thực sự ? Cho đến khi nào trí thông minh nhân tạo phát triển tới mức để máy tính có thể hiểu ra những gì chúng ta đã làm ra và cũng như có thể đánh giá được nghệ thuật và văn chương con người đang diễn tả, test thủ công vẫn luôn luôn là cần thiết. Tất nhiên, ngoài những thứ bắt buộc cần sự có mặt của con người ra, nhờ vào test tự động, chúng ta vẫn có thể làm cho cross-browser nhàn nhã hơn rất nhiều.

What’s Your Objective?

Có hai mục đích chính của việc thực hiện cross-browser testing:

• Phát hiện ra bug.

• Sanity-testing Kiểm tra tính đúng đắn, đảm bảo đa số người dùng có trải nghiệm sử dụng như mong đợi.

Một mặt, theo W3School, chúng ta có thể kiểm chứng trải nghiệm của ít nhất 50% người dùng thông qua Chrome. Mặt khác, nếu mục tiêu của là tìm ra lỗi, chúng ta cần chạy nó trên những trình duyệt cổ lỗ sĩ vẫn còn được support đến nay như là IE8 và Android Browser 2. Số lượng người dùng của 2 trình duyệt này là cực kỳ ít ỏi (cỡ 1,5%), khiến cho việc kiểm thử trên chúng giảm đi hiệu quả của sanity-testing. Chúng ta muốn đảm bảo số đông người dùng được hài lòng nhưng lại đi test trên trình duyệt mà số ít sử dụng, mặc dù vậy những trình duyệt cổ lỗ sĩ với engine lạc hậu là một thước đo tuyệt vời để đánh giá hệ thống của bạn đã được lập trình tốt như thế nào ?!

Chiến lược kiểm thử truyền thống luôn dành nhiều sự quan tâm và công sức trên các trình duyệt phổ biến. Tuy vậy, nhiều bug lại chỉ được tìm ra trên các trình duyệt ít phổ biến hơn, điều mà mô hình kiểm thử truyền thống không thể phát hiện ra cho đến giai đoạn cuối của việc kiểm thử. Bạn sẽ làm gì khi lâm vào tình huống tiến thoái lưỡng nan, tìm ra bug vào thời điểm muộn màng sau cả một đợt kiểm thử dài hơi ?

• Bỏ qua
• Sửa bug đó và hy vọng không có gì đổ vỡ xảy ra
• Sửa bug và test lại trên tất cả những trình duyệt đã test trước đó

Lựa chọn cuối cùng có lẽ là lý tưởng nhất và cũng là lựa chọn duy nhất để bạn có thể tự tin tuyên bố tất cả các trình duyệt vẫn hoạt động bình thường. Tuy vậy, nó rõ ràng là quá kém hiệu quả và bạn sẽ phải lặp lại cả tá công việc n lần nữa. Chúng ta lại lâm vào một tình cảnh trớ trêu khác, để hiệu quả tối đa, ta cần sửa tất cả các bug trước khi bắt đầu cross-browser testing nhưng chúng ta lại không thể biết bug nào cho đến khi bắt đầu test.

Câu trả lời là hãy thực hiện mục tiêu bug-finding và sanity-checking từng bước theo chiến thuật three-phase attack.

Three-Phase Attack

• Reconnaissance - Thăm dò

  Thực hiện các test thăm dò trên các trình duyệt phổ biến trên máy develop. Cảm nhận nơi bug có thể phát sinh và sửa bất cứ lỗi nào gặp phải.

• Raid - Vây ráp

  Kiểm thử thủ công với một số ít các trình duyệt không phổ biến để tìm bug, tương tự như trên fix on sight.

• Clearance - Dọn sạch

  Sanity checking- kiểm tra tính đúng đắn cho trình duyệt phổ biến nhất mà khác hàng sử dụng để đảm bảo thu được trải nghiệm như mong muốn.

Như có thể thấy, chương trình bắt đầu với khoảng thời gian ít nhất và lớn dần lên theo quá trình tăng trưởng của sự ổn định của hệ thống. Càng nhiều cuộc thăm dò bạn thực hiện - bạn càng có thể định vị được nhiều bug chỉ trong thời gian ngắn. Raid-vây ráp thì mãnh liệt hơn với cường độ cao cũng như tiêu tốn nhiều thời gian nhưng đem lại kết quả đáng giá và sự ổn định rõ ràng cho hệ thống. Giai đoạn cuối là vất vả nhất trong tất cả, nhất là khi mỗi lỗi bất ngờ xuất hiện và có khả năng gây nguy hiểm, sau khi dọn dẹp nó bạn lại thực hiện lại lần nữa để đảm bảo sự "trong sạch" của hệ thống.

Cả 3 giai đoạn trên đáp ứng đủ được hai yêu cầu đề ra ban đầu : tìm bug và sanity checking và sau đó chúng ta có thể tự tin nói rằng hệ thống hoạt động bình thường cho X% người dùng.