SQL untuk QA

SQL untuk QA berfokus pada apa yang sebenarnya terjadi pada data, bukan optimasi kueri mendalam atau pekerjaan DBA. Ketika UI dan API tidak selaras, database sering memberikan bukti paling langsung.

SQL dasar pun sangat membantu pengujian. SQL memverifikasi apakah record dibuat, status tersimpan, duplikat muncul, relasi benar, laporan cocok, atau data hilang setelah suatu tindakan.

Mengapa QA membutuhkan SQL

Dalam pekerjaan sehari-hari, SQL biasanya memiliki tiga tujuan:

• →Memeriksa keadaan data aktual setelah suatu skenario
• →Menyelidiki defect lebih cepat
• →Menentukan apakah masalah berada pada UI, API, logika, atau data

Banyak masalah yang tampak seperti defect tombol sebenarnya merupakan masalah keadaan data.

• →Record muncul di UI tetapi baris terkait tidak ada
• →API melaporkan sukses tetapi perubahan tidak tersimpan
• →Laporan menggunakan data yang salah
• →Retry membuat duplikat
• →Filter tampak rusak karena data tersimpan sudah berbeda dari ekspektasi produk

Tanpa SQL, penyelidikan ini dapat lambat dan kekurangan informasi.

Apa yang perlu dipelajari terlebih dahulu

QA tidak perlu langsung menguasai seluruh bahasa. Mulailah dengan beberapa unsur penting.

• →SELECT mengambil data
• →WHERE menyaring baris
• →ORDER BY mengatur urutan
• →LIMIT menghindari pengambilan baris yang tidak diperlukan
• →COUNT menghitung jumlah
• →JOIN menghubungkan data antartabel
• →GROUP BY menampilkan agregat dan duplikat
• →IS NULL dan IS NOT NULL memeriksa nilai null

Unsur ini mencakup banyak tugas pengujian sehari-hari.

Pahami tujuan setiap konstruksi beserta sintaksnya. Dengan tabel pesanan, pengguna, dan pembayaran, SQL dapat memverifikasi skenario lengkap, bukan sekadar menampilkan baris.

Manfaat SQL bagi QA

Kekuatan utama SQL adalah ketepatan.

UI menampilkan informasi terpilih; API memberikan respons satu panggilan. Pemeriksaan data langsung dapat menjawab:

• →Apakah record benar-benar dibuat?
• →Berapa jumlah record semacam itu yang sebenarnya ada?
• →Apakah ada duplikat?
• →Pengguna mana yang memiliki entitas tersebut?
• →Apakah status yang benar tersimpan?
• →Apakah ada record tanpa induk?
• →Apakah jumlahnya sesuai dengan antarmuka?
• →Apakah operasi benar-benar mengubah record, atau hanya tampak demikian?

Hal ini sangat berguna untuk integrasi, antrean, retry, pekerjaan latar belakang, pembaruan massal, dan relasi entitas yang kompleks.

JOIN untuk QA

JOIN sangat berharga karena menunjukkan hubungan antarentitas, bukan hanya isi setiap tabel.

• →Setiap pesanan memiliki pemilik
• →Pesanan memiliki item yang diperlukan
• →Pembayaran terkait dengan pesanan yang benar
• →Pengguna memiliki peran yang benar
• →Tidak ada record yang merujuk objek yang tidak ada

Sering kali record tersedia tetapi terhubung secara salah atau sebagian rantai relasinya terputus. JOIN membuat defect tersebut lebih mudah terlihat.

Kesalahan SQL yang umum dalam QA

• →Menyamakan NULL dengan nilai kosong
• →Mengabaikan baris duplikat akibat JOIN
• →Hanya memeriksa baris pertama yang mudah ditemukan
• →Menjalankan operasi tulis yang tidak diperlukan

Pendekatan umum paling aman adalah membaca dahulu dan hanya membuat perubahan yang disengaja pada lingkungan yang sesuai. SELECT cukup untuk sebagian besar penyelidikan.

Contoh praktis

Misalkan pengguna melaporkan dua pesanan identik.

UI memberikan pandangan sebagian, dan endpoint API memperlihatkan satu bagian. SQL dapat memastikan lebih banyak hal:

• →Apakah dua baris pesanan benar-benar ada
• →Apakah kunci bisnisnya sama
• →Apakah keduanya dibuat pada waktu yang sama
• →Apakah keduanya memiliki item pesanan identik
• →Apakah retry membuat duplikat
• →Apakah ada dua pembayaran atau hanya satu
• →Apakah duplikasi nyata atau UI menampilkan satu record dua kali

Di sini SQL menjadi alat QA praktis, bukan tambahan teknis opsional.

Kebiasaan praktis untuk QA

• →Mulai dengan SELECT sederhana
• →Periksa satu entitas dahulu, lalu relasinya
• →Selalu tentukan kunci yang mengidentifikasi data
• →Jangan menarik kesimpulan dari satu baris ketika pola yang lebih luas penting
• →Gunakan kueri tulis dengan hati-hati
• →Saat ragu, bandingkan bukti SQL dengan perilaku API dan UI

SQL sangat berguna sebagai penghubung antarlapisan sistem.

Hal penting bagi QA

