SOFTWARE TESTING STRATEGIES Software validation Validasi software atau sering disebut verification and Validation.

Verification mengacu kepada sekumpulan aktifitas yang memastikan bahwa sistem telah mengimplementasikan fungsi yang sesuai dengan spesifikasi. Validation mengacu kepada sekumpulan aktifitas yang berbeda yang memastikan bahwa software telah dikembangkan dapat memenuhi ekspektasi/harapan pengguna sistem. Melibatkan checking dan review proses serta ujicoba sistem. Ujicoba sistem meliputi pengeksekusian sistem dengan skenario uji yang diturunkan dari spesifikasi data real untuk diproses oleh sistem. Verification : Are we building the product right ! Validation : Are we building the right product !

U n it te s t in g M o d u l e te s t in g S u b s y s t e m te s t i n g S y s te m te s t in g A c c e p t a n c e te s t in g

C o m p o n e n t te s t in g

I n te g r a ti o nte s ti n g

U s e r te s t in g

The testing process

System Analysis System Design Software Design Program Design Module Design

ser Spesification System Spesification Software Spesification Program Spesification Module Spesification PROGRAMMING

Acceptance Testing System Testing Function Testing Integration Testing nit Testing

"elationship between system de#elopment and testing acti#ities $Adams, Powers, Owles, 1985%

Ayuliana/&esting dan 'mplementasi/(eb)*++

Tahapan-Tahapan Ujicoba 1. Unit Testing/Module Testing nit testing!"od#le Testing dilaksanakan untuk mengetahui kesalahan dalam logika atau fungsi setiap #nit terkecil dari software, yaitu mod#le. -iujikan pada komponen.komponen yang saling terhubung dan saling bergantung satu dengan yang lainnya. &ipe.tipe kesalahan yang mungkin terjadi, diantaranya : a. Kesalahan Tampilan (Interface errors) +. Ujicoba jenis ini diaplikasikan pada bagian program dimana data dan kontrol dilemparkan dari satu modul ke modul lainnya. ). /ontoh yang paling umum menyertakan pemindahan kontrol proses dari modul ke subrutin atau subprogram. 0. 1bjek dari ujicoba adalah untuk menentukan bahwa argumen yang dilemparkan ke subrutin sesuai dengan parameter yang diterima. 2. Ujicoba diaplikasikan untuk memastikan kesesuaian jumlah field data, atribut $ukuran dan tipe% field data, dan perintah pemindahan dan penerimaan. b. Kesalahan Masukan/Keluaran(Input/output errors) +. Ujicoba jenis ini diaplikasikan untuk memastikan bahwa seluruh record $file eksternal akan dibaca atau dituliskan% telah dipindahkan dan diterima seperti yang diharapkan. ). Ujicoba diaplikasikan pada atribut record, termasuk jumlah field, ukuran field, dan tipe data yang terdapat dalam field. 0. 3ebagai tambahan, kesalahan juga terlihat pada format record, organisasi file, dan penggunaan kunci. 'denya adalah untuk memastikan bahwa kunci yang digunakan sesuai dengan record dan file yang disusun dan direferensikan sesuai dengan kunci. 2. Ujicoba juga mencakup prosedur pembukaan dan penutupan file yang digunakan dan penanganan kesalahan pada input dan output. Memeriksa kesalahan dalam flagging pada kondisi end$of$file dan proses yang sesuai jika terjadi file n#ll atau empt%. 4. -engan akses langsung pada file, ujicoba diaplikasikan untuk kesalahan yang terjasi jika record yang sesuai dengan kunci ditemukan, atau tidak. 5. 6egunaan ujicoba kesalahan input.output yang paling akhir adalah menemukan kesalahan output sistem, dimana prosedur ujicobanya adalah menghasilkan atau menampilkan output yang seharusnya. 7. 1utput ini kemudian diperiksa/disesuaikan dengan spesifikasi modul untuk memastikan bahwa proses yang akurat telah dilaksanakan terhadap data dan hasil yang diharapkan telah diberikan sesuai dengan format output. c. Kesalahan Struktur ata (Data structure errors) +. Ujicoba ini mencari kesalahan dalam penanganan atau pembentukan elemen data yang didefinisikan dan dibangun dalam modul proses. ). /ontoh dapat menyertakan tabel.tabel atau record sementara yang digunakan untuk pemindahan data. Ujicoba diaplikasikan untuk perbaikan format dan atribut. 0. Ujicoba lainnya dapat berkenaan dengan definisi tabel, termasuk prosedur.prosedur utama dan ukuran tabel. 2. 8emerikasaan lainnya dilakukan untuk konsistensi pemakaian nama, untuk penginisialisasian co#nter dan akumulator dan untuk melengkapi spesifikasi data item.

