MAKALAH

PENGUJIAN PENJAMINAN MUTU PERANGKAT LUNAK

Disusun Oleh :

1. Diah Afrianti 120155201034

2. Lydia Wati 120155201041
3. Ahmad Hafizh 120155201042
4. Novricky Wahyudi 120155201058
5. Bondan Chorisma 120155201062

Teknik Informatika

Fakultas Teknik

Universitas Maritim Raja Ali Haji

2016
 PEMBAGIAN TUGAS FIREWALL

Posisi Nama Tugas

Ketua Novricky Wahyudi

Wakil Ketua Ahmad Hafizh

Anggota 1 Bondan Chorisma

Anggota 2 Diah Afrianti

Anggota 3 Lydia Wati

i
 DAFTAR ISI

PEMBAGIAN TUGAS FIREWALL.......................................................................i

DAFTAR ISI............................................................................................................ii
1. Pengertian Pengujian Perangkat Lunak............................................................1
2. Tujuan Pengujian Perangkat Lunak..................................................................2
3. Tipe Pengujian..................................................................................................3
4. Prinsip-prinsip Pengujian................................................................................16
5. Kegagalan dan Kesalahan...............................................................................18
6. Testability (Kemampuan Test).......................................................................20
DAFTAR PUSTAKA............................................................................................23

ii
1. Pengertian Pengujian Perangkat Lunak

Berikut ini definisi pengujian perangkat lunak menurut para ahli,

diantaranya:

1. Menurut Myers (1979)

Proses menjalankan program dengan maksud menemukan kesalahan.
2. Menurut IEEE (1990)
 Proses sistem operasi atau komponen menurut kondisi tertentu,
pengamatan atau pencatatan hasil dan mengevaluasi beberapa aspek
sistem atau komponen.
 Proses analisis item perangkat lunak untuk mendeteksi perbedaan
antara kondisi yang ada dengan yang diinginkan dan mengevaluasi
fitur item perangkat lunak.
3. Menurut Galin (2004)
Proses formal yang ditentukan oleh tim pengujian yang meliputi unit
perangkat lunak, beberapa unit perangkat lunak terintegrasi atau seluruh
package perungkat lunak yang ditentukan oleh program yang berjalan di
komputer. Seluruh tes saling terkait dan adanya prosedur pengujian dan
kasus pengujian.
Dapat disimpulkan bahwa pengujian perangkat lunak adalah proses
menjalankan sebuah program dengan maksud menemukan kesalahan-kesalahan
(error). Serta proses untuk menjalankan sebuah program komputer dan
membandingkan tingkah laku yang sesungguhnya dengan yang diharapkan
sehinga bisa menghasilkan produk yang berkualitas.Yang dimaksud
membandingkan adalah menemukan bentuk penyimpangan-penyimpangan (jika
ada).
Pengujian perangkat lunak adalah salah satu elemen yang penting dari
jaminan kualitas perangkat lunak dan merespresentasikan kajian pokok dari
spesifikasi, desain dan pengkodean. Meningkatnya visibilitas perangkat lunak
sebagai suatu elemen sistem dan “biaya” yang muncul akibat kegagalan perangkat

1
lunak, memotivasi dilakukannya perencanaan yang baik melalui pengujian yang
teliti. Pengujian  termasuk dalam  teknik verifikasi dan validasi (V & V).
Pengujian melibatkan pelatihan perangkat lunak dengan memakai data seperti data
riil yang diolah oleh perangkat lunak. Tujuan akhir dari proses verifikasi dan
validasi adalah menanamkan kepercayaan bahwa sistem perangkat lunak “siap
untuk tujuannya”.
Pada saat V & V perangkat lunak, kesalahan pada perangkat lunak
biasanya ditemukan dan kemudian diubah untuk membetulkan kesalahan tersebut.
Proses debug ini seringkali terintegrasi dengan kegiatan verifikasi dan validasi
lain.  Bagaimanapun, pengujian (atau lebih umum verifikasi dan validasi) dan
debug merupakan proses yang berbeda yang tidak harus diintegrasikan (Ridwan,
2013):
1. Verifikasi dan Validasi adalah proses yang meyakinkan  adanya kesalahan
pada sistem perangkat lunak.
2. Debug merupakan proses yang menemukan dan membetulkan  kesalahan
tersebut.

