Pengenalan terhadap kebutuhan menjadi lebih jelas dan kesalahan yang dapat terjadi akan dapat dikenali dengan baik bila kita mengetahui bagaimana cara melakukan tes padanya. Suatu kasus disebut berbasis pada kebutuhan bila dibuat dari spesifikasi atau kebutuhan eksternal software. Bila informasi disain software dan struktur data tidak ada, disain tes
Testing dan Implementasi Sistem
berbasis kebutuhan akan tidak dapat dispesifikasikan dengan baik. Bagaimanapun, tujuannya adalah untuk membuat situasi tes berbasis pada kebutuhan dan menggunakannya sebagai tes dari pengertian dan validasi kebutuhan (misal ketidaklengkapan dan ketidakpresisian kebutuhan).
Metodologi testing STEP, sebagaimana telah dibahas pada sub bab sebelumnya, tekanan
pemenuhan dari disain tes berbasis kebutuhan akan mulai terjadi sebelum disain dan coding
dari software dimulai. Hal ini berdasarkan pada keyakinan akan pemakaian waktu dan usaha
untuk mengembangkan suatu tes secara keseluruhan dari kebutuhan akan terjadi lebih dari sekali kerja atau terjadi berulang-ulang secara iteratif sepanjang pengembangan dan validasi
lebih lanjut dari kebutuhan sebelum aktifitas disain dan coding dari software dimulai.
6.9.2 Mat rik validasi kebutuhan
Satu hal yang efektif dalam mengorganisasikan seluruh kebutuhan dan memastikan telah dispesifikasikan untuk tiap dari kebutuhan tersebut adalah dengan menggunakan matrik
validasi kebutuhan, yang merupakan suatu matrik kebutuhan terhadap test cases. Sebagai
gambaran akan penggunaan matrik validasi kebutuhan dapat dilihat pada gambar di bawah ini.
Pengorganisasian Tes Kebutuhan dengan Matrik Validasi Kebutuhan
No Kebutuhan Test Cases Status
1 Menyediakan kemampuan untuk mengirim
pesanan penjualan tiap item. 87, 88, 102 V V V
2 Menyediakan kemampuan untuk mengirim pesanan penjualan dengan multi item dan multi kuantitas.
81-88, 102 V V V
3 Menghasilkan order kembali secara otomatis
bagi item yang telah habis.
4 Menghasilkan verifikasi kredit pelanggan untuk
pelanggan baru secara otomatis. 87, 88, 103-106V
Matrik mendaftar tiap kebutuhan dan referensinya terhadap test cases atau situasi yang telah
dibuat untuk mengetesnya. Nomor test cases dapat merupakan referensi terhadap suatu
kumpulan data on-line dimana tes sepenuhnya didiskripsikan atau dapat juga merupakan
referensi secara sederhana ke nomor map atau folio.
Contoh matrik menyebutkan bahwa test cases 87, 88, dan 102 harus diselesaikan
sepenuhnya untuk memenuhi testing dari kebutuhan 1. Perlu dicatat bahwa test cases 87 dan
88 juga digunakan untuk kebutuhan 2 dan 4. Hal ini tentunya berlawanan dengan apa yang
dipikirkan di awal, dimana tiap kebutuhan akan selalu diselesaikan dengan test cases yang
unik. Namun secara praktis, biasanya akan terdapat beberapa test cases untuk melakukan
Testing dan Implementasi Sistem
untuk melakukan tes kebutuhan lainnya yang memiliki kesamaan. Tidak adanya test cases
untuk kebutuhan 3 di dalam matrik, menandakan bahwa belum adanya pengembangan
ataupun persetujuan terhadap test cases yang tepat untuk kebutuhan 3.
Keuntungan penggunaan matrik validasi kebutuhan, adalah sebagai berikut:
Memastikan kebutuhan telah didaftarkan.
Mengidentifikasikan tes-tes yang dihubungkan dengan tiap kebutuhan.
Memfasilitasi review dari kebutuhan dan tes.
Menyediakan mekanisme yang mudah untuk melacak status dari disain test case dan
review kinerja proses.
Memberikan kemudahan dalam membuat sebagian rencana tes utama dan dapat diubah
di sepanjang proses dari proyek untuk memberikan data dari semua testing kebutuhan.
6.9.3 Testi ng k e butuha n denga n melakukan tes protipe atau
mod el
Strategi yang penting lainnya untuk testing kebutuhan (menentukan apakah tiap kebutuhan ada yang hilang atau kurang atau apakah kebutuhan dapat disederhanakan) adalah dengan melakukan tes prototipe atau model. Teknik termasuk pembangunan sederhana suatu model atau prototipe sistem, tidak termasuk penggunaannya secara inten, namun untuk melakukan tes dan konfirmasi pengetahuan akan kebutuhan yang sebenarnya.
Keuntungan dari model, yaitu:
Suatu gambar menggambarkan ribuan pernyataan.
Suatu contoh menggambarkan ribuan gambar.
Tes model secara khusus berguna bila terdapat sangat sedikit pengetahuan tentang
kebutuhan dan hal tersebut penting untuk mendapatkan beberapa “eksperimen” dengan
membuat suatu model. Suatu model mengenali perubahan kebutuhan dengan pengalaman dan merupakan suatu cara terbaik dalam melakukan tes untuk mengetahui kebutuhan yang benar secara tepat yang digunakan suatu sistem (atau setidaknya sebagai kerangka yang secara praktis disediakan untuk tujuan-tujuan dari tes).
Praktek yang populer dalam pengembangan secara bertahap adalah suatu ekstensi dari
konsep prototipe. Pengembangan secara bertahap secara sederhana berarti bahwa proses penetapan kebutuhan dan pendisaian, pembangunan, dan testing suatu sistem dilakukan dalam bentuk perbagian. Kemudian berdasar pada pengalaman dari bagian tersebut, dapat
digunakan dalam memprediksikan permasalahan dari bagian yang lainnya, demikian
seterusnya. Keuntungannya adalah kebutuhan untuk tahap berikutnya tidak harus dispesifikasikan secara prematur dan dapat diatur berdasarkan pada pengalaman kerja.
6.9.4 Teknik testing kebutuhan lainnya
Testing untuk kebutuhan yang hilang atau terlewatkan dapat dibantu dengan mengorganisasikan atau “me-strukturisasi”daftar kebutuhan yang ada. Membuat indek dan
Testing dan Implementasi Sistem
mengorganisasikan berdasarkan fungsi, atau elemen data atau keluaran sistem sehingga kebutuhan dapat digrupkan, akan sangat berguna, terutama sebagai langkah awal dalam
review formal. Daftar cek (checklist) juga dapat berguna sebagai pengingat dari area-area
kebutuhan atau kesalahan-kesalahan atau perkecualian-perkecualian sebelumnya yang akan disupervisi. Bila kebutuhan telah digrupkan, akan dapat dianalisa dalam suatu blok untuk kesederhanaan, redudansi dan konsistensi. Dengan melihat keseluruhan grup, akan dapat memudahkan dalam menyederhanakan formulasi atau kebutuhan tingkat tinggi yang memiliki spesifikasi sama secara efektif, dan elemen yang tidak dibutuhkan dapat disederhanakan dengan membuangnya.
Keberadaan alat bantu dan pendukung otomatisasi yang digunakan untuk testing kebutuhan
sangat sedikit. Disain yang berorientasi pada testabilitas akan sangat membantu dalam
meningkatkan kemampuan dalam mengetahui dan validasi kebutuhan. Alat bantu otomatisasi yang dapat digunakan, adalah program pengindekan untuk mengrupkan hal-hal yang berkaitan dengan kebutuhan, penganalisa paragraf untuk menandai kebingungan dan pernyataan yang terlalu komplek, dan penganalisa tabel keputusan dan grafik sebab akibat.
Segala hal yang membantu untuk membuat kebutuhan dapat dites lebih baik, akan
meningkatkan kemampuan dalam menyederhanakan atau menghilangkan kebutuhan yang tidak diperlukan. Melakukan spesifikasi kebutuhan dalam bentuk tabel keputusan atau grafik sebab akibat adalah salah satu contohnya. Penggunaan tabel untuk memperlihatkan kondisi yang mungkin dan spesifikasi aksi yang diinginkan akan menyediakan suatu tes implisit dalam menentukan kesuksesan. Jadi kebutuhan yang disediakan dalam bentuk suatu tabel
keputusan (atau grafik sebab akibat) akan dapat dites secara inheren dan akan dapat
divalidasi dengan amat mudah.
Tidak ada formula sederhana yang jelas untuk testing kebutuhan. Review yang baik merupakan komponen dasar. Semua alat otomatisasi hanya akan memainkan peran yang minor dalam praktek testing kebutuhan.
6 . 1 0
T e s t i n g D i s a i n S i s t e m
Sebagaimana pada testing kebutuhan, pada testing disain sistem juga mempunyai dua pertanyaan dasar, yaitu:
Apakah solusi merupakan pilihan yang benar?
Dapatkah disain dicapai dengan lebih sederhana? Apakah merupakan pendekatan alternatif yang terbaik? Apakah merupakan cara tercepat untuk melakukan pekerjaan?
Apakah solusi memenuhi kebutuhan?
Apakah semua kebutuhan telah dicakup dalam disain? Apakah merupakan disain kerja?
Apasaja sumber dan resiko dari kegagalan?
Sekali lagi metode testing yang dominan digunakan adalah review formal. Untuk melakukan tes fase disain secara efektif, review disain harus direncanakan dan dilakukan sepanjang
Testing dan Implementasi Sistem
fase. Review harus menentukan tidak hanya apakah disain akan bekerja, namun juga apakah alternatif yang dipilih merupakan pilihan yang terbaik dari yang ada.
Metode-metode yang dapat digunakan untuk menetapkan adalah:
Simulasi dan model.
Kompetisi disain.
Kebutuhan dan disain test cases berbasis disain.
alternatif dan validasi disain,
6 . 1 0 . 1
T e s t i n g d i s a i n
m e n g g u n a k a n a n a l i s a a l t e r n a t i f
Proses disain secara inheren terdiri dari alternatif-alternatif. Hal yang sangat penting perlu diperhatikan, adalah testing harus dilakukan untuk konfirmasi bahwa pendekatan yang dipilih oleh pendisain merupakan alternatif yang tepat.
Pada software, analisa terhadap alternatif yang ada sangat jarang dilakukan. Review disain
berkonsentrasi pada pertanyaan apakah disain akan bekerja, dan kemudian pendisain akan secara cepat terfokus pada pendekatan-pendekatan tertentu. Alternatif-alternatif harus direview di awal proses disain. Sehingga dibutuhkan waktu satu atau dua minggu untuk melakukan review disain tingkat tinggi setelah fase disain dimulai. Perencanaan review harus
berkonsentrasi pada alternatif-alternatif dan cara-cara mengevaluasi dan
membandingkannya.
Pendisain harus mendeskripsikan alternatif-alternatif yang mereka pertimbangkan namun ditolak dan alasan yang mendasar terhadap alternatif yang dipilih. Review dibagi menjadi dua bagian. Pertama, pereview mendengarkan alternatif-alternatif disain yang dipertimbangkan oleh pendisain, dan menelaah keunggulan-keunggulan dan kekurangan-kekurangan tiap alternatif. Terdapat sesi istirahat antara bagian pertama dan bagian kedua, dimana tiap pereview diminta untuk mengevaluasi alternatif-alternatif disain yang ada, bilamana terdapat alternatif yang belum dipertimbangkan. Pada pertemuan kedua dari tim review, alternatif- alternatif yang telah dievaluasi dan disain keseluruhan dipertimbangkan lagi. Teknik lainnya adalah menggunakan konsep kompetisi disain, yang akan didiskusikan pada sub bab berikutnya.
Koreksi terhadap pendekatan yang salah tidak dapat dilakukan kemudian tanpa memulai dari awal. Hal ini menjadikan permasalahan menjadi sederhana, yaitu memulai dengan benar dari awal atau hidup dengan penuh konsekuensi. Tak ada review formal lainnya yang sangat mendasar seperti review disain tingkat tinggi, dan dari keseluruhan fase testing merupakan hal yang sangatlah fundamental.
6.10.2
Memaksa analisa alternatif dengan komp etisi disain
Teknik ini adalah teknik yang memanfaatkan psikologi manusia, dimana pendisain akan dipaksa untuk melakukan analisa alternatif disain sebelum mengajukan suatu solusi disain,
Testing dan Implementasi Sistem
kompetisi di antara pendisain, salah satunya adalah dengan memberikan suatu penghargaan baik berupa imbalan uang ataupun bentuk yang lain bagi pemenang kompetisi disain, yaitu pendisain yang mengajukan disain terbaik. Penilaian kompetisi tentunya melalui review formal terhadap disain, sebagaimana dijelaskan pada sub bab sebelumnya.
6.10.3
Testing disain dengan melakukan tes mod el
Disain mempunyai banyak aspek-aspek kritis yang cocok untuk dilakukan testing
berdasarkan tes model atau analisa dari simulasi. Teknik dasar terdiri dari pembangunan representasi yang disederhanakan atau model dari sifat disain yang dipilih dan kemudian penggunaan model untuk mengeksplorasi (atau melakukan tes) disain tersebut. Model menjadikan testing dapat dilakukan di awal dalam fase disain, sebelum pemrograman dimulai, dan memastikan bahwa disain benar (setidaknya berhubungan dengan aspek yang dites). Suatu model digunakan secara ekstensif untuk melakukan tes konfigurasi disain database, sekuensial transaksi, waktu respon, dan antar muka pengguna.