d. Kesalahan !ritmatika (Arith etic errors) +. 9asil dari instruksi perhitungandalam modul diujicobakan untuk menemukan kesalahan termasuk kesalahan pendefinisian sebagaimana mestinya seluruh data item yang ditermasuk dalam instruksi aritmatika. ). Untuk setiap data item, ujicoba diaplikasikan untuk memastikan bahwa data berada dalam keadaan yang semestinya untuk eksekusi instruksi, bahwa ukuran dari hasil sementara dan hasil akhir sudah cukup besar untuk mengakomodasikan hasil perhitungan $eliminasi kesalahan potensial disebabkan pemotongan%, bahwa, perhitungan dilaksanakan dengan perintah yang tepat untuk menghasilkan hasil yang telah dispesifikasikan sebelumnya, dan bahwa nilai nol tidak dapat digunakan sebagai pembagi. $:ika ditemukan dibagi dengan ;ol, maka program harus dapat menangani kondisi ini%

Ayuliana/&esting dan 'mplementasi/(eb)*++

"

e. Kesalahan "erbandingan (!o parison errors) +. Ujicoba ini mencari kesalahan yang meliputi presentasi data item yang berbeda tipe atau bentuknya untuk fungsi.fungsi perbandingan. ). &ujuannya adalah untuk memastikan bahwa program atau modul tidak akan mengi<inkan operasi perbandingan antara field alphabetik dengan field numerik atau antara field numerik dengan bentuk yang berbeda. 0. 3ama seperti fungsi ujicoba kesalahan lainnya, idenya adalah untuk menyajikan kondisi.kondisi seperti tersebut ke sistem dan memastikan bahwa sistem dapat menangani dan me.reco#ernya. 2. Ujicoba akan menjadi sulit untuk menetapkan fungsi.fungsi seperti operasi perbandingan jamak bersarang $m#ltiple nested comparison% ditambilkan dengan perintah tertentu. f. Kesalahan #ogika Kendali proses (!ontrol "o#ic errors) +. /omputer merupakan mesin sekuensial. 6arena itu tidak diperlukan ujicoba khusus untuk fungsi kontrol sekuensial. &etapi ujicoba diaplikasikan untuk pemilihan dan pengulangan. ). Ujicoba pemilihan untuk menetapkan apakah jalur eksekusi yang benar yang dilaksanakan untuk seluruh kondisi yang diujicobakan dan untuk semua nilai dari data item yang diujicoba. :uga terhadap seluruh titik percabangan dalam fungsi pemilihan diberi label yang tepat dan memiliki titik e=it untuk semua jalur terbuka 0. Untuk struktur kontrol pengulangan, ujicoba diaplikasikan untuk memastikan bahwa inde= pengulangan telah diinisialisasikan dengan benar dan bahwa nilainya akan meningkat pada setiap iterasinya. ujicoba juga termasuk penetapan, pengujicobaan, dan pengimplementasian batas akhir loop untuk menghindari situasi loop berakhir karena h#ng$#p. "rinsip pengaplikasian ujicoba pada modul $aitu % Ujicoba semua perintah sedikitnya satu kali Ujicoba semua kemungkinan kombinasi ekseskusi atau jalur logika Ujicoba seluruh pengulangan meliputi keseluruhan range dari indeks atau subscript.nya Ujicoba semua titik masukan dan keluaran untuk setiap modul &. Sub S$stem Testing ('ntegration Testing) 'ntegrasi program meliputi prosedur.prosedur yang disertakan untuk menghubungkan modul.modul menjadi subsistem maupun sistem lengkap. Ujicoba integrasi dibangun dari spesifikasi sistem, meliputi ujicoba terhadap hubungan antar program.program untuk menentukan kemungkinan pelaksanaan dan kekuatannya. Ujicoba diaplikasikan dan diutamakan pada ujicoba interface antar modul dalam program aplikasi. &erdapat dua pendekatan yang dapat dilaksanakan : a. &ncremental testing, modul dapat ditambahkan pada modul lainnya untuk ujicoba indi#idual, biasanya berupa penulisan modul baru. b. 'onincremental testing, seluruh modul dalam program dapat dibangun terlebih dahulu, kemudian digabungkan dan diujicobakan sebagai satu entitas, sehingga seluruh interface dalam modul diujicoba dalam satu waktu untuk keseluruhan program. &erdapat dua metode untuk mengaplikasikan &ncremental testing, yaitu : a$ Top%down testin#

