Software validation

Software validation
Validasi software atau sering disebut verification and Validation, bertujuan untuk menunjukkan bahwa
sistem telah sesuai dengan spesifikasinya dan 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.
The testing process
Relationship between system development and testing activities
(Adams, Powers, Owles, 1985)
Tahapan-Tahapan Ujicoba
1. Unit Testing
Unit testing dilaksanakan untuk mengetahui kesalahan dalam logika atau fungsi setiap komponen
(individual component).
2. Module Testing
Module Testing diujikan pada komponen-komponen yang saling terhubung dan saling bergantung satu
dengan yang lainnya. Tipe-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.
• Contoh yang paling umum menyertakan pemindahan kontrol proses dari modul ke subrutin atau
subprogram.
• Objek dari ujicoba adalah untuk menentukan bahwa argumen yang dilemparkan ke subrutin
sesuai dengan parameter yang diterima.
• 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.
• Sebagai tambahan, kesalahan juga terlihat pada format record, organisasi file, dan penggunaan
kunci. Idenya adalah untuk memastikan bahwa kunci yang digunakan sesuai dengan record dan
file yang disusun dan direferensikan sesuai dengan kunci.
• 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 null atau empty.
• Dengan akses langsung pada file, ujicoba diaplikasikan untuk kesalahan yang terjasi jika record
yang sesuai dengan kunci ditemukan, atau tidak.
• Kegunaan ujicoba kesalahan input-output yang paling akhir adalah menemukan kesalahan
output sistem, dimana prosedur ujicobanya adalah menghasilkan atau menampilkan output
yang seharusnya.
• Output 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 Data (Data structure errors)
• Ujicoba ini mencari kesalahan dalam penanganan atau pembentukan elemen data yang
didefinisikan dan dibangun dalam modul proses.
• Contoh dapat menyertakan tabel-tabel atau record sementara yang digunakan untuk
pemindahan data. Ujicoba diaplikasikan untuk perbaikan format dan atribut.
• Ujicoba lainnya dapat berkenaan dengan definisi tabel, termasuk prosedur-prosedur utama dan
ukuran tabel.
• Pemerikasaan lainnya dilakukan untuk konsistensi pemakaian nama, untuk penginisialisasian
counter dan akumulator dan untuk melengkapi spesifikasi data item.
d. Kesalahan Aritmatika (Arithmetic errors)
• Hasil 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. (Jika ditemukan dibagi dengan Nol, maka program
harus dapat menangani kondisi ini)
e. Kesalahan Perbandingan (Comparison errors)
• Ujicoba ini mencari kesalahan yang meliputi presentasi data item yang berbeda tipe atau
bentuknya untuk fungsi-fungsi perbandingan.
• Tujuannya adalah untuk memastikan bahwa program atau modul tidak akan mengizinkan
operasi perbandingan antara field alphabetik dengan field numerik atau antara field numerik
dengan bentuk yang berbeda.
• Sama seperti fungsi ujicoba kesalahan lainnya, idenya adalah untuk menyajikan kondisi-kondisi
seperti tersebut ke sistem dan memastikan bahwa sistem dapat menangani dan me-recovernya.
• Ujicoba akan menjadi sulit untuk menetapkan fungsi-fungsi seperti operasi perbandingan jamak
bersarang (multiple nested comparison) ditambilkan dengan perintah tertentu.
f. Kesalahan Logika Kendali proses (Control Logic errors)
• Computer merupakan mesin sekuensial. Karena itu tidak diperlukan ujicoba khusus untuk fungsi
kontrol sekuensial. Tetapi 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.
Juga terhadap seluruh titik percabangan dalam fungsi pemilihan diberi label yang tepat dan
memiliki titik exit untuk semua jalur terbuka
• Untuk struktur kontrol pengulangan, ujicoba diaplikasikan untuk memastikan bahwa index
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 hung-up.
Prinsip pengaplikasian ujicoba pada modul yaitu :
• 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
3. Sub System Testing (Integration Testing)
Integrasi 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. Terdapat dua pendekatan yang dapat dilaksanakan :
a. Incremental testing, modul dapat ditambahkan pada modul lainnya untuk ujicoba individual,
biasanya berupa penulisan modul baru.
b. Nonincremental 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.
Terdapat dua metode untuk mengaplikasikan Incremental testing, yaitu :
a. Top-down testing
 Diaplikasikan pada modul berbasis top-down/mengarah ke bawah berdasarkan kontrol hirarki.,
