Bab 6: Integration, System & Acceptance Testing

📖 Bagian 1: Integration Testing

Integration Testing adalah pengujian yang menguji interaksi antar komponen/modul yang sudah diuji secara individual (unit test). Tujuannya memastikan komponen-komponen tersebut bisa bekerja sama dengan benar.

Analogi

Unit testing = tes setiap pemain bola satu per satu (dribble, tendangan). Integration testing = tes apakah pemain-pemain ini bisa kerja sama (passing, strategi). Masing-masing pemain mungkin jago sendiri, tapi belum tentu bisa kompak.

Pendekatan Integration Testing

1. Big Bang Integration

Semua komponen digabung sekaligus dan diuji bersama-sama.

✅ Kelebihan: Mudah dan cepat untuk sistem kecil
❌ Kekurangan: Kalau ada error, sulit menemukan sumber masalah karena semua digabung sekaligus

2. Incremental Integration (Bertahap)

Komponen digabung dan diuji satu per satu secara bertahap. Ada 2 sub-pendekatan:

🔽 Top-Down

Pengujian dimulai dari modul paling atas (level tertinggi), lalu turun ke modul di bawahnya.

Modul bawah yang belum siap digantikan oleh Stub (komponen tiruan sederhana).

Urutan: Main Module → Sub-Module → Detail Module

🔼 Bottom-Up

Pengujian dimulai dari modul paling bawah (level terendah), lalu naik ke atas.

Modul atas yang belum siap digantikan oleh Driver (komponen yang memanggil modul bawah).

Urutan: Detail Module → Sub-Module → Main Module

💡 Tips Hafalan Pendekatan Integrasi

Big Bang = "Duarrr semua langsung" → gabungin semua sekaligus
Top-Down = "Dari atap ke lantai" → pakai Stub (pengganti modul bawah)
Bottom-Up = "Dari fondasi ke atap" → pakai Driver (pengganti modul atas)
Ingat: Stub = yang dibawah (karena stub itu "tiang" yang menopang dari bawah), Driver = yang menggerakkan dari atas

🎭 Test Doubles (SANGAT PENTING!)

Test Double adalah objek pengganti yang digunakan saat testing untuk menggantikan komponen asli yang belum siap atau sulit diakses. Ada 4 jenis:

Jenis	Penjelasan	Contoh
Dummy	Objek yang dikirim tapi tidak benar-benar digunakan. Hanya sebagai pengisi parameter.	Mengirim objek kosong ke fungsi yang butuh parameter tapi isinya tidak penting untuk tes ini
Fake	Implementasi nyata tapi disederhanakan. Berfungsi, tapi tidak untuk production.	In-memory database (database palsu yang hidup di memori, bukan database sungguhan)
Stub	Mengembalikan data statis/hardcoded yang sudah ditentukan sebelumnya. Untuk state verification.	Fungsi yang selalu return "LUNAS" tanpa cek apapun
Mock	Objek dinamis yang bisa memverifikasi apakah method dipanggil dengan benar (parameter, frekuensi). Untuk behavior verification.	Memverifikasi bahwa method send_email() dipanggil tepat 1 kali dengan parameter yang benar

⚠️ WAJIB PAHAM: Stub vs Mock

Ini yang paling sering keluar di soal dan paling sering membingungkan:

Aspek	Stub	Mock
Sifat	Statis (hardcoded)	Dinamis (berdasarkan ekspektasi)
Apa yang diverifikasi?	State — "Apakah HASIL-nya benar?"	Behavior — "Apakah METHOD-nya dipanggil dengan benar?"
Mengembalikan	Nilai tetap yang sudah ditentukan	Bisa bervariasi + mencatat pemanggilan
Contoh di kode	`return "LUNAS"` (selalu)	`verify(mock).sendEmail("user@mail.com")`

Contoh Kode: Stub

# STUB: Selalu mengembalikan nilai statis "LUNAS"
class StubPaymentService:
    def check_payment_status(self, order_id):
        return "LUNAS"   # ← Selalu "LUNAS", tidak peduli order_id apa