-iaplikasikan pada modul berbasis top$down/mengarah ke bawah berdasarkan kontrol hirarki., atau diproses dari modul le#el atas diturunkan sampai modul detail. 6omponen.komponen high level dari sistem diintegrasikan dan diujicoba sebelum rancangan dan implementasinya lengkap. 8enggabungan modul subordinate dengan modul utama dapat dilakukan dengan struktur depth$ first atau (readth$first. 'ntegrasi depth$first akan mengintegrasikan modul dijalur utama, misal dari gambar dibawah A, >, ? akan diintegrasikan lebih dulu, kemudian mengarah ke jalur tengah dan kanan 'ntegrasi (readth$first akan mengintegrasikan secara langsung seluruh modul subordinate, misal >, /, - $stub -% akan diintegrasikan lebih dulu baru le#el dibawahnya 8roses integrasi dilakukan dalam 4 tahapan : +. Modul kontrol utama digunakan sebagai test driver dan st#( disubtitusikan untuk seluruh modul yang secara langsung merupakan subordinate dari modul kontrol utama

Ayuliana/&esting dan 'mplementasi/(eb)*++

). >erdasarkan dari pendekatan integrasi yang dipilih, st#( subordinat digantikan dengan modul yang sesungguhnya pada saat yang bersamaan. 0. Ujicoba dilaksanakan pada setiap modul yangtelah diintegrasikan 2. 8ada setiap akhir dari serangkaian ujicoba, stub lainnya digantikan dengan modul yang sesungguhnya 4. )egression testing, $melaksanakan sebagian atau seluruhnya ujicoba sebelumnya% dapat dilaksanakan untuk memastikan apakah terdapat kesalahan baru.

8roses akan berulang mulai dari langkah ke.) sampai seluruh struktur program terbangun. 6eterhubungan dibuat dari modul teratas ke modul dile#el bawahnya yang belum diimplementasikan. Untuk itu, bagian dari modul yang akan menangani interface disediakan dan digunakan dalam ujicoba eksekusi yang diaplikasikan ke hubungan modul high level dengan menggunakan modul subordinat. "utin ujicoba seperti ini disebut program *t#(s. "utin ini mensimulasikan proses yang akan dijalankan ketika modul dikodekan. 3elama ujicoba, st#(s menyediakan target untuk pemanggilan subprogram sehingga modul superordinat dapat melatih fungsi kontrol mereka. *t#(s juga dapat melemparkan data ke superordinat untuk menguji interface. Ujicoba dengan pendekatan top.down memberikan #erifikasi awal dari interface utama dan juga keseluruhan logika kontrol, yang harus berasal dari tingkat teratas struktur program. 6arena dimulai dari le#el atas kebawah, maka menjadi sangat mungkin untuk mendemonstrasikan fungsi program secara lengkap dan keseluruhan pada titik awal dari prosedur ujicoba. 8erhatikan gambar berikut :

A C F G H I D J

B E

3tructure chart for program to be tested incrementally

A
StubB StubC StubD