2. Tujuan Pengujian Perangkat Lunak

Tujuan pengujian Perangkat Lunak :

• Menilai apakah perangkat lunak yang dikembangkan telah
memenuhi kebutuhan pemakai
• Menilai apakah tahap pengembangan perangkat lunak telah sesuai
dengan metodologi yang digunakan
• Membuat dokumentasi hasil pengujian yang menginformasikan
kesesuaian perangkat lunak yang diuji dengan spesifikasi yang
telah ditentukan

Melihat tujuan dari pengujian perangkat lunak, maka dapat

dijabarkan hal-hal yang harus dilakukan ketika melakukan pengujian,
yaitu:

2
 • Mengidentifikasikan dan menemukan beberapa kesalahan yang
mungkin ada dalam Perangkat Lunak yang diuji
• Setelah Perangkat Lunak dibetulkan, diidentifikasi ulang kesalahan
dan dites ulang untuk menjamin kualitas level penerimaan
• Membentuk tes yang efisien dan efektif dengan anggaran dan
jadwal yang terbatas.
• Mengumpulkan daftar kesalahan untuk digunakan dalam daftar
pencegahan kesalahan (tindakan corrective dan preventive).

3. Tipe Pengujian

1. Pengujian cacat (Defect Testing)

Tipe pengujian ini digunakan untuk menetapkan keberadaan cacat

sistem. Tujuannya untuk menemukan ketidak konsistenan antara program
dan spesifikasinya. Pengujian tipe ini dirancang untuk mengungkapkan
adanya cacat pada sistem dan bukan untuk mensimulasi penggunaan
operasionalnya. Serta bermanfaat bagi pemrogram dan menunjukkan
cacat-cacat yang ada di kode (program).
Model umum dari pengujian ini ditunjukkan pada gambar berikut :

Gambar 1. Proses Pengujian Cacat

Kasus uji merupakan spesifikasi input untuk menguji dan output

yang diharapkan dari sistem dan ditambah dengan pernyataan apa yang
sedang diuji. Data uji merupakan input yang telah disesuaikan untuk

3
menguji sistem. Data uji kadang – kadang dibangkitkan secara otomatis.
Pembangkitan kasus uji otomatis tidak mungkin dilakukan karena output
uji tidak dapat diramalkan.

Dalam melakukan pengujian cacat memiliki banyak metode

pengujian, akan tetapi metode yang sering digunakan dalam pengujian
cacat adalah black box dan white box testing (metode struktural).

a. Pengujian Black Box

Pengujian fungsional atau kotak hitam (Black-box testing)
merupakan pendekatan pengujian yang ujinya diturunkan dari
spesifikasi program atau komponen. Sistem merupakan ‘kotak hitam’
yang perilakunya hanya dapat ditentukan dengan mempelajari input
dan output yang berkaitan. Nama lain untuk cara ini adalah pengujian
fungsional karena penguji hanya berkepentingan dengan fungsionalitas
dan bukan implementasi perangkat lunak (Sommerville, 2003).

Pengujian black box adalah pengujian aspek fundamental

sistem tanpa memperhatikan struktur logika internal perangkat lunak.
Metode ini digunakan untuk mengetahui apakah perangkat lunak
berfungsi dengan benar. Pengujian black box merupakan metode
perancangan data uji yang didasarkan pada spesifikasi perangkat lunak.
Data uji dibangkitkan, dieksekusi pada perangkat lunak dan kemudian
keluaran dari perangkat lunak dicek apakah telah sesuai dengan yang
diharapkan.

Pada gambar dibawah ini mengilustrasikan model sistem yang

diasumsikan pada pengujian kotak hitam. Pendekatan ini dapat
diterapkan pula pada sistem yang disusun sebagai fungsi atau sebagai
objek. Penguji memberikan input kepada komponen atau sistem dan
meneliti output yang dihasilkan. Jika output bukan merupakan yang
diramalkan, berarti uji tersebut telah dengan berhasil mendeteksi
masalah dengan perangkat lunak tersebut.

4
 Input data uji

Sistem

Output hasil uji

Gambar 2. Pengujian Kotak Hitam

Keterangan :
Ie : Input yang menyebabkan perilaku menyimpang
Oe : Output yang mengungkapkan adanya cacat

