Kiểm thử Trợ năng cho các Ứng dụng Toàn diện

Giới thiệu: Trợ năng là Gì và Tại Sao Nó Quan Trọng Với Kỹ sư QA?

Chào mừng các bạn đến với một bài viết mới trong chuỗi “Lộ trình học Kỹ sư QA (Tester)“. Sau khi chúng ta đã tìm hiểu về Đảm bảo Chất lượng, phát triển Tư duy QA, các loại kiểm thử cơ bản như Black Box, White Box, Gray Box, và cả các mô hình SDLC phổ biến cùng vai trò của QA trong Agile, hôm nay chúng ta sẽ đi sâu vào một khía cạnh ngày càng quan trọng: Kiểm thử Trợ năng (Accessibility Testing).

Trong thế giới kỹ thuật số hiện đại, mục tiêu của chúng ta không chỉ là tạo ra các ứng dụng hoạt động đúng chức năng (Kiểm thử Chức năng) hay có hiệu năng tốt (Kiểm thử Hiệu năng). Chúng ta còn phải đảm bảo rằng các ứng dụng đó có thể tiếp cận và sử dụng được bởi tất cả mọi người, bao gồm cả những người khuyết tật.

Trợ năng (Accessibility – A11y, viết tắt vì có 11 ký tự giữa A và y) là việc thiết kế và phát triển sản phẩm, thiết bị, dịch vụ hoặc môi trường dành cho mọi người, không phân biệt khả năng. Trong lĩnh vực phần mềm, kiểm thử trợ năng tập trung vào việc đánh giá xem ứng dụng của bạn có thể được sử dụng bởi những người có các loại khuyết tật khác nhau hay không. Điều này bao gồm nhưng không giới hạn ở:

• Người khiếm thị hoặc thị lực kém (sử dụng trình đọc màn hình, phóng to, độ tương phản cao).
• Người khiếm thính hoặc khó nghe (cần phụ đề, phiên âm).
• Người khuyết tật vận động (sử dụng bàn phím thay vì chuột, công tắc chuyển đổi).
• Người khuyết tật nhận thức hoặc học tập (cần giao diện đơn giản, ngôn ngữ rõ ràng, điều hướng nhất quán).
• Người khuyết tật lời nói.
• Người bị nhạy cảm ánh sáng hoặc rung động.

Là Kỹ sư QA, vai trò của chúng ta không chỉ là tìm lỗi mà còn là người bảo vệ chất lượng toàn diện của sản phẩm. Điều này bao gồm cả việc đảm bảo sản phẩm mang tính toàn diện (inclusive). Kiểm thử trợ năng không chỉ là tuân thủ pháp luật (ở nhiều quốc gia đã có quy định bắt buộc) mà còn là trách nhiệm đạo đức và cơ hội mở rộng thị trường.

Tại sao Kiểm thử Trợ năng Quan trọng đối với QA?

Kiểm thử trợ năng là một phần không thể thiếu của kiểm định (validation), đảm bảo rằng chúng ta đang xây dựng “đúng sản phẩm” cho “tất cả” người dùng của mình. Nó bổ sung cho kiểm thử phi chức năng, bên cạnh hiệu năng hay bảo mật (Kiểm thử Bảo mật Cơ bản).

Đối với QA, tích hợp kiểm thử trợ năng vào quy trình làm việc giúp:

1. Mở rộng phạm vi kiểm thử: Đảm bảo ứng dụng hoạt động tốt với nhiều công cụ và phương thức tương tác khác nhau (bàn phím, trình đọc màn hình, v.v.).
2. Cải thiện chất lượng tổng thể: Nhiều cải tiến trợ năng cũng mang lại lợi ích cho người dùng không khuyết tật (ví dụ: phụ đề hữu ích trong môi trường ồn ào, điều hướng bàn phím hiệu quả giúp người dùng nâng cao năng suất).
3. Giảm thiểu rủi ro pháp lý và uy tín: Tránh các vụ kiện hoặc phản ứng tiêu cực từ cộng đồng do ứng dụng không thể tiếp cận.
4. Nâng cao kỹ năng bản thân: Hiểu biết về trợ năng và các công cụ kiểm thử liên quan là một điểm cộng lớn trong sự nghiệp QA.
5. Đóng góp vào mục tiêu toàn diện của sản phẩm: Giúp sản phẩm thực sự phục vụ được một lượng lớn người dùng tiềm năng.