Testing sequence

A
StubB StubC StubD

StubE &$ 'otto %(p

StubF

Ujicoba dimulai dari le#el terendah dari struktur program dan bergerak keatas sebagai sebuah modul yang diintegrasikan dan diujicoba. 8rinsip yang hampir sama dengan top.down juga dilakukan diujicoba bottom.up, dimulai dari bagian input lalu bagian output sebagai strategi ujicoba keseluruhan. 3ebuah driver dibangun untuk ujicoba modul pada low.le#el. +river sama seperti *t#(s tetapi kebalikannya. +river merupakan modul ujicoba, atau rutin program yang membangkitkan

Ayuliana/&esting dan 'mplementasi/(eb)*++

pemanggilan terhadap modul pada low.le#el dan melemparkan data melalui interface. +river mensimulasikan aksi dari grup yang belum dibangun dari superordinat ke modul yang diujicoba

6euntungan dari pendekatan bottom.up untuk mengujicoba identifikasi lebih dulu alur proses detail yang mungkin terjadi antar interface low.le#el dan melatih lebih dulu kasus input/output. 6ekurangannya adalah pendekatan ini menunda kemampuan untuk menampilkan keseluruhan, kerangka program sampai seluruh modul telah diujicoba dan ditempatkan.3trategi integrasi bottom.up dapat diimplementasikan dengan langkah.langkah berikut : +. Modul low$level dikombinasikan kedalam cl#ster $kadang disebut (#ilds% yang menampilkan subfungsi software khusus ). 3ebuah driver $program kontrol untuk ujicoba% dibuat untuk mengkoordinasikan kasus uji input dan output 0. ,l#ster diujioba 2. +river dihapuskan dan cl#ster dikombinasikan mengarah keatas sesuai dengan struktur program perhatikan gambar berikut : DriverC DriverB DriverA

F E

B F

