Setelah tahu APA yang dibutuhkan, tim perlu memutuskan BAGAIMANA sistem akan dibangun. Tahap desain menerjemahkan kebutuhan menjadi cetak biru teknis, mirip arsitek yang menggambar denah sebelum tukang mulai membangun rumah.

HLD dan LLD

Desain dibagi menjadi dua tingkat:

Untuk aplikasi kas kelas, HLD-nya bisa sesederhana ini: "Aplikasi web monolit, satu server, satu database, tiga modul: pencatatan iuran, saldo, dan laporan."

LLD-nya lebih rinci. Misalnya tabel iuran punya kolom id, siswa_id, tanggal, dan nominal. Lalu ada aturan validasi: nominal harus angka positif, tanggal tidak boleh di masa depan.

Empat Area Desain

Deck menyebut empat area yang biasa dirancang:

• Arsitektur: bagaimana sistem dipecah menjadi bagian-bagian.
• Basis Data (ERD): tabel apa saja dan bagaimana relasinya.
• UI/UX dan Wireframe: alur dan tampilan layar.
• Desain API: alamat, data masukan, dan data keluaran setiap endpoint.

Contoh spesifikasi API kecil untuk kas kelas bisa ditulis seperti ini:

// Spesifikasi endpoint (bagian dari LLD)
const apiCatatIuran = {
  metode: "POST",
  alamat: "/iuran",
  masukan: { siswaId: "string", nominal: "angka > 0", tanggal: "YYYY-MM-DD" },
  keluaran: { status: 201, data: "iuran yang tersimpan" },
};

Output tahap desain adalah Software Design Document (SDD), diagram UML, ERD, dan wireframe atau prototipe UI. Desain yang baik memudahkan pengembangan dan pemeliharaan, karena developer tidak perlu menebak struktur yang diharapkan.

Di tahap ini developer menulis kode program berdasarkan dokumen desain. Biasanya ini tahap dengan durasi dan usaha terbesar.

Aktivitas dan Praktik

• Menyiapkan lingkungan pengembangan.
• Menulis kode mengikuti coding standard, misalnya aturan penamaan yang disepakati.
• Membuat unit test oleh developer sendiri.
• Melakukan code review sebelum merge.
• Integrasi berkala dengan version control seperti Git.

Version control dan code review adalah dua penjaga kualitas utama. Version control mencatat setiap perubahan, sehingga kalau ada yang rusak, kamu bisa melihat kapan dan siapa yang mengubahnya. Code review memastikan setiap perubahan dibaca rekan setim sebelum digabung.

Contoh fungsi dari LLD kas kelas beserta unit test sederhananya:

function validasiIuran(nominal) {
  return typeof nominal === "number" && nominal > 0;
}

// unit test sederhana
console.log(validasiIuran(5000) === true);  // true
console.log(validasiIuran(-100) === false); // true
console.log(validasiIuran("5000") === false); // true

Output tahap implementasi: source code, build, dan dokumentasi teknis atau API.

Pengujian memverifikasi bahwa software berjalan benar, bebas cacat kritis, dan memenuhi kebutuhan.

Tingkatan Pengujian

Ada empat tingkatan, dari yang paling kecil:

1. Unit Test: menguji fungsi atau komponen terkecil, seperti validasiIuran di atas.
2. Integration Test: memastikan antarmodul bekerja sama, misalnya modul pencatatan iuran dan modul saldo.
3. System Test: menguji sistem utuh dari ujung ke ujung (end-to-end).
4. Acceptance Test (UAT): pengguna memvalidasi, misalnya bendahara mencoba sendiri aplikasinya.

Tingkatan ini sering digambarkan sebagai piramida pengujian: banyak unit test yang cepat dan murah di bagian bawah, lebih sedikit UAT di bagian atas. Alasannya sederhana. Unit test bisa dijalankan ratusan kali dalam hitungan detik, sedangkan UAT butuh waktu pengguna sungguhan.

Jenis Pengujian

Contoh pada kas kelas:

• Black-box: masukkan iuran 5000, cek saldo bertambah 5000. Penguji tidak peduli isi kodenya.
• White-box: penguji membaca kode validasiIuran dan memastikan cabang untuk angka negatif dan bukan angka sama-sama diuji.
• Non-fungsional: cek apakah halaman saldo terbuka di bawah 2 detik, sesuai kebutuhan non-fungsional dari tahap analisis.
• Regression: setelah menambah fitur ekspor, jalankan lagi semua tes lama untuk memastikan pencatatan iuran tetap benar.

Perhatikan bahwa kebutuhan non-fungsional yang ditulis di tahap analisis sekarang diuji. Inilah alasan kebutuhan harus terukur: "di bawah 2 detik" bisa dites, "harus cepat" tidak.

Output tahap pengujian: Test Plan, Test Case, Bug Report, dan Laporan Hasil Uji.

Coba ikuti satu kebutuhan kas kelas melewati ketiga tahap ini. Kebutuhan dari tahap analisis berbunyi "bendahara dapat mencatat iuran". Di tahap desain, kebutuhan itu menjadi tabel iuran dan endpoint POST /iuran beserta aturan validasinya. Di tahap implementasi, aturan validasi itu menjadi fungsi validasiIuran lengkap dengan unit test. Di tahap pengujian, penguji menulis test case black-box yang membuktikan iuran tersimpan dan saldo bertambah. Setiap tahap mengambil output tahap sebelumnya sebagai input, persis seperti yang kamu pelajari di bab pertama.

• Melompati desain dan langsung menulis kode. Akibatnya struktur tabel berubah-ubah dan modul saling bertabrakan.
• Menganggap pengujian hanya tugas QA. Developer tetap wajib menulis unit test untuk kodenya sendiri.
• Hanya menguji jalur yang lancar. Tes juga input aneh seperti angka negatif, teks kosong, atau tanggal di masa depan.
• Melupakan regression test. Fitur baru sering diam-diam merusak fitur lama.