i
ANALISIS DAN PENGUJIAN PERANGKAT LUNAK DENGAN METODE
BLACK BOX, STUDI KASUS BRS ONLINE
UNIVERSITAS SANATA DHARMA
SKRIPSI
Diajukan untuk Memenuhi Salah Satu Syarat
Memperoleh Gelar Sarjana Komputer
Program Studi Teknik Informatika
Oleh :
I Komang Widya Purnama Yasa
085314027
PROGRAM STUDI TEKNIK INFORMATIKA
FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS SANATA DHARMA
YOGYAKARTA
ii
ANALYSIS AND SOFTWARE TESTING WITH BLACK BOX METHOD,
STUDY CASE BRS ONLINE
SANATA DHARMA UNIVERSITY.
THESIS
Presented as a Partial Fulfillment of the Requirements
to Obtain Sarjana Computer Degree
In Informatics Engineering
By :
I Komang Widya Purnama Yasa
085314027
INFORMATICS ENGINEERING STUDY PROGRAM
FACULTY OF SCIENCE AND TECHNOLOGY
SANATA DHARMA UNIVERSITY
YOGYAKARTA
v
HALAMAN PERSEMBAHAN
Karya ini ku persembahkan kepada Tuhan Yang Maha Esa, sebagai
kebanggaan Ayah, Ibu dan kakak-kakakku atas kerja keras selama penulis
menempuh studi. Kepada Universitas Sanata Dharma yang telah memberikan
segudang ilmu kepada penulis sehingga mampu memperkaya diri guna masa
vi
PERNYATAAN KEASLIAN KARYA
Dengan ini saya menyatakan bahwa dalam skripsi ini tidak terdapat karya
yang pernah diajukan untuk memperoleh gelar kesarjanaan di suatu Perguruan
Tinggi, dan sepanjang pengetahuan saya juga tidak terdapat karya atau pendapat
yang pernah ditulis oleh orang lain, kecuali yang secara tertulis diacu dalam
naskah ini dan disebutkan dalam daftar pustaka.
Yogyakarta, 19 Januari 2013
Penulis,
vii
LEMBAR PERNYATAAN PERSETUJUAN
PUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS
Yang bertanda tangan di bawah ini, saya mahasiswa Universitas Sanata Dharma :
Nama : I Komang Widya Purnama Yasa
Nomor Mahasiswa : 085314027
Demi pengembangan ilmu pengetahuan, saya memberikan kepada perpustakaan
Universitas Sanata Dharma karya ilmiah saya yang berjudul :
Analisis Dan Pengujian Perangkat Lunak
Dengan Metode Black Box, Studi Kasus BRS Online
Universitas Sanata Dharma.
Beserta perangkat yang diperlukan (bila ada). Dengan demikian saya memberikan
kepada Perpustakaan Universitas Sanata Dharma hak untuk menyimpan,
mengalihkan dalam bentuk media lain, mengelolanya dalam bentuk pangkalan
data, mendistribusikan secara terbatas, dan mempublikasikannya di internet atau
media lain untuk kepentingan akademis tanpa perlu meminta izin dari saya
maupun memberikan royalti kepada saya selama tetap mencantumkan nama saya
sebagai penulis.
Demikian pernyataan ini saya buat dengan sebenarnya.
Dibuat di Yogyakarta
Pada tanggal : 19 Januari 2013
viii
HALAMAN MOTO
Masalah ada ketika kita melakukan suatu proses ...
Suatu kesuksesan itu bukan hal yang mustahil kita bisa peroleh,
karena kesuksesan tersebut sebenarnya telah tertanam di dalam diri
seseorang. Temukan kunci kesuksesan tersebut melalui kerja keras,
berlapang dada dan berdoa pada setiap proses yang terjadi dalam
hidup kita maka tidak mustahil lagi kesuksesan menjadi milik kita.
ix ABSTRAK
Pengujian Black Box merupakan salah satu metode pengujian suatu perangkat lunak di mana pengujiannya hanya terbatas pada suatu interface yang tersaji tanpa pengujian lebih detail ke dalam struktur program perangkat lunak. Pengujian
black box ini menggunakan tiga langkah dalam melakukan analisa yaitu graph-based, partisi ekuivalensi dan analisa nilai batas. Pengujian ini akan melakukan analisa setiap fungsi pada modul-modul yang tersedia di perangkat lunak apakah telah sesuai dengan yang diharapakan atau tidak. Hal tersebut bertujuan untuk menemukan kesalahan-kesalahan yaitu Fungsi-fungsi yang tidak benar atau hilang, kesalahan interface, kesalahan dalam struktur data atau akses database eksternal, kesalahan kinerja atau performansi serta inisialisasi dan kesalahan terminasi. Dalam proses pengujian maupun analisa suatu sistem, terbagi atas modul-modul utama hal ini bertujuan untuk membagi berdasarkan fungsi yang diberikan dan melihat pengaruh dari fungsi tersebut.
Sistem Informasi Akademik (SIA) merupakan suatu perangkat lunak yang menangani masalah yang berkaitan dengan aktifitas akademik. Salah satu produk dari Sistem Informasi Akademik (SIA) yaitu BRS Online. BRS Online merupakan suatu sistem berbasis intranet yang dikembangkan oleh BAPSI untuk meningkatkan efektifitas dan kualitas pelayanan kepada mahasiswa di Universitas Sanata Dharma. Sistem ini mampu melayani pengambilan rencana studi mahasiswa, transkrip nilai, jadwal kuliah, pengelolaan sistem poin melalui kegiatan keorganisasian maupun asistensi dan sebagainya melalui akses intranet. dalam pengujiannya sistem ini terbagi atas 3 jenis sistem pengguna dengan jumlah modul yaitu SIA Mahasiswa dengan jumlah modul 22, SIA Dosen Pembimbing Akademik dengan jumlah modul 17, SIA Kepala Program Studi dengan jumlah modul 14.
Pengumpulan data pengujian SIA dilakukan dengan cara menyebarkan cek list dalam bentuk kuesioner kepada mahasiswa, dosen pembimbing akademik, kepala program studi Universitas Sanata Dharma yang memanfaatkan Sistem Informasi Akademik dalam proses BRS Online. Analisa dan pengujian graph-based, partisi ekuivalensi dan analisa nilai batas dilakukan secara pribadi oleh penulis dengan proses percobaan yang dibantu oleh pihak lain. Hasil analisa menunjukkan bahwa dari ketiga modul pengguna tersebut dinyatakan sesuai dalam memenuhi kebutuhan pengguna dengan perolehan derajat nilai modul pengguna lebih besar sama dengan dari 0.80 (80%) atau masih di atas rata-rata standar keberhasilan sistem. Berdasarkan hasil ini dapat disimpulkan bahwa metode pengujian black box dapat menentukan tingkat keberhasilan Sistem Informasi Akademik (SIA) serta dapat menemukan kesalahan yang ada di dalam sistem.
x ABSTRACT
The Black Box testing is one of the software testing methods where the testing is limited only to an interface presented without detailed testing toward the
software’s structure. The Black Box testing employs three phases in conducting
the analysis namely graph-based, equivalence partition, and analysis of value limitation. The testing will conduct an analysis toward each function in the modules available in the software in order to find out whether the software has been under the expectation or not. The objective of the analysis is to find the errors such as inappropriate or missing functions, interface errors, structure of data or access of external database errors, performance errors, and initialization or termination errors. Within the testing process or the analysis of an item, the phases are divided into the main modules in order to make a category based on the given function and to see the effect of the given function.
Sistem Informasi Akademik (SIA) is software that handles problems related to the academic activities. One of the products provided by Sistem Informasi Akademik (SIA) is BRS Online. BRS Online is an intranet-based system developed by BAPSI in order to increase the effectiveness and the quality of service toward the students in Sanata Dharma University. The system is able to serve the setting
of students’ study plan, score transcripts, course timetable, management of point
system through the organizational activities, and even assistency or any other activity by means of intranet access. Within the testing, the system is divided into 3 types of user system with the following numbers of modules: SIA Mahasiswa
with 22 units, SIA Dosen Pembimbing with 17 unit, and SIA Kepala Program Studi with 14 units.
The data gathering of SIA testing was conducted by delivering checklists in the forms of questionnaires to the students, the academic supervisors, and the heads of study programs who benefit Sistem Informasi Akademik in the process of
BRS Online. The analysis and the testing of graph based, equivalence partition, and analysis of limitation value are conducted in private manner by means of third-party assistance. The results of the analysis showed that the three modules of users have been appropate in meeting the users’ demand with the degree of score attainment for 0.80 (80%) or still above the standard of system success. Based on the result, the researcher conclude that the Black Box testing method is able to determine the level of Sistem Informasi Akademik (SIA) success and is able to find the errors within a system.
xi
KATA PENGANTAR
Puji dan syukur penulis tujukkan ke hadirat Tuhan Yang Maha Esa, karena hanya
dengan segala berkat dan limpah-Nya penulis dapat menyelesaikan skripsi yang
berjudul “Analisis dan Pengujian Perangkat Lunak dengan Metode Black Box,
Studi Kasus BRS Online Universitas Sanata Dharma” dengan baik.
Momen ini penulis gunakan untuk menyampaikan rasa terima kasih kepada
pihak-pihak yang telah turut membantu dan melancarkan terselesainya skripsi ini :
1. Ibu Paulina Heruningsih Prima Rosa, S.Si., M.Sc. selaku Dekan Fakultas
Sains dan Teknologi Universitas Sanata Dharma.
2. Kaprodi Teknik Informatika Ibu Ridowati Gunawan, S.Kom., M.T. dan
Wakaprodi Teknik Informatika Ibu Sri Hartati Wijono, S.Si., M.Kom. atas
semangat dan motivasinya.
3. Bapak Drs. Johanes Eka Priyatma M.Sc., Ph.D. selaku dosen pembimbing
utama yang telah menyediakan waktu, tenaga dan pikiran dalam membimbing
penulis sehingga penelitian ini dapat berjalan dengan lancar.
4. Kepada bapak Puspaningtyas Sanjoyo Adi., S.T., M.T. serta Eko Hari
Parmadi, S.Si., M.Kom. selaku dosen penguji yang telah memberikan
bantuan bimbingan serta masukan yang membangun dalam penelitian ini.
5. Kepada Drs. Stephanus Hari Suparwito, S.J.M.App.IT. selaku Kepala BAPSI
serta staf yang senantiasa memberikan masukan dan data untuk
menyelesaikan penelitian ini.
6. Drs. I Ketut Sukasana dan Ni Luh Subadri, Ayah dan Ibu yang tidak
xii
bersekolah sampai lulus dari Teknik Informatika Universitas Sanata Dharma.
Kakak-kakakku, I Putu Suputra Utama dan Ni Made Putri Utami, yang turut
memberikan dukungan moril dan materil untuk menyelesaikan penelitian ini.
7. Kepada I Gusti Nyoman Sedana, Heribertus Adi Wibowo, Raymundus
Nonnatus, Chandra, Agus oki, Eduardus yang telah memberikan motivasi dan
bantuan dalam pengambilan data.
8. Semua teman di Teknik Informatika. Persahabatan yang telah terjalin selama
kuliah di Universitas Sanata Dharma, mungkin dilain waktu dan kesempatan
pertemanan tersebut dapat berlanjut dengan membangun kerja sama bisnis.
9. Terakhir untuk saudara-saudara di Keluarga Mahasiswa Hindu Dharma
(KMHD) Swastika Taruna terima kasih atas doanya, ini sekaligus motivasi
buat kalian.
Penulis menyadari bahwa skripsi ini masih memiliki banyak kekurangan,
sehingga segala bentuk kritik dan saran berbagai pihak yang bersifat membangun
sangat penulis harapkan demi mencapai perbaikan yang lebih baik kedepannya.
Akhirnya dengan segala kekurangan yang ada, penulis berharap skripsi ini
bermanfaat dalam meningkatkan ilmu pengetahuan khususnya di bidang Teknik
Informatika.
Yogyakarta, 19 Januari 2013
xiii
DAFTAR ISI
HALAMAN JUDUL ... i
HALAMAN JUDUL (ENGLISH) ... ii
HALAMAN PERSETUJUAN PEMBIMBING ...iii
HALAMAN PENGESAHAN ... iv
HALAMAN PERSEMBAHAN ... v
PERNYATAAN KEASLIAN KARYA ... vi
LEMBAR PERSETUJUANPUBLIKASI KARYA ILMIAH... vii
HALAMAN MOTO ...viii
1.6. Sistematika Penulisan ... 6
BAB II TINJAUAN PUSTAKA ... 8
2.1 Perangkat Lunak ... 8
2.1.1. Definisi Perangkat Lunak ... 8
2.1.2. Pengertian Rekayasa Perangkat Lunak ... 9
2.1.3. Karakteristik perangkat lunak ... 10
2.1.4. Aplikasi Perangkat Lunak ... 12
2.1.5. Jenis kerusakan dalam perangakat lunak ... 13
2.2. Sistem Informasi Akademik (SIA) ... 14
2.2.1. Penjelasan Sistem Informasi Akademik (SIA) ... 15
2.2.2. Penjelasan BRS Online ... 15
2.3. Pengujian Perangkat Lunak ... 16
2.3.1. Definisi Pengujian Perangkat Lunak ... 17
2.3.2. Sasaran Pengujian ... 17
2.3.3. Verifikasi dan Validasi ... 18
2.3.4. Strategi Pengujian ... 20
2.3.5. Testabilitas ... 21
2.3.6. Tujuan Pengujian ... 23
2.4. Black Box ... 24
2.4.1. Pengujian Black Box ... 24
2.4.2. Graph Based Testing... 25
2.4.3. Equivalence Partitioning (Partisi Ekuivalensi)... 28
2.4.4. Boundary Value Analysis (Analisis Nilai Batas) ... 30
BAB III RANCANG BANGUN PENELITIAN ... 32
3.1. Jenis Penelitian ... 32
3.2. Obyek Penelitian ... 33
3.3. Identifikasi Resiko Perangkat Lunak ... 33
3.4. Efektifitas Pengujian ... 35
3.5. Identifikasi Fungsi Utama Produk... 35
3.6. Tahap Pengujian Perangkat Lunak ... 36
xiv
3.6.2. Tahap Pengujian Fungsional ... 37
3.6.3. Tahap Pengujian Graph-Based ... 38
3.6.4. Tahap Pengujian Equivalence Partitioning ... 39
3.6.5. Tahap Pengujian Boundary Value Analysis ... 39
3.7. Modul Pengujian Perangkat Lunak ... 42
3.7.1. Modul Pengujian Mahasiswa ... 43
3.7.2. Modul Pengujian Dosen Pembimbing Akademik (DPA) ... 46
3.7.3. Modul Pengujian Kepala Program Studi (Kaprodi) ... 48
3.8. Perolehan Data ... 49
3.9. Kebutuhan perangkat lunak pendukung pengujian. ... 51
3.10. Metode analisis data ... 51
3.11. Estimasi Waktu Pengujian dan Keterlibatan Pengguna. ... 54
3.11.1. Estimasi Waktu Pengujian ... 54
3.11.2. Keterlibatan Pengguna ... 55
BAB IV HASIL DAN ANALISA... 56
4.1. Proses Pengujian ... 56
4.2. Demografi responden ... 58
4.2.1. Karakteristik Responden Pada Program Studi ... 58
4.3. Hasil Pengujian ... 61
4.3.1. Tahap perencanaan dan penentuan kasus pengujian ... 62
4.3.2. Tahap pengujian fungsional ... 62
4.3.3. Tahap pengujian graph-based, equivalence partitioning serta boundary value analysis. 63 4.3.3.1. Fungsi – fungsi yang tidak benar atau hilang ... 63
4.3.3.2. Kesalahan interface ... 64
4.3.3.3. Kesalahan dalam struktur data atau akses database eksternal ... 65
4.3.3.4. Kesalahan kinerja atau performansi ... 66
4.3.3.5. Inisialisasi dan kesalahan terminasi... 66
4.3.4. Tahap pengujian test case (cek list) ... 67
4.3.4.1.Persentase Nilai Modul Pengguna ... 67
4.3.4.2.Standar Deviasi ... 69
4.3.4.3. Nilai Persentase SIA Berdasarkan Pembagian Persentase Yang Sama Setiap Pernyataan 72 4.3.4.4. Perbandingan Persentase Antara Nilai Modul Pengguna Tanpa Bobot dengan Nilai Persentase Modul Pengguna dengan Bobot ... 73
4.3.5.2. Persentase nilai modul pengguna ... 85
4.4. Kendala Pengujian ... 89
BAB V KESIMPULAN DAN SARAN ... 90
5.1. Kesimpulan ... 90
5.2. Saran ... 92
DAFTAR PUSTAKA ... 94
xv
DAFTAR GAMBAR
Gambar 2.1. Pencapaian kualitas perangkat lunak... 18
Gambar 2.2. Strategi Pengujian ... 21
Gambar 2.3. (a) notasi grafik; (b) contoh sederhana ... 26
Gambar 3.1. Tahapan Pengujian Perangkat Lunak ... 40
Gambar 4.1. Diagram Derajat Nilai Modul ... 68
Gambar 4.2. Diagram Standar Deviasi – SIA Kemahasiswaan ... 69
Gambar 4.3. Diagram Standar Deviasi – SIA DPA ... 70
Gambar 4.4. Diagram Standar Deviasi – SIA Pejabat ... 71
xvi
DAFTAR TABEL
Tabel 3.1. Tabel Jumlah Modul Pengujian ... 41
Tabel 3.2. Tabel Pengujian Mahasiswa... 42
Tabel 3.3. Tabel Pengujian Dosen Pembimbing Akademik (DPA)... 45
Tabel 3.4. Tabel Pengujian Kepala Program Studi (Kaprodi) ... 47
Tabel 3.5. Estimasi Waktu Pengujian ... 54
Tabel 3.6. Keterlibatan Pengguna ... 55
Tabel 4.1.Tabel karakteristik Responden Sistem Informasi Akademik (SIA) Kemahasiswaan ... 59
Tabel 4.2. Tabel karakteristik Responden Sistem Informasi Akademik (SIA) DPA ... 60
Tabel 4.3. Tabel karakteristik Responden Sistem Informasi Akademik (SIA) Pejabat ... 61
Tabel 4.4. Fungsi – fungsi yang tidak benar atau hilang ... 64
Tabel 4.5. Kesalahan interface ... 65
Tabel 4.6. Kesalahan dalam struktur data atau akses database eksternal... 65
Tabel 4.7. Kesalahan kinerja atau performansi ... 66
Tabel 4.8. Inisialisasi dan kesalahan terminasi ... 66
Tabel 4.9. Hasil Perbandingan Persentase Nilai Modul Pengguna SIA Kemahasiswaan ... 73
Tabel 4.10. Hasil Perbandingan Persentase Nilai Modul Pengguna SIA DPA .... 74
xvii
Tabel 4.12. Analisa Hasil Pengujian Modul Mahasiswa ... 77
Tabel 4.13. Analisa Hasil Pengujian Modul Dosen Pembimbing Akademik
(DPA) ... 81
Tabel 4.14. Analisa Hasil Pengujian Modul Kepala Program Studi (Kaprodi) .... 83
Tabel 4.15. Analisa Hasil Persentase nilai modul pengguna – Mahasiswa ... 85
Tabel 4.16. Analisa Hasil Persentase nilai modul pengguna – Dosen Pembimbing
Akademik (DPA) ... 86
Tabel 4.17. Analisa Hasil Persentase nilai modul pengguna – Kepala Program
xviii
DAFTAR LAMPIRAN
Lampiran I. Surat Penelitian ... 95
Lampiran II. Item-item Kuesioner. ... 99
Lampiran III. Data Penelitian. ... 138
Lampiran IV. Hasil Analisa dan Pengujian... 153
BAB I
PENDAHULUAN
1.1. Latar Belakang
Aktifitas manusia dalam melakukan pekerjaan telah berubah pesat
dengan adanya dukungan suatu perangkat lunak. Hal ini disebabkan
perangkat lunak mampu memberikan kemudahan dan kenyamanan bagi
penggunanya. Oleh sebab itu telah banyak dikembangkan berbagai jenis
perangkat lunak yang mampu mendukung aktifitas manusia. Perangkat
lunak banyak dijumpai di sekolah, perusahaan, instansi-instansi
pemerintah serta usaha-usaha lainnya sesuai dengan fungsi dan kegunaan
dari perangkat lunak yang digunakan. Akan tetapi tidak sedikit perangkat
lunak yang tidak sesuai dengan keinginan penggunanya. Seperti halnya
tampilan perangkat lunak (interface) yang tidak sesuai, penggunaan fungsi-fungsi dan input-output yang salah dan sebagainya. Hal ini
dipengaruhi karena kurang adanya pengujian perangkat lunak untuk
mengukur sejauh mana keberhasilan perangkat lunak yang dikeluarkan.
Berbagai macam pengujian terhadap perangkat lunak telah
diciptakan dan dirancang oleh para peneliti teknologi. Salah satu metode
pengujian yang dihasilkan adalah pengujian black box. Pengujian black box merupakan salah satu metode pengujian perangkat lunak yang terbatas
pada suatu interface yang tersaji tanpa pengujian lebih detail ke dalam
fungsional perangkat lunak, sehingga memungkinkan perekayasa
perangkat lunak mendapatkan serangkaian kondisi input yang sepenuhnya
menggunakan semua persyaratan fungsional untuk suatu program.
Pengujian black box cenderung untuk menemukan kesalahan-kesalahan
fungsi-fungsi yang tidak benar atau hilang, kesalahan interface, kesalahan
dalam struktur data atau akses database eksternal, kesalahan kinerja atau
performansi, serta inisialisasi dan kesalahan terminasi. Dalam pengujian
black box ini ada 4 hal yang perlu diukur yaitu : Pengujian Graph-based,
Equivalence Partitioning (Partisi Ekuivalensi), Boundary Value Analysis
(Analisis Nilai Batas) serta Comparison Testing (Pressman, 2005).
Metode pengujian black box ini telah banyak menghasilkan analisa yang menyatakan bahwa perangkat lunak tidak secara keseluruhan
menghasilkan produk yang sesuai dengan persyaratan fungsional. Hal
tersebut telah dilakukan oleh Setiawan (2011) dalam pengujiannya
terhadap perangkat lunak EXELSA dan berhasil menemukan
kesalahan-kesalahan yang terjadi pada perangakat lunak tersebut. Menindaklanjuti
keberhasilan yang telah dilakukan oleh Setiawan (2011), metode
pengujian black box akan digunakan pula pada perangkat lunak BRS Online.
BRS Online merupakan salah satu produk perangkat lunak yang
ada di Universitas Sanata Dharma yang memiliki fungsi untuk melayani
pengambilan rencana studi mahasiswa melalui akses intranet. BRS Online
pengembangan sistem menjadi lebih terstruktur dan modern dalam hal
desain maupun implementasinya. Selain bisa melakukan perencanaan
studi, mahasiswa juga mampu melihat transkrip nilai, jumlah SKS dan
mata kuliah yang telah ditempuh selama menjadi mahasiswa Universitas
Sanata Dharma. Meskipun pengembangan sistem telah dilakukan, masih
banyak dijumpai ketidaksesuaian baik input-output maupun fungsi-fungsi
yang terdapat pada perangkat lunak tersebut. Oleh karena itu perlu
dilakukan pengujian yang mampu mengungkap kesalahan yang ada. Salah
satu metode pengujian yang dapat digunakan adalah metode pengujian
black box.
Dari permasalahan-permasalahan perangkat lunak serta teori
analisis yang telah dijabarkan, maka penulis akan membahas tentang
Analisis dan Pengujian Perangkat Lunak dengan Metode Black Box,
Studi Kasus BRS Online Universitas Sanata Dharma. Pertimbangan
dipilihnya perangkat lunak BRS Online di Universitas Sanata Dharma
dikarenakan perangkat lunak tersebut selalu digunakan oleh segenap
mahasiswa dan fakultas dalam mengisi KRS setiap semesternya. Hasil
akhir penelitian ini adalah sejauh mana metode black box mampu diuji untuk mengetahui kesalahan-kesalahan dalam perangkat lunak BRS
Online. Hasil tersebut dapat digunakan oleh BAPSI untuk melakukan
1.2. Rumusan Masalah
Dari latar belakang masalah yang telah dikemukakan, studi ini
akan menjawab masalah berikut :
1. Seberapa efektif metode black box dapat digunakan untuk menguji
perangkat lunak BRS Online ?
2. Sejauh mana metode black box mampu mengetahui
kesalahan-kesalahan perangkat lunak BRS Online Universitas Sanata Dharma?
1.3. Tujuan
Beberapa tujuan pengujian sistem perangkat lunak adalah sebagai
berikut (Perry, 1995) :
1. Menilai apakah perangkat lunak yang dikembangkan telah memenuhi
kebutuhan pemakai.
2. Menilai apakah tahap pengembangan perangkat lunak telah sesuai
dengan metodologi yang digunakan.
3. Membuat dokumentasi hasil pengujian yang menginformasikan
kesesuaian perangkat lunak yang diuji dengan spesifikasi yang telah
ditentukan.
Selain itu, tujuan dari pengujian sistem dengan menggunakan metode
Black Box pada BRS Online di Universitas Sanata Dharma untuk menemukan kesalahan berupa :
a. Fungsi-fungsi yang tidak benar atau hilang
c. Kesalahan dalam struktur data atau akses database eksternal.
d. Kesalahan kinerja atau performansi
e. Inisialisasi dan kesalahan terminasi
1.4. Manfaat
Manfaat yang ingin dicapai dalam penelitian ini dibagi menjadi 2
(dua) yaitu :
a. Manfaat Teoritis
Penelitian ini diharapkan dapat memberikan evaluasi apakah
fungsi-fungsi atau obyek-obyek sesuai dengan keluaran yang diharapkan atau
tidak dalam sistem BRS Online di Universitas Sanata Dharma.
b. Manfaat Praktis
Hasil penelitian dapat digunakan oleh BAPSI untuk mengetahui
kesalahan-kesalahan yang tertera pada sistem mengenai fungsi-fungsi
atau obyek-obyek yang digunakan dalam sistem BRS Online, sehingga
BAPSI dapat melakukan pembenahan terhadap perangkat lunak ini.
1.5. Batasan Masalah
Dari identifikasi masalah yang terpapar di atas diperoleh gambaran
permasalahan yang sangat luas. Namun menyadari keterbatasan waktu dan
kemampuan, maka penulis memandang perlu memberi batasan masalah
1. Pengujian dilakukan berdasarkan fungsional yang terdapat pada Sistem
BRS Online tanpa mengetahui langkah program di dalamnya.
2. Para responden dalam pengujian ini adalah mahasiswa, Dosen
Pembimbing Akademik (DPA) serta Kepala Program Studi Universitas
Sanata Dharma.
3. Pengujian menggunakan metode Black Box pada perangkat lunak ini terbatas pada 3 (tiga) hal, yaitu :
a. Pengujian graph-based
b. Equivalence Partitioning (Partisi Ekuivalensi)
c. Boundary Value Analysis (Analisis Nilai Batas)
Penggunaan metode pengujian tersebut disesuaikan dengan hasil
perencanaan dan perancangan terhadap perangkat lunak.
1.6. Sistematika Penulisan
I Pendahuluan
Bagian ini menguraikan tentang latar belakang, rumusan masalah,
manfaat, tujuan, batasan masalah, serta sistematika penulisan
proyek akhir.
II Tinjauan Pustaka
Bagian ini menguraikan landasan teori yang telah ada dan
berkembang untuk digunakan pada penelitian sebagai
pengembangan hipotesis dan mampu menjelaskan permasalahan
III Rancangan Bangun Penelitian
Bagian ini menguraikan tentang data yang akan digunakan dalam
pengujian atau penelitian yang akan dilakukan.
IV Hasil dan Analisa
Bagian ini menguraikan tentang hasil dan analisa dari penelitian
atau pengujian hipotesis menggunakan data yang diolah sesuai
dengan model empiris yang sudah diterapkan.
V Penutup
Bagian ini berisi tentang ringkasan, kesimpulan, keterbatasan serta
saran – saran perbaikan yang akan dikembangkan untuk
BAB II
TINJAUAN PUSTAKA
Bab ini berisi uraian tentang landasan penelitian ini, yang secara
garis besarnya tentang perangkat lunak, Sistem Informasi Akademik
(SIA), Definisi pengujian perangkat lunak serta Black Box.
2.1 Perangkat Lunak
Penggunaan perangkat lunak sampai saat ini telah banyak kita
jumpai dalam berbagai aspek kehidupan manusia. Hal tersebut
dikarenakan perangkat lunak mampu mendukung aktifitas manusia itu
sendiri. Sekolah, instansi-instansi pemerintahan, swalayan dan perusahaan
pun menggunakan perangkat lunak untuk memudahkan suatu pekerjaan.
Agar dapat mengetahui lebih jelas tentang suatu perangkat lunak itu
sendiri serta karakteristik aplikasi perangkat lunak yang tersedia maka
akan dibahas pada bagian ini.
2.1.1. Definisi Perangkat Lunak
Para ilmuwan mengartikan perangkat lunak dari berbagai sudut
pandang yang berbeda, salah satunya adalah Pressman (2005) berpendapat
bahwa :
a) Perintah (program komputer) yang bila dieksekusi memberikan fungsi
b) Struktur data yang memungkinkan program memanipulasi informasi
secara proporsional.
c) Dokumen yang menggambarkan operasi dan kegunaan dari suatu
program.
2.1.2. Pengertian Rekayasa Perangkat Lunak
Beberapa pengertian perangkat lunak menurut para ahli rekayasa
adalah sebagai berikut:
Menurut Stephen R. Schach (1990) : Rekayasa perangkat lunak adalah
sebuah disiplin untuk menghasilkan perangkat lunak yang bebas dari
kesalahan dan pengolahan data yang tepat serta memuaskan keinginan
pemakai.
Menurut Fritz Bauer (1968) : Rekayasa perangkat lunak adalah
pengembangan dan penggunaan prinsip rekayasa dalam rangka
memperoleh perangkat lunak yang dapat dipercaya dan dapat bekerja serta
efisien pada mesin nyata.
Menurut IEEE 610.12 (1990) : Rekayasa perangkat lunak adalah sebuah
studi dan aplikasi dari sebuah pendekatan kuantifiabel, disiplin, dan
sistematis untuk pengembangan, operasi dan pemeliharaan perangkat
lunak yang kesemuanya itu merupakan aplikasi rekayasa yang berkaitan
dengan perangkat lunak.
Kristianto (2004) di dalam bukunya mengemukakan bahwa dari
pengertian tersebut, arti yang diberikan Fritz Bauer (1968) sangat sesuai
Stephen R. Schach (1990) terbatas pada menanggulangi kekurangan yang
terjadi jika tidak menerapkan rekayasa perangkat lunak. IEEE 610.12
memberikan pengertian yang paling baik dalam menyampaikan wujud dari
rekayasa perangkat lunak.
Perangkat lunak merupakan ilmu yang penting untuk diperdalam
karena teknologi ini memberikan stabilitas, kontrol, dan organisasi
aktifitas. Beberapa tujuan yang dilakukan rekayasa perangkat lunak antara
lain (Kristianto, 2004) :
1. Dapat membangun software yang benar (right software) dan software
yang tepat (correct).
2. Menciptakan sistem pengelolaan dan pemeliharaan software yang
sesuai.
2.1.3. Karakteristik perangkat lunak
Perangkat lunak lebih merupakan elemen logika dan bukan
merupakan elemen sistem fisik. Dengan demikian, perangkat lunak
memiliki ciri yang berbeda dari perangkat keras (Pressman, 2005) :
1. Perangkat lunak dibangun dan dikembangkan serta tidak dibuat dalam
bentuk yang klasik.
Banyak kesamaan di antara pabrik perangkat keras dan perangkat
lunak, tetapi aktivitas keduanya secara mendasar sangat berbeda.
Dalam kedua aktivitas tersebut, kualitas yang tinggi dicapai melalui
perancangan yang baik tetapi di dalam fase pembuatan perangkat
disesuaikan dengan perangkat lunak. Kedua aktivitas tersebut
tergantung pada manusia, tetapi hubungan antara penerapan yang
dilakukan manusia dengan usaha yang diperoleh sangat berbeda.
Kedua aktivitas tersebut membutuhkan konstruksi sebuah produk,
tetapi pendekatan yang digunakan berbeda.
Dibangunnya perangkat lunak ini tidak menyatakan bahwa adanya
perkembangan perangkat lunak dan pembuatan perangkat keras itu
ekivalen. Terlebih lagi, perusahaan perangkat lunak mengijinkan
pemakaian alat-alat yang diotomatisasi untuk pengembangan
perangkat lunak.
2. Perangkat lunak tidak pernah usang.
Perangkat lunak tidak rentan terhadap pengaruh lingkungan yang
merusak sehingga menyebabkan perangkat lunak menjadi usang.
Kesalahan-kesalahan yang tidak dapat ditemukan akan menyebabkan
tingkat kegagalan menjadi sangat tinggi pada awal hidup program.
Tetapi hal tersebut dapat diperbaiki dan diharapkan tidak lagi
ditemukan kesalahan yang lain.
Aspek lain dari keusangan menunjukkan perbedaan antara perangkat
keras dan perangkat lunak. Bila komponen suatu perangkat telah
usang, komponen dapat diganti dengan suku cadangnya. Namun tidak
ada suku cadang bagi perangkat lunak. Setiap kegagalan perangkat
mana rancangan diterjemahkan ke dalam kode mesin yang dapat
dieksekusi.
3. Sebagian besar perangkat lunak dibuat secara costum-built, serta tidak dapat dirakit dari komponen yang sudah ada.
Para perancang perangkat lunak tidak diberi fasilitas seperti halnya
perangkat keras. Dengan sedikit pengecualian, tidak ada katalog
komponen dalam perangkat lunak. Memang memungkinkan untuk
memesan perangkat lunak secara terpisah, tetapi tetap merupakan satu
kesatuan yang lengkap, bukan sebagai komponen yang dapat
dipasangkan ke dalam program-program baru. Jika adanya pemesanan
perangkat yang terpisah-pisah memungkinkan adanya penggunaan
yang tidak sesuai dengan harapan yang diinginkan sehingga hanya
menambahkan permasalahan yang ada.
2.1.4. Aplikasi Perangkat Lunak
Perangkat lunak dapat diaplikasikan ke berbagai situasi di mana
serangkaian langkah prosedural (seperti algoritma) telah didefinisikan
(pengecualian yang didapat pada aturan ini adalah sistem pakar dan
perangkat lunak jaringan syaraf cerdas buatan). Cukup sulit untuk
menentukan kategori umum dalam aplikasi perangkat lunak. Ketika
kompleksitas perangkat lunak mulai muncul, maka penggolongan yang
rapi menjadi hilang. Area perangkat lunak berikut ini menunjukkan
a. Perangkat lunak Sistem
b. Perangkat lunak Real-Time
c. Perangkat lunak Bisnis
d. Perangkat lunak Teknik dan Ilmu Pengetahuan
e. Embedded software
f. Perangkat lunak Komputer Personal
g. Perangkat lunak Kecerdasan Buatan
2.1.5. Jenis kerusakan dalam perangakat lunak
Perry (1995) mengemukakan berbagai macam kerusakan yang
dapat ditemukan di dalam perangkat lunak saat melakukan pengujian.
Kerusakan tersebut berdasarkan pada :
1. Kerusakan (defect), berasal dari spesifikasi produk yang berarti bahwa di dalam proses pembuatan perangkat lunak terjadi kesalahan
pelaksanaan lapangan yang tidak memahami hasil pekerjaan para
analis.
2. Variasi, berasal dari keinginan costumer atau user yang berarti bahwa
di dalam proses perencanaan perangkat lunak, terdapat keinginan
costumer yang tidak dimasukkan ke dalam dokumen SRS atau
walaupun keinginan costumer tersebut tercantum di dalam SRS, namun terabaikan karena kesalahan dalam mengimplementasikan
Jenis – jenis kerusakan (defect) yang terdapat di dalam perangkat lunak : 1. Mistake (Kekeliruan) : suatu aksi manusia yang menyebabkan
hasil keluaran yang tidak benar.
2. Faults (kekurangan) : suatu salah langkah, baik proses atau
definisi data dalam program komputer.
3. Failure (kegagalan) : suatu hasil keluaran yang salah akibat dari
fault (contoh : crash)
4. Error (kesalahan) : suatu hasil keluaran yang tidak dapat di eksekusi.
5. Wrong (ketidakbenaran) : spesifikasi telah diimplementasikan secara salah (variances form user).
6. Missing (kehilangan) : suatu kebutuhan tertentu yang tidak
dimasukkan ke dalam produk (Variance form product evaluation) atau terdapat kebutuhan yang baru ada ketika produk selesai dibuat.
2.2. Sistem Informasi Akademik (SIA)
Sistem Informasi Akademik merupakan salah satu sarana penunjang
dalam melaksanakan studi mahasiswa. Selain itu, Sistem Informasi
Akademik ini memiliki peran penting dalam memajukan suatu lembaga
pendidikan khususnya Universitas Sanata Dharma. Hal mengenai Sistem
2.2.1. Penjelasan Sistem Informasi Akademik (SIA)
Sistem Informasi Akademik atau yang lebih dikenal dengan SIA
merupakan suatu perangkat lunak yang menangani masalah yang berkaitan
dengan aktifitas akademik universitas seperti halnya pengambilan rencana
studi, administrasi, jadwal kuliah, beasiswa, transkrip nilai semester.
Abdul Kadir (2003) menyatakan bahwa sistem layanan akademis berbasis
Web dapat memungkinkan mahasiswa memperoleh data-data akademis
atau bahkan dapat mendaftarkan mata kuliah yang diambil pada semester
baru. SIA ini dikelola oleh BAPSI yaitu Biro Administrasi Perencanaan
dan Sistem Informasi. Untuk membangun SIA ini BAPSI tidak bekerja
sendiri namun saling berkoordinasi dengan biro-biro lainnya seperti BAA,
sekertariat masing- masing fakultas dan jurusan serta para dosen.
Sistem Informasi Akademik (SIA) ini dibangun untuk
memudahkan mahasiswa dalam mengakses layanan yang tersedia
sehingga mahasiswa cepat dalam memperoleh informasi-informasi
ter-update yang telah tersedia. Dengan demikian SIA mampu membantu para karyawan untuk bekerja secara optimal tanpa proses yang lama untuk
melayani mahasiswa dalam perolehan informasi atau apapun yang
berkaitan dengan nilai akademik.
2.2.2. Penjelasan BRS Online
BRS Online merupakan salah satu bagian dari Sistem Informasi
mahasiswa melalui akses intranet. BRS Online telah didirikan sekitar
tahun 1999 dan telah mengalami regenerasi pengembangan sistem menjadi
lebih terstruktur dan modern dalam hal desain maupun implementasinya.
Selain bisa melakukan rencana studi, mahasiswa juga mampu melihat
transkrip nilai, jumlah SKS dan mata kuliah yang telah ditempuh selama
menjadi mahasiswa Universitas Sanata Dharma.
BRS Online memudahkan dalam penyusunan rencana studi
mahasiswa, sehingga waktu yang dibutuhkan dalam penyusunan studi
mahasiswa menjadi lebih cepat. Secara tidak langsung BRS Online juga
menjadikan mahasiswa mampu menggunakan fasilitas teknologi yang
dimiliki oleh universitas.
2.3. Pengujian Perangkat Lunak
Pada dasarnya pengujian suatu perangkat lunak harus dilakukan
untuk mengetahui mutu dan kualitas suatu perangkat lunak tersebut saat
sebelum ataupun sesudah digunakan oleh user. Pengujian dimaksudkan
untuk mengetahui sejauh mana tingkat keberhasilan produk (perangkat
lunak) dihasilkan, apakah terdapat kesalahan atau tidak pada input-output
perangkat lunak dan lain sebagainya. Berkaitan tentang penjelasan di atas
terlebih dahulu akan diuraikan penjabaran tentang suatu pengujian
2.3.1. Definisi Pengujian Perangkat Lunak
Pengujian perangkat lunak adalah elemen kritis dari jaminan
kualitas perangkat lunak dan merepresentasikan kajian pokok dari
spesifikasi, desain dan pengkodean (Pressman, 2005). Menurut Setiawan
(2011) definisi pengujian perangkat lunak adalah proses untuk mencari
kesalahan pada setiap item perangkat lunak, mencatat hasilnya,
mengevaluasi setiap aspek pada setiap komponen sistem dan mengevaluasi
semua fasilitas dari perangkat lunak yang dikembangkan. Pada intinya
proses pengujian bersifat untuk menemukan kerusakan (defect) yang
terdapat di dalam suatu perangkat lunak agar dapat ditindak lanjuti
menjadi lebih baik.
2.3.2. Sasaran Pengujian
Beberapa aturan yang dapat digunakan sebagai langkah pendukung
dalam pengujian perangkat lunak adalah sebagai berikut (Myers, 2010) :
1. Pengujian adalah proses menjalankan suatu program dengan maksud
menemukan kesalahan.
2. Test case yang baik adalah test case yang memiliki kemungkinan
tinggi untuk menemukan kesalahan yang belum pernah ditemukan
sebelumnya.
3. Pengujian yang sukses adalah pengujian yang mengungkap semua
kesalahan yg belum pernah ditemukan sebelumnya.
Perry (1995) menyimpulkan bahwa suatu pengujian yang baik
tetapi juga untuk dapat menemukan data uji yang dapat menemukan
kesalahan secara lebih teliti
2.3.3. Verifikasi dan Validasi
Pengujian perangkat lunak adalah satu elemen dari topik yang lebih
luas yang sering diacu sebagai verifikasi dan validasi (V&V). Memahami
hal tersebut Pressman (2005) menjabarkan bahwa :
1. Verifikasi mengacu pada suatu rangkaian aktivitas yang memastikan
bahwa perangkat lunak secara tepat mengimplementasikan suatu
fungsi tertentu.
2. Validasi mengacu pada serangkaian aktivitas yang berbeda yang
memastikan bahwa perangkat lunak yang dibangun dapat ditelusuri ke
persyaratan user.
Definisi dari verifikasi dan validasi meliputi berbagai aktivitas yang
kita rujuk sebagai jaminan kualitas perangkat lunak (SQA). Berikut
merupakan serangkaian komponen untuk mencapai suatu kualitas
(Pressman, 2005).
Software Quality Assurance (SQA) dimulai dengan sekumpulan alat dan metode teknis yang membantu analis untuk mendapatkan
spesifikasi yang berkualitas tinggi dan bagi perancang untuk merancang
dengan kualitas tinggi pula. Setelah spesifikasi dan desain dibuat,
ditetapkan kualitasnya dengan melakukan review teknis formal. Pengujian
perangkat lunak mengkombinasikan langkah-langkah strategi dengan
metode rancangan test-case yang dapat menjamin pendeteksian kesalahan
secara efektif. Jika terdapat standar yang formal, berarti harus dapat
dijamin bahwa standar tersebut diikuti. Pengontrolan perubahan dilakukan
selama pembuatan perangkat lunak dan pada tahap pemeliharaan. Setiap
perubahan dapat menyebabkan kesalahan dan efek lain yang akan
menyebabkan kesalahan juga. Pengukuran terhadap perangkat lunak
mencakup pengukuran secara manajemen dan teknis. Penyimpanan hasil
dari review, audit, pengontrolan perubahan, pengujian dan lain-lain
sebagai bagian dari record historis untuk suatu proyek dan
didesiminasikan kepada para staf pengembang sebagai dasar untuk ketahui
dan ditindaklanjuti.
Miller (1981) menghubungkan pengujian perangkat lunak dengan
jaminan kualitas menyatakan bahwa motivasi yang mendasari pengujian
program adalah untuk menentukan kualitas perangkat lunak dengan
metode-metode yang dapat secara ekonomis dan efektif diaplikasikan pada
Pada umumnya proses verifikasi dan validasi mempunyai 2 (dua)
sasaran utama (Perry, 1995) yaitu :
1. Menemukan kekurangan dalam sebuah sistem.
2. Memperkirakan apakah sistem berguna dan dapat digunakan atau
tidak dalam situasi operasional.
3. Verifikasi dan validasi harus memberikan kepastian bahwa software
sesuai dengan tujuannya.
Verifikasi memiliki 2 (dua) kegiatan yang dapat dilakukan dalam
pengujian perangkat lunak (Perry, 1995) yaitu :
1. Verifikasi Statik, yaitu berhubungan dengan analisis representasi
sistematik untuk menemukan masalah, biasa disebut Software inspection.
2. Verifikasi Dinamis, yaitu berhubungan dengan pelaksanaan dan
memperhatikan perilaku produk, biasa disebut Software testing.
2.3.4. Strategi Pengujian
Strategi pengujian perlu dilakukan untuk merancang suatu
tahapan-tahapan dalam perencanaan pengujian yang akan dilakukan. Proses ini
juga dimaksudkan untuk memperhitungkan estimasi waktu, upaya dan
sumber daya yang diperlukan sehingga perencanaan dapat dilakukan
dengan baik.
Strategi pengujian perangkat lunak dapat digambarkan sebagai proses
Gambar 2.2. Strategi Pengujian
Konteks spiral di atas dapat dijabarkan sebagai berikut :
a. Tes unit dilakukan pada saat diimplementasikannya sebuah perangkat
lunak di dalam kode sumber.
b. Tes integrasi fokusnya terletak pada desain dan konstruksi arsitektur
perangkat lunak.
c. Tes validasi dilakukan sebagai persyaratan dibangunnya perangkat
lunak dan kemudian dianalisis validasinya terhadap perangkat lunak
yang telah dikonstuksi.
d. Tes sistem dilakukan terhadap perangkat lunak dan elemen sistem
yang lain diuji secara keseluruhan.
Dalam pengujian suatu perangkat lunak, proses berjalan sepanjang
streamline yang memperluas ruang lingkup pengujian lewat
masing-masing urutan proses.
2.3.5. Testabilitas
Menurut James Bach (1994), testabilitas perangkat lunak secara
sederhana adalah seberapa mudah sebuah program komputer dapat diuji.
penguji untuk membuatnya menjadi mudah. Lakukan proses pendataan
mengenai masalah-masalah desain yang ada, fungsi-fungsi sebagai
input-output dan lain sebagainya untuk membantu dalam proses pengujian.
Beberapa karakteristik suatu perangkat lunak yang dapat diuji (James
Bach, 1994) yaitu :
1. Operabilitas, semakin baik perangkat lunak bekerja, akan membuat
perangkat lunak dites dengan lebih efisien.
2. Observabilitas, apa yang anda lihat adalah apa yang anda uji.
3. Kontrolabilitas, semakin baik kita dapat mengontrol perangkat lunak
semakin banyak pengujian yang dapat diotomatisasi dan dioptimalkan.
4. Dekomposabilitas, dengan mengontrol ruang lingkup pengujian kita
dapat lebih cepat mengisolasi masalah dan melakukan pengujian ulang
yang lebih baik.
5. Kesederhanaan, semakin sedikit yang diuji semakin cepat kita
melakukannya.
6. Stabilitas, semakin sedikit perubahan semakin sedikit gangguan
pengujian.
7. Kemampuan dipahami, semakin banyak informasi yang dimiliki,
kita akan dapat melakukan tes yang lebih baik.
Menurut Falk, dkk (2003) atribut-atribut dari pengujian yang baik
adalah sebagai berikut :
1. Pengujian yang baik memiliki probabilitas yang tinggi untuk
2. Pengujian yang baik tidak redundan.
3. Pengujian yang baik tidak boleh terlalu sederhana atau terlalu
kompleks.
2.3.6. Tujuan Pengujian
Penentuan tujuan dari suatu pengujian perlu dilakukan untuk
menentukan sasaran apa yang ingin dicapai dari suatu proses pengujian
tersebut. Beberapa tujuan dilakukannya pengujian suatu perangkat lunak
adalah sebagai berikut (Perry, 1995) :
1. Menilai apakah perangkat lunak yang dikembangkan telah memenuhi
kebutuhan pemakai.
2. Menilai apakah tahap pengembangan perangkat lunak telah sesuai
dengan metodologi yang digunakan.
3. Membuat dokumentasi hasil pengujian yang menginformasikan
kesesuaian perangkat lunak yang diuji dengan spesifikasi yang telah
ditentukan.
Setelah mengetahui tujuan yang akan dicapai dari pengujian suatu
perangkat lunak, maka dapat dijabarkan hal-hal yang perlu dilakukan saat
pengujian yaitu (Perry, 1995) :
1. Mengidentifikasi dan menemukan beberapa kesalahan yang mungkin
ada dalam perangkat lunak yang diuji.
2. Setelah perangkat lunak diperbaiki, identifikasi ulang kesalahan dan
3. Membentuk tes yang efisien dan efektif dengan anggaran dan jadwal
terbatas.
4. Mengumpulkan daftar kesalahan untuk digunakan dalam daftar
pencegahan kesalahan (tindakan corrective dan preventive).
2.4. Black Box
Hasil teknologi khususnya perangkat lunak telah mengalami
tingkat kemajuan yang sangat signifikan penggunaannya dan digunakan
dalam berbagai lingkup apapun baik perusahan maupun sekolah. Namun
tidak terlepas dari hal itu suatu perangkat lunak haruslah sesuai dengan
desain yang telah ditentukan sehingga perlu dilakukan pengujian sebelum
perangkat lunak tersebut digunakan. Salah satu metode pengujian
perangkat lunak adalah Black Box. Berkaitan tentang gambaran umum
black box akan diuraikan pada bagian ini.
2.4.1. Pengujian Black Box
Pengujian Black Box merupakan salah satu metode pengujian
suatu perangkat lunak di mana pengujiannya hanya terbatas pada suatu
interface yang tersaji tanpa pengujian lebih detail ke dalam struktur
program perangkat lunak. Pengujian ini berfokus pada persyaratan
fungsional perangkat lunak, sehingga memungkinkan perekayasa
perangkat lunak mendapatkan serangkaian kondisi input yang sepenuhnya
Pengujian black box bukanlah solusi alternatif dari pengujian white box. Akan tetapi pengujian ini merupakan pendekatan komplementer yang
kemungkinan besar mampu mengungkap kesalahan daripada metode
pengujian white box (Pressman, 2005).
Dalam pengujian black box akan dilakukan eksekusi terhadap
fungsi-fungsi yang tersedia pada perangkat lunak dan diamati hasil keluaran
yang diperoleh kemudian akan dicek apakah hasil tersebut telah sesuai
dengan yang diharapakan atau tidak. Pengujian black box bertujuan untuk menemukan kesalahan berikut (Perry, 1995) :
1. Fungsi-fungsi yang tidak benar atau hilang.
2. Kesalahan interface.
3. Kesalahan dalam struktur data atau akses database eksternal.
4. Kesalahan kinerja atau performansi.
5. Inisialisasi dan kesalahan terminasi.
Dalam melakukan pengujian black box dapat dilakukan 3 hal yang
terdiri dari (Laurie, 2006) :
1. Pengujian graph-based.
2. Equivalence Partitioning (Partisi Ekuivalensi). 3. Boundary Value Analysis (Analisis Nilai Batas).
2.4.2. Graph Based Testing
diuji. Langkah pertama dalam pengujian Black Box adalah memahami obyek yang dimodelkan dalam perangkat lunak dan menentukan hubungan
di antara obyek-obyek tersebut. Hal ini dapat dilakukan dengan cara
membuat suatu grafik dari obyek-obyek yang penting. Langkah selanjutnya
menentukan sederetan pengujian yang membuktikan bahwa semua obyek
tersebut memiliki hubungan yang sesuai satu dengan yang lainnya. Jika
diamati melalui grafik obyek-obyek yang telah dibuat maka kesalahan dapat
ditemukan (Smirnov, 2002).
(a)
(b)
Langkah gambar 2.3 memudahkan perekayasa dalam
merepresentasikan obyek-obyek, link yang merepresentasikan hubungan
antar obyek, node weight yang menggambarkan properti dari suatu simpul (nilai data atau tingkah laku keadaan), link weight yang menggambarkan
karakteristik link, link paralel yang menggambarkan hubungan yang berbeda yang dibangun antar simpul, serta link simetris yang menggambarkan hubungan dua arah antara dua obyek.
Pada link weight terdapat jenis tiga pola, yaitu :
1. Transitivitas, yaitu hubungan antara tiga obyek atau lebih yang
menentukan bagaimana pengaruh hubungan tersebut menyebar pada
obyek yang ditentukan.
2. Simetris, yaitu hubungan antara dua obyek secara dua arah.
3. Refleksif, yaitu hubungan yang mengarah pada node itu sendiri atau
loop null.
Beizer (1990), menggambarkan sejumlah metode pengujian
behavioral yang dapat menggunakan grafik :
1. Transaction Flow Modeling (Pemodelan Aliran Transaksi), metode ini
menggunakan node sebagai representasi langkah pada transaksi, dan
link sebagai representasi hubungan logika antara langkah-langkah
tersebut.
representasi transisi. Statechart atau state transition diagram dapat digunakan untuk membuat graph.
3. Data Flow Modeling (Pemodelan Aliran Data), metode ini menggunakan node sebagai representasi obyek data dan link sebagai
transformasi dari satu obyek data ke obyek data yang lain.
4. Timing Modeling (Pemodelan Pemilihan Waktu), metode ini menggunakan node sebagai representasi obyek program dan link
sebagai hubungan sekuensial antara obyek.
2.4.3. Equivalence Partitioning (Partisi Ekuivalensi)
Equivalence partioning merupakan metode ujicoba black box yang membagi domain input dari program menjadi beberapa kelas data.
Equivalence partioning berusaha untuk mendefinisikan kasus pengujian yang menemukan sejumlah jenis kesalahan, dan mengurangi jumlah kasus
pengujian yang harus dibuat. Kasus pengujian yang didesain untuk
Equivalence partioning berdasarkan pada evaluasi dari ekuivalensi jenis atau class untuk kondisi input. class-class yang ekuivalen
merepresentasikan sekumpulan keadaan valid dan invalid untuk kondisi
input. Suatu kondisi input dapat berupa harga numeris, rentan harga,
serangkaian harga khusus, atau kondisi boolean (Perry, 1995).
Kelas ekivalensi dapat ditentukan sesuai dengan pedoman sebagai
1. Bila kondisi input menentukan suatu range, maka satu kelas ekivalensi valid dan dua invalid ditentukan.
2. Bila suatu kondisi input membutuhkan suatu harga khusus, maka satu
kelas ekivalensi valid dan dua yang invalid ditentukan.
3. Bila suatu kondisi input menentukan anggota suatu himpunan, maka
satu kelas ekivalensi valid dan dua yang invalid ditentukan.
4. Bila suatu kondisi input adalah boolean, maka satu kelas ekivalensi
valid dan satu yang invalid ditentukan.
Sebagai kasus (Pressman, 2005), perhatikan data yang dijaga
sebagai bagian dari suatu aplikasi perbankan otomatis. Perangkat lunak
yang dipasok untuk aplikasi perbankan menerima data dalam bentuk :
Kode area – kosong atau tiga nomor digit
Prefiks– tiga nomor digit tidak dimulai dengan 1 atau 0
Sufik– empat nomor digit
Password– enam nilai alfanumeris digit
Perintah – cek, deposit, bayar pajak dan lain sebagainya.
Kondisi input yang sesuai dengan masing-masing elemen data untuk
aplikasi perbankan dapat ditentukan sebagai :
Kode area : kondisi input, boolean - kode area mungkin atau
mungkin tidak ada kondisi Input, range - nilai yang ditentukan antara 200 dan 999, dengan pengecualian
khusus
dengan tanpa digit 0.
Sufiks : kondisi input, boolean - password dapat ada atau tidak
ada kondisi input harga - antrian enam karakter.
Perintah : kondisi input, himpunan - berisi perintah yang sudah
ditulis di atas
2.4.4. Boundary Value Analysis (Analisis Nilai Batas)
Boundary Value Analysis merupakan teknik desain proses yang melengkapi Equivalence Partitioning. Boundary Value Analysis lebih
mengarah kepada pemilihan test case pada edge dari kelas bukan pada kondisi input.
Dalam banyak hal, pedoman untuk Boundary Value Analysis sama
dengan yang diberikan untuk Equivalence Partitioning (Pressman, 2005) yaitu :
1. Bila suatu kondisi input mengkhususkan suatu range dibatasi oleh nilai a dan b, maka test case harus didesain dengan nilai a dan b, persis di atas dan di bawah a dan b, secara bersesuaian.
2. Bila suatu input mengkhususkan sejumlah nilai, maka test case harus dikembangkan dengan menggunakan jumlah minimum dan
maksimum. Nilai tepat di atas dan di bawah minimum dan maksimum
3. Pedoman 1 dan 2 diaplikasikan ke kondisi output, output harus menghasilkan jumlah minimum (dan maksimum) dari entri tabel yg
diijinkan.
4. Bila struktur data program telah memesan suatu batasan, maka
BAB III
RANCANG BANGUN PENELITIAN
Bab ini berisi uraian tentang rancang bangun yang menjadi proses
tahapan penelitian, yang berupa jenis penelitian, obyek penelitian,
identifikasi resiko perangkat lunak, tahap pengujian, modul pengujian,
perolehan data, pendukung pengujian, metode analisa serta estimasi waktu
dan keterlibatan pengguna..
3.1. Jenis Penelitian
Penelitian ini ditujukan untuk mengidentifikasi kesalahan yang
terdapat pada perangkat lunak. Pengujian ini berfokus pada persyaratan
fungsional perangkat lunak, yang memungkinkan perekayasa perangkat
lunak mendapatkan serangkaian kondisi input yang sepenuhnya
menggunakan semua persyaratan fungsional untuk suatu program. Melalui
kondisi-kondisi yang ada maka akan dianalisa proses apa saja yang terjadi
dan apakah sesuai dengan hasil yang diinginkan.
Penelitian ini mencoba untuk mengetahui kriteria-kriteria
kesalahan (Perry,1995) : 1) Fungsi – fungsi yang tidak benar atau hilang,
2) Kesalahan interface, 3) Kesalahan dalam struktur data atau akses
database eksternal, 4) Kesalahan kinerja atau performansi, 5) Inisialisasi
dan kesalahan terminasi, semua hal tersebut diuji dalam satu perangkat
lunak BRS Online. Dalam membantu menemukan kesalahan-kesalahan
(Pressman, 2005) : 1) Pengujian graph-based, 2) Equivalence Partitioning
(Partisi Ekuivalensi), 3) Boundary Value Analysis (Analisis Nilai Batas).
3.2. Obyek Penelitian
Obyek penelitian merupakan suatu atribut atau sifat atau nilai dari
seseorang, terhadap suatu kegiatan yang di mana mempunyai variasi
tertentu yang ditetapkan oleh peneliti untuk dipelajari dan kemudian
ditarik kesimpulannya (Sugiyono, 2009). Obyek penelitian ditentukan
berdasarkan permasalahan yang ditimbulkan oleh suatu sistem yang akan
dianalisa.
Obyek penelitian ini adalah seluruh komponen pembangkit yang
terdapat didalam sistem perangkat lunak BRS Online Universitas Sanata
Dharma. Komponen-komponen tersebut mulai dari interface, tools-tools, database, performansi perangkat lunak, desain dokumentasi. Semua hal
tersebut merupakan suatu rangkaian pengujian dan penelitian apakah
sesuai dengan konsep desain awal sampai perancangan akhir dari
perangkat lunak ini. setiap komponen diuji dan dinilai berdasarkan
persyaratan fungsional suatu perangkat lunak yaitu nilai input dan output
yang diberikan.
3.3. Identifikasi Resiko Perangkat Lunak
Dalam melakukan proses identifikasi resiko saat melakukan
Tujuan dari strategi resiko adalah menciptakan skenario pengujian yang
mampu mengatasi resiko-resiko yang dimiliki oleh perangkat lunak
tersebut. Strategi resiko tidak hanya mengatasi namun menilai dan
mengevaluasi tingkat resiko perangkat lunak yang telah dibangun dan
dikembangkan. Semakin tinggi resiko yang ada maka akan semakin sulit
tingkat pembuatan skenario pengujian serta kasus pengujiannya. Pada
umumnya strategi resiko pengujian dibagi menjadi tiga yaitu (Perry,
1995):
1. Resiko terstruktur (Structural risks) : Resiko-resiko yang berhubungan
dengan aplikasi dan metode yang digunakan untuk pengembangan
sistem. Pada kasus BRS Online, resiko ini berkaitan tentang proses
input-output dan fungsi-fungsi pada perangkat lunak. Metode
pengembangan lebih tertuju pada proses-proses pembuatan BRS
Online (baik pada desain perancangan, desain antarmuka, dan lain
sebagainya).
2. Resiko teknisi (Technical risks) : Resiko-resiko yang berhubungan dengan teknologi yang digunakan untuk membangun dan
mengoperasikan sistem yang dikembangkan. Pada kasus BRS Online,
resiko ini berkaitan tentang kemampuan perangkat pendukung (misal :
komputer, daya listrik) yang membantu dalam proses penggunaan
perangkat lunak.
3. Resiko terukur (Size risks) : Resiko-resiko yang berhubungan dengan
BRS Online,resiko ini berkaitan tentang banyaknya jumlah pengguna
yang dapat mengakses perangkat lunak (batas maksimum rata-rata
penggunaan perangkat lunak).
3.4. Efektifitas Pengujian
Suatu pengujian dikatakan efektif jika metode yang telah
dikembangkan tersebut mampu menemukan permasalahan yang terdapat
di dalam topik yang dibahas serta mampu menemukan solusi-solusi dari
permasalahan tersebut. Namun untuk pengukuran efektifitas secara
langsung terbilang cukup sulit dikarenakan berkaitan dengan faktor dari
pemakainya itu sendiri, sehingga dibutuhkan proses-proses yang menjadi
indikator dalam pengukuran tersebut. Proses-proses itulah yang akan
diperhitungkan dan dibahas sehingga mampu mengungkap bahwa metode
yang digunakan efektif dalam memecahkan permasalahan yang ada.
Dalam kasus ini kita akan mengetahui apakah efektif metode black box
dalam pengujian perangkat lunak SIA-BRS Online terhadap modul-modul
fungsi yang ada dengan perhitungan dari modul-modul tersebut.
3.5. Identifikasi Fungsi Utama Produk
Pada pengujian black box yang akan dilakukan pada perangkat lunak SIA BRS Online baik pada pengguna SIA Kemahasiswaan, SIA
DPA dan SIA Kaprodi terdapat fungsi-fungsi utama yang merupakan
fokus dari diadakannya penelitian ini. Pada SIA Kemahasiswaan terdapat
mahasiswa, jadwal dosen mengajar, kartu rencana studi (KRS), transkrip
nilai, nilai per semester, prediksi matakuliah yang bisa diambil serta
pengelolaan sistem poin mahasiswa, namun selain itu terdapat
fungsi-fungsi tambahan yang akan diuji yaitu login, home, bioadata, daftar
pembayaran, lihat judul tugas akhir, pengecekan matakuliah, daftar tarif
kuliah, history peminjaman buku, pesan, kontribusi, bantuan serta logout.
Pada SIA DPA terdapat fungsi-fungsi utama pokok permasalahan
yaitu jadwal dosen, daftar mahasiswa bimbingan, pengelolaan sistem poin
mahasiswa serta BRS Online. Selain itu terdapat pula fungsi tambahan
yaitu login, home, ganti password, logout mahasiswa, kontribusi, bantuan
serta logout. Pada SIA Kaprodi terdapat fungsi-fungsi utama pokok
permasalahan yaitu daftar dosen, kapasitas kelas matakuliah serta
pengelolaan sistem poin mahasiswa. Untuk fungsi tambahan SIA Kaprodi
yaitu login, home, ganti password, kontribusi, bantuan serta logout.
Dari dua jenis fungsi tersebut (utama dan tambahan) akan
ditentukan kritis dan tidak kritisnya fungsi tersebut terhadap fungsi-fungsi
yang lainnya. Hal tersebut berguna agar dapat mempermudah analis dalam
memperhitungkan nilai-nilai persentase nantinya.
3.6. Tahap Pengujian Perangkat Lunak
Proses pengujian perangkat lunak BRS Online memerlukan
tahapan-tahapan sehingga diperoleh hasil dari adanya pengujian yang
3.6.1. Tahap Perencanaan dan Penentuan Kasus Pengujian
Dalam tahap perencanaan dan penentuan kasus pengujian
dilakukan penelusuran terhadap seluruh modul-modul yang terdapat di
dalam perangkat lunak oleh analis. Di dalam tahap perencanaan dan
penentuan ini keluaran yang diperoleh yaitu banyaknya modul-modul yang
akan diuji serta deskripsi pada setiap modul tersebut. Modul tersebut
kemudian akan disusun dan dikelompokkan berdasarkan kriteria pengguna
yang mengakses perangkat lunak ini. Setelah pengelompokan selesai maka
pengujian black box dapat dilakukan dengan menggunakan 3 bagian
pengujian.
3.6.2. Tahap Pengujian Fungsional
Pada tahap ini dilakukan pengujian terhadap seluruh fungsi-fungsi
yang tersedia pada perangkat lunak BRS Online yang sebelumnya telah
dilakukan analisa terhadap modul dan objek yang ada. Pengujian ini
dilakukan oleh analis beserta tim yang dibentuk analis untuk membantu
menentukan validitas dari kesalahan yang ditemukan. Dari tahap
pengujian fungsional ini diharapkan dapat menemukan dan menentukan
kesalahan-kesalahan yang terdapat di dalam perangkat lunak untuk dapat
di analisa ke dalam tahap pengujian berikutnya. Dalam tahap pengujian
fungsional hal-hal yang dilakukan adalah :
1. Melakukan interface checking dan GUI modul yang diuji, apakah
2. Mencari fungsi-fungsi yang tidak benar dan hilang pada modul yang
diuji.
3. Mencari kesalahan kinerja, inisialisasi dan terminasi dengan
melakukan pengecekan seluruh fungi-fungsi yang ada dalam modul
yang diuji.
3.6.3. Tahap Pengujian Graph-Based
Tahap pengujian ini bertujuan untuk mengetahui aktivitas
objek-objek yang ada dalam modul yang diuji. Pada tahap pengujian graph based ini keluaran yang akan dihasilkan berupa graph aktifitas
objek-objek yang ada di dalam modul. Dalam tahap pengujian graph-based hal-hal yang dilakukan adalah :
1. Membuat daftar test case berdasarkan objek-objek yang ada dalam
modul yang diuji. Daftar test case berisi tentang objek-objek pada modul yang hendak diuji. Daftar test case akan digunakan dalam
pengujian selanjutnya oleh para responden (tester).
2. Membuat graph test berdasarkan daftar test case yang telah dibuat.
Graph test berkaitan tentang hubungan setiap objek dengan objek
lainnya pada modul tersebut, apakah setiap objek memiliki pengaruh
terhadap objek lain atau tidak (lihat gambar 3).
3.6.4. Tahap Pengujian Equivalence Partitioning
Tahap pengujian ini bertujuan untuk menentukan keadaan valid
atau invalid terhadap kondisi input perangkat lunak. Pengujian ini
berusaha menentukan sebuah test case yang mampu mengungkap
kelas-kelas kesalahan, sehingga mengurangi jumlah total test case yang harus dikembangkan. Dalam tahap pengujian equivalence partitioning hal-hal yang dilakukan adalah :
1. Membuat daftar test case berdasarkan fungsi-fungsi yang ada dalam modul yang diuji. Daftar test case berisi tentang objek-objek pada
modul yang hendak diuji. Daftar test case akan digunakan dalam pengujian selanjutnya oleh para responden (tester).
2. Membuat model komponen pengujian yang merupakan partisi dari
nilai input dan output berdasarkan spesifikasi fungsi dan objek modul
yang diuji.
3. Melakukan pengujian berdasarkan model partisi yang dibuat.
3.6.5. Tahap Pengujian Boundary Value Analysis
Tahap pengujian ini bertujuan untuk menguji kemampuan program
dalam menangani data pada batas yang dapat diterima perangkat lunak.
Pengujian boundary value analysis merupakan komplemen dari teknik pengujian equivalence partitioning namun lebih pada memilih