Possi(le testing pattern for (ottom$#p incremental testing Terdapat ( hal utama $ang membedakan top-do)n dengan bottom up % 1. Architect#re validation, ujicoba top.down mencari kesalahan pada arsitektur sistem dan le#el teratas didesain pada tahap awal proses pembentukan. >iasanya berupa kesalahan struktural, sehingga semakin cepat terdetesi akan mengurangi biaya. 3edangkan ujicoba bottom.up, desain le#el teratas tidak di#alidasi sampai tahapan terakhir diproses. -. *%stem demonstration, dengan ujicoba top.down demonstrasi sistem yang sudah dapat berjalan dapat dilakukan pada awal proses. 3edangkan dengan ujicoba bottom up, demonstrasi sistem dapat dilakukan bila yang dilakukan jika sistem dibangun dari komponen yang digunakan ulang. .. Test implementation, ujicoba topdown sulit untuk diimplementasikan karena simulasi st#(s program lower level dari sistem harus dibuat. 6etika digunakan ujicoba botom.up, harus menuliskan dri#er ujicoba untuk melatih komponen lower level . Ujicoba dri#er ini mensimulasikan komponen lingkungan dan pemanggilan komponen yang akan diujicoba. /. Test o(servation, baik ujicoba top.down maupun bottom.up mempunyai masalah dengan ujicoba obser#asi. 8ada top.down, le#el atas dari sistem yang telah diimplementasikan lebih dulu tidak dapat menghasilkan output, untuk mengujicoba le#el ini maka dibuat agar dapat menghasilkan output. begitu pula kebalikannya untuk pendekatan bottom.up c$ !o &ined Testin# )ethods

&idak ada aturan baku yang menetapkan kapan digunakan ujicoba dengan pendekatan top. down atau bottom.up dilaksanakan. Untuk keefektifan dapat juga dikombinasikan keduanya. 8ada dasarnya semua pendekatan berbasis modul per modul, sehingga penting untuk menemukan perencanaan untuk ujicoba integrasi incremental dari hubungan dan interface yang ada dalam seluruh modul di sistem.

Ayuliana/&esting dan 'mplementasi/(eb)*++

0. *unction Testing Ujicoba fungsi mengaplikasikan teknik (lack$(o0 dalam mencari kesalahan atau kegagalan dalam paket software lengkap. 8ada dasarnya ujicoba fungsi mengikuti ujicoba modul dan ujicoba integrasi. 3angat tidak mungkin menguji seluruh sistem sebelum seluruh modul diujicoba dan dibuat penyesuaian. 6emudian modul harus diintegrasi secara indi#idual atau sekelompok kecil. Aturan khusus pada ujicoba fungsi adalah untuk melatih/mengamati keseluruhan program dengan tujuan untuk memastikan bahwa spesifikasi user eksternal untuk input dan output telah terpenuhi. 6riteria yang diaplikasikan pada ujicoba fungsi meliputi pengukuran atas komponen.komponen seperti:

(ormat input (ormat output 1rganisasi file Akses file 'nterface manusia.komputer

(ungsi program dilakukan untuk memastikan bahwa software beroperasi sesuai desain. "ecord input direpresentasikan untuk ujicoba fungsi yang menyertakan field data yang benar dan tidak. &ermasuk situasi dimana nilai data alphanumerik lebih panjang daripada field yang telah didesain, atau penempatan nilai yang salah seperti nilai data numerik diberikan pada field alphanumerik. 8arameter input dan output diperiksa untuk nilai elemen data yang benar dan salah untuk menetapkan kemampuan program dalam mengatasinya. Kriteria ujicoba +alidasi a. Validasi software diperoleh melalui serangkaian ujicoba black bo= yang mendemonstrasikan kesesuaian dengan permintaan/kebutuhan. b. 3etelah setiap ujicoba fungsi/#alidasi dilakukan, terdapat ) kondisi yang mungkin terjadi : $+.% 6arakteristik fungsi atau performa sesuai dengan spesifikasi dan diterima, atau $). % ditemukannya penyimpangan dari spesifikasi dan menyebabkan defisiensi. ,e+ie) Kon-igurasi ?lemen penting dalam proses #alidasi adalah config#ration review seperti digambarkan dibawah ini. "e#iew konfigurasi ini bertujuan untuk memastikan bahwa seluruh elemen konfigurasi software yang dibangun secara tepat dikatalogkan dan memiliki detail penting untuk dukungan pada fase pemeliharaan dalam software lifec%cle. Ujicoba !lpha dan .eta a. Untuk pengembang software, hampir tidak mungkin mengetahui bagaimana customer menggunakan program. 'nstruksi yang diberikan mungkin akan diinterpretasikan secara salah. b. 6etika penyesuaian software dilakukan untuk seorang customer, maka serangkaian acceptance test harus dilakukan untuk memungkinkan customer mem#alidasi kebutuhannya. c. (ungsi program dilakukan untuk memastikan bahwa software beroperasi sesuai desain. "ecord input direpresentasikan untuk ujicoba fungsi yang menyertakan field data yang benar dan tidak. d. &ermasuk situasi dimana nilai data alphanumerik terlalu lebih panjang daripada field yang telah didesain, atau penempatan nilai yang salah seperti nilai data numerik diberikan pada field alphanumerik. e. 8arameter input dan output diperiksa untuk nilai elemen data yang benar dan salah untuk menetapkan kemampuan program dalam mengatasinya. f. :ika software dibangun sebagai produk yang digunakan oleh beberapa customer, maka akan sangat tidak prakstis untuk melakukan acceptance test formal satu.persatu. g. >iasanya digunakan proses yang disebut alpha and (eta testing, untuk menemukan kesalahan yang hanya bias ditemukan oleh end user. h. 6etika ujicoba alpha dilakukan, maka software dipergunakan sebagaimana mestinya, dengan pengembang software yang tetap mengawasi apa bila terjadi kesalahan. Atau dengan kata lain ujicoba alpha dilakukan dalam lingkungan yang terkontrol. i. Ujicoba beta dilakukan dari sisi end user, baik seorang maupun beberapa orang, dimana pihak pengembang tidak berada bersama para end user tersebut. Atau dengan kata lain, ujicoba beta j. dilakukan dalam lingkungan yang tidak terkontrol oleh pengembang.
Ayuliana/&esting dan 'mplementasi/(eb)*++

&

k. l.

8ara pengguna akhir akan mencatat semua kesalahan yang terjadi dan melaporkannya kepada pihak pengembang dalam inter#al waktu tertentu. -an sebagai hasilnya, pihak pengembang akan melakukan modifikasi dan melakukan persiapan untuk mengeluarkan produknya keseluruh pengguna.

/onfiguration re#iew$8ressman, +@@)% 2. S$stem Testing Mengujicoba keseluruhan sistem dan properti yang ada. Akti#itas ujicoba sistem meliputi ujicoba sistem dan fungsi ujicoba penerimaan. 6etika dilaksanakan ujicoba sistem dan user terlibat didalamnya, maka tidak hanya menguji program tetapi mengujicoba kemampuan keseluruhan sistem. 8rogram dapat berfungsi dengan baik ketika dibandingkan dengan spesifikasi. Ujicoba sistem dilakukan pada program setelah melalui ujicoba unit, integrasi dan fungsi. Ujicoba meliputi e#aluasi kemampuan sistem untuk berfungsi dalam koordinasi.integrasi manual, off.line, mesin dan proses komputer untuk memastikan bahwa seluruh prosedur sudah cocok/sesuai dan dapat digabungkan. 9al lain yang terkait adalah mengujicoba kecukupan/kelayakan referensi manual bagi pengguna untuk memastikan ketepatan dan kecukupannya untuk memandu pengguna melaksanakan operasi hariannya dengan menggunakan sistem yang baru. 3alah satu tujuannya adalah untuk menetapkan seberapa baiknya sistem dapat dioperasikan oleh orang.orang yang tidak terbiasa dengannya. Unit atau fungsi yang diujicoba harus menampilkan semirip mungkin dengan input, proses dan output yang sesungguhnya yang aka diberikan oleh sistem. 8ada titik.titik tertentu dalan ujicoba sistem, komputer harus menangani sejumlah transaksi dan pemrosesan yang melebihi batas spesifikasi. &ujuannya adalah untuk mengetahui seberapa baiknya sistem menangani kelebihan beban. 3elain itu untuk mengujicoba respon dan waktu pengiriman. Untuk sistem on.line, harus terdapat spesifikasi mengenai waktu yang dibutuhkan oleh sistem untuk menerima transaksi, melengkapi proses dan mengembalikan respon ke pengguna. Recover* testin# +. >eberapa system berbasis computer harus me. recover jika terjadi kesalahan dan mengulang proses dengan waktu yang telah ditentukan sebelumnya. ). Ujicoba reco#ery merupakan ujicoba system yang memaksa software menjadi gagal dengan berbagai cara dan mem.#erifikasi apakah reco#ery dilaksanakan secara tepat. 0. :ika reco#ery dilaksanakan secara otomatis, inisialisasi ulang, mekanisme checkpointing, reco#ery data, dan restart die#aluasi untuk perbaikan.
Ayuliana/&esting dan 'mplementasi/(eb)*++

'

2. :ika reco#ery memerlukan inter#ensi manusia, waktu untuk perbaikan die#aluasi untuk memastikan apakah sesuai dengan limit yang ada Stress Testin# +. 3tress test didesain untuk menghadapkan program pada situasi yang abnormal. 3ecara mendasar, seseorang yang melakukan stress testing akan menanyakan : 3eberapa jauh kita dapa menggunakan mesin ini sebelum mereka gagal $9ow high can we crank this up before it fails % ). 3tress testing mengeksekusi system dalam perilaku yang membutuhkan sumberdaya dalam jumlah, frekuensi dan #olume yang abnormal. /ontohnya : &es khusus yang didesain untuk menghasilkan +* interupsi/detik, dimana + atau ) interupsi adalah rata.rata "ange data masukan diperbesar untuk melihat bagaimana fungsi input akan bereaksi 6asus uji yang memerlukan memory maksimum atau sumber daya lain untuk dieksekusi Variasi dari stress testing merupakan teknik yang disebut sensitivit% testing. -alam beberapa situasi $kebanyakan dalan algoritma matematika% sejumlah kecil range dari data yang #alid dalam suatu batasan tertentu dapat menyebabkan proses yang ektrin atau tidak la<im atau penurunan performa. *ensitivit% testing berussaha untuk menemukan kombinasi data dalam class data yang #alid yang dapat menyebabkan ketidakstabilan atau proses yang tidak sesuai +erfor ance testin# +. Untuk sistem realtime atau embedded, software yang menyediakan fungsi yang dibutuhkan tetapi tidak sesuai dengan kebutuhan performanya, maka software tersebut tidak dapat diterima. ). Performance testing didesain untuk menguji performa real time dari softwaredalam konteks integrated s%stem. 0. Performance testing dilakukan dalam setiap tahapan dalam proses ujicoba, walaupun pada tahapan unit/modul sudah terlaksana melalui white bo= testing 2. >iasanya performance Testing dipasangkan dengan stress testing dan membutuhkan instrumen hardware dan software. 4. !cceptance Testing Ujicoba ini merupakan tahapan akhir dalam proses ujicoba sebelum sistem diterima untuk penggunaan operasional. 3istem diujicoba dengan data yang diberikan oleh pengguna $bukan data simulasi% untuk dinilai penerimaan/kelayakannya. Acceptance testing dapat mengungkapkan kesalahan dan penghilangan definisi kebutuhan sistem karena data sesungguhnya akan melatih sistem dengan cara yang berbeda dibandingkan data ujicoba. Acceptance testing juga dapat mengungkapkan masalah.masalah kebutuhan ketika fasilitas sistem tidak sesuai dengan kebutuhan user atau performa sistem tidak seperti yang diharapkan.

R equirements specifica tion

System specification

System de si gn

D etailed de sign

A cceptance te st plan

System inte gration te st plan

Sub-system inte gration te st plan

M odule and unit code and tess

Service

A cceptance te st

System inte gration test

Testing Phases

Sub-system inte gration test

Ayuliana/&esting dan 'mplementasi/(eb)*++

+ro#ra in# and De&u##in# Programming and +e(#gging yaitu proses yang merubah desain kedalam program dan menghilangkan error yang ditimbulkan dari program. Programming merupakan akti#itas personal dan tidak terdapat proses generic programming. 3eorang pemrogram hanya dapat melakukan beberapa ujicoba program untuk mencari kesalahan dan menghilangkan kesalahan ini dalam proses de(#gging.
L o c a t e e r r o r D e s i g n e r r o r r e p a i r R e p a i r e r r o r R e t e s t p r o g r a m

Programming and +e(#gging Process

+e(#gging terjadi sebagai konsekuensi dari keberhasilan ujicoba/testing, yaitu ketika uji kasus berhasil menemukan kesalahan, debugging merupakan proses yang memberi hasil dalam menghilangkan kesalahan.kesalahan tersebut. +e(#gging merupakan hasil dari ujicoba.ujicoba sebelumnya yang akan menempatkan dan memperbaiki kesalahan yang terjadi. 8erhatikan gambar berikut :

+e(#gging

8roses debugging dimulai dari eksekusi uji, hasilnya diperkirakan dan kurangnya keterhubungan antara hasil yang diharapkan dengan hasil yang sesungguhnya akan ditemui. -alam banyak kasus, data yang tidak salin gterhubung merupakan gejala yang merupakan penyebab dasar yang masih tersembunyi 8rose debugging berusaha untuk menyesuaikan gejala dengan sebab yang akan mengarahkan pada perbaikan kesalahan 8roses debugging akan selalu mempunyai salah satu dari ) output yang mungkin : !) 3ebab akan ditemukan, diperbaiki dan dihilangkan ). 3ebab tidak ditemukan. -alam kasus selanjutnya orang yang melaksanakan debugging akan memperkirakan penyebabnya, mendesain kasus uji untuk membantu mem.#alidasi kecurigaannya dan mengerjakan perbaikan secara iterati#e

>eberapa pendekatan untuk membantu identifikasi dan menempatkan kesalahan, termasuk : +. "emor% d#mps, tampilan sederhana yang menampilkan status dari memory pada saat itu, biasanya pada saat kesalahan$error% terdeteksi. "emor% d#mps memungkinkan untuk mencari data tertentu yang diproses secara salah.

Ayuliana/&esting dan 'mplementasi/(eb)*++

). 10ec#tion trace, menyebabkan komputer mencetak catatan dari urutan eksekusi program. 8enelusuran pada umumnya akan mendaftar nama.nama modul yang dieksekusi. 8enelusuran eksekusi disajikan sebagai tool untuk menentukan urutan proses dari suatu program. :ika program digagalkan karena suatu kesalahan, maka akan dapat ditemukan modul terakhir yang dieksekusi dan dititik ini perbaikan akan dilaksanakan. 0. Program desk checking, dilakukan melalui pemeriksaan detail dari so#rce code yang mengakibatkan pengeksekusian logika dalam pikiran pemeriksa. 3eorang programer yang berpengalaman dapat menelusuri logika dan perosesan data dengan me.re#iew so#rce code$nya. 2. 2%pothesis testing, melihat program melalui metode analisis. >erlaku ketika programer mengaplikasikan teknik penanganan dan perbaikan masalah. 6etika satu kesalahan teridentifikasi, analisis dilakukan untuk menentukan jenis kesalahan pemrograman yang mungkin menghasilkan hasil tertentu. 9ipotesis berisikan tentang dimana kemungkinan terjadi kesalahan dalam program dan jenis kesalahan apa yang menyebabkan deteksi kesalahan. ebugging !pproaches &erdapat 0 kategori pendekatan dalam debugging A. >rute force +. Merupakan metode yang paling umum dan efisien untuk mengisolasi kesalahan software. ). Mengaplikasikan metode ini dengan menggunakan filosofi !let the computer find the error! 0. Menggunakan "emor% d#mps, tampilan sederhana yang menampilkan status dari memory pada saat itu, biasanya pada saat kesalahan$error% terdeteksi. "emor% d#mps memungkinkan untuk mencari data tertentu yang diproses secara salah. 2. Aalaupun informasi yang dihasilkan sering sukses, tetapi memerlukan usaha dan waktu yang lebih banyak >. >acktracking +. Merupakan metode debugging yang umum dan dapat digunakan pada program skala kecil ). -imulai dari saat gejala kesalahan terjadi, kode program ditelusuri kebelakang secara manual sampai saat kesalahan ditemukan 0. 10ec#tion trace, menyebabkan komputer mencetak catatan dari urutan eksekusi program. 8enelusuran pada umumnya akan mendaftar nama.nama modul yang dieksekusi. 8enelusuran eksekusi disajikan sebagai tool untuk menentukan urutan proses dari suatu program. :ika program digagalkan karena suatu kesalahan, maka akan dapat ditemukan modul terakhir yang dieksekusi dan dititik ini perbaikan akan dilaksanakan. 2. Program desk checking, dilakukan melalui pemeriksaan detail dari so#rce code yang mengakibatkan pengeksekusian logika dalam pikiran pemeriksa. 3eorang programer yang berpengalaman dapat menelusuri logika dan perosesan data dengan me.re#iew so#rce code$nya. 4. 3ayangnya semakin banyak baris kode yang ditelususi maka proses akan semakin lama. /. /ause elimination +. -ata yang terkait dengan kesalahan diorganisasikan untuk mengisolasi penyebab potensial. ). 2%pothesis testing, melihat program melalui metode analisis. >erlaku ketika programer mengaplikasikan teknik penanganan dan perbaikan masalah. 6etika satu kesalahan teridentifikasi, analisis dilakukan untuk menentukan jenis kesalahan pemrograman yang mungkin menghasilkan hasil tertentu. 9ipotesis berisikan tentang dimana kemungkinan terjadi kesalahan dalam program dan jenis kesalahan apa yang menyebabkan deteksi kesalahan.

Ayuliana/&esting dan 'mplementasi/(eb)*++