atau diproses dari modul level atas diturunkan sampai modul detail.
 Komponen-komponen high level dari sistem diintegrasikan dan diujicoba sebelum rancangan
dan implementasinya lengkap.
 Penggabungan modul subordinate dengan modul utama dapat dilakukan dengan struktur depthfirst
atau breadth-first.
 Integrasi depth-first akan mengintegrasikan modul dijalur utama, misal dari gambar dibawah A,
B, E akan diintegrasikan lebih dulu, kemudian mengarah ke jalur tengah dan kanan
 Integrasi breadth-first akan mengintegrasikan secara langsung seluruh modul subordinate,
misal B, C, D (stub D) akan diintegrasikan lebih dulu baru level dibawahnya
 Proses integrasi dilakukan dalam 5 tahapan :
1. Modul kontrol utama digunakan sebagai test driver dan stub disubtitusikan untuk seluruh
modul yang secara langsung merupakan subordinate dari modul kontrol utama
2. Berdasarkan dari pendekatan integrasi yang dipilih, stub subordinat digantikan dengan modul
yang sesungguhnya pada saat yang bersamaan.
3. Ujicoba dilaksanakan pada setiap modul yangtelah diintegrasikan
4. Pada setiap akhir dari serangkaian ujicoba, stub lainnya digantikan dengan modul yang
sesungguhnya
5. Regression testing, (melaksanakan sebagian atau seluruhnya ujicoba sebelumnya) dapat
dilaksanakan untuk memastikan apakah terdapat kesalahan baru.
 Proses akan berulang mulai dari langkah ke-2 sampai seluruh struktur program terbangun.
 Keterhubungan dibuat dari modul teratas ke modul dilevel 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.
 Rutin ujicoba seperti ini disebut program Stubs. Rutin ini mensimulasikan proses yang akan
dijalankan ketika modul dikodekan.
 Selama ujicoba, stubs menyediakan target untuk pemanggilan subprogram sehingga modul
superordinat dapat melatih fungsi kontrol mereka. Stubs juga dapat melemparkan data ke
superordinat untuk menguji interface.
 Ujicoba dengan pendekatan top-down memberikan verifikasi awal dari interface utama dan juga
keseluruhan logika kontrol, yang harus berasal dari tingkat teratas struktur program.
 Karena dimulai dari level atas kebawah, maka menjadi sangat mungkin untuk
mendemonstrasikan fungsi program secara lengkap dan keseluruhan pada titik awal dari
prosedur ujicoba.
 Perhatikan gambar berikut :
Structure chart for program to be tested incrementally
b. Bottom-Up
 Ujicoba dimulai dari level terendah dari struktur program dan bergerak keatas sebagai sebuah
modul yang diintegrasikan dan diujicoba.
 Prinsip yang hampir sama dengan top-down juga dilakukan diujicoba bottom-up, dimulai dari
bagian input lalu bagian output sebagai strategi ujicoba keseluruhan.
 Sebuah driver dibangun untuk ujicoba modul pada low-level. Driver sama seperti Stubs tetapi
kebalikannya. Driver merupakan modul ujicoba, atau rutin program yang membangkitkan
pemanggilan terhadap modul pada low-level dan melemparkan data melalui interface.
 Driver mensimulasikan aksi dari grup yang belum dibangun dari superordinat ke modul yang
diujicoba
 Keuntungan dari pendekatan bottom-up untuk mengujicoba identifikasi lebih dulu alur proses
detail yang mungkin terjadi antar interface low-level dan melatih lebih dulu kasus input/output.
 Kekurangannya adalah pendekatan ini menunda kemampuan untuk menampilkan keseluruhan,
kerangka program sampai seluruh modul telah diujicoba dan ditempatkan.
 Strategi integrasi bottom-up dapat diimplementasikan dengan langkah-langkah berikut :
1. Modul low-level dikombinasikan kedalam cluster (kadang disebut builds) yang
menampilkan subfungsi software khusus
2. Sebuah driver (program kontrol untuk ujicoba) dibuat untuk mengkoordinasikan kasus uji
input dan output
3. Cluster diujioba
4. Driver dihapuskan dan cluster dikombinasikan mengarah keatas sesuai dengan struktur
program
 perhatikan gambar berikut :