Ciri-ciri Black Box Testing, (Shihab, 2014) :

 Black box testing berfokus pada kebutuhan fungsional pada
software, berdasarkan pada spesifikasi kebutuhan dari
software.
 Black box testing bukan teknik alternatif daripada white box
testing. Lebih daripada itu, ia merupakan pendekatan
pelengkap dalam mencakup error dengan kelas yang berbeda
dari metode white box testing.

5
  Black box testing melakukan pengujian tanpa pengetahuan
detil struktur internal dari sistem atau komponen yang dites.

Black Box dapat menemukan kesalahan dalam kategori berikut

(Rouf, 2012) :

1. Fungsi-fungsi yang tidak benar atau hilang

2. Kesalahan interface
3. Kesalahan dalam struktur data atau akses basisdata eksternal
4. Inisialisasi dan kesalahan terminasi
5. validitas fungsional
6. kesensitifan sistem terhadap nilai input tertentu
7. batasan dari suatu data

Sasaran Utama Desain Test Case Black Box (Ridwan, 2013) :

1. Didesain untuk mengungkap kesalahan pada persyaratan

fungsional tanpa mengabaikan kerja internal dari suatu program.
2. Berfokus pada domain informasi dari perangkat lunak.
3. Melakukan teste case dengan mempartisi domain input dan
output dari suatu program dengan cara yang memberikan cakupan
pengujian yang mendalam.
4. Partisi ekivalensi (Equivalence Class Partitioning) membagi
domain input kedalam kelas data yang mungkin untuk melakukan
fungsi perangkat lunak tertentu.
5. Analisis nilai terbatas (Boundary Value Analysis) memeriksa
kemampuan program untuk menangani data pada patas yang
dapat diterima.
6. Pengujian perbandingan (Comparison Testing) mengembangkan
perangkat lunak ke dalam versi-versi yang independen dari suatu
aplikasi dengan menggunakan spesifikasi yang sama. Setiap versi

6
 diuji dengan data uji yang sama untuk memastikan bahwa semua
versi memberikan output yang identik. Disebut juga pengujian
back to back.

Kelebihan black box testing (Irwan, 2013):

1. Spesifikasi program dapat ditentukan di awal

2. Dapat digunakan untuk menilai konsistensi program
3. Testing dilakukan berdasarkan spesifikasi

Kekurangan black box testing adalah apabila spesifikasi

program yang dibuat kurang jelas dan ringkas, maka akan sulit
membuat dokumentasi setepat mungkin. (Irwan, 2013). Metode-
metode dalam black box testing :

1. Graf Based Testing

Langkah pertama pada pengujian black box adalah memahami

objek yang terdapat dalam model perangkat lunak dan menentukan
hubungan yang dimiliki antara objek-objek tersebut. Pengujian
berbasiskan model graf dilakukan terhadap perilaku sistem. Langkah
selanjutnya menentukan sederetan pengujian yang membuktikan
bahwa semua objek memiliki hubungan antara satu dengan lainnya.

Dibwah ini contoh representasi simbolik dari grafik :

7
 Gambar 3. representasi simbolik dari grafik

Keterangan :

Simpul, merepresentasikan objek.

Link, merepresentasikan hubungan antar objek.

Beban simpul (node weight), menggambarkan

x property dari suatu simpul.

x Beban link (link weight), menggambarkan

karakterisktik suatu link.

Link paralel, menggambarkan hubungan yang

berbeda yang dibangun antar node
Link simetris, menggambarkan hubungan dua arah
antar dua objek

Contoh grafik pengolah kata

New Menu select Document

file membangkit
Waktu window
pembangkita
Membolehkan
editing
Dihadirkan berisi
sebagai
Document
text

Gambar 4. Contoh grafik

8
2. Equivalence Partitioning (Partisi ekuivalensi)

Partisi ekuivalensi adalah metode yang membagi domain

input dari suatu program ke dalam kelas data, menentukan kasus
pengujian dengan mengungkapkan kelas-kelas kesalahan, sehingga
akan mengurangi jumlah keseluruhan kasus pengujian. Bila suatu link
weight mempunyai pola transitivitas, simetris, dan refleksif maka
akan terdapat kelas ekuivalensi. Kelas ekuivalensi merepresentasikan
serangkaian kondisi valid dan invalid untuk kondisi inputan. Secara
khusus, suatu kondisi input dapat berupa harga numeric, suatu
rentang harga, serangkaian harga yang terkait, atau suatu kondisi
Boolean. Penentuan Kelas Ekuivalensi

