TESTING DAN IMPLEMENTASI SISTEM

Materi :

1. SUMBER PERANGKAT LUNAK APLIKASI

2. PENGUJIAN BLACK BOX
3. PENGUJIAN WHITE BOX
4. PENGUJIAN BASIS PATH
5. DASAR-DASAR PENGUJIAN PERANGKAT LUNAK
6. MEMPRODUKSI PERANGKAT LUNAK BERKUALITAS TINGGI
7. KONSEP KUALITAS
8. KUALITAS
1. SUMBER PERANGKAT LUNAK APLIKASI

Pengembangan perangkat lunak (Software development) merupakan salah satu dari tahap
rancangan system rinci/detail dari Siklus Hidup Pengembangan Sistem (Software
Development Life Cycle atau SDLC).

Tim proyek system mungkin mulai mencari paket perangkat lunak komersial yang sesuai atau
mendukung spesifikasi rancangan system dan berjalan pada rancangan arsitektur
komputernya. Paket perangkat lunak komersial secara luas tersedia untuk aplikasi fungsi
spesifik dan aplikasi bisnis yang telah ditetapkan secara baku.

Tetapi untuk rancangan sistem yang terkait dengan kebutuhan khusus atau unik (memenuhi
keperluan pemakai dan spesifikasi rancangan sistem) maka paket perangkat lunak komersial
mungkin tidak sesuai atau mendukung kebutuhan pemakai secara langsung. Perangkat lunak
yang diharapkan untuk mendukung rancangan sistem tersebut harus dibuat sendiri dari awal
(scratch)

1.1.Sumber Perangkat Lunak Aplikasi

1. Perangkat Lunak Komersial dari Vendor

2. Perangkat Lunak Pesanan (customized software) dikembangkan secara in-house atau
oleh kontraktor pemrograman independent

A. Perangkat Lunak Komersial dari Vendor

Paket (off-the-self) yang tersedia bisa diterapkan dalam berbagai kebutuhan bisnis.
Beberapa paket bersifat generik dan multifungsional yang memungkinkan para
pemakai memprogram sofware tersebut untuk kebutuhannya sendiri. Paket-paket
tersebut mengotomisasi fungsi-fungsi bisnis dasar yang umumnya tidak terlalu
bervariasi dari satu organisasi dengan organisasi lain. Contoh jenis paket adalah
spreadsheet dan DBMS.

Keuntungan/kelebihan dari Perangkat Lunak Komersial :

1. Implementasi yang cepat

Software tersebut bersifat siap, teruji, dan terdokumentasi. Paket yang dibeli biasanya
pengimplementasiannya jauh lebih cepat dari pada mengembangkan program yang
sama secara in-house atau menyuruh kontraktor independen untuk
mengembangkannya sehingga secara potensial membantu memecahkan backlog
(penimbunan pekerjaan yang belum selesai).
2. Penghematan Biaya

Satu paket perangkat lunak komersial bisa dijual kepada banyak organisasi sehingga
biaya pengembangan ditanggung oleh banyak pemakai, dan biaya total suatu paket
akan lebih murah dari pada program pesanan yang sama.

3. Estimasi biaya dan waktu

Biaya atau harga paket komersial telah diketahui, dan tanggal pengimplementasian-
nya mudah diestimasi. Sebaliknya program pesanan biasanya cenderung melampaui
estimasi waktu dan biaya.

4. Reliabilitas

Sebelum diterbitkan di pasaran umum, paket perangkat lunak komersial pasti telah
diuji secara teliti. Melalui penggunaan yang ekstensif oleh sejumlah organisasi, segala
kesalahan yang dijumpai telah dideteksi dan dikoreksi sehingga peluang kesalahannya
lebih sedikit.

Kerugian/kelemahan :

1. Kesesuaian Rancangan sistem yang tidak baik

Paket software komersial dibuat untuk berbagai organisasi, dan tidak untuk organisasi
tertentu maka paket ini mungkin mempunyai beberapa fungsi yang tidak diperlukan
atau mungkin tidak mempunyai fungsi yang diperlukan sehingga paket tersebut harus
dimodifikasi. Jika vendor tidak membuat kode sumber (source code) yang bisa
digunakan untuk penyesuaian dan tidak menyediakan layanan penyesuaian maka
rancangan sistem mungkin harus diubah agar sesuai dengan paket tersebut. Jika hal
ini terjadi sebaiknya mengembangkan program secara in-house agar programnya bisa
memenuhi spesifikasi rancangan sistem yang tepat.

