Software

Testing
STMIK MATERI
MULAI PalComTech
 Bahan Kajian

1 • Kualitas Perangkat Lunak

• Terminologi Kegagalan (Failure), Kesalahan
(Error/Fault), Cacat (Defect), dan Bug
• 7 Prinsip Pengujian Perangkat Lunak
• Proses Pengujian
• V-Model
 Bahan Kajian

2 • Alat Pengujian
• Teknik Pengujian
– Black Box Testing
– White Box Testing
– Experience Testing Referensi :
• ISTQB
• ISO
• V-Model
 Bahan Kajian

3 • Perawatan Sistem
• Jaminan Kualitas

Referensi :
• ISTQB
• ISO
• V-Model
 Software Quality
⮚ Karakteristik khusus dari kualitas perangkat lunak adalah sebuah hal yang kompleks
dan tak mudah untuk langsung dimengerti (intangibility).
⮚ Banyak sekali beda persepsi dan ekspektasi mengenai kualitas perangkat lunak,
diantaranya kebutuhan, keinginan, kemauan, dan prioritas dari pengguna
perangkat lunak.
⮚ Definisi kualitas terhadap sebuah obyek itu tidak dapat dideskripsikan dengan pasti
dan jelas, akan tetapi dapat diukur menggunakan parameter yang sesuai.
⮚ Untuk itu, pengembang perangkat lunak dituntut untuk dapat menghasilkan
“deliverables” yang dapat diuji atau diukur kualitasnya.
⮚ Hal ini penting untuk dapat menciptakan pengalaman, kenyamanan dan kepuasan
pengguna dalam kaitannya dengan usabilitas dan aspek kualitas perangkat lunak
lainnya.
 Software Quality
De Groot [Link]. (2013)
Quality is the totality of features and characteristics of a product or service that bear
on its ability to satisfy stated or implied needs -- totalitas fitur dan karakteristik
produk atau jasa yang bergantung pada kemampuannya untuk memuaskan
kebutuhan yang dinyatakan atau tersirat.

Spillner (2014:303)ity and features of a software product that bear on its

The totality of functionality and features of a software product that bear on its ability
to satisfy stated or implied needs -- totalitas fungsionalitas dan fitur produk
perangkat lunak yang bergantung pada kemampuannya untuk memenuhi
kebutuhan yang dinyatakan atau tersirat.
 Software Quality

Ada beberapa hal yang perlu diketahui untuk menentukan tingkatan kualitas
perangkat lunak yang diharapkan, diantaranya (Handayani, 2021) :

1. Beda perspektif dan harapan dari pengguna dan tim yang terlibat dalam proses
pembangunan/pengembangan perangkat lunak.
2. Visi dan misi dari pihak manajemen (owner dari perangkat lunak tersebut).
3. Kondisi yang diharapkan saat implementasi di lingkungan end-user.
4. Karakteristik dan feed back dari pengguna.
5. Hasil uji coba usabilitas perangkat lunak tersebut.
 Software Quality
Lima hal utama yang perlu diperhatikan untuk menjamin kualitas sebuah perangkat
lunak, diantaranya (Handayani, 2021) :
1. Kebutuhan fungsional yang khusus, dimana utamanya mengacu pada keluaran dari
sistem perangkat lunak. Kebutuhan perangkat lunak ini merupakan pondasi
kualitas yang akan diukur. Kurangnya penyesuaian terhadap kebutuhan tersebut
menunjukkan rendahnya kualitas perangkat lunak.

2. Pengujian perangkat lunak sebagai sarana untuk memastikan kualitas perangkat

lunak.

3. Standar kualitas perangkat lunak yang disebutkan dalam kontrak proyek rekayasa
perangkat lunak harus dapat dipenuhi. Jika tidak, maka bisa dipastikan dapat
menimbulkan stigma negatif terhadap perangkat lunak tersebut.
 Software Quality

4. Ada serangkaian kebutuhan implisit yang sering kali tidak dicantumkan dalam
kontrak rekayasa perangkat lunak tapi harus dapat dipenuhi. Hal ini dicatat sebagai
alternatif lain untuk menjamin kualitas perangkat lunak, diantaranya pencegahan
cacat kualtias, proses perbaikan dan pemeliharaan, toleransi kesalahan, jaminan
keamanan, dan pengendalian kerusakan sistem.

5. Pengukuran dan analisa kualitas sebagai umpan balik (feed back) sebagai upaya
penilaian dan peningkatkan kualitas perangkat lunak secara terukur.
 Software Quality
Dalam ISO/IEC 9126, kualitas sebuah produk perangkat lunak dikategorikan menjadi
empat bagian, diantaranya :

1. Kualitas internal (dinilai dari kualitas pemrogramannya),

2. Kualitas eksternal (dinilai pada saat perangkat lunak tersebut dieksekusi atau diuji
coba),
3. Kualitas penggunaan (dinilai dari sejauh mana kebutuhan pengguna terpenuhi di
lingkungan kerja end-user), dan
4. Kualitas proses (dinilai dari kematangan perencanaan kebutuhan dan standar
pemenuhan kebutuhan dalam proyek rekayasa perangkat lunak).
 Software Quality

Kategori Kualitas Perangkat lunak Berdasarkan ISO/IEC 9126

 Software Quality

• Kualitas
• Perangkat Lunak
• Proses
• (Pengukuran kualitas dilakukan selama proyek rekayasa perangkat lunak dimulai
sampai dengan selesai)
• Produk
• (Pengukuran kualitas perangkat lunak sebagai produk akhir dari proyek rekayasa
perangkat lunak)
 Testing vs SQA
Testing ⬄ Software Quality Assurance (SQA) :

~~improve the product by improving the process~~

SQA secara spesifik mencoba merekayasa produk melalui proses perekayasaan

perangkat lunak.

Testing dilakukan murni berorientasi pada produk akhir rekayasa perangkat lunak.

Testing fokus pada mengurangi / menghilangkan kesalahan (fault) pada produk

perangkat lunak.
 Testing for Quality
• Definisi kualitas dari sebuah perangkat lunak
Usability merupakan aktualisasi dari pengalaman dan
kepuasan para penggunanya.
Experience Satisfaction
• Sebuah perangkat lunak dapat dinyatakan
berkualitas, maka terlebih dahulu harus
dilakukan pengujian (testing) dan pengukuran
QUALITY (measurement) tingkat kualitasnya.
Software • Pengujian juga dimaksudkan untuk
Testing
memastikan apakah perangkat lunak tersebut
USER benar-benar dapat digunakan (useable) oleh
penggunanya [Handayani & Adelin, 2019].
QA Engineer
 Software Testing
Testing 🡪 Pengujian jelas berkaitan dengan kesalahan (error/defect/bug),
kegagalan (failure), dan insiden.
Insiden 🡪 Ketika kegagalan terjadi, mungkin atau secara tidak langsung
terlihat oleh pengguna atau penguji. Insiden adalah gejala yang terkait dengan
kegagalan yang memperingatkan pengguna untuk terjadinya kegagalan.
Testing dilakukan sebagai tindakan menjalankan perangkat lunak dengan
kasus uji. Testing memiliki dua tujuan yang berbeda: (1) untuk menemukan
kegagalan, atau (2) untuk menunjukkan eksekusi yang benar.
Test Case (kasus uji) 🡪 Kasus uji memiliki identitas dan dikaitkan dengan
perilaku program. Kasus uji juga memiliki kumpulan input dan output yang
diharapkan.
 Software Testing
Pengujian perangkat lunak sangat diperlukan untuk memastikan
software/aplikasi yang sudah/sedang dibuat (direkayasa) dapat berjalan sesuai
fungsionalitas yang diharapkan.

Pengembang/penguji software harus menyiapkan sesi khusus untuk menguji

program yang telah dibuat agar kesalahan ataupun kekurangan dapat dideteksi
sejak awal dan dikoreksi secepatnya.

Pengujian (testing) sendiri merupakan elemen kritis dari jaminan kualitas

perangkat lunak dan merupakan bagian yang tidak terpisahkan dari siklus
hidup pengembangan perangkat lunak seperti halnya analisis, desain, dan
pengkodean (Shi, 2020).
 Software Testing
• Upaya pengujian perangkat lunak (PL) berkisar antara 25-
50% (Spillner, 2014) atau 30-40% (Pertiwi, 2021) dari total
waktu penyelesaian pengembangan perangkat lunak.

• Porsi upaya pengujian PL yang tinggi ini harusnya dapat

terjangkau karena mengacu pada risiko kerusakan sistem
perangkat lunak.

• Risiko dihitung sebagai kemungkinan terjadinya dan jumlah

