Dokumentasi Catatan Teknik

Wawasan, tutorial, dan catatan mendalam seputar QA automation dan rekayasa perangkat lunak.

QA Process & Strategy Terakhir diperbarui: 14 Agustus 2026

Dasar Pengujian Perangkat Lunak ISTQB: Test Levels, Test Types & Test Techniques

Pengujian perangkat lunak (software testing) adalah aktivitas sistematis yang digunakan untuk mengevaluasi produk perangkat lunak, mengidentifikasi cacat (defect), mengurangi risiko, dan memberikan informasi tentang kualitasnya kepada para pemangku kepentingan. Strategi pengujian yang terstruktur dengan baik tidak bergantung pada satu metode pengujian saja. Sebaliknya, QA (Quality Assurance) atau Tester menggabungkan berbagai tingkat pengujian (test levels), jenis pengujian (test types), dan teknik pengujian (test techniques) sesuai dengan objek uji, tujuan, risiko, dan sumber daya yang tersedia.

Artikel ini utamanya didasarkan pada Silabus ISTQB Certified Tester Foundation Level (CTFL) v4.0.1 serta standar pengujian perangkat lunak internasional terkait, termasuk ISO/IEC/IEEE 29119-4:2021 untuk teknik pengujian dan ISO/IEC 25010 untuk kualitas produk perangkat lunak. Contoh dan penjelasan dalam artikel ini disederhanakan untuk tujuan edukasi.

Taksonomi Pengujian: Test Levels, Test Types & Test Techniques

Konsep-konsep ini menjawab pertanyaan yang berbeda:

Konsep Pertanyaan Utama Tujuan
Test Levels Di mana / pada tingkatan apa? Menentukan tingkatan dari objek uji yang sedang diuji.
Test Types Apa yang dievaluasi? Menentukan fokus pengujian, seperti fungsionalitas atau karakteristik kualitas.
Test Techniques Bagaimana cara merancang kasus uji? Memberikan cara sistematis untuk merancang kasus uji (test cases) yang efektif.

Ketiga konsep ini dapat digabungkan. Misalnya, seorang penguji dapat melakukan system testing dengan menggunakan jenis functional testing, sambil menerapkan teknik equivalence partitioning dan boundary value analysis untuk merancang kasus ujinya.

1 Test Levels (Tingkatan Pengujian)

ISTQB CTFL v4.0.1 mendeskripsikan lima tingkatan pengujian. Sebuah test level mengelompokkan aktivitas pengujian yang diatur dan dikelola bersama, serta diterapkan pada perangkat lunak pada tahap pengembangan tertentu.

1.1 Component Testing

Juga dikenal sebagai Unit Testing, berfokus pada pengujian komponen individu secara terisolasi. Komponen dapat berupa fungsi, method, kelas, modul, atau unit lain yang dapat diuji secara mandiri. Pengujian ini umumnya dilakukan oleh Developer dan sering menggunakan framework unit testing.

Contoh: Sebuah fungsi calculateDiscount() diuji dengan berbagai nilai input untuk memverifikasi apakah fungsi tersebut mengembalikan jumlah diskon yang diharapkan.

Tools yang umum digunakan: PHPUnit, Jest, JUnit, NUnit, pytest.

1.2 Component Integration Testing

Berfokus pada antarmuka (interfaces) dan interaksi antar komponen. Tujuannya adalah memverifikasi bahwa komponen individu dapat berkomunikasi dengan benar setelah diintegrasikan.

Shopping Cart
↓
Pricing Service
↓
Inventory Service

Pengujian ini memverifikasi bahwa komponen bertukar data yang diharapkan dan menangani kendala integrasi dengan benar.

1.3 System Testing

Mengevaluasi perilaku keseluruhan dan kemampuan sistem atau produk secara utuh. Ini dapat mencakup pengujian fungsional dan non-fungsional. Alur End-to-end (E2E) sering kali disertakan dalam system testing untuk memvalidasi alur pengguna (user flow) yang lengkap.

Login → Browse Product → Add to Cart → Checkout → Payment → Order Confirmation

Lingkungan uji (test environment) yang representatif sangat penting saat mengevaluasi karakteristik non-fungsional tertentu.