1. Bila kondisi input menentukan suatu range, maka satu

kelas ekuvalensi valid dan dua yang invalid ditentukan
2. Bila suatu kondisi input memerlukan suatu harga khusus,
maka satu kelas ekuivalensi valid dan dua yang invalid
ditentukan
3. Bila suatu kondisi menentukan anggota suatu himpunan,
maka satu kelas ekuivalensi valid atau dua yang invalid
ditentukan
4. Bila suatu kondisi input adalah Boolean, maka satu kelas
valid dan satu yang lain ditentukan.

3. Comparison Testing

Pengujian perbandingan adalah metode pembangkitan data uji

yang dilakukan pada perangkat lunak yang dibuat redundan.
Perangkat lunak yang redundan mempunyai dua tim pengembang

9
yang masing-masing mengembangkan perangkat lunak sendiri-sendiri
untuk spesifikasi yang sama.

Metode pengujian perbandingan digunakan untuk

membangkitkan data uji untuk salah satu perangkat lunak, yang
kemudian digunakan sebagai masukan pada pengujian perangkat lunak
yang lain. Comparison Testing digunakan untuk system yang
menganut redundancy, kasus uji yang dirancang untuk satu versi
perangkat lunak dijadikan masukan pada pengujian versi perangkat
lunak lainnya, dan diharapkan hasil kedua versi perangkat lunak harus
sama. Jika hasil pengujian kedua perangkat lunak tersebut berbeda
maka kedua perangkat lunak itu akan dicek untuk mencari yang salah.

b. Pengujian Struktural (White box testing)

Pengujian structural (structural testing) merupakan pendekatan

terhadap pengujian yang diturunkan dari pengetahuan struktur dan
implementasi perangkat lunak. Pendekatan ini kadang-kadang disebut
pengujian ‘kotak putih’ (‘white-box’ testing), pengujian ‘kotak kaca’
atau ‘pengujian kotak jernih’ untuk membedakannya dari pengujian
kotak hitam.

Pengujian struktural biasanya diterapkan untuk unit program

yang relatif kecil seperti subrutin atau operasi yang terkait dengan
suatu objek. Sebagaimana ditunjukan oleh namanya, penguji dapat
menganalisis kode dan menggunakan pengetahuan mengenai struktur
komponen untuk menurunkan data uji. Analisis kode dapat digunakan
untuk menemukan berapa kasus uji yang dibutuhkan untuk menjamin
bahwa statement pada program atau kompenen dieksekusi paling tidak
satu kali pada proses pengujian.

Pengujian white box (glass box) adalah pengujian yang

didasarkan pada pengecekan terhadap detil perancangan,

10
menggunakan struktur kontrol dari desain program secara procedural
untuk membagi pengujian ke dalam beberapa kasus pengujian.
Penentuan kasus uji disesuaikan dengan struktur system, pengetahuan
mengenai program digunakan untuk mengidentifikasikan kasus uji
tambahan.

Tujuan penggunaan white box untuk menguji semua statement

program. Penggunaan metode pengujian white box dilakukan untuk :

 Memberikan jaminan bahwa semua jalur independen suatu modul

digunakan minimal satu kali
 Menggunakan semua keputusan logis untuk semua kondisi true
atau false
 Mengeksekusi semua perulangan pada batasan nilai dan
operasional pada setiap kondisi
 Menggunakan struktur data internal untuk menjamin validitas jalur
keputusan.

Data Uji

Kode
Komponen Output uji

Gambar 5. Pengujian Kotak Putih

Keunggulan dan Kekurangan White Box (Irwan, 2013),

Kelebihan White Box Testing :
 Kesalahan logika. Digunakan pada sintaks ‘if’ dan pengulangan.
Dimana White Box Testing akan mendeteksi kondisi-kondisi
yang tidak sesuai dan mendeteksi kapan proses pengulangan akan
berhenti.

11
 Ketidaksesuaian asumsi. Menampilkan asumsi yang tidak sesuai
dengan kenyataan, untuk di analisa dan diperbaiki.
 Kesalahan ketik. Mendeteksi bahasa pemrograman yang bersifat
