Pengujian dan Jaminan Kualitas Perangkat Lunak

Mata kuliah ini membahas konsep dasar, prinsip, dan standar kualitas perangkat lunak serta peran pengujian dalam menjamin mutu. Fokusnya adalah pemahaman konseptual dan analisis studi kasus Quality Assurance (QA).

Capaian Pembelajaran Mata Kuliah (CPMK)

Sub-CPMK

Komponen Penilaian

Kontrak Kuliah & Pengantar QA dan Testing dalam SDLC

Perangkat lunak yang “jalan” belum tentu berkualitas. Pertemuan ini memperkenalkan apa itu kualitas, apa bedanya QA, QC, dan testing, serta di mana kegiatan tersebut berada dalam siklus hidup pengembangan perangkat lunak (SDLC).

Kontrak perkuliahan

• Perkuliahan 16 pertemuan × 2×50 menit; pertemuan 8 UTS dan pertemuan 16 UAS.
• Metode: case-based, problem-based, project-based, dan reflective learning. Mahasiswa diharapkan aktif berdiskusi.
• Media: SIKULI, Google Drive, Google Meet, dan WhatsApp untuk koordinasi.
• Tugas dikerjakan secara jujur; plagiarisme dan penyalinan laporan termasuk pelanggaran etika akademik.

Apa itu kualitas perangkat lunak?

Kualitas perangkat lunak adalah sejauh mana sebuah produk memenuhi kebutuhan yang dinyatakan maupun tersirat dari penggunanya ketika dipakai dalam kondisi tertentu. Kualitas bukan hanya “tidak ada bug”, tetapi juga mudah digunakan, cepat, aman, dan mudah dipelihara.

Error, defect, dan failure

Contoh: analis salah memahami aturan diskon (error), programmer menulis > padahal seharusnya >= (defect), pelanggan dengan belanja tepat Rp100.000 tidak mendapat diskon (failure).

QA, QC, dan Testing

Tujuh prinsip pengujian

1. Testing menunjukkan adanya defect, bukan membuktikan tidak ada defect.
2. Exhaustive testing tidak mungkin; kita memilih tes berdasarkan risiko dan prioritas.
3. Early testing menghemat biaya; cacat yang ditemukan di tahap kebutuhan jauh lebih murah diperbaiki.
4. Defect clustering: sebagian besar cacat sering terkumpul di sedikit modul.
5. Pesticide paradox: tes yang sama diulang terus akan berhenti menemukan cacat baru.
6. Testing bergantung konteks: aplikasi bank berbeda kebutuhan ujinya dengan game.
7. Absence-of-errors fallacy: sistem tanpa bug tetap gagal jika tidak memenuhi kebutuhan pengguna.

QA di setiap tahap SDLC

Model V (V-Model) menggambarkan pasangan ini: setiap tahap pengembangan di sisi kiri memiliki tahap pengujian yang sesuai di sisi kanan (kebutuhan ↔ acceptance test, desain sistem ↔ system test, desain arsitektur ↔ integration test, desain modul ↔ unit test).

Standar & Model Kualitas: ISO 25010, CMMI, TMMi

Agar kualitas bisa dibicarakan dan diukur secara objektif, industri memakai standar. ISO/IEC 25010 menilai kualitas produk, sedangkan CMMI dan TMMi menilai kematangan proses organisasi.

ISO/IEC 25010 — model kualitas produk

ISO/IEC 25010 (keluarga SQuaRE) mendefinisikan karakteristik kualitas produk perangkat lunak. Versi 2011 memiliki delapan karakteristik berikut; revisi 2023 menambahkan safety dan mengganti beberapa nama (mis. usability menjadi interaction capability, portability menjadi flexibility).

CMMI — kematangan proses organisasi

Capability Maturity Model Integration (CMMI) mengukur seberapa matang proses pengembangan di sebuah organisasi.

TMMi — kematangan proses pengujian

