QA lead Anda bilang "lakukan stress test" ÔÇö tapi yang Anda jalankan ternyata load test biasa. Hasilnya? Sistem lolos pengujian dengan skor sempurna, tapi crash saat event promo karena tidak pernah diuji melampaui batas kapasitas. Bug ini bukan di kode ÔÇö melainkan di kesalahpahaman istilah testing.
Ini bukan masalah sepele. Menurut pengalaman kami mendampingi tim QA di sektor perbankan, lebih dari separuh tim masih mencampuradukkan kedua istilah ini. Akibatnya: test plan yang salah, hasil yang tidak relevan, dan keputusan go-live yang berbahaya.
Artikel ini membedah perbedaan mendasar stress testing dan load testing menurut standar ISTQB CT-PT ÔÇö lengkap dengan tabel perbandingan dan contoh skenario mobile banking yang bisa langsung Anda adaptasi.
Definisi Menurut ISTQB
Load Testing
Menurut ISTQB Glossary:
"A type of performance testing conducted to evaluate the behavior of a component or system with increasing load, e.g., numbers of parallel users and/or numbers of transactions, to determine what load can be handled by the component or system."
Intinya: Load testing menguji sistem pada beban yang diharapkan ÔÇö apakah sistem mampu menangani jumlah pengguna dan transaksi sesuai proyeksi bisnis?
Stress Testing
Menurut ISTQB Glossary:
"A type of performance testing conducted to evaluate a system or component at or beyond the limits of its anticipated or specified workloads, or with reduced availability of resources such as access to memory or servers."
Intinya: Stress testing mendorong sistem melampaui batas normalnya ÔÇö untuk menemukan titik patah (breaking point) dan memastikan sistem bisa pulih dengan baik.
Tabel Perbandingan
| Aspek | Load Testing | Stress Testing |
|---|---|---|
| Tujuan | Verifikasi performa pada beban normal/puncak | Menemukan breaking point dan kemampuan recovery |
| Beban | Sesuai expected load (100% kapasitas) | Melebihi expected load (120-200%+ kapasitas) |
| Fokus | Apakah SLA terpenuhi? | Kapan dan bagaimana sistem gagal? |
| Durasi | Durasi operasional normal (30 menit - 2 jam) | Hingga sistem gagal atau menunjukkan degradasi |
| Resource | Semua resource tersedia normal | Resource mungkin dikurangi (kill server, reduce memory) |
| Hasil yang diharapkan | Sistem berjalan normal, SLA terpenuhi | Sistem akhirnya gagal ÔÇö yang penting: bagaimana gagalnya |
| Kapan dilakukan | Setiap release, sebelum go-live | Saat capacity planning, BCP/DR testing |
| Metrik utama | Response time, throughput, error rate | Breaking point, recovery time, failure mode |
| Contoh | 5.000 users login bersamaan (sesuai proyeksi) | 50.000 users login bersamaan (10x proyeksi) |
Analogi Sederhana
Bayangkan sebuah jembatan yang dirancang untuk menahan beban 10 ton:
- Load testing = Melewatkan kendaraan dengan total beban 10 ton. Apakah jembatan tetap stabil? Apakah ada getaran berlebih?
- Stress testing = Melewatkan kendaraan dengan beban 15 ton, 20 ton, 25 ton... hingga menemukan di titik berapa jembatan mulai retak. Dan apakah retakan bisa diperbaiki?
Contoh Skenario: Aplikasi Mobile Banking
Skenario Load Testing
Proyeksi bisnis menunjukkan 5.000 nasabah mengakses mobile banking secara bersamaan pada jam sibuk (08:00-10:00 hari kerja).
Test plan:
- Simulasikan 5.000 concurrent users
- Ramp-up: 10 menit (500 users per menit)
- Steady state: 30 menit pada beban puncak
- Skenario: login  cek saldo  transfer  logout
- Think time: 3-5 detik antar aksi
Kriteria lulus:
- Response time login < 2 detik
- Response time transfer < 3 detik
- Throughput > 100 TPS
- Error rate < 0.5%
Hasil: Jika semua kriteria terpenuhi  sistem siap production.
Skenario Stress Testing
Apa yang terjadi saat gajian PNS (tanggal 1) dan semua nasabah login bersamaan?
Test plan:
- Mulai dari 5.000 users (beban normal)
- Naikkan ke 10.000  20.000  30.000  50.000 users
- Pada setiap level, ukur response time dan error rate
- Lanjutkan hingga error rate > 10% atau response time > 30 detik
- Setelah menemukan breaking point, turunkan beban ke normal
- Ukur: berapa lama sistem pulih ke performa normal?
Yang ingin diketahui:
- Breaking point ada di berapa users?
- Apa yang gagal duluan? (database? connection pool? memory?)
- Apakah sistem crash total atau graceful degradation?
- Berapa lama recovery time setelah beban diturunkan?
- Apakah ada data yang corrupt selama stress?
Jenis Performance Testing Lainnya
Selain load testing dan stress testing, ISTQB CT-PT mendefinisikan 5 jenis lainnya. Memahami perbedaannya penting untuk memilih pendekatan yang tepat:
| Jenis | Tujuan | Kapan Digunakan |
|---|---|---|
| Load Testing | Verifikasi pada beban normal | Setiap release |
| Stress Testing | Menemukan breaking point | Capacity planning, BCP |
| Spike Testing | Respons terhadap lonjakan mendadak | Flash sale, pengumuman hasil |
| Endurance Testing | Stabilitas di bawah beban konstan lama | Deteksi memory leak (8-72 jam) |
| Scalability Testing | Kemampuan scaling saat resource ditambah | Sebelum scaling infrastruktur |
| Capacity Testing | Menentukan kapasitas maksimum | Perencanaan infrastruktur |
| Concurrency Testing | Perilaku saat operasi sama dilakukan bersamaan | Deteksi deadlock, race condition |
Untuk penjelasan lengkap setiap jenis, baca: Apa Itu Load Testing? Panduan Lengkap Berdasarkan Standar ISTQB
Tools yang Digunakan
Load testing dan stress testing menggunakan tools yang sama ÔÇö yang berbeda adalah konfigurasinya:
| Tools | Bahasa | Kelebihan | Cocok Untuk |
|---|---|---|---|
| Apache JMeter | Java | Open source, multi-protocol, GUI + CLI | Standar industri perbankan Indonesia |
| Gatling | Scala | Report visual, code-first approach | Developer yang familiar coding |
| k6 (Grafana) | JavaScript | Modern, ringan, CI/CD native | Tim DevOps |
| Locust | Python | Mudah dipelajari, distributed | Tim Python |
| Artillery | JavaScript | YAML config, cloud-native | Microservices testing |
Untuk tutorial hands-on menggunakan JMeter, baca: Cara Load Testing dengan JMeter: Tutorial Step-by-Step
Kapan Menggunakan Masing-Masing?
Gunakan Load Testing ketika:
- Sebelum deployment ke production (validasi SLA)
- Setelah perubahan infrastruktur (upgrade server, migrasi database)
- Secara berkala sesuai jadwal audit (POJK 11/2022)
- Setelah major release atau perubahan arsitektur
Gunakan Stress Testing ketika:
- Melakukan capacity planning (berapa server yang dibutuhkan?)
- Mempersiapkan Business Continuity Plan (BCP)
- Menguji Disaster Recovery (DR) ÔÇö apa yang terjadi jika satu data center down?
- Sebelum event dengan traffic spike (flash sale, periode laporan keuangan)
- Mengevaluasi failover mechanism
Kesalahan Umum
- Hanya melakukan load testing tanpa stress testing ÔÇö Anda tahu sistem berjalan normal, tapi tidak tahu kapan dan bagaimana sistem gagal.
- Menggunakan beban yang tidak realistis ÔÇö Beban load test harus berdasarkan data produksi nyata, bukan angka acak.
- Tidak mendokumentasikan environment ÔÇö Hasil test hanya valid untuk environment tertentu. Catat spesifikasi server, versi software, dan konfigurasi jaringan.
- Mengabaikan recovery testing dalam stress test ÔÇö Mengetahui breaking point saja tidak cukup. Yang lebih penting: apakah sistem bisa pulih?
Load Testing dan Stress Testing di Industri Teregulasi
Untuk bank, asuransi, dan fintech Indonesia:
- POJK 11/2022 mewajibkan pengujian performa dan stress testing untuk sistem core banking
- Stress testing regulasi ÔÇö berbeda dari stress testing teknis. OJK memiliki skenario stress testing khusus untuk ketahanan finansial, namun stress testing TI juga diperlukan sebagai bagian dari Business Continuity Management
- Dokumentasi ÔÇö Seluruh hasil load test dan stress test harus terdokumentasi dan dapat diaudit
- Frekuensi ÔÇö Minimal dilakukan saat ada perubahan major dan secara berkala (quarterly atau semi-annual)
Kuasai Performance Testing
Untuk menguasai seluruh jenis performance testing secara hands-on, Frans Training menyediakan program Performance & Load Testing dengan JMeter yang mencakup:
- Praktik langsung: load testing, stress testing, spike testing, dan endurance testing
- Skenario industri riil: core banking, payment gateway, e-commerce
- Analisis bottleneck dan capacity planning
- Penyusunan test report yang memenuhi standar audit OJK
- Sertifikat pelatihan yang diakui di sektor perbankan
Konsultasi gratis dengan tim kami untuk menentukan program pelatihan yang tepat bagi tim QA dan engineering Anda.
Referensi
- ISTQB Glossary ÔÇö Load Testing
- ISTQB Glossary ÔÇö Stress Testing
- ISTQB CT-PT Syllabus
- ISO/IEC 25010:2011 ÔÇö Systems and Software Quality Requirements and Evaluation
Contoh Skenario Lanjutan: E-Commerce Flash Sale
Skenario Load Testing ÔÇö Flash Sale
Proyeksi marketing menunjukkan 50.000 pengguna akan mengakses halaman flash sale dalam 5 menit pertama.
Test plan:
- Simulasikan 50.000 concurrent users
- Ramp-up: 5 menit
- Skenario: buka halaman promo  tambah ke keranjang  checkout  pembayaran
- Kriteria lulus: response time checkout < 5 detik, error rate < 2%
Skenario Stress Testing ÔÇö Flash Sale
Apa yang terjadi jika viral di media sosial dan traffic 5x lipat dari proyeksi?
Test plan:
- Mulai dari 50.000 users (proyeksi normal)
- Naikkan ke 100.000  150.000  250.000
- Ukur: kapan pertama kali checkout mulai gagal?
- Turunkan beban ÔÇö berapa lama sistem pulih?
- Apakah ada pesanan yang corrupt (paid tapi tidak tercatat)?
Checklist: Sudah Melakukan Kedua Jenis Test?
| Checklist | Load Test | Stress Test |
|---|---|---|
| Target beban berdasarkan data produksi? | Ya/Tidak | Ya/Tidak |
| SLA/acceptance criteria didefinisikan? | Ya/Tidak | Ya/Tidak |
| Test environment mirip production? | Ya/Tidak | Ya/Tidak |
| Resource monitoring aktif selama test? | Ya/Tidak | Ya/Tidak |
| Hasil terdokumentasi untuk audit? | Ya/Tidak | Ya/Tidak |
| Recovery test dilakukan setelah stress? | N/A | Ya/Tidak |
FAQ
Apakah harus melakukan load test dulu sebelum stress test?
Ya, selalu. Load test memvalidasi bahwa sistem berjalan normal pada beban expected. Stress test tanpa baseline load test tidak memiliki konteks ÔÇö Anda tidak tahu apakah kegagalan terjadi karena desain yang buruk atau memang karena beban yang extreme.
Berapa lama recovery time yang acceptable?
Tergantung SLA bisnis. Untuk core banking, recovery time setelah stress biasanya harus < 5 menit. Untuk e-commerce, < 15 menit masih acceptable. Yang penting: sistem harus pulih tanpa intervensi manual.
Apakah stress testing bisa merusak data production?
Jangan pernah menjalankan stress test di production environment. Selalu gunakan environment terpisah dengan data sintetis. Stress test dirancang untuk membuat sistem gagal ÔÇö Anda tidak ingin itu terjadi pada data nasabah riil.
Berhenti Menebak: Kuasai Kedua Teknik dalam 3 Hari
Apakah tim QA Anda sudah menjalankan kedua jenis test ini secara benar? Kebanyakan tim hanya melakukan load testing dan melewatkan stress testing ÔÇö hingga sistem gagal di production saat event yang tidak terduga.
Dalam pelatihan Performance & Load Testing dengan JMeter, tim Anda akan praktik langsung:
- Load testing dengan 5.000 concurrent users (skenario banking)
- Stress testing hingga menemukan breaking point
- Spike testing untuk simulasi flash sale
- Analisis bottleneck dan penyusunan rekomendasi