Sesi 06 dari 16

Analisis Defect & Root Cause Analysis

Menemukan bug itu mudah — yang sulit adalah memahami mengapa bug itu bisa ada, dan mencegah kategori yang sama tidak muncul lagi di masa depan.

🔍 5 Whys · Fishbone · FTA
📊 Pareto Analysis
🏷️ ODC Taxonomy
⏱️ 3 × 50 menit
🎯 Bagian 1 — Mengapa RCA Lebih dari Sekedar Memperbaiki Bug?

Jangan Hanya Mengobati Gejala

💡 ANALOGI — Kebocoran Atap

Tanpa RCA: Setiap kali hujan, Anda meletakkan ember untuk menampung air yang bocor. Masalah "teratasi" — tapi besok hujan, ember lagi.

Dengan RCA: Anda naik ke atap, menemukan bahwa genteng retak bukan karena usia, tapi karena tukang pasang baut terlalu kencang. Anda memperbaiki genteng DAN mengubah SOP pemasangan — sehingga kebocoran serupa tidak terjadi lagi di rumah lain.

RCA dalam software: Bukan hanya memperbaiki bug yang ditemukan, tapi memahami akar penyebabnya agar kelas bug yang sama tidak muncul lagi di modul lain atau di sprint berikutnya.

🔄 Bagian 2 — Siklus Hidup Defect

Perjalanan Sebuah Bug dari Lahir hingga Mati

🔭
Discovery
Bug ditemukan oleh tester atau user
📝
Reporting
Bug dicatat di bug tracker (Jira, GitHub)
⚖️
Triage
Tim menilai severity, priority, dan assign ke developer
🔧
Resolution
Developer memperbaiki dan membuat fix
Verification
QA memverifikasi fix sudah benar
🔒
Closure
Bug ditutup resmi di sistem tracker

📋 Status Bug yang Mungkin Terjadi

NEW

Baru dilaporkan, belum diperiksa

ASSIGNED

Sudah di-assign ke developer

IN PROGRESS

Sedang diperbaiki

RESOLVED

Developer klaim sudah diperbaiki

CLOSED

QA verifikasi — bug benar-benar selesai

REOPENED

Fix tidak berhasil, dikembalikan ke developer

WONT FIX

Diputuskan tidak perlu diperbaiki (low risk, high cost)

DUPLICATE

Bug yang sama sudah dilaporkan sebelumnya

🏷️ Bagian 3 — Klasifikasi Defect

Severity vs Priority: Jangan Tertukar!

💡 ANALOGI — Pasien di IGD

Severity (keparahan medis) = Seberapa parah kondisi pasien secara klinis. Patah tulang = berat, luka kecil = ringan. Ini ditentukan dokter berdasarkan kondisi fisik.

Priority (prioritas penanganan) = Urutan siapa yang ditangani lebih dulu. Pasien VIP dengan flu mungkin ditangani lebih cepat dari pasien biasa dengan luka kecil — meskipun secara medis luka kecil lebih "urgent". Priority dipengaruhi faktor bisnis dan konteks.

Dalam software: Bug di fitur demo besok (severity rendah) bisa punya priority tinggi. Bug di fitur yang jarang dipakai (severity tinggi) bisa punya priority rendah untuk sementara.

🚨
CRITICAL
Sistem crash total, data hilang/korup, keamanan terkompromi. Tidak ada workaround. Harus diperbaiki segera.
🔴
HIGH
Fitur utama tidak berfungsi, ada workaround tapi sulit. Dampak besar pada pengguna mayoritas.
🟡
MEDIUM
Fitur berfungsi tapi tidak sempurna. Ada workaround yang mudah. Hanya memengaruhi sebagian pengguna.
🟢
LOW
Masalah kosmetik/UI kecil. Typo, warna salah, spasi tidak pas. Tidak memengaruhi fungsionalitas.

🗂️ ODC — Orthogonal Defect Classification

ODC adalah taksonomi defect yang dikembangkan IBM untuk mengklasifikasikan bug secara sistematis, sehingga pola bisa diidentifikasi dan proses pengembangan bisa diperbaiki secara targeted.