case sensitive.

Kelemahan White Box Testing adalah jika digunakan Untuk

perangkat lunak yang tergolong besar, White Box Testing dianggap
sebagai strategi yang tergolong boros, karena akan melibatkan
sumber daya yang besar untuk melakukannya.

1. Pengujian Basis Path

Pengujian basis path adalah pengujian white box yang

diusulkan pertama kali oleh Tom McCabe. Metode ini
memungkinkan penguji dapat mengukur kompleksitas logis dari
desain procedural dan menggunakannya sebagai pedoman untuk
menetapkan himpunan basis dari semua jalur eksekusi.

 Notasi Diagram Alir

Notasi yang digunakan untuk menggambarkan jalur eksekusi

adalah notasi diagram alir (atau grafik program), yang menggunakan
notasi lingkaran (simpul atau node) dan anak panah (link atau edge).
Notasi ini menggambarkan aliran control logika yang digunakan
dalam suatu bahasa pemrograman.

12
 Gambar 6. Notasi Diagram Alir

Contoh diagram alir :

Var
A, B, C : integer
Begin
A := 10; (1)
B :=5; (2)
C:= 6; (3)
If A>B (4)
then C:=A+B (5)
Else if A>C (6)
then C:=A (7)
Else C:=B; (8)

13
 Endif (9)
Endif (10)
Writeln(‘Nilai C = ‘,C); (11)
End. (12)

Gambar 7. Contoh Metode Basis Path

2. Grey Box Testing

Grey Box Testing adalah sebuah metodologi kombinasi dari Black

Box dan White Box Testing, menguji software berdasarkan spesifikasi
tetapi menggunakan cara kerja dari dalam. Grey Box dapat di gunakan
dengan baik dalam software testing (Setiawan, 2014).
Grey box testing mengacu pada teknik pengujian sistem dengan
pengetahuan yang terbatas (limited knowledge) dari internal sistem. Grey
box testing memiliki akses ke desain dokumen dengan rinci melalui
informasi di luar persyaratan dokumen.

14
 Grey Box Testing biasa di gunakan pada software berorientasi
object, dimana object–object tersebut adalah unit terpisah yang memiliki
kode eksekusi atau data. Contoh aplikasi yang membutuhkan Grey Box
Testing :
 Architectural model
 Unified Modeling Language – UML Design Model
 Finite-state machine – State Model.

Teknik-teknik yang ada pada Grey Box Testing :

 Matrix Testing : menyatakan laporan atau status proyek

 Regression testing : menyatakan status apakah terjadi perubahan
pada kasus uji yang baru dibuat.
 Pattern Testing : memverifikasi aplikasi yang baik untuk desain
atau arsitektur dan pola.
 Orthogonal array testing : digunakan sebagai bagian dari semua
kemungkinan kombinasi.

Pengujian Grey Box ini cocok untuk Aplikasi WEB. Aplikasi Web
telah didistribuasikan jaringan atau system, karena tidak adanya sumber
kode atau binary, tidak mungkin untuk menggunakan pengujian, white-
box. Pengujian Black-box juga tidak digunakan karena hanya melakukan
kontrak Antara pelanggan dan pengembang, sehinggal lebih efisien
menggunakan Grey-box testing sebagai informasi penting yang tersedia
dalam Web Service Definition Language (WSDL).

Pengujian Grey Box cocok untuk pengujian fungisonal atau domain

bisnis. Pengujian fungsional dilakaukan pada dasarnya tes interaksi
pengguna dengan system. Ini juga membantu untuk mengkonfirmasi
software yang memenuhi persyaratan yang di tetapkan untuk perangkat
lunak.

15
 3. Pengujian Stress

Dirancang untuk menghadapi situasi yang tidak normal pada saat

program diuji. Testing ini dilakukan oleh sistem untuk kondisi seperti
volume data yang tidak normal (melebihi atau kurang dari batasan) atau
frekuensi (Parno, tt). Tujuan pengujian stress (Ridwan, 2012):
 Mengetahui kemampuan sistem dalam melakukan transaksi selama
periode waktu puncak proses. Contoh periode puncak: ketika
penolakan proses login on-line setelah sistem down atau pada kasus
batch, pengiriman batch proses dalam jumlah yang besar dilakukan
setelah sistem down.
Contoh :
Melakukan login ke server ketika sejumlah besar workstation
melakukan proses menjalankan perintah sql database.

