SlideShare a Scribd company logo
1 of 154
MULAI MATERI
Software Testing
STMIK PalComTech
Bahan Kajian
• Kualitas Perangkat Lunak
• Terminologi Kegagalan (Failure),
Kesalahan (Error/Fault), Cacat (Defect),
dan Bug
• 7 Prinsip Pengujian Perangkat Lunak
• Proses Pengujian
• V-Model
1
Bahan Kajian
• Alat Pengujian
• Teknik Pengujian
–Black Box Testing
–White Box Testing
–Experience Testing Referensi :
• ISTQB
• ISO
• V-Model
2
Bahan Kajian
• Perawatan Sistem
• Jaminan Kualitas
Referensi :
• ISTQB
• ISO
• V-Model
3
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 et.all. (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.
1. Pengujian perangkat lunak sebagai sarana untuk memastikan kualitas perangkat
lunak.
1. 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.
• Definisi kualitas dari sebuah perangkat lunak
merupakan aktualisasi dari pengalaman dan
kepuasan para penggunanya.
• Sebuah perangkat lunak dapat dinyatakan
berkualitas, maka terlebih dahulu harus
dilakukan pengujian (testing) dan pengukuran
(measurement) tingkat kualitasnya.
• Pengujian juga dimaksudkan untuk
memastikan apakah perangkat lunak tersebut
benar-benar dapat digunakan (useable) oleh
penggunanya [Handayani & Adelin, 2019].
Testing for Quality
Usability
Experience Satisfaction
QUALITY
USER
Software
Testing
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) -
http://www.istqb.org
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.
1. 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.
Error, Fault, Defect, Bug, Failure
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.
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
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.
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.
7 Prinsip Pengujian Software
Proses Pengujian
Model Proses
Software Testing:
V-Modell
.
• 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
(extends the waterfall process)
• Kiri = SDLC (development
activities)
• Kanan = Proses pengujian
(testing activities)
• V = Verifikasi & Validasi
• Diusulkan oleh Paul Rook
(1980)
V-Model (tradisional)
V-Model (tradisional)
Spillner, 2014 Mathur & Malik, 2010
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 (tradisional)
• 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.
V-Model (advanced)
• 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 :
• Menganalisa Requirement
• Membuat test plan
• Membuat test case
• Eksekusi dari test case
• Mencari kecacatan
• Memperbaiki kecacatan
Alat Pengujian
Langkah-langkah Automation
Testing :
• Menilai dan mengevaluasi alat
pengujian yang dipakai.
• Merancang test case
• Melakukan Implementasi test
case menggunakan testing tools
• Membuat laporan pengujan
• Melakukan pengecekan hasil
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.
Alat Pengujian
Bahan Kajian
• Kategori Pengujian
• Teknik Pengujian
Referensi :
• ISTQB
• ISO
• V-Model
3
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 :
https://journal.ipb.ac.id/index.php/jika/article/view/7997
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.
Teknik Pengujian Model Pengujian
Cacat “khas” yang dapat ditemukan
menggunakan teknik ini
Equivalence Partitioning
(EP)
Model Domain Penanganan data/nilai domain yang salah.
Boundary Value Analysis
(BVA)
Model Domain
Penanganan data yang salah pada batasan
domain.
Decision Table Testing
(DTT)
Model Logika
Keputusan
Penanganan aturan bisnis yang salah.
State Transition Testing
(STT)
Model Perilaku
Penanganan transisi yang salah antar
status.
Use Case Testing (UCT) Model Proses Bisnis Penanganan proses bisnis yang salah.
Black Box Testing
• 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 :
Equivalence Partitioning
• 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 :
Boundary Value Analysis
Black-Box :
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 :
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
• 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
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
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
1. Pengguna memilih jenis minuman “Soda-1”.
2. 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 :
Use Case Testing
Black-Box :
Black-Box :
• 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
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
• 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-).
White Box Testing
• Experience Based Test (EBT) hampir sama
dengan Black Box Testing.
Experience 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 Based Testing
1. Teknik menebak kesalahan (Error guessing) :
1. Bertujuan untuk mengidentifikasi cacat yang mungkin tidak mudah
ditangkap dengan teknik yang lebih formal.
1. Biasanya dilakukan setelah teknik yang lebih formal selesai.
1. 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).
Experience Testing
Pemeliharaan Sistem
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
Jaminan Kualitas
Kategori Kualitas Perangkat lunak Berdasarkan ISO/IEC 9126
Jaminan Kualitas
Pengukuran Kualitas Perangkat Lunak Dalam Proyek Rekayasa Perangkat Lunak
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)
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 🡪 http://ww.iso.org
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).
Jaminan Kualitas
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].
ISO / IEC 25010
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 29119
Part of ISO/IEC 9241-11
• 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).
Jaminan Kualitas
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. http://www.bth.se/besq.
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. https://doi.org/10.1007/978-1-4614-3067-4_1
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). https://doi.org/10.1080/08874417.2006.11645940
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. https://ojs.ummetro.ac.id/index.php/mikrotik/article/view/749
9) Handayani, F. S. (2021). Desain Instrumen Pengujian Usabilitas Aplikasi Menggunakan Heuristic Usability Nielson. JSAI (Journal Scientific and Applied
Informatics), 4(1). https://doi.org/10.36085/jsai.v4i1.1346
10) Handayani, F. S., & Adelin, A. (2019). Interpretasi Pengujian Usabilitas Wibatara Menggunakan System Usability Scale. Techno.Com, 18(4).
https://doi.org/10.33633/tc.v18i4.2882
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).
https://doi.org/10.1080/10447318.2017.1418805
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). https://doi.org/10.1080/10447318.2015.1064665
15) Mardiana, M. (2020). Implementasi User Satisfaction Model Dalam Mengukur Kualitas Website. MATRIK : Jurnal Manajemen, Teknik Informatika Dan
Rekayasa Komputer, 19(2). https://doi.org/10.30812/matrik.v19i2.711
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). https://doi.org/10.5121/ijsea.2014.5603
17) Molich, R. (1994). Preventing user interface disasters. Behaviour and Information Technology, 13(1–2). https://doi.org/10.1080/01449299408914594
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). https://doi.org/10.31961/eltikom.v4i1.139
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. https://www.nngroup.com/articles/usa%0Ability-101-introduction-to-usability
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).
https://doi.org/10.1287/isre.13.2.151.88
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. https://doi.org/10.1108/k.1998.27.4.457.4
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).
24) https://hell.meiert.org/core/pdf/sus.pdf
25) http://uxpajournal.org/wp-content/uploads/pdf/JUS_Bangor_May2009.pdf
26) https://measuringu.com/wp-content/uploads/2017/07/Lewis_Sauro_HCII2009.pdf
27) https://www.ueq-online.org/
Pustaka Lainnya :
SoftwareTesting
SoftwareTesting
SoftwareTesting
SoftwareTesting
SoftwareTesting
SoftwareTesting