1.4 System Integration Testing

Berfokus pada interaksi antara sistem yang diuji dengan sistem lain atau layanan eksternal (external services). Ini berbeda dengan Component Integration Testing:

  • Component Integration: Komponen A ↔ Komponen B
  • System Integration: Sistem yang Diuji ↔ Sistem/Layanan Eksternal
Contoh: Aplikasi e-commerce berkomunikasi dengan Payment gateway, penyedia pengiriman, layanan email, dll. Tujuannya adalah memverifikasi bahwa antarmuka antar-sistem ini bekerja dengan benar dalam kondisi normal maupun tak terduga.
1.5 Acceptance Testing

Berfokus pada validasi dan mendemonstrasikan kesiapan sistem untuk dirilis. Tujuannya adalah menentukan apakah sistem memenuhi kebutuhan bisnis pengguna. Idealnya, pengujian ini melibatkan pengguna sesungguhnya atau perwakilan bisnis.

  • User Acceptance Testing (UAT)
  • Operational Acceptance Testing
  • Contractual / Regulatory Acceptance Testing
  • Alpha / Beta Testing

Contoh: Tim bisnis memverifikasi bahwa aplikasi penagihan mendukung alur kerja, aturan bisnis, persyaratan laporan, dan proses persetujuan sebelum dirilis ke production.

2 Test Types (Jenis Pengujian)

Kelompok aktivitas pengujian yang berfokus pada karakteristik kualitas atau tujuan pengujian tertentu. Menurut CTFL v4.0.1, terdapat empat jenis pengujian utama, namun industri sering menggunakan jenis pengujian hibrida lainnya.

2.1 Functional Testing

Mengevaluasi apa yang seharusnya dilakukan perangkat lunak. Fokus utamanya adalah kelengkapan, kebenaran, dan ketepatan fungsi sesuai dengan spesifikasi.

Contoh (Aplikasi Belanja): Syarat: Sistem harus menghitung total pesanan dengan benar.
Produk A ($50) + Produk B ($30) + Ongkir ($10) = Expected Total ($90). Pengujian memverifikasi hasil ini.
2.2 Non-Functional Testing

Mengevaluasi seberapa baik sistem beroperasi, bukan hanya apa yang dilakukannya. Silabus CTFL v4.0.1 mengidentifikasi karakteristik kualitas seperti:

  • Performance: Apakah aplikasi merespons dalam waktu yang ditentukan di bawah beban sistem?
  • Compatibility: Apakah aplikasi berfungsi di berbagai browser, OS, dan perangkat?
  • Usability: Dapatkah pengguna menyelesaikan tugas dengan efektif dan efisien?
  • Security: Apakah sistem melindungi informasi dari akses ilegal?
  • Reliability: Apakah sistem bekerja secara konsisten pada kondisi tertentu?
Catatan: ISO/IEC 25010:2023 adalah standar yang mendefinisikan karakteristik kualitas produk. CTFL v4.0.1 memiliki pembahasannya sendiri, sehingga terminologinya tidak boleh dicampuradukkan tanpa memeriksa versi yang dirujuk.
2.3 Black-Box Testing

Pengujian berbasis spesifikasi. Penguji tidak perlu mengetahui struktur internal (kode) dari objek yang diuji.

Contoh: Username valid + Password valid → Login Sukses. Username invalid + Password valid → Login Gagal. Penguji tidak perlu tahu algoritma autentikasi di balik layar.
2.4 White-Box Testing

Pengujian berbasis struktur. Penguji menurunkan kasus uji menggunakan pengetahuannya tentang struktur internal, aliran data, source code, atau arsitektur.

Contoh: Seorang developer merancang tes khusus untuk mengeksekusi berbagai cabang (branches) dari sebuah statement IF/ELSE di dalam kode.
2.5 Gray-Box Testing

Pengujian yang menggabungkan pengecekan UI/eksternal (Black-Box) dengan pengetahuan parsial tentang operasi internal seperti database atau API (White-Box). Meskipun bukan klasifikasi resmi dalam CTFL v4.0.1, ini adalah pendekatan yang sangat lazim digunakan di industri.