• →QA menggunakan SQL untuk memverifikasi kenyataan data, bukan untuk memprogram database.
• →SELECT, WHERE, JOIN, COUNT, dan GROUP BY dasar mendukung penyelidikan defect yang kuat.
• →Banyak defect produk merupakan masalah keadaan data.
• →Menghubungkan bukti UI, API, dan database adalah keterampilan pengujian yang berharga.
• →SQL membuat diagnosis lebih tepat, cepat, dan sistematis.

Bacaan lanjutan

• →Dalam basis pengetahuan ini: Pengujian database
• →Dalam basis pengetahuan ini: JSON dan XML
• →Sumber eksternal: Tutorial JOIN PostgreSQL

Latihan dengan satu dataset bersama: delapan soal yang telah diperiksa

Gunakan lembar latihan QA Hub dan sql-for-qa-fixture.sql yang ditautkan, bukan membuat dataset kedua. Dataset berisi empat pelanggan fiktif dan lima pesanan, dengan jumlah dalam sen bulat. Panduan ini menggunakan SQLite 3; materi juga menjelaskan SQL portabel, tetapi instruksi ini tidak mengklaim eksekusi PostgreSQL. Unduh kedua berkas, buka terminal pada direktorinya, dan pertahankan satu sesi tetap terbuka.

sqlite3 :memory:
-- At the SQLite prompt:
.read sql-for-qa-fixture.sql
SELECT COUNT(*) FROM qa_customers;
-- Expected: 4
SELECT COUNT(*) FROM qa_orders;
-- Expected: 5

Fixture membuat tabel sementara pada sesi saat ini. Sesi :memory: baru dimulai kosong; menjalankan CREATE lagi dalam sesi yang sama tanpa reset gagal karena tabel sudah ada. Tutup sesi sementara lalu mulai sesi baru untuk mereset. Tidak diperlukan koneksi atau kredensial produksi.

Prediksi baris sebelum membuka lembar jawaban

Tugas dalam materi	Hasil yang diharapkan
1 Pesanan dibayar	(101, 1, 1200), (103, 2, 700), (105, 3, 0)
2 Pesanan per pelanggan, termasuk nol	(1, Ada, 2), (2, Boris, 2), (3, Chen, 1), (4, Dina, 0)
3 Pendapatan dibayar per pelanggan	(1, 1200), (2, 700), (3, 0), (4, 0)
4 Pelanggan tanpa pesanan	(4, Dina)
5 Email non-null duplikat	(ada@example.invalid, 2)
6 Jumlah dibayar tidak valid menurut aturan latihan	(105, 0)
7 Setidaknya dua pesanan	(1, 2), (2, 2)
8 Email tidak ada	(4, Dina)

Nomor tugas dan hasil ini sama dengan lembar unduhan. Email duplikat dan pesanan dibayar bernilai nol merupakan contoh yang sengaja ditanamkan. Apakah keduanya merupakan defect pada produk nyata bergantung pada persyaratan produk. Jangan menyimpulkan aturan keunikan, nilai positif, atau normalisasi hanya dari kueri.

Jebakan LEFT JOIN: total benar tetapi satu pelanggan hilang

Bandingkan dua kueri ini setelah memuat fixture bersama. Aturan laporan mengharuskan keempat pelanggan ditampilkan, termasuk yang tidak memiliki pesanan dibayar. Kueri pertama menempatkan filter paid dalam WHERE:

SELECT c.customer_id, COALESCE(SUM(o.amount_cents), 0) AS paid_cents
FROM qa_customers c
LEFT JOIN qa_orders o ON o.customer_id = c.customer_id
WHERE o.status = 'paid'
GROUP BY c.customer_id ORDER BY c.customer_id;

Hasilnya (1,1200), (2,700), (3,0): Dina hilang. Baris hasil join yang tidak berpasangan memiliki kolom pesanan NULL sehingga kondisi WHERE membuangnya. Jumlah tetap 1900 sen; karena itu, pemeriksaan total keseluruhan saja tidak menemukan defect.

Tempatkan filter dalam kondisi join agar pelanggan tanpa pasangan tetap ada:

SELECT c.customer_id, COALESCE(SUM(o.amount_cents), 0) AS paid_cents
FROM qa_customers c
LEFT JOIN qa_orders o
  ON o.customer_id = c.customer_id AND o.status = 'paid'
GROUP BY c.customer_id ORDER BY c.customer_id;

Hasil yang diharapkan: (1,1200), (2,700), (3,0), (4,0). Periksa ID pelanggan dan jumlah secara tepat. COUNT(o.order_id) diperlukan untuk menghitung pesanan; COUNT(*) juga menghitung baris outer join tanpa pasangan. Periksa NULL dengan IS NULL, bukan = NULL. Lembar jawaban mencakup kasus ini beserta kueri yang dapat dijalankan.

Ubah ketidakcocokan menjadi bukti yang berguna

Catat versi fixture atau data, dialek SQL, kueri, aturan produk, baris yang diharapkan, dan baris aktual. Tentukan pengurutan sebelum membandingkan hasil berurutan. Untuk hasil tanpa urutan, bandingkan himpunan atau multihimpunan sesuai makna duplikat. Kueri yang berhasil dijalankan tidak membuktikan hasil bisnisnya benar.

Lanjutkan belajar

Perluas pemeriksaan ke perilaku database

Laporkan ketidakcocokan data dengan bukti

Unduh fixture SQL bersama

Unduh delapan latihan SQL beserta jawaban

Dokumentasi SQLite: SELECT, outer join, dan filter