Giống như việc viết các trường hợp kiểm thử hay báo cáo lỗi hiệu quả, kiểm thử trợ năng đòi hỏi một cách tiếp cận có hệ thống và sự hiểu biết về các tiêu chuẩn liên quan.

Các Tiêu chuẩn Trợ năng: WCAG là Gì?

Tiêu chuẩn phổ biến và được công nhận rộng rãi nhất về trợ năng nội dung web là WCAG (Web Content Accessibility Guidelines) do Tổ chức World Wide Web Consortium (W3C) phát triển. WCAG cung cấp một bộ hướng dẫn để làm cho nội dung web dễ tiếp cận hơn cho người khuyết tật.

WCAG được xây dựng dựa trên bốn nguyên tắc cốt lõi (POUR):

1. Perceivable (Có thể cảm nhận): Thông tin và giao diện người dùng phải được trình bày theo những cách mà người dùng có thể cảm nhận được. Ví dụ: cung cấp văn bản thay thế cho hình ảnh, phụ đề cho video, nội dung có thể điều chỉnh kích thước mà không mất thông tin.
2. Operable (Có thể thao tác): Các thành phần giao diện người dùng và điều hướng phải có thể thao tác được. Ví dụ: có thể điều hướng bằng bàn phím, cung cấp đủ thời gian cho người dùng, tránh nội dung gây co giật (flash).
3. Understandable (Có thể hiểu): Thông tin và hoạt động của giao diện người dùng phải dễ hiểu. Ví dụ: sử dụng ngôn ngữ rõ ràng, dễ đọc; làm cho các trang web xuất hiện và hoạt động theo cách dễ đoán; giúp người dùng tránh và sửa lỗi.
4. Robust (Mạnh mẽ): Nội dung phải đủ mạnh mẽ để có thể được diễn giải bởi nhiều tác nhân người dùng, bao gồm cả các công nghệ hỗ trợ. Điều này có nghĩa là các tiêu chuẩn mã hóa web cần được tuân thủ để đảm bảo khả năng tương thích ngược và về phía trước.

WCAG có ba mức độ tuân thủ: A (thấp nhất), AA (trung bình và phổ biến nhất), và AAA (cao nhất). Hầu hết các yêu cầu pháp lý hoặc chính sách của công ty thường nhắm đến mức AA.

Các Vấn đề Trợ năng Thường Gặp Mà QA Cần Chú Ý

Khi thực hiện kiểm thử trợ năng, QA nên tập trung vào việc phát hiện các vấn đề phổ biến sau:

• Thiếu văn bản thay thế (Alt Text) cho hình ảnh: Người dùng trình đọc màn hình không biết nội dung hình ảnh là gì.
• Độ tương phản màu thấp: Người dùng thị lực kém hoặc mù màu khó đọc văn bản nếu màu chữ và màu nền quá giống nhau.
• Không thể truy cập bằng bàn phím: Người dùng khuyết tật vận động không thể sử dụng chuột, họ cần điều hướng chỉ bằng bàn phím (phím Tab, Enter, Space). Các thành phần tương tác như nút, liên kết, trường nhập liệu phải có thể nhận focus và hoạt động khi dùng phím.
• Thiếu hoặc sai nhãn (Labels) cho các trường biểu mẫu: Người dùng trình đọc màn hình gặp khó khăn khi điền biểu mẫu nếu các trường nhập liệu không được liên kết đúng với nhãn mô tả chúng.
• Thứ tự focus bàn phím không logic: Khi nhấn phím Tab, focus nhảy qua các thành phần theo thứ tự không mong muốn hoặc bỏ sót các thành phần.
• Không có phụ đề hoặc phiên âm cho nội dung đa phương tiện: Người khiếm thính không thể tiếp cận nội dung video/audio.
• Thông báo lỗi không rõ ràng hoặc không được thông báo tới người dùng trình đọc màn hình: Người dùng có thể không biết họ đã nhập sai hoặc có lỗi xảy ra.
• Kích thước văn bản không thể thay đổi: Người dùng thị lực kém không thể phóng to văn bản để dễ đọc hơn.
• Thiếu cấu trúc tiêu đề (Heading structure): Người dùng trình đọc màn hình sử dụng cấu trúc tiêu đề (H1, H2, H3…) để điều hướng nội dung trang.
• Các liên kết không mô tả (ví dụ: “Click Here”): Người dùng trình đọc màn hình thường quét qua danh sách các liên kết; các liên kết không mô tả gây khó hiểu.

