Dokumen ini membahas tentang pengujian perangkat lunak melalui black-box testing, yang berfokus pada fungsi yang dispesifikasikan tanpa perlu mengetahui struktur internal. Metode ini mencakup teknik-teknik seperti equivalence class partitioning dan boundary value analysis untuk menemukan kesalahan dalam perangkat lunak. Selain itu, dokumen ini juga menyoroti langkah-langkah yang perlu diperhatikan dalam membuat skenario pengujian yang efektif.

1. Pengujian Perangkat Lunak:
Black-Box Testing

2. Berdasarkan pada fungsi yang dispesifikasikan dari produk, tes dapat dilakukan
dengan mendemonstrasikan tiap fungsi telah beroperasi secara penuh sesuai
dengan yang diharapkan. Sementara itu, pada saat yang bersamaan, dilakukan
pencarian error pada tiap fungsi.
Metode uji coba blackbox memfokuskan pada keperluan fungsional dari
software. Karena itu uji coba blackbox memungkinkan pengembang software
untuk membuat himpunan kondisi input yang akan melatih seluruh syarat-syarat
fungsional suatu program. Ujicoba blackbox bukan merupakan alternatif dari
ujicoba whitebox, tetapi merupakan pendekatan yang melengkapi untuk
menemukan kesalahan lainnya, selain menggunakan metode whitebox.
Black-Box Testing

3. Black box testing, tidak perlu mengetahui detail struktur internal dari sistem
atau komponen yang dites. Juga disebut sebagai behavioral testing,
specification-based testing, input/output
Black box testing berfokus pada kebutuhan fungsional pada software,
berdasarkan pada spesifikasi kebutuhan dari software.
Black-Box Testing

4. Ujicoba blackbox berusaha untuk menemukan kesalahan dalam beberapa
kategori, diantaranya :
1. Fungsi-fungsi yang salah atau hilang
2. Kesalahan interface
3. Kesalahan dalam struktur data atau akses database eksternal
4. Kesalahan performa
5. Kesalahan inisialisasi dan terminasi
Kategori error melalui black-box testing

5. Karena ujicoba blackbox dengan sengaja mengabaikan struktur kontrol,
sehingga perhatiannya difokuskan pada informasi domain. Ujicoba didesain
untuk dapat menjawab pertanyaan pertanyaan berikut :
1. Bagaimana validitas fungsionalnya diuji?
2. Jenis input seperti apa yang akan menghasilkan kasus uji yang baik ?
3. Apakah sistem secara khusus sensitif terhadap nilai input tertentu ?
4. Bagaimana batasan-batasan kelas data diisolasi?
5. Berapa rasio data dan jumlah data yang dapat ditoleransi oleh sistem?
6. Apa akibat yang akan timbul dari kombinasi spesifik data pada operasi
sistem?
Black-Box Testing

6. ◦ Manganalisa kebutuhan dan spesifikasi dari perangkat lunak
◦ Pemilihan jenis input yang memungkinkan output benar serta jenis yang
memungkinkan output salah pada perangkat lunak yang sedang di uji
◦ Menentukan ouput untuk suatu jenis input
◦ Pengujian dilakukan dengan input-input yang telah benar diseleksi
◦ Melakukan pengujian
◦ Pembandingan output yang dihasilkan dengan output yang diharapkan
◦ Menentukan fungsionalitas yang seharusnya ada pada perangkat lunak yang
sedang diuji
Proses Black-Box Testing

7. Ruang Lingkup Black-Box
Black box testing dapat dilakukan pada setiap level pembangunan sistem. Mulai dari unit, integration,
system, dan acceptance.

8. Jenis Teknik Desain Black-Box Testing
Equivalence Class Partitioning
Merupakan teknik yang digunakan untuk mengurangi jumlah test case yang ada
pada saat pengujian. Kebanyakan tester menggunakan teknik yang simpel ini
meskipun secara formal tester tersebut tidak mengetahui mengenai metode
desain formal dalam pengujian perangkat lunak.
Kasus uji yang didesain untuk equivalence class testing berdasarkan pada
evaluasi dari ekuivalensi jenis/class untuk kondisi input. Class class yang
ekuivalen mempresentasikan sekumpulan keadaan valid untuk kondisi input.
Biasanya kondisi input dapat berupa numerik, kisaran nilai, kumpulan nilai yang
berhubungan atau kondisi boolean