Test Maturity Model integration (TMMi) mirip CMMI tetapi khusus untuk proses pengujian: (1) Initial, (2) Managed — ada kebijakan, test plan, desain dan eksekusi tes; (3) Defined — organisasi tes, pelatihan, siklus hidup tes terintegrasi, non-functional testing, peer review; (4) Measured — pengukuran tes dan evaluasi kualitas produk; (5) Optimization — pencegahan cacat dan optimasi proses tes.

Proses & Level Pengujian

Pengujian dilakukan bertahap, dari bagian terkecil kode hingga sistem utuh yang diterima pengguna. Setiap level memiliki tujuan, pelaku, dan dasar uji yang berbeda.

Proses pengujian dasar

• Perencanaan: menentukan ruang lingkup, pendekatan, sumber daya, dan jadwal.
• Analisis: menentukan apa yang diuji (test condition) dari dokumen kebutuhan.
• Desain: menentukan bagaimana menguji — test case dan data uji.
• Implementasi: menyiapkan lingkungan, data, dan script tes.
• Eksekusi: menjalankan tes, mencatat hasil, melaporkan defect.
• Penyelesaian: membuat laporan akhir, mengarsipkan aset tes, mencatat pelajaran.

Pemantauan dan pengendalian (monitoring & control) berjalan sepanjang proses.

Empat level pengujian

Strategi integration testing

• Big bang: semua modul digabung sekaligus — cepat, tetapi sulit melacak sumber cacat.
• Top-down: mulai dari modul atas, modul bawah diganti stub.
• Bottom-up: mulai dari modul bawah, modul pemanggil diganti driver.
• Sandwich: gabungan top-down dan bottom-up.

Jenis acceptance testing

User Acceptance Testing (UAT), operational acceptance (backup, pemulihan), contractual/regulatory acceptance, serta alpha testing (di lokasi pengembang) dan beta testing (di lokasi pengguna).

Tipe pengujian

Teknik Pengujian: Black-box & White-box

Teknik desain tes membantu kita memilih data uji yang paling berpeluang menemukan cacat dengan jumlah tes sesedikit mungkin.

Black-box testing

Menguji berdasarkan spesifikasi tanpa melihat kode. Penguji hanya memperhatikan input dan output.

1. Equivalence Partitioning (EP)

Bagi input menjadi kelompok (partisi) yang diperlakukan sama oleh sistem, lalu ambil satu wakil dari setiap partisi.

Kasus: nilai angka mata kuliah valid 0–100.

2. Boundary Value Analysis (BVA)

Cacat sering muncul di batas. Uji nilai tepat di batas dan tepat di luarnya: -1, 0, 100, 101 (BVA dua titik) atau -1, 0, 1, 99, 100, 101 (tiga titik).

3. Decision Table

Cocok untuk aturan bisnis dengan kombinasi kondisi. Kasus: mahasiswa boleh ikut UAS jika kehadiran ≥ 75% dan sudah membayar UKT.

4. State Transition

Untuk sistem yang berperilaku berbeda tergantung status. Contoh status pesanan: Baru → Dibayar → Dikirim → Selesai, dengan transisi tidak sah seperti Baru → Dikirim yang harus ditolak.

5. Use Case Testing

Menurunkan tes dari skenario utama dan alternatif pada use case, misalnya alur login berhasil, password salah, dan akun terkunci setelah 3 kali gagal.

White-box testing

Menguji berdasarkan struktur internal kode. Ukurannya adalah coverage.

function statusKelulusan(nilai) {
  if (nilai < 0 || nilai > 100) {   // keputusan 1
    return "INVALID";
  }
  if (nilai >= 60) {                 // keputusan 2
    return "LULUS";
  }
  return "TIDAK LULUS";
}

• Statement coverage: setiap baris dieksekusi minimal sekali. Tes: -1, 70, 40 → 100% statement.
• Branch/decision coverage: setiap cabang true dan false dijalankan. Tes yang sama juga mencapai 100% branch karena setiap keputusan bernilai true dan false.
• Path coverage: setiap jalur unik dari awal sampai akhir.

Cyclomatic complexity