Cách Thực hiện Kiểm thử Trợ năng

Kiểm thử trợ năng thường là sự kết hợp của kiểm thử thủ công và kiểm thử tự động, tương tự như nhiều loại kiểm thử khác.

Kiểm thử Thủ công

Kiểm thử thủ công là cốt lõi của kiểm thử trợ năng vì các công cụ tự động chỉ phát hiện được khoảng 30-50% các vấn đề trợ năng. Các kỹ thuật thủ công bao gồm:

• Điều hướng bằng Bàn phím: Rút chuột ra và thử sử dụng toàn bộ ứng dụng chỉ với bàn phím (phím Tab, Shift+Tab, Enter, Space, mũi tên). Kiểm tra thứ tự focus, các thành phần có nhận focus không, và các thành phần tương tác có hoạt động không. Đây là một kỹ thuật Black Box rất hiệu quả.
• Sử dụng Trình đọc Màn hình: Cài đặt và làm quen với một trình đọc màn hình phổ biến (ví dụ: NVDA hoặc JAWS trên Windows, VoiceOver trên macOS/iOS, TalkBack trên Android). Duyệt qua ứng dụng bằng trình đọc màn hình để cảm nhận trải nghiệm của người khiếm thị. Lắng nghe cách nội dung được đọc, thứ tự đọc, và liệu tất cả thông tin quan trọng có được truyền tải không.
• Kiểm tra Độ tương phản Màu: Sử dụng các công cụ kiểm tra độ tương phản màu trực tuyến hoặc tiện ích mở rộng trình duyệt để đảm bảo văn bản và nền đáp ứng tỷ lệ tương phản tối thiểu của WCAG (4.5:1 cho văn bản thông thường theo WCAG AA).
• Phóng to Trang: Phóng to trang web lên 200% (hoặc hơn) trong trình duyệt để xem bố cục có bị vỡ, nội dung có chồng chéo hay thông tin bị ẩn đi không.
• Kiểm tra Nội dung Đa phương tiện: Xác minh sự tồn tại và độ chính xác của phụ đề, phiên âm hoặc mô tả âm thanh cho video/audio.
• Kiểm tra Biểu mẫu: Đảm bảo tất cả các trường biểu mẫu có nhãn rõ ràng, thông báo lỗi dễ hiểu và có thể truy cập bằng bàn phím/trình đọc màn hình.

Kiểm thử thủ công này đòi hỏi sự kiên nhẫn và khả năng tư duy của người kiểm thử để đặt mình vào vị trí người dùng có những hạn chế khác nhau. Nó cũng liên quan chặt chẽ đến các kỹ năng đã học trong bài về Kiểm thử Thủ công 101.

Kiểm thử Tự động

Các công cụ tự động giúp phát hiện nhanh chóng các vấn đề trợ năng hiển nhiên và lặp đi lặp lại. Một số công cụ phổ biến bao gồm:

• Tiện ích mở rộng trình duyệt: Axe by Deque, WAVE by WebAIM, Lighthouse (tích hợp trong Chrome DevTools).
• Công cụ quét trang web: Siteimprove, Dynatrace (trước đây là Monotype).
• Thư viện cho tự động hóa kiểm thử: Axe-core (có thể tích hợp với Selenium, Playwright, Cypress).

Ví dụ sử dụng Lighthouse trong Chrome DevTools:

1. Mở trang web cần kiểm thử trong Chrome.
2. Mở Chrome DevTools (F12 hoặc chuột phải -> Inspect).
3. Chọn tab "Lighthouse".
4. Chọn danh mục "Accessibility".
5. Nhấn "Analyze page load".
6. Xem báo cáo và các vấn đề được liệt kê.

Các công cụ tự động rất hữu ích để kiểm tra các quy tắc cứng nhắc như độ tương phản màu, thiếu alt text, cấu trúc HTML cơ bản. Tuy nhiên, chúng không thể hiểu ngữ cảnh hoặc kiểm tra các tương tác phức tạp (ví dụ: thứ tự focus logic, trải nghiệm với trình đọc màn hình).

Sử dụng Công nghệ Hỗ trợ và Người dùng Thật