4. Prinsip-prinsip Pengujian

Sebelum menetapkan metode pengujian, seorang ahli pada bidang

software harus mengerti betul atau memahami prinsip dasar yang menuntun
pengujian perangkat lunak. Alan Davis mendefinisikan sendiri  mengenai prinsip-
prinsip pengujian terhadap perangkat lunak  :
1. Semua pengujian harus dapat ditelusuri hingga ke persyaratan pelanggan.
Sebagai tujuan utama pengujian perangkat lunak yaitu untuk mengungkap
kesalahan. Yang mana berarti kesalahan paling fatal apabila perangkat
lunak tidak dapat memenuhi syarat yang ditentukan oleh pelanggan.
2. Pengujian harus direncanakan lama sebelum pengujian itu dimulai.
Perencanaan pengujian dapat dimulai setelah model persyaratan telah
dilengkapi. Definisi detail tentang test case dapat dimulai segera setelah
model desain ditetapkan. Dengan demikian pengujian dapat direncanakn
dan dirancang sebelum pengkodean dilakukan.
3. Prinsip Pareto berlaku untuk pengujian perangkat lunak.
Prinsip Pareto mengimplikasikan bahwa 80% dari semua kesalahan yang
ditemukan selama pengujian, hanya dapat ditelusuri 20% dari semua

16
 modul program. Hanya saja kita sulit untuk mengetahui modul yang
mengalami kesalahan dan mengujinya dengan teliti.
4. Pengujian harus mulai “dari yang terkecil” dan berkembang ke pengujian
“yang besar”.
Pengujian biasanya dilakukan terhadap modul program individual. Selagi
pengujian berlangsung, maka seluruh modul yang terintegrasi lebih mudah
diuji.
5. Pengujian yang mendalam tidak mungkin.
Jumlah jalur permutasi pada perangkat lunak sangat besar, oleh karena itu
sulit untuk melakukan pengujian terhadap semua jalur skema pengujian.
Akan tetapi setidaknya kita dapat mengetahui bahwa logika yang tertuang
dalam perancangan perangkat lunak itu telah tepat dan memastikan semua
kondisi telah teruji.
6. Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak ketiga
yang independen.
Arti dari “paling efektif”  adalah pengujian yang memiliki peluang
tertinggi untuk menemukan kesalahan. Perekayasa perangkat lunak yang
membuat sistem bukanlah orang yang paling tepat untuk melakukan
semua pengujian bagi perangkat lunak.
Dalam berbagi kasus pengujian terkadang sulit untuk menentukan
keberhasilan maupun kelayakan dari pengujian tersebut. Dalam melaksanakan
pengujian terdapat beberapa point untuk menentukan keberhasilan dari pengujian
yang dilakukan. Di antaranya :

 Pengujian tersebut memiliki probabilitas yang tinggi untuk menemukan

kesalahan.
Penguji harus memahami perangkat lunak yang diuji sehingga dapat
menemukan dan menentukan kemungkinan penyebab terjadinya kesalahan
dalam perangkat lunak.

17
  Pengujian yang baik tidak redundan
Mengingat adanya batasan waktu dalam melakukan sebuah pengujian
maka efektifitas ahrus dipertimbangkan sehingga diupayakan dalam
pengjian hanya dilakukan untuk kasus yang berbeda.
 Pengujian yang baik haruslah “jenis terbaik”
Penguji harus dapat menentukan jenis pengujian yang terbaik yang dapat
digunakan untuk menemukan banyak jenis kesalahan pada perangkat
lunak.
 Pengujian yang baik tidak boleh terlalu sederhana maupun terlalu
kompleks
Pengujian harus dilakukan terpisah untuk test case yang berbeda. Jangan
dilakukan secara bersama-sama.

5. Kegagalan dan Kesalahan

Kesalahan sistem tidak selalu mengakibatkan error sistem, karena status

salahnya mungkin bersifat sementara dan dapat diperbaiki sebelum terjadi
perilaku yang merupakan error. Jenis kegagalan dan kesalahan pada sistem antara
lain  : (Sommerville, 2003)
 Kegagalan sistem (system failure), Peristiwa yang terjadi pada suatu waktu
