Checklist pengujian situs web

Checklist situs mendukung verifikasi sistematis; tidak menjanjikan penemuan setiap defect. Nilainya ialah pemahaman tim atas cakupan, hasil yang diharapkan, dan risiko tersisa. Satu daftar tidak dapat melayani situs berita, portal bank, dan panel administrasi internal dengan sama baik.

Sesuaikan item dengan produk serta rilis sebelum eksekusi. Perubahan formulir pesanan memerlukan kedalaman berbeda dari koreksi teks footer. Pemeriksaan berikut menyediakan dasar: pilih yang berlaku dan tambahkan risiko khusus perubahan.

Siapkan konteks pengujian

Catat build, lingkungan, area berubah, peran, data uji, dan browser didukung. Identifikasi alur kritis: hasil apa yang membawa pengguna ke situs, dan kegagalan mana yang paling mahal?

Tiap item memerlukan hasil dan bukti. Gunakan status “lulus”, “defect”, “terblokir”, “belum diuji”, dan “tidak berlaku” beserta alasan. Pengujian dilewati tidak boleh dihitung lulus. Siapkan lingkungan dan data aman untuk pembayaran, email, dan penghapusan uji.

Periksa pemuatan dan navigasi

→Buka beranda dan halaman penting langsung lewat URL: konten benar dimuat dan sumber daya wajib bekerja.
→Refresh halaman bertingkat: server dan klien mempertahankan rute benar tanpa kesalahan tak terduga.
→Navigasi mundur dan maju: UI memulihkan keadaan konsisten tanpa mengulang tindakan secara tidak sengaja.
→Buka alamat tidak ada: halaman kesalahan jelas menyediakan jalan melanjutkan, dan respons HTTP sesuai tujuan sumber daya.
→Periksa menu, tautan internal, dan navigasi layanan eksternal: tanpa jalan buntu, domain salah, atau loop redirect.

Pertimbangkan sesi baru dan yang sudah ada. Situs baru dibuka dan tab lama mungkin menerima versi aset serta keadaan berbeda.

Periksa skenario bisnis utama

Ikuti seluruh alur dari titik masuk sampai hasil, lalu verifikasi hasil benar-benar tersimpan. Pesan “sukses” saja tidak mengonfirmasi perubahan data.

Untuk toko, artinya mencari produk, memakai keranjang, checkout, dan melihat pesanan. Untuk basis pengetahuan, artinya menemukan dan membaca artikel, mengikuti materi terkait, serta mendapatkan URL berbagi yang benar. Gunakan peran dan data realistis: administrator mungkin melewati pembatasan pengguna biasa.

Periksa formulir dan data

→Nilai kosong, biasa, dan batas ditangani menurut kontrak; kesalahan membantu pengguna memperbaiki masukan.
→Tombol dan Enter memicu pengiriman konsisten; klik berulang tidak menggandakan operasi.
→Setelah penolakan server, nilai valid tetap tersedia dan ada cara retry yang jelas.
→Teks panjang, karakter Kiril, locale berbeda, dan format tanggal tidak merusak data.
→Unggah dan unduh memenuhi persyaratan tipe, ukuran, nama berkas, dan akses.

Bandingkan data masukan, request, respons, dan keadaan yang dibaca sesudahnya. Rantai ini membantu menemukan hilangnya presisi atau normalisasi tak disadari.

Pastikan login, logout, kedaluwarsa sesi, dan autentikasi ulang mengikuti kebijakan produk. Uji URL terlindungi tanpa login dan operasi oleh peran tanpa izin yang diperlukan.

Dengan akun siap pakai, periksa akses objek uji pengguna lain melalui UI dan API. Tombol tersembunyi tidak menggantikan kontrol akses server. Setelah berganti pengguna, aplikasi tidak boleh menampilkan data akun sebelumnya dari keadaan lokal atau cache yang salah digunakan.

Periksa kesalahan, jaringan, dan pemulihan

Perlambat jaringan, putus request, reproduksi kesalahan server yang direncanakan, dan kembalikan respons kosong. Harapkan keadaan jelas, indikator loading yang selesai, dan cara melanjutkan yang terdefinisi.

Hasil tidak pasti sangat penting: server mungkin menyimpan pesanan tetapi klien tidak menerima respons. Retry tidak boleh diam-diam membuat pesanan kedua. Periksa konsistensi server dan perlindungan duplikat. Gunakan Console dan Network untuk diagnosis, tetapi nilai hasil berdasarkan perilaku produk dan data.

Periksa tampilan dan aksesibilitas

Pilih browser serta ukuran dari matriks dukungan. Selesaikan tindakan kritis dalam jendela sempit, dengan konten panjang, dan zoom diperbesar. Panel tetap dan keyboard tidak boleh menutupi tindakan wajib.