Tipe DefectDeskripsiContoh Nyata
FunctionKesalahan dalam logika bisnis atau algoritma utamaRumus perhitungan bunga pinjaman salah
AssignmentInisialisasi variabel salah atau struktur data tidak tepatArray dimulai dari index 1 bukan 0
InterfaceMasalah pada antarmuka antar komponen (API, parameter)Format tanggal yang berbeda antara frontend-backend
CheckingValidasi input tidak memadai atau error handling kurangTidak ada validasi untuk field kosong di form login
Timing/SerializationRace condition, deadlock, masalah sinkronisasiDua user mengedit data sama secara bersamaan
Build/PackageMasalah dalam proses build, deployment, atau konfigurasiLibrary versi lama tidak di-update di server production
DocumentationDokumentasi tidak akurat atau tidak lengkapAPI docs mengatakan endpoint /users tapi sebenarnya /user

Manfaat ODC: Jika 40% bug bertipe "Checking", artinya tim perlu meningkatkan code review dan validasi input. Data ODC memberi arah perbaikan proses yang spesifik!

🕵️ Bagian 4 — Teknik Root Cause Analysis (RCA)

Tiga Teknik RCA yang Wajib Dikuasai

🔎 Teknik 1: 5 Whys — Terus Bertanya "Mengapa?"

Teknik sederhana tapi powerful: tanyakan "mengapa?" setidaknya 5 kali sampai menemukan akar masalah yang sebenarnya. Dikembangkan oleh Sakichi Toyoda di Toyota Production System.

💡 ANALOGI — Mesin yang Berhenti

Mesin pabrik tiba-tiba berhenti. Mengapa? Sekring putus. Mengapa? Arus berlebihan. Mengapa? Bearing tidak dilumasi. Mengapa? Pompa oli tidak bekerja. Mengapa? Filter oli tersumbat dan tidak pernah diganti. Solusi bukan ganti sekring, tapi buat jadwal penggantian filter oli!

Kasus: Sistem e-commerce down selama 2 jam saat Harbolnas

❓1
MASALAH:
Website e-commerce tidak bisa diakses selama 2 jam saat Harbolnas
W1
MENGAPA website tidak bisa diakses?
Database server kehabisan koneksi (connection pool exhausted)
W2
MENGAPA connection pool exhausted?
Terlalu banyak request bersamaan — lebih dari 10× traffic normal
W3
MENGAPA sistem tidak menangani lonjakan traffic?
Tidak ada auto-scaling yang dikonfigurasi untuk database layer
W4
MENGAPA auto-scaling tidak dikonfigurasi?
Load testing sebelum Harbolnas hanya menguji 3× traffic normal, bukan 10×
W5
🎯 AKAR MASALAH:
Tidak ada prosedur baku untuk menentukan skenario load test berdasarkan data historis traffic event sebelumnya. Tim engineering tidak tahu berapa peak traffic yang realistis untuk Harbolnas.

Solusi dari akar masalah: Buat prosedur analisis historis traffic sebelum setiap event besar → definisikan skenario load test → konfigurasi auto-scaling → bukan sekadar "tambah server" saat sudah down!

🐟 Teknik 2: Fishbone Diagram (Ishikawa)

Cocok untuk masalah yang memiliki banyak faktor penyebab potensial. Diagram berbentuk tulang ikan, dengan "kepala" adalah masalah, dan "tulang" adalah kategori penyebab.

💥 Defect Rate tinggi di Sprint 7 (38 bug dalam 2 minggu)

Kategori penyebab yang dianalisis:

👥 People
2 senior dev sakit, diganti junior
Onboarding tidak memadai
Tim kelelahan (overtime 3 minggu)
⚙️ Process
Code review di-skip karena deadline
Tidak ada unit test requirement
Requirements berubah 3× dalam sprint
💻 Technology
Library baru tanpa dokumentasi matang
Environment dev ≠ production
CI/CD pipeline tidak stabil
🌐 Environment
Server staging sering down
Database versi berbeda dev vs prod
📋 Management
Sprint terlalu padat (18 story points)
Tidak ada waktu untuk refactoring
📊 Measurement
Tidak ada metrik kualitas kode
Defect tidak dikategorisasi

Setelah fishbone dibuat: Tim voting untuk menentukan faktor yang paling berkontribusi, lalu fokus pada 2-3 akar masalah utama untuk diperbaiki di sprint berikutnya.