kerusakan yang diperkirakan.
 Testing Life Cycle

Jorgensen (2014:4)
Software Testing :
A Craftman’s Approach,
4th edition
 Portofolio Sertifikasi
Seorang Software Tester

Organisasi Penyelenggara
Sertifikasi Internasional untuk
Software Tester (base @Germany):
The International Software Testing
Qualification Board (ISTQB) -
[Link]
Error, Fault, Defect, Bug, Failure
Error (Mistake/ kesalahan secara parsial) 🡪 saat programmer melakukan kesalahan
dalam membuat kode program, maka kondisi ini disebut mistake bugs. Kesalahan
dapat terjadi selama proses desain sistem atau saat penulisan kode program.

Fault (Defect/Bug/kesalahan secara simultan)🡪 fault (kesalahan) yang merupakan

akumulasi dari error atau bisa disebut representasi (tampilan) dari sebuah ekspresi
sistem. Sumber kesalahan bisa disebabkan oleh banyak hal dalam sistem, misal
kesalahan penafsiran pada diagram UML, navigasi, maupun kode programnya. Inilah
yang terkadang membuat sebuah kesalahan sulit dipahami.
Error, Fault, Defect, Bug, Failure
Ada 2 bentuk Fault yaitu:
1. a Fault of Commission : saat kita inputkan data/karakter kedalam sebuah tampilan
dan ternyata inputan tersebut salah/dianggap salah. Misalnya : kombinasi user
name dan password pada saat Login tidak sesuai dengan yang terdapat pada tabel
user di dalam database.

2. a Fault of Ommission : saat kita gagal atau tidak bisa memberikan inputan atau
informasi yang benar kepada sistem. Misalnya pada saat seorang admin (BAAK)
diminta untuk menginputkan nama dari seorang mahasiswa ke dalam sebuah
form. Hal ini bisa saja menimbulkan kesalahan dalam menuliskan ejaan huruf dari
nama mahasiswa tsb, jika tidak dikoordinasikan dengan baik pada database
(redudansi/inkonsistensi).
Error, Fault, Defect, Bug, Failure
Failure (kegagalan) 🡪 Kegagalan terjadi ketika kode yang terkait dengan
kesalahan tersebut dijalankan.

Failure (Kegagalan) 🡪 Ketika persyaratan yang diberikan tidak dapat

terpenuhi. Ada beda antara perilaku yang sebenarnya dan perilaku yang
diharapkan.

Kegagalan hadir jika harapan pengguna tidak terpenuhi secara memadai.

Contoh kegagalan misalnya produk perangkat lunak yang terlalu sulit
digunakan atau terlalu lambat responnya tetapi masih memenuhi persyaratan
fungsionalnya.
Error, Fault, Defect, Bug, Failure
Kegagalan dapat terjadi dalam representasi yang dapat dieksekusi, yang biasanya
berasal dari kode sumber, atau lebih tepatnya kode program dari objek yang akan
ditampilkan.
Kegagalan dapat juga dihubungkan dengan a Fault of Ommission.

• Bagaimana kita bisa menangani kegagalan yang sesuai dengan kesalahan

kelalaian?
• Bagaimana dengan kesalahan yang tidak pernah terjadi untuk dieksekusi, atau
mungkin tidak mengeksekusi sistem untuk waktu yang lama?
• Bagaimana cara mencegah banyak kegagalan dengan menemukan kesalahan?
Solusi untuk hal tersebut adalah melakukan review secara menyeluruh yang dilakukan
dengan baik dapat menemukan kesalahan kelalaian.
Error, Fault, Defect, Bug, Failure
Berbeda dengan kegagalan sistem fisik, kegagalan perangkat lunak tidak terjadi
karena: Penuaan atau Abrasi.

Kegagalan terjadi karena kesalahan dalam perangkat lunak. Kesalahan (error), cacat
(defect), atau bug pada perangkat lunak ada sejak perangkat lunak dikembangkan atau
diubah, namun hanya terwujud ketika perangkat lunak dijalankan, menjadi terlihat
sebagai bentuk kegagalan perangkat lunak seperti output yang salah, atau program
macet.
Error, Fault, Defect, Bug, Failure
Kita harus membedakan antara kejadian kegagalan dan penyebabnya.

Kegagalan (failure) disebabkan oleh kesalahan (fault / error) dalam perangkat

lunak.
Kesalahan (fault) ini juga disebut cacat (defect) atau kesalahan internal.
Bahasa gaul programmer untuk suatu kesalahan adalah bug.

Misalnya:
Kesalahan terjadi bisa karena memang salah atau lupa menegaskan
pernyataan dalam kode program. Ada kemungkinan bahwa suatu kesalahan
disembunyikan oleh satu atau lebih banyak kesalahan lain di bagian lain dari
program (penyamaran cacat (defect masking)).
Error, Fault, Defect, Bug, Failure
Kesalahan dan kegagalan adalah 2 hal yang berbeda.

Kegagalan dapat terjadi hanya setelah cacat telah diperbaiki. Ini menunjukkan
bahwa koreksi dapat memiliki efek samping.

Satu kesalahan dapat menyebabkan tidak ada, satu, atau banyak kegagalan
untuk sejumlah pengguna.

Contoh yang sangat berbahaya adalah beberapa kerusakan kecil pada data
yang disimpan, yang mungkin ditemukan lama sekali setelah kerusakan
pertama terjadi.
 Testing Life Cycle

Jorgensen (2014:4)
Software Testing :
A Craftman’s Approach,
4th edition
Jenis-Jenis Kesalahan (Fault)
Jenis-Jenis Kesalahan (Fault)
 Jenis-Jenis Kesalahan (Fault)

Jorgensen (2014:4)
Software Testing : A Craftman’s Approach,
4th edition
Kapan Pengujian Berakhir?
• Pada minggu pertama, rata-rata
ada dua kegagalan baru per jam
pengujian.
• Pada minggu ke-10, kurang dari
satu kegagalan per dua jam.
• Jika tingkat kegagalan turun di
bawah ambang batas yang
diberikan (misalnya, kurang dari
satu kegagalan per jam
pengujian), akan diasumsikan
bahwa pengujian lanjutan tidak
diperlukan dan proses pengujian
dapat diakhiri.
 7 Prinsip Pengujian Software
Prinsip 1:
Pengujian menunjukkan adanya cacat, bukan ketidakhadirannya.

• Pengujian dapat menunjukkan kegagalan produk PL, tapi pengujian

tidak dapat membuktikan bahwa suatu program bebas cacat.

• Pengujian yang memadai mengurangi kemungkinan adanya cacat

tersembunyi pada PL. Walaupun tidak ditemukan kegagalan selama
pengujian, ini juga tidak membuktikan bahwa tidak ada cacat pada
produk PL tersebut.
 7 Prinsip Pengujian Software
Prinsip 2:
Pengujian menyeluruh adalah tidak mungkin.

• Tidak mungkin menjalankan tes lengkap yang mencakup semua

nilai untuk semua inputan dan kombinasinya dikombinasikan
dengan semua prasyarat yang berbeda.
• Perangkat lunak, dalam praktik normal, akan membutuhkan angka
yang "secara astronomis" tinggi dari kasus uji.
• Setiap tes hanyalah sampel. Oleh karena itu, upaya pengujian
harus dikendalikan, dengan mempertimbangkan risiko dan prioritas.
 7 Prinsip Pengujian Software
Prinsip 3:
Kegiatan pengujian harus dimulai sedini mungkin.

• Aktivitas pengujian harus dimulai sedini mungkin dalam siklus hidup

perangkat lunak dan fokus pada tujuan yang telah ditentukan. Hal
ini dilakukan untuk bisa menemukan cacat kualitas PL lebih awal.

• Lihat slide 28 (Testing Life Cycle) atau lihat materi V-Model.

 7 Prinsip Pengujian Software
Prinsip 4:
Pengelompokan cacat (defect).
• Cacat tidak merata pada seluruh komponen perangkat lunak.
Kebanyakan cacat terdapat pada beberapa bagian obyek uji.
• Jika banyak cacat terdeteksi di satu tempat, biasanya ada lebih
banyak cacat di dekatnya.
• Selama pengujian, seseorang harus bereaksi fleksibel terhadap
prinsip ini.
 7 Prinsip Pengujian Software
Prinsip 5:
Paradoks pestisida.
• Serangga dan bakteri menjadi kebal terhadap pestisida.
• Demikian pula, jika tes yang sama diulang-ulang, mereka
cenderung kehilangan keefektifannya.
• Untuk menjaga efektivitas tes, kasus uji baru dan yang dimodifikasi
harus dikembangkan dan ditambahkan ke dalam rangkaian
pengujian.
• Bagian dari perangkat lunak belum diuji, atau sebelumnya
kombinasi input yang tidak digunakan kemudian akan terlibat dan
lebih banyak cacat mungkin ditemukan.
 7 Prinsip Pengujian Software
