Automated testing adalah praktik menjalankan pengujian secara otomatis agar bug tertangkap sebelum rilis aplikasi sampai ke pengguna. Bayangkan tim yang merilis pembaruan pada Jumat sore. Perubahannya terlihat kecil, hanya merapikan cara menghitung ongkos kirim. Namun, sejam kemudian pelanggan melaporkan bahwa pembayaran gagal, dan tim harus bekerja di akhir pekan untuk memulihkan sistem.
Kejadian seperti ini jarang disebabkan oleh kecerobohan. Aplikasi yang tumbuh punya banyak bagian yang saling bergantung, sehingga satu perubahan bisa memengaruhi bagian lain yang tidak terpikirkan. Pengujian manual tidak sanggup memeriksa semuanya setiap kali ada perubahan, apalagi saat tim ingin merilis lebih sering. Di sinilah pengujian otomatis berperan: pemeriksaan yang sama dijalankan berulang kali oleh kode, bukan oleh manusia.
Artikel ini menjelaskan apa itu automated testing, tujuh alasan pentingnya sebelum aplikasi masuk ke production, jenis-jenisnya, contoh kode dengan Node.js, tools yang umum dipakai, dan cara menjalankannya otomatis lewat CI. Selain itu, Anda akan menemukan langkah memulai, hal yang tidak bisa digantikan oleh tes otomatis, kesalahan umum yang perlu dihindari, dan jawaban atas pertanyaan yang sering diajukan.
Daftar Isi
- Apa itu automated testing
- Mengapa automated testing penting sebelum rilis aplikasi
- 7 alasan automated testing penting
- Jenis automated testing dan piramida pengujian
- Contoh automated testing dengan Node.js
- Tips menulis tes yang baik
- Tools automated testing yang umum dipakai
- Menjalankan automated testing lewat CI
- Yang tidak bisa digantikan automated testing
- Langkah memulai automated testing
- Kesalahan umum dalam automated testing
- Pertanyaan yang sering diajukan
- Daftar periksa automated testing
- Kesimpulan
Apa Itu Automated Testing dan Apa yang Diuji?
Automated testing berarti Anda menulis kode yang memeriksa perilaku aplikasi, lalu menjalankannya otomatis. Setiap tes menyatakan harapan, misalnya “ongkos kirim untuk 1,2 kilogram ke zona dekat adalah Rp16.000”. Jika hasil aplikasi berbeda dari harapan, tes gagal dan tim langsung tahu.
Berbeda dengan pengujian manual, tes otomatis bisa dijalankan ribuan kali tanpa lelah. Sekali ditulis, tes itu menjaga perilaku yang sama pada setiap perubahan kode. Inilah yang membuatnya sangat efektif untuk mencegah regresi, yaitu fitur lama yang rusak akibat perubahan baru. Pemeriksaan semacam ini sering disebut regression testing.
Yang diuji bisa berupa fungsi kecil, interaksi antara beberapa komponen, atau alur lengkap dari sudut pandang pengguna. Kita akan membahas jenis-jenisnya di bagian piramida pengujian.
Mengapa Automated Testing Penting Sebelum Rilis Aplikasi ke Production?
Production adalah lingkungan nyata tempat pengguna sungguhan memakai aplikasi. Kesalahan di sini berdampak langsung: transaksi gagal, data salah, dan kepercayaan pelanggan menurun. Selain itu, memperbaiki bug di production biasanya lebih mahal daripada menangkapnya sebelum rilis, karena tim harus bekerja dengan tekanan, menyiapkan perbaikan darurat, dan kadang menarik kembali perubahan.
Pengujian manual saja tidak cukup untuk menjaga kecepatan. Setiap rilis menuntut pemeriksaan ulang atas fitur yang sudah ada, dan daftar itu terus bertambah. Pada akhirnya tim harus memilih antara merilis lambat atau merilis tanpa cukup jaminan. Automated testing menghilangkan dilema itu dengan memeriksa banyak hal dalam hitungan menit.
7 Alasan Automated Testing Penting sebelum Rilis Aplikasi
1. Bug Tertangkap Lebih Awal
Tes dijalankan saat developer menulis kode atau membuka permintaan penggabungan perubahan. Kesalahan terlihat dalam hitungan menit, saat konteksnya masih segar dan perbaikannya masih murah, bukan berminggu-minggu kemudian lewat laporan pengguna.
2. Regresi Dicegah
Ketika bug ditemukan, tim bisa menulis tes yang mereproduksinya sebelum memperbaikinya. Tes itu lalu tinggal di dalam kumpulan tes selamanya, sehingga bug yang sama tidak muncul lagi tanpa disadari.
3. Rilis Lebih Cepat dan Lebih Percaya Diri
Tim yang punya kumpulan tes yang andal berani merilis lebih sering, karena mereka tahu perubahan melewati pemeriksaan otomatis. Rilis kecil lebih mudah dipahami dan lebih mudah ditarik kembali dibanding rilis besar yang jarang. Pembahasan otomatisasi proses kerja semacam ini ada di Mengapa Perusahaan Mulai Menggunakan Workflow Automation?.
4. Tes Menjadi Dokumentasi yang Hidup
Tes yang ditulis dengan nama jelas menjelaskan perilaku sistem. Developer baru bisa membacanya untuk memahami aturan bisnis, misalnya bagaimana ongkos kirim dihitung atau kapan sebuah pesanan dianggap valid. Berbeda dengan dokumen biasa, tes yang usang akan gagal, sehingga lebih sulit terlupakan.
5. Refactoring dan Modernisasi Lebih Aman
Merapikan atau memperbarui kode lama menakutkan jika tidak ada jaminan perilakunya tetap sama. Dengan tes yang memadai, tim bisa mengubah struktur dengan lebih berani dan segera melihat jika ada yang berubah. Hal ini sangat penting saat memperbarui sistem lama, seperti dibahas di Legacy System Modernization: Kapan Software Lama Perlu Diperbarui?.
6. Beban Pengujian Manual yang Berulang Berkurang
Pemeriksaan yang sama setiap rilis membosankan dan rawan terlewat. Dengan tes otomatis, penguji manusia bisa fokus pada hal yang membutuhkan penilaian, seperti menjelajahi aplikasi dengan cara yang tidak terduga dan menilai kemudahan penggunaan. Aspek terakhir itu dibahas di Mengenal Usability Testing Sebelum Aplikasi Diluncurkan.
7. Jaring Pengaman di Era Kode yang Dibantu AI
Alat bantu AI mempercepat penulisan kode, tetapi hasilnya tetap perlu diverifikasi. Kode yang terlihat benar bisa menyimpan bug halus. Tes otomatis memberi cara objektif untuk memeriksa apakah kode, siapa pun yang menulisnya, memenuhi aturan yang Anda harapkan. Topik ini dibahas di Bagaimana AI Mengubah Cara Developer Membangun Aplikasi?.
Jenis Automated Testing dan Piramida Pengujian
Tidak semua tes sama. Dalam panduan The Practical Test Pyramid di martinfowler.com, pesan utamanya adalah menulis tes dengan tingkat granularitas berbeda, dan semakin tinggi tingkatnya, semakin sedikit tes yang sebaiknya dimiliki. Panduan itu menyarankan banyak tes unit yang kecil dan cepat, beberapa tes yang lebih kasar, dan sangat sedikit tes tingkat tinggi yang menguji aplikasi dari ujung ke ujung.
| Jenis | Yang Diuji | Kecepatan | Jumlah yang Disarankan |
|---|---|---|---|
| Unit test | Satu fungsi atau komponen kecil, misalnya perhitungan ongkir | Sangat cepat | Paling banyak |
| Integration test | Interaksi dengan database, API lain, atau layanan di sekitarnya | Sedang | Cukup |
| End-to-end test | Alur lengkap seperti pengguna, misalnya mendaftar lalu memesan | Lambat | Paling sedikit, fokus pada jalur kritis |
Perlu dicatat, bentuk piramida adalah panduan, bukan hukum. Sebagian praktisi menyukai komposisi lain, misalnya lebih banyak tes integrasi pada sistem berbasis layanan. Prinsip yang tetap berlaku sama: seimbangkan kecepatan umpan balik, tingkat keyakinan, dan biaya perawatan.
Contoh Automated Testing dengan Node.js
Berikut contoh sederhana dengan test runner bawaan Node.js. Pastikan Anda memakai Node.js versi yang masih didukung, misalnya 20 atau lebih baru. Pertama, fungsi yang menghitung ongkos kirim. Contoh ini hanya ilustrasi, jadi aturan dan angka tarifnya sesuaikan dengan bisnis Anda.
// ongkir.js
const TARIF_PER_KG = { dekat: 8000, sedang: 12000, jauh: 18000 };
export function hitungOngkir(beratKg, zona) {
if (!(beratKg > 0)) {
throw new Error('Berat harus lebih dari 0');
}
const tarif = TARIF_PER_KG[zona];
if (!tarif) {
throw new Error('Zona tidak dikenal');
}
return Math.ceil(beratKg) * tarif;
}Kedua, tes yang memeriksa aturan penting, termasuk kasus yang salah. Perhatikan bahwa nama tes menjelaskan perilaku yang diharapkan.
// ongkir.test.js
import test from 'node:test';
import assert from 'node:assert/strict';
import { hitungOngkir } from './ongkir.js';
test('berat dibulatkan ke atas per kilogram', () => {
assert.equal(hitungOngkir(1.2, 'dekat'), 16000);
});
test('zona yang tidak dikenal ditolak', () => {
assert.throws(() => hitungOngkir(1, 'luar-angkasa'), /Zona tidak dikenal/);
});
test('berat nol atau negatif ditolak', () => {
assert.throws(() => hitungOngkir(0, 'dekat'), /Berat/);
assert.throws(() => hitungOngkir(-2, 'dekat'), /Berat/);
});Karena contoh ini memakai sintaks import dan export, proyek Anda perlu mengaktifkan modul ES lewat "type": "module" di package.json. Tanpa baris itu, Node.js akan menganggap berkas .js sebagai CommonJS dan menampilkan galat. Di berkas yang sama, taruh skrip npm test agar mudah dipanggil oleh orang lain dan oleh sistem otomatis.
{
"type": "module",
"scripts": {
"test": "node --test"
}
}Jalankan tes dengan perintah npm test atau langsung node --test. Tes sederhana seperti ini murah ditulis dan sangat cepat berjalan. Karena itu, mulailah dari aturan bisnis yang penting dan sering berubah, seperti harga, diskon, dan validasi.
Mengukur Cakupan Tes (Code Coverage)
Cakupan tes menunjukkan bagian kode mana yang dijalankan oleh tes. Angka ini berguna untuk menemukan area yang belum tersentuh, bukan untuk membuktikan kualitas tes. Pada Node.js, fitur ini tersedia lewat opsi eksperimental, jadi periksa dokumentasi untuk versi yang Anda pakai.
node --test --experimental-test-coverageTips Menulis Tes yang Baik
Tes yang buruk justru menambah beban. Beberapa kebiasaan berikut membuat tes lebih mudah dibaca dan dirawat.
- Ikuti pola Arrange, Act, Assert. Siapkan data, jalankan aksi yang diuji, lalu periksa hasilnya. Tiga langkah yang jelas membuat tes mudah dibaca.
- Satu tes, satu perilaku. Jika tes gagal, Anda langsung tahu bagian mana yang rusak.
- Beri nama berdasarkan perilaku. “Zona yang tidak dikenal ditolak” lebih jelas daripada “tes 2”.
- Buat tes saling independen. Hasil sebuah tes tidak boleh bergantung pada urutan atau hasil tes lain.
- Buat hasilnya konsisten. Hindari ketergantungan pada waktu sekarang, angka acak, atau jaringan. Gunakan data tetap atau tiruan (mock) untuk layanan eksternal, misalnya penyedia pembayaran, agar tes tidak kadang lulus kadang gagal.
- Uji perilaku, bukan cara kerja internal. Dengan begitu, tes tetap lulus saat kode dirapikan selama perilakunya sama.
Tools Automated Testing yang Umum Dipakai
Anda tidak perlu memulai dari nol. Hampir setiap ekosistem punya alat pengujian yang matang. Pilih yang paling umum di ekosistem proyek Anda agar mudah mencari dokumentasi dan bantuan.
| Ekosistem | Unit dan Integration Test | End-to-End Test |
|---|---|---|
| JavaScript dan TypeScript | test runner bawaan Node.js, Jest, Vitest | Playwright, Cypress |
| Python | pytest, unittest | Playwright, Selenium |
| PHP dan Laravel | PHPUnit, Pest | Laravel Dusk, Playwright |
| Java | JUnit | Selenium, Playwright |
| Go | paket testing bawaan | Playwright |
Daftar di atas hanya contoh yang umum, bukan satu-satunya pilihan. Pilih berdasarkan kebutuhan tim, dan jangan ragu memulai dengan alat bawaan karena sering kali sudah cukup.
Menjalankan Automated Testing Otomatis lewat CI
Tes yang hanya dijalankan kalau ingat akan sering terlewat. Karena itu, jalankan tes secara otomatis pada setiap perubahan lewat continuous integration (CI). Contoh berikut memakai GitHub Actions. Versi action dan Node.js perlu Anda sesuaikan dengan yang terbaru dan yang dipakai proyek Anda.
# .github/workflows/pengujian.yml
name: Pengujian
on:
pull_request:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm testPerintah npm ci dan opsi cache: npm mengandalkan berkas package-lock.json, jadi pastikan berkas itu ikut disimpan di repositori. Dengan konfigurasi ini, setiap permintaan penggabungan menjalankan seluruh tes. Anda bisa menjadikan hasil tes sebagai pemeriksaan wajib lewat pengaturan perlindungan cabang (branch protection) atau ruleset di repositori, sehingga penggabungan diblokir jika ada tes yang gagal. Dengan begitu, perubahan yang merusak perilaku penting tidak bisa masuk begitu saja ke cabang utama, apalagi sampai ke production.
Yang Tidak Bisa Digantikan Automated Testing
Tes otomatis kuat, tetapi bukan jawaban untuk semua hal. Beberapa kebutuhan tetap membutuhkan cara lain:
- Kemudahan penggunaan. Tes otomatis memeriksa apakah tombol berfungsi, bukan apakah pengguna paham cara memakainya. Untuk itu, Anda memerlukan pengamatan pengguna nyata.
- Pengujian eksploratif. Manusia menemukan masalah dengan mencoba hal yang tidak terpikirkan oleh penulis tes.
- Kinerja dan beban nyata. Tes fungsi tidak menunjukkan bagaimana aplikasi bertahan saat banyak pengguna datang bersamaan.
- Keamanan. Tes fungsional tidak menggantikan peninjauan keamanan dan pemindaian kerentanan. Prinsip dasarnya ada di Zero Trust Security: Pendekatan Keamanan yang Perlu Dipahami Bisnis Digital.
- Pemantauan setelah rilis. Masalah yang hanya muncul di lingkungan nyata tetap perlu dipantau dan dicatat, misalnya dengan pencatatan seperti di Mengapa Aplikasi Bisnis Perlu Memiliki Sistem Audit Trail?.
Karena itu, anggap automated testing sebagai satu lapisan pengaman di antara beberapa lapisan lain, bukan satu-satunya.
Langkah Memulai Automated Testing
- Mulai dari jalur yang paling penting. Pilih alur yang berdampak besar bila rusak, seperti login, pembayaran, dan pembuatan pesanan.
- Tulis tes untuk bug yang pernah terjadi. Setiap bug yang diperbaiki sebaiknya meninggalkan satu tes.
- Tambahkan tes unit untuk logika bisnis. Fungsi yang berisi aturan, perhitungan, dan validasi paling cocok untuk tes unit.
- Tambahkan tes integrasi untuk batas sistem. Uji interaksi dengan database dan API di sekitarnya.
- Tulis sedikit tes end-to-end untuk jalur kritis. Cukup beberapa alur utama, karena tes ini lambat dan lebih rapuh.
- Jalankan lewat CI pada setiap perubahan. Jadikan hasil tes sebagai syarat sebelum penggabungan.
- Rawat kumpulan tes. Perbaiki tes yang tidak stabil, hapus yang tidak berguna, dan jaga agar tes tetap cepat.
Kesalahan Umum dalam Automated Testing
- Mengejar angka cakupan semata. Cakupan tinggi tidak berarti tes bermakna. Pastikan tes memeriksa perilaku yang penting.
- Terlalu banyak tes end-to-end. Kumpulan tes yang didominasi tes lambat dan rapuh membuat umpan balik lama dan sulit dirawat.
- Tes yang tidak stabil. Tes yang kadang lulus dan kadang gagal tanpa perubahan kode membuat tim kehilangan kepercayaan dan mulai mengabaikannya.
- Menguji detail implementasi. Tes yang terikat pada cara kerja internal gagal setiap kali kode dirapikan, padahal perilakunya sama.
- Tidak menjalankan tes di CI. Tes yang hanya dijalankan sesekali tidak melindungi apa-apa.
- Membiarkan tes yang gagal. Tes yang dimatikan agar rilis lancar menghilangkan fungsinya.
- Tidak memperbarui tes. Aturan bisnis berubah, tes juga harus ikut diperbarui.
- Mengandalkan tes untuk semuanya. Kemudahan penggunaan, keamanan, dan kinerja tetap butuh pemeriksaan lain.
Pertanyaan yang Sering Diajukan tentang Automated Testing
Apa bedanya automated testing dan pengujian manual?
Pengujian manual dikerjakan oleh manusia, sedangkan automated testing dijalankan oleh kode. Pengujian manual unggul untuk eksplorasi dan menilai kemudahan penggunaan. Tes otomatis unggul untuk pemeriksaan berulang yang harus konsisten pada setiap perubahan. Keduanya saling melengkapi, bukan saling menggantikan.
Kapan sebaiknya mulai menulis automated testing?
Idealnya sejak awal pengembangan, tetapi tidak pernah terlambat. Pada aplikasi yang sudah berjalan, mulailah dari jalur kritis dan setiap bug yang diperbaiki. Untuk prototipe yang pasti akan dibuang, investasi tes yang besar mungkin belum sepadan.
Apakah cakupan tes harus 100 persen?
Tidak. Angka cakupan hanya menunjukkan bagian kode yang dijalankan tes, bukan seberapa baik tes tersebut. Fokuskan tes pada logika penting dan jalur yang berisiko tinggi, lalu gunakan laporan cakupan untuk menemukan bagian penting yang terlewat.
Apa itu test-driven development (TDD)?
TDD adalah cara kerja yang menulis tes yang gagal terlebih dahulu, lalu menulis kode agar tes lulus, kemudian merapikan kode. TDD bukan syarat untuk memakai automated testing. Anda tetap bisa menulis tes setelah kodenya ada.
Apakah automated testing menggantikan peran QA?
Tidak. Tes otomatis mengambil alih pemeriksaan berulang, sehingga tim QA bisa fokus pada pengujian eksploratif, kemudahan penggunaan, dan risiko yang sulit ditulis menjadi tes.
Seberapa cepat tes seharusnya berjalan di CI?
Tidak ada angka baku. Prinsipnya, jaga agar cukup singkat sehingga developer tidak enggan menunggunya. Jika kumpulan tes makin lambat, pisahkan tes cepat yang berjalan pada setiap perubahan dari tes lambat yang berjalan lebih jarang.
Daftar Periksa Automated Testing
- Apakah jalur kritis, seperti login dan pembayaran, sudah dilindungi tes?
- Apakah setiap bug yang diperbaiki meninggalkan satu tes?
- Apakah logika bisnis utama punya tes unit?
- Apakah interaksi dengan database dan API diuji?
- Apakah jumlah tes end-to-end dijaga tetap sedikit?
- Apakah tes berjalan otomatis di CI pada setiap perubahan?
- Apakah penggabungan diblokir saat tes gagal?
- Apakah tes yang tidak stabil segera diperbaiki?
Kesimpulan: Automated Testing Membuat Rilis Aplikasi Lebih Aman dan Lebih Cepat
Automated testing penting karena menangkap bug lebih awal, mencegah fitur lama rusak, mempercepat rilis, dan membuat perubahan kode lebih berani dilakukan. Dengan piramida pengujian sebagai panduan, tim menulis banyak tes kecil yang cepat, beberapa tes integrasi, dan sedikit tes menyeluruh untuk jalur kritis.
Mulailah dari yang sederhana. Pilih satu alur yang paling penting, tulis beberapa tes, lalu jalankan otomatis lewat CI. Tambahkan tes setiap kali bug ditemukan. Dengan kebiasaan itu, rilis aplikasi menjadi peristiwa rutin yang tenang, bukan momen yang menegangkan.
Butuh bantuan membangun aplikasi dengan proses pengujian dan rilis yang andal? Tim kami siap membantu lewat layanan pengembangan aplikasi dan website Powercode.
Artikel Menarik Lainnya di Blog Powercode
Lanjutkan membaca topik teknologi lain yang relevan untuk bisnis dan tim pengembang Anda:
- Mengapa Perusahaan Mulai Menggunakan Workflow Automation?
- Bagaimana AI Mengubah Cara Developer Membangun Aplikasi?
- Mengenal Usability Testing Sebelum Aplikasi Diluncurkan
- Legacy System Modernization: Kapan Software Lama Perlu Diperbarui?
- Mengapa Aplikasi Bisnis Perlu Memiliki Sistem Audit Trail?
- Zero Trust Security: Pendekatan Keamanan yang Perlu Dipahami Bisnis Digital