Ikuti alur dengan keyboard; periksa fokus terlihat, label kolom, kesalahan jelas, dan nama tombol aksesibel. Gunakan pembaca layar bila perlu. Pemeriksaan otomatis memberi sinyal tambahan tetapi tidak membuktikan setiap proses aksesibel.

Periksa visibilitas publik dan pengaturan rilis

Untuk situs publik, periksa title, description, canonical, aturan robots, sitemap, dan redirect yang diharapkan. Untuk layanan privat, pembatasan akses benar lebih penting. Jangan menerapkan persyaratan indeks pencarian pada area akun privat.

Periksa konfigurasi produksi: domain API, tautan, aset, dan tidak adanya stub uji atau rahasia diagnostik. Setelah deployment, lakukan smoke test singkat dengan data berizin. Batasi pengujian beban dan destruktif pada lingkungan serta cakupan yang disepakati sebelumnya.

Contoh praktis: rilis checkout

Misalkan formulir alamat dan perhitungan pengiriman berubah. Prioritaskan penyelesaian checkout, batas alamat, pergantian metode pengiriman, dan retry setelah timeout.

1.Buat pesanan uji dengan alamat biasa. Harapkan satu record dengan alamat, jumlah, dan metode pengiriman benar.
2.Masukkan alamat panjang di ponsel lalu perbaiki kesalahan. Pesan dan tombol tetap dapat diakses saat keyboard terbuka.
3.Ubah alamat sebelum perhitungan selesai. Pilihan terbaru harus berlaku, bukan respons tertunda.
4.Ulangi konfirmasi setelah simulasi kegagalan respons. Harapkan status konsisten tanpa duplikat.
5.Periksa tampilan pesanan dengan peran uji lain. Aturan akses harus ditegakkan.

Pilih item tersisa berdasarkan ketergantungan terdampak dan riwayat defect, bukan sekadar menghabiskan seluruh daftar.

Menyelesaikan eksekusi

Dalam laporan, hubungkan defect dengan item checklist dan sebutkan lingkungan tercakup, penghambat, serta area belum diuji. Bedakan “tidak ditemukan defect yang diketahui” dari “tidak ada risiko”: pengujian tidak dapat membuktikan yang kedua.

Kesalahan umum meliputi kedalaman sama untuk setiap rilis, hasil yang diharapkan tidak ditulis, dan pemeriksaan terblokir ditandai hijau. Checklist baik mendukung keputusan rilis berdasarkan bukti dan batas yang dinyatakan.

Bacaan lanjutan

Lembar rilis web berbasis bukti

Gunakan tugas konkret seperti pengiriman formulir kontak fiktif. Sepakati aturan kolom, perilaku sukses, dan browser didukung sebelum menguji. Baris berikut menentukan pengamatan; ini lembar kerja rilis ringkas, bukan audit keamanan atau aksesibilitas lengkap. Catat hasil aktual terpisah dari ekspektasi.

plain text

Area	Tindakan	Pengamatan yang diharapkan	Bukti yang perlu dikumpulkan
Fungsi	Kirim satu formulir valid	Satu pengiriman diterima dan konfirmasi jelas	ID request + UI
Validasi	Kirim tanpa email wajib	Kesalahan spesifik; tidak sukses; request tidak valid ditangani sesuai kontrak	UI + log request
Keyboard	Selesaikan tugas dengan Tab/Shift+Tab/Enter	Fokus terlihat; kontrol terjangkau; tidak ada jebakan keyboard	Video
Label	Periksa nama aksesibel input	Nama menjelaskan tujuan; kesalahan terkait dengan kolomnya	Pohon aksesibilitas
Responsif	Gunakan viewport sempit/lebar yang disepakati	Kontrol tidak terpotong; konten dapat digunakan	Viewport + tangkapan layar
SEO	Ambil HTML halaman publik	Bahasa, title, canonical, dan kebijakan indeks benar	Header + cuplikan HTML
Jaringan	Interupsi sebelum/setelah pengiriman	Tidak ada keberhasilan palsu; pemulihan aman tanpa pengiriman ganda	Jejak jaringan
Data	Baca kembali pengiriman yang diterima	Nilai tersimpan sesuai masukan dan kebijakan akses	Bukti record tanpa data sensitif

Contoh pengamatan bersifat hipotetis: jika tombol menampilkan “Terkirim” sementara request menghasilkan kesalahan server, catat status, waktu, dan keadaan UI; jangan klaim pesan tersimpan. Sebaliknya, timeout tidak membuktikan server menolak penulisan. Pastikan hasil sebelum retry.

Alat QA Hub dapat membantu bukti spesifik: URL parser menjelaskan parameter kueri, JSON formatter memperjelas struktur respons, JSON diff membandingkan payload harapan dan aktual, dan HTTP codes memberi referensi. Alat ini tidak memutuskan apakah persyaratan produk terpenuhi. Akhiri dengan kegagalan diketahui, cakupan belum diuji, penanggung jawab, dan keputusan risiko rilis.