Memahami Testing: Dari Unit Test ke UAT — Fase Paling Krusial di SDLC

Memahami Testing: Dari Unit Test ke UAT — Fase Paling Krusial di SDLC

Series: Memahami SDLC — Part 7 dari 10

Enam artikel sebelumnya kita udah bahas BRD (masalah bisnis), PRD (fitur yang akan dibangun), SRS (spesifikasi teknis), HLD (arsitektur sistem), LLD (rancangan detail), dan Implementasi (kode beneran). Sekarang kita masuk ke fase yang sering dianggap remeh tapi justru paling krusial: Testing atau Quality Assurance.

Banyak tim — terutama startup — yang skip fase testing dengan alasan “buru-buru launch.” Hasilnya? Bug bertebaran di produksi, user komplain, dan tim harus lembur di malam minggu buat hotfix. Ironisnya, memperbaiki bug di produksi biayanya 10 kali lipat dibanding ketemu di fase testing.

Pertanyaannya: gimana caranya testing yang efektif tanpa bikin timeline molor berminggu-minggu?

Kenapa Testing Sering Dilewatin?

Ada beberapa alasan kenapa fase testing sering jadi korban:

1. Deadline gak realistis — manajemen pengen fitur cepet rilis, testing dianggap “bisa nanti” 2. Kurangnya pemahaman — banyak yang kira testing cuma “coba-coba klik” doang 3. Gak ada dedicated QA — developer ngetes kode sendiri, bias konfirmasi tinggi 4. Testing dianggap mahal — padahal lebih murah daripada bug di produksi

Padahal, testing yang baik justru ngirit waktu di jangka panjang. Tim yang punya test coverage bagus bisa nambah fitur baru tanpa takut ngerusak yang lama.

Level-Level Testing di SDLC

Testing bukan cuma satu aktivitas. Ada beberapa level yang harus dilalui, masing-masing dengan tujuan dan metode berbeda.

1. Unit Testing — Ngetes Komponen Paling Kecil

Unit test adalah tes terhadap fungsi atau method terkecil di kode. Biasanya ditulis oleh developer sendiri pake framework seperti Jest (JavaScript), Pytest (Python), atau JUnit (Java).

Apa yang dites: – Apakah fungsi return value yang benar untuk input tertentu? – Apakah error handling jalan sesuai ekspektasi? – Apakah edge cases (input kosong, nilai negatif, null) tertangani?

Best practice: – Satu unit test fokus ke satu perilaku aja – Mock external dependencies (database, API eksternal) – Coverage minimal 70-80% untuk kode bisnis logic – Jalanin otomatis di setiap commit via CI/CD

Contoh sederhana: kalau lo punya fungsi hitungDiskon(harga, persen), unit test harus ngecek: harga normal, harga 0, persen 0, persen 100, dan persen negatif.

2. Integration Testing — Ngetes Interaksi Antar Komponen

Integration test ngecek apakah dua atau lebih komponen bisa bekerja sama dengan benar. Ini penting karena unit test cuma ngecek komponen secara terisolasi — padahal masalah sering muncul pas komponen mulai saling ngobrol.

Apa yang dites: – Apakah API endpoint return response yang benar? – Apakah database query return data sesuai? – Apakah komunikasi antar microservices jalan lancar?

Integration test biasanya lebih lambat dari unit test karena butuh environment yang lebih kompleks (database beneran, server beneran). Makanya, jumlahnya biasanya lebih sedikit.

3. System Testing — Ngetes Seluruh Sistem

System test ngecek aplikasi secara keseluruhan — dari frontend sampai backend, dari login sampai logout. Tujuannya: memastikan semua fitur jalan sesuai spesifikasi yang udah ditulis di SRS.

Jenis-jenis system testing: – Functional testing — ngecek fitur sesuai PRD – Performance testing — ngecek response time, throughput, resource usage – Security testing — ngecek celah keamanan (SQL injection, XSS, dll) – Usability testing — ngecek apakah UI intuitif buat user

System testing biasanya dilakukan oleh tim QA yang terpisah dari developer. Kenapa? Karena developer punya bias — mereka udah tau “harusnya gimana,” jadi cenderung gak nemu bug.

4. User Acceptance Testing (UAT) — Ngetes dari Sisi User