Contoh: Penguji menguji form pendaftaran pada aplikasi (Black-box), lalu memverifikasi respons JSON dari API pendaftaran atau mengeksekusi query ke database secara langsung (White-box) untuk memastikan data tersimpan dengan format dan relasi yang benar.

3 Confirmation, Regression, Smoke, & Sanity Testing

Rilis *build* baru atau adanya perubahan pada kode (fitur baru/perbaikan bug) rentan memicu masalah tak terduga. Oleh karena itu, pengujian pasca-perubahan umumnya berfokus pada teknik berikut:

3.1 Confirmation Testing

Juga dikenal sebagai Re-testing. Memverifikasi bahwa cacat/bug yang sebelumnya dilaporkan benar-benar telah berhasil diperbaiki.

Contoh: Bug "User tidak bisa login menggunakan special character" telah diperbaiki developer. QA mengulang skenario tes yang sama persis untuk memastikan masalah tersebut hilang.
3.2 Regression Testing

Memverifikasi bahwa perubahan terbaru pada kode tidak merusak fitur lain yang sebelumnya berjalan normal (side-effect/efek samping).

Contoh: Developer merombak kalkulasi diskon di Checkout. Regression testing memverifikasi bahwa hal ini tidak merusak fungsi Keranjang, Pajak, dan Riwayat Pesanan secara luas.
3.3 Smoke Testing

Sering disebut Build Verification Testing. Tes cepat dan dangkal untuk memastikan fungsi kritis aplikasi berjalan (tidak crash parah) sebelum membuang waktu untuk tes mendalam.

Contoh: *Build* baru dirilis ke lingkungan staging. QA hanya mencoba login dan membuka halaman utama. Jika tombol login menyebabkan layar putih (crash), build langsung dikembalikan.
3.4 Sanity Testing

Tes sempit namun mendalam (narrow and deep), bertindak sebagai bagian (*subset*) dari regresi, yang dilakukan pasca-perbaikan guna memastikan stabilitas suatu komponen spesifik.

Contoh: Setelah developer memperbaiki "bug kupon", QA akan fokus menguji fitur kupon dari berbagai sisi dan efeknya pada total belanja (tanpa menguji area Profil atau Payment Gateway yang tidak relevan).

4 Test Design Techniques

Memberikan cara sistematis untuk menurunkan kasus uji (test cases) sehingga mendapatkan cakupan maksimal tanpa harus menguji setiap kombinasi data yang jumlahnya tak terbatas.

4.1 Black-Box Test Techniques
  • Equivalence Partitioning (EP): Membagi data ke dalam partisi yang dianggap memiliki perilaku sama (Valid dan Invalid). Cukup ambil 1 sampel representatif dari tiap grup.
    Partisi (Syarat Umur 18-65)Contoh NilaiKlasifikasi
    Di bawah 1815Invalid
    18 - 6530Valid
    Di atas 6570Invalid
  • Boundary Value Analysis (BVA): Menguji nilai yang berada persis di batas/ujung partisi, karena masalah sering terjadi di area ini.
    2-Value BVA: Menguji batas bawah (18) dan nilai terdekat di luar batas (17) atau batas atas yaitu (65) dan (66).
  • Decision Table Testing: Memetakan kombinasi aturan bisnis (If-Then) ke dalam tabel untuk memastikan tidak ada logika yang terlewat. Contoh: Promo aktif JIKA VIP = Yes DAN Keranjang > $100.
  • State Transition Testing: Bermanfaat jika sistem berubah status berdasarkan event berurutan. Contoh: Akun Aktif → PIN Salah 3x → Akun Terkunci.
  • Use Case Testing: Merancang pengujian berdasarkan alur interaksi aktual antara aktor (pengguna) dan sistem, mendefinisikan *Main Success Scenario* dan skenario *exception/alternate flow* yang mungkin terjadi. (Catatan: teknik ini dialihkan ke level *Advanced* pada rilis CTFL v4.0.1).