🌳 Teknik 3: Fault Tree Analysis (FTA)

FTA memvisualisasikan bagaimana kombinasi kejadian (fault) dapat menyebabkan sebuah kegagalan (top event). Menggunakan logika boolean (AND gate, OR gate) — sangat berguna untuk sistem safety-critical.

💡 ANALOGI — Kebakaran

Kebakaran terjadi jika ada tiga hal bersamaan (AND gate): bahan bakar + oksigen + panas. Jika salah satu tidak ada → tidak ada kebakaran. Sebaliknya, sistem alarm berbunyi jika ada salah satu dari (OR gate): asap ATAU panas berlebih ATAU api terdeteksi.

FTA dalam software: "Sistem payment gagal" ← bisa dari [API bank timeout] OR [validasi gagal] OR [database tidak tersedia]. Masing-masing bisa dipecah lebih lanjut.

💥 TOP EVENT: Payment gagal
    OR
    ├── API Bank timeout
    │    AND
    │    ├── Koneksi internet putus
    │    └── Retry mechanism tidak ada
    ├── Validasi data gagal
    │    OR
    │    ├── Format kartu salah
    │    └── CVV tidak valid
    └── Database tidak tersedia
        AND
        ├── Primary DB down
        └── Failover ke replica gagal
📊 Bagian 5 — Analisis Tren Defect & Pareto

Aturan 80/20: 20% Penyebab, 80% Bug

💡 ANALOGI — Prinsip Pareto

Vilfredo Pareto menemukan bahwa di Italia, 20% penduduk memiliki 80% tanah. Prinsip ini ternyata berlaku hampir universal. Dalam software: 20% modul atau tipe defect menyebabkan 80% bug yang ditemukan. Fokus perbaiki yang 20% itu, dan Anda sudah menyelesaikan 80% masalah!

📊 Analisis Pareto Defect — Proyek SIAKAD (Sprint 1-6)

Total: 120 defect. Tiga kategori teratas menyebabkan 79% dari semua bug!

KATEGORI DEFECT JUMLAH KUMULATIF
Validasi Input Kurang
38%
46
38%
Error Handling Lemah
25%
30
63%
Race Condition (Timing)
16%
19
79% ← 80!
UI/Tampilan Tidak Konsisten
11%
13
90%
Logika Bisnis Salah
7%
8
97%
Lain-lain
3%
4
100%

Keputusan berbasis data: Fokuskan improvement sprint berikutnya pada "Validasi Input" dan "Error Handling". Solusi: wajibkan checklist validasi di setiap PR, dan adakan workshop error handling untuk seluruh tim developer.

🏢 Bagian 6 — Studi Kasus RCA dari Open Source

Belajar dari Bug Proyek Nyata

📋 KASUS NYATA — Mozilla Firefox Bug #431

🦊 Integer Overflow di Browser Engine

Masalah: Firefox crash ketika membuka halaman web dengan gambar berukuran sangat besar (>2GB). Ini adalah bug yang bisa dieksploitasi untuk crash browser pengguna.

5 Whys Analysis:

W1: Mengapa Firefox crash? → Integer overflow saat kalkulasi ukuran buffer gambar
W2: Mengapa integer overflow? → Variabel tipe int32 (max ~2 miliar) tidak cukup untuk ukuran gambar
W3: Mengapa tipe int32 digunakan? → Kode ditulis saat RAM komputer masih sangat terbatas
W4: Mengapa tidak di-update? → Tidak ada review berkala untuk kode lama saat kapabilitas hardware meningkat
W5 (Root Cause): Tidak ada kebijakan audit "legacy code assumptions" — asumsi batasan hardware tidak didokumentasikan dan tidak di-review secara berkala.

Solusi yang diterapkan: Ganti int32 → int64 untuk kalkulasi ukuran. Tambahkan batas maksimum gambar yang eksplisit. Buat kebijakan audit asumsi hardware setiap 2 tahun.

Pelajaran untuk SI: Saat membangun sistem informasi yang akan berkembang, selalu dokumentasikan asumsi (misal: "maksimum 10.000 pengguna", "ukuran file max 50MB") dan jadwalkan review asumsi tersebut secara berkala!