Nếu có thể, thử nghiệm với các công nghệ hỗ trợ thực tế hoặc giả lập (ví dụ: cài đặt tiện ích mở rộng mô phỏng mù màu, sử dụng tính năng thu phóng của hệ điều hành). Lý tưởng nhất là tổ chức các buổi kiểm thử với sự tham gia của những người khuyết tật thật sự. Phản hồi từ người dùng cuối là vô giá.

Tích hợp Kiểm thử Trợ năng vào Quy trình Phát triển

Để trợ năng thực sự hiệu quả, nó không nên chỉ là một bước kiểm thử cuối cùng. Nó cần được tích hợp vào toàn bộ chu trình phát triển phần mềm (SDLC).

Trong môi trường Agile, QA có vai trò quan trọng trong việc thúc đẩy trợ năng từ sớm:

1. Lên kế hoạch và thiết kế: Tham gia vào các buổi refine story, đảm bảo các yêu cầu trợ năng được xem xét ngay từ đầu. Đảm bảo thiết kế (UX/UI) tuân thủ các nguyên tắc trợ năng (kích thước target, khoảng cách, độ tương phản).
2. Phát triển: Hợp tác với developer để đảm bảo họ sử dụng semantic HTML, thêm ARIA attributes khi cần, và tuân thủ các coding standard về trợ năng. Khuyến khích developer chạy các công cụ kiểm thử tự động cục bộ.
3. Kiểm thử: Thực hiện cả kiểm thử thủ công và tự động trên các môi trường staging/testing. Báo cáo lỗi trợ năng một cách chi tiết, giống như cách bạn viết báo cáo lỗi thông thường nhưng kèm theo thông tin về nguyên tắc WCAG vi phạm và cách khắc phục (nếu biết).
4. Triển khai và Giám sát: Đảm bảo các kiểm tra trợ năng là một phần của quy trình CI/CD (ví dụ: chạy Axe trong pipeline).

Cách tiếp cận “Shift Left” (đưa kiểm thử sớm hơn vào quy trình) đặc biệt quan trọng với trợ năng. Tìm và sửa lỗi trợ năng ở giai đoạn thiết kế hoặc coding sớm sẽ rẻ hơn và dễ dàng hơn rất nhiều so với việc sửa chúng sau khi sản phẩm đã hoàn thiện.

Bảng Tổng hợp: Các Loại Khuyết tật và Kỹ thuật Kiểm thử

Dưới đây là bảng tóm tắt mối liên hệ giữa các loại khuyết tật phổ biến và các kỹ thuật kiểm thử trợ năng tương ứng:

Bảng này chỉ là một cái nhìn tổng quan. Mỗi loại khuyết tật có thể có nhiều nhu cầu khác nhau, và một người có thể có nhiều loại khuyết tật cùng lúc.

Một Số Kỹ thuật và Khái niệm Chi tiết hơn

Semantic HTML

Sử dụng các thẻ HTML có ý nghĩa ngữ nghĩa (semantic tags) như <header>, <nav>, <main>, <article>, <footer>, <button>, <a>, <form> thay vì chỉ dùng <div> hoặc <span>. Semantic HTML giúp trình đọc màn hình và các công nghệ hỗ trợ khác hiểu rõ cấu trúc và vai trò của các thành phần trên trang.

Ví dụ: Sử dụng <button> thay vì <div> với event listener để tạo nút. Thẻ <button> có ngữ nghĩa và hỗ trợ bàn phím/trình đọc màn hình sẵn có.

ARIA Attributes

ARIA (Accessible Rich Internet Applications) là tập hợp các thuộc tính đặc biệt có thể thêm vào các phần tử HTML để cung cấp thông tin bổ sung cho các công nghệ hỗ trợ, đặc biệt là khi sử dụng các thành phần giao diện người dùng phức tạp hoặc động mà HTML gốc không đủ để mô tả ngữ nghĩa. Ví dụ:

• role="button": Chỉ định một phần tử không phải là nút chuẩn đang hoạt động như một nút.
• aria-label="Đóng hộp thoại": Cung cấp một nhãn mô tả cho một nút chỉ có biểu tượng.
• aria-hidden="true": Ẩn một phần tử khỏi trình đọc màn hình.
• aria-expanded="false": Cho biết trạng thái của một phần tử (ví dụ: menu dropdown đang đóng).

Sử dụng ARIA cần cẩn thận. Nguyên tắc chung là: “Sử dụng HTML ngữ nghĩa trước. Chỉ sử dụng ARIA khi HTML gốc không đủ.” Kiểm thử viên cần kiểm tra xem các thuộc tính ARIA có được sử dụng đúng cách và có cung cấp thông tin chính xác cho trình đọc màn hình không.

