Karier di QA

Aplikasi bisa dibuka. Sudah siap dipakai?

Bayangkan toko online yang baru merilis fitur promo.

• Harga diskon benar, tetapi ongkir ikut terpotong.
• Pembayaran berhasil, tetapi pesanan tidak tercatat.
• Tombol bayar ditekan dua kali: muncul dua pesanan.

QA bertanya: apa yang bisa salah, dan siapa yang terdampak?

Apa sebenarnya QA itu?

Quality Assurance: membantu proses menghasilkan kualitas yang baik.

Testing: mengevaluasi produk dan menemukan masalah melalui pemeriksaan.

Di banyak tim, posisi “QA” mencakup keduanya: meninjau kebutuhan, menguji, dan menyampaikan risiko.

Kualitas adalah tanggung jawab seluruh tim.

Kerjaannya dari awal sampai rilis

Kebutuhan → Rencana uji → Pengujian → Temuan → Uji ulang → Rilis

• Sebelum dibuat: tanyakan aturan yang belum jelas.
• Saat dikembangkan: siapkan skenario dan data uji.
• Setelah tersedia: uji, laporkan, lalu verifikasi perbaikan.
• Menjelang rilis: ringkas hasil dan risiko yang masih tersisa.

Sehari sebagai QA: contoh, bukan jadwal baku

Apakah pekerjaan ini cocok untukmu?

• Senang bertanya “kenapa?” dan “bagaimana kalau?”.
• Teliti, tetapi tetap bisa melihat dampak bisnis.
• Mau mengulang, mencatat, dan mencari pola.
• Bisa membahas masalah tanpa menyalahkan orang.

Tantangannya: kebutuhan berubah, waktu terbatas, dan bug kadang sulit diulang.

Pindah bidang? Pengalamanmu tetap berguna

Strategi banting setir yang realistis

1. Baca 10 lowongan target; catat kemampuan yang berulang.
2. Coba satu proyek kecil sebelum membeli banyak kursus.
3. Pelajari dasar, lalu buat bukti kerja yang bisa ditinjau.
4. Cari pengalaman: proyek internal, komunitas, atau peran junior.
5. Evaluasi kesiapan waktu, keuangan, dan proses melamar.

Tentukan langkah pindah berdasarkan bukti progresmu.

Manual dan automation saling melengkapi

Manual bukan “asal klik”; automation bukan “sekali buat, selesai”.

Manual QA: apa yang perlu dipelajari?

• Memahami kebutuhan dan acceptance criteria: syarat fitur diterima.
• Mendesain kasus normal, salah input, dan nilai batas.
• Exploratory testing: belajar sambil menguji secara terarah.
• Menulis test case, bug report, dan ringkasan hasil.
• Memilih pengujian berdasarkan dampak dan kemungkinan masalah.

Latihan: uji aturan gratis ongkir

Aturan fiktif: subtotal setelah diskon ≥ Rp100.000 mendapat gratis ongkir.

Pertanyaan berikutnya: bagaimana jika diskon mengubah subtotal menjadi Rp95.000?

Test case yang bisa dijalankan orang lain

TC-ONGKIR-002 — Tepat di batas gratis ongkir

• Prasyarat: akun uji, alamat valid, aturan promo aktif.
• Data: subtotal setelah diskon Rp100.000; ongkir awal Rp15.000.
• Langkah: buka checkout → pilih alamat → lihat ringkasan.
• Harapan: ongkir Rp0; total Rp100.000; tidak ada biaya lain.
• Catat hasil aktual, status lulus/gagal, build, dan bukti.

Bug report: buat masalahnya bisa diulang

BUG-014 — Ongkir tetap Rp15.000 pada batas promo

• Lingkungan: staging, build demo-1.2, Chrome; akun uji baru.
• Langkah: siapkan subtotal Rp100.000 → buka checkout.
• Aktual: ongkir Rp15.000; total Rp115.000.
• Harapan: ongkir Rp0; total Rp100.000.
• Bukti: screenshot, waktu kejadian, dan respons terkait.

Bekal teknis di luar tampilan aplikasi

Browser DevTools → lihat request gagal, respons, dan console.

HTTP & API → pahami metode, status, JSON, dan autentikasi.

SQL dasar → baca dan cocokkan data lewat SELECT, WHERE, JOIN.

Git → simpan perubahan dan berkolaborasi lewat commit.