More Related Content

What's hot

Jenis dan proses interupsi
Jenis dan proses interupsiJenis dan proses interupsi
Jenis dan proses interupsilaurensius08
 
Metode proses pengembangan perangkat lunak
Metode proses pengembangan perangkat lunakMetode proses pengembangan perangkat lunak
Metode proses pengembangan perangkat lunakMoch. Nor Kholis
 
Ppt: Usability (Interaksi Manusia dan Komputer)
Ppt: Usability (Interaksi Manusia dan Komputer)Ppt: Usability (Interaksi Manusia dan Komputer)
Ppt: Usability (Interaksi Manusia dan Komputer)agungt4565
 
Testing dan implementasi_sistem_-_romeo
Testing dan implementasi_sistem_-_romeoTesting dan implementasi_sistem_-_romeo
Testing dan implementasi_sistem_-_romeoAbrianto Nugraha
 
Incremental development (pengembangan incremental)
Incremental development (pengembangan incremental)Incremental development (pengembangan incremental)
Incremental development (pengembangan incremental)Fitria Hati
 
04 Testing Perangkat Lunak
04 Testing Perangkat Lunak04 Testing Perangkat Lunak
04 Testing Perangkat LunakMrirfan
 
Rancangan perangkat lunak
Rancangan perangkat lunakRancangan perangkat lunak
Rancangan perangkat lunakAinul Yaqin
 
