Modul AjarPertemuan 5Bab 2Fase ESemester 1

Modul Ajar Informatika Kelas 10: Pengujian Rancangan Program: Kasus Uji

Modul Ajar ini disusun untuk satu pertemuan tatap muka mata pelajaran Informatika kelas 10 dengan topik "Pengujian Rancangan Program: Kasus Uji". Dokumen mengikuti Alur Tujuan Pembelajaran (ATP) Kurikulum Merdeka, lengkap dengan tujuan, langkah kegiatan, dan asesmen ringkas.

MEJAGURU.ID - DOKUMEN MODUL AJAR

Modul Ajar Informatika Kelas 10: Pengujian Rancangan Program: Kasus Uji

Informatika - Kelas 10

Bab 2 - Pertemuan 5

MODUL AJAR

Informatika — Kelas 10 (Fase E)

Topik: Pengujian Rancangan Program: Kasus Uji

INFORMASI UMUM

Mata Pelajaran	Informatika
Fase / Kelas	Fase E / Kelas 10
Topik	Pengujian Rancangan Program: Kasus Uji
Alokasi Waktu	2x45 menit
Jumlah Pertemuan	1

TUJUAN PEMBELAJARAN

Murid dapat merancang kasus uji yang relevan untuk memverifikasi kebenaran pseudokode yang telah ditulis.
Murid dapat menguji dan memperbaiki rancangan program sederhana dalam pseudokode berdasarkan hasil kasus uji.

PROFIL LULUSAN

Dimensi	Disasar
Keimanan dan Ketakwaan terhadap Tuhan Yang Maha Esa
Kewargaan
Penalaran Kritis	✓
Kreativitas	✓
Kolaborasi	✓
Kemandirian	✓
Kesehatan
Komunikasi

PERTANYAAN PEMANTIK

Bagaimana kita bisa yakin bahwa pseudokode yang kita tulis benar-benar menghasilkan output sesuai harapan untuk semua kemungkinan input?
Apa yang terjadi jika kita hanya menguji program dengan satu contoh input saja — apakah cukup untuk membuktikan program itu benar?
Pernahkah kalian menemukan bug di aplikasi yang sering digunakan? Menurut kalian, mengapa bug itu bisa lolos sampai ke pengguna?

KEGIATAN PEMBELAJARAN

Pertemuan 1

Pendahuluan:

Guru membuka pelajaran dengan salam dan memastikan kesiapan murid.
Guru menampilkan contoh pseudokode sederhana (menghitung bilangan genap/ganjil) yang mengandung kesalahan tersembunyi dan bertanya: 'Apakah pseudokode ini sudah benar? Bagaimana cara membuktikannya?'
Guru menyampaikan tujuan pembelajaran hari ini: merancang kasus uji dan menggunakannya untuk menguji serta memperbaiki pseudokode.
Asesmen awal diagnostik: Guru meminta murid menuliskan di kertas/sticky note satu contoh input dan output yang diharapkan dari pseudokode yang ditampilkan (2 menit).

Kegiatan Inti:

Memahami (Berkesadaran, Bermakna):

Guru menjelaskan konsep kasus uji (test case): definisi, komponen (input, output yang diharapkan, output aktual, status lulus/gagal), dan mengapa pengujian penting dalam pengembangan program.
Guru menyajikan contoh tabel kasus uji untuk pseudokode penghitung diskon sederhana, mencakup kasus normal, kasus batas (boundary), dan kasus tidak valid.
Murid mencatat dan berdiskusi singkat dengan teman sebangku: mengapa perlu kasus batas dan kasus tidak valid, bukan hanya kasus normal.
Guru memfasilitasi tanya jawab untuk memastikan pemahaman konsep sebelum lanjut ke praktik.

Mengaplikasi (Bermakna, Menggembirakan):

Murid dibagi dalam kelompok kecil (3-4 orang). Setiap kelompok menerima lembar kerja berisi pseudokode program sederhana yang berbeda (contoh: mencari nilai maksimum dari 3 bilangan, menentukan kelulusan berdasarkan nilai, menghitung total belanja dengan diskon).
Setiap kelompok merancang minimal 5 kasus uji yang mencakup: kasus normal (2), kasus batas/boundary (2), dan kasus tidak valid (1).
Kelompok melakukan dry-run (penelusuran manual) pseudokode menggunakan kasus uji yang telah dirancang dan mencatat output aktual di tabel kasus uji.
Jika ditemukan ketidaksesuaian antara output yang diharapkan dan output aktual, kelompok mengidentifikasi letak kesalahan pada pseudokode dan menulis versi perbaikannya.
Kelompok menukar lembar kerja dengan kelompok lain untuk saling memeriksa kasus uji dan hasil perbaikan (peer review).
Guru berkeliling memantau, memberikan umpan balik formatif, dan mencatat kesalahpahaman umum.

