Metodologi Rasional Rose
6.9 Testing Kebutuhan
Testing suatu dokumen harus mempertimbangkan dua pertanyaan dasar, yaitu: 1. Apakah ada kebutuhan yang hilang?
Ap semua fungsi yang dibutuhkan telah dialamatkan dengan benar? Apakah kinerja yang dibutuhkan telah dispesifikasikan?
Apakah kualitas softwar akah
e telah dispesifikasikan?
njawab dua pertanyaan ini secara efektif bergantung pada pemenuhan review
mban
Apakah software telah sepenuhnya didefinisikan?
2. Dapatkah suatu kebutuhan disederhanakan atau dihilangkan? Dapatkah kebutuhan dikombinasikan?
Apakah ada kebutuhan yang sangat restriktif?
Apakah ada kebutuhan yang redundansi atau kontradiksi? Untuk me
formal sebagai metodologi dasar. Pengetahuan bagaimana untuk melakukan tes terhadap suatu kebutuhan adalah syarat untuk dapat melakukan validasi atau tes kebenaran dari kebutuhan dan formulasi dari kebutuhan, atau untuk dapat melakukan tes kebutuhan dengan menganalisa bagaimana untuk melakukan tes terhadap kebutuhan tersebut.
Teknik-teknik yang berguna dalam testing kebutuhan, termasuk: Matrik validasi kebutuhan.
Model atau prototipe.
Penge gan secara bertahap.
Tabel keputusan dan grafik sebab dan akibat. Penggrupan dan analisa kebutuhan.
6.9.1 Testing kebutuhan dengan menggunakan disain test cases
berbasis kebutuhan
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
Bab VI Proses Testing Halaman 156 berbasis kebutuhan akan tidak dapat dispesifikasikan dengan baik. Bagaimanapun, tujuannya adalah untuk membuat situasi tes berbasis pada kebutuhan dan menggunakannya sebagai
EP, sebagaimana telah dibahas pada sub bab sebelumnya, tekanan tes dari pengertian dan validasi kebutuhan (misal ketidaklengkapan dan ketidakpresisian kebutuhan).
Metodologi testing ST
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 Matrik 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 bagi item yang telah habis. Menghasilkan order kembali secara otomatis 4 Menghasilkan verifikasi kredit pelanggan untuk 87, 88, 103-1pelanggan baru secara otomatis. 06 V
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.
diselesaikan sepenuhnya untuk memenuhi testing dari kebutuhan 1. Perlu dicatat bahwa test cases 87 dan
test cases yang test cases untuk melakukan gunakan kembali beberapa test cases tersebut Contoh matrik menyebutkan bahwa test cases 87, 88, dan 102 harus
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
unik. Namun secara praktis, biasanya akan terdapat beberapa tes suatu kebutuhan secara efektif, dan meng
Bab VI Proses Testing Halaman 157 untuk melakukan tes kebutuhan lainnya yang memiliki kesamaan. Tidak adanya test cases untuk kebutuhan 3 di dalam matrik, menandakan bahwa belum adanya pengembangan
Keu lidasi kebutuhan, adalah sebagai berikut:
tes-tes yang dihubungkan dengan tiap kebutuhan.
mudah untuk melacak status dari disain test case dan m membuat sebagian rencana tes utama dan dapat diubah ataupun persetujuan terhadap test cases yang tepat untuk kebutuhan 3.
ntungan penggunaan matrik va
Memastikan kebutuhan telah didaftarkan. Mengidentifikasikan
Memfasilitasi review dari kebutuhan dan tes. Menyediakan mekanisme yang
review kinerja proses. Memberikan kemudahan dala
di sepanjang proses dari proyek untuk memberikan data dari semua testing kebutuhan.
6.9.3 Testing kebutuhan dengan melakukan tes protipe atau
model
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
dengan erupakan suatu cara terbaik dalam melakukan tes untuk mengetahui kebutuhan yang
pat yang digunakan suatu sistem (atau setidaknya sebagai kerangka yang sec
Praktek suatu ekstensi dari
kon secara sederhana berarti bahwa proses
pen esting suatu sistem dilakukan
ian. Kemudian berdasar pada pengalaman dari bagian tersebut, dapat
digu demikian
sete
dispesifi atur dan dapat diatur berdasarkan pada pengalaman kerja.
6.9.4 Teknik testing kebutuhan lainnya
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”
membuat suatu model. Suatu model mengenali perubahan kebutuhan dengan pengalaman dan m
benar secara te
ara praktis disediakan untuk tujuan-tujuan dari tes).
yang populer dalam pengembangan secara bertahap adalah sep prototipe. Pengembangan secara bertahap
etapan kebutuhan dan pendisaian, pembangunan, dan t dalam bentuk perbag
nakan dalam memprediksikan permasalahan dari bagian yang lainnya,
rusnya. Keuntungannya adalah kebutuhan untuk tahap berikutnya tidak harus kasikan secara prem
Testing untuk kebutuhan yang hilang atau terlewatkan dapat dibantu dengan mengorganisasikan atau “me-strukturisasi”daftar kebutuhan yang ada. Membuat indek dan
Bab VI Proses Testing Halaman 158 mengorganisasikan berdasarkan fungsi, atau elemen data atau
kebutuhan dapat digrupkan, akan sangat berguna, terutama se
keluaran sistem sehingga bagai langkah awal dalam ari area-area u kesalahan-kesalahan atau perkecualian-perkecualian sebelumnya yang akan
disu dianalisa dalam suatu blok untuk
kes pat
m menyederhanakan formulasi atau kebutuhan tingkat tinggi yang memiliki
spe dibutuhkan dapat disederhanakan
den
Kebera omatisasi yang digunakan untuk testing kebutuhan
dikit. at membantu dalam
kan k lat bantu otomatisasi
ng terlalu komplek, dan penganalisa tabel keputusan dan grafik sebab akibat.
Segala hal yang membantu untu h baik, akan
meningkatkan kem lam men atau m kebutuhan yang
tidak diperluk ifikasi kebu an dalam bentuk tabel keputusan atau grafik sebab akibat ntohnya. Penggunaan tabel u erlihatkan kondisi yang mungki si aksi yang dii inkan akan meny an suatu tes implisit dalam mene ksesan. Jadi kebutu yang disediak bentuk suatu tabel
keputusan ibat) akan apat dites seca dan akan dapat
divalidasi de
idak ada formula sederhana yang jelas untuk testing kebutuhan. Review yang baik praktek testing kebutuhan.
6.10 Te g D
review formal. Daftar cek (checklist) juga dapat berguna sebagai pengingat d kebutuhan ata
pervisi. Bila kebutuhan telah digrupkan, akan dapat
ederhanaan, redudansi dan konsistensi. Dengan melihat keseluruhan grup, akan da memudahkan dala
sifikasi sama secara efektif, dan elemen yang tidak gan membuangnya.
daan alat bantu dan pendukung ot
sangat se Disain yang berorientasi pada testabilitas akan sang meningkat emampuan dalam mengetahui dan validasi kebutuhan. A
yang dapat digunakan, adalah program pengindekan untuk mengrupkan hal-hal yang berkaitan dengan kebutuhan, penganalisa paragraf untuk menandai kebingungan dan pernyataan ya
k membuat kebutu an dapat dites lebih ampuan da yederhanakan enghilangkan an. Melakukan spes tuh
adalah salah satu co ntuk memp
n dan spesifika ng ediak
ntukan kesu han an dalam
(atau grafik sebab ak d ra inheren
ngan amat mudah. T
merupakan komponen dasar. Semua alat otomatisasi hanya akan memainkan peran yang minor dalam
stin isain Sistem
Sebagaiman tuhan, pa esting disain sistem juga mempunyai dua pertanyaan d
Apakah s n pilihan yang b
Dapa dicapai dengan leb rhana?
Apak atan alte ang terbaik?
Apak a tercepat un elakukan pekerjaa
Apakah s emenuhi kebutuhan?
Apakah semua kebutuhan telah dicakup dalam disain? pasaja sumber dan resiko dari kegagalan?
a pada testing kebu da t asar, yaitu:
olusi merupaka enar?
tkah disain ih sede
ah merupakan pendek rnatif y
ah merupakan car tuk m n?
olusi m
Apakah merupakan disain kerja? A
Bab VI Proses Testing Halaman 159 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 n,
adalah:
n dan disain test cases sis disain
ain gguna n analisa al atif
alternatif dan validasi disai Simulasi dan model.
Kompetisi disain.
Kebutuha berba .
6.10.1 Testing dis men ka tern
Proses disain secara inheren terdiri alternatif-alternatif. Hal yang t penting perlu h testing harus d n untuk masi bahwa pe tan yang dipilih leh pendisain merupakan alternatif yang tepat.
are, w disain
trasi pada p kan
rtentu. Alternatif-alternatif harus mel tingkat tinggi setelah fase disain dimulai. Perencanaan review harus mem
dito
bag ngarkan alternatif-alternatif disain yang dipertimbangkan
alte ian pertama dan bagian kedua, dimana tiap
alte
ternatif-ipertimbangkan lagi. Teknik lainnya in, yang akan didiskusikan pada sub bab Kor
awa ermasalahan menjadi sederhana, yaitu memulai dengan benar dari men kat tinggi, dan dari keseluruhan fase testing merupakan
6.10.2
dari sanga
diperhatikan, adala ilakuka konfir ndeka
o
Pada softw analisa terhadap alternatif yang ada sangat jarang dilakukan. Revie berkonsen ertanyaan apakah disain akan bekerja, dan kemudian pendisain a secara cepat terfokus pada pendekatan-pendekatan te
direview di awal proses disain. Sehingga dibutuhkan waktu satu atau dua minggu untuk akukan review disain
berkonsentrasi pada alternatif-alternatif dan cara-cara mengevaluasi dan bandingkannya.
Pendisain harus mendeskripsikan alternatif-alternatif yang mereka pertimbangkan namun lak dan alasan yang mendasar terhadap alternatif yang dipilih. Review dibagi menjadi dua ian. Pertama, pereview mende
oleh pendisain, dan menelaah keunggulan-keunggulan dan kekurangan-kekurangan tiap rnatif. Terdapat sesi istirahat antara bag
pereview diminta untuk mengevaluasi alternatif-alternatif disain yang ada, bilamana terdapat rnatif yang belum dipertimbangkan. Pada pertemuan kedua dari tim review, al
alternatif yang telah dievaluasi dan disain keseluruhan d adalah menggunakan konsep kompetisi disa
berikutnya.
eksi terhadap pendekatan yang salah tidak dapat dilakukan kemudian tanpa memulai dari l. Hal ini menjadikan p
awal atau hidup dengan penuh konsekuensi. Tak ada review formal lainnya yang sangat dasar seperti review disain ting
hal yang sangatlah fundamental.