Manajemen Resiko (Tugas RPL)
 Manajemen Resiko (Tugas RPL)  Manajemen Resiko (Tugas RPL)
Manajemen Resiko (Tugas RPL) viiasilviaa
 
metode-pengujian-blackbox
 metode-pengujian-blackbox metode-pengujian-blackbox
metode-pengujian-blackboxIwan Kurniarasa
 
3 rekayasa kebutuhan
3 rekayasa kebutuhan3 rekayasa kebutuhan
3 rekayasa kebutuhanObey Rohman
 
Evolusi perkembangan rekayasa perangkat lunak
Evolusi perkembangan rekayasa perangkat lunakEvolusi perkembangan rekayasa perangkat lunak
Evolusi perkembangan rekayasa perangkat lunakFebry San
 
Pertemuan 4-5-6 Metode Pelacakan dan Pencarian
Pertemuan 4-5-6 Metode Pelacakan dan PencarianPertemuan 4-5-6 Metode Pelacakan dan Pencarian
Pertemuan 4-5-6 Metode Pelacakan dan PencarianEndang Retnoningsih
 
LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...
LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...
LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...Uofa_Unsada
 
Rekayasa Perangkat Lunak
Rekayasa Perangkat LunakRekayasa Perangkat Lunak
Rekayasa Perangkat LunakYudi Purwanto
 