Merefleksi (Berkesadaran, Bermakna):

Satu atau dua kelompok mempresentasikan hasil kasus uji dan perbaikan pseudokode mereka di depan kelas.
Guru memfasilitasi diskusi kelas: Apa pola kesalahan yang paling sering ditemukan? Strategi apa yang paling efektif untuk merancang kasus uji yang baik?
Murid secara individu menuliskan refleksi singkat: (1) Apa yang saya pelajari hari ini tentang pengujian program? (2) Kesulitan apa yang saya alami? (3) Apa yang akan saya lakukan berbeda saat menulis pseudokode berikutnya?

Penutup:

Guru bersama murid menyimpulkan poin-poin penting: kasus uji yang baik mencakup kasus normal, batas, dan tidak valid; pengujian membantu menemukan dan memperbaiki kesalahan sebelum program diimplementasikan.
Guru memberikan apresiasi terhadap kerja kelompok dan individu.
Guru menyampaikan kaitan materi hari ini dengan pertemuan berikutnya.
Guru menutup pelajaran dengan salam.

Diferensiasi:

Konten: Murid yang sudah mahir diberikan pseudokode dengan logika lebih kompleks (nested if atau loop bersarang). Murid yang masih berkembang diberikan pseudokode linear sederhana dengan petunjuk tambahan berupa contoh satu kasus uji yang sudah terisi.
Proses: Murid cepat diminta menjadi tutor sebaya dalam kelompok. Murid yang membutuhkan pendampingan mendapat scaffolding berupa template tabel kasus uji yang sudah terisi sebagian dan panduan langkah-langkah dry-run.
Produk: Murid cepat menghasilkan minimal 7 kasus uji termasuk kasus edge case kreatif dan menulis penjelasan mengapa kasus tersebut penting. Murid yang masih berkembang cukup menghasilkan 4 kasus uji dengan bantuan template.

ASESMEN

Awal:

Murid menuliskan satu contoh input dan output yang diharapkan dari pseudokode yang ditampilkan guru di awal pelajaran untuk mengecek pemahaman awal tentang hubungan input-output dalam program.

Proses:

Guru mengamati apakah setiap kelompok mampu mengidentifikasi minimal tiga jenis kasus uji (normal, batas, tidak valid).
Guru memeriksa apakah murid dapat melakukan dry-run dengan benar dan mencatat output aktual secara akurat.
Guru menilai kemampuan murid mengidentifikasi lokasi kesalahan dan menulis perbaikan pseudokode yang logis.

Akhir:

Setiap kelompok mengumpulkan lembar kerja berisi: (1) tabel kasus uji lengkap minimal 5 kasus, (2) hasil dry-run dengan output aktual, (3) identifikasi bug jika ada, (4) pseudokode yang sudah diperbaiki. Dinilai menggunakan rubrik 4 level.

Formatif:

Observasi aktivitas kelompok saat merancang kasus uji dan melakukan dry-run.
Umpan balik lisan saat guru berkeliling ke setiap kelompok.
Peer review antar kelompok terhadap kelengkapan dan relevansi kasus uji.

Sumatif:

Penilaian lembar kerja kelompok berisi tabel kasus uji, hasil dry-run, dan perbaikan pseudokode menggunakan rubrik.

RUBRIK PENILAIAN