2. Ketergantungan Vendor

Jika organisasi memerlukan perubahan paketnya maka organisasi akan tergantung

pada vendor dalam perolehan dukungannya, dan jika vendor telah tiada maka
organisasi akan kesulitan mencari dukungannya.

3. Biaya tidak langsung dari kerusakan SDLC

Seringkali apa yang ingin dicapai, manajemen tidak melaksanakan SDLC menyeluruh
atau mungkin melewati tahap SDLC, dan secara langsung menuju ke paket perangkat
lunak komersial Strategi ini seringkali mengakibatkan paket perangkat lunak
komersial tidak berjalan sesuai yang diharapkan dan masalah sistem serta
organisasional yang terjadi sebelum implementasi paket tersebut tetap muncul
sehingga menimbulkan kesulitan atau harus dibayar kemudian yaitu adanya
peningkatan biaya implementasi, operasi, dan pemeliharaan.

Menyiapkan permohonan untuk proposal berorientasi kinerja

Terkait dengan pemrolehan (akuisisi) perangkat lunak komersial maka perlu membuat
atau menyiapkan Permohonan Proposal (Request For Proposal atau RFP)
berorientasi kinerja untuk menyeleksi vendor dan paket perangkat lunak komersial
yang tepat. Faktor-faktor evaluasi mencakup pemenuhan spesifikasi rancangan
detail untuk output, input, proses, dan database serta cocok dengan batasan waktu
dan biayanya, juga penggunaan benchmark yang mensimulasi kebutuhan sistem baru
(bentuk prototyping) harus diterapkan pada setiap paket dari vendor.

Penilaian paket

Setiap paket dari vendor harus dinilai. Penilaian tersebut meliputi :

a. Sebagian penilaian dari benchmark (tanda untuk menentukan tingginya suatu

nama), dan penilaian lain dari sejumlah publikasi yang didasarkan pada survei dari
sejumlah besar pengguna paket tersebut.

b. Kinerja pengoperasian (operating performance)

Penilaian dari benchmark yang digunakan untuk mengukur hal-hal seperti transaksi
perdetik (transaction per second) dan waktu respon (response time).

c. Dokumentasi

Penilaian ini mencerminkan kuantitas dan kualitas prosedur tertulis, prosedur online,
pedoman quick start, online tutorial, dan fasilitas help.

d. Mudah dipelajari

Penilain ini tergantung pada interface pemakai dan rancangan intuitif dari paket
tersebut. Paket harus bisa dipelajari oleh rata-rata pemakai.

e. Mudah digunakan

Menu yang mudah diikuti dan perintah yang jelas membantu kemudahan penggunaan.

f. Pengendalian dan penanganan kesalahan.

Untuk menjaga kesalahan input, paket software harus menyediakan pencegahan

kesalahan, pendeteksian kesalahan dan perbaikan kesalahan, serta menuliskan
kesalahan ke file kesalahan.
 g. Dukungan (support).

Menyediakan dukungan kebijakan dan teknis. Dukungan kebijakan mencakup jalur

toll-free, garansi, dan pelatihan. Dukungan teknis menyediakan teknisi dan yang
berpengalaman.

2. PENGUJIAN BLACK BOX

Black-box testing adalah metode pengujian perangkat lunak yang tes fungsionalitas dari
aplikasi yang bertentangan dengan struktur internal atau kerja (lihat pengujian white-box).
pengetahuan khusus dari kode aplikasi / struktur internal dan pengetahuan pemrograman pada
umumnya tidak diperlukan. Uji kasus dibangun di sekitar spesifikasi dan persyaratan, yakni,
aplikasi apa yang seharusnya dilakukan. Menggunakan deskripsi eksternal perangkat lunak,
termasuk spesifikasi, persyaratan, dan desain untuk menurunkan uji kasus. Tes ini dapat
menjadi fungsional atau non-fungsional, meskipun biasanya fungsional. Perancang uji
memilih input yang valid dan tidak valid dan menentukan output yang benar.

Tidak ada pengetahuan tentang struktur internal benda uji itu.

Metode uji dapat diterapkan pada semua tingkat pengujian perangkat lunak: unit, integrasi,
fungsional, sistem dan penerimaan.Ini biasanya terdiri dari kebanyakan jika tidak semua
pengujian pada tingkat yang lebih tinggi, tetapi juga bisa mendominasi unit testing juga.
Metode ujicoba blackbox memfokuskan pada keperluan fungsional dari software. Karna itu
ujicoba blackbox memungkinkan pengembang software untuk membuat himpunan kondisi
input yang akan melatih seluruh syarat-syarat fungsional suatu program.