Contoh Review Jurnal Ilmiah (PENGARUH KEPEMIMPINAN, BUDAYA ORGANISASI DAN LIN...
Contoh Review Jurnal Ilmiah (PENGARUH KEPEMIMPINAN, BUDAYA ORGANISASI DAN LIN...Contoh Review Jurnal Ilmiah (PENGARUH KEPEMIMPINAN, BUDAYA ORGANISASI DAN LIN...
Contoh Review Jurnal Ilmiah (PENGARUH KEPEMIMPINAN, BUDAYA ORGANISASI DAN LIN...Wulandari Rima Kumari
 
PENGERTIAN ANALISIS SISTEM INFORMASI
PENGERTIAN ANALISIS SISTEM INFORMASIPENGERTIAN ANALISIS SISTEM INFORMASI
PENGERTIAN ANALISIS SISTEM INFORMASIMandiri Sekuritas
 

What's hot (20)

Jenis dan proses interupsi
Jenis dan proses interupsiJenis dan proses interupsi
Jenis dan proses interupsi
 
Metode proses pengembangan perangkat lunak
Metode proses pengembangan perangkat lunakMetode proses pengembangan perangkat lunak
Metode proses pengembangan perangkat lunak
 
Pertemuan 4 Strategi Testing
Pertemuan 4  Strategi TestingPertemuan 4  Strategi Testing
Pertemuan 4 Strategi Testing
 
Erp pertemuan-5
Erp pertemuan-5Erp pertemuan-5
Erp pertemuan-5
 
Ppt: Usability (Interaksi Manusia dan Komputer)
Ppt: Usability (Interaksi Manusia dan Komputer)Ppt: Usability (Interaksi Manusia dan Komputer)
Ppt: Usability (Interaksi Manusia dan Komputer)
 
Testing dan implementasi_sistem_-_romeo
Testing dan implementasi_sistem_-_romeoTesting dan implementasi_sistem_-_romeo
Testing dan implementasi_sistem_-_romeo
 
Incremental development (pengembangan incremental)
Incremental development (pengembangan incremental)Incremental development (pengembangan incremental)
Incremental development (pengembangan incremental)
 
04 Testing Perangkat Lunak
04 Testing Perangkat Lunak04 Testing Perangkat Lunak
04 Testing Perangkat Lunak
 
Rancangan perangkat lunak
Rancangan perangkat lunakRancangan perangkat lunak
Rancangan perangkat lunak
 
Manajemen Resiko (Tugas RPL)
 Manajemen Resiko (Tugas RPL)  Manajemen Resiko (Tugas RPL)
Manajemen Resiko (Tugas RPL)
 
metode-pengujian-blackbox
 metode-pengujian-blackbox metode-pengujian-blackbox
metode-pengujian-blackbox
 
3 rekayasa kebutuhan
3 rekayasa kebutuhan3 rekayasa kebutuhan
3 rekayasa kebutuhan
 
Evolusi perkembangan rekayasa perangkat lunak
Evolusi perkembangan rekayasa perangkat lunakEvolusi perkembangan rekayasa perangkat lunak
Evolusi perkembangan rekayasa perangkat lunak
 
Pertemuan 4-5-6 Metode Pelacakan dan Pencarian
Pertemuan 4-5-6 Metode Pelacakan dan PencarianPertemuan 4-5-6 Metode Pelacakan dan Pencarian
Pertemuan 4-5-6 Metode Pelacakan dan Pencarian
 
LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...
LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...
LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...
 
Rekayasa Perangkat Lunak
Rekayasa Perangkat LunakRekayasa Perangkat Lunak
Rekayasa Perangkat Lunak
 
Contoh Review Jurnal Ilmiah (PENGARUH KEPEMIMPINAN, BUDAYA ORGANISASI DAN LIN...
Contoh Review Jurnal Ilmiah (PENGARUH KEPEMIMPINAN, BUDAYA ORGANISASI DAN LIN...Contoh Review Jurnal Ilmiah (PENGARUH KEPEMIMPINAN, BUDAYA ORGANISASI DAN LIN...
Contoh Review Jurnal Ilmiah (PENGARUH KEPEMIMPINAN, BUDAYA ORGANISASI DAN LIN...
 
PENGERTIAN ANALISIS SISTEM INFORMASI
PENGERTIAN ANALISIS SISTEM INFORMASIPENGERTIAN ANALISIS SISTEM INFORMASI
PENGERTIAN ANALISIS SISTEM INFORMASI
 
Ppt cloudcomputing
Ppt cloudcomputingPpt cloudcomputing
Ppt cloudcomputing
 
Erp pertemuan-8
Erp pertemuan-8Erp pertemuan-8
Erp pertemuan-8
 

Similar to SoftwareTesting

Ch 02 - Hubungan Software Development Life Cycle (SDLC) dan Testing
Ch 02 - Hubungan Software Development Life Cycle (SDLC) dan TestingCh 02 - Hubungan Software Development Life Cycle (SDLC) dan Testing
Ch 02 - Hubungan Software Development Life Cycle (SDLC) dan TestingTri Sugihartono
 
Laporan LKP PLN Bab II
Laporan LKP PLN Bab IILaporan LKP PLN Bab II
Laporan LKP PLN Bab IILC
 
Testing dan implemetasi sistem 1
Testing dan implemetasi sistem 1Testing dan implemetasi sistem 1
Testing dan implemetasi sistem 1Fendi Hidayat
 
Rekayasa Perangkat Lunak JAMINAN KUALITAS PERANGKAT LUNAK
Rekayasa Perangkat Lunak JAMINAN KUALITAS PERANGKAT LUNAKRekayasa Perangkat Lunak JAMINAN KUALITAS PERANGKAT LUNAK
Rekayasa Perangkat Lunak JAMINAN KUALITAS PERANGKAT LUNAKListyowatik (Yanie)
 
Testing dan implemetasi sistem 3
Testing dan implemetasi sistem 3Testing dan implemetasi sistem 3
Testing dan implemetasi sistem 3Fendi Hidayat
 
Tugas2 kelompok5 rpl(b)
Tugas2 kelompok5 rpl(b)Tugas2 kelompok5 rpl(b)
Tugas2 kelompok5 rpl(b)Pande Narendra
 
PPT-UEU-Manajemen-Proyek-SI-Pertemuan-14.pptx
PPT-UEU-Manajemen-Proyek-SI-Pertemuan-14.pptxPPT-UEU-Manajemen-Proyek-SI-Pertemuan-14.pptx
PPT-UEU-Manajemen-Proyek-SI-Pertemuan-14.pptxKairiAbasa
 
Bug management
Bug managementBug management
Bug managementIvano78
 
08 Software Testing
08 Software Testing08 Software Testing
08 Software TestingAinul Yaqin
 
software testing (black box testing) -- irma darmayanti
software testing (black box testing) -- irma darmayantisoftware testing (black box testing) -- irma darmayanti
software testing (black box testing) -- irma darmayantiIrma Darmayanti
 
Software testing
Software testingSoftware testing
Software testingjullejulle
 
Jaminan kualitas pl
Jaminan kualitas plJaminan kualitas pl
Jaminan kualitas plSiti Rohani
 
SQA architecture
SQA architectureSQA architecture
SQA architectureashamarsha
 
Jaminan Kualitas Perangkat Lunak
Jaminan Kualitas Perangkat LunakJaminan Kualitas Perangkat Lunak
Jaminan Kualitas Perangkat LunakYunita Rainbow
 
Test plan Document Example
Test plan Document ExampleTest plan Document Example
Test plan Document ExampleMiftakhul Akhyar
 
Proses rekayasa perangkat lunak
Proses rekayasa perangkat lunakProses rekayasa perangkat lunak
Proses rekayasa perangkat lunakDavy Arya Atmaja
 

Similar to SoftwareTesting (20)

Ch 02 - Hubungan Software Development Life Cycle (SDLC) dan Testing
Ch 02 - Hubungan Software Development Life Cycle (SDLC) dan TestingCh 02 - Hubungan Software Development Life Cycle (SDLC) dan Testing
Ch 02 - Hubungan Software Development Life Cycle (SDLC) dan Testing
 
Laporan LKP PLN Bab II
Laporan LKP PLN Bab IILaporan LKP PLN Bab II
Laporan LKP PLN Bab II
 
Testing dan implemetasi sistem 1
Testing dan implemetasi sistem 1Testing dan implemetasi sistem 1
Testing dan implemetasi sistem 1
 
Rekayasa Perangkat Lunak JAMINAN KUALITAS PERANGKAT LUNAK
Rekayasa Perangkat Lunak JAMINAN KUALITAS PERANGKAT LUNAKRekayasa Perangkat Lunak JAMINAN KUALITAS PERANGKAT LUNAK
Rekayasa Perangkat Lunak JAMINAN KUALITAS PERANGKAT LUNAK
 
Testing dan implemetasi sistem 3
Testing dan implemetasi sistem 3Testing dan implemetasi sistem 3
Testing dan implemetasi sistem 3
 
Tugas2 kelompok5 rpl(b)
Tugas2 kelompok5 rpl(b)Tugas2 kelompok5 rpl(b)
Tugas2 kelompok5 rpl(b)
 
PPT-UEU-Manajemen-Proyek-SI-Pertemuan-14.pptx
PPT-UEU-Manajemen-Proyek-SI-Pertemuan-14.pptxPPT-UEU-Manajemen-Proyek-SI-Pertemuan-14.pptx
PPT-UEU-Manajemen-Proyek-SI-Pertemuan-14.pptx
 
Bug management
Bug managementBug management
Bug management
 
08 Software Testing
08 Software Testing08 Software Testing
08 Software Testing
 
Model quality management sofwtware
Model quality management sofwtwareModel quality management sofwtware
Model quality management sofwtware
 
software testing (black box testing) -- irma darmayanti
software testing (black box testing) -- irma darmayantisoftware testing (black box testing) -- irma darmayanti
software testing (black box testing) -- irma darmayanti
 
Software testing
Software testingSoftware testing
Software testing
 
Jaminan kualitas pl
Jaminan kualitas plJaminan kualitas pl
Jaminan kualitas pl
 
SQA architecture
SQA architectureSQA architecture
SQA architecture
 
Ch 01
Ch 01Ch 01
Ch 01
 
Jaminan Kualitas Perangkat Lunak
Jaminan Kualitas Perangkat LunakJaminan Kualitas Perangkat Lunak
Jaminan Kualitas Perangkat Lunak
 
Test plan Document Example
Test plan Document ExampleTest plan Document Example
Test plan Document Example
 
Dede Rpl Kuis
Dede Rpl KuisDede Rpl Kuis
Dede Rpl Kuis
 
Proses rekayasa perangkat lunak
Proses rekayasa perangkat lunakProses rekayasa perangkat lunak
Proses rekayasa perangkat lunak
 
Ch 12
Ch 12Ch 12
Ch 12
 

SoftwareTesting

  • 2. Bahan Kajian • Kualitas Perangkat Lunak • Terminologi Kegagalan (Failure), Kesalahan (Error/Fault), Cacat (Defect), dan Bug • 7 Prinsip Pengujian Perangkat Lunak • Proses Pengujian • V-Model 1
  • 3. Bahan Kajian • Alat Pengujian • Teknik Pengujian –Black Box Testing –White Box Testing –Experience Testing Referensi : • ISTQB • ISO • V-Model 2
  • 4. Bahan Kajian • Perawatan Sistem • Jaminan Kualitas Referensi : • ISTQB • ISO • V-Model 3
  • 5. 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.
  • 6. Software Quality De Groot et.all. (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.
  • 7. 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.
  • 8. 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. 1. Pengujian perangkat lunak sebagai sarana untuk memastikan kualitas perangkat lunak. 1. 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.
  • 9. 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.
  • 10. 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).
  • 11. Software Quality Kategori Kualitas Perangkat lunak Berdasarkan ISO/IEC 9126
  • 12. 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)
  • 13. 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.
  • 14. • Definisi kualitas dari sebuah perangkat lunak merupakan aktualisasi dari pengalaman dan kepuasan para penggunanya. • Sebuah perangkat lunak dapat dinyatakan berkualitas, maka terlebih dahulu harus dilakukan pengujian (testing) dan pengukuran (measurement) tingkat kualitasnya. • Pengujian juga dimaksudkan untuk memastikan apakah perangkat lunak tersebut benar-benar dapat digunakan (useable) oleh penggunanya [Handayani & Adelin, 2019]. Testing for Quality Usability Experience Satisfaction QUALITY USER Software Testing QA Engineer
  • 15. 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.
  • 16. 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).
  • 17. 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.
  • 18. Testing Life Cycle Jorgensen (2014:4) Software Testing : A Craftman’s Approach, 4th edition
  • 19. Portofolio Sertifikasi Seorang Software Tester Organisasi Penyelenggara Sertifikasi Internasional untuk Software Tester (base @Germany): The International Software Testing Qualification Board (ISTQB) - http://www.istqb.org
  • 20. 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
  • 21. 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. 1. 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
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. 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
  • 26. 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. Error, Fault, Defect, Bug, Failure
  • 27. Testing Life Cycle Jorgensen (2014:4) Software Testing : A Craftman’s Approach, 4th edition
  • 30. Jenis-Jenis Kesalahan (Fault) Jorgensen (2014:4) Software Testing : A Craftman’s Approach, 4th edition
  • 31. 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.
  • 32. 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
  • 33. 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
  • 34. 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
  • 35. 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
  • 36. 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
  • 37. 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.
  • 38. 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. 7 Prinsip Pengujian Software
  • 41. • 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 (extends the waterfall process)
  • 42. • Kiri = SDLC (development activities) • Kanan = Proses pengujian (testing activities) • V = Verifikasi & Validasi • Diusulkan oleh Paul Rook (1980) V-Model (tradisional)
  • 43. V-Model (tradisional) Spillner, 2014 Mathur & Malik, 2010
  • 44. 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)
  • 45. 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)
  • 46. 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)
  • 47. 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 (tradisional)
  • 48. • Kiri = SDLC (development activities) • Kanan = Proses pengujian (testing activities) • V = Validasi / Verifikasi • Diusulkan oleh Paul Rook (1980) V-Model (advanced)
  • 49. 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)
  • 50. 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)
  • 51. Security Testing: Pengujian ini bertujuan untuk mengevaluasi keberadaan dan berjalannya fungsi keamanan sistem/aplikasi guna memastikan integritas dan kerahasiaan data. V-Model (advanced)
  • 52. 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. V-Model (advanced)
  • 53. • 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
  • 54. Langkah-langkah Manual Testing : • Menganalisa Requirement • Membuat test plan • Membuat test case • Eksekusi dari test case • Mencari kecacatan • Memperbaiki kecacatan Alat Pengujian Langkah-langkah Automation Testing : • Menilai dan mengevaluasi alat pengujian yang dipakai. • Merancang test case • Melakukan Implementasi test case menggunakan testing tools • Membuat laporan pengujan • Melakukan pengecekan hasil pengujian.
  • 55. 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
  • 56. 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
  • 57. 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. Alat Pengujian
  • 58. Bahan Kajian • Kategori Pengujian • Teknik Pengujian Referensi : • ISTQB • ISO • V-Model 3
  • 59. Kategori Pengujian Secara umum ada 2 kategori pengujian perangkat lunak : 1. User Acceptance Testing (UAT) 2. Usability Testing (UT)
  • 60. 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.
  • 61. 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.
  • 62. 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.
  • 63. 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.
  • 64. 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
  • 65. 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.
  • 66. 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.
  • 68. 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).
  • 69. 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).
  • 71. Kategori Pengujian Nurhadryani dkk, 2013 : https://journal.ipb.ac.id/index.php/jika/article/view/7997
  • 72. 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.
  • 73. 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.
  • 74. 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.
  • 75. 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)
  • 77. 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.
  • 78. 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.
  • 79. 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.
  • 80. Teknik Pengujian Model Pengujian Cacat “khas” yang dapat ditemukan menggunakan teknik ini Equivalence Partitioning (EP) Model Domain Penanganan data/nilai domain yang salah. Boundary Value Analysis (BVA) Model Domain Penanganan data yang salah pada batasan domain. Decision Table Testing (DTT) Model Logika Keputusan Penanganan aturan bisnis yang salah. State Transition Testing (STT) Model Perilaku Penanganan transisi yang salah antar status. Use Case Testing (UCT) Model Proses Bisnis Penanganan proses bisnis yang salah. Black Box Testing
  • 81. • 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
  • 84. 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
  • 85. • 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 : Equivalence Partitioning
  • 86. • 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
  • 89. • 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 : Boundary Value Analysis
  • 91. 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
  • 95. 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/
  • 96. 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.
  • 97. 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)
  • 98. Black-Box : State Transition Testing Contoh :
  • 99. 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
  • 100. 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
  • 101. 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
  • 102. 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
  • 103. • 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
  • 104. 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.
  • 105. 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.
  • 107. 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
  • 108. (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 1. Pengguna memilih jenis minuman “Soda-1”. 2. 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
  • 109. (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
  • 110. 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
  • 111. Pertanyaan : (c) Manakah dari kasus uji TC1–TC4 yang mencakup jalur alternatif 3b? Jawab : Jalur alternatif 3b masuk dalam cakupan TC3. Black-Box : Use Case Testing
  • 114. • 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
  • 115. • 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
  • 116. White Box Testing: Control Flow Graph (CFG)
  • 117. White Box Testing: Control Flow Graph (CFG)
  • 118. White Box Testing: Control Flow Graph (CFG)
  • 119. 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%
  • 120. 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
  • 121. 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
  • 122. • 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-). White Box Testing
  • 123. • Experience Based Test (EBT) hampir sama dengan Black Box Testing. Experience Testing
  • 124. • 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 Based Testing
  • 125. 1. Teknik menebak kesalahan (Error guessing) : 1. Bertujuan untuk mengidentifikasi cacat yang mungkin tidak mudah ditangkap dengan teknik yang lebih formal. 1. Biasanya dilakukan setelah teknik yang lebih formal selesai. 1. Kesalahan meliputi: bagi dengan nol, pointer nol atau parameter tidak valid. Experience Testing
  • 126. 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
  • 127. 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
  • 128. 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). Experience Testing
  • 130. 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
  • 131. 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
  • 132. • 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
  • 133. 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
  • 134. Jaminan Kualitas Kategori Kualitas Perangkat lunak Berdasarkan ISO/IEC 9126
  • 135. Jaminan Kualitas Pengukuran Kualitas Perangkat Lunak Dalam Proyek Rekayasa Perangkat Lunak 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)
  • 137. 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
  • 138. • Standar Kualitas : ISO 🡪 http://ww.iso.org 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). Jaminan Kualitas
  • 139. 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
  • 140. ✔ 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]. ISO / IEC 25010
  • 141. 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 29119
  • 142. Part of ISO/IEC 9241-11
  • 143. • 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
  • 144. • 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
  • 145. • 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). Jaminan Kualitas
  • 146. 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. http://www.bth.se/besq. 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. https://doi.org/10.1007/978-1-4614-3067-4_1 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). https://doi.org/10.1080/08874417.2006.11645940 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. https://ojs.ummetro.ac.id/index.php/mikrotik/article/view/749 9) Handayani, F. S. (2021). Desain Instrumen Pengujian Usabilitas Aplikasi Menggunakan Heuristic Usability Nielson. JSAI (Journal Scientific and Applied Informatics), 4(1). https://doi.org/10.36085/jsai.v4i1.1346 10) Handayani, F. S., & Adelin, A. (2019). Interpretasi Pengujian Usabilitas Wibatara Menggunakan System Usability Scale. Techno.Com, 18(4). https://doi.org/10.33633/tc.v18i4.2882 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 :
  • 147. 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). https://doi.org/10.1080/10447318.2017.1418805 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). https://doi.org/10.1080/10447318.2015.1064665 15) Mardiana, M. (2020). Implementasi User Satisfaction Model Dalam Mengukur Kualitas Website. MATRIK : Jurnal Manajemen, Teknik Informatika Dan Rekayasa Komputer, 19(2). https://doi.org/10.30812/matrik.v19i2.711 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). https://doi.org/10.5121/ijsea.2014.5603 17) Molich, R. (1994). Preventing user interface disasters. Behaviour and Information Technology, 13(1–2). https://doi.org/10.1080/01449299408914594 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). https://doi.org/10.31961/eltikom.v4i1.139 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. https://www.nngroup.com/articles/usa%0Ability-101-introduction-to-usability 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). https://doi.org/10.1287/isre.13.2.151.88 23) Pressman, R. S. (2012). Software-Engineering 7th ED by Roger S. Pressman. In Software Engineering A Practitioner’s Approach. Pustaka Lainnya :
  • 148. 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. https://doi.org/10.1108/k.1998.27.4.457.4 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). 24) https://hell.meiert.org/core/pdf/sus.pdf 25) http://uxpajournal.org/wp-content/uploads/pdf/JUS_Bangor_May2009.pdf 26) https://measuringu.com/wp-content/uploads/2017/07/Lewis_Sauro_HCII2009.pdf 27) https://www.ueq-online.org/ Pustaka Lainnya :