V(G) = jumlah keputusan + 1. Fungsi di atas memiliki 2 keputusan, maka V(G) = 3, artinya minimal 3 jalur independen yang perlu diuji. (Jika kondisi majemuk || dihitung terpisah, V(G) = 4.)

Memilih teknik

Selain itu ada experience-based testing seperti error guessing dan exploratory testing yang mengandalkan pengalaman penguji.

Menyusun Test Plan & Test Case

Test plan menjelaskan strategi pengujian sebuah proyek; test case adalah langkah konkret untuk memverifikasi satu kondisi. Pada pertemuan ini kamu mulai mengerjakan tugas terstruktur.

Isi test plan (mengacu IEEE 829 / ISO/IEC/IEEE 29119-3)

1. Identitas & pendahuluan: nama sistem, versi, tujuan dokumen.
2. Ruang lingkup: fitur yang diuji dan tidak diuji.
3. Pendekatan: level, tipe, dan teknik pengujian yang dipakai.
4. Kriteria masuk & keluar: kapan pengujian boleh dimulai dan dinyatakan selesai.
5. Kriteria suspend/resume: kapan pengujian dihentikan sementara.
6. Lingkungan uji: perangkat, browser, database, data uji.
7. Deliverable: test case, laporan defect, laporan ringkasan.
8. Jadwal & sumber daya: siapa mengerjakan apa dan kapan.
9. Risiko & mitigasi.

Format test case

Ciri test case yang baik

• Satu test case menguji satu tujuan yang jelas.
• Langkah dapat diulang oleh orang lain dan hasil diharapkan dapat diverifikasi.
• Dapat dilacak ke kebutuhan melalui Requirement Traceability Matrix (RTM).
• Mencakup skenario positif, negatif, dan batas.

Evaluasi Hasil Pengujian & Pelaporan QA

Menjalankan tes baru setengah pekerjaan. Hasilnya harus dicatat, dianalisis, dan dikomunikasikan sehingga pemangku kepentingan bisa memutuskan apakah produk siap dirilis.

Status hasil eksekusi

• Pass: hasil aktual sama dengan hasil diharapkan.
• Fail: hasil berbeda — buat laporan defect.
• Blocked: tes tidak bisa dijalankan karena hambatan (mis. fitur lain rusak, lingkungan mati).
• Not run / skipped: belum atau sengaja tidak dijalankan.

Laporan defect yang baik

ID          : BUG-017
Judul       : Total belanja tidak mendapat diskon saat tepat Rp100.000
Lingkungan  : Staging v1.3.2, Chrome 130, Windows 11
Langkah     : 1. Login sebagai pelanggan
              2. Tambah produk hingga subtotal Rp100.000
              3. Buka halaman checkout
Diharapkan  : Diskon 10% diterapkan (total Rp90.000)
Aktual      : Tidak ada diskon (total Rp100.000)
Severity    : Major      Priority : High
Lampiran    : screenshot-checkout.png
Test case   : TC-DISKON-003

Test summary report

• Ringkasan: apa yang diuji, kapan, versi berapa.
• Statistik eksekusi: total test case, pass, fail, blocked.
• Ringkasan defect: jumlah per severity, status open/closed.
• Penyimpangan dari test plan dan alasannya.
• Evaluasi terhadap kriteria keluar dan risiko yang tersisa.
• Rekomendasi: go / no-go / rilis bersyarat.

Contoh perhitungan: dari 120 test case, 102 pass, 12 fail, 6 blocked. Pass rate = 102/120 = 85%. Jika kriteria keluar adalah pass rate ≥ 95% dan tidak ada defect critical yang masih open, maka rekomendasinya belum siap rilis.

Review Konsep QA & Pengujian

Pertemuan ini menghubungkan seluruh konsep sebelum UTS dengan penerapan pengujian di dunia nyata.

Peta konsep

Pengujian statis vs dinamis