Prinsip 6:
Pengujian bergantung pada konteks.

• Pengujian harus disesuaikan dengan risiko yang melekat dalam

penggunaan dan lingkungan dari aplikasi.
• Oleh karena itu, tidak ada dua sistem yang harus diuji secara tepat
cara yang sama.
• Intensitas pengujian, kriteria keluar pengujian, dll harus diputuskan
secara individual untuk setiap sistem perangkat lunak, tergantung
pada penggunaannya lingkungan.
• Misalnya, sistem yang kritis terhadap keselamatan kerja
memerlukan pengujian yang berbeda dari aplikasi e-niaga.
7 Prinsip Pengujian Software
Prinsip 7:
Jika “tidak ada kegagalan yang ditemukan berarti sistem
berguna”, maka itu adalah sebuah kesalahan.

• Menemukan kegagalan dan memperbaiki cacat PL tidak menjamin

bahwa sistem memenuhi harapan dan kebutuhan pengguna.

• Keterlibatan awal pengguna dalam proses pengembangan dan

penggunaan prototipe adalah tindakan pencegahan dimaksudkan
untuk menghindari masalah ini.
Proses Pengujian
 .

Model Proses
Software Testing:
V-Modell
 V-Model
(extends the waterfall
•
process)
V-Modell pertama kali diterbitkan oleh Angkatan Bersenjata Jerman pada
tahun 1992. Sejak itu telah ada dua revisi, V-Model 97 dan V-Model XT.

• Versi pertama V-Modell XT dirilis pada Februari 2005. Penambahan "XT"

adalah singkatan dari "eXtreme Tailoring" dan menggarisbawahi
kemampuan beradaptasi yang fleksibel untuk lingkungan proyek tertentu.
Riset, sektor swasta dan sektor publik sama-sama terlibat dalam
pengembangan V-Modell XT.

• Saat ini sudah dikembangkan V-Model versi 2.3. Fokusnya pada

peningkatan kegunaan dan desain ulang dependensi produk terkait
konten. Hal ini guna mendukung jaminan kualitas hasil proyek.
V-Model (tradisional)
• Kiri = SDLC (development
activities)
• Kanan = Proses pengujian
(testing activities)
• V = Verifikasi & Validasi
• Diusulkan oleh Paul Rook
(1980)
 V-Model (tradisional)

Spillner, 2014 Mathur & Malik, 2010

 V-Model (tradisional)
Component / Unit Testing :
Fokus pengujian pada tiap komponen secara individu,
memastikan tiap komponen tersebut berfungsi dengan baik
sebagai satu kesatuan.

Teknik pengujiannya menggunakan White Box Testing

dengan pengujian jalur (path) pada struktur kontrol modul
sistem untuk memastikan cakupan pengujiannya lengkap
dan deteksi maksimum terhadap kesalahan sistem.
 V-Model (tradisional)
Integration Testing :
Pengujian ini membahas perakitan dan integrasi komponen
untuk membentuk paket perangkat lunak yang lengkap.

Pengujian ini menggunakan teknik Black Box Testing untuk

mengatasi masalah yang terkait dengan masalah verifikasi
ganda dan konstruksi program.
 V-Model (tradisional)
System Testing :
Pengujian dilakukan secara lengkap, sistem terintegrasi
untuk mengevaluasi kepatuhan sistem dengan persyaratan
yang ditentukan.

Dalam pengujian ini tidak membutuhkan pengetahuan

mengenai desain bagian dalam dari kode ataupun logika.
 V-Model (tradisional)
Acceptance Testing :
Pengujian dilakukan untuk memverifikasi suatu produk
apakah telah memenuhi persyaratan yang ditentukan oleh
pelanggan atau masih harus disesuaikan lagi.

Seorang pelanggan biasanya melakukan jenis pengujian ini

pada produk perangkat lunak yang dikembangkan secara
eksternal.
V-Model (advanced)
• Kiri = SDLC (development
activities)
• Kanan = Proses pengujian
(testing activities)
• V = Validasi /
Verifikasi
• Diusulkan oleh Paul Rook
(1980)
 V-Model (advanced)
Test Cases :
Seperangkat kondisi atau variabel pengujian yang
digunakan oleh penguji untuk menentukan apakah
sistem/aplikasi yang diuji tersebut telah memenuhi standar
spesifikasi unit tersebut.

Test cases ini dilakukan setelah pengujian unit

(unit/component testing) selesai dilakukan.
 V-Model (advanced)
Regression Testing:
Pengujian ini dilakukan untuk mendeteksi kesalahan palsu
yang disebabkan oleh modifikasi atau koreksi perangkat
lunak berdasarkan hasil pengujian sebelumnya.

Pengujian ini dilakukan untuk memastikan bahwa

perubahan sebagai hasil koreksi dari pengujian
sebelumnya telah benar-benar sesuai dengan kondisi yang
diharapkan.
 V-Model (advanced)
Security Testing:
Pengujian ini bertujuan untuk mengevaluasi keberadaan
dan berjalannya fungsi keamanan sistem/aplikasi guna
memastikan integritas dan kerahasiaan data.
 V-Model (advanced)
Deployment Testing:
Pengujian dilakukan dengan cara simulasi implementasi
sistem pada lingkungan fisik dan operasionalnya oleh end-
user.

Pengujian ini dapat dilakukan dengan menguji apakah

sistem / aplikasi tersebut dapat berjalan sesuai dengan
kondisi yang diharapkan jika diimplementasi pada OS yang
berbeda, browser yang berbeda, atau user yang awam.
 Alat Pengujian
• Manual Testing
Pengujian terhadap perangkat lunak secara manual tanpa menggunakan
alat. Manual testing menjalankan test case yang sifatnya general untuk
menemukan bug yang mungkin tidak dapat dipantau oleh alat pengujian
(testing tools)

• Automation Testing
Pengujian perangkat lunak menggunakan alat pengujian atau kode (script)
pengujian dengan membandingkan hasil yang diinginkan dengan hasil
yang sebenarnya, dan aktivitas ini dilakukan berulang kali sampai didapat
hasil yang benar-benar konsisten.
 Alat Pengujian
Langkah-langkah Manual Testing : Langkah-langkah Automation
Testing :
• Menganalisa Requirement • Menilai dan mengevaluasi alat
• Membuat test plan pengujian yang dipakai.
• Membuat test case • Merancang test case
• Eksekusi dari test case • Melakukan Implementasi test
case menggunakan testing tools
• Mencari kecacatan
• Membuat laporan pengujan
• Memperbaiki kecacatan
• Melakukan pengecekan hasil
pengujian.
 Alat Pengujian
1. Eye Tracking
• Pelacak mata menunjukkan dimana peserta melihat sebagian atau
keseluruhan area tampilan yang diujikan.
• Pelacak mata memancarkan pola cahaya inframerah (tidak terlihat oleh
manusia) dan melacak pantulan pola tersebut di mata peserta dengan
kamera khusus.
• Pelacak matadapat mengambil sampel data hingga 120 kali per detik.
• Penguji dapat dengan cepat menentukan jumlah atau panjang fiksasi pada
area tertentu dari halaman web.
• Pelacak mata dapat diatur untuk memungkinkan pengamat mengikuti
pandangan peserta selama sesi tes.
 Alat Pengujian
1. Eye Tracking
• Moderator tes kemudian dapat menyesuaikan pertanyaan tanya jawab
pasca tes berdasarkan pola yang diamati selama tes. Misalnya, jika peserta
menghabiskan banyak waktu untuk melihat fitur, moderator tes dapat
menanyakan pendapat peserta tentang fitur tersebut.
• Penguji juga dapat menggunakan data kuantitatif yang dihasilkan oleh
pelacak mata dalam analisis pasca tes.
• Hasil pelacakan mata ini dapat memberikan wawasan tambahan tentang
perilaku peserta.
• Data dapat menjawab pertanyaan seperti “Area halaman mana yang paling
banyak dilihat peserta?” dan “Apakah ada area yang tidak mereka lihat
semuanya?”
 Alat Pengujian
2. First Click Testing
• Untuk melakukan tes First Click, peneliti
memerlukan kerangka gambar beranda
yang fungsional. Tautan harus aktif, tetapi
halaman tingkat kedua hanya dapat
memiliki pesan "tugas selesai".
• Hanya dengan menggunakan rancangan
awal situs (wireframe), peneliti dapat
melakukan pengujian First Click cukup
awal dalam proses pengembangan,
sebelum pengorganisasian terhadap situs
ditetapkan.
 Bahan Kajian