# Penggunaan dalam test:
def test_order_completion():
    stub = StubPaymentService()
    result = stub.check_payment_status("ORDER-123")
    assert result == "LUNAS"  # State verification: cek NILAI hasilnya

Contoh Kode: Mock

# MOCK: Memverifikasi bahwa method dipanggil dengan benar
from unittest.mock import Mock

def test_send_notification():
    mock_email = Mock()
    
    # Panggil fungsi yang menggunakan email service
    process_order(email_service=mock_email)
    
    # Behavior verification: cek APAKAH method dipanggil
    mock_email.send_email.assert_called_once_with("user@mail.com")
    # ↑ Bukan cek hasilnya, tapi cek PERILAKUNYA

💡 Tips Hafalan Stub vs Mock

Stub = "Statis" & "State" → Nilai tetap, cek hasil
Mock = "Monitoring" & "Method call" → Dinamis, cek apakah method dipanggil
Kalau di soal ada kode yang selalu return nilai yang sama → itu Stub
Kalau di soal ada verify() atau assert_called() → itu Mock

📖 Bagian 2: System Testing

System Testing adalah pengujian terhadap keseluruhan sistem yang sudah terintegrasi. Sistem diuji sebagai satu kesatuan yang utuh.

Jenis-Jenis System Testing

Jenis	Menguji Apa?	Contoh
Functional Testing	Apakah fitur-fitur berfungsi sesuai requirement	Login, checkout, search berjalan benar
Performance Testing	Kecepatan dan kemampuan sistem	Response time < 2 detik
Security Testing	Keamanan sistem dari ancaman	SQL Injection, XSS tidak bisa dilakukan
Compatibility Testing	Kompatibilitas dengan berbagai platform	Berjalan di Chrome, Firefox, Safari
Usability Testing	Kemudahan penggunaan	User bisa menyelesaikan task tanpa kebingungan
Recovery Testing	Kemampuan sistem pulih dari kegagalan	Sistem bisa restart setelah crash

📖 Bagian 3: Acceptance Testing

Acceptance Testing adalah pengujian terakhir sebelum software dianggap siap digunakan. Tujuannya memastikan software memenuhi kebutuhan bisnis dan diterima oleh pengguna/stakeholder.

Ada 2 jenis utama:

1. UAT (User Acceptance Testing)

Pengujian oleh pengguna akhir (end user) untuk memastikan software sesuai kebutuhan mereka.

Alpha Testing

Dilakukan di lingkungan pengembang (internal)
Oleh tim internal atau penguji yang dipilih
Sebelum dirilis ke publik

Beta Testing

Dilakukan di lingkungan pengguna (eksternal)
Oleh pengguna sungguhan yang dipilih
Feedback dikumpulkan sebelum rilis final

Contoh UAT

Skenario: Seorang mahasiswa mencoba fitur pengisian IRS (Isian Rencana Studi) di SIAKAD — menambah mata kuliah, menyimpan, dan mencetak KRS. Jika semua berjalan lancar dan sesuai kebutuhan, UAT berhasil.

2. OAT (Operational Acceptance Testing)

Pengujian oleh tim operasional/IT untuk memastikan software siap di-operasikan di production.

OAT menguji aspek operasional seperti:

Instalasi & Deployment — bisa di-install dengan benar
Backup & Restore — data bisa di-backup dan dipulihkan
Recovery — sistem bisa pulih dari kegagalan
Maintenance — mudah di-maintain
Security operasional — firewall, akses, logging

Contoh OAT

Skenario: Admin IT melakukan restart server aplikasi, melakukan backup database, lalu memulihkan data dari backup tersebut. Jika semua berhasil, OAT lolos.

💡 Tips Hafalan UAT vs OAT

UAT = "User" → Dilakukan oleh pengguna akhir → "Apakah ini yang saya butuhkan?"
OAT = "Operational" → Dilakukan oleh tim IT/operasional → "Apakah ini bisa di-jalankan di server?"
Alpha = Awal = di dalam (internal)
Beta = Belakangan = di luar (eksternal, user sungguhan)