4.2 White-Box Test Techniques
  • Statement Testing & Coverage: Merancang pengujian untuk mengeksekusi setiap baris kode yang dapat dieksekusi minimal satu kali.
    Statement Coverage = (Executed Statements / Total Statements) × 100%
  • Branch Testing & Coverage: Merancang pengujian untuk mengeksekusi setiap cabang/keputusan kontrol logika (seperti TRUE dan FALSE pada blok IF).
    Aturan emas: 100% branch coverage secara otomatis berarti 100% statement coverage, tetapi tidak berlaku sebaliknya.
  • Path Testing & Coverage: Merancang pengujian untuk mengeksekusi rute (*paths*) spesifik dari titik awal berjalannya sebuah fungsi perangkat lunak hingga akhir. Teknik ini jauh lebih kompleks dibanding sekadar cabang.
4.3 Experience-Based Test Techniques
  • Error Guessing: Mengantisipasi letak bug berdasarkan pengalaman QA atas kesalahan yang sering dilakukan developer (misal: input kosong, karakter spesial, format tanggal salah).
  • Exploratory Testing: Pengujian dinamis di mana desain tes, eksekusi, dan proses evaluasi terjadi secara bersamaan dan adaptif. Sangat cocok jika spesifikasi dokumen tidak lengkap.
  • Checklist-Based Testing: Pengujian menggunakan daftar periksa (checklist) yang memuat kondisi pengujian, risiko produk, atau ekspektasi pengguna sebagai panduan.

5 Collaboration-Based Test Approaches

Pendekatan di mana penguji, developer, dan perwakilan bisnis berkolaborasi sejak awal untuk mencegah cacat dan menyamakan pemahaman. Contohnya termasuk penulisan User Story kolaboratif dan ATDD (Acceptance Test-Driven Development). Fokus utamanya adalah mencegah bug, bukan sekadar menemukannya.

6 Risk-Based Testing

Sumber daya selalu terbatas. Risk-based testing memprioritaskan area pengujian berdasarkan risiko kegagalan (Risk = Likelihood × Impact). Modul berisiko tinggi (misal: Transaksi Pembayaran) akan menerima pengujian ketat, sedangkan modul berisiko rendah (misal: warna UI) mendapat porsi pengujian yang lebih ringan. Ini bukan teknik desain, melainkan cara memprioritaskan strategi pengujian.

7 Putting Everything Together

Sebuah strategi pengujian praktis menggabungkan seluruh konsep ini. Contoh untuk sistem pembayaran:

TEST LEVEL: System Testing
↓
TEST TYPES: Functional + Non-Functional + Gray-Box
↓
TEST TECHNIQUES: Equivalence Partitioning, BVA, Decision Table, State Transition
↓
EXPERIENCE-BASED SUPPORT: Error Guessing, Exploratory Testing
↓
CHANGE-RELATED TESTING: Smoke, Sanity, Confirmation, & Regression Testing
↓
RISK-BASED PRIORITIZATION: Skenario pembayaran berisiko tinggi diuji lebih dalam.

8 Quick Reference (Referensi Cepat)

KategoriContoh
Test LevelsComponent, Component Integration, System, System Integration, Acceptance
Test TypesFunctional, Non-Functional, Black-Box, White-Box, Gray-Box
Black-Box TechniquesEquivalence Partitioning, Boundary Value Analysis, Decision Table, State Transition, Use Case Testing
White-Box TechniquesStatement Testing, Branch Testing, Path Testing
Experience-BasedError Guessing, Exploratory Testing, Checklist-Based Testing
Change-Related / Post-BuildSmoke Testing, Sanity Testing, Confirmation Testing, Regression Testing

9 Final Takeaway (Kesimpulan)

Pengujian yang efektif bukanlah soal menjalankan sebanyak mungkin test cases, melainkan memilih kombinasi yang tepat untuk menemukan bug terpenting menggunakan sumber daya yang tersedia. Ingat pembeda utama berikut:

  • Test Level Di mana / Pada tahapan apa?
  • Test Type Apa yang dievaluasi?
  • Test Technique Bagaimana cara mendesain pengujiannya?
  • Risk-Based Testing Di mana prioritas harus difokuskan?
References
  • International Software Testing Qualifications Board (ISTQB). Certified Tester Foundation Level Syllabus v4.0.1, 2024.
  • ISO/IEC/IEEE 29119-4:2021. Software and systems engineering — Software testing — Part 4: Test techniques.
  • ISO/IEC 25010:2023. Systems and software engineering — SQuaRE — Product quality model.