• Kategori Pengujian

3 • Teknik Pengujian

Referensi :
• ISTQB
• ISO
• V-Model
 Kategori Pengujian
Secara umum ada 2 kategori pengujian perangkat lunak :
1. User Acceptance Testing (UAT)
2. Usability Testing (UT)
 Kategori Pengujian
1. User Acceptance Testing (UAT)
• Pengujian terhadap perangkat lunak untuk mengetahui apakah desain
produk PL tersebut sudah sesuai dengan kebutuhan user.
• Data hasil pengujian UAT digunakan oleh seorang software developer
untuk melakukan pengembangan PL.
• UAT bertujuan untuk mengetahui fungsionalitas komponen PL tersebut
berjalan dengan baik atau tidak, sehingga fungsionalitas yang
ditampilkan PL sesuai dengan hasil yang diharapkan oleh penguji dan
user.
 Kategori Pengujian
2. Usability Testing (UT)
• Pengujian terhadap perangkat lunak untuk mengetahui user experience
dari desain produk PL tersebut.
• UT dilakukan oleh seorang peneliti UX (UX researcher) untuk melihat
apakah user dapat menggunakan PL secara mudah atau bahkan
mengalami kesulitan.
• UT bertujuan untuk mengetahui User Interface dari PL tersebut dapat
digunakan dengan mudah atau tidak, sehingga user dapat
menggunakannya secara intuitif atau tidak.
 Kategori Pengujian
• Misalnya, ada kotak dialog dengan pilihan “Ya” atau “Tidak”.
• Developer bisa saja mengganti kedua kata tersebut dengan gambar dan
warna yang berbeda dari biasanya, misalnya :
– pilihan “Ya” biasanya pakai warna hijau diganti warna ungu
– pilihan “Tidak” biasanya pakai warna merah diganti warna kuning.
• Secara fungsi, tiap pilihan sudah berfungsi dengan baik. Namun, user bisa
saja jadi kebingungan dan justru memilih tombol yang tidak sesuai dengan
keinginannya.
• Hal ini nantinya cenderung akan menurunkan user experience dari PL
tersebut.
 Kategori Pengujian
Berdasarkan pelakunya, ada 2 kategori pengujian perangkat lunak :
1. Alpha Testing
Dilakukan pada sisi pengembang oleh seorang pengguna. PL digunakan pada
setting yang natural dengan pengembang “yg memandang” melalui kacamata
pemakai dan merekam semua kemungkinan fault/failure yang terjadi dan masalah
pemakaian oleh pengguna tersebut.

2. Betha Testing
• Dilakukan pada satu atau lebih pelanggan oleh pemakai akhir PL dalam
lingkungan yg sebenarnya, pengembang biasanya tidak ada pada pengujian ini.
• Pelanggan merekam semua masalah (real atau imajiner) yg ditemui selama
pengujian dan melaporkan pada pengembang pada interval waktu tertentu.
 Kategori Pengujian
• Secara fungsional komponen perangkat lunak dapat dilakukan pengujian
menggunakan metode Blackbox baik secara alpha testing ataupun betha
testing.

• Selain itu, ada beberapa kategori pengujian yang biasanya dilakukan,

diantaranya:
1. Pengujian Regresi
2. Pengujian Tegangan (Stress Testing)
3. Pengujian Kinerja
 Kategori Pengujian
1. Pengujian Regresi
Pengujian ini dilakukan oleh tim penjamin kualitas (QA). Pengujian biasanya
akan dilakukan secara regresi, dalam arti bahwa satu perubahan yang terjadi
dalam satu kali pengujian tidak akan mengubah atau merusak sistem secara
menyeluruh.
Misalnya dalam sistem E-Commerce semua pelanggan diperkenankan untuk
melakukan pembayaran dengan menggunakan Visa dan MasterCard. Setelah
dilakukan pengembangan, kini pelanggan juga diperbolehkan untuk
membayar menggunakan PayPal.
Pengujian regresi pada fitur pembayaran PayPal ini dilakukan untuk
memverifikasi bahwa setelah memperkenalkan PayPal, para pelanggan masih
dapat membayar dengan metode pembayaran sebelumnya.
 Kategori Pengujian
2. Pengujian Tegangan
Pengujian ini dilakukan oleh tim pengembang dan operasional sistem.

Pengujian tegangan dilakukan untuk memastikan sistem tetap dapat bekerja

walau dalam kapasitas beban yang tinggi, bahkan mungkin sampai pada
kondisi overload.

Pengujian tegangan juga mempersiapkan perangkat lunak untuk dapat

mengantisipasi jika hal tersebut terjadi.
Black-Box :
 Kategori Pengujian
3. Pengujian Kinerja
Pengujian ini juga dilakukan oleh tim pengembang dan operasional sistem.

Pengujian ini dilakukan untuk memeriksa apakah sistem masih berfungsi

seperti yang diharapkan sebelum dan setelah dioperasikan, dan dalam
berbagai kondisi skenario pengujian.

Pengujian kinerja juga memastikan perangkat lunak dapat memenuhi

permintaan pengguna dalam batasan waktu yang masih dapat diterima oleh
penggunanya (acceptance time frames).
 Kategori Pengujian
3. Pengujian Kinerja (lanjutan)
• Pengujian kinerja dilakukan pada fase integration testing dan usability
testing.
• Pengujian ini biasanya dilakukan untuk perangkat lunak yang baru saja
dibuat atau akan dirilis ke lingkungan end-user.
• Dengan dilakukannya pengujian ini, developer/owner/user dapat
menentukan apakah sistem dapat bekerja sesuai dengan kriteria kinerja
yang ditentukan dalam batas waktu tertentu.
• Salah satu contoh metode usability testing yang dapat digunakan ialah
System Usability Scale (SUS).
Black-Box :
 Kategori Pengujian

Nurhadryani dkk, 2013 :

[Link]
 Teknik Pengujian
Berdasarkan sifatnya, ada 2 kategori pengujian :

1. Pengujian Statis (Verification Testing)

Proses pengujian yang biasanya berlangsung pada tahap
pengembangan (development) yaitu pada saat program
belum dijalankan atau kode program belum dieksekusi.
Tujuannya adalah untuk melakukan pemeriksaan pada kode
program, dokumen, dan file perangkat lunak.
 Teknik Pengujian
Pengujian Statis (Verification Testing)
• Inspection: tujuan utamanya adalah untuk menemukan
kecacatan/defects, dilakukan oleh moderator dengan list pengecekan yang
sudah disiapkan
• Walkthrough: Teknik testing dengan melakukan meeting sehingga
participant dapat memberikan masukan/saran
• Technical Reviews: Teknik testing untuk memastikan pembuatan source
code telah memenuhi teknikal spesifikasi dan standard yang ditentukan.
• Informal Reviews: document direview secara informal dan tidak
berdasarkan prosedur, tujuannya adalah untuk meningkatkan kualitas
document.
 Teknik Pengujian
Berdasarkan sifatnya, ada 2 kategori pengujian :

2. Pengujian Dinamis
Proses pengujian dilakukan pada saat program sedang
berjalan/kode program sudah dieksekusi. Dengan
memasukan input kedalam program, kita dapat
membandingkan output yang diinginkan. Dengan cara ini kita
bisa melihat perilaku dari software, performance (kinerja),
serta memonitor memori dari sistem.
 Teknik Pengujian
Ada 3 teknik pengujian perangkat lunak (Roman, 2018) :
1. White-Box Testing (dinamis)
2. Black-Box Testing (statis)
3. Experience Based Testing (statis)
Teknik Pengujian
 Teknik Pengujian
White-Box Testing
• Teknik uji kotak putih disebut juga teknik struktural atau berbasis
struktur (source code) pada aplikasi yang akan dites, untuk
mengetahui apakah fungsi-fungsi internal telah berjalan dengan baik
dan benar sesuai dengan spesifikasi atau belum.
• Pengujian berdasarkan analisis arsitektur, desain, struktur internal, dan
algoritma programnya.
• Fokus pengujian pada pemrosesan dalam ujian obyek. Analisis struktur
internal objek uji digunakan untuk merancang pengujian kasus.
• Test ini biasanya dilakukan saat proses testing unit level.
 Teknik Pengujian
Black-Box Testing
• Teknik uji kotak hitam disebut juga teknik berbasis perilaku
(behavioral/input-output testing).

• Pengujian berdasarkan analisis dasar yang sesuai, misalnya:

persyaratan spesifikasi, kasus penggunaan, cerita pengguna,
proses bisnis, atau bahkan pengetahuan pelanggan atau akal
sehat.

• Fokus pengujian pada perilaku sistem yang diuji, yaitu pada input
dan output dari objek uji, tanpa mengacu pada struktur internalnya.
 Teknik Pengujian
Experience Based Testing

• Teknik tes berbasis pengalaman.

• Pengujian ini memanfaatkan pengetahuan dan pengalaman dari

pengembang, penguji, dan pengguna untuk menentukan apa yang
harus diuji.

• Teknik-teknik ini sering dikombinasikan dengan teknik uji Black-Box

dan White-Box.
 Black Box Testing
Model Pengujian Cacat “khas” yang dapat ditemukan
Teknik Pengujian
menggunakan teknik ini
Equivalence Penanganan data/nilai domain yang
Model Domain
Partitioning (EP) salah.
Boundary Value Penanganan data yang salah pada
Model Domain
Analysis (BVA) batasan domain.
Decision Table Testing Model Logika
Penanganan aturan bisnis yang salah.
(DTT) Keputusan
State Transition Penanganan transisi yang salah antar
Model Perilaku
Testing (STT) status.
Use Case Testing
Model Proses Bisnis Penanganan proses bisnis yang salah.
 Black-Box :
Equivalence Partitioning
• EP dilakukan ketika pengujian menyeluruh tidaklah memungkinkan untuk
dilakukan pada kondisi tertentu.
• Diberikan domain beberapa variabel dan penguji membaginya menjadi
sejumlah himpunan bagian tak kosong yang disebut kelas/partisi kesetaraan.
• Perancangan test case equivalence partitioning berdasarkan evaluasi kelas
equivalence untuk kondisi input yg menggambarkan kumpulan keadaan yang
valid atau tidak. Kondisi input dapat berupa nilai numerik, range nilai,
kumpulan nilai yang berhubungan atau kondisi Boolean.
• Test case bekerja berdasarkan asumsi bahwa kasus uji yang dirancang untuk
satu kelas mewakili semua nilai input yang lain dalam kelas yang sama (Zuriati
dkk, 2018).
 Black-Box :
Equivalence Partitioning
 Black-Box :
Equivalence Partitioning
 Black-Box :
Equivalence Partitioning

Tabel diatas yang berisikan hasil pengujian data normal yang artinya tabel ini
sesuai dengan cara pengisian data yang sebenarnya yang diisi atau diinputkan
oleh seorang yang berada pada ruang lingkup perangkat lunak.
 Black-Box :
Equivalence Partitioning

• Tabel diatas adalah contoh pengujian dengan teknik equivalence partitioning

dengan test case pada sesuai dengan tampilan yang diinginkan (form output).
• Pengujian ini dilakukan pada form yang sudah ada pada sistem informasi TPA
dengan memasukkan data yang tidak sesuai dengan tipe data atau
memasukkan data acak.
 Black-Box :
Boundary Value Analysis
• Boundary value analysis merupakan salah satu jenis teknik pengujian
Black Box yang melakukan pengujian pada batas atas dan batas bawah
dari suatu nilai yang diinput kedalam aplikasi.
• Ketentuan utama dari boundary value analysis (Hanifah & Alit, 2016)
adalah :
a) Boundary value analysis merupakan pelengkap dari teknik equivalence
partitioning testing yang hanya memperhatikan nilai input, sedangkan
pada boundary value analysis tidak hanya nilai input tapi juga
memperhatikan nilai output.
b) Boundary value analysis menguji input pada batas atas maupun batas
bawah sebuah nilai yang valid.
 Black-Box :
Boundary Value Analysis
 Black-Box :
Boundary Value Analysis
 Black-Box :
Boundary Value Analysis

• Tabel 5 adalah contoh pengujian dengan teknik boundary value analysis dengan test
case pada sesuai dengan gambar 4. Pengujian ini untuk memastikan bahwa masukkan
data yang melebihi batas yang sudah ditentukan tidak dapat tersimpan dengan baik
pada database, dan sistem hanya memunculkan data yang kurang dari batas data.
Black-Box :
 Black-Box :
Decision Tabel Testing
Contoh :
Operator menginputkan informasi hasil ujian mengemudi kedalam sistem mengikuti aturan
berikut :
a) Hasil akhir dari ujian tertulis (dalam numerik dengan range 0-100 poin)
b) Hasil akhir dari ujian praktek (dalam numerik ≥ 0 sebagai nilai dari banyaknya
kesalahan yang dilakukan selama ujian praktek)
• Kriteria penilaian : Peserta ujian akan mendapatkan lisensi mengemudi, jika dia
mendapatkan nilai 85-100 untuk ujian tertulis DAN jika dia melakukan maks.2x kesalahan
selama ujian praktek.
• Jika salah satu kriteria penilaian tidak terpenuhi, maka peserta masih diizinkan untuk
mengulang salah satu ujian saja (tertulis ATAU praktek mengemudi).
• Jika peserta gagal di kedua jenis ujian (tertulis dan praktek mengemudi), maka peserta
diharuskan mengikuti kedua jenis ujian tersebut (tertulis dan praktek mengemudi).
 Black-Box :
Decision Tabel Testing
 Black-Box :
Decision Tabel Testing
 Black-Box :
Decision Tabel Testing
 Black-Box :
State Transition Testing
• State transition testing dilakukan
dengan cara memeriksa aspek
perilaku sistem dengan batasan
waktu akses yang ditentukan.

• States : mewakili kondisi yang

memungkinkan dari sebuah sistem.

• Transitions : mewakili kemungkinan

perubahan dari 1 status ke status
lainnya/
 Black-Box :
State Transition Testing
• Events : mewakili hal-hal eksternal yang
mungkin terjadi dan memicu
perubahan state.

• Actions : mewakili aktivitas yang

mungkin dilakukan oleh sistem saat
mengalami perubahan state.

• Guard Conditions : mewakili kondisi

tambahan untuk memicu transitions.
Guard conditions digunakan jika ada
lebih dari 1 kemungkinan transisi dari
state yang sama dan pada 1 event yang
sama.
 Black-Box :
State Transition Testing
Contoh :
State : "Layar Masuk" (ketika sistem menampilkan layar login dan
menunggu pengguna untuk login)

Event : "Menekan Tombol Login" (kejadian yang dapat dilihat sebagai

situasi yang terjadi secara cepat dan segera)
 Black-Box :
State Transition Testing
Contoh :
 Black-Box :
State Transition Testing
• States :
– Sistem baru dibuat (New),
– Sistem diperbaiki (Fixing),
– Memverifikasi hasil perbaikan sistem (Verifiying),
– Sistem ditutup (Close).

• Events (kejadian/peristiwa) :
– Kerjakan (assign),
– OK (lanjut ke state berikutnya),
– Tidak OK (kembali ke state sebelumnya/ulangi state
yg sekarang).

• Kesimpulan :
– 4 states dan 3 Events
– 4 States x 3 Event = 12 Transisi Penuh
– 5 Valid Transitions
 Black-Box :
State Transition Testing
• Actions :
– OK tanpa PrintMsg,
– OK atau Beri informasi saat sistem sudah
selesai diperbaiki (OK/PrintMsg),
– Harus beri informasi saat sistem sudah
selesai diperbaiki (OK+PrintMsg),
– Jika x>0 (guard conditions), maka dianggap
OK (dengan atau tanpa PrintMsg).

• Guard Conditions :
Misalnya :
– perbaikan sudah dilakukan minimal 1 kali
[X>0]
– Fault ≤ 0
 Black-Box :
State Transition Testing
Latihan 1:
Mengidentifikasi Perilaku yang Benar dari State
Machine pada Gambar disamping.

Gambar tersebut menyajikan diagram transisi keadaan

yang memodelkan proses pemesanan di beberapa
toko elektronik.

Manakah yang merupakan perilaku yang tidak

diharapkan dari sistem yang dimodelkan pada diagram
tersebut?
(a) Ketika sistem menunjukkan keranjang belanja,
klien dapat melakukan pembayaran.
(b) Saat sedang melakukan proses pembayaran
(belum dibayar), klien dapat kembali ke
keranjang belanjanya.
(c) Saat membayar, jika terjadi kesalahan,
sistem akan kembali ke layar checkout.
(d) A dan C adalah perilaku yang tidak diharapkan
(e) A dan B adalah perilaku yang diharapkan
 Black-Box :
State Transition Testing
Latihan 2:
Mengidentifikasi Urutan yang Benar Lihat
state machine dari Gambar disamping.

Manakah dari rangkaian peristiwa berikut