🔐 Integration Testing untuk Keamanan

Integration testing juga bisa digunakan untuk menguji keamanan di level interaksi antar komponen. Contoh paling umum:

Pengujian Injeksi pada Halaman Login

Menguji apakah form login bisa menangkal SQL Injection saat frontend mengirim data ke backend.

# Integration test: frontend + backend + database
def test_login_sql_injection_integration():
    # Simulasi user memasukkan payload SQL injection di form login
    response = client.post("/login", data={
        "username": "' OR 1=1 --",
        "password": "anything"
    })
    assert response.status_code == 401  # Login HARUS gagal
    assert "Login Failed" in response.text

📌 Poin-Poin Penting (WAJIB DIHAPAL)

            ✅ Ringkasan Kunci untuk UAS
            Integration Testing = menguji interaksi antar komponen
Big Bang = gabung semua sekaligus, Top-Down = dari atas (pakai Stub), Bottom-Up = dari bawah (pakai Driver)
Stub = nilai statis/hardcoded, untuk state verification (cek hasil)
Mock = dinamis, untuk behavior verification (cek pemanggilan method)
Kalau kode selalu return "LUNAS" → itu Stub
Dummy = pengisi parameter saja, Fake = implementasi sederhana (misal in-memory DB)
System Testing = menguji seluruh sistem sebagai satu kesatuan
UAT = oleh pengguna akhir (mahasiswa coba IRS)
OAT = oleh tim IT/operasional (admin restart server, backup database)
Alpha = di internal, Beta = di eksternal (user sungguhan)

        

🧠 TIPS MENGHAFAL — Bab 6: Integration, System & Acceptance

"Big Bang" = Gabung semuanya sekaligus.
"Top-Down pakai Stub, Bottom-Up pakai Driver" → Ingat: Stub = penopang dari bawah (untuk Top-Down). Driver = sopir di atas (untuk Bottom-Up).
"Stub vs Mock" (WAJIB INGAT) → Stub = Statis/Hardcoded (selalu return "LUNAS"). Mock = Dinamis/Verifikasi Pemanggilan (verify method).
"Dummy vs Fake" → Dummy = Cuma numpang lewat (pengisi parameter). Fake = Jalan beneran tapi sederhana (misal in-memory database).
"System Testing = Seluruhnya" → Tes lengkap semua komponen jadi satu kesatuan (fungsional, load, security, dll).
"UAT = User" → Dilakukan sama End User (pengguna asli) buat ngecek apakah sesuai kebutuhan mereka.
"OAT = Operational/IT" → Dilakukan sama tim IT/Admin buat ngecek kesiapan server (backup, restore, instalasi).
"Alpha = Internal, Beta = Eksternal" → Alpha di dalam kantor dev, Beta dilepas ke user asli di luar.

📝 Contoh Soal & Jawaban

Contoh Soal 1

Perhatikan kode berikut:

class PaymentStub:
    def get_status(self, order_id):
        return "LUNAS"

Kode di atas adalah contoh dari...

A. Mock
B. Fake
C. Stub
D. Driver

Jawaban: C (Stub) — Karena selalu mengembalikan nilai statis "LUNAS" tanpa logika apapun.

Contoh Soal 2

Seorang mahasiswa mencoba menambahkan mata kuliah di sistem IRS, menyimpan, dan mencetak KRS. Pengujian ini termasuk jenis apa?

A. Unit Testing
B. OAT (Operational Acceptance Testing)
C. UAT (User Acceptance Testing)
D. Regression Testing

Jawaban: C (UAT) — Karena dilakukan oleh pengguna akhir (mahasiswa) untuk memvalidasi kebutuhan mereka.

Contoh Soal 3

Admin IT melakukan restart server dan memulihkan database dari backup. Ini termasuk pengujian apa?

A. UAT
B. Integration Testing
C. Unit Testing
D. OAT (Operational Acceptance Testing)

Jawaban: D (OAT) — Karena dilakukan oleh tim operasional untuk memastikan kesiapan sistem di production.

🔗 Integration, System & Acceptance Testing

📑 Daftar Isi