Arsitektur klien–server adalah model ketika satu bagian sistem meminta data atau tindakan dan bagian lain menyediakannya. Klien memulai request; server memproses dan mengembalikan hasil.
Terdengar sederhana, tetapi ini model dasar bagi QA. Ketika melihat produk demikian, banyak bug tidak lagi terlihat seperti “perilaku UI aneh” dan menjadi titik kegagalan yang dapat dikenali: klien, jaringan, server, database, integrasi eksternal, cache, antrean, atau otorisasi.
Cara kerjanya
Pada produk web atau seluler biasa, klien berupa browser, aplikasi seluler, atau layanan lain. Pengguna mengklik tombol; klien mengumpulkan data dan mengirim request. Server menerima, memeriksa izin, memvalidasi masukan, menjalankan logika bisnis, dan bila perlu mengakses database atau sistem eksternal.
- →Klien dapat berupa browser, aplikasi seluler, layanan lain, atau mitra eksternal.
- →Server tidak selalu satu proses atau monolit.
- →Gateway, load balancer, cache, antrean, database, dan integrasi eksternal sering berada di sepanjang jalur klien–server.
Karena itu, satu klik pengguna dapat memicu rantai tindakan, bukan satu operasi saja.
Sebuah contoh sederhana
Pengguna mengklik “Bayar pesanan”. Klien mengirim request berisi ID pesanan, jumlah, dan detail pengguna. Server memeriksa keberadaan pesanan, izin pengguna membayar, dan apakah status saat ini mengizinkan pembayaran. Lalu server memanggil provider pembayaran, menyimpan hasil, dan mengembalikan respons ke klien.
Pengguna hanya melihat tombol dan pesan akhir. QA perlu melihat seluruh rantai. Jika tidak, penyebab defect mudah salah diidentifikasi.
Apa yang perlu diperiksa QA
- →Apakah request dikirim.
- →Request tepat yang dikirim.
- →Respons server.
- →Cara klien menafsirkan respons.
- →Apakah data berubah di semua tempat yang seharusnya.
- →Apakah layanan eksternal atau lingkungan tidak stabil terlibat.
Jika UI menampilkan jumlah salah, beberapa sebab mungkin: server mengembalikan nilai salah, database berisi data salah, layanan eksternal memberikan respons tidak terduga, atau klien merender respons benar secara salah. Gejala terlihat sama tetapi titik kegagalannya berbeda.
Lapisan yang paling sering diuji
- →Lapisan klien: apakah request terkirim, parameter disusun benar, dan hasil ditampilkan benar.
- →Lapisan server: apakah validasi, kontrol akses, dan logika bisnis bekerja benar.
- →Lapisan data: apakah data dibuat, diperbarui, atau dihapus sesuai harapan.
- →Lapisan integrasi: cara sistem menangani kegagalan, timeout, dan respons tidak terduga layanan eksternal.
Manfaat dalam praktik
Pertama, penyelidikan defect. Penguji yang hanya melihat layar menulis “tidak berfungsi”. Penguji yang memahami arsitektur menulis: request berisi parameter salah; server mengembalikan 403 padahal peran seharusnya berizin; database tidak diperbarui. Standar laporannya jauh lebih tinggi.
Kedua, desain pengujian. Memahami lapisan dalam skenario membantu merancang pemeriksaan lebih kuat: happy path UI, kesalahan jaringan, request berulang, kegagalan parsial, data tidak konsisten, dan masalah integrasi.
Ketiga, komunikasi tim. Model ini membantu berbicara spesifik: masalah pada klien, server, data, atau provider eksternal. Ini menghemat waktu dan memudahkan triase.
Hal penting bagi QA
- →Satu tindakan pengguna sering melibatkan beberapa langkah teknis.
- →Bug UI terlihat sama dapat berasal dari lapisan sistem berbeda.
- →Untuk mengisolasi masalah, periksa request, respons, data, dan ketergantungan selain layar.
- →Pemahaman arsitektur klien–server membuat laporan bug lebih tepat dan penyelidikan lebih cepat.
Bacaan lanjutan
- →Dalam basis pengetahuan ini: Apa itu API? — pengantar antarmuka untuk komunikasi.
- →Dalam basis pengetahuan ini: HTTP dan HTTPS — untuk memahami lapisan transport request dan respons lebih baik.
- →Dalam basis pengetahuan ini: Metode, kode status, dan header — agar lebih yakin menafsirkan sinyal teknis API.
Lacak satu tindakan dari browser ke penyimpanan
Skenario fiktif: peserta menyimpan nama tampilan profil. Hasil yang diharapkan ialah pembacaan berikutnya menampilkan nama baru bagi akun berizin yang sama. Toast sukses hanya membuktikan klien menampilkan pesan; bukan keadaan tersimpan.
Lapisan Pengamatan Hal yang dapat dibuktikan
Browser Tindakan, masukan, payload request, dan waktu Apa yang benar-benar dikirim klien
Jaringan/API Metode, URL, status, body, ID korelasi Respons API yang diamati
Log layanan ID korelasi yang sama dan hasil validasi Jalur server yang menangani request, jika log tersedia
Penyimpanan Pembacaan uji berizin pada record target Nilai tersimpan pada waktu pengamatan
Pembacaan API lanjutan Respons GET untuk akun yang sama Apakah jalur baca menampilkan nilai tersimpanGunakan pembacaan uji berizin atau fixture, bukan menganggap akses database tersedia. Dalam sistem asinkron, konsistensi langsung mungkin tidak dijanjikan: sepakati sinyal selesai dan jendela waktu dahulu. Jika browser timeout setelah mengirim penulisan, periksa hasil sebelum retry. Server mungkin sudah menyimpannya.
Untuk mengisolasi kegagalan, bandingkan pengamatan berdekatan. Data request salah mengarah ke persiapan klien; request benar dengan kesalahan validasi terdokumentasi mengarah ke interpretasi kontrak/masukan; respons sukses dengan data hilang memerlukan penyelidikan jalur tulis atau alur asinkron. Ini arah penyelidikan, bukan penyebab terbukti. Pertahankan timestamp serta ID korelasi dan hapus rahasia dari bukti.