<!-- Ví dụ về nút chỉ có biểu tượng cần aria-label -->
<button aria-label="Đóng">
    <svg>...</svg> <!-- Biểu tượng chữ X -->
</button>

<!-- Ví dụ về một thẻ div được làm cho có vai trò của nút với aria-role -->
<div role="button" tabindex="0" aria-label="Gửi biểu mẫu">
    Gửi
</div>

Lưu ý: Ví dụ thứ hai cho thấy việc sử dụng ARIA phức tạp hơn vì bạn phải tự thêm tabindex="0" để nó nhận focus và xử lý sự kiện nhấn phím Enter/Space.

Quản lý Focus

Đảm bảo thứ tự focus khi nhấn phím Tab là logic và trực quan. Các phần tử tương tác phải có một chỉ báo focus (focus indicator) rõ ràng (đường viền, thay đổi màu sắc) để người dùng biết họ đang ở đâu trên trang. Khi các thành phần động xuất hiện (ví dụ: modal, popup), focus cần được quản lý đúng cách (chuyển focus vào modal khi mở, giới hạn focus trong modal, trả lại focus về nơi ban đầu khi đóng). Đây là điểm mà kiểm thử thủ công với bàn phím là không thể thiếu.

Thách thức và Lời khuyên

Kiểm thử trợ năng có thể đối mặt với một số thách thức:

• Thiếu kiến thức: Đội ngũ có thể chưa quen với các tiêu chuẩn WCAG hoặc cách sử dụng công nghệ hỗ trợ.
• Thời gian và nguồn lực: Kiểm thử thủ công tốn thời gian hơn, và việc có quyền truy cập vào người dùng khuyết tật thật sự có thể khó khăn.
• Các thành phần phức tạp: Các component UI tùy chỉnh hoặc các ứng dụng SPA (Single Page Application) động có thể gây khó khăn cho cả công cụ tự động và trình đọc màn hình.

Lời khuyên cho các QA:

• Bắt đầu từ những điều cơ bản: Làm quen với các nguyên tắc POUR của WCAG và các vấn đề phổ biến nhất (bàn phím, alt text, độ tương phản).
• Tận dụng công cụ tự động: Sử dụng chúng như một bước kiểm tra nhanh để phát hiện các lỗi hiển nhiên.
• Thực hành với trình đọc màn hình: Dành thời gian làm quen với ít nhất một trình đọc màn hình. Đây là cách tốt nhất để hiểu trải nghiệm của người dùng khiếm thị.
• Hợp tác với đội ngũ: Chia sẻ kiến thức về trợ năng với developer, designer và product owner. Trợ năng là trách nhiệm của cả đội.
• Tham khảo tài nguyên: WCAG, WebAIM, và MDN Web Docs là những nguồn thông tin tuyệt vời.
• Báo cáo lỗi rõ ràng: Khi báo cáo lỗi trợ năng, giải thích vấn đề là gì, ai bị ảnh hưởng, tại sao nó quan trọng (tham chiếu đến WCAG nếu có thể), và các bước tái hiện cụ thể (bao gồm cả công cụ hỗ trợ hoặc phím tắt đã dùng).

Kết luận

Kiểm thử trợ năng không chỉ là một “tính năng” để kiểm tra, mà là một khía cạnh cốt lõi của việc xây dựng các ứng dụng chất lượng cao và mang tính toàn diện. Là Kỹ sư QA, chúng ta có vị trí độc đáo để trở thành người ủng hộ mạnh mẽ cho trợ năng trong đội ngũ của mình.

Bằng cách hiểu các nguyên tắc WCAG, làm quen với các kỹ thuật kiểm thử thủ công và tự động, và tích hợp trợ năng vào quy trình làm việc từ sớm, chúng ta có thể giúp đảm bảo rằng sản phẩm của mình có thể tiếp cận được bởi mọi người, bất kể khả năng của họ là gì.

Hãy coi kiểm thử trợ năng là một phần không thể thiếu trong bộ kỹ năng của bạn trên Lộ trình học Kỹ sư QA. Nó không chỉ mở rộng phạm vi kiểm thử của bạn mà còn giúp bạn xây dựng những sản phẩm có ý nghĩa hơn cho một thế giới kỹ thuật số công bằng và toàn diện hơn.