22
MAKALAH
PENGUJIAN PENJAMINAN MUTU PERANGKAT LUNAK
Disusun Oleh :
Diah Afrianti 120155201034
Lydia Wati 120155201041
Ahmad Hafizh 120155201042
Novricky Wahyudi 120155201058
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
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
Pengertian Pengujian Perangkat Lunak
Berikut ini definisi pengujian perangkat lunak menurut para ahli, diantaranya:
Menurut Myers (1979)
Proses menjalankan program dengan maksud menemukan kesalahan.
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.
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 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):
Verifikasi dan Validasi adalah proses yang meyakinkan adanya kesalahan pada sistem perangkat lunak.
Debug merupakan proses yang menemukan dan membetulkan kesalahan tersebut.
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:
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).
Tipe Pengujian
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 CacatGambar 1. Proses Pengujian Cacat
Gambar 1. Proses Pengujian Cacat
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 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).
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.
SistemInput data ujiIeOutput hasil ujiOeSistemInput data ujiIeOutput hasil ujiOe
Sistem
Input data uji
Ie
Output hasil uji
Oe
Sistem
Input data uji
Ie
Output hasil uji
Oe
Gambar 2. Pengujian Kotak HitamGambar 2. Pengujian Kotak Hitam
Gambar 2. Pengujian Kotak Hitam
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.
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) :
Didesain untuk mengungkap kesalahan pada persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program.
Berfokus pada domain informasi dari perangkat lunak.
Melakukan teste case dengan mempartisi domain input dan output dari suatu program dengan cara yang memberikan cakupan pengujian yang mendalam.
Partisi ekivalensi (Equivalence Class Partitioning) membagi domain input kedalam kelas data yang mungkin untuk melakukan fungsi perangkat lunak tertentu.
Analisis nilai terbatas (Boundary Value Analysis) memeriksa kemampuan program untuk menangani data pada patas yang dapat diterima.
Pengujian perbandingan (Comparison Testing) mengembangkan perangkat lunak ke dalam versi-versi yang independen dari suatu aplikasi dengan menggunakan spesifikasi yang sama. Setiap versi 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):
Spesifikasi program dapat ditentukan di awal
Dapat digunakan untuk menilai konsistensi program
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 :
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 :
Gambar 3. representasi simbolik dari grafikGambar 3. representasi simbolik dari grafik
Gambar 3. representasi simbolik dari grafik
Gambar 3. representasi simbolik dari grafik
Keterangan :
Simpul, merepresentasikan objek.Link, merepresentasikan hubungan antar objek.xxLink paralel, menggambarkan hubungan yang berbeda yang dibangun antar nodeLink simetris, menggambarkan hubungan dua arah antar dua objekSimpul, merepresentasikan objek.Link, merepresentasikan hubungan antar objek.xxLink paralel, menggambarkan hubungan yang berbeda yang dibangun antar nodeLink simetris, menggambarkan hubungan dua arah antar dua objek
Simpul, merepresentasikan objek.
Link, merepresentasikan hubungan antar objek.
x
x
Link paralel, menggambarkan hubungan yang berbeda yang dibangun antar node
Link simetris, menggambarkan hubungan dua arah antar dua objek
Simpul, merepresentasikan objek.
Link, merepresentasikan hubungan antar objek.
x
x
Link paralel, menggambarkan hubungan yang berbeda yang dibangun antar node
Link simetris, menggambarkan hubungan dua arah antar dua objek
Beban simpul (node weight), menggambarkan property dari suatu simpul.
Beban link (link weight), menggambarkan karakterisktik suatu link.
Contoh grafik pengolah kata
New fileDocument windowDocument textNew fileDocument windowDocument textWaktu pembangkitan < 1,0 detikWaktu pembangkitan < 1,0 detikMenu select membangkitkanMenu select membangkitkan
New file
Document window
Document text
New file
Document window
Document text
Waktu pembangkitan < 1,0 detik
Waktu pembangkitan < 1,0 detik
Menu select membangkitkan
Menu select membangkitkan
Membolehkan editingMembolehkan editing
Membolehkan editing
Membolehkan editing
berisiberisiDihadirkan sebagaiDihadirkan sebagai
berisi
berisi
Dihadirkan sebagai
Dihadirkan sebagai
Gambar 4. Contoh grafikGambar 4. Contoh grafik
Gambar 4. Contoh grafik
Gambar 4. Contoh grafik
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
Bila kondisi input menentukan suatu range, maka satu kelas ekuvalensi valid dan dua yang invalid ditentukan
Bila suatu kondisi input memerlukan suatu harga khusus, maka satu kelas ekuivalensi valid dan dua yang invalid ditentukan
Bila suatu kondisi menentukan anggota suatu himpunan, maka satu kelas ekuivalensi valid atau dua yang invalid ditentukan
Bila suatu kondisi input adalah Boolean, maka satu kelas valid dan satu yang lain ditentukan.
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 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.
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, 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 UjiKodeKomponenOutput ujiData UjiKodeKomponenOutput uji
Data Uji
Kode
Komponen
Output uji
Data Uji
Kode
Komponen
Output uji
Gambar 5. Pengujian Kotak PutihGambar 5. Pengujian Kotak Putih
Gambar 5. Pengujian Kotak Putih
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.
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.
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.
Gambar 6. Notasi Diagram AlirGambar 6. Notasi Diagram Alir
Gambar 6. Notasi Diagram Alir
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)
Endif (9)
Endif (10)
Writeln('Nilai C = ',C); (11)
End. (12)
Gambar 7. Contoh Metode Basis PathGambar 7. Contoh Metode Basis Path
Gambar 7. Contoh Metode Basis Path
Gambar 7. Contoh Metode Basis Path
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.
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.
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.
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 :
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.
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.
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 modul program. Hanya saja kita sulit untuk mengetahui modul yang mengalami kesalahan dan mengujinya dengan teliti.
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.
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.
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.
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.
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 :
Mild (Ringan)
Gejala dari kesalahan yang mengganggu kita secara estetis
Kesalahan pengejaan
Kesalahan penempatan
Moderate (sedang)
Kesalahan yang berpengaruh pada penampilan system
Informasi yang menyesatkan
Annoying (menjengkelkan)
Kesalahan dari sistem karena adanya suatu virus.
Nama yang terpotong
Tagihan untuk Rp. 0,00 di cetak / dikirim
Disturbing (mengganggu)
Sistem menolak untuk menangani transaksi yang sah
Kartu kredit yang dilaporkan tidak bisa digunakan
Serious (serius)
Perhitungan yang salah
Hal ini menghilangkan hubungan pada proses transaksi
Tidak mencetak setiap pembayaran
Very Serious (sangat serius)
Kesalahan yang menyebabkan system melakukan transaksi yang salah
Sebuah system kredit dapat melakukan kesalahan perhitungan
Extreme (besar)
Masalah yang tidak terbatas pada beberapa transaksi
Sering berubah-ubah atau masalah yang tidak lazim
Intolerable (kurang tahan)
Pertimbangan yang serius diberikan untuk mematikan system.
Catastrophic (bencana besar)
Sistem yang salah.
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 :
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)
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.
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.
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.
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.