9. Equivalence Class Partitioning
Step by Step Equivalence Class Partitioning
◦ Identifikasi Kelas yang ekuivalen (equivalence class)
◦ Buat test case untuk tiap-tiap equivalence class
◦ Jika memungkinkan buat test case tambahan acak yang memungkinkan
ditemukannya cacat pada perangkat lunak.

10. Equivalence Class Partitioning
Discrete Equivalence Class
Contoh nilai untuk jumlah kepemilikan rumah yang diisyaratkan untuk melakukan pembelian
rumah secara kredit.

11. Equivalence Class Partitioning
Single Selection Equivalence Class
Contohnilai untuk kategori pengajuan yang di isyaratkan untuk melakukan pembelian rumah
secara kredit.

12. Jenis Teknik Desain Black-Box Testing
Boundary Value Analysis
Untuk suatu alasan yang tidak dapat sepenuhnya dijelaskan, sebagian besar
jumlah errors cenderung terjadi di sekitar batasan dari domain masukan
daripada di “pusat”nya.
Karena alasan inilah boundary value analysis (BVA) dikembangkan sebagai salah
satu teknik testing.
Boundary value analysis adalah suatu teknik disain test cases yang berguna
untuk melakukan pengujian terhadap nilai sekitar dari pusat domain masukan.

13. Teknik boundary value analysis merupakan komplemen dari teknik
equivalence partitioning.
Setelah dilakukan pemilihan tiap elemen suatu kelas ekuivalensi
(menggunakan equivalence partitioning), BVA melakukan pemilihan
nilai batas-batas dari kelas untuk test cases.
BVA tidak hanya berfokus pada kondisi masukan, BVA membuat test
cases dari domain keluaran juga.
Boundary value analysis

14. Boundary-values merupakan nilai batasan dari kelas-kelas ekuivalensi. Contoh:
◦ Senin dan Minggu untuk hari.
◦ Januari dan Desember untuk bulan.
◦ (-32767) dan 32767 untuk 16-bit integers.
◦ Satu karakter string dan maksimum panjang string.
Test cases dilakukan untuk menguji nilai-nilai di kedua sisi dari batasan.
Nilai tiap sisi dari batasan yang dipilih, diusahakan mempunyai selisih sekecil
mungkin dengan nilai batasan (misal: selisih 1 untuk bilangan integers).
Boundary value analysis

15. Contoh Kasus Black-Box Testing
Contoh
Program mencatat pembayaran sejumlah barang dari table barang. Jika data
valid akan menghitung nilai bayar jika data tidak valid akan muncui pesan
kesalahan. Data yang diinput adalah kode barang dan jumlah barang. Isi tabel
barang : kd_barang, nama brg, satuan, harga.
Buatlah kelas ekivalensi test case untuk menguji program tersebut.

16. Contoh Kasus Black-Box Testing
Contoh Kelas Ekivalensi
Asumsi kode barang 5 digit:
A = ATK
B = Barang lain
(jumlah digit kode barang = A/B xxxx)
Data valid
Kode barang harus look-up table
Jumlah barang integer > 0

17. Contoh Kasus Black-Box Testing
Contoh Kelas Ekivalensi
Data invalid
Kode barang diinput baru
Kode barang blank
Jumlah barang <= 0
Jumlah barang pecahan / non numerik
Berapa kali dilakukan test case ?
(valid = 2, invalid =4)

18. Contoh Kasus Black-Box Testing
Test Case menggunakan Tabel Pengujian
No Data Uji Input Hasil test
diharapkan
Output Kesimpulan
1 Kd barang = lookup
table
Jumlah > 0
Kd barang =
A1122
Jumlah = 2
Perhitungan
nilai bayar
Perhitungan
nilai bayar
Sukses/
Valid
2 Kd barang= kosong
Jml > 0
Kd barang= ‘’
Jml =2
Pesan
kesalahan
Pesan
kesalahan
Sukses/
Valid
3 Kd-barang=isi baru
Jml > 0
Kd barang=
b9911
Jumlah = 3
Pesan
kesalahan
Perhitungan
nilai bayar
Gagal/invali
d