ketika sistem tidak memberikan layanan sebagaiman diharapkan oleh user.

 Eror sistem (system eror), Perilaku eror sistem dimana perilaku, sistem
yang tidak sesuai dengan spesifikasinya
 Kesalahan sistem (system fault), Status sistem yang tidak benar, yaitu
status sistem yang tidak diharapkan oleh perancang sistem.
 Eror atau kesalahan manusia (human error), Perilaku manusia yang
mengakibatkan kesalahan sistem.

Telah diketahui bahwa salah satu tujuan dari pengujian terhadap perangkat
lunak, adalah untuk menemukan suatu kesalahan. Kesalahan-kesalahan tersebut
mempunyai tingkatan-tingkatan yang diukur dengan istilah yang dimengerti oleh
manusia. Tingkatan-tingkatan kesalahan tersebut dikategorikan sebagai berikut :

18
1. Mild (Ringan)
Gejala dari kesalahan yang mengganggu kita secara estetis
 Kesalahan pengejaan
 Kesalahan penempatan

2. Moderate (sedang)
 Kesalahan yang berpengaruh pada penampilan system
 Informasi yang menyesatkan

3. Annoying (menjengkelkan)
 Kesalahan dari sistem karena adanya suatu virus.
 Nama yang terpotong
 Tagihan untuk Rp. 0,00 di cetak / dikirim

4. Disturbing (mengganggu)
 Sistem menolak untuk menangani transaksi yang sah
 Kartu kredit yang dilaporkan tidak bisa digunakan

5. Serious (serius)
 Perhitungan yang salah
 Hal ini menghilangkan hubungan pada proses transaksi
 Tidak mencetak setiap pembayaran

6. Very Serious (sangat serius)

 Kesalahan yang menyebabkan system melakukan transaksi yang
salah
 Sebuah system kredit dapat melakukan kesalahan perhitungan

7. Extreme (besar)
 Masalah yang tidak terbatas pada beberapa transaksi
 Sering berubah-ubah atau masalah yang tidak lazim

19
 8. Intolerable (kurang tahan)
 Pertimbangan yang serius diberikan untuk mematikan system.

9. Catastrophic (bencana besar)

 Sistem yang salah.

6. Testability (Kemampuan Test)

Testabilitas perangkat lunak adalah seberapa mudah sebuah program

komputer dapat diuji. Karena pengujian sangat sulit, maka perlu diketahui apa
yang dapat dilakukan untuk membuatnya menjadi mudah. Kadang-kadang
pemrogram bersedia melakukan hal-hal yang akan membantu proses pengujian,
dan membuat checklist (daftar periksa) mengenai masalah-masalah desain yang
mungkin, fitur dan lain sebagainya yang dijadikan sebagai pedoman dalam
melakukan pengujian. Beberapa checklist dibawah ini, akan membantu sebagai
pedoman dalam kegiatan pengujian perangkat lunak  :

1. Operability (Mampu menjalankan/operasi)

 Semakin baik hal tersebut dijalankan, pengujian akan semakin efesien.
 Sistem memiliki sedikit kesalahan.
 Tidak ada kesalahan yang menghalangi jalannya pengujian.
 Produk berkembang dalam tahapan fungsional (memungkinkan
pengembangan dan pengujian secara simultan)

2. Observability (Kemampuan untuk mengamati/meneliti) “Apa yang dilihat

adalah apa yang diuji.”
 Output yang berbeda dikeluarkan oleh masing-masing input.
 Tahap dan variabel sistem dapat dilihat atau diantrikan selama
eksekusi.

20
  Sistem dan variabel yang lalu dapat dilihat atau diantrikan (misalnya,
logaritma transaksi)
 Semua faktor yang mempengaruhi output dapat dilihat.
 Output yang tidak benar dapat diidentifikasi dengan mudah.
 Kesalahan internal dideteksi secara otomatis melalui mekanisme
pengujian itu sendiri.
 Kesalahan internal dilaporkan secara otomatis.
 Kode sumber dapat diakses.

3.  Controllability (Kemampuan untuk mengawasi) “ Semakin baik kita dapat

mengontrol perangkat lunak, semakin banyak pengujian yang dapat diotomatisasi
dan dioptimalkan. “

 Semua output yang baik, dapat diperoleh melalui beberapa kombinasi