🐍 Bagian 7 — Praktik Python: Analisis Defect Dataset

Otomasi Analisis Pareto & Tren Defect

PRAKTIK: Analisis Defect & Visualisasi Pareto Python · pandas · matplotlib
# ================================================================
# S11409 - Sesi 6: Analisis Defect & Visualisasi Pareto
# Dosen: Riadi Marta Dinata, S.Ti., M.Kom. | ISTN Jakarta
# ================================================================

import pandas as pd
import matplotlib.pyplot as plt
import matplotlib.ticker as mticker
import numpy as np
from collections import Counter

# ── DATASET SIMULASI DEFECT ──
data_defect = {
    'id': [f'BUG-{i:03d}' for i in range(1, 121)],
    'sprint': np.random.choice(['S1','S2','S3','S4','S5','S6'], 120,
                p=[0.10,0.15,0.22,0.20,0.18,0.15]),
    'kategori': np.random.choice([
        'Validasi Input', 'Error Handling', 'Race Condition',
        'UI Tampilan', 'Logika Bisnis', 'Lain-lain'
    ], 120, p=[0.38,0.25,0.16,0.11,0.07,0.03]),
    'severity': np.random.choice(['Critical','High','Medium','Low'],
                  120, p=[0.10,0.25,0.40,0.25]),
    'waktu_fix': np.random.exponential(scale=3, size=120).round(1)  # jam
}
df = pd.DataFrame(data_defect)

# ── ANALISIS DASAR ──
print("="*55)
print("    LAPORAN ANALISIS DEFECT — PROYEK SIAKAD")
print("="*55)
print(f"Total defect        : {len(df)}")
print(f"Rata-rata waktu fix : {df['waktu_fix'].mean():.1f} jam")
print(f"Defect Critical     : {(df['severity']=='Critical').sum()}")
print()

# ── PARETO ANALYSIS ──
kategori_count = df['kategori'].value_counts().sort_values(ascending=False)
total = kategori_count.sum()
persen = (kategori_count / total * 100).round(1)
kumulatif = persen.cumsum()

print("--- Pareto Analysis ---")
for kat, cnt in kategori_count.items():
    print(f"  {kat:<22} : {cnt:3d} ({cnt/total*100:5.1f}%)")
print()

# ── DEFECT ARRIVAL/CLOSURE CURVE ──
arrival_by_sprint = df.groupby('sprint').size()

# Simulasi closure (biasanya lebih lambat dari arrival)
closure_by_sprint = (arrival_by_sprint * np.array([0.7,0.8,0.85,0.9,0.95,1.0])).astype(int)

# ── VISUALISASI (3 plot) ──
fig = plt.figure(figsize=(16, 5))
fig.patch.set_facecolor('#0A0608')

# Plot 1: Pareto Chart
ax1 = fig.add_subplot(1, 3, 1)
ax1.set_facecolor('#160C0E')
colors = ['#C8102E','#F97316','#FCD34D','#22C55E','#38BDF8','#9B7A80']
bars = ax1.bar(kategori_count.index, kategori_count.values,
               color=colors[:len(kategori_count)], alpha=0.85)
ax1.set_title('Pareto Defect by Kategori', color='white', pad=10)
ax1.tick_params(axis='x', rotation=45, colors='#9B7A80', labelsize=8)
ax1.tick_params(axis='y', colors='#9B7A80')
ax2_twin = ax1.twinx()
ax2_twin.plot(range(len(kumulatif)), kumulatif.values,
              color='#D4A017', marker='o', linewidth=2, markersize=5)
ax2_twin.axhline(80, color='#D4A017', linestyle='--', alpha=0.5)
ax2_twin.set_ylabel('Kumulatif %', color='#D4A017')
ax2_twin.tick_params(colors='#D4A017')
ax2_twin.yaxis.set_major_formatter(mticker.PercentFormatter())

# Plot 2: Defect per Sprint (Arrival vs Closure)
ax3 = fig.add_subplot(1, 3, 2)
ax3.set_facecolor('#160C0E')
x = np.arange(len(arrival_by_sprint))
ax3.plot(x, arrival_by_sprint.values, color='#C8102E', marker='o',
         lw=2, label='Defect Masuk')