19. Contoh Lain Black-Box Testing
Test Case sistem Log In
No. Skenario pengujian Test case Hasil yang diharapkan Hasil pengujian Status
1 Mengosongkan semua isian
data login, lalu langsung
mengklik tombol ‘Masuk’.
Nama: -
Kata sandi: -
Sistem akan menolak akses
login dan menampilkan
pesan “Mohon isi dulu nama
admin dan kata sandi”
Sesuai harapan Valid
2 Hanya mengisi data nama
admin dan mengosongkan
data kata sandi, lalu langsung
mengklik tombol ‘Masuk’.
Nama: admin
Kata sandi: -
Sistem akan menolak akses
login dan menampilkan
pesan “Mohon isi dulu salah
satu data yang masih
kosong”
Sesuai harapan Valid
3 Menginputkan data login
yang benar, lalu mengklik
tombol ‘Masuk’.
Nama: admin
Kata sandi:
123
Sistem menerima akses
login dan kemudian
langsung menampilkan form
pakar/admin.
Sesuai harapan Valid

20. Hal — hal yang perlu diperhatikan dalam
membuat sebuah skenario test antara lain :
ü Requirement Description. Pada aspek ini seorang QA harus memahami behaviour sebuah
aplikasi yang diuji, bagaimana cara aplikasi tersebut berjalan serta mengetahui goals yang
sesuai dengan requirement aplikasi yang sedang dikembangkan agar tetap selaras.
ü Inputs and outputs or actions (positive-negative scenarios) and expected results. Seorang
QA harus mengetahui hasil dari eksekusi langkah — langkah pengujian yang ditulis dalam
skenario test
ü Updates. Jika seorang QA menemukan skenario baru atau bahkan jika terdapat
penambahan/perubahan task (karena diterapkannya scrumb) maka ia harus terus
memperbarui skenario tersebut. Sehingga skenario dapat mencakup seluruh aspek aplikasi

21. ü Konsisten. Pada aspek ini merupakan konsisten dalam hal penamaan. Agar Skenario test
tersebut lebih rapi, mudah dipahami dan tidak membingungkan. contoh : Setelah
menggunakan istilah ‘login’, namun setelah itu menggunakan istilah ‘Sign in.
ü Simple dan Transparan. Pada saat membuat skenario, semua langkah pelaksanaan harus
jelas dan tidak ada yang terlewat
ü Mudah Dimengerti. Saat menyusun skenario alangkah baiknya menggunakan bahasa yang
sederhana dan mudah dipahami. Sehingga orang lain pun dapat memahami skenario yang
dibuat
ü End-user mind. Seorang QA tester harus bisa bermindset bahwa ia adalah seorang end-user.
maka dari itu hal yang lain yang perlu diperhatikan adalah kemudahan penggunaan aplikasi
sehingga konsumen mendapat kepuasan terhadap produk yang dikembangkan tersebut

23. Komponen Skenario Test Case
1. Modul. Pada section modul merupakan nama kasus uji/task aplikasi tersebut pada contoh di atas
nama modulnya adalah Maintenance Ticket
2. Feature. Pada kolom features berisi fitur/kasus — kasus yang lebih detail. pada gambar di atas adalah
beberapa contoh fitur dalam task maintenance ticket yaitu View List Active Ticket dan fitur add note
3. Test Steps. Pada Test Step berisi langkah — langkah user dalam mengoperasikan sebuah fitur pada
suatu task.
4. Expected Result. Pada expected result berisi hasil yang diharapkan atau yang sesuai dengan
requirement aplikasi dari setiap test steps yang ditulis. berikut ini merupakan contoh expected result
dari fitur Add note
5. Status. Pada Kolom Status, disajikan berupa dropdown sehingga jika skenario telah dieksekusi maka
QA dapat mengubah status tersebut apakah aplikasi sudah sesuai dengan ekspektasi yang diharapkan
6. Note. Pada kolom ini dapat diisi dengan catatan khusus jika hasil testing gagal.

24. Terima Kasih