Ujicoba blackbox bukan merupakan alternatif dari ujicoba whitebox, tetapi merupakan
pendekatan yang melengkapi untuk menemukan kesalahan lainnya, selain menggunakan
metode whitebox. Ujicoba blackbox berusaha untuk menemukan kesalahan dalam beberapa
kategori, diantaranya :

1. Fungsi-fungsi yang salah atau hilang.

2. Kesalahan interface.
3. Kesalahan dalam struktur data atau akses database eksternal.
4. Kesalahan performa
5. kesalahan inisialisasi dan terminasi

3. PENGUJIAN WHITE BOX

 Pengujian White Box adalah metode desain test case yang menggunakan struktur control
desain procedural untuk memperoleh test case.
 Disebut juga pengujian glassbox.
 Dengan pengujian whitebox, perekayasa dapat :
1. Memberikan jaminan bahwa semua jalur independen pada suatu modul telah
digunakan paling tidak satu kali.
 2. Menggunakan semua keputusan logis pada sisi true and false.
3. Mengeksekusi semua loop pada nya
4. Menggunakan struktur data internal untuk menjamin validitasnya.

 Condition Testing

Pengujian yang menjalankan kondisi logis yang terdapat pada modul program.

 Data Flow Testing

Pengujian dengan metode yang menyeleksi jalur uji program menurut lokasi
pendefinisian dan menggunakan variable-variabel program

 Loop Testing.

Pengujian yang berfokus pada validitas dari bentuk loop

 simple loop
 concatenated loop
 nested loop
 nstructured loop

4. PENGUJIAN BASIS PATH

 Diperkenalkan oleh Tom McCabe

 Pengujian basis path memungkinkan desain test case mengukur kompleksitas logis dari
desain procedural dan menggunakannya sebagai pedoman untuk menetapkan basis set
dari jalur eksekusi.

 Test case yang dilakukan untuk menggunakan basis set tersebut dijamin untuk
menggunakan setiap statemen di dalam program paling tidak sekali selama pengujian.

 Perangkat yang digunakan :

1. Notasi Flow Graph atau Program Graph .
2. Kompleksitas Siklomatis
Kompleksitas Siklomatis adalah metric perangkat lunak yang memberikan pengukuran
kuantitaif terhadap kompleksitas logis suatu program. Kompleksitas Siklomatis
menentukan jumlah jalur independen dalam basis set suatu program dan memberikan
batas atas bagi jumlah pengujian yang harus dilakukan untuk memastikan bahwa
semua statemen telah dieksekusi sedikitnya satu kali.
3. Graph Metrik
Graph metrik adalah matrik empat persegi yang mempunyai ukuran yang sama dengan
jumlah node pada flowgraph. Masing-masing baris dan kolom mempunyai hubungan
 dengan node yang telah ditentukan dan pemasukan data matrik berhubungan dengan
hubungan (edge) antar node. Contoh sederhana pemakaian graph metrik dapat
digambarkan sebagai berikut :
Melakukan Test Case
1. Dengan menggunakan desain atau kode sebagai dasar, gambarkan sebuah grafik
alir yang sesuai.
2. Tentukan kompleksitas siklomatis dari grafik alir resultan.
3. Tentukan sebuah basis set dari jalur independen secara linier.
4. Siapkan test case yang akan memaksa adanya eksekusi setiap basis set.

5. DASAR-DASAR PENGUJIAN PERANGKAT LUNAK

Pada pengujian perangkat lunak, pelaku RPL menciptakan sekumpulan kasus uji untuk
diujikan kepada perangkat lunak. Proses ini lebih terkesan berusaha untuk “membongkar”
perangkat lunak yang sudah dibangun.

5.1 Sasaran Pengujian Perangkat Lunak

Pengujian adalah proses mengeksekusi program dengan tujuan khusus untuk menemukan
kerusakan. Kasus uji yang baik adalah yang memiliki tingkat kemungkinan tinggi untuk
menemukan kerusakan yang belum ditemukan. Pengujian dikatakan berhasil jika berhasil
menemukan kerusakan yang belum ditemukan

5.2 Prinsip Pengujian

1. Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan.