ax3.plot(x, closure_by_sprint.values, color='#22C55E', marker='s',
         lw=2, linestyle='--', label='Defect Ditutup')
ax3.fill_between(x, arrival_by_sprint.values, closure_by_sprint.values,
                 alpha=0.15, color='#C8102E', label='Backlog')
ax3.set_xticks(x); ax3.set_xticklabels(arrival_by_sprint.index)
ax3.set_title('Defect Arrival vs Closure Curve', color='white', pad=10)
ax3.legend(fontsize=8); ax3.grid(alpha=0.15)
ax3.tick_params(colors='#9B7A80')

# Plot 3: Severity Distribution
ax4 = fig.add_subplot(1, 3, 3)
ax4.set_facecolor('#160C0E')
sev_count = df['severity'].value_counts()
sev_colors = ['#F87171','#F97316','#FCD34D','#22C55E']
wedges, texts, autotexts = ax4.pie(sev_count.values,
    labels=sev_count.index, colors=sev_colors,
    autopct='%1.1f%%', startangle=90, pctdistance=0.85)
for t in texts: t.set_color('#9B7A80'); t.set_fontsize(9)
for at in autotexts: at.set_color('white'); at.set_fontsize(9)
ax4.set_title('Distribusi Severity Defect', color='white', pad=10)

plt.tight_layout()
plt.savefig('analisis_defect.png', dpi=150, facecolor='#0A0608', bbox_inches='tight')
print("✅ Grafik tersimpan: analisis_defect.png")
print("\n💡 Rekomendasi perbaikan berdasarkan Pareto:")
top3 = kategori_count.head(3)
for kat, cnt in top3.items():
    print(f"  → Fokus pada '{kat}' ({cnt} bug, {cnt/total*100:.0f}%)")
✏️ Latihan Mandiri
📝 KUIS SESI 6

Uji Pemahaman Anda

Soal 1 — Siklus Hidup Defect

Sebuah bug dilaporkan pengguna (status: NEW), lalu developer mengatakan "sudah diperbaiki" (RESOLVED), tapi QA menemukan bug masih ada. Jelaskan langkah-langkah yang harus diambil tim QA. Apa status yang tepat dan siapa yang harus melakukan apa?

Soal 2 — Severity vs Priority

Berikan contoh nyata (dalam konteks aplikasi kampus SIAKAD) untuk: (a) Severity tinggi, Priority rendah, (b) Severity rendah, Priority tinggi. Jelaskan mengapa bisa terjadi situasi seperti ini.

Soal 3 — 5 Whys

Aplikasi presensi mahasiswa menunjukkan data presensi yang salah — mahasiswa yang hadir tercatat absen. Lakukan analisis 5 Whys untuk menemukan akar masalahnya. Tentukan minimal 2 kemungkinan root cause yang berbeda.

Soal 4 — Fishbone Diagram

Buat fishbone diagram untuk masalah "Waktu respons aplikasi sangat lambat (>5 detik)" pada sistem informasi akademik. Identifikasi minimal 3 penyebab untuk setiap kategori: People, Process, Technology, dan Environment.

Soal 5 — Python Challenge

Modifikasi kode Python di atas untuk: (a) menghitung mean waktu perbaikan (MTTR) per severity level, (b) mengidentifikasi sprint dengan defect backlog tertinggi, (c) membuat rekomendasi otomatis berdasarkan Pareto (kategori mana yang harus diprioritaskan).

💡 Rangkuman Kunci Sesi 6

RCA mencari akar masalah, bukan sekadar memperbaiki bug yang terlihat — 5 Whys adalah alat paling praktis

Severity ≠ Priority — keparahan teknis dan urgensi bisnis bisa berbeda, keduanya harus dipertimbangkan

ODC mengklasifikasikan bug berdasarkan tipe — data ini mengarahkan perbaikan proses yang spesifik

Fishbone ideal untuk masalah dengan banyak faktor; FTA untuk sistem safety-critical dengan logika AND/OR

Pareto 80/20 — fokus perbaiki 20% penyebab yang menyumbang 80% bug, jangan buang waktu untuk hal minor

Arrival vs Closure curve menunjukkan apakah tim bisa "mengimbangi" bug baru — jika arrival > closure terus, ada masalah serius