Cara kami meningkatkan pengujian aksesibilitas
Pada awal perjalanan aksesibilitas kami, kami umumnya mengelompokkan pengujian aksesibilitas menjadi dua kategori: otomatis dan manual. Yang pertama untuk dengan cepat menangkap masalah mudah yang dapat dideteksi secara algoritmik dan yang kedua untuk segala hal lain yang membutuhkan lebih banyak waktu dan perhatian untuk ditemukan. Pengujian otomatis sangat cocok untuk proses cepat seperti integrasi berkelanjutan (CI), sedangkan pengujian manual membutuhkan koordinasi yang cermat dengan penguji yang terampil untuk mencakup semua hal yang tidak dapat dilakukan oleh alat otomatis.
Selama prosesnya, kami menemukan bahwa sebenarnya ada titik ideal antara kedua pendekatan ini. Dalam kemitraan dengan Assistiv Labs, kami menggabungkan proses yang lebih baik dengan pengujian layanan menyeluruh menuju Alur Kerja pengujian yang mendefinisikan ulang otomatis dan manual. Ini adalah sesuatu di antara keduanya, pendekatan hybrid yang secara dramatis meningkatkan cakupan otomatis dan mengurangi biaya koordinasi manual.
Sekarang kami menangkap isu yang jelas dan mudah diperbaiki dalam hitungan jam, bukan minggu. Proses baru kami secara otomatis mencari tahu hal yang mendesak dan mengirimkan isu ke tim yang tepat, yang biasanya menyelesaikannya dalam beberapa hari.
Hasilnya bersifat teknis dan budaya. Kami memberikan umpan balik aksesibilitas jauh lebih cepat, tim menyelesaikan bug lebih cepat, dan para teknisi di Asana telah mulai memikirkan isu aksesibilitas dengan cara yang berbeda.
Membangun proses untuk memprioritaskan bug aksesibilitas
Pada skala Asana, Kerangka Kerja prioritas yang kuat yang didukung oleh proses dan prinsip tata kelola sangat penting. Tim perlu mengetahui hal yang perlu dijadwalkan ke dalam backlog mereka untuk kapan, dan hal yang perlu diperhatikan saat ini.
Namun, mudah untuk meremehkan betapa sulitnya memprioritaskan bug aksesibilitas. Prioritas didasarkan pada matriks faktor unik yang rumit, termasuk teknologi pendukung, browser, kelompok pengguna yang terdampak, umpan balik pengguna, area produk, tingkat kesulitan perbaikan, solusi alternatif, kesesuaian WCAG, dan konteks historis. Beberapa bug mungkin sudah ada sejak lama, tetapi baru terdeteksi belum lama ini. Bug lain muncul dengan fitur baru. Dan beberapa adalah regresiβfungsionalitas yang sebelumnya dapat diakses tetapi sekarang tidak.
Untuk membuat Kerangka Kerja, kami secara formal mendefinisikan berbagai jenis bug aksesibilitas sehingga kami dapat merancang Alur Kerja yang efisien untuk masing-masing bug. Salah satu langkah penting adalah menentukan apa yang merupakan regresi dan apa yang bukan.
regresi (n)
Isu yang terdokumentasi (apakah ada bukti proses bahwa ini berfungsi, seperti bug sebelumnya, utas komentar, tangkapan layar, atau rekaman layar?), dapat direproduksi (apakah kolega dapat mereproduksi menggunakan langkah-langkah seperti yang diuraikan?), dan sebelumnya berfungsi tetapi sekarang tidak lagi.
Regresi tentu saja dapat mendapatkan prioritas tinggiβhal terakhir yang diinginkan siapa pun adalah mengalami kemunduran aksesibilitas. Ini dapat sangat menyederhanakan penentuan prioritas dalam banyak kasus.
Namun, ada hal yang perlu diperhatikan. Regresi ditentukan oleh cuplikan sebelum dan sesudah. Misalnya, cuplikan sebelum bisa berupa video fungsionalitas yang berfungsi dan cuplikan sesudah bisa berupa video hasil bermasalah yang baru. Bug secara alami memiliki snapshot setelah. Namun, menemukan snapshot sebelum biasanya membutuhkan pencarian mendalam.
Tanpa sumber snapshot sebelum yang andal, sering kali tidak sepadan dengan waktu yang dihabiskan untuk menyelidiki apakah bug dapat diprioritaskan sebagai regresi. Di sinilah jenis automasi baru terbukti sangat membantu.
Automasi aksesibilitas end-to-end
Pengujian yang sepenuhnya otomatis bukanlah hal baru dalam pengujian aksesibilitas atau bagi Asana. Secara historis, axe DevTools dan jsx-a11y untuk React memberi kami cakupan horizontal yang luas. Tapi cakupannya dangkal. Kami merasa perkiraan token 30% untuk pengujian otomatis di seluruh industri cukup dekat dengan kriteria WCAG yang kami capai. Cakupan terbatas berarti pengujian manual masih menemukan bug yang luput dari alat otomatis.
Kami membutuhkan alat yang dapat menganalisis lebih dalam. Alat yang lebih selaras dengan riset pengguna dan prinsip tata kelola kami. Itulah yang kami temukan dengan Assistiv. Pengujian untuk layanan menyeluruh Assistiv ditulis dari awal oleh para teknisi Assistiv berdasarkan alur pengguna dan parameter pengujian yang kami sediakan. Suite ini menggabungkan pintasan keyboard, pembaca layar sungguhan, peramban, dan visi mesin yang didukung oleh cloud Assistiv Labs. Hasilnya lebih dari sekadar simulasi, dengan peristiwa yang ditransmisikan ke mesin dengan cara yang sama seperti yang dilakukan pengguna manusia, memaksimalkan cakupan WCAG dan masalah aksesibilitas yang lebih luas.
Automasi aksesibilitas menyeluruh sangat berbeda dari automasi tradisional, berinteraksi dengan Asana untuk menyelesaikan tugas dengan cara yang sama seperti yang dilakukan penguji manual. Dimungkinkan untuk mencakup hingga 75% kriteria WCAG, tergantung pada skenario pengujian. Dan masih ada pakar berpikir kritis yang secara langsung mengawasi semuanya. Orang-orang dari Asana dan Assistiv terlibat dalam merancang tindakan pengguna yang representatif dan meninjau hasilnya, yang secara drastis meningkatkan standar pengujian otomatis dalam hal ruang lingkup, frekuensi, dan akurasi.
Menggabungkan kekuatan
Dengan Kerangka Kerja prioritas yang kuat dan automasi baru yang beralih dari menemukan sebagian kecil bug menjadi sebagian besar, kami menerapkan Alur Kerja prioritas yang andal.
Pertama, pengujian otomatis disinkronkan dengan pipeline teknik Asana yang sudah ada. Isu baru terdeteksi hampir secara real-time dan dikorelasikan dengan perubahan kode yang kemungkinan menyebabkannya.
Selanjutnya, seorang teknisi Assistiv meninjau untuk memfilter positif palsu dan menulis isu di backlog Asana dengan dampak pengguna yang dikontekstualisasikan dan panduan remediasi. Karena pengujian otomatis berjalan terus menerus, snapshot sebelumnya tersedia dengan mudah dan regresi dapat dengan mudah diklasifikasikan. Kami mempertahankan alur kerja Asana otomatis yang mengarahkan isu ke tim yang benar.
Dalam praktiknya, ini berarti bahwa regresi biasanya ditandai dalam waktu 24 jam setelah penyebaran dan didokumentasikan dengan cara yang mudah dipahami oleh teknisi tanpa latar belakang aksesibilitas. Hal ini memungkinkan tim aksesibilitas kami menetapkan SLA untuk menangani regresi dan menyerahkannya kepada tim produk. Tidak ada yang harus membuat alasan untuk menentukan regresi mana yang harus ditangani pertama atau kedua atau terakhir. Itu hanya bug yang membutuhkan perhatian.
Desentralisasi ini secara langsung menghasilkan program yang lebih berkelanjutan dan pengalaman pengguna akhir yang lebih inklusif. Kami memiliki lebih banyak kemandirian dan dampak, lebih banyak ruang untuk kreativitas karena kami tidak terus-menerus menangani banyak masalah kecil. Dan itu pada akhirnya berarti kami lebih bahagia dan lebih efektif.
ROI dari loop umpan balik yang lebih cepat
Bug yang tidak terdeteksi selama berminggu-minggu atau berbulan-bulan akan mahal untuk diperbaiki. Seseorang harus memilahnya ke tim yang sesuai dan memastikan bug tersebut diprioritaskan. Teknisi yang ditugaskan kemungkinan bukan teknisi yang menyebabkannya. Bahkan jika orang yang sama, sulit untuk mengungkap konteks yang terlupakan, mengubah cara kerja, atau berkoordinasi dengan tim lain untuk mengatasi utang teknis yang muncul dalam beberapa minggu dan bulan berikutnya.
Dengan mengukur masalah dalam angka, sebuah studi IBM yang banyak dikutip menemukan bahwa biaya untuk menemukan bug dalam produksi 30 kali lebih mahal daripada yang ditemukan selama fase desain. Itu benar.
Ketika teknisi menyebarkan pembaruan di pagi hari, bukti regresi biasanya akan mulai muncul sebelum akhir hari kerja. Rangkaian umpan baliknya begitu singkat sehingga pengujian ujung ke ujung kami adalah yang pertama kali memperingatkan kami tentang bug UI generik, tidak terbatas pada pembaca layar atau navigasi keyboard, dalam beberapa kesempatan.
Ketika para teknisi mulai menerima umpan balik yang lebih cepat dari pengujian menyeluruh, kami melihat penurunan beban kognitif dalam penentuan prioritas. Ambiguitas menghilang. Para teknisi akan berpikir, βSaya bertanggung jawab atas hal ini karena saya yang mengirimkannya pagi ini. Kemarin berfungsi dan hari ini rusak, saya harus memperbaikinya sekarang.β Memperbaiki bug aksesibilitas menjadi seperti memori otot.
Di Asana, bug aksesibilitas hanyalah bug. Dan bug tersebut diperbaiki.
Cara yang lebih baik untuk mengotomatiskan aksesibilitas
Sebelum mengadopsi pengujian aksesibilitas menyeluruh, tim aksesibilitas kami membuat kemajuan signifikan. Di sisi Operasi, tim desain dan teknik telah mendokumentasikan proses peninjauan, definisi regresi, dan SLA yang berlaku. Dalam hal pengujian, ada solusi otomatis untuk laporan yang cepat tetapi dangkal dan QA manual untuk audit yang menyeluruh tetapi memakan waktu.
Dengan pendekatan menyeluruh, kami memiliki solusi teknis yang melengkapi dan berada di atas upaya yang sudah ada. Regresi didokumentasikan lebih cepat, lebih detail, dengan lebih banyak bukti. Hampir tidak ada yang membuang waktu untuk laporan bug yang tidak dapat ditindaklanjuti atau direproduksi.
Sekarang kami memiliki gambaran yang jelas tentang bug mana yang baru dan mana yang lama, alur pengguna mana yang terpengaruh, dan siapa yang bertanggung jawab atas perbaikan. Kami dapat menjadi yang terdepan dan berfokus pada visi kami untuk aksesibilitas Asana di masa mendatang.
Tentang penulis:Β Β Cameron Cundiff (Pimpinan Teknis) dan Jiaxin Zheng (Manajer Program Teknis) adalah anggota grup Siklus Pengembangan, yang berdedikasi untuk menyediakan alat yang memungkinkan pengembang mewujudkan ide menjadi produk dengan cepat, kuat, dan menyenangkan.