2. Pengujian harus direncanakan lama sebelum pengujian itu mulai.
3. Pengujian harus mulai “dari yang kecil” dan berkembang menjadi pengujian “yang
besar”.

5.3 Karakteristik Pengujian

Karakteristik yang Membawa Perangkat Lunak Dapat Diuji. Operabilitas, yaitu : Semakin
baik Dia bekerja, semakin efisien Dia dapat diuji.

a) Obsaikervabilitas, yaitu : “Apa yang Anda lihat adalah apa yang Anda uji”.
b) Kontralabilitas, yaitu : “Semakin baik kita dapat mengontrol perangkat lunak, semakin
banyak pengujian yang dapat diotomasisasi dan dioptimalkan”.
c) Dekomposabilitas, yaitu : “Dengan mengontrol ruang lingkup pengujian, kita dapat
dengan lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara
lebih halus”.
d) Kesederhanaan, yaitu : “Semakin sedikit yang kita uji, semakin cepat kita dapat
mengujinya’.
e) Stabilitas, yaitu : “Semakin sedikit perubahan, semakin sedikit pula gangguan dalam
pengujian’.
 f) Kemampuan untuk dapat dipahami, yaitu : “Semakin banyak informasi yang kita
miliki, semakin halus pengujian yang akan dilakukan’.

Atribut-atribut pengujian yang baik :

1. Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan.
2. Pengujian yang baik tidak redudan.
3. Pengujian yang baik seharusnya “jenis terbaik”,
4. Pengujian yang baik tidak boleh terlalu sederhana atau terlalu kompleks.

Tujuan Pengujian :
Menjalankan program untuk menemukan error yang tersembunyi atau yang sebelumnya
tidak terduga.

5.4 Fase Pengujian

Ada 2 tingkat yang tersedia pada proses pegujian, yaitu :

1. Konfigurasi perangkat lunak yang mencakup spesifikasi keperluan perangkat
lunak, spesifikaasi perancangan, test case dan program sumber
2. Konfigurasi uji coba yang mencakup rencana dan prosedur uji coba, test case dan
hasil yang diharapkan.

6. MEMPRODUKSI PERANGKAT LUNAK BERKUALITAS TINGGI

Pendekatan rekayasa perangkat lunak yang digambarkan dalam buku ini bekerja kearah tujuan
tunggal, yaitu, “menghasilkan perangkat lunak berkualitas tinggi”. Masalah manajemen
kualitas bukanlah suatu hal yang tidak diketahui. Masalahnya adalah apa yang mereka pikir
mereka tahu.

Banyak pengembang perangkat lunak terus percaya bahwa kualitas perangkat lunak
merupakan sesuatu yang mulai anda khawatirkan setelah kode-kode dilahirkan. Jaminan
kualitas perangkat lunak atau Software Qualitiy Assurance (SQA) adalah aktivitas pelindung
yang diaplikasikan pada seluruh proses perangkat lunak. SQA meliputi :

1. Pendekatan manajemen kualitas.

2. Teknoligi rekayasa perangkat lunak yang efektif (metode dan peranti).

3. kajian teknik formal yang diaplikasikan pada keseluruhan proses perangkat lunak.

4. strategi pengujian multitiered (deret bertingkat).

5. control dokumentasi perangkat lunak dan dokumentasi yang dibuat.

6. prosedur untuk menjamin keseuaian dengan standar pengembangan.

 7. mekanisme pengukuran dan pelaporan.

7. KONSEP KUALITAS

Telah dikatakan bahwa tidak ada dua butir salju yang sama. Bila kita melihat salju jauh itu sangat
sulit untuk bisa mengatakan bahwa butiran-butiran salju itu berbeda bentuk satu sama lain. Belum
lagi bahwa setiap butir salju memiliki bentuk dan ukuran yang unik. Untuk bisa mengamati
perbedaan diantara dua butir salju, kita harus melakukan pendekatan objek. Dengan menggunakan
alat bantu microscop semakin dekat kita melihat dan semakin besar pula perbedaan yang dapat
kita amati.

Fenomena tersebut adalah sebagian contoh kecil antar-sample, semua bagian yang direkayasa dan
dihasilkan menunjukan keragaman. Keragaman antar-sample tidak akan nyata tanpa bantuan
peralatan yang teliti untuk mengukurnya secara geometri, karakter listrik, atau atribut bagian.