tidak valid?
(A) AddItem, Finalize, GoBack, Finalize
(B) ToCatalog, AddItem, Finalize,
Payment
(C) GoBack, ToCatalog
(D) ToCatalog, ToCatalog, Finalize,
Payment , TransactionConfirmed
(E) AddItem, Payment,
TransactionConfirmed
(F) ToCatalog, AddItem, ToCatalog,
AddItem, Finalize, GoBack, Finalize,
Payment
 Black-Box :
Use Case Testing
• Sebuah use case menentukan perilaku sistem yang berinteraksi
dengan satu atau lebih aktor menghasilkan hasil nilai yang dapat
diamati bagi para aktor.
• Aktor biasanya adalah pengguna, tapi mungkin juga sistem lainnya.
• Kasus usabilitas yang terstruktur dengan baik menunjukkan esensial
perilaku sistem atau subsistem saja, dan tidak terlalu umum atau
terlalu spesifik, serta tidak ada cara standar untuk menulis kasus uji.
• Menurut Silabus ISTQB® Foundation 2018, use case harus terdiri
dari:
– Prasyarat / Pre-Condition (opsional)
– Pasca-kondisi / Post-Condition (hasil yang dapat diamati) [jaminan sukses]
– Hanya satu jalur utama / Main-Path [skenario sukses utama]
– Jalur alternatif / Alternate-Path (0 atau lebih) [teknologi & daftar variasi data]
– Jalur pengecualian / Exception-Path (0 atau lebih) [ekstensi]
 Black-Box :
Use Case Testing
Contoh :
Menganalisis Use Case Perhatikan kutipan berikut dari use case
“Pesan minuman dari Vending Mechine (mesin penjual otomatis)“

Pra-kondisi:
Mesin dalam keadaan awal, menampilkan layar selamat datang.

Langkah skenario utama:

1. Pengguna memilih jenis minuman “Soda-1”.
2. Mesin menunjukkan harga Soda-1 (80 sen).
3. Seorang pengguna memasukkan 80 sen ke dalam slot koin.
4. Mesin mengembalikan/memberikan minuman Soda-1.
 Black-Box :
Use Case Testing
Jalur alternatif:
3a. Seorang pengguna memasukkan lebih dari 80 sen (mesin mengembalikan
uang kembalian pada langkah 4).
3b. Seorang pengguna membatalkan operasi (mesin mengembalikan uang dan
kembali ke layar selamat datang).

Pengecualian:
2. Tidak ada minuman "Soda-1" di dalam mesin.
 Black-Box :
Use Case Testing
 Black-Box :
Use Case Testing
Pertanyaan :
(a) Berapa banyak kasus uji (test case) yang diperlukan untuk menyelesaikan
kasus usabilitas tersebut?

Jawab :
• (Main path): 1, 2, 3, 4
• (Alternative path 3a): 1, 2, 3a
• (Alternative path 3b): 1, 2, 3b
• (Exception 2): 1, 2E
 Black-Box :
Use Case Testing
(Main path): 1, 2, 3, 4
1. Pengguna memilih jenis minuman “Soda-1”.
2. Mesin menunjukkan harga Soda-1 (80 sen).
3. Seorang pengguna memasukkan 80 sen ke dalam slot koin.
4. Mesin mengembalikan/memberikan minuman Soda-1.

(Alternative path 3a): 1, 2, 3a

5. Pengguna memilih jenis minuman “Soda-1”.
6. Mesin menunjukkan harga Soda-1 (80 sen).
3a. Seorang pengguna memasukkan lebih dari 80 sen (mesin mengembalikan
uang kembalian pada langkah 4).
 Black-Box :
Use Case Testing
(Alternative path 3b): 1, 2, 3b
1. Pengguna memilih jenis minuman “Soda-1”.
2. Mesin menunjukkan harga Soda-1 (80 sen).
3b. Seorang pengguna membatalkan operasi (mesin mengembalikan uang dan
kembali ke layar selamat datang).

(Exception 2): 1, 2E
1. Pengguna memilih jenis minuman “Soda-1”.
2E. Tidak ada minuman "Soda-1" di dalam mesin.
 Black-Box :
Use Case Testing
Pertanyaan :
(b) Cakupan apa yang dicapai oleh keempat kasus uji yang ditunjukkan di atas
(TC1 sampai TC4)?

Jawab :
• TC1 tidak mencakup apa pun dalam kasus usabilitas tersebut, dalam kasus
uji ini, pengguna juga bisa saja memilih minuman "Soda-2", bukan minuman
"Soda-1".
• TC2, TC3, dan TC4 masing-masing mencakup: jalur alternatif 3a, jalur
alternatif 3b, dan pengecualian dalam langkah 2.
• Secara keseluruhan, keempat kasus uji ini mencakup 3 dari 4 jalur kasus
usabilitas, jadi mereka mencapai cakupan 3/4 = 75%.
 Black-Box :
Use Case Testing
Pertanyaan :
(c) Manakah dari kasus uji TC1–TC4 yang mencakup jalur alternatif 3b?

Jawab :
Jalur alternatif 3b masuk dalam cakupan TC3.
Black-Box :
Black-Box :
 White Box Testing
• Pengujian kotak putih didasarkan pada struktur perangkat lunak sistem.

• Umumnya digunakan pada tingkat pengujian komponen (disebut pengujian

unit), tetapi mungkin juga diterapkan pada tingkat pengujian lainnya
menggunakan model kotak putih yang berbeda dari perangkat lunak,
misalnya:
– Grafik panggilan pada tingkat integrasi
– Proses bisnis di tingkat sistem
– Struktur menu pada tingkat pengujian penerimaan

• Pada tingkat pengujian komponen, model biasanya berupa kode sumber.

Kode sumber ini digunakan untuk merancang kasus uji yang mencakup
beberapa elemen struktural kode (pernyataan, keputusan, dll).
 White Box Testing
• Hasil yang diharapkan dari tes semacam itu tentu saja harus ditentukan
berdasarkan sumber eksternal, seperti: spesifikasi persyaratan atau jenis
dokumentasi lainnya.

• Karakteristik umum dari teknik uji kotak putih adalah sebagai berikut:
– Kondisi uji, kasus uji, dan data uji diturunkan dari basis pengujian yang mungkin termasuk
kode, arsitektur perangkat lunak, desain terperinci, atau sumber lainnya informasi mengenai
struktur perangkat lunak.
– Cakupan diukur berdasarkan item yang diuji dalam struktur yang dipilih (misalnya, kode
atau antarmuka).
– Spesifikasi sering digunakan sebagai sumber informasi tambahan untuk menentukan hasil
yang diharapkan dari kasus uji.
 White Box Testing:
Control Flow Graph (CFG)
 White Box Testing:
Control Flow Graph (CFG)
 White Box Testing:
Control Flow Graph (CFG)
 White Box Testing:
Control Flow Graph (CFG)
a) Statement Testing
10 kode baris dari gambar disamping,
Jumlah minimal kasus uji yang mencapai
cakupan pernyataan (100%) ada 2 test
case, karena baris 7 dan 8 tidak dapat
dieksekusi dalam satu pengujian.

Dua kasus uji sampel dapat mengikuti

jalur berikut:
• Tes 1: 1, 2, 3, 4, 5, 3, 6, 7, 9, 10 = 90%
• Tes 2: 1, 2, 3, 6, 8, 9, 10 = 70%
 White Box Testing:
Control Flow Graph (CFG)
b) Decision Testing
Terdapat 3 node keputusan (decision),
yaitu {1,2}, {3}, dan {6}. Dimana ketiganya
memiliki nilai True dan False, sehingga
ada 6 kondisi keputusan yang harus
dicakup, yaitu :
• Keputusan {1,2} bernilai True
• Keputusan {1,2} bernilai False
• Keputusan {3} bernilai True
• Keputusan {3} bernilai False
• Keputusan {6} bernilai True
• Keputusan {6} bernilai False
 White Box Testing:
Control Flow Graph (CFG)
b) Decision Testing (lanjutan)

Dari 6 kondisi tersebut dapat dibentuk

3 test case, yaitu :
• Test 1: 1, 2, 9, 10
• Test 2: 1, 2, 3, 4, 5, 3, 6, 7, 9, 10
• Test 3: 1, 2, 3, 6, 8, 9, 10
 White Box Testing
• Beberapa jenis white box testing yang lainnya seperti : Cyclomatic
Complexity, Graph Metric, Condition testing, Condition/decision (C/D)
testing, Modified condition/decision coverage (MC/DC), Multiple condition
testing, dan Path testing tidak dibahas dalam ISTQB Syllabus 2018 (Silabus
software testing edisi 2018-).
 Experience Testing