API testing: status 200 belum cukup

Contoh respons fiktif dari layanan ongkir:

{ "subtotal": 100000, "shippingFee": 15000 }

• Request berhasil, tetapi aturan bisnis bisa salah.
• Periksa nilai, struktur, hak akses, dan pesan kesalahan.
• Bandingkan respons dengan aturan dan data yang dikirim.

Automation QA: kemampuan tambahannya

Dasar coding → Tes sederhana → Debugging → Suite terawat → CI

• Satu bahasa: variabel, fungsi, kondisi, array, async/await.
• Locator, assertion, data uji, serta setup dan cleanup.
• Git, membaca error, dan menjaga tes tetap independen.
• CI: menjalankan tes otomatis saat ada perubahan kode.

Pilih alat sesuai sasaran

Mulai dari satu jalur; tambah alat ketika ada kebutuhan.

Seperti apa kode automation?

Contoh Playwright pada aplikasi latihan:

import { test, expect } from '@playwright/test';

test('ongkir gratis pada batas promo', async ({ page }) => {
  await page.goto('/checkout-demo');
  await page.getByLabel('Subtotal').fill('100000');
  await page.getByRole('button', { name: 'Hitung' }).click();
  await expect(page.getByTestId('shipping-fee')).toHaveText('Rp0');
});

Buka → Isi → Jalankan → Periksa hasil.

Apa yang layak diotomasi lebih dulu?

Utamakan nilai dan keandalan; jumlah skrip bukan tujuan.

Tes otomatis juga bisa bermasalah

Flaky test: kadang lulus, kadang gagal tanpa perubahan yang relevan.

• Telusuri: bug produk, data, lingkungan, atau kode tes?
• Pakai locator yang stabil dan assertion yang menunggu.
• Isolasi data agar satu tes tidak bergantung pada tes lain.
• Simpan bukti kegagalan; perbaiki penyebabnya.

Rencana belajar 12 minggu

Portofolio: satu proyek yang bisa ditinjau

Pilih aplikasi demo atau proyek milik sendiri.

• Ringkasan produk, cakupan, risiko, dan aturan yang dipakai.
• 10–15 skenario bermakna, hasil uji, dan bukti temuan nyata.
• Latihan API/SQL serta 3–5 tes otomatis bila relevan.
• README: cara menjalankan, batasan, dan keputusan pengujian.

Labeli simulasi sebagai simulasi; jelaskan pekerjaanmu sendiri.

Melamar: tunjukkan cara berpikirmu

CV: pengalaman bidang asal + keterampilan QA + tautan bukti kerja.

Interview: jelaskan satu fitur, risiko, pengujian, temuan, dan keputusanmu.

Latihan: “Waktu tinggal 30 menit sebelum rilis. Apa yang diuji dulu?”

Jawaban kuat: prioritaskan alur kritis dan ungkapkan yang belum teruji.

Setelah masuk, kariernya bisa ke mana?

Mendalam di produk → QA analyst / spesialis domain.

Mendalam di teknik → QA automation / SDET.

Mendalam di keahlian → performance, accessibility, atau security testing.

Mendalam di kepemimpinan → QA lead / quality engineering manager.

AI bisa membantu. Penilaian tetap milikmu.

• Minta ide kasus tepi atau draf skenario.
• Cocokkan jawabannya dengan kebutuhan produk.
• Jalankan dan pahami kode sebelum mengandalkannya.
• Ikuti aturan tim untuk data, rahasia, dan alat yang boleh dipakai.

Tes yang terlihat meyakinkan belum tentu memeriksa hal yang benar.

Mulai minggu ini

Hari 1–2: pilih satu fitur; tulis aturan dan lima risiko.

Hari 3–4: buat lima skenario; jalankan dan simpan hasilnya.

Hari 5–6: rapikan satu laporan; minta masukan orang lain.

Hari 7: jelaskan temuanmu dalam tiga menit.

Pertanyaan diskusi: pengalaman lamamu bisa membantu menguji apa?

Sumber dan bacaan lanjutan

• ISTQB CTFL v4.0.1 — konsep & teknik dasar testing.
• Playwright: Best Practices — locator, assertion, isolasi, debugging.
• Appium Documentation — automation UI, termasuk mobile.

Contoh proyek dan rencana belajar disusun untuk presentasi ini.

Sumber diakses 14 September 2026.