Pemrograman yang menciptakan rutin sorting (atau memilihnya dari sebuah pustaka komponen
reusable) memilih menggunakan quicksort untuk memecahkan masalah yang ada. Dapatkah
seorang pengamat produk akhir membedakan perangkat lunak dari sebuah produk yang sangat
identik yang menggunakan bubble sort ? Mungkin dapat, tetapi kita membutuhkan lebih banyak
informasi dan peralatan yang sangat sensitive untuk dapat membedakan perbedaan antara kedua
sistem tersebut.

Kontrol variasi merupakan inti dari kontrol kualitas. Pemanufaktur ingin meminimalkan variasi
antara produk yang mereka buat, bahkan dalam hal yang kecil sekali pun, seperti ,menduplikasi
disket. Tentu saja ini bukan masalah menduplikasi disket merupakan operasi produksi yang sangat
mudah, dan kita dapat menjamin bahwa duplikat perangkat linak yang tepat selalu dapat dibuat.

Bagai mana organisasi pengembang perfangkat lunak melakukan control variasi? Dari satu proyek
ke proyek lain kita perlumeminimalkan perbedaan di antara sumber-sumber daya yang diharapkan
menyelesaikan proyek dansumber daya actual yang digunakan. Secara umum kita perlu
memastikan bahwa program pengujian kita sudah mencangkup presentase perangkat lunak yang
diketahui dari satu peluncuran ke peluncuran lain. Kita tidak hanya perlu meminimalkan jumlah
cacat yang dilepas ke medan, tetapi kita juga harus memastikan bahwa varian dalam jumlah bug
juga telah diminimalkan dari satu pelapasan ke pelepasan lain.

8. KUALITAS

Kualitas sebagai sebuah karakteriktis atau atribut dari sesuatu. Sebagai atribut dari sesuatu,
kualitas mengacu pada karakteristik yang dapat diukur.

Dapat dibagi menjadi dua jenis yang mencangkup dengan kualitas:

1. kualitas design, mengacu pada karakteristik yang ditentukan oleh designer terhadap suatu
item tertentu
2. kualitas konformasi, adalah tingkat dimana spesifikasi design terus diikuti selama
pembuatan. semakin tinggi tingkat konformasi, semakin tinggi juga kualitas konformasi.

Dalam pengembangan perangkat lunak, kualitas design syarat, spesifikasi, dan desain sistem.
Kualitas konformasi adalah suatu masalah yang difokuskan pada implementasi. Bila
implimentasi mengikuti desain dan sistem yang dihasilkan memenuhi persyaratan serta tujuan
kinerja, maka kualitas konformasi menjadi tinggi.

8.1 Kontrol Kualitas

Aktivitas kualitas kontrol dapat menjadi otomatis sepenuhnya atau manual secara
keseluruhan, atau bisa dikombinasi antar keduanya. Konsep kunci kualitas kontrol adalah
bahwa semua produk kerja memiliki spesifikasi yang telah ditentukan dan dapat diukur
dimana kita dapat membandingkan output dari setiap proses. Kadang menjadi penting
untuk meminimalkan cacat yang dihasilkan.

8.2 Jaminan Kualitas

Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen. Tujuan jaminan
kualitas adalah untuk memberikan data yang diperlukan manajemen dalam
menginformasikan masalah kualitas produk.

8.3 Biaya Kualitas

Biaya kualitas menyangkut semua biaya yang diadakan untuk mengejar kualitas atau untuk
menampilkan kualitas yang berhubungan dengan aktivitas. Biaya kualitas dapat dibagi
kedalam biaya-biaya yang dihubungkan dengan pencegahan, penilaian, dan kegagalan.

Biaya pencegahan meliputi :

1. perencanaan kualitas

2. kajian teknis formal

3. perlengkapan pengujian, dan pelatihan.

Menyiapkan rencana suatu SQA untuk suatu proyek, rencana itu dikembangkan selama
perancangan proyek dan dikaji oleh semua kelompok yang tertarik. Aktivitas yang
dilakukan oleh tim rekayasa perangkat lunak dan kelompok SQA diatur oleh rencana.
Rencana tersebut mengidentifikasi hal hal berikut :
1. evaluasi yang dilakukan

2. audit dan kajian yang dilakukan.

3. standar yang dapat diaplikasikan oleh proyek

4. prosedur untuk pelaporan dan penelusuran kesalahan

5. dokumen yang dihasilkan oleh sekelompok SQA

6. jumlah umpan balik yang diberikan pada tim proyek perangkat lunak.