Testing dengan Sp esifikasi yang Berevolusi

8.1 Testing dengan Sp esifikasi yang 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. Dalam pendekatan waterfall terdapat serangkaian fase tere ncana, dengan suatu penanda akhir fase sebelum bergerak ke fase berikutnya. Fase-fase utama, adalah: analisa, disain, 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, By Hendranet dan dokumentasi yang dibutuhkan, menjadikan proses membutuhkan waktu yang lama dalam menyerahkan produk. Sistem yang diserahk an biasanya tidak sesuai dengan yang dibutuhkan, sebagian karena kebutuhan ini telah berubah dalam kurun waktu tunggu, dan sebagian lagi karena

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 opment (RAD) terhadap 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.

Pendekatan spiral / iterasi dikembangkan untuk lebih memberdayakan proses pengembangan dan perawatan sistem, melalui:

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 ngkinkan sistem dapat berevolusi dari waktu ke waktu, dan menjadi fleksibel serta mudah untuk diubah. Sistem pelatihan profesional terhadap RAD atau meto dologi prototyping .

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 By Hendranet

berikutnya, sehingga tak pernah mencapai akhir proyek. Proses testing pada pendekatan prototyping, spiral / iterasi, RAD berbeda dengan model 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 empelajari dan menganalisa sistem dan mengembangkan 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 n sekilas dimana perkembangan didiskusikan. Dan 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 penden), dan melakukan tes versi baru segera setelah terselesaikan. Testing tiap iterasi dilakukan secara singkat, dan fokus tiap iterasi tes berikutnya, sehingga tak pernah mencapai akhir proyek. Proses testing pada pendekatan prototyping, spiral / iterasi, RAD berbeda dengan model 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 empelajari dan menganalisa sistem dan mengembangkan 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 n sekilas dimana perkembangan didiskusikan. Dan 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 penden), dan melakukan tes versi baru segera setelah terselesaikan. Testing tiap iterasi dilakukan secara singkat, dan fokus tiap iterasi tes

Menetapkan suatu obyektifitas dan cakupan yang jelas di depan, dan jangan sampai keluar dari batasan yang di tetapkan selama proses pengembangan berlangsung.

Pernyataan obyektifitas tidak perlu detil, na mun dapat menentukan arah proyek. Menetapkan titik penilaian kembali secara periodek, untuk memastikan proyek masih sesuai den gan obyektifitas dan cakupan, dan proyek masih dalam arah yang tepat. Merencanakan secara bertahap, dan secara bertingkat menstabilkan si stem dalam kinerja spiral. Spiral awal, yang biasanya hanya bersifat internal dan tidak untu k pelanggan eksternal, tak dapat ditetapkan keberhasilannya dalam m emenuhi kebutuhan, sehingga perbandingan alokasi sumber daya pengembangan dan testing dapat menjadi 5:1. Harapan reliabilitas sangat rendah pada iterasi a wal. Saat sistem mulai stabil, rata- rata perubahan kode dari iterasi ke iterasi seharusnya menurun sekitar 20%. Dan pada akhi r spiral , sebelum kepastian dicapai, perbandingan alokasi sumber daya pengembangan dan testing adalah 2:1 atau bahkan 1:1.