Pengantar Automation
Kenapa perusahaan butuh test otomatis, dan kapan sebaiknya (atau tidak perlu) diotomasi.
Automation testing membuat pengecekan rutin berjalan sendiri, supaya waktumu dipakai untuk mencari bug yang belum terpikirkan.
Ingat regression test sebelum rilis: test case yang sama dijalankan ulang di setiap build. Automation testing adalah test case itu, ditulis sekali sebagai kode, lalu komputer yang menjalankannya setiap kali dibutuhkan.
Apa itu automation testing?
Automation testing adalah program kecil yang menjalankan langkah di aplikasi, lalu mengecek hasilnya. Contoh: 40 skenario di 3 browser berarti 120 pengecekan manual setiap rilis. Test otomatis menjalankannya dalam beberapa menit.
Setiap test punya tiga langkah:
buka halaman login
isi username & password, klik Masuk
apakah muncul "Halo, Rina Wulandari"?
Langkah ketiga yang paling penting. Script yang hanya mengklik tanpa mengecek hasil belum bisa disebut test. Pengecekan ini disebut assertion, dibahas di Modul 6.
Tiga langkah ini sama dengan isi test case yang biasa kamu tulis: precondition, test steps, dan expected result. Assertion adalah expected result yang dicek oleh komputer.
Manual vs automation: satu tim
| Manual testing | Automation testing | |
|---|---|---|
| Kecepatan | Lambat kalau diulang | Cepat, bisa jalan paralel |
| Ketelitian | Bisa lupa atau salah langkah | Selalu sama persis |
| Biaya di awal | Kecil | Besar, karena menulis kode |
| Biaya jangka panjang | Bertambah setiap rilis | Makin hemat, sekali tulis dipakai berkali-kali |
| Menemukan bug baru | Jago, memakai intuisi | Kurang, hanya mengecek yang ditulis |
| Menilai tampilan dan kenyamanan | Hanya manusia | Tidak bisa |
| Mengecek fitur lama masih aman | Membosankan | Paling cocok |
Automation tidak menggantikan QA manual. Automation mengambil pekerjaan yang berulang, supaya kamu punya waktu untuk mencari celah dan menilai risiko.
Test pyramid: test ditaruh di mana?
- Unit test mengecek potongan kecil kode. Biasanya ditulis developer.
- API test mengecek jalur data antara tampilan dan server. Cepat dan stabil, dibahas di Modul 13.
- UI atau End-to-End (E2E) test membuka browser sungguhan dan bertindak seperti pengguna. Di sinilah Playwright paling berguna.
Test E2E paling lambat dan paling mudah gagal tanpa sebab yang jelas. Pakai untuk alur yang benar-benar penting, sisanya lewat API test.
Kapan sebaiknya diotomasi?
| Cocok diotomasi | Lebih baik manual |
|---|---|
| Pengecekan rutin setiap rilis | Fitur yang tampilannya masih berubah setiap hari |
| Alur penting: login, pembayaran, checkout | Mencari celah dengan mencoba-coba (exploratory testing) |
| Skenario dengan banyak kombinasi data | Menilai tampilan dan kenyamanan |
| Pengecekan di banyak browser atau perangkat | Test sekali pakai yang tidak akan diulang |
| Cek cepat setelah rilis (smoke test) | Skenario yang butuh CAPTCHA atau OTP dari HP |
Hitungannya sederhana. Satu skenario manual butuh 5 menit, di 3 browser, 4 rilis sebulan: total 60 menit per bulan. Menulis test-nya sekitar 2 jam, jadi balik modal dalam 2 bulan.
Cara berpikir automation engineer
- Test juga kode. Harus rapi, mudah dibaca, dan ikut direview.
- Setiap test berdiri sendiri. Dijalankan sendirian atau dalam urutan apa pun, hasilnya sama.
- Test yang gagal memberi petunjuk. Pesannya menyebut yang diharapkan (expected) dan yang terjadi (actual).
- Hindari test flaky. Test yang kadang lulus kadang gagal tanpa perubahan membuat tim berhenti percaya.
- Curigai test yang tidak pernah gagal. Rusak aplikasinya dengan sengaja. Kalau test tetap hijau, test itu tidak mengecek apa pun.
Contoh test yang nanti kamu tulis
Belum perlu paham semua barisnya, setelah Fase 2 kamu bisa menulisnya sendiri. Ganti bahasa di pojok kanan atas untuk melihat versi lainnya.
def test_login_berhasil(page): # satu test case, page = tab browser
# 1. Siapkan: buka halaman login
page.goto("/login-toko.html")
# 2. Aksi: isi form lalu klik Masuk
page.get_by_label("Username").fill("customer") # isi kolom Username
page.get_by_label("Password").fill("rahasia123") # isi kolom Password
page.get_by_role("button", name="Masuk").click() # klik tombol Masuk
# 3. Periksa: sapaan harus menyebut nama customer
expect(page.get_by_test_id("greeting")).to_have_text("Halo, Rina Wulandari")test('login berhasil', async ({ page }) => { // satu test case, page = tab browser
// 1. Siapkan: buka halaman login
await page.goto('/login-toko.html');
// 2. Aksi: isi form lalu klik Masuk
await page.getByLabel('Username').fill('customer'); // isi kolom Username
await page.getByLabel('Password').fill('rahasia123'); // isi kolom Password
await page.getByRole('button', { name: 'Masuk' }).click(); // klik tombol Masuk
// 3. Periksa: sapaan harus menyebut nama customer
await expect(page.getByTestId('greeting')).toHaveText('Halo, Rina Wulandari');
});Komentar 1, 2, dan 3 menandai tiga langkah tadi: siapkan, aksi, periksa.
Lebih jauh (opsional)Trik komunitas
- Testing Trophy. Banyak tim frontend memakai model "piala": lebih banyak integration test dan pengecekan otomatis di kode (TypeScript, linter), dengan sedikit test E2E. Pesannya sama: E2E sedikit saja, untuk alur paling penting.
- Mulai dari yang paling berisiko. Urutkan skenario berdasarkan seberapa parah kalau rusak dan seberapa sering rusak. Login dan pembayaran biasanya juara pertama.
- Minta
data-testidsejak awal. Ajak developer memberi label khusus test di elemen penting sejak fitur dibuat. Aplikasi di Playground sudah memakaidata-testid, jadi kamu bisa melihat contohnya. - Tulis skenarionya dalam kalimat biasa dulu, misalnya pola Given, When, Then (diberikan, ketika, maka). Kalimat seperti ini juga mudah diberikan ke AI agent di Modul 16.
Latihan
Belum ada kode di modul ini. Latihannya mencoba aplikasi seperti pengguna, karena automation selalu dimulai dari paham aplikasinya.
Jadi customer TokoQA selama 10 menit
Brief: sebelum menulis test, coba alur belanja TokoQA dari awal sampai akhir.
- Buka TokoQA, lalu login sebagai
customer/rahasia123. - Ketik
mousedi kolom pencarian. Berapa produk yang tersisa? - Kosongkan pencarian, lalu pilih kategori Furnitur. Produk apa saja yang muncul?
- Masukkan 2 produk ke keranjang, checkout, lalu bayar sampai nomor pesanan muncul.
- Buka Pesanan saya. Apa status pesananmu?
Hasilkamu punya nomor pesanan berawalan TQA- dan tahu statusnya
- Pencarian
mousemenyisakan 1 produk (Mouse Wireless). - Kategori Furnitur berisi 2 produk: Kursi Ergonomis dan Meja Lipat.
- Tas Laptop tidak bisa dibeli karena stoknya habis. Tombolnya tidak bisa diklik.
- Setelah bayar, muncul judul "Pesanan berhasil!" dengan nomor seperti
TQA-1003. - Di Pesanan saya, statusnya Baru, karena belum diproses admin.
Setiap poin di atas adalah calon test yang akan kamu otomasi nanti.
Bandingkan peran customer dan admin
Brief: TokoQA punya dua peran, dan test untuk masing-masing peran berbeda.
- Buka menu profil (nama di kanan atas), tekan Keluar, lalu login sebagai
admin/admin123. Kamu dibawa ke halaman apa? - Cari pesananmu dari latihan sebelumnya, lalu ubah statusnya menjadi Dikirim.
- Keluar, login lagi sebagai
customer, lalu buka Pesanan saya. - Terakhir, coba login dengan akun
terkunci/rahasia123.
Hasilcustomer melihat status pesanannya berubah menjadi Dikirim
- Admin langsung masuk ke Dashboard admin, bukan ke toko. Tidak ada tombol keranjang, karena admin tidak berbelanja.
- Admin melihat pesanan semua customer dan bisa mengubah statusnya. Setelah diubah, muncul notifikasi "Status TQA-... diubah menjadi Dikirim".
- Customer melihat status Dikirim di halaman Pesanan saya.
- Akun terkunci ditolak dengan pesan "Akun kamu terkunci. Hubungi admin."
Ini alur dua peran: satu orang melakukan sesuatu, orang lain melihat hasilnya. Di Modul 13, kamu mengotomasi alur ini dengan dua browser context sekaligus.
Pilih skenario yang layak diotomasi
Tulis 5 skenario dari aplikasi tadi. Tandai masing-masing otomasi atau manual, lalu beri alasan dalam satu kalimat.
Hasiltabel 5 baris berisi keputusan dan alasannya
Contoh jawaban (alasanmu boleh berbeda, asal masuk akal):
| Skenario | Keputusan | Alasan |
|---|---|---|
| Login berhasil dan gagal | Otomasi | Dijalankan setiap rilis, langkahnya selalu sama |
| Belanja sampai pesanan berhasil | Otomasi | Alur paling penting, kalau rusak toko tidak menghasilkan uang |
| Validasi form checkout | Otomasi | Banyak kombinasi data, cocok untuk data-driven test |
| Tampilan terasa rapi dan enak dilihat | Manual | Butuh penilaian manusia |
| Fitur baru yang desainnya masih sering berubah | Manual dulu | Test otomatis akan sering rusak kalau tampilannya belum stabil |