• Experience Based Test (EBT) hampir sama
dengan Black Box Testing.
 Experience Based Testing
• Teknik pengujian yang didasarkan pada keterampilan dan pengalaman
penguji, pakar, pengguna, dll.
• Pengujian ini “bisa saja” dilakukan karena tidak tersedia spesifikasi yang
tepat untuk menguji aplikasi. Di sini penguji bergantung pada pengalaman
masa lalu dengan teknologi yang sama. Penguji sesuai pengalamannya
berfokus pada area penting dari perangkat lunak, seperti area yang paling
sering digunakan oleh pelanggan atau area yang paling mungkin gagal.
• Pengalaman yang dimaksud bisa saja dari teknik berbasis spesifikasi atau
teknik berbasis struktur atau desain dari perangkat lunak (black box dan
white box).
• Teknik ini digunakan untuk sistem risiko rendah. Pengujian semacam ini
dilakukan bahkan ketika tidak ada spesifikasi atau memiliki daftar spesifikasi
yang tidak memadai.
 Experience Testing
1. Teknik menebak kesalahan (Error guessing) :
1. Bertujuan untuk mengidentifikasi cacat yang mungkin tidak mudah
ditangkap dengan teknik yang lebih formal.

2. Biasanya dilakukan setelah teknik yang lebih formal selesai.

3. Kesalahan meliputi: bagi dengan nol, pointer nol atau parameter tidak
valid.
 Experience Testing
2. Teknik eksplorasi (Exploratory):
1. Digambarkan sebagai pembelajaran simultan, desain tes, dan
pelaksanaan tes.
2. Pengujian ini diterapkan ketika penguji tidak memiliki kasus uji dan
perencanaan pengujian.
3. Kekurangan waktu daripada penguji berpengalaman menggunakan
pengetahuan mereka.
4. Data tidak mencukupi.
 Experience Testing
3. Pengujian berbasis daftar periksa (Checklist based):
1. Pengujian ini adalah versi kasus uji yang lebih kecil. Dimana penguji
hanya perlu menentukan kasus mana yang perlu diuji tanpa
memasukkan banyak informasi ke dalamnya.
2. Pengujian ini termasuk item yang akan diperiksa, daftar aturan atau
kondisi data yang akan diverifikasi.
 Experience Testing
4. Teknik serangan kesalahan:
1. Pengujian ini meningkatkan total area pengujian lengkap dengan
memasukkan kesalahan ke dalam perangkat lunak untuk menguji
keputusan.
2. Ketika Anda menjalankan program jika ada kesalahan, itu disebut
kesalahan. Dimana kesalahan simultan (fault) adalah keadaan
perangkat lunak yang disebabkan oleh kesalahan parsial (error).
Pemeliharaan Sistem
 Jaminan Kualitas
Menurut Tian (2005), ada lima pandangan mengenai perspektif
kualitas perangkat lunak, diantaranya :
1. Transcendental (diluar nalar),
2. Pengguna,
3. Manufaktur,
4. Produk akhir, dan
5. Penilaian.
 Jaminan Kualitas
Transcendental adalah sebuah hal yang memaksa pengguna untuk
berpikir keras bagaimana caranya menjelaskan secara gamblang
(detil) mengenai definisi kualitas perangkat lunak yang dipakai dan
dirasakan kepada orang (pengguna) lainnya.

Hal ini terkait dengan sesuatu yang disebut “kualitas yang tidak
berwujud namun dapat dirasakan”.
 Jaminan Kualitas
• Untuk bisa menyamakan persepsi mengenai kualitas ini dibutuhkan
sebuah alat ukur yang menggunakan ukuran atau satuan yang
dapat disepakati bersama.

• Para pengguna sendiri memandang kualitas perangkat lunak

sebagai penyelarasan tujuan untuk dapat memenuhi kebutuhan
mereka.

• Sedangkan dari sisi manufaktur, kualitas dipandang sebagai

kesesuaian dan kepatuhan terhadap standar proses dalam
pembangunan atau pengembangan perangkat lunak.
 Jaminan Kualitas
Dalam ISO 9126-1, kualitas sebuah produk perangkat lunak
dikategorikan menjadi empat bagian (lihat pada tabel 1), diantaranya :
• Kualitas internal (dinilai dari kualitas pemrogramannya),
• Kualitas eksternal (dinilai pada saat perangkat lunak tersebut
dieksekusi atau diuji coba),
• Kualitas penggunaan (dinilai dari sejauh mana kebutuhan
pengguna terpenuhi di lingkungan kerja end-user), dan
• Kualitas proses (dinilai dari kematangan perencanaan kebutuhan
dan standar pemenuhan kebutuhan dalam proyek rekayasa
perangkat lunak).
 Jaminan Kualitas

Kategori Kualitas Perangkat lunak Berdasarkan ISO/IEC 9126

 Jaminan Kualitas
Proses
(Pengukuran kualitas dilakukan selama
proyek rekayasa perangkat lunak dimulai
sampai dengan selesai)
Kualitas
Perangkat Lunak
Produk
(Pengukuran kualitas perangkat lunak
sebagai produk akhir dari proyek rekayasa
perangkat lunak)

Pengukuran Kualitas Perangkat Lunak Dalam Proyek Rekayasa Perangkat Lunak

Jaminan Kualitas
 Jaminan Kualitas
Dalam ISO/IEC 12207: 1995, ada tiga jenis proses yang dapat diukur
untuk mendapatkan definisi kualitas perangkat lunak (Berander et al.,
2005, p.6), diantaranya :
• Proses primer (primer process), terdiri dari akuisisi, suplai,
pengembangan, operasional, dan pemeliharaan sistem.
• Proses pendukung (supporting process), terdiri dari dokumentasi,
manajemen konfigurasi, jaminan kualitas, verifikasi, validasi, review
bersama, audit, dan pemecahan masalah.
• Proses organisasi (organization process), terdiri dari manajemen
perusahaan, infrastruktur, perbaikan, dan pelatihan.
 Jaminan Kualitas
• Standar Kualitas : ISO 🡪 [Link]
o ISO/IEC 15504,
o ISO/IEC 12207,
o ISO 9000,
o ISO 25010 (pengganti ISO 9126)
o ISO 9241
o ISO 29119
o IEEE Std 1074:1997 (developing software life cycle process),
o IEEE Std 730:1998 (software quality assurance plans),
o IEEE Std 828:1998 (software configuration management plans-description),
o IEEE Std 829:1998 (software test documentation),
o IEEE Std 830:1998 (recommended practice for software requirements specifications),
o IEEE Std 1058:1998 (software project management plans).
 ISO / IEC 25010
Pada tahun 2011, Standard ISO/IEC 9126 digantikan dengan Standard
ISO/IEC 25010 :
[ISO/IEC 25010:2011, Systems and software engineering —Systems and software
Quality Requirements and Evaluation (SQuaRE) --System and software quality models.]

ISO/IEC 25010 mempartisi kualitas perangkat lunak menjadi tiga

model:
• Kualitas dalam model yang digunakan (quality in use model),
• Model kualitas produk (product quality model), dan
• Model kualitas data (data quality model).
 ISO / IEC 25010
✔ Model kualitas yang digunakan (quality in use model) terdiri dari karakteristik :
Efektivitas (effectiveness), kepuasan (satisfaction), kebebasan dari risiko (freedom
from risk), dan cakupan konteks (context coverage).

✔ Model kualitas produk (product quality model) terdiri dari keberlanjutan

fungsional, efisiensi kinerja, kompatibilitas, kegunaan, keandalan, keamanan,
pemeliharaan, dan portabilitas (layaknya seperti di ISO/IEC 9126).

✔ Kualitas data (data quality model) didefinisikan dalam ISO/IEC 25012 :

[ISO/IEC 25012:2008, Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Data
quality model [ISO 29119], standard ini adalah seri terbaru dalam standards pengujian perangkat lunak (software testing).
Seri ini telah divalidasi menjadi silabus pengujian kualitas data pada perangkat lunak sejak tahun 2015].
 Part of ISO/IEC 29119
ISO/IEC/IEEE 29119-1:2013 Software and systems engineering – Software testing – Part 1:
Concepts and definitions

ISO/IEC/IEEE 29119-2:2013 Software and systems engineering – Software testing – Part 2: Test
processes

ISO/IEC/IEEE 29119-3:2013 Software and systems engineering – Software testing – Part 3: Test
documentation

ISO/IEC/IEEE 29119-4 (Draft International Standard in February 2014) Standard Systems and
software engineering—Software testing—Part 4: Test techniques
Part of ISO/IEC 9241-11
 Jaminan Kualitas