UAT adalah fase terakhir sebelum aplikasi dirilis ke produksi. Bedanya dengan testing sebelumnya: yang ngetes adalah user beneran atau perwakilan klien, bukan tim teknis.

Tujuan UAT: – Memastikan aplikasi sesuai dengan kebutuhan bisnis (BRD) – Validasi workflow dan user journey – Deteksi masalah yang gak kelihatan dari sisi teknis

UAT biasanya dilakukan di environment staging yang mirip produksi. User dikasih skenario tertentu dan diminta jalanin. Hasilnya dicatat sebagai feedback — ada yang diterima (accepted), ada yang ditolak (rejected) dan harus diperbaiki.

Automation vs Manual Testing — Kapan Pake yang Mana?

Banyak perdebatan soal automation vs manual testing. Jawabannya: dua-duanya penting, tergantung konteks.

Automation testing cocok buat: – Regression test (ngecek fitur lama gak rusak) – Performance test (butuh ribuan request simulasi) – Repetitive test case (login, CRUD, validasi form)

Manual testing cocok buat: – Exploratory testing (cari bug dengan cara kreatif) – Usability testing (ngecek pengalaman user) – UAT (user beneran yang ngetes)

Best practice: automation buat hal yang repetitive dan predictable, manual buat hal yang butuh kreativitas dan konteks manusia.

Testing di CI/CD Pipeline

Tim modern biasanya ngeintegrasikan testing ke dalam CI/CD pipeline. Setiap kali developer push kode, otomatis:

1. Lint & format check — ngecek gaya kode 2. Unit test — jalan dalam 1-2 menit 3. Build — kompilasi aplikasi 4. Integration test — jalan di environment terisolasi 5. Security scan — ngecek dependency vulnerability 6. Deploy ke staging — kalo semua lolos 7. E2E test — jalan di staging

Kalo ada yang gagal di tengah, pipeline berhenti dan developer dapat notifikasi. Gak ada kode yang bisa masuk ke produksi tanpa lolos semua gate.

Common Mistakes di Fase Testing

Berdasarkan pengalaman tim-tim yang udah berkali-kali lewatin fase ini, berikut kesalahan yang paling sering terjadi:

1. Test coverage tinggi tapi kualitas rendah. 90% coverage gak ada artinya kalo test cuma ngecek path yang “happy” doang. Pastikan test juga ngecek error handling dan edge cases.

2. Testing di environment yang beda sama produksi. Kalo staging pake database MySQL 5.7 tapi produksi pake 8.0, siap-siap aja kejutan. Usahakan environment staging semirip mungkin dengan produksi.

3. Gak ada regression test. Tim nambah fitur baru, fitur lama rusak, dan gak ada yang sadar sampe user komplain. Regression test otomatis adalah safety net yang wajib ada.

4. Testing cuma pas akhir sprint. Testing harus jalan paralel dengan development. Jangan nunggu semua kode selesai baru dites — backlog bug bakal numpuk dan gak kehandle.

Tools Testing Populer 2026

Buat yang baru mau mulai, berikut tools yang lagi populer di 2026:

| Kategori | Tools | |—|—| | Unit Test (JS) | Vitest, Jest, Playwright | | Unit Test (Python) | Pytest, unittest | | Unit Test (Java) | JUnit 5, TestNG | | API Testing | Postman, Bruno, Supertest | | E2E Testing | Playwright, Cypress, Selenium | | Performance | k6, Locust, Artillery | | Security | OWASP ZAP, SonarQube, Snyk |

Kesimpulan

Fase testing bukanlah “tambahan” di SDLC — ini adalah fase yang nentuin apakah aplikasi lo siap dipake atau cuma jadi bom waktu. Investasi di testing di awal bakal ngirit biaya, waktu, dan reputasi tim di jangka panjang.

Mulai dari yang kecil: tulis unit test buat fungsi bisnis yang paling kritis. Tambahin integration test buat API endpoint utama. Terakhir, setup CI/CD yang otomatis jalanin test di setiap commit.

Gak perlu sempurna dari awal. Yang penting konsisten dan bertahap. Karena tim yang punya budaya testing yang baik adalah tim yang bisa tidur nyenyak setelah rilis.

Baca juga: 5G di Indonesia 2026, Operator Mana yang Paling Siap dan Terjangkau.

Baca juga: Perang Chipset 2026: MediaTek Dimensity 9400 vs Snapdragon 8 Gen 4 — Siapa Palin.