Aspek	Belum Berkembang	Mulai	Berkembang	Sangat Berkembang
Kelengkapan dan Relevansi Kasus Uji	Membuat kurang dari 3 kasus uji dan hanya mencakup kasus normal tanpa variasi.	Membuat 3-4 kasus uji namun belum mencakup kasus batas atau kasus tidak valid secara memadai.	Membuat 5 kasus uji yang mencakup kasus normal, batas, dan tidak valid dengan relevansi yang baik.	Membuat lebih dari 5 kasus uji yang mencakup semua jenis kasus termasuk edge case kreatif disertai justifikasi mengapa setiap kasus dipilih.
Ketepatan Dry-Run dan Identifikasi Kesalahan	Tidak dapat melakukan dry-run dengan benar; tidak mampu mengidentifikasi kesalahan pada pseudokode.	Melakukan dry-run dengan beberapa kesalahan penelusuran; mampu mengidentifikasi kesalahan tetapi belum tepat lokasinya.	Melakukan dry-run dengan benar untuk sebagian besar kasus uji; mengidentifikasi lokasi kesalahan dengan tepat.	Melakukan dry-run dengan benar untuk semua kasus uji; mengidentifikasi semua kesalahan dengan tepat dan menjelaskan penyebabnya secara logis.
Kualitas Perbaikan Pseudokode	Tidak menulis perbaikan atau perbaikan yang ditulis masih mengandung kesalahan logika yang sama.	Menulis perbaikan tetapi hanya menyelesaikan sebagian kesalahan; pseudokode hasil perbaikan masih gagal di beberapa kasus uji.	Menulis perbaikan yang menyelesaikan semua kesalahan yang ditemukan; pseudokode hasil perbaikan lolos semua kasus uji yang dirancang.	Menulis perbaikan yang efisien dan elegan; pseudokode lolos semua kasus uji serta murid mampu menjelaskan alasan perubahan yang dilakukan.
Kolaborasi dan Komunikasi dalam Kelompok	Tidak berpartisipasi aktif dalam diskusi kelompok; tidak berkontribusi pada hasil kerja.	Berpartisipasi minimal dalam diskusi; kontribusi terbatas pada satu aspek tugas saja.	Berpartisipasi aktif dalam diskusi; berkontribusi pada perancangan kasus uji dan proses dry-run.	Memimpin atau memfasilitasi diskusi kelompok secara produktif; membantu anggota lain memahami proses dan berkontribusi signifikan pada semua aspek tugas.

REFLEKSI

Refleksi Guru:

Apakah murid mampu membedakan kasus normal, kasus batas, dan kasus tidak valid dalam merancang kasus uji?
Apakah alokasi waktu untuk setiap tahap (Memahami, Mengaplikasi, Merefleksi) sudah proporsional dan cukup?
Kesulitan apa yang paling banyak dialami murid? Apakah perlu penyesuaian scaffolding untuk pertemuan berikutnya?
Apakah diferensiasi yang diberikan sudah efektif menjangkau murid dengan kemampuan berbeda?

Refleksi Murid:

Apa hal baru yang saya pelajari hari ini tentang cara menguji program?
Jenis kasus uji mana yang paling sulit saya rancang (normal, batas, atau tidak valid)? Mengapa?
Bagaimana pengalaman bekerja dalam kelompok membantu saya memahami materi lebih baik?
Apa yang akan saya lakukan secara berbeda saat menulis dan menguji pseudokode di masa depan?

SUMBER BELAJAR

Buku Siswa Informatika Kelas X (Edisi Revisi) — Bab 2: Algoritma dan Struktur Data, khususnya Aktivitas 10.2-08-U Membuat Kasus Uji.
Buku Panduan Guru Informatika Kelas X (Edisi Revisi) — Bab 2, bagian aktivitas 10.2-08-UP.
Lembar kerja kelompok berisi pseudokode dan template tabel kasus uji (disiapkan guru).
Papan tulis atau proyektor untuk menampilkan contoh pseudokode dan tabel kasus uji.
Alat tulis dan kertas untuk dry-run manual.

Lihat & unduh lengkap

Masuk pakai Google untuk membuka modul ajar pertemuan ini secara penuh.

Apa isi pertemuan ini?

Dokumen mencakup tujuan pembelajaran terpilih, urutan kegiatan inti yang sudah disesuaikan dengan alokasi JP, serta pertanyaan pemantik dan asesmen formatif singkat. Cocok dipakai sebagai bahan persiapan tatap muka maupun lampiran supervisi.

Cara pakai pertemuan ini

Unduh DOCX, lalu sesuaikan nama sekolah, kepala sekolah, dan NIP. Bagian kegiatan inti bisa Bapak/Ibu kurangi atau tambah sesuai karakter siswa di kelas; tujuan pembelajaran sebaiknya tetap selaras dengan ATP induk.