Possible testing pattern for bottom-up incremental testing
Terdapat 4 hal utama yang membedakan top-down dengan bottom up :
1. Architecture validation, ujicoba top-down mencari kesalahan pada arsitektur sistem dan level
teratas didesain pada tahap awal proses pembentukan. Biasanya berupa kesalahan struktural,
sehingga semakin cepat terdetesi akan mengurangi biaya. Sedangkan ujicoba bottom-up,
desain level teratas tidak divalidasi sampai tahapan terakhir diproses.
2. System demonstration, dengan ujicoba top-down demonstrasi sistem yang sudah dapat berjalan
dapat dilakukan pada awal proses. Sedangkan dengan ujicoba bottom up, demonstrasi sistem
dapat dilakukan bila yang dilakukan jika sistem dibangun dari komponen yang digunakan ulang.
3. Test implementation, ujicoba topdown sulit untuk diimplementasikan karena simulasi stubs
program lower level dari sistem harus dibuat. Ketika digunakan ujicoba botom-up, harus
menuliskan driver ujicoba untuk melatih komponen lower level . Ujicoba driver ini
mensimulasikan komponen lingkungan dan pemanggilan komponen yang akan diujicoba.
4. Test observation, baik ujicoba top-down maupun bottom-up mempunyai masalah dengan
ujicoba observasi. Pada top-down, level atas dari sistem yang telah diimplementasikan lebih
dulu tidak dapat menghasilkan output, untuk mengujicoba level ini maka dibuat agar dapat
menghasilkan output. begitu pula kebalikannya untuk pendekatan bottom-up
c. Combined Testing Methods
 Tidak ada aturan baku yang menetapkan kapan digunakan ujicoba dengan pendekatan topdown
atau bottom-up dilaksanakan. Untuk keefektifan dapat juga dikombinasikan keduanya.
 Pada 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.
4. Function Testing
Ujicoba fungsi mengaplikasikan teknik black-box dalam mencari kesalahan atau kegagalan dalam
paket software lengkap. Pada dasarnya ujicoba fungsi mengikuti ujicoba modul dan ujicoba integrasi.
Sangat tidak mungkin menguji seluruh sistem sebelum seluruh modul diujicoba dan dibuat penyesuaian.
Kemudian modul harus diintegrasi secara individual 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.
Kriteria yang diaplikasikan pada ujicoba fungsi meliputi pengukuran atas komponen-komponen
seperti :
 Format input
 Format output
 Organisasi file
 Akses file
 Interface manusia-komputer
Fungsi program dilakukan untuk memastikan bahwa software beroperasi sesuai desain. Record
input direpresentasikan untuk ujicoba fungsi yang menyertakan field data yang benar dan tidak.
Termasuk 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. Parameter
input dan output diperiksa untuk nilai elemen data yang benar dan salah untuk menetapkan
kemampuan program dalam mengatasinya.

Kriteria ujicoba validasi
a. Validasi software diperoleh melalui serangkaian ujicoba black box yang mendemonstrasikan
kesesuaian dengan permintaan/kebutuhan.
b. Setelah setiap ujicoba fungsi/validasi dilakukan, terdapat 2 kondisi yang mungkin terjadi : (1.)
Karakteristik fungsi atau performa sesuai dengan spesifikasi dan diterima, atau (2. ) ditemukannya
penyimpangan dari spesifikasi dan menyebabkan defisiensi.
Review Konfigurasi
Elemen penting dalam proses validasi adalah configuration review seperti digambarkan dibawah ini.
Review 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 lifecycle.
Ujicoba Alpha dan Beta
a. Untuk pengembang software, hampir tidak mungkin mengetahui bagaimana customer
menggunakan program. Instruksi yang diberikan mungkin akan diinterpretasikan secara salah.
b. Ketika penyesuaian software dilakukan untuk seorang customer, maka serangkaian acceptance test
harus dilakukan untuk memungkinkan customer memvalidasi kebutuhannya.
c. Fungsi program dilakukan untuk memastikan bahwa software beroperasi sesuai desain. Record
input direpresentasikan untuk ujicoba fungsi yang menyertakan field data yang benar dan tidak.
d. Termasuk 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. Parameter input dan output diperiksa untuk nilai elemen data yang benar dan salah untuk
menetapkan kemampuan program dalam mengatasinya.
f. Jika software dibangun sebagai produk yang digunakan oleh beberapa customer, maka akan
sangat tidak prakstis untuk melakukan acceptance test formal satu-persatu.
g. Biasanya digunakan proses yang disebut alpha and beta testing, untuk menemukan kesalahan yang
hanya bias ditemukan oleh end user.
h. Ketika 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
dilakukan dalam lingkungan yang tidak terkontrol oleh pengembang.
j. Para pengguna akhir akan mencatat semua kesalahan yang terjadi dan melaporkannya kepada
pihak pengembang dalam interval waktu tertentu.
k. Dan sebagai hasilnya, pihak pengembang akan melakukan modifikasi dan melakukan persiapan
untuk mengeluarkan produknya keseluruh pengguna.
5. System Testing
Mengujicoba keseluruhan sistem dan properti yang ada. Aktivitas ujicoba sistem meliputi ujicoba
sistem dan fungsi ujicoba penerimaan. Ketika dilaksanakan ujicoba sistem dan user terlibat didalamnya,
maka tidak hanya menguji program tetapi mengujicoba kemampuan keseluruhan sistem. Program dapat
berfungsi dengan baik ketika dibandingkan dengan spesifikasi. Ujicoba sistem dilakukan pada program
setelah melalui ujicoba unit, integrasi dan fungsi. Ujicoba meliputi evaluasi 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.
Hal 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. Salah 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. Pada titik-titik tertentu dalan ujicoba sistem,
komputer harus menangani sejumlah transaksi dan pemrosesan yang melebihi batas spesifikasi.
Tujuannya adalah untuk mengetahui seberapa baiknya sistem menangani kelebihan beban.
Selain 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.

