Manual Testing vs Automation Testing: Bedanya, Kapan Dipakai, dan Mana yang Dipelajari Dulu
Perbandingan manual testing dan automation testing untuk QA tester pemula: pengertian, kelebihan dan kekurangan, jenis pengujian yang cocok untuk masing-masing, cara menghitung kapan otomatisasi balik modal, dan urutan belajar yang realistis.
Hampir semua lowongan QA di Indonesia menyebut salah satu dari dua istilah ini: QA manual atau QA automation. Pemula sering bingung: apakah manual testing sudah ketinggalan zaman? Haruskah langsung belajar Selenium atau Playwright? Jawabannya tidak sesederhana memilih satu. Keduanya dipakai berdampingan di hampir setiap tim yang serius menjaga kualitas aplikasi.
Artikel ini melanjutkan apa itu QA tester. Jenis-jenis pengujian dan cara menulis test case dibahas di QA tester: jenis pengujian dan test case.
Pengertian singkat
- Manual testing: manusia menjalankan aplikasi langkah demi langkah sesuai test case, mengamati hasilnya, lalu mencatat apakah sesuai harapan. Alatnya cukup aplikasi itu sendiri, spreadsheet atau tool manajemen test case, dan tool pelaporan bug.
- Automation testing: langkah-langkah pengujian ditulis sebagai kode, lalu dijalankan oleh komputer. Contoh alatnya Playwright, Cypress, atau Selenium untuk tampilan web, Postman atau skrip untuk API, dan framework unit test untuk kode program.
Istilah QC tester di lowongan biasanya merujuk pada orang yang menjalankan pengujian terhadap aplikasi yang sudah jadi, yang sebagian besar masih dilakukan secara manual.
Perbandingan langsung
| Aspek | Manual testing | Automation testing |
|---|---|---|
| Biaya awal | Rendah, bisa langsung mulai | Tinggi, perlu menulis dan merawat skrip |
| Biaya tiap kali diulang | Sama besar setiap kali | Hampir nol setelah skrip jadi |
| Kecepatan | Lambat untuk skenario banyak | Ratusan skenario dalam hitungan menit |
| Menemukan hal tak terduga | Kuat: manusia melihat tampilan aneh, alur membingungkan | Lemah: hanya memeriksa apa yang ditulis di skrip |
| Konsistensi | Bisa terlewat karena lelah atau terburu-buru | Sama persis setiap kali dijalankan |
| Cocok untuk fitur yang sering berubah | Ya | Kurang, skrip sering rusak dan harus diperbaiki |
| Skill utama | Ketelitian, pemahaman bisnis, komunikasi | Coding, desain test, CI/CD |
Pengujian yang sebaiknya tetap manual
- Exploratory testing: mencoba aplikasi seperti pengguna sungguhan tanpa skrip, mencari celah yang tidak terpikirkan saat menulis test case.
- Usability: apakah tombol mudah ditemukan, apakah pesan error dimengerti petugas di lapangan.
- Fitur baru yang masih sering berubah. Mengotomatisasi tampilan yang minggu depan dirombak hanya membuang waktu.
- Pengujian sekali jalan, misalnya verifikasi hasil migrasi data dengan sampel acak.
- User acceptance test (UAT) bersama pengguna. Di proyek aplikasi kesehatan, misalnya, petugas lab atau kasir sendiri yang memastikan alurnya sesuai pekerjaan mereka sehari-hari.
Pengujian yang paling layak diotomatisasi
- Regression test: memastikan fitur lama tidak rusak setiap ada perubahan. Ini paling sering diulang, sehingga paling cepat balik modal.
- Alur kritis: login dan hak akses, perhitungan tagihan, penyimpanan data penting.
- API: lebih stabil daripada tampilan, sehingga skripnya jarang rusak.
- Pengujian dengan banyak kombinasi data, misalnya validasi input dengan puluhan variasi nilai.
- Smoke test setelah deploy: beberapa menit untuk memastikan aplikasi hidup dan fungsi utama berjalan.
Kapan otomatisasi balik modal?
Cara sederhana untuk memutuskan: bandingkan waktu membuat skrip dengan waktu yang dihemat setiap kali pengujian diulang.
Jumlah pengulangan sampai balik modal = waktu membuat skrip ÷ (waktu manual − waktu otomatis per pengujian)
Contoh: satu paket regression berisi 40 skenario butuh 4 jam jika dijalankan manual. Menulis skripnya diperkirakan 24 jam, dan menjalankannya otomatis termasuk memeriksa hasil butuh 30 menit. Penghematan per putaran 3,5 jam, sehingga otomatisasi balik modal setelah 24 ÷ 3,5 ≈ 7 kali rilis. Jika tim merilis setiap minggu, investasinya kembali dalam kurang dari dua bulan. Jika rilis hanya tiga kali setahun, mungkin belum layak, kecuali skenarionya sangat kritis.
Jangan lupa biaya perawatan. Setiap perubahan tampilan bisa membuat skrip gagal walaupun aplikasinya benar. Tambahkan cadangan waktu untuk memperbaiki skrip, dan mulailah dari bagian yang paling jarang berubah.
Piramida pengujian
Banyak tim memakai prinsip piramida pengujian: sebanyak mungkin pengujian di level bawah yang cepat dan murah, dan sedikit di level atas yang lambat.
- Unit test (paling banyak): ditulis programmer, berjalan dalam hitungan detik.
- API atau integration test: memeriksa modul yang saling terhubung, termasuk database dan layanan luar.
- UI end-to-end test (paling sedikit): mensimulasikan klik di browser untuk alur paling penting saja.
- Di puncaknya, exploratory dan UAT manual.
Kesalahan umum adalah membalik piramida: ratusan tes UI otomatis yang lambat dan sering gagal, tetapi hampir tanpa unit test.
Mana yang dipelajari dulu?
Untuk pemula, urutan yang realistis adalah manual dulu, lalu otomatisasi. Alasannya, otomatisasi hanya menjalankan apa yang Anda rancang. Jika belum bisa menyusun test case yang baik, skrip otomatis pun akan menguji hal yang salah dengan sangat cepat.
- Bulan 1–2: dasar testing, menulis test case dan laporan bug, SQL dasar untuk memeriksa data.
- Bulan 3: API testing dengan Postman, termasuk membaca response JSON dan status code.
- Bulan 4–5: satu bahasa pemrograman (JavaScript/TypeScript atau Python) dan satu tool UI automation seperti Playwright.
- Bulan 6: menjalankan tes otomatis di pipeline CI, misalnya GitLab CI atau GitHub Actions, dan menaruh hasilnya di portofolio.
Dari sisi karier, posisi manual tester lebih mudah dimasuki, sedangkan QA automation atau SDET umumnya meminta pengalaman coding dan biasanya ditawari gaji lebih tinggi. Banyak orang memulai sebagai manual tester sambil belajar otomatisasi di proyek yang sama.
Pertanyaan yang sering diajukan
Apakah manual testing akan hilang? Tidak. Otomatisasi menggantikan pengulangan, bukan penilaian. Exploratory testing, usability, dan UAT tetap butuh manusia.
Apakah QA manual perlu bisa coding? Tidak wajib, tetapi SQL dasar dan kemampuan membaca log serta response API sangat membantu dan sering diminta di lowongan.
Tool otomatisasi apa yang sebaiknya dipelajari? Untuk aplikasi web, Playwright dan Cypress populer karena relatif mudah dan cepat. Selenium masih banyak dipakai di proyek lama dan perusahaan besar. Pilih satu, kuasai, lalu konsep yang sama mudah dipindahkan ke tool lain.
Tim kecil tanpa QA khusus, mulai dari mana? Otomatisasi smoke test dan alur paling kritis dulu, lalu jadikan code review dan pengujian silang antar-programmer sebagai kebiasaan. Lihat juga code review untuk tim kecil.