Selain menjalankan program (dinamis), cacat juga dapat ditemukan tanpa menjalankan kode (statis): review kebutuhan, walkthrough, inspeksi formal, dan analisis kode otomatis (linter, SonarQube). Pengujian statis efektif menemukan kebutuhan yang ambigu dan kode yang sulit dipelihara sejak dini.

Studi kasus nyata untuk direfleksikan

Pertanyaan refleksi

1. Konsep mana yang paling sulit kamu pahami sejauh ini? Mengapa?
2. Jika kamu menjadi QA di proyek tugas kelompok, risiko kualitas terbesar apa yang kamu lihat?
3. Bagaimana kamu menjelaskan perbedaan QA dan testing kepada manajer non-teknis?

UTS — Teori dan Studi Kasus QA

UTS menguji kemampuan menjawab soal analitis dan studi kasus QA berdasarkan konsep standar dan teknik pengujian (materi pertemuan 1–7).

Kisi-kisi

Contoh soal latihan

1. Aplikasi beasiswa menerima IPK 3,00–4,00 dan penghasilan orang tua ≤ Rp5.000.000. Susun tabel keputusan dan nilai batasnya.
2. Hitung cyclomatic complexity sebuah fungsi yang memiliki satu if, satu else if, dan satu perulangan for.
3. Sebuah startup belum memiliki dokumen test plan dan pengujian bergantung pada satu orang senior. Pada level TMMi berapa organisasi tersebut? Apa langkah untuk naik satu level?

QA Process & Defect Tracking

Di organisasi profesional, setiap defect dikelola melalui alur yang jelas sehingga tidak ada temuan yang hilang dan setiap perbaikan terverifikasi.

Siklus hidup defect

Cabang lain: Rejected (bukan defect), Duplicate, Deferred (ditunda ke rilis berikutnya), dan Reopened (gagal saat retest).

Tingkat severity

Tools defect tracking

Jira, Azure DevOps Boards, GitHub Issues, Bugzilla, Redmine, atau Mantis. Test management seperti TestRail, Zephyr, atau Qase menghubungkan test case dengan defect.

Root cause analysis (RCA)

Setelah defect diperbaiki, QA yang matang bertanya “mengapa cacat ini bisa lolos?”. Teknik umum: 5 Whys dan diagram fishbone (Ishikawa) dengan kategori manusia, proses, alat, kebutuhan, dan lingkungan.

Masalah: diskon tidak diterapkan pada Rp100.000
Why 1 → kondisi memakai ">" bukan ">="
Why 2 → kebutuhan menulis "di atas Rp100.000" (ambigu)
Why 3 → kebutuhan tidak di-review oleh QA
Why 4 → proses review kebutuhan belum wajib
Why 5 → belum ada checklist review kebutuhan
Tindakan: wajibkan review kebutuhan + tambahkan BVA di unit test

Etika & Tanggung Jawab Profesional QA

Penguji sering menjadi pihak terakhir yang melihat produk sebelum sampai ke pengguna. Karena itu QA memikul tanggung jawab etis terhadap pengguna, organisasi, dan masyarakat.

Kode etik rujukan

• ACM/IEEE Software Engineering Code of Ethics: delapan prinsip — Public, Client & Employer, Product, Judgment, Management, Profession, Colleagues, Self.
• ISTQB Code of Ethics untuk penguji perangkat lunak dengan prinsip serupa.
• Regulasi: UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi (UU PDP) mengatur pemrosesan data pribadi, termasuk saat pengujian.

Dilema etis yang sering dihadapi QA

Prinsip praktik QA yang etis

1. Melaporkan hasil secara jujur dan lengkap, termasuk risiko yang belum teruji.
2. Menggunakan data uji sintetis atau data yang sudah dianonimkan/di-masking.
3. Menjaga kerahasiaan informasi klien dan temuan keamanan (responsible disclosure).
4. Mengkritik produk, bukan orangnya — komunikasi defect yang netral dan sopan.
5. Terus meningkatkan kompetensi dan mengakui batas kemampuan.

QA dalam Agile & DevOps Environment

Dalam Agile dan DevOps, kualitas menjadi tanggung jawab seluruh tim dan pengujian berlangsung terus-menerus, didukung otomasi.