Recovery testing
• Beberapa system berbasis computer harus me-recover jika terjadi kesalahan dan mengulang
proses dengan waktu yang telah ditentukan sebelumnya.
• Ujicoba recovery merupakan ujicoba system yang memaksa software menjadi gagal dengan
berbagai cara dan mem-verifikasi apakah recovery dilaksanakan secara tepat.
• Jika recovery dilaksanakan secara otomatis, inisialisasi ulang, mekanisme checkpointing, recovery
data, dan restart dievaluasi untuk perbaikan.
• Jika recovery memerlukan intervensi manusia, waktu untuk perbaikan dievaluasi untuk memastikan
apakah sesuai dengan limit yang ada

Stress Testing
• Stress test didesain untuk menghadapkan program pada situasi yang abnormal. Secara mendasar,
seseorang yang melakukan stress testing akan menanyakan : Seberapa jauh kita dapa
menggunakan mesin ini sebelum mereka gagal ? (How high can we crank this up before it fails??)
• Stress testing mengeksekusi system dalam perilaku yang membutuhkan sumberdaya dalam jumlah,
frekuensi dan volume yang abnormal. Contohnya :
• Tes khusus yang didesain untuk menghasilkan 10 interupsi/detik, dimana 1 atau 2 interupsi adalah
rata-rata
• Range data masukan diperbesar untuk melihat bagaimana fungsi input akan bereaksi
• Kasus uji yang memerlukan memory maksimum atau sumber daya lain untuk dieksekusi
• Variasi dari stress testing merupakan teknik yang disebut sensitivity testing. Dalam beberapa
situasi (kebanyakan dalan algoritma matematika) sejumlah kecil range dari data yang valid dalam
suatu batasan tertentu dapat menyebabkan proses yang ektrin atau tidak lazim atau penurunan
performa.
• Sensitivity testing berussaha untuk menemukan kombinasi data dalam class data yang valid yang
dapat menyebabkan ketidakstabilan atau proses yang tidak sesuai

Performance testing
• 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 system.
• Performance testing dilakukan dalam setiap tahapan dalam proses ujicoba, walaupun pada tahapan
unit/modul sudah terlaksana melalui white box testing
• Biasanya performance Testing dipasangkan dengan stress testing dan membutuhkan instrumen
hardware dan software.
6. Acceptance Testing
Ujicoba ini merupakan tahapan akhir dalam proses ujicoba sebelum sistem diterima untuk
penggunaan operasional. Sistem diujicoba dengan data yang diberikan oleh pengguna data dari pada
menggunakan 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.
Testing Phases

Software Evolution
Pada dasarnya software bersifat flexible dan dapat dirubah, seiring dengan perubahan kebutuhan dan
perubahan kondisi bisnis. Dengan pengembangan dan pemeliharaan yang terus meningkat, maka hanya
akan terdapat sedikit sistem yang benar-benar baru.