• Model Kualitas :
• Technology Acceptance Model (TAM),
• Perceived Usefulness,
• Perceived Ease of Use,
• Usability Nielson dan Heuristic Usability Nielson(Nielsen, 2012;
Nielsen, 1995),
• Usability Preece,
• User Satisfaction Green-Pearson,
• User Satisfaction Venkatesh,
• User Satisfaction Palmer,
• Web Qual
 Jaminan Kualitas
• Beberapa karaktersitik yang disoroti untuk dijadikan acuan pengukuran
usabilitas perangkat lunak, diantaranya konteks penggunaan oleh user
(usability), konsistensi, visibilitas, error prevention, rekognisi, fleksibilitas,
aesthetic, pusat bantuan, efisiensi, efektifitas, dan kenyamanan pengguna.
• Secara resmi pada tahun 2020 dalam web korporasinya, Nielson
memperbarui artikelnya mengenai karakteristik usabilitas. Nielson
menambahkan lebih banyak penjelasan, contoh, dan tautan terkait mengenai
usabilitas dan merumuskan 10 karakteristik dalam model heuristic usability
bersama rekannya Rolf Molich (Nielsen & Molich, 1990; Molich, 1994).
• Sepuluh karakteristik heuristik ini dinilai masih tetap relevan dan tidak
berubah sejak awal model ini dirumuskan tahun 1994 sampai sekarang, dan
kemungkinan masih dapat berlaku juga bagi penilaian antarmuka pengguna
dimasa yang akan datang.
 Jaminan Kualitas
• Kuesioner :
o Questionnaire for User Interaction Satisfaction (QUIS),
o Software Usability Measurement Inventory (SUMI),
o Post-Study System Usability Questionnaire (PSSUQ),
o Software Usability Scale (SUS) (Brooke, 1996; Bangor et al., 2008; Lewis et al., 2015; Lewis,
2018),
o Expectation ratings (ER),
o Usability Magnitude Estimation (UME),
o Computer System Usability Questionnaire (CSUQ),
o Usefulness, Satisfaction, and Ease-of-Use (USE),
o Usability Metric for User Experience (UMUX),
o Hedonic Quality (HQ),
o Customer Experience Index (CxPi).
o User Experience Questionnaire (UEQ).
Pustaka Lainnya :
1) Bangor, A., Kortum, T. P., & Miller, J. (2008). An empirical evaluation of the system usability scale. International Journal of Human–Computer Interaction.
International Journal of Human–Computer Interaction, 24(6).
2) Bentro, H. C., Rokhmawati, R. I., & Brata, K. C. (2019). Analisis Dan Perbaikan Aplikasi UB Bookstore Berdasarkan Aspek Usability ( ISO 9241-11 ). Jurnal
Pengembangan Teknologi Informasi Dan Ilmu Komputer, 3(1).
3) Berander, P., Damm, L.-O., Eriksson, J., Gorschek, T., Henningsson, K., Jönsson, P., Kågström, S., Milicic, D., Mårtensson, F., Rönkkö, K., & Tomaszewski, P.
(2005). Software quality attributes and trade-offs. June, 1–100. [Link]
4) Brooke, J. (1996). SUS -A quick and dirty usability scale Usability and context. Usability Evaluation in Industry, 189(194).
5) De Groot, T., Vos, T., Vogels, R. J. M. J., & Van Driel, W. D. (2013). Quality and reliability in solid-state lighting. In Solid State Lighting Reliability:
Components to Systems. [Link]
6) Green, D., & Pearson, J. M. (2006). Development of a Web site usability instrument based on ISO 9241-11. Journal of Computer Information Systems,
47(1). [Link]
7) Handayani, F. S. (2015). Perancangan Alat Ukur Kualitas Perangkat Lunak Menggunakan Komponen ISO/IEC 9126. E-JURNAL JUSITI: Jurnal Sistem
Informasi …, Oktober 2015.
8) Handayani, F. S. (2018). Perencanaan Strategi Sistem Informasi Dalam Kegiatan Penelusuran Minat Siswa Sekolah Menengah Pertama. Mikrotik : Jurnal
Manajemen Informatika, 8(1), 74–86. [Link]
9) Handayani, F. S. (2021). Desain Instrumen Pengujian Usabilitas Aplikasi Menggunakan Heuristic Usability Nielson. JSAI (Journal Scientific and Applied
Informatics), 4(1). [Link]
10) Handayani, F. S., & Adelin, A. (2019). Interpretasi Pengujian Usabilitas Wibatara Menggunakan System Usability Scale. [Link], 18(4).
[Link]
11) IEEE. (1999). IEEE Standard for Software Maintenance, IEEE Std 1219-1998. In IEEE Standards Software Engineering, Volume Two: Process Standards
(Vol. 1998).
Pustaka Lainnya :
12) Khumaidi, A., Suryana, A., & Ridhawati, E. (2016). Perencanaan Strategi Sistem Informasi dan Teknologi Informasi Pada STMIK Pringsewu Dengan
Menggunakan Metodologi Enterprise Architecture Planning ( EAP). Seminar Nasional Teknologi Informasi Dan Multi Media, 3.
13) Lewis, J. R. (2018). Measuring Perceived Usability: The CSUQ, SUS, and UMUX. International Journal of Human-Computer Interaction, 34(12).
[Link]
14) Lewis, J. R., Brown, J., & Mayes, D. K. (2015). Psychometric Evaluation of the EMO and the SUS in the Context of a Large-Sample Unmoderated Usability
Study. International Journal of Human-Computer Interaction, 31(8). [Link]
15) Mardiana, M. (2020). Implementasi User Satisfaction Model Dalam Mengukur Kualitas Website. MATRIK : Jurnal Manajemen, Teknik Informatika Dan
Rekayasa Komputer, 19(2). [Link]
16) Miguel, P. J., Mauricio, D., & Rodríguez, G. (2014). A Review of Software Quality Models for the Evaluation of Software Products. International Journal of
Software Engineering & Applications, 5(6). [Link]
17) Molich, R. (1994). Preventing user interface disasters. Behaviour and Information Technology, 13(1–2). [Link]
18) Munanto, T. C., Hartanto, R., & Fauziati, S. (2020). Pengujian Usabilitas Website Sistem Seleksi Calon Pegawai Negeri Sipil Nasional (SSCN) Badan
Kepegawaian Negara (BKN). Jurnal ELTIKOM, 4(1). [Link]
19) Nielsen, J. (1995). 10 Usability Heuristics for User Interface Design. In Conference companion on Human factors in computing systems CHI 94.
20) Nielsen, J. (2012). Usability 101: Introduction to Usability. [Link]
21) Nielsen, J., & Molich, R. (1990). Heuristic Evaluation of User Interface Inspection Methods. CHI ’90, April.
22) Palmer, J. W. (2002). Web site usability, design, and performance metrics. Information Systems Research, 13(2). [Link]
23) Pressman, R. S. (2012). Software-Engineering 7th ED by Roger S. Pressman. In Software Engineering A Practitioner’s Approach.
Pustaka Lainnya :
24) Ramulu, K. P., & Murhtyr, B. R. (2018). IMPORTANCE OF SOFTWARE QUALITY MODELS IN SOFTWARE ENGINEERING. IMPORTANCE OF SOFTWARE
QUALITY MODELS IN SOFTWARE ENGINEERING.‖ International Journal of Engineering Technologies and Management Research, 5(3).
25) Rosalina, V., & Harsiti. (2016). Pemodelan Decision Support System. Jurnal ProTekInfo Vol.3 No.1 September 2016, 3(1), 1–7.
26) Sauro, J., & Lewis, J. R. (2016). Quantifying the User Experience, Chapter 8: Standardized Usabilty Questionnaires. In Quantifying the User Experience.
27) Tian, J. (2005). Software Quality Engineering : Testing, Quality Assurance, and Quantifiable Improvement. In Kybernetes (Vol. 27, Issue 4). IEEE Computer
Society. [Link]
28) Travis, D. (2011). ISO 13407 is dead. Long live ISO 9241-210! Userfocus.
29) Trisnadoli, A. (2015). ANALISIS KEBUTUHAN KUALITAS PERANGKAT LUNAK PADA SOFTWARE GAME BERBASIS MOBILE. Jurnal Komputer Terapan, 1(2).
30) Vanitha, N., & Thirumalai, S. R. (2014). A Report on the Analysis of Metrics and Measures on Software Quality Factors – A Literature Study. International
Journal of Computer Science and Information Technologies, 5(5).

31) [Link]
32) [Link]
33) [Link]
34) [Link]