sebagian besar konsep baru berdasarkan pada konsep lama yang disesuaikan untuk memenuhi perkembangan dari kebutuhan akan testing yang baru.
8.1 Testing dengan Sp
Berevolusi
Model waterfall tradisional dari pengembangan sistem yang telah ada sejak sekitar 25 tahun yang lalu dikembangkan untuk memecahkan masalah pada situasi pengembangan dalam waktu yang singkat, dimana masalah yang ditangani tidak dianalisa dan dipahami dengan baik, serta solusi yang diajukan tidak didisain dengan baik pula.
ncana, dengan suatu penanda akhir fase sebelum bergerak ke fase berikutnya. Fase-fase utama, adalah: analisa, disain,
an biasanya tidak sesuai dengan yang dibutuhkan, sebagian karena waktu tunggu, dan sebagian lagi karena
opment (RAD) terhadap Dalam pendekatan waterfall terdapat serangkaian fase tere
pemrograman, testing, dan instalasi. Pendekatan perfase, secara tak langsung memberikan komitmen terhadap proyek, dan membangun kendali pada proses pengembangan.
Model waterfall bekerja dengan baik, namun terdapat kendala-kendala sebagai berikut:
Pelanggan biasanya tidak mengetahui apa yang mereka inginkan hingga mereka melihatnya. Harapan akan spesifikasi dapat didefinisikan secara keseluruhan di depan, kadang tidak realistik.
Keberadaan sekuensial fase-fase secara linear, penanda akhir fase, manajemen review, dan dokumentasi yang dibutuhkan, menjadikan proses membutuhkan waktu yang lama dalam menyerahkan produk.
Sistem yang diserahk
kebutuhan ini telah berubah dalam kurun
pengguna tidak pernah diikutsertakan secara mendalam dalam pendefinisian kebutuhan sistem.
Sistem yang diserahkan dapat menjadi tidak fleksibel, tidak dikembangkan untuk mengakomodasi perubahan dan sulit untuk dirawat.
Bila terjadi perubahan spesifikasi selama proyek berlangsung, kebanyakan tim pengembang tidak menyimpan definisi kebutuhan dan dokumen disain yang terkini.
Pendekatan prototyping, spiral / iterasi, dan rapid application devel
pengembangan sistem adalah reaksi terhadap keterbatasan model waterfall. Saat definisi awal kebutuhan akan datang tidak dapat dibuat secara komplit dan akurat, terdapat ide untuk memulainya dengan membuat suatu prototype awal, untuk kemudian diadaptasikan dan dievolusikan sesuai dengan evolusi kebutuhan atau pemahaman terhadap pengembangan kebutuhan.
Bab VIII Konsep Baru Sekitar Testing Halaman 190 Pendekatan spiral / iterasi dikembangkan untuk lebih memberdayakan proses pengembangan dan perawatan sistem, melalui:
ngkinkan sistem dapat berevolusi dari waktu ke waktu, dan menjadi fleksibel serta
dologi prototyping.
/ iterasi, RAD berbeda dengan model
empelajari dan menganalisa sistem dan mengembangkan
n sekilas dimana perkembangan didiskusikan. Dan
penden), dan melakukan tes versi baru segera setelah terselesaikan. Testing tiap iterasi dilakukan secara singkat, dan fokus tiap iterasi tes
Memperlihatkan hasil dengan cepat, dalam bentuk prototype atau pengerjaan sistem di awal dengan fungsional awal yang terbatas.
Mendukung pengguna untuk berpartisipasi secara material dalam proses. Bereksperimen dengan reaksi terhadap suksesi tiap iterasi pembangunan sistem.
Memu
mudah untuk diubah.
Sistem pelatihan profesional terhadap RAD atau meto
Otorisasi dan pemberdayaan tim untuk menyelesaikan pekerjaan.
Menerapkan konsep rekayasa software, dimana analisa, disain, pengkodean, dam testing dilakukan secara paralel dalam suatu sekuensial fase yang linier.
Penggunaan pemrograman visual, alat bantu berorientasi obyek dalam pengembangan dan modifikasi.
Namun pendekatan prototyping, spiral / iterasi, RAD juga masih memiliki kendala, antara lain:
Proyek menjadi sulit diprediksi, dengan sedikit pengendalian dan cenderung mudah lepas kendali.
Arsitektur sistem biasanya tak terencana.
Dengan makin meningkatnya perubahan-perubahan yang terjadi setiap waktu, kadangkala sistem menjadi tidak dapat dirawat.
Fleksibilitas dan kemudahan perubahan dapat menjadi kontra produktif. Kebutuhan dapat hilang kendali, atau dibatalkan dari suatu versi dan ditambahkan kembali pada versi berikutnya, sehingga tak pernah mencapai akhir proyek.
Proses testing pada pendekatan prototyping, spiral
waterfall. Dalam model waterfall, testing berdasarkan pada dokumen spesifikasi atau definisi kebutuhan. Dokumen-dokumen ini diharapkan dapat diselesaikan secara komplit, benar dan tidak berubah secara esensial, setidaknya selama proyek berlangsung. Berdasarkan salinan dokumen-dokumen ini, tester m
rencana tes.
Secara kontras, proses testing pada pendekatan prototyping, spiral / iterasi, dan RAD sangat berbeda dengan model waterfall, karena spesifikasi dan definisi produk pada pendekatan prototyping, spiral / iterasi, dan RAD tidak tetap dan terus berevolusi secara tak pasti. Suatu definisi kebutuhan dan disain sistem berkemungkinan tidak akan pernah didokumentasikan, karena cepatnya pergerakan proyek; spesisikasi dapat dalam bentuk tak formal dan tak lebih dari koleksi memo-memo dan pertemua
satu-satunya cara untuk melakukan testing adalah ikut masuk ke dalam keseluruhan proses spiral dari pengembangan. Tester harus sangat dekat dengan usaha pengembangan (beresiko kehilangan prespektif yang inde
Bab VIII Konsep Baru Sekitar Testing Halaman 191 harus mengutamakan fitur yang ditambahan atau diubah. Idealnya, harus menggunakan alat bantu otomasi dalam melakukan tes regresi, yang dapat digunakan untuk melakukan tes
n:
tetapkan selama proses pengembangan berlangsung. mun dapat menentukan arah proyek.
gan obyektifitas dan cakupan, dan proyek masih dalam arah yang tepat.
stem dalam k emenuhi kebutuhan,
5:1. wal. Saat sistem mulai stabil, rata-
akhi , sebelum kepastian dicapai, perbandingan alokasi sumber daya secara singkat terhadap produk versi baru yang dirilis.
Solusi dalam menangani permasalahan atau kendala pada pendekatan prototyping, spiral / iterasi, dan RAD, antara lai
Menetapkan suatu obyektifitas dan cakupan yang jelas di depan, dan jangan sampai keluar dari batasan yang di
Pernyataan obyektifitas tidak perlu detil, na
Menetapkan titik penilaian kembali secara periodek, untuk memastikan proyek masih sesuai den
Merencanakan secara bertahap, dan secara bertingkat menstabilkan si
kinerja spiral. Spiral awal, yang biasanya hanya bersifat internal dan tidak untu pelanggan eksternal, tak dapat ditetapkan keberhasilannya dalam m
sehingga perbandingan alokasi sumber daya pengembangan dan testing dapat menjadi Harapan reliabilitas sangat rendah pada iterasi a
rata perubahan kode dari iterasi ke iterasi seharusnya menurun sekitar 20%. Dan pada r spiral
pengembangan dan testing adalah 2:1 atau bahkan 1:1.
8.2 Testing Berorientasi Obyek
Sasaran testing secara sederhana adalah untuk menemukan kemungkinan terbesar jumlah
lebih banyak testing yang diperlukan agar error dengan jumlah usaha yang dapat dimanajemeni pada rentang waktu yang realistis. Meskipun sasaran fundamental itu tetap tidak berubah untuk software berorientasi obyek (OO), sifat program OO mengubah baik strategi maupun taktik pengujian.
Tidaklah benar pendapat bahwa pada saat OOA dan OOD matang, penggunaan kembali (reuse) pola disain secara lebih banyak akan mengurangi jumlah kebutuhan testing untuk sistem OO.Biner [BIN94] membahas tentang hal tersebut dengan menyatakan :
Setiap reuse merupakan konteks baru kegunaan dan testing kembali merupakan hal yang bijaksana. Hal ini memungkinkan untuk
mendapatkan reliabilitas yang tinggi di dalam sistem OO.
Untuk melakukan testing sistem OO yang mencukupi, harus dilakukan tiga hal berikut: (1) definisi testing harus diperluas untuk mencakup teknik penemuan error yang diaplikasikan ke dalam model OOA dan OOD; (2) strategi unit testing akan menjadi kurang berarti dan strategi integrasi harus berubah secara signifikan; (3) disain test case harus bertanggung jawab terhadap karakteristik unik software OO.
8.2.1 Perluasan Pandang Testing
Pengembangan software OO dimulai dengan kriteria model analis dan disain. Karena sifat evolusioner dari paradigma pengembangan software, maka model-model itu berawal dari representasi yang tidak formal dari persyaratan sistem dan berkembang ke dalam model-
Bab VIII Konsep Baru Sekitar Testing Halaman 192 model kelas yang detil, koneksi dari hubungan kelas, disain dan alokasi sistem, dan disain
si atribut kelas yang diungkap selama analisis,
pada kelas tersebut (sehubungan dengan kesalahpahaman domain masalah). Dua operasi kemudian dikhususkan untuk memanipulasi
mudian dilakukan dan domain lanjut menunjukkan masalah
g
ain:
Alo n atau tugas-tugas dapat terjadi
alisis.
Ker nciptakan disain prosedural bagi
ungannya.
Mod di tidak benar (karena pesan harus didisain untuk operasi
dak terdeteksi selama disain dan berlanjut ke dalam aktivitas
pengko r usaha dan energi untuk memunculkan kode yang
mengim operasi yang tidak diperlukan, pesan-
pesan byek, dan berbagai masalah lain yang
obyek (menghubungkan model konektifitas melalui pemesanan). Pada masing-masing tahap, model tersebut dapat berupa testing untuk mengungkap error sebelum menyebar ke iterasi selanjutnya.
Kajian terhadap model disain analis OO secara khusus berguna karena gagasan sematik yang sama (misalnya, kelas, atribut, operasi, pesan) muncul pada tingkat analisis, disain, dan kode. Dengan demikian, masalah pada defini
akan menghidarkan efek samping yang mungkin terjadi bila masalah tidak ditemukan sampai disain atau pengkodean (atau bahkan pada iterasi selanjutnya).
Sebagai contoh, perhatikan suatu kelas di mana sejumlah atribut ditetapkan selama iterasi OOA pertama. Atribut ekstra dilampirkan
atribut tersebut. Kajian ke
tersebut. Dengan mengeliminasi atribut yang tidak ada hubungannya pada tahap ini, maka selama analisis, masalah dan usaha yang tidak perlu berikut ini dapat dihindari:
Subkelas khusus mungkin dimunculkan untuk mengakomodasi atribut atau pengecualian yang tidak perlu. Usaha yang dilibatkan di dalam pembuatan subkelas yang tidak perlu telah dihindari.
Salah interpretasi mengenai definisi kelas dapat menyebabkan hubungan kelas yan tidak ada hubungannya atau yang tidak benar.
Tingkah laku sistem atau kelasnya dapat secara tidak teratur ditandai untuk mengakomodasi atribut yang tidak ada hubungannya.
Bila masalah tidak ditemukan selama analisis dan penyebaran lebih lanjut, masalah berikut ini dapat muncul (dan akan dihindari karenan kajian awal) selama dis
kasi yang tidak tepat dari kelas ke subsisten da selama disain an
ja disain yang tidak perlu dapat dilakukan untuk me operasi yang mencakup atribut yang tidak ada hub
el pemesanan akan menja yang tidak ada hubungannya). Bila masalah tetap ti
dean, maka akan kelua
plementasi atribut yang tidak berguna, dua yang mengendalikan komunikasi antar o
berhubungan. Sebagai tambahan, pengujian kelas akan menyerap lebih banyak waktu daripada yang diperlukan. Begitu masalah akhirnya terungkap, maka modifikasi ke sistem tersebut harus dilakukan dengan potensi yang pernah ada untuk efek samping yang disebabkan oleh perubahan.