initial commit

4 files changed, 640 insertions, 0 deletions

diff --git a/files/vi/learn/tools_and_testing/cross_browser_testing/index.html b/files/vi/learn/tools_and_testing/cross_browser_testing/index.html
new file mode 100644
index 0000000000..b581a119f1
--- /dev/null
+++ b/files/vi/learn/tools_and_testing/cross_browser_testing/index.html
@@ -0,0 +1,33 @@
+---
+title: Kiểm tra trình duyệt chéo
+slug: Learn/Tools_and_testing/Cross_browser_testing
+translation_of: Learn/Tools_and_testing/Cross_browser_testing
+---
+<div>{{LearnSidebar}}</div>
+
+<p class="summary">Mô-đun này tập trung vào kiểm thử các dự án web trên các trình duyệt khác nhau. Chúng tôi xem xét việc xác định đối tượng mục tiêu của bạn (ví dụ: người dùng, trình duyệt và thiết bị nào bạn cần quan tâm nhất?), Cách thực hiện kiểm thử, các vấn đề chính mà bạn sẽ phải đối mặt với các loại mã khác nhau và cách giảm thiểu chúng, những công cụ nào hữu ích nhất trong việc giúp bạn kiểm thử và khắc phục sự cố và cách sử dụng tự động hóa để tăng tốc độ kiểm thử.</p>
+
+<h2 id="Điều_kiện_tiên_quyết">Điều kiện tiên quyết</h2>
+
+<p>Bạn nên thành thạo cốt lõi của các ngôn ngữ <a href="/en-US/docs/Learn/HTML">HTML</a>, <a href="/en-US/docs/Learn/CSS">CSS</a>, và <a href="/en-US/docs/Learn/JavaScript">JavaScript</a> trước khi sử dụng công cụ được liệt kê trong loạt bài viết này.</p>
+
+<h2 id="Hướng_dẫn">Hướng dẫn</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Introduction">Giới thiệu về kiểm thử trình duyệt chéo</a></dt>
+ <dd>Khởi đầu mô-đun bằng cách cung cấp khái quát về vấn đề kiểm thử trình duyệt chéo, trả lời các câu hỏi như là "kiểm thử trình duyệt chéo là gì?", "các sự cố thường gặp như thế nào?", và "các hướng tiếp cận chính để kiểm thử, xác định và sửa chữa các sự cố đó?"</dd>
+ <dt><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies">Chiến lược kiểm thử</a></dt>
+ <dd>Tiếp theo, ta đào sâu vào chiến lược kiểm thử, xác định đối tượng mục tiêu (tức là trình duyệt, thiết bị, và những phân đoạn nào bạn nên kiểm thử kỹ lưỡng), chiến lược kiểm thử low fi (kiếm thật nhiều thiết bị và vài máy ảo, và kiểm thử ad hoc nếu cần), chiếc lược high tech (tự động hoá, sử dụng ứng dụng dành riêng cho việc kiểm thử), và kiểm thử với nhóm người dùng.</dd>
+ <dt><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS">Xử lý sự cố HTML và CSS thường gặp</a></dt>
+ <dd>Sau khi đã nắm bắt được căn bản, ta sẽ đi vào tìm hiểu những sự cố tương thích trình duyệt thường gặp trong các đoạn mã HTML và CSS, và dùng công cụ nào để ngăn chặn sự cố xảy ra, hoặc sửa chữa lỗi lầm hiện hành. Điều này bao gồm phân tích mã nguồn (linting), xử lý tiền tố CSS, dùng công cụ dành cho nhà phát triển của trình duyệt để mò lỗi, dùng polyfill để hỗ trợ thêm cho trình duyệt, xác định vấn đề trong thiết kế linh hoạt, và nhiều hơn nữa.</dd>
+ <dt><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/JavaScript">Xử lý sự cố JavaScript thường gặp</a></dt>
+ <dd>Giờ ta sẽ xem xét tới sự cố tương thích trình duyệt của JavaScript và cách sửa chúng. Điều này bao gồm thông tin về cách dùng công cụ dành cho nhà phát triển của trình duyệt đề mò lỗi và cách sửa chúng, dùng polyfill và thư viện để dựng giải pháp dự phòng, dùng tính năng cao cấp của JavaScript trên các trình duyệt cổ, và hơn thế nữa.</dd>
+ <dt><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility">Xử lý sự cố tiếp cận thường gặp</a></dt>
+ <dd>Tiếp đến ta dành tâm trí cho khả năng tiếp cận, cung cấp thông tin về các sự cố thường gặp, cách kiểm thử đơn giản, và cách dùng công cụ kiểm toán/ tự động hoá để tìm kiếm sự cố tiếp cận.</dd>
+ <dt><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection">Hiện thực bộ nhận diện tính năng</a></dt>
+ <dd>Nhận diện tính năng liên quan tới kiểm tra xem trình duyệt này có hỗ trợ khối lệnh kia hay không, và chạy lệnh khác tuỳ thuộc vào câu trả lời là có hay không, để các trình duyệt luôn hoạt động thay vì oẳng hoặc báo lỗi. Bài viết này hướng dẫn chi tiết bạn cách viết bộ nhận diện tính năng một cách đơn giản, cách dùng thư viện để tăng tốc hiện thực nó, và các tính năng dựng sẵn dành dành cho bộ nhận diện tính năng như <code>@supports</code>.</dd>
+ <dt><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Automated_testing">Tự động hoá kiểm thử</a></dt>
+ <dd>Tiến hành kiểm thử bằng tay trên nhiều trình duyệt và thiết bị, liên tục nhiều ngày, có thể gây ra chán nản và tốn tohừi gian. Để gia tăng hiệu suất kiểm thử, bạn nên làm quen với một vài công cụ tự động. Trong bài viết này, ta sẽ nghiên cứu công cụ nào dùng được, cách chạy công việc, và cơ bản cách dùng ứng dụng kiểm thử tự động thương mại (tốn phí) như Sauce Labs và Browser Stack.</dd>
+ <dt><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Your_own_automation_environment">Cấu hình môi trường kiểm thử tự động của riêng mình</a></dt>
+ <dd>Trong bài viết này, chúng tôi sẽ dạy bạn cách cài đặt môi trường tự động cho riêng mình và chạy test trên Selenium/WebDriver và thư viện kiểm thử như selenium-webdriver cho Node. We will also look at how to integrate your local testing environment with commercial apps like the ones discussed in the previous article.</dd>
+</dl>
diff --git a/files/vi/learn/tools_and_testing/cross_browser_testing/introduction/index.html b/files/vi/learn/tools_and_testing/cross_browser_testing/introduction/index.html
new file mode 100644
index 0000000000..aedc41104b
--- /dev/null
+++ b/files/vi/learn/tools_and_testing/cross_browser_testing/introduction/index.html
@@ -0,0 +1,201 @@
+---
+title: Giới thiệu về kiểm tra trình duyệt chéo
+slug: Learn/Tools_and_testing/Cross_browser_testing/Introduction
+translation_of: Learn/Tools_and_testing/Cross_browser_testing/Introduction
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{NextMenu("Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies", "Learn/Tools_and_testing/Cross_browser_testing")}}</div>
+
+<p class="summary">Bài viết này bắt đầu bằng cách cung cấp tổng quan về chủ đề kiểm thử trình duyệt (chéo), trả lời các câu hỏi như "kiểm thử trình duyệt chéo là gì?", "Loại sự cố phổ biến nhất bạn gặp phải là gì?" Và "các phương pháp chính để thử nghiệm, xác định và khắc phục sự cố là gì?"</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">Điều kiện tiên quyết:</th>
+   <td>Quen thuộc với các các khái niệm cốt lõi của các ngôn ngữ <a href="https://developer.mozilla.org/vi/docs/Learn/HTML">HTML</a>, <a href="https://developer.mozilla.org/vi/docs/Learn/CSS">CSS</a> và <a href="https://developer.mozilla.org/vi/docs/Learn/JavaScript">JavaScript</a>.</td>
+  </tr>
+  <tr>
+   <th scope="row">Mục tiêu:</th>
+   <td>Để hiểu được các khái niệm cấp cao liên quan đến kiểm tra trình duyệt chéo.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Kiểm_thử_trình_duyệt_chéo_là_gì">Kiểm thử trình duyệt chéo là gì?</h2>
+
+<p>Kiểm thử trình duyệt chéo là hoạt động đảm bảo trang web hoặc ứng dụng web của bạn chạy ổn trên một lượng trình duyệt chấp nhận được. Là một nhà phát triển web, bạn không chỉ có trách nhiệm đảm bảo dự án của mình chạy được, mà còn phải chạy được trên mọi trình duyệt, thiết bị hoặc thiết bị hỗ trợ mà người dùng của bạn sử dụng. Bạn cần tính đến các phương án như sau:</p>
+
+<ul>
+ <li>Trình duyệt khác một hoặc hai loại mà bạn thường dùng trên thiết bị của mình, bao gồm cả những trình duyệt hơi cũ một chút - không hỗ trợ tính năng "xịn xò" hoặc mới nhất của CSS hoặc JavaScript - mà một vài người vẫn còn dùng.</li>
+ <li>Thiết bị khác nhau có khả năng khác nhau, từ những dòng tablet và điện thoại thông minh đời mới nhất, hay tivi thông minh, đến những dòng rẻ tiền và cũ kỹ mà chỉ có thể chạy được những trình duyệt có tính năng giới hạn.</li>
+ <li>Người khuyết tật, những người dùng Web với công nghệ hỗ trợ như screenreader (trình đọc màn hình), hoặc không dùng chuột (vài người chỉ dùng bàn phím).</li>
+</ul>
+
+<p>Hãy nhớ bạn không phải người dùng trang web của bạn — web của bạn có thể chạy ngon lành trên Macbook Pro hay dòng Galaxy Nexus cao cấp không có nghĩa là nó sẽ chạy được cho mọi người dùng — bạn còn phải kiểm thử nhiều lắm!</p>
+
+<div class="note">
+<p><strong>Ghi chú</strong>: <a href="https://hacks.mozilla.org/2016/07/make-the-web-work-for-everyone/">Make the web work for everyone</a> đưa ra nhiều góc nhìn dựa trên trình duyệt mà mọi người dùng, thị phần của các trình duyệt, và sự cố tương thích trình duyệt chéo.</p>
+</div>
+
+<p>Ta nên xem xét vài thuật ngữ đã. Trước hết, khi nhắc tới trang web "chạy ổn trên trình duyệt chéo", tức là chúng phải đạt được một lượng trải nghiệm người dùng chấp nhận được trên nhiều trình duyệt khác nhau. Một trang web được xếp vào dạng OK không có nghĩa trải nghiệm đều như nhau trên mọi trình duyệt, mà chỉ cần cho phép truy cập được các chức năng cốt lõi. Trên trình duyệt hiện đại, bạn có thể có đạt được hoạt hoạ (anmiation), 3D và các hiệu ứng chuyên nghiệp, trong khi trên trình duyệt cũ hơn, bạn sẽ chỉ có các mảng tĩnh chứa đầy đủ thông tin cần thiết. Chỉ cần chủ của trang web vui là bạn làm được việc rồi.</p>
+
+<p>Mặt khác, sẽ chẳng OK tẹo nào nếu một trang chỉ chạy ổn với những người bình thường, còn người khuyết tật thì hoàn toàn không thể truy cập được bởi vì trình screen reader của họ không thể đọc được nội dung trên trang web.</p>
+
+<p>Thứ hai, khi nhắc tới "một lượng trình duyệt web chấp nhận được", không có nghĩa hoàn toàn 100% trình duyệt trên toàn thế giới — điều này là bất khả thi. Bạn nên dự đoán trước các trình duyệt và thiết bị mà người dùng trang web sẽ có thể dùng tới (ta sẽ bàn về vấn đề này trong phần thứ hai của loạt bài viết này — mời đọc <a href="https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies#Gotta_test_%27em_all">Gotta test 'em all?</a>), nhưng bạn không thể đảm bảo mọi thhws. Là nhà phát triển web, bạn cần ước lượng một khoảng nhất định trình duyệt và thiết bị chắc chắn chạy được mã bạn viết ra; còn ngoài khoảng đó, bạn phải viết làm sao để cho các trìnhh duyệt khác cũng có thheer sử dụng nội dung của mình. Đây là một trong những thách thức khó nhằn nhất với nhà phát triển web.</p>
+
+<div class="note">
+<p><strong>Ghi chú</strong>: Ta sẽ xem mã nguồn về phần này trong các bài viết sau.</p>
+</div>
+
+<h2 id="Tại_sao_lại_xảy_ra_sự_cố_tương_thích_trình_duyệt_chéo">Tại sao lại xảy ra sự cố tương thích trình duyệt chéo?</h2>
+
+<p>Có nhiều lý do khác nhau giải thích tại sao sự cố tương thích trình duyệt chéo lại xảy ra, trong bài viết này, chúng tôi chủ yếu đề cập những sự cố với hành vi khác nhau trên các trình duyệt / thiết bị / cài đặt duyệt web khác nhau. Before you even get to cross browser issues, you should have already fixed out bugs in your code (see <a href="/en-US/docs/Learn/HTML/Introduction_to_HTML/Debugging_HTML">Gỡ lỗi HTML</a>, <a href="/en-US/docs/Learn/CSS/Introduction_to_CSS/Debugging_CSS">Gỡ lỗi CSS</a>, và <a href="/en-US/docs/Learn/JavaScript/First_steps/What_went_wrong">Sai ở đâu? Khắc phục sự cố JavaScript</a> từ các chủ đề trước đây để nạp lại trí nhớ của bạn).</p>
+
+<p>Sự cố trình duyệt chéo thường xảy ra vì:</p>
+
+<ul>
+ <li>thỉnh thoảng trình duyệt có lỗi, hoặc hiện thực hoá các tính năng theo cách riêng biệt. Trường hợp này giờ đỡ khiếp hơn ngày trước; vào thời kỳ IE4 và Netscape 4 tranh nhhau thị phần mảng trình duyệt trong thập niên 80, các công ty trình duyệt thời đó cố tình cài đặt mọi thứ theo cách riêng biệt để đạt được lợi thế cạnh tranh, điều đó khiến cho các nhà phát triển ứng dụng mệt lử. Trình duyệt hiện nay đã bớt đi các khía cạnh đó, nhưng thi thoảng sự khác biệt và lỗi vẫn phát sinh</li>
+ <li>một số trình duyệt có hỗ trợ tính năng công nghệ theo mức khác nhhau. Điều này là không thể tránh khỏi khi bạn sử dụng công nghệ quá tân tiến mà trình duyệt hiện đại đang chuẩn bị cài đặt chúng, hoặc bạn phải hỗ trợ các trình duyệt cũ kỹ mà chẳng ai thèm phát triển thêm nữa, hay còn gọi là đóng băng (tức là không có thêm cập nhật mới) khá lâu trước cả khi tính năng đó được tạo ra. Chẳng hạn, nếu bạn muốn dùng tính năng tân tiến của JavaScript trong trang web của mình, những tính năng đó có thể sẽ không hoạt động trên trình duyệt cũ. Nếu bạn muốn hỗ trợ các trình duyệt cũ hơn, có lẽ bạn phải dùng đoạn mã khác, hoặc tìm cách dịch ngược đoạn mã của mình thành mã mà trình duyệt đó có thể hiểu được (thông qua các trình biên dịch chéo).</li>
+ <li>một số thiết bị có thể có hạn chế khiến cho trang web chạy chậm, hoặc hiển thị tồi. Chẳng hạn, nếu một web được thiết kế thật đẹp trên PC, chắc chắn người dùng điện thoại sẽ thấy nó nhỏ xíu và khó đọc. Nếu trang của bạn có nhiều hoạt hoạ nặng, chắc hẳn nó sẽ chạy êm ru trên một chiếc tablet cấu hỉnh mạnh, nhưng sẽ chậm chạp và ì achhj trên một thiết bị yếu đuối hơn.</li>
+</ul>
+
+<p>và còn nhiều lý do hơn nữa.</p>
+
+<p>Trong các bài viết tiếp sau này, ta sẽ khám phá thêm các sự cố trình duyệt chéo thường gặp, và tìm giải pháp.</p>
+
+<h2 id="Quy_trình_kiểm_thử_trình_duyệt_chéo">Quy trình kiểm thử trình duyệt chéo</h2>
+
+<p>Mới nghe qua về công việc kiểm thử trình duyệt chéo thì có vẻ đáng sợ vầ tốn thời gian thật, nhưng không hẳn là vậy đâu - bạn chỉ cần lên kế hoạch thật kỹ càng, và đảm bảo bạn thực hiện đủ và đúng chỗ để không bị lạc vào những sự cố khó lường. Nếu bạn làm việc với một dự án lớn, bạn nên kiểm thử định kỳ, để chắc chắn tính năng mới hoạt động với đối tượng mục tiêu của bạn, và những đoạn mã mới thêm không phá huỷ tính năng cũ mà trước đó hoạt động ngon nghẻ.</p>
+
+<p>Nếu bạn để dành kiểm thử tới cuối dự án, lúc này mọi lỗi bạn phát hiện ra đều tốn kém chi phí và thời gian để sửa hơn trong lúc xây dựng.</p>
+
+<p>Quy trình kiểm thử và sửa lỗi cho một dự án có thể được chia làm 4 pha (mỗi người có cách chia khác nhau):</p>
+
+<p><strong>Lên kế hoạchh &gt; Phát triển &gt; Kiểm thử/ khai phá &gt; Sửa lỗi/ lặp lại</strong></p>
+
+<p>Từ bước 2 – 4 sẽ thường được lặp đi lặp lại cho tới khi đã cài đặt hết tất cả mọi thứ. Ta sẽ xem kỹ hơn về từng giai đoạn thuộc quy trình kiểm thử trong các bài viết sau, còn giờ cứ lướt qua từng bước nhé.</p>
+
+<h3 id="Lên_kế_hoạch">Lên kế hoạch</h3>
+
+<p>Trong pha lên kế hoạch, chắc hẳn bạn sẽ gặp mặt chủ của trang/ khách hàng (đây có thể là sếp của bạn, hoặc một người ở đơn vị ngoài thuê bận làm), tại đây bạn sẽ xác định chính xác xem trang web nên trông như thế nào - nội dung và tính năng của trang là gì, trông nó ra làm sao, vân vân. Ngoài ra, bạn sẽ còn muốn biết bạn có bao nhiêu thời gian để thực hiện trang web - hạn cuối của họ là bao giờ, và họ định bỏ bao nhiêu ra để trả cho bạn? Ta sẽ không đi quá chi tiết vào phần này, nhưng sự cố trình duyệt chéo thường có ảnh hưởng quan trọng tới bước lên kế hoạch.</p>
+
+<p>Ngay khi có ý tưởng về các chức năng cần làm, và công nghệ để bạn dựng chúng lên, bạn nên bắt đầu tìm hiểu về đối tượng mục tiêu — trình duyệt hay thiết bị nào sẽ là đối tượng mục tiêu cho trang web của bạn? Có thể khách hàng của bạn đã có dữ liệu về những đối tượng này rồi, thông qua các nghiên cứu của riêng bên họ, như là từ các trang web mà họ đã sở hữu, hoặc từ chính phiên bản cũ của trang web mà bạn đang làm mới. Nếu không có dữ liệu về vấn đề này, bạn có thể dựa trên dữ liệu của một số nguồn khác, như là thông tin của phe đối thủ, hay là vùng đất mà trang web của bạn chuẩn bị hoạt động. Bạn cũng có thể dựa vào trực giác.</p>
+
+<p>Chẳng hạn, bạn chuẩn bị xây dựng một trang thương mại điện tử phục vụ khách hàng ở Bắc Mĩ. Trang web đó nên chạy ổn định trên mọi trình duyệt nổi tiếng cho máy tính cá nhân cũng như thiết bị di động (iOS, Android, Windows phone) — nên bao gồm cả Chrome (và Opera bởi nó dùng cùng engine với Chrome), Firefox, IE/Edge, và Safari. Trang web đó cũng nên có trải nghiệm truy cập chấp nhận được trên IE 8 và 9, và tuân thủ WCAG AA.</p>
+
+<p>Khi nắm được các nền tảng để kiểm thử, bạn nên dành thời gian kiểm tra lại các chức năng cũng như công nghệ bạn định dùng. Chẳng hạn, nếu chủ của trang thương mai điện tử đó muốn có 3D tour sử dụng WebGL cho từng sản phẩm trên trang chi tiết sản phẩm, họ buộc phải chấp nhận rằng tính năng này không thể hoạt động trên IE trước phiên bản 11. Bạn sẽ phải làm thêm phiên bản khác không có tính năng này để hỗ trợ người dùng dùng bản IE cũ hơn.</p>
+
+<p>Bạn nên soạn ra danh sách khoanh vùng sự cố tiềm tàng.</p>
+
+<div class="note">
+<p><strong>Ghi chú</strong>: Bạn có tìm thấy thông tin về hỗ trợ tương thích trình duyệt đối với các công nghệ ngay trên trính trang này - MDN! Ngoài ra bạn cũng nên ghé qua <a href="http://caniuse.com/">caniuse.com</a>, để kiếm thêm thông tin chi tiết hữu ích.</p>
+</div>
+
+<p>Khi đã có đủ thông tin chi tiết rồi, bạn có thể chuyển sang phát triển trang web.</p>
+
+<h3 id="Phát_triển">Phát triển</h3>
+
+<p>Giớ đến pha phát triển trang web. Bạn nên chia nhỏ các phần khác nhau trong trang thành mô-đun, chẳng hạn, bạn nên chia nhỏ các vùng hiển thị trên trang thành - trang chủ, trang chi tiết sản phẩm, giỏ hàng, luồng thanh toán, vân vân. Sau đó bạn cũng có thể chia nhỏ hơn nữa - cài đặt đầu trang, cuối trang, chi tiết sản phẩm, vân vân.</p>
+
+<p>Có nhiều chiến lược phát triển trên trình duyệt chéo, chẳng hạn:</p>
+
+<ul>
+ <li>Đảm bảo mọi chức năng đều hoạt động được trên mọi trình duyệt đối tượng. Để đạt được điều này, bạn có thể sẽ phải viết nhiều dòng mã khác nhau để tái hiện các chức năng đó cho các trình duyệt khác nhau, hoặc dùng {{glossary("Polyfill")}} trên JavaScript hoặc công nghệ khác để hỗ trợ chúng, hoặc dùng thư viện có chức năng tự động hoá công cuộc đó (như Babel) tuỳ thuộc vào trình duyệt mà đối tượng mục tiêu của bạn sử dụng.</li>
+ <li>Chấp nhận rằng có một số thứ không thể hoạt động y hệt nhau trên mọi trình duyệt, và đưa ra giải pháp khác (chấp nhận được) cho trình duyệt không hỗ trợ mọi chức năng. Đôi khi ta không thể tránh khỏi điều này do hạn chế từ phía thiết bị — trải nghiệm thị giác trên màn ảnh rộng ở rạp chiếu phim không thể sánh được với chiếc điện thoại có kích thước màn 4 inch được, không kể cách bạn lập trình trang web của mình..</li>
+ <li>Chấp nhận rằng trang web của bạn sẽ không chạy được trên trình duyệt lâu đời, và bước tiếp. Điều này OK nếu khách hàng của bạn/ người dùng của bạn OK với điều đó.</li>
+</ul>
+
+<p>Thông thường quá trình phát triển của bạn sẽ bao gồm sự kết hợp của cả ba hướng tiếp cận phía trên. Điều quan trọng nhất trong pha này là bạn phải kiểm thử từng phần nhỏ trước khi tải nó lên - đừng để dành kiểm thử đến cuối!</p>
+
+<h3 id="Kiểm_thử_Khai_phá">Kiểm thử/ Khai phá</h3>
+
+<p>Sau mỗi pha phát triển, bạn sẽ cần kiểm thử chức năng mới của mình. Trước hết, bạn nên đảm bảo không có lỗi lớn nào trong mã nguồn cản trở sự hoạt động của chắc năng đó:</p>
+
+<ol>
+ <li>Kiểm thử nó với một vài trình duyệt ổn định nhất trên hệ thống của bạn, như là Firefox, Safari, Chrome, hay IE/Edge.</li>
+ <li>Thử tiếp cận trang của bạn theo cách thủ công hơn, chẳng hạn như chỉ dùng bàn phím, hoặc screen reader để xem liệu nó có thể điều hướng được hay không.</li>
+ <li>Kiểm thử trên thiết bị di động, như Android hoặc iOS.</li>
+</ol>
+
+<p>Tới đây, hãy sửa mọi lỗi lầm mà bạn phát hiện trong đoạn mã nguồn mới.</p>
+
+<p>Kế đến, bạn nên thử mở rộng danh sách trình duyệt cần kiểm thử hướng tới đối tượng mục tiêu của mình và tập trung phát hiện sự cố trình duyệt chéo (để biết thêm chi tiết, đọc trong bài tiếp theo <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies#Gotta_test_%27em_all">xác định đối tượng trình duyệt được sử dụng</a>). Chẳng hạn:</p>
+
+<ul>
+ <li>Kiểm thử thay đổi mới nhất đó trên nhiều trình duyệt hiện đại cho dòng máy tính cá nhân nhất có thể — bao gồm Firefox, Chrome, Opera, IE, Edge, và Safari trên các hệ điều hành máy tính cá nhân (lý tưởng nhất là Mac, Windows, và Linux).</li>
+ <li>Kiểm thử trên các dòng điện thoại thông minh và máy tính bảng thông dụng (tức là iOS Safari trên iPhone/iPad, Chrome và Firefox trên iPhone/iPad/Android),</li>
+ <li>Kiểm thử trên cả các trình duyệt có trong danh sách đối tượng của bạn nữa.</li>
+</ul>
+
+<p>Cách chân tay nhất là tự tay kiểm thử mọi thứ (kéo thêm vài thành viên nữa nếu bạn làm việc trong nhóm). Nếu có thể, bạn nên kiểm thử trên thiết bị thật.</p>
+
+<p>Nếu bạn không có đủ tư liệu để kiểm thử tất cả các trình duyệt, hệ điều hành hay thiết bị phần cứng, bạn cũng có thể thử dùng bộ mô phỏng (mô phỏng một thiết bị bằng phần mềm trên máy tính cá nhân của mình) và máy ảo (phần mềm cho phép bạn mô phỏng hệ điều hành/ phần mềm khác trên máy tính cá nhân của mình). Đây là một trong những quyết định khá là phổ biến, đặc biệt trong một số tình huống - chẳng hạn, Windows không cho phép bạn cài nhiều phiên bản của hệ điều hành trên cùng một máy, vậy thì chỉ còn dựng máy ảo lên thôi.</p>
+
+<p>Ngoài cách đó ra, bạn có thể dùng nhóm người dùng - dùng một nhóm người nằm ngoài đội phát triển của bạn để kiểm thử trang web cho bạn. Nhóm người này có thể là bạn bè hoặc người thân trong gia đình, nhóm các đồng nghiệp khác, một lớp học ở các cơ sở giáo dục, hoặc một chuyên gia kiểm thử, bạn bỏ tiền ra để lấy được kết quả kiểm thử.</p>
+
+<p>Sau cùng, bạn có thể kiểm thử thông minh hơn bằng cách sử dụng công cụ kiểm toán hoặc tự đống hoá; đây là một lựa chọn đáng để lưu tâm khi dự án của bạn phình to lên, do kiểm thử bằng tay thực sự mất kha khá nhiều thì giờ. Bạn có thể tự cấu hình hệ thống kiểm thử tự động (<a href="http://www.seleniumhq.org/">Selenium</a> hiện đang là ứng dụng khá phổ biến phục vụ mục đích này) có thể kiểm thử hoạt động của trang bạn trên nhiều trình duyệt khác nhau, và:</p>
+
+<ul>
+ <li>kiểm tra xem nút bấm trên màn hình có trả về hành vi chuẩn hay không (chẳng hạn, nút bấm đăng nhập), hiển thị kết quả sau mỗi lần kiểm tra</li>
+ <li>chụp lại ảnh màn hình, cho phép bạn kiểm tra xem layout trang có đồng nhất trên mọi trình duyệt hay không.</li>
+</ul>
+
+<p>Nếu muốn, còn nhiều thứ để bạn lựa hơn. Có vài công cụ mất phí như là <a href="https://saucelabs.com/">Sauce Labs</a> và <a href="https://www.browserstack.com/">Browser Stack</a> giúp bạn đạt được mục đích của mình, mà không phải tốn thời gian cấu hình, nếu bạn sẵn sàng bỏ ra chút kinh phí vào công cuộc kiểm thử. Bạn cũng có thể cấu hình môi trường tự động kiểm thử cho mình, và chỉ cho phép kết hợp thay đổi của mình vào kho mã nguồn khi nó vượt qua được bài kiểm tra tương thích.</p>
+
+<h4 id="Kiểm_thử_trên_trình_duyệt_mới_ra_mắt">Kiểm thử trên trình duyệt mới ra mắt</h4>
+
+<p>Việc kiểm thử trên phiên bản mới ra mắt của trình duyệt thường là ý tưởng hay; xem trong đống link sau:</p>
+
+<ul>
+ <li><a href="https://www.mozilla.org/en-US/firefox/developer/">Firefox Developer Edition</a></li>
+ <li><a href="https://insider.windows.com/">Edge Insider Preview</a></li>
+ <li><a href="https://developer.apple.com/safari/technology-preview/">Safari Technology Preview</a></li>
+ <li><a href="https://www.google.com/chrome/browser/canary.html">Chrome Canary</a></li>
+ <li><a href="http://www.opera.com/computer/beta">Opera Developer</a></li>
+</ul>
+
+<p>Bạn nên kiểm thử theo cách này nếu bạn dùng công nghệ mới tinh trong trang web của mình, và bạn muốn kiểm thử với phiên bản mới nhất, hoặc bạn muốn thử xem nhà phát triển của trình duyệt đã sửa cái lỗi bạn tìm thấy trên phiên bản đó hay không.</p>
+
+<h3 id="Sửa_lỗi_Lặp_lại">Sửa lỗi/ Lặp lại</h3>
+
+<p>Khi phát hiện được lỗi, bạn cần thử sửa nó.</p>
+
+<p>Trước hết phải thu hẹp vùng có thể gây lỗi. Ghi lại thật nhiều thông tin từ người báo lỗi cho bạn — nền tảng, thiết bị, trình duyệt, vân vân. Hãy thử lỗi đó với cấu hình tương tự (tức là cùng phiên bản trình duyệt trên nhiều nền tảng khác nhau, hoặc nhiều phiên bản trình duyệt trên cùng một nền tảng) và đánh giá vùng gây lỗi.</p>
+
+<p>Có thể đó không phải lỗi của bạn — nếu có lỗi trên trình duyệt, chỉ còn cách cầu mong nhà phát triển của trình duyệt đó mau chóng sửa lỗi. Lỗi đó cũng có thể đã được sửa rồi — chẳng hạn nếu có một lỗi tồn tại trên Firefox release 49, nhưng không còn gặp lại lỗi đó nữa trên Firefox Nightly (phiên bản 52), thì họ đã sửa nó rồi. Nếu nó vẫn chưa được sửa, bạn sẽ muốn báo lỗi (xem {{anch("Reporting bugs")}}, phía dưới).</p>
+
+<p>Nếu đó là lỗi của bạn, bạn phải sửa nó! Dò nguyên nhân gây lỗi cũng áp dụng chiến lược y như mọi lỗi khi phát triển web (nhắc lại, hãy đọc <a href="/en-US/docs/Learn/HTML/Introduction_to_HTML/Debugging_HTML">Gỡ lỗi HTML</a>, <a href="/en-US/docs/Learn/CSS/Introduction_to_CSS/Debugging_CSS">Gỡ lỗi CSS</a>, và <a href="/en-US/docs/Learn/JavaScript/First_steps/What_went_wrong">Sai ở đâu? Khắc phục sự cố JavaScript</a>). Khi đã xác định được nguyên nhân gây ra lỗi, bạn cần quyết dịnh xem sẽ xử lý thế nào để nó hoạt động được với các trình duyệt sinh ra lỗi này — bạn không thể cứ thể đổi thẳng mã nguồn, bởi điều này có thể khiến nó không chạy được trên các trình duyệt khác. Hướng tiếp cận chung lúc này là sao chép lại mã nguồn và sửa cũng như kiểm thử trên phiên bản mã nguồn đó.</p>
+
+<p>Khi đã sửa được lỗi, bạn nên lặp lại quy trình kiểm thử để đảm bảo chỗ bạn vừa sửa chạy OK, và không gây lỗi tới các phần khác hoặc trên các trình duyệt khác.</p>
+
+<h2 id="Báo_lỗi">Báo lỗi</h2>
+
+<p>Nhắc lại phía trên, nếu bạn phát hiện lỗi trên trình duyệt, bạn nên báo cáo chúng cho nhà phát triển biết:</p>
+
+<ul>
+ <li><a href="https://bugzilla.mozilla.org/">Firefox Bugzilla</a></li>
+ <li><a href="https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/">EdgeHTML issue tracker</a></li>
+ <li><a href="https://bugs.webkit.org/">Safari</a></li>
+ <li><a href="https://bugs.chromium.org/p/chromium/issues/list">Chrome</a></li>
+ <li><a href="https://bugs.opera.com/wizard/desktop">Opera</a></li>
+</ul>
+
+<h2 id="Tóm_tắt">Tóm tắt</h2>
+
+<p>Bài viết này cung cấp cho bạn các lý thuyết quan trọng nhất về kiểm thử trình duyệt chéo. Với đống kiến thức này, giờ bạn đã sẵn sàng học tiếp các chiến lược Kiểm thử trình duyệt chéo.</p>
+
+<p>{{NextMenu("Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies", "Learn/Tools_and_testing/Cross_browser_testing")}}</p>
+
+<h2 id="Trong_loạt_bài_này">Trong loạt bài này</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Introduction">Giới thiệu về kiểm thử trình duyệt chéo</a></li>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies">Strategies for carrying out testing</a></li>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS">Handling common HTML and CSS problems</a></li>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/JavaScript">Handling common JavaScript problems</a></li>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility">Handling common accessibility problems</a></li>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection">Implementing feature detection</a></li>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Automated_testing">Introduction to automated testing</a></li>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Your_own_automation_environment">Setting up your own test automation environment</a></li>
+</ul>
diff --git a/files/vi/learn/tools_and_testing/cross_browser_testing/testing_strategies/index.html b/files/vi/learn/tools_and_testing/cross_browser_testing/testing_strategies/index.html
new file mode 100644
index 0000000000..6fee4b39fa
--- /dev/null
+++ b/files/vi/learn/tools_and_testing/cross_browser_testing/testing_strategies/index.html
@@ -0,0 +1,358 @@
+---
+title: Strategies for carrying out testing
+slug: Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies
+translation_of: Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/Introduction","Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS", "Learn/Tools_and_testing/Cross_browser_testing")}}</div>
+
+<p class="summary">Bài viết này cung cấp khái quát về kiểm thử trình duyệt chéo, trả lời các câu hỏi như là "kiểm thử trình duyệt chéo là gì?", "các sự cố mà bạn sẽ thường gặp?", và "các hướng tiếp cận chính để kiểm thử, xác định và vá lỗi là gì?"</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">Điều kiện tiên quyết:</th>
+   <td>Thành thạo ngôn ngữ <a href="/en-US/docs/Learn/HTML">HTML</a>, <a href="/en-US/docs/Learn/CSS">CSS</a>, và <a href="/en-US/docs/Learn/JavaScript">JavaScript</a>; biết chút về <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Introduction">lý thuyết kiểm thử trình duyệt chéo</a>.</td>
+  </tr>
+  <tr>
+   <th scope="row">Mục tiêu:</th>
+   <td>Hiểu được lý thuyết nâng cao về kiểm thử trình duyệt chéo.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Có_nên_kiểm_thử_tất_tần_tật">Có nên kiểm thử tất tần tật?</h2>
+
+<p>Khi kiểm thử trình duyệt chéo, bạn cần lên một danh sách trình duyệt cần kiểm thử. Bạn sẽ không thể kiểm thử trên mọi trình duyệt và thiết bị mà người dùng sử dụng - bởi lẽ có vô vàn các loại trình duyệt và thiết bị, và phiên bản mới cũng như thiết bị mới được ra mắt liên tục.</p>
+
+<p>Thay vì thế, bạn nên cố gắng đảm bảo trang web của mình sẽ hoạt động trên các trình duyệt và thiết bị mục tiêu, và viết mã một cách phòng thủ để trang web của bạn đạt được sự tương thích mong muốn nhất.</p>
+
+<p>"Viết mã một cách phòng thủ" tức là dựng fallback thông minh để nếu có tính năng hoặc style nào đó không hoạt động trên trình duyệt này, trang web có thể dùng phương thức hoặc thuộc tính cấp thấp hơn để đạt được trải nghiệm người dùng chấp nhận được — chẳng hạn như các thông tin lõi vẫn truy cập được, mặc dù giao diện có thể không đẹp lắm.</p>
+
+<p>Mục đích của chúng ta là dựng biểu đồ thể hiện sự tương thích giữa các trình duyệt/ thiết bị trong lúc bạn kiểm thử. Bạn có thể làm nó phức tạp hay đơn giản tuỳ thích — chẳng hạn, bạn có thể đặt ra các cấp độ hỗ trợ khác nhau, như sau:</p>
+
+<ol>
+ <li>Cấp A: Trình duyệt hiện đại/ phổ biến — Có khả năng. Kiểm thử tất cả và cung cấp đầy đủ tính năng.</li>
+ <li>Cấp B: Trình duyệt cũ/ ít sử dụng — Không đủ khả năng. Kiểm thử, và cung cấp trải nghiệm cơ bản bao gồm truy cập được các thông tin và dịch vụ cốt lõi.</li>
+ <li>Cấp C: Trình duyệt hiếm gặp/ không biết — không kiểm thử, nhưng cho là có khả năng. Chạy được cả trang, chí ít là được với giải pháp dự phòng (fallback) đã được cài trong lúc viết mã nguồn một cách phòng thủ.</li>
+</ol>
+
+<p>Trong phần tiếp theo, ta sẽ dựng biểu đồ tương thích theo mẫu này.</p>
+
+<div class="note">
+<p><strong>Ghi chú</strong>: Yahoo là đơn vị đầu tiên khiến phương pháp tiếp cận này nổi tiếng, với phương pháp <a href="https://github.com/yui/yui3/wiki/Graded-Browser-Support">Graded browser Support</a>.</p>
+</div>
+
+<h3 id="Phán_đoán_có_cơ_sở">Phán đoán có cơ sở</h3>
+
+<p>Có thể gọi đây là "giả định", hoặc "linh cảm". Đây không phải hướng tiếp cận khoa học, chính xác, nhưng là một người có kinh nghiệm trong ngành ứng dụng web, bạn sẽ nắm được vài trình duyệt nên kiểm thử. Điều này có thể tạo thành nền tảng tốt cho biểu đồ tương thích.</p>
+
+<p>Chẳng hạn, nếu bạn sống ở Tây Âu hoặc Bắc Mĩ, bạn sẽ biết có khá nhiều người sử dụng máy bàn(desktop) và máy tính xách tay (laptop) chạy Windows hoặc Mac, với trình duyệt chính là Chrome, Firefox, Safari, IE, và Edge. Bạn nên kiểm thử trên phiên bản mới nhất của 3 trình duyệt đầu tiên, bởi chúng thường được cập nhật liên tục. Với Edge và IE, bạn nên kiểm thử vài phiên bản gần đây; gom tất cả đống trên lại ta sẽ được cấp A.</p>
+
+<div class="note">
+<p><strong>Ghi chú</strong>: Bạn chỉ cài đặt được duy nhất một phiên bản của IE hoặc Edge trên mỗi máy tính, bởi vậy bạn sẽ phải dùng đến máy ảo, hoặc áp dụng chiến lược kiểm thử khác nếu cần. Phần {{anch("Virtual machines")}} tiếp theo sẽ giải thích cặn kẽ hơn.</p>
+</div>
+
+<p>Kha khá nhiều người dùng iOS và Android, nên bạn cũng cần kiểm thử trên phiên bản mới nhất của iOS Safari, vài phiên bản gần đây của stock browser trên Android, và Chrome và Firefox cho iOS và Android. Nếu được, hãy kiểm thử trên cả điện thoại lẫn máy tính bảng (tablet), để đảm bảo thiết kế linh hoạt (responsive design) hoạt động OK.</p>
+
+<p>Bạn cũng nên biết rằng có nhiều người dùng IE 9. Trình duyệt này cũ và yếu đuối hơn, nên hãy xếp nó vào cấp B.</p>
+
+<p>Từ đây ta xây dựng được biểu đồ tương thích như sau:</p>
+
+<ol>
+ <li>Cấp A: Chrome và Firefox cho Windows/Mac, Safari cho Mac, Edge và IE cho Windows (hai phiên bản gần đây nhất của mỗi loại), iOS Safari cho iPhone/iPad, stock browser cho điện thoại/ máy tính bảng chạy Android (hai phiên bản gần đây nhất) on phone/tablet, Chrome và Firefox cho điện thoại/ máy tính bảng chạy Android (hai phiên bản gần nhất)</li>
+ <li>Cấp B: IE 9 cho Windows</li>
+ <li>Cấp C: n/a</li>
+</ol>
+
+<p>Nếu bạn sống ở vùng khác, hoặc đang xây dựng trang web để phục vụ vùng khác (như vùng lãnh thổ khác), thì trình duyệt phổ biến để kiểm thử sẽ khác đi ít nhiều.</p>
+
+<div class="note">
+<p><strong>Ghi chú</strong>: "CEO của công ty tao xài Blackberry, nên bọn tao phải làm web chạy mượt trên đó" cũng là một ý tưởng thuyết phục.</p>
+</div>
+
+<h3 id="Chỉ_số_tương_thích_trình_duyệt">Chỉ số tương thích trình duyệt</h3>
+
+<p>Một trong những tiêu chí để xem xét lựa chọn trình duyệt kiểm thử có thể đưa ra là chỉ số tương thích trình duyệt. Có nhiều trang cung cấp chỉ số này, chẳng hạn:</p>
+
+<ul>
+ <li><a href="https://www.netmarketshare.com/browser-market-share.aspx?qprid=2&amp;qpcustomd=0">Netmarketshare</a></li>
+ <li><a href="http://gs.statcounter.com/">Statcounter</a></li>
+</ul>
+
+<p>Cả hai trang đều lấy dữ liệu ở trung tâm Bắc Mĩ, không hoàn toàn chính xác, nhưng chúng có thể cho bạn biết chút ít về xu hướng hiện hành.</p>
+
+<p>Chẳng hạn, hãy vào <a href="https://www.netmarketshare.com/browser-market-share.aspx?qprid=2&amp;qpcustomd=0">Netmarketshare</a>. Như bạn có thể thấy, Opera được xếp trong danh sách ít nhưng vẫn có người sử dụng, ta nên xếp nó vào cấp C trong biểu đồ tương thích ở trên.</p>
+
+<p>IE8 cũng được xếp vào mục rất ít, nhưng nó cũ và không thể chạy nổi được mấy. Opera Mini cũng vậy, nhưng vẫn đủ khả năng thực thi mã nguồn JavaScript phức tạp trong lúc thời gian chạy, vân vân (xem <a href="https://dev.opera.com/articles/opera-mini-and-javascript/">Opera Mini and JavaScript</a> để biết thêm chi tiết). Ta cũng nên sắp nó vào cấp B.</p>
+
+<h3 id="Phân_tích">Phân tích</h3>
+
+<p>Nguồn dữ liệu chính xác hơn, nếu bạn có thể lấy được, thường tới từ các ứng dụng phân tích như <a href="https://www.google.com/analytics/">Google Analytics</a>. Đây là ứng dụng cung cấp cho bạn chỉ số chính xác về loại trình duyệt mà người dùng sử dụng để truy cập vào trang web của bạn. Tất nhiên, cách này chỉ áp dụng được khi bạn đã có sẵn một trang web đang hoạt động, nên hướng tiếp cận này sẽ không thích hợp với các trang web hoàn toàn mới.</p>
+
+<p>Nhưng lịch sử phân tích có thể cũng hữu dụng để tìm ra chỉ số tương thích cho một trang web mới hoàn toàn, hoặc cho một tính năng sắp sửa được thêm vào trang web đã tồn tại. Những dữ liệu này có độ chính xác cao hơn các chỉ số được tổng hợp toàn cầu như hai trang kể trên.</p>
+
+<p>Ngoài ra, bạn cũng có thể dùng các nền tảng phân tích dữ liệu mã nguồn mở như <a href="http://www.openwebanalytics.com">Open Web Analytics</a> và <a href="https://matomo.org">Matomo</a>. Để sử dụng được chúng, bạn phải tự dựng lên máy chủ của mình (self-host). </p>
+
+<h4 id="Thiết_lập_Google_analytics">Thiết lập Google analytics</h4>
+
+<ol>
+ <li>Trước hết, bạn cần có tài khoản Google. Dùng tài khoản này để đăng nhập vào <a href="https://www.google.com/analytics/">Google Analytics</a>.</li>
+ <li>Chọn tuỳ chọn web <a href="https://analytics.google.com/analytics/web/">Google Analytics</a>, và nhấn vào nút <em>Sign Up</em>.</li>
+ <li>Nhập chi tiết trang web/ ứng dụng của bạn trên trang đăng ký. Form nhập liệu tại đây khá trực quan; trường thông tin quan trọng nhất phải điền đúng là URL của trang Web. Hãy đảm bảo lấy đúng URL gốc.</li>
+ <li>Ngay khi đã nhập xong mọi thứ, nhấn nút <em>Get Tracking ID</em>, rồi chọn tiếp chấp nhận điều khoản dịch vụ.</li>
+ <li>Trang tiếp theo cung cấp cho bạn vài đoạn mã nguồn kèm theo chú giải. Với trang web đơn giản, bạn chỉ cần sao chép đoạn mã nguồn <em>Website tracking</em> và dán nó vào mã nguồn của mọi trang bạn muốn theo dõi bằng Google Analytics. Bạn có thể đặt nó ngay dưới thẻ <code>&lt;/body&gt;</code>, hoặc ở chỗ nào đó để tách biệt so với mã nguồn gốc trên ứng dụng của mình.</li>
+ <li>Tải những thay đổi trên lên kho mã nguồn phát triển của bạn, hoặc bất cứ nơi đâu tuỳ ý.</li>
+</ol>
+
+<p>Vậy là xong! Trang web của bạn giờ đã sẵn sàng để báo cáo dữ liệu phân tích rồi.</p>
+
+<h4 id="Nghiên_cứu_dữ_liệu_phân_tích">Nghiên cứu dữ liệu phân tích</h4>
+
+<p>Giờ hãy quay lại trang chủ của <a href="https://analytics.google.com/analytics/web">Analytics Web</a>, và bắt đầu theo dõi dữ liệu bạn vừa thu thập được trên trang Web của mình (tất nhiên bạn cần dành ra chút thời gian để thu thập dữ liệu.)</p>
+
+<p>Theo mặc định, bạn sẽ thấy một tab báo cáo như sau:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/14081/analytics-reporting.png" style="border-style: solid; border-width: 1px; display: block; height: 386px; margin: 0px auto; width: 700px;"></p>
+
+<p>Như bạn thấy đó, có hàng tá dữ liệu khi dùng Google Analytics — thông báo tuỳ chỉnh theo từng đề mục, vân vân — và ta không có nhiều thời gian để bàn luận về tất cả. <a href="https://support.google.com/analytics/answer/1008015">Getting started with Analytics</a> cung cấp vài chỉ dẫn hữu ích cho người mới khi tương tác với những báo cáo này.</p>
+
+<p>Bạn cũng nên xem xét các tuỳ chọn khác nhau ở phía bên trái, và lọc ra dữ liệu cần dùng. Chẳng hạn, bạn có thể tìm trình duyệt và hệ điều hành mà người dùng sử dụng bằng cách tích chọn <em>Audience &gt; Technology &gt; Browser &amp; OS</em> từ menu bên trái.</p>
+
+<div class="note">
+<p><strong>Ghi chú</strong>: Khi sử dụng Google analytics, bạn cần cẩn trọng trước những dự đoán không rõ ý, chẳng hạn "Chúng ta không có người dùng trên Firefox Mobile" thường khiến bạn không hỗ trợ Firefox mobile nữa. Nhưng bạn sẽ không có người dùng nào trên Firefox Mobile nếu ngay từ đầu trang Web của bạn đã không hoạt động trên đó.</p>
+</div>
+
+<h3 id="Một_vài_đề_xuất_khác">Một vài đề xuất khác</h3>
+
+<p>Bạn cũng nên xem xét một vài khía cách khác. Bạn nên đưa khả năng tiếp cận như là yêu cầu kiểm thử cấp A (chúng tôi sẽ viết rõ hơn về những thứ bạn cần kểm thử trong bài "Xử lý sự cố tiếp cận thường gặp")</p>
+
+<p>Vả lại bạn cũng cần xem xét thêm các yếu tố môi trường. Nếu bạn viết ứng dụng cho mạng Intranet của một công ty nào đó, nhằm dựng biểu đồ thống kê đơn bán lẻ cho quản lý, và tất cả các quản lý đều được phát cho một chiếc điện thoại cài hệ điều hành Windows, lúc này bạn sẽ phải đưa IE vào danh mục hỗ trợ hàng đầu.</p>
+
+<h3 id="Biểu_đồ_tương_thích_bản_cuối">Biểu đồ tương thích bản cuối</h3>
+
+<p>Sau tất cả, biểu đồ tương thích của chúng ta sẽ có dạng như sau:</p>
+
+<ol>
+ <li>Cấp A: Chrome và Firefox cho Windows/Mac, Safari cho Mac, Edge và IE cho Windows (hai phiên bản gần đây nhất cho mỗi loại), iOS Safari cho iPhone/iPad, Android stock browser (hai phiên bản gần đây nhất) cho điện thoại/ máy tính bảng, Chrome và Firefox cho Android (hai phiên bản gần đây nhất) cho điện thoại/ máy tính bảng. Qua được kiểm thử khả năng tiếp cận thông thường.</li>
+ <li>Cấp B: IE 8 và 9 cho Windows, Opera Mini.</li>
+ <li>Cấp C: Opera, và một số trình duyệt hiện đại kém phổ biến khác.</li>
+</ol>
+
+<h2 id="Bạn_định_kiểm_thử_cái_gì">Bạn định kiểm thử cái gì?</h2>
+
+<p>Khi bạn muốn kiểm thử phần mã nguồn mới thêm vào, trước khi bắt đầu tiến hành, bạnn nên lập một danh sách yêu cầu kiểm thử mà buộc phải qua được thì mới được chấp nhận. Những yêu cầu này có thể thuộc chức năng hoặc thẩm mĩ - kết hợp hai yêu cầu này lại sẽ thành một chức năng khả dùng cho trang web của bạn.</p>
+
+<p>Hãy xem xét ví dụ sau (xem <a href="https://github.com/mdn/learning-area/blob/master/tools-testing/cross-browser-testing/strategies/hidden-info-panel.html">mã nguồn</a>, và <a href="http://mdn.github.io/learning-area/tools-testing/cross-browser-testing/strategies/hidden-info-panel.html">bản chạy trực tiếp</a>):</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/14083/sliding-box-demo.png" style="border-style: solid; border-width: 1px; display: block; height: 455px; margin: 0px auto; width: 700px;"></p>
+
+<p>Các hạng mục kiểm thử cho ví dụ này được trình bày như sau:</p>
+
+<p>Cấp A và B:</p>
+
+<ul>
+ <li>Các nút nên được kích hoạt bằng cơ chế kiểm soát chính của người dùng - bao gồm chuột, bàn phím và touch.</li>
+ <li>Các nút đảo chiều (toggle) nên ẩn/hiện hộp thoại thông tin.</li>
+ <li>Văn bản nên đọc được.</li>
+ <li>Người dùng khiếm thị khi dùng trình đọc màn hình (screenreader) nên tiếp cận được văn bản.</li>
+</ul>
+
+<p>Cấp A:</p>
+
+<ul>
+ <li>Hộp thoại văn bản nên ẩn/hiện mượt mà.</li>
+ <li>Nên có vùng chuyển màu (gradient) và bóng chữ (shadow) để tăng cường vẻ ngoài cho các khối.</li>
+</ul>
+
+<p>Nếu để ý, bạn sẽ thấy văn bản trong ví dụ không chạy được trên IE8 — sự cố này đã được liệt kê trong bảng tương thích của chúng ta, mà bạn sẽ phải làm theo, có lẽ bạn sẽ phải dùng thư viện nhận diện tính năng để cài đặt lại tính năng đó sao cho phù hợp với các trình duyệt không hỗ trợ CSS transition (xem Hiện thực bộ nhận diện tính năng ở bài viết sau).</p>
+
+<p>Chắc bạn cũng ddể ý rằng nút bấm không dùng được nếu chỉ sử dụng bàn phím - điều này cũng phải xem xét lại. Có lẽ ta nên dùng vài dòng lệnh JavaScript để cho phép bàn phím kiểm soát hoạt động của nút đảo chiều, hoặc dùng phương thức khác thay thế luôn?</p>
+
+<p>Các thông số kiểm thử này rất hữu dụng, vì:</p>
+
+<ul>
+ <li>Chúng cung cấp tập các bước để kiểm thử ứng dụng của bạn.</li>
+ <li>Chúng cũng có thể dễ dàng chuyển đổi thành tập các lệnh cho nhóm người dùng để kiểm thử (chẳng hạn "thử dùng chuột bật nút lên, và rồi thử dùng bàn phím...") — xem {{anch("User testing")}} phía dưới.</li>
+ <li>Chúng cũng có thể cung cấp nền tảng để viết ca kiểm thử tự động. Nếu biết mình muốn kiểm thử cái gì thì sẽ dễ viết các ca kiểm thử hơn cũng như nắm được điều kiện kiểm thử thành công (mời đọc Tự động hoá kiểm thử ở các bài viết sau).</li>
+</ul>
+
+<h2 id="Xây_dựng_phòng_thí_nghiệm_kiểm_thử">Xây dựng phòng thí nghiệm kiểm thử</h2>
+
+<p>Một trong các phương thức tiếp cận kiểm thử là tự kiểm thử bằng tay. Để làm được việc này, bạn sẽ phải kết hợp giữa kiểm thử trên một số thiết bị vật lý thực, và trên môi trường ảo hoá (dùng cả bộ giả lập cũng như máy ảo).</p>
+
+<h3 id="Thiết_bị_vật_lý">Thiết bị vật lý</h3>
+
+<p>Việc kiểm thử trên thiết bị thật chạy trình duyệt thường tốt hơn bao giờ hết, việc này cho ra kết quả chính xác nhất thoả mãn các hành vi cũng như trải nghiệm của người dùng. Để phục vụ một phòng thí nghiệm cỡ nhỏ, bạn sẽ cần những thiết bị sau đây:</p>
+
+<ul>
+ <li>Một máy tính Mac, bao gồm trình duyệt cần kiểm thử — có thể bao gồm Firefox, Chrome, Opera, và Safari.</li>
+ <li>Một máy tính cá nhân chạy Windows, bao gồm trình duyệt cần kiểm thử — có thể bao gồm Edge (hoặc IE), Chrome, Firefox, và Opera.</li>
+ <li>Điện thoại hoặc máy tính bảng tầm cao chạy Android kèm trình duyệt cần kiểm thử — có thể bao gồm Chrome, Firefox, và Opera Mini cho Android, cùng với trình duyệt dựng sẵn trên dành riêng cho Android.</li>
+ <li>Điện thoại hoặc máy tính bảng tầm cao chạy iOS kèm trình duyệt cần kiểm thử — có thể bao gồm iOS Safari, and Chrome, Firefox, và Opera Mini cho iOS.</li>
+</ul>
+
+<p>Nếu có thể thì bạn nên đầu tư thêm:</p>
+
+<ul>
+ <li>Máy tính cá nhân chạy Linux, nếu bạn cần kiểm thử các lỗi cho từng phiên bản trình duyệt trên Linux. Người dùng Linux thường dùng Firefox, Opera, và Chrome. Nếu chỉ có một máy tính, bạn có thể tìm cách cài đặt song song Linux và Windows trên hai phân vùng tách biệt. Nếu tiếp cận theo hướng này thì nên cài Ubuntu; đọc <a href="https://help.ubuntu.com/community/WindowsDualBoot">WindowsDualBoot</a> để biết thêm chi tiết.</li>
+ <li>Vài thiết bị di động tầm thấp để kiểm thử khả năng chạy hình hoạ trên vi xử lý yếu.</li>
+</ul>
+
+<p>Máy tính chính của bạn cũng có thể dùng làm chỗ cài đặt một số công cụ chuyên biệt, như công cụ kiểm toán khả năng tiếp cận, bộ đọc màn hình, và máy ảo/giả lập.</p>
+
+<p>Đối với các công ty lớn, phòng thí nghiệm của họ có nhiều loại thiết bị thuộc nhiều mẫu mã khác nhau, cho phép nhà phát triển tìm diệt lỗi trên các trình duyệt và thiết bị chuyên biệt. Các công ty nhỏ và các cá nhân thường không đủ vốn để đua theo nên họ thường sử dụng máy ảo, các bộ giả lập và các ứng dụng kiểm thử thương mại.</p>
+
+<p>Ta sẽ đi sơ qua từng lựa chọn này phía dưới.</p>
+
+<div class="note">
+<p><strong>Ghi chú</strong>:  Some efforts have been made to create publically accessible device labs — see <a href="https://opendevicelab.com/">Open Device Labs</a>.</p>
+</div>
+
+<div class="note">
+<p><strong>Ghi chú</strong>: Ta cũng phải xem xét khả năng tiếp cận - có khá nhiều công cụ hữu dụng mà bạn có thể cài đặt lên máy của mình phục vụ cho quá trình kiểm thử khả năng tiếp cận, nhưng ta sẽ bàn về chúng trong bài viết "Xử lý sự cố tiếp cận thường gặp", trong loạt bài này.</p>
+</div>
+
+<h3 id="Giả_lập">Giả lập</h3>
+
+<p>Giả lập là phần mềm chạy trong máy tính của bạn và giả lập một thiết bị nào đó, cho phép bạn thoải mái kiểm thử thay vì phải tìm chính xác phần cứng/ phần mềm tương ứng.</p>
+
+<p>Giả lập thường dùng để kiểm thử trạng thái của thiết bị. Chẳng hạn, nếu bạn muốn kiểm tra nhanh chiều dài và bề rộng của thiết bị có phù hợp với thiết kế linh hoạt (responsive design) của mình hay không, bạn có thể dùng <a href="/en-US/docs/Tools/Responsive_Design_Mode">Responsive Design Mode</a> của Firefox. Safari cũng có chế độ tương tự, mà ta có thể dùng tới bằng cách vào <em>Safari &gt; Preferences</em>, và chọn <em>Show Develop menu</em>, rồi chọn <em>Develop &gt; Enter Responsive Design Mode</em>. Chrome cũng có chế độ tương tự: Device mode (xem <a href="https://developers.google.com/web/tools/chrome-devtools/device-mode/">Simulate Mobile Devices with Device Mode</a>). </p>
+
+<p>Bạn sẽ phải cài đặt vài bộ giả lập. Các trình duyệt/ thiết bị bạn sẽ thường muốn kiểm thử như sau:</p>
+
+<ul>
+ <li>Nền tảng lập trình ứng dụng android, <a href="https://developer.android.com/studio/">Android Studio IDE</a>, hơi nặng nếu chỉ dùng để kiểm thử trang web chạy trên Google Chrome hoặc trình duyệt Stock Android, nhưng nó có <a href="https://developer.android.com/studio/run/emulator.html">bộ giả lập</a> tương đối mạnh mẽ. Nếu bạn muốn dùng gì đấy nhẹ hơn, <a href="http://leapdroid.com/">LeapDroid</a> là lựa chọn tốt cho Windows, và <a href="http://www.andyroid.net/">Andy</a> thích hợp để chạy cho cả Windows và Mac.</li>
+ <li>Apple còn sản xuất ứng dụng tên là <a href="https://developer.apple.com/library/content/documentation/IDEs/Conceptual/iOS_Simulator_Guide/Introduction/Introduction.html">Simulator</a> chạy trên môi trường phát triển <a href="https://developer.apple.com/xcode/">XCode</a>, và giả lập iPad/iPhone/Apple Watch/Apple TV. Các máy giả lập đã bao gồm cả trình duyệt iOS Safari. Tuy nhiên, ứng dụng này chỉ chạy trên Mac.</li>
+</ul>
+
+<p>Bạn cũng có thể dùng bộ giả lập cho môi trường thiết bị di động khác như:</p>
+
+<ul>
+ <li><a href="https://developer.blackberry.com/develop/simulator/">Blackberry</a> (bộ giả lập cho Windows, Mac OSX và Linux).</li>
+ <li>Bạn có thể giả lập <a href="https://dev.opera.com/articles/installing-opera-mini-on-your-computer/">Opera Mini</a> trên chính nó để kiểm thử.</li>
+ <li>Hệ điều hành Windows Mobile cũng có bộ giả lập: xem <a href="https://msdn.microsoft.com/en-us/library/windows/apps/ff402563(v=vs.105).aspx">Windows Phone Emulator for Windows Phone 8</a> và <a href="https://msdn.microsoft.com/en-us/windows/uwp/debug-test-perf/test-with-the-emulator">Test with the Microsoft Emulator for Windows 10 Mobile</a> (các bộ giả lập này chỉ chạy trên Windows).</li>
+</ul>
+
+<div class="note">
+<p><strong>Ghi chú</strong>: Một số bộ giả lập đòi hỏi phải chạy máy ảo (xem bên dưới); thường sẽ có hướng dẫn đi kèm về cách cài đặt và sử dụng máy ảo để giả lập.</p>
+</div>
+
+<h3 id="Máy_ảo">Máy ảo</h3>
+
+<p>Máy ảo là ứng dụng chạy trên máy tính cá nhân và cho phép bạn chạy giả lập của toàn bộ hệ điều hành, mỗi máy ảo được ngăn cách trên chính ổ cứng ảo của nó (thường biểu diễn dưới dạng một tệp tin lớn trên ổ cứng của máy thật). Có khá nhiều ứng dụng chạy máy ảo nổi tiếng, như là <a href="www.parallels.com/">Parallels</a>, <a href="http://www.vmware.com/">VMWare</a>, và <a href="https://www.virtualbox.org/wiki/Downloads">Virtual Box</a>; cá nhân người viết bài thích Virtual Box hơn vì nó miễn phí.</p>
+
+<div class="note">
+<p><strong>Ghi chú</strong>: Bạn cần rất nhiều dung lượng ổ cứng để chạy máy ảo; mỗi hệ điều hành mà bạn giả lập lên đều ngốn khá nhiều bộ nhớ. Tất nhiên, bạn được chọn dung lượng ổ cứng cài đặt cho máy ảo; có thể chỉ giới hạn 10GB thôi, nhưng một số hệ điều hành đòi hỏi phải có ít nhất 50GB mới chạy ổn định được. Một trong những lựa chọn tối ưu cho hầu hết ứng dụng máy ảo là tạo ổ cứng <strong>cấp phát động</strong> tự tăng/giảm dung lượng khi cần.</p>
+</div>
+
+<p>Để dùng Virtual Box, bạn cần:</p>
+
+<ol>
+ <li>Kiếm bộ cài hoặc ảnh (tức là tệp ISO) chứa hệ điều hành bạn muốn giả lập. Virtual Box không tự cung cấp những tệp tin này; hầu hết các hệ điều hành, như Windows, là sản phẩm thương mại hoá nên không thể phân phối tự do.</li>
+ <li><a href="https://www.virtualbox.org/wiki/Downloads">Tải bộ cài đặt thích hợp</a> cho hệ điều hành trên máy thật và cài đặt nó.</li>
+ <li>Mở ứng dụng lên; giao diện hiện ra như hình: <img alt="" src="https://mdn.mozillademos.org/files/14089/virtualbox.png" style="display: block; height: 512px; margin: 0px auto; width: 700px;"></li>
+ <li>Để tạo máy ảo mới, nhấn nút <em>New</em> ở góc trên cùng bên trái.</li>
+ <li>Làm theo hướng dẫn và điền vào hộp thoại các thông tin như:
+  <ol>
+   <li>Tên cho máy ảo mới</li>
+   <li>Chọn hệ điều hành và phiên bản muốn cài đặt</li>
+   <li>Đặt giới hạn RAM (chúng tôi đè nghị 2048MB, hoặc 2GB)</li>
+   <li>Tạo ổ cứng ảo (giữ nguyên lựa chọn mặc định trong hộp thoại chứa <em>Create a virtual hard disk now</em>, <em>VDI (virtual disk image)</em>, và <em>Dynamically allocated</em>).</li>
+   <li>Chọn đường dẫn đến tệp tin và kích thước của ổ cứng ảo (chọn tên và nơi chứa dễ nhớ, nơi chứa nên có đủ không gian nhớ sao cho thích hợp với yêu cầu, ít nhất 50GB).</li>
+  </ol>
+ </li>
+</ol>
+
+<p>Lúc này, virtual box sẽ hiện ra trên thanh công cụ bên trái của giao diện Virtual Box. Giờ bạn có thể nhấp đúp chuột vào virtual box — nó sẽ khởi động máy ảo lên, nhưng chưa có hệ điều hành đâu nhé. Bạn phải chọn ảnh/bộ cài của hệ điều hành và virtual box sẽ chạy từng bước cài đặt lên máy ảo, như thể đang cài đặt trên máy thật.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/14085/virtualbox-installer.png" style="display: block; margin: 0 auto;"></p>
+
+<div class="warning">
+<p><strong>Lưu ý</strong>: Bạn cần xác định rõ hệ điều hành bạn muốn cài lên máy ảo vào lúc này. Nếu bạn huỷ tiến trình vào lúc này, nó sẽ khiến máy ảo không dùng được, và bạn sẽ phải xoá máy ảo đi và tạo lại mới. Việc này tuy không ảnh hưởng gì nghiêm trọng nhưng gây ra khó chịu.</p>
+</div>
+
+<p>Sau khi tiến trình chạy xong, bạn sẽ một máy ảo chạy hệ điều hành trên máy thật.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/14087/virtualbox-running.png" style="display: block; margin: 0 auto;"></p>
+
+<p>Hãy dùng hệ điều hành ảo như thể dùng hệ điều hành thực - ví dụ, cài đặt trình duyệt bạn muốn kiểm thử vào, cài đặt phần mềm diệt vi-rut để bảo vệ nó.</p>
+
+<p>Có nhiều máy ảo cùng lúc cũng cực kỳ tiện, chẳng hạn bạn muốn kiểm thử Windows IE/Edge — trên Windows, bạn không thể cài đặt cùng lúc nhiều phiên bản của trình duyệt này, nên bạn sẽ phải dựng một bộ máy ảo để thử nghiệm từng chức năng trên các phiên bản khác nhau, như là:</p>
+
+<ul>
+ <li>Windows 10 với Edge 14</li>
+ <li>Windows 10 với Edge 13</li>
+ <li>Windows 8.1 với IE11</li>
+ <li>Windows 8 với IE10</li>
+ <li>Windows 7 với IE9</li>
+ <li>Windows XP với IE8</li>
+ <li>Windows XP với IE7</li>
+ <li>Windows XP với IE6</li>
+</ul>
+
+<div class="note">
+<p><strong>Ghi chú</strong>: Một ưu điểm nữa của máy ảo là ổ cứng ảo khá là độc lập. Nếu bạn làm việc trong một đội, bạn có thể tạo ra một ổ cứng ảo, rồi sao chép nó đi khắp nơi. Nếu hệ điều hành cài trên máy ảo là sản phẩm có giấy phép thì bạn phải đảm bảo cung cấp đầy đủ giấy phép cho từng máy ảo.</p>
+</div>
+
+<h3 id="Ứng_dụng_tự_động_và_thương_mại_hoá">Ứng dụng tự động và thương mại hoá</h3>
+
+<p>Như đã đề cập ở chương trước, bạn sẽ bớt lo ngại khi kiểm thử trình duyệt bằng cách dùng một số hệ thôgns tự động. Bạn có thể tự thiết lập chúng (một trong số những ứng dụng nổi tiếng nhất là <a href="http://www.seleniumhq.org/">Selenium</a>), tuy cũng tốn chút công sức, nhưng kết quả đổi lại rất đáng.</p>
+
+<p>Ngoài ra, bạn có thể dùng các ứng dụng thương mại hoá như <a href="https://saucelabs.com/">Sauce Labs</a>, <a href="https://www.browserstack.com/">Browser Stack</a> và <a href="https://www.lambdatest.com/">LambdaTest </a>sẽ thiết lập giúp bạn nếu bạn sẵn sàng chịu đầu tư để kiểm thử.</p>
+
+<p>Ta sẽ đi vào chi tiết cách dùng các công cụ này ở bài tương ứng.</p>
+
+<h2 id="Kiểm_thử_phía_người_dùng">Kiểm thử phía người dùng</h2>
+
+<p>Trước khi sang bài mới, ta sẽ tìm hiểu sơ qua về kiểm thử phía người dùng — đây có thể là lựa chọn tốt nếu bạn có một nhóm người dùng sẵn sàng kiểm thử tính năng mới cho mình. Việc lựa chọn người dùng tham gia kiểm thử hoàn toàn tuỳ theo ý bạn - có thể là một nhóm bạn, nhóm đồng nghiệp, hoặc nhóm tình nguyện viên có phí hoặc miễn phí, tuỳ theo lượng tiền bạn có thể chi trả.</p>
+
+<p>Thông thường bạn sẽ cho người dùng xem trang hoặc một đoạn chứa chức năng mới trên máy chủ phát triển, để thay đổi không tác động đến phiên bản ứng dụng chính của bạn. Bạn nên bắt họ kiểm thử theo từng bước và báo cáo lại kết quả họ nhận được. Sẽ tiện hơn nếu bạn có sẵn một tập các bước (đôi khi gọi là kịch bản) để kết quả kiểm thử gần hơn với cái bạn muốn kiểm thử. Ta vừa đề cập tới điều này ở mục {{anch("What are you going to test")}} phía trên. Chẳng hạn, các bước sau phù hợp với một người dùng có thị giác:</p>
+
+<ul>
+ <li>Nhấp chuột vào nút có dấu hỏi trên màn hình máy tính cá nhân của bạn vài lần. Tải lại trang.</li>
+ <li>Chọn và kích hoạt nút có dấu hỏi bằng bàn phím trên máy tính cá nhân của bạn vài lần.</li>
+ <li>Chạm vào nút có dấu hỏi vài lần trên thiết bị có màn hình cảm ứng của bạn.</li>
+ <li>Các nút công tắc sẽ làm hộp thoại thông tin ẩn/hiện. Nút đó có hoạt động hay không?</li>
+ <li>Nội dung văn bản có đọc được không?</li>
+ <li>Hộp thoại thông tin có ẩn hiện mượt mà không?</li>
+</ul>
+
+<p>Trong lúc kiểm thử, cũng nên làm (nếu điều kiện cho phép) các việc như:</p>
+
+<ul>
+ <li>Thiết lập hồ sơ trình duyệt riêng rẽ, tức là tắt bỏ mọi trình mở rộng của trình duyệt và các thứ tương tự, và chạy kiểm thử trên hồ sơ này (chẳng hạn <a href="https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles">Use the Profile Manager to create and remove Firefox profiles</a> và <a href="https://support.google.com/chrome/answer/2364824">Share Chrome with others or add personas</a>).</li>
+ <li>Dùng chế độ riêng tư của trình duyệt, nếu được (như là <a href="https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history">Private Browsing</a> trên Firefox, <a href="https://support.google.com/chrome/answer/95464">Incognito Mode</a> trên Chrome) để không lưu lại cookie hay bộ nhớ tạm.</li>
+</ul>
+
+<p>Việc thực hiện các bước trên nhằm đảm bảo sự "thuần khiết" cho trình duyệt, tức là không có bất cứ thứ gì ảnh hưởng tới kết quả của việc kiểm thử.</p>
+
+<div class="note">
+<p><strong>Ghi chú</strong>: Nếu bạn có điều kiện về phần cứng, bạn nên thử chạy ứng dụng của mình trên các thiết bị di động tầm thấp — bởi vì khi ứng dụng càng phát triển, càng có nhiều tính năng và các hiệu ứng, thì khả năng ứng dụng bạn chạy chậm hơn trên các thiết bị này càng cao hơn, bởi vậy bạn cũng phải suy tính tới hiệu năng của ứng dụng nhiều hơn. Vả lại, nếu các tính năng của bạn chạy ổn trên thiết bị tầm thấp, thì trải nghiệm người dùng chắc chắn sẽ khá hơn trên các thiết bị cao cấp hơn.</p>
+</div>
+
+<div class="note">
+<p><strong>Ghí chú</strong>: Một số môi trường phát triển phía-máy-chủ cung cấp cơ chế thiết lập thay đổi cho một tập người dùng nhất định, đảm bảo tập người dùng đó có thể kiểm thử các tính năng mới mà không ảnh hưởng tới các máy chủ khác. Chẳng hạn như <a href="https://github.com/jsocol/django-waffle">Django Waffle Flags</a>.</p>
+</div>
+
+<h2 id="Tóm_lại">Tóm lại</h2>
+
+<p>Sau khi đọc bài viết này, giờ bạn đã nắm chắc ý tưởng để xác định danh sách khách hàng mục tiêu/ trình duyệt mục tiêu, và tiến hành kiểm thử chéo trên danh sách này sao cho hiệu quả.</p>
+
+<p>Next we'll turn our attention to the actual code issues your testing might uncover, starting with HTML and CSS.</p>
+
+<p>{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/Introduction","Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS", "Learn/Tools_and_testing/Cross_browser_testing")}}</p>
+
+<h2 id="Trong_loạt_bài_viết_này">Trong loạt bài viết này</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Introduction">Giới thiệu về kiểm thử trình duyệt chéo</a></li>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies">Chiến lược kiểm thử</a></li>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS">Xử lý sự cố HTML và CSS thường gặp</a></li>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/JavaScript">Xử lý sự cố JavaScript thường gặp</a></li>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility">Xử lý sự cố tiếp cận thường gặp</a></li>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection">Hiện thực bộ nhận diện tính năng</a></li>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Automated_testing">Tự động hoá kiểm thử</a></li>
+ <li><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Your_own_automation_environment">Cấu hình môi trường kiểm thử tự động của riêng mình</a></li>
+</ul>
diff --git a/files/vi/learn/tools_and_testing/index.html b/files/vi/learn/tools_and_testing/index.html
new file mode 100644
index 0000000000..a032697166
--- /dev/null
+++ b/files/vi/learn/tools_and_testing/index.html
@@ -0,0 +1,48 @@
+---
+title: Tools and testing
+slug: Learn/Tools_and_testing
+tags:
+  - Accessibility
+  - Automation
+  - Beginner
+  - CSS
+  - CodingScripting
+  - HTML
+  - JavaScript
+  - Landing
+  - Learn
+  - NeedsTranslation
+  - Testing
+  - Tools
+  - Topic
+  - TopicStub
+  - cross browser
+  - user testing
+translation_of: Learn/Tools_and_testing
+---
+<div>{{LearnSidebar}}</div>
+
+<p class="summary">Once you've started to become comfortable programming with core web technologies (like HTML, CSS, and JavaScript), and you start to get more experience, read more resources, and learn more tips and tricks, you'll start to come across all kind of tools, from ready-rolled CSS and JavaScript, to testing and automation apps, and more besides. As your web projects become larger and more complex, you'll want to start taking advantage of some of these tools, and working out reliable testing plans for your code. This part of the learning area aims to give you what you need get started and make informed choices.</p>
+
+<p>The web industry is an exciting place to work, but it is not without its complications. The core technologies we use to build web sites are fairly stable now, but new features are being added all the time, and new tools — that facilitate working with, and are built on top of these technologies — are constantly appearing. On top of that, we still need to keep cross-browser support in the forefront of our minds, and make sure that our code follows best practices that allow our projects to work across different browsers and devices that our users are using to browse the Web, and be usable by people with disabilities.</p>
+
+<p>Working out what tools you should be using can be a difficult process, so we have written this set of articles to inform you of what types of tool are available, what they can do for you, and how to make use of the current industry favourites.</p>
+
+<div class="note">
+<p><strong>Note</strong>: Because new tools appear and old ones go out of fashion all the time, we have deliberately written this material to be as neutral as possible — we want to focus first and foremost on the general types of tasks these tools will help you accomplish, and keep prescribing specific tools to a minimum. We obviously need to show tool usage to demonstrate specific techniques, but be clear that we do not necessarily recommend these tools as the best or only way to do things — in most cases there are other ways, but we want to provide you with a clear methodology that works.</p>
+</div>
+
+<h2 id="Learning_pathway">Learning pathway</h2>
+
+<p>You should really learn the basics of the core <a href="/en-US/docs/Learn/HTML">HTML</a>, <a href="/en-US/docs/Learn/CSS">CSS</a>, and <a href="/en-US/docs/Learn/JavaScript">JavaScript</a> languages first before attempting to use the tools detailed here. For example, you'll need to know the fundamentals of these languages before you start debugging problems in complex web code, or making effective use of JavaScript libraries, or writing tests and running them against your code using test runners, etc.</p>
+
+<p>You need a solid foundation first.</p>
+
+<h2 id="Modules">Modules</h2>
+
+<dl>
+ <dt>Real world web development tools (TBD)</dt>
+ <dd>In this module, we explore the different kinds of web development tools available. This includes reviewing the most common kinds of tasks you may be called on to solve, how they can fit together in a workflow, and the best tools currently avaiable for carrying out those tasks.</dd>
+ <dt><a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing">Cross browser testing</a></dt>
+ <dd>This module looks specifically at the area of testing web projects across different browsers. Here we look identifying your target audience (e.g. what users, browsers and devices do you most need to worry about?), how to go about doing testing, the main issues that you'll face with different types of code and how to fix/mitigate those, what tools are most useful in helping you test and fix problems, and how to use automation to speed up testing.</dd>
+</dl>