input.
 Semua kode dapat dijalankan melalui berbagai kombinasi input.
 Keadaan dan variabel perangkat lunak dan perangkat keras dapat dikontrol
secara langsung oleh penguji.
 Format input dan output konsisten dan terstruktur.
 Pengujian dapat dispesifikasi, dioptimasi, dan direproduksi dengan baik.

4.  Decomposability (Kemampuan untuk menyelesaikan)

 Dengan mengontrol ruang lingkup pengujian, kita dapat dengan lebih

cepat mengisolasi masalah dan melakukan pengujian kembali secara lebih
halus.
 Sistem perangkat lunak dibangun dari modul-modul yang independen.
 Modul-modul dapat diuji secara independen.

5.  Simplicity (Kemampuan untuk menyederhanakan kerumitan)

 Semakin sedikit  yang diuji, semakin cepat kita dapat mengujinya.

21
  Fungsi yang sederhana (kumpulan fitur adalah kebutuhan minimum untuk
memenuhi persyaratan).
 Struktur yang sederhana (arsitektur dimodularisasi untuk membatasi
penyebaran kesalahan).
 Kode yang sederhana (standar pengkodean diadopsi demi kemudahan
inspeksi dan pemeliharaan)

6.  Stability (Mampu menyeimbangkan)

 Semakin sedikit perubahan, semakin sedikit gangguan dalam pengujian.

 Perubahan perangkat lunak jarang terjadi.
 Perubahan perangkat lunak dapat dikontrol.
 Perubahan perangkat lunak memvalidasi pengujian yang sudah ada.
 Kegagalan perangkat lunak dapat diperbaiki dengan baik.

7.  Understandbility (kemampuan untuk memahami/mengerti)

 Semakin banyak informasi yang kita dapat, semakin mudah pengujian

dilakukan.
 Rancangan dapat dipahami dengan baik.
 Ketergantungan antara komponen internal, eksternal, dan yang dipakai
bersama, dipahami dengan baik.
 Perubahan rancangan dibicarakan.
 Dokumentasi teknik dapat diakses dengan cepat.
 Dokumen teknik diorganisasikan dengan baik.
 Dokumentasi teknik spesifik dan detail.
 Dokumentasi teknik akurat.

22
 DAFTAR PUSTAKA

Galin, Daniel. (2004). Software Quality Assurance From Theory to

Implementation. England: Pearson Education Limited.

Gunadarma, “Metode Pengujian Perangkat Lunak Black Box”.

http://wsilfi.staff.gunadarma.ac.id/. Diakses pada tanggal 18 Maret 2016.
Irfan. (2010). Testing Perangkat Lunak. http://www.slideshare.net/Mrirfan/04-
testing-perangkat-lunak. Diakses pada tanggal 18 Maret 2016.
Irwan, Muhammad. (2013). Black Box Testing Dan White box Testing
http://tkjpnup.blogspot.co.id/2013/12/black-box-testing-dan-white-box-
testing.html. Diakses pada tanggal 17 Maret 2016.
Ridwan, Doris. (2012). Dasar-Dasar Pengujian Perangkat Lunak
http://dorisazzura.blogspot.com/2012/07/dasar-dasar-pengujian-perangkat-
lunak.html. Diakses pada tanggal 18 Maret 2016.
Ridwan, Muhammad. (2013). Materi Testing. https://www.academia.edu/.
Diakses pada tanggal 17 Maret 2016.
Rouf, Abdul. (2012). Pengujian Perangkat Lunak Dengan Menggunakan Metode
White Box Dan Black Box. www.ejournal.himsya.ac.id Diakses pada
tanggal 18 Maret 2016.
Setiawan, Wira. (2014). Grey Box Testing https://wirasetiawan29.wordpress.com.
Diakses pada tanggal 18 Maret 2016.
Sihabuddin, Muhammad Rijja (2014). Metode White Box Dan Black Box Testing.
http://rijjasihabuddin.blogspot.co.id. Diakses pada tanggal 17 Maret 2016.
Sommerville, Ian. (2003). Software Engineering, 6th edition. Erlangga, Jakarta.
Wahyudi, Bambang (2013). PPL: Melakukan Pengujian Perangkat Lunak
http://belajar-barengan.blogspot.co.id. Diakses pada tanggal 17 Maret
2016.

23
24