Peran QA di Agile/Scrum

• Ikut sprint planning dan refinement untuk memastikan user story memiliki acceptance criteria yang dapat diuji.
• Menyepakati Definition of Done (mis. unit test lulus, code review selesai, tidak ada defect critical).
• Menguji di dalam sprint, bukan setelah sprint berakhir.

Behavior-Driven Development (BDD)

Fitur: Pengambilan KRS
  Skenario: Kelas sudah penuh
    Diberikan kelas "Basis Data A" memiliki kuota 40 dan sudah terisi 40
    Ketika mahasiswa mengambil kelas "Basis Data A"
    Maka sistem menolak dengan pesan "Kuota kelas penuh"

Agile Testing Quadrants & Test Pyramid

Test pyramid menyarankan banyak unit test (cepat, murah), lebih sedikit integration/API test, dan paling sedikit UI/end-to-end test (lambat, rapuh).

Tools pengujian otomatis

Unit test dengan JUnit 5

import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvSource;

class KelulusanTest {
    @ParameterizedTest
    @CsvSource({ "-1, INVALID", "0, TIDAK LULUS", "59, TIDAK LULUS",
                 "60, LULUS", "100, LULUS", "101, INVALID" })
    void statusSesuaiNilaiBatas(int nilai, String harapan) {
        assertEquals(harapan, Kelulusan.status(nilai));
    }
}

Perhatikan bahwa data uji diambil langsung dari Boundary Value Analysis pada pertemuan 4.

UI test dengan Selenium WebDriver (Python)

from selenium import webdriver
from selenium.webdriver.common.by import By

driver = webdriver.Chrome()
try:
    driver.get("http://localhost:8000/login")
    driver.find_element(By.NAME, "username").send_keys("mhs01")
    driver.find_element(By.NAME, "password").send_keys("salah123")
    driver.find_element(By.CSS_SELECTOR, "button[type=submit]").click()
    pesan = driver.find_element(By.CLASS_NAME, "alert").text
    assert "Username atau password salah" in pesan   # TC-LOGIN-002
finally:
    driver.quit()

Tools lain: PHPUnit (PHP/Laravel), pytest (Python), Cypress/Playwright (web), Postman/Newman (API), JMeter/k6 (performa), OWASP ZAP (keamanan).

CI/CD dan Shift-Left / Shift-Right

• Shift-left: menguji sedini mungkin (review kebutuhan, unit test, analisis statis di pipeline).
• Shift-right: memantau kualitas di produksi (monitoring, canary release, A/B test).
• Quality gate: pipeline otomatis gagal jika tes gagal atau coverage di bawah ambang.

Review Dokumentasi QA & Metrik Kualitas

“Apa yang tidak diukur tidak bisa dikelola.” Metrik membantu menilai kualitas produk dan efektivitas proses pengujian secara objektif.

Metrik produk dan proses

Contoh perhitungan

Modul pembayaran berukuran 8 KLOC. Tim QA menemukan 36 defect sebelum rilis; pengguna melaporkan 4 defect setelah rilis.

• Defect density = (36 + 4) ÷ 8 = 5 defect/KLOC
• DRE = 36 ÷ 40 × 100% = 90%
• Defect leakage = 4 ÷ 40 × 100% = 10%

Checklist review dokumentasi QA

• Apakah ruang lingkup dan kriteria keluar di test plan jelas dan terukur?
• Apakah setiap kebutuhan memiliki test case (cek RTM)?
• Apakah laporan defect dapat direproduksi dan memiliki severity yang wajar?
• Apakah metrik disajikan dengan konteks (tren, target, interpretasi)?
• Apakah kesimpulan laporan didukung data?

Menyusun Laporan QA Konseptual

Laporan QA konseptual merangkum strategi, hasil, analisis, dan rekomendasi kualitas sebuah sistem informasi, disusun sesuai standar dan etika profesional.

Struktur laporan

1. Ringkasan eksekutif — satu halaman untuk pembaca non-teknis: kondisi kualitas dan rekomendasi.
2. Profil sistem — tujuan, pengguna, fitur utama.
3. Kebutuhan kualitas — dipetakan ke karakteristik ISO 25010.
4. Strategi pengujian — level, tipe, teknik, tools, lingkungan.
5. Hasil pengujian — statistik eksekusi dan daftar defect utama.
6. Analisis metrik — pass rate, coverage, defect density/DRE, interpretasi.
7. Analisis risiko & akar masalah.
8. Pertimbangan etika — perlakuan data uji, keterbukaan risiko.
9. Rekomendasi — perbaikan produk dan proses (mis. menuju level TMMi berikutnya).
10. Lampiran — test plan, test case, RTM, laporan defect.

Menulis secara profesional

• Gunakan bahasa objektif dan berbasis data; hindari menyalahkan individu.
• Nyatakan keterbatasan pengujian dengan jujur (apa yang belum diuji dan mengapa).
• Sajikan angka dengan grafik sederhana dan beri penjelasan maknanya.
• Cantumkan sumber standar dan referensi yang dipakai.

Presentasi & Diskusi QA Report

Setiap kelompok mempresentasikan laporan QA dan menerima umpan balik dari dosen dan teman sejawat.

Format presentasi (± 10 menit + 5 menit diskusi)

1. Sistem yang diuji dan kebutuhan kualitas utamanya.
2. Strategi dan teknik pengujian yang dipilih — beserta alasannya.
3. Temuan penting dan metrik kunci.
4. Rekomendasi rilis dan perbaikan proses.
5. Pelajaran dan pertimbangan etis selama pengerjaan.

Rubrik umpan balik sejawat

Review & Refleksi Akhir

Pertemuan terakhir sebelum UAS digunakan untuk merefleksikan capaian pembelajaran dan nilai profesional QA.

Rangkuman perjalanan

Pertanyaan refleksi

1. Kemampuan QA apa yang paling berkembang dalam dirimu selama semester ini?
2. Bagaimana cara pandangmu tentang “kode yang berkualitas” berubah?
3. Nilai profesional apa yang akan kamu pegang jika bekerja sebagai QA engineer atau developer?
4. Langkah belajar berikutnya: sertifikasi (mis. ISTQB Foundation), otomasi tes, atau performance/security testing?

Jalur karier QA

Gunakan roadmap.sh/qa untuk memetakan keterampilan yang perlu dikuasai.

UAS — QA Process, Agile QA, dan Etika Profesional

UAS menilai kemampuan menganalisis kasus QA modern dan menerapkan etika profesional dalam menyusun solusi QA (materi pertemuan 9–15).

Kisi-kisi

Contoh kasus

1. Hitung dan interpretasikan risiko berdasarkan data yang ada.
2. Identifikasi masalah etika dan regulasi (UU PDP) dalam kasus ini.
3. Rancang rekomendasi: keputusan rilis, perbaikan proses QA, dan strategi otomasi di pipeline.

Pustaka

Utama

1. ACM/IEEE Joint Task Force. Computing Curricula 2020 (CC2020), Bab 5 & 7.
2. ACM/AIS. Information Systems 2020 (IS2020), Section 6.4 dan Body of Knowledge “Systems Analysis, Design, and Quality”.

Pendukung

• Pressman, R.S. & Maxim, B.R. (2020). Software Engineering: A Practitioner’s Approach. McGraw-Hill.
• Sommerville, I. (2020). Software Engineering (10th ed.). Pearson.
• Kaner, C., Falk, J., & Nguyen, H.Q. (2013). Testing Computer Software. Wiley.
• roadmap.sh — QA Roadmap.
• Slalom Build (2022). “Quality Engineer Learning Roadmap”. Medium.
• Agati, F. (2023). “Belajar Software Quality Assurance Mulai dari Mana Ya?”. Medium.
• ISO/IEC 25010 — Systems and software Quality Requirements and Evaluation (SQuaRE).
• ISTQB — Certified Tester Foundation Level Syllabus.