(30 Sept) BKPM WORKSHOP SQA

BKPM
(BUKU KERJA PRAKTIK MAHASISWA)
TIF3605 WORKSHOP KUALITAS PERANGKAT LUNAK
SEMESTER 3
OLEH :
Intan Sulistyaningrum Sakkinah, S.Pd., M.Eng
Ratih Ayuninghemi, S.ST, M.Kom
Hendra Yufit Riskiawan, S.Kom, M.Cs
PROGRAM STUDI TEKNIK INFORMATIKA

JURUSAN TEKNOLOGI INFORMASI
POLITEKNIK NEGERI JEMBER

TAHUN 2021
1
KEMENTERIAN PENDIDIKAN, KEBUDAYAAN, RISET, DAN TEKNOLOGI
POLITEKNIK NEGERI JEMBER
LEMBAR PENGESAHAN
WORKSHOP PENGEMBANGAN PERANGKAT LUNAK
Mengetahui,
Ka.Prodi, Koordinator,
Trismayanti Dwi P, S.Kom., M.Cs Intan Sulistyaningrum S., S.Pd., M.Eng

NIP.19900227 2018 03 2 001 NIK.19951013 202103 2 001
Menyetujui,
Ka.Jur,
Hendra Yufit Riskiawan, S.Kom., M.Cs

NIP. 19830203 200604 1 003
i
KATA PENGANTAR
Puji Syukur kehadirat Tuhan Yang Maha Esa karena atas limpahan rahmat-Nya sehingga
kami dapat menyelesaikan Buku Kerja Praktik Mahasiswa (BKPM) Workshop Kualitas Perangkat
Lunak. Materi Workshop terdiri dari framework Software Quality Assurance (SQA), lingkup SQA,
pengelolaan risiko QA, sumber daya pada SQA, integrasi QA ke dalam organisasi pengembang,
pengujian perangkat lunak manual dan otomatis, pengujian keamanan perangkat lunak,
penyusunan rekomendasi SQA, dan evaluasi pelaksanaan SQA. BKPM ini disusun berdasarkan
metode Student Center Learning yaitu menempatkan mahasiswa sebagai pusat kegiatan belajar.
BKPM ini terdiri dari Pokok Bahasan, Acara Praktikum, Tempat, Alokasi Waktu, Capaian
Pembelajaran Mata Kuliah (CPMK), Indikator, Dasar Teori, Alat dan Bahan, Prosedur Kerja, Hasil
dan Pembahasan, Kesimpulan, Rubrik Penilaian.
Kami menyadari masih banyak kekurangan dalam penyusunan BKPM ini. Oleh karena itu,
kami sangat mengharapkan kritik dan saran demi perbaikan dan kesempurnaan modul ini. Kami
mengucapkan terima kasih kepada berbagai pihak yang telah membantu proses penyelesain
BKPM ini. Semoga BKPM ini dapat bermanfaat bagi kita semua.
Jember, 6 September 2021
Tim Penulis
ii
DAFTAR ISI
LEMBAR PENGESAHAN i
KATA PENGANTAR ii
DAFTAR ISI iii
Acara 1 1
Acara 2 4
Acara 3 6
Acara 4 10
Acara 5 13
Acara 6 16
Acara 7 23
Acara 8 26
Acara 9 29
Acara 10 31
Acara 11 33
Acara 12 37
Acara 13 40
Acara 14 45
Acara 15 49
Acara 16 52
Acara 17 55
Acara 18 58
Acara 19 61
Acara 20 71
Acara 21 77
iii
Acara 1
Pokok Bahasan : Menentukan Metode / Framework
Acara Praktikum/Praktik : Minggu 1 / 1
Tempat : Politeknik Negeri Jember
Alokasi Waktu : 2x100 menit
a. Capaian Pembelajaran Mata Kuliah (CPMK)

1. Mahasiswa mampu Mengidentifikasi metode penjaminan kualitas proses dan
produk pengembangan perangkat lunak
2. Mahasiswa mampu Menentukan metode penjaminan kualitas proses dan produk
pengembangan perangkat lunak
3. Mahasiswa mampu Menganalisa acuan-acuan penjaminan kualitas perangkat
lunak
b. Indikator
Ketepatan mengidentifikasi keseuaian metode penjaminan dengan metode
pengembangan diidentifikasi sebagai dasar kegiatan berikutmya
c. Dasar Teori
1. Metode Penjaminan Kualitas
Merupakan metode penjamin kualitas proses pengembangan dan produk hasil
proyek perangkat lunak memuliah aktivitas penjaminan.misalnya: IT Assuranc E-
Framework (ITAFTM), Comprehensive, Lightweight Application Security Process
(CLASP), Microsoft Software Development Library (MS-SDL), Open Software Assurance
Maturity Model (Open SAMM), Building Security In Maturity Model (BSIMM), Microsoft
Software Assurance Methodology (MS-STRIDE) dan metode lain sejenis sesuai
kebutuhan.
2. IT Assuranc E-Framework (ITAFTM),
Sejarah dan Definisi ITAF
ITAF didesain dan diciptakan oleh ISACA, ITAF adalah sebuah Framework Praktek
Profesional Audit / jaminan SI yang bertujuan sebagai sumber daya pendidikan untuk
para profesional yang bekerja pada bidang audit/ jaminan SI. ITAF merupakan model
referensi yang komprehensif dan baik penerapannya dikarenakan:
§ Menetapkan standar audit dan jaminan peran dan tanggung jawab
profesional SI, pengetahuan dan keterampilan, dan ketekunan, perilaku.
§ Mendefinisikan istilah dan konsep spesifik untuk jaminan SI.
§ Memberikan bimbingan dan alat-alat dan teknik pada perencanaan,
desain, pelaksanaan dan pelaporan SI audit dan jaminan tugas
1
ITAF difokuskan pada materi ISACA dan menyediakan satu sumber dimana IS audit
dan jaminan profesional dapat mencari bimbingan, penelitian kebijakan dan prosedur,
mendapatkan program audit dan jaminan, dan mengembangkan laporan yang efektif.
ITAF 2nd Edition dimasukkan dalam pedoman audit dan jaminan ISACA pada 1
November 2013, sedangkan 3rd Edition sendiri dimasukan pada 1 September 2014
yang akan dipakai sebagai pedoman baru dan akan di index didalam framework.
Keuntungan menggunakan model ITAF
§ ITAF lebih menitikberatkan pada proses audit, tidak seperti metode lain
(COBIT, ITIL, dsb) yang lebih memfokuskan pada tata kelola TI.
§ ITAF didesain untuk profesional yang bergerak di bidang jasa audit atau
assurance sehingga cocok diterapkan oleh lembaga.
§ Prosedur, metode dan istilah-istilah dalam ITAF lebih familiar, mudah
dimengerti dan diterapkan oleh auditor.
d. Alat dan Bahan
Peralatan
1) Perangkat komputer dan kelengkapannya atau mesin sejenis
Bahan
1) Manual Framework atau Metode
e. Prosedur Kerja
a) Bentuklah kelompok dengan jumlah anggota 5-6 orang.
b) Buatlah makalah yang berisi jenis-jenis metode penjaminan kualitas
proses dan produk pengembangan perangkat lunak dibagi dengan tiap
anggota kelompok.
c) Rangkum prosedur pelaksanaan penjaminan kualitas perangkat lunak.
d) Sertakan daftar rujukan yang digunakan.
f. Hasil dan Pembahasan
Makalah jenis-jenis metode penjaminan kualitas proses dan produk
g. Kesimpulan
Mahasiswa mampu mengindetifikasi dan menentukan metode penjaminan kualitas
proses dan produk pengembangan perangkat lunak
2
h. Rubrik Penilaian
No Indikator Skor*
Ketepatan waktu dan ketepatan dalam menjelaskan dari tugas
1 1 2 3 4
ditunjang dengan bukti referensi
2 Ketepatan waktu dan ketepatan dalam menjelaskan dari tugas 1 2 3 4
3 Ketepatan waktu akan tetapi kurang tepat dalam menjelaskan tugas 1 2 3 4
Keterlambatan pengumpulan tugas dan ketidaktepatan dalam
4 1 2 3 4
menjelaskan tugas
Jumlah skor
3
Acara 2
Pokok Bahasan : Menentukan Metode / Framework
Alokasi Waktu : 100 menit

1. Mahasiswa mampu Mengidentifikasi metode penjaminan kualitas proses dan
produk pengembangan perangkat lunak
2. Mahasiswa mampu Menentukan metode penjaminan kualitas proses dan produk
3. Mahasiswa mampu Menganalisa acuan-acuan penjaminan kualitas perangkat
lunak
b. Indikator
Ketepatan mengidentifikasi keseuaian metode penjaminan dengan metode
pengembangan diidentifikasi sebagai dasar kegiatan berikutmya
c. Dasar Teori
1. Metode Penjaminan Kualitas
Merupakan metode penjamin kualitas proses pengembangan dan produk hasil
proyek perangkat lunak memuliah aktivitas penjaminan.misalnya: IT Assuranc E-
Framework (ITAFTM), Comprehensive, Lightweight Application Security Process
(CLASP), Microsoft Software Development Library (MS-SDL), Open Software Assurance
Maturity Model (Open SAMM), Building Security In Maturity Model (BSIMM), Microsoft
Software Assurance Methodology (MS-STRIDE) dan metode lain sejenis sesuai
kebutuhan.
CMMI (Capability Maturity Model Integration) untuk menggambarkan kondisi pada
perusahan. Dalam metode CMMI representasi bertingkat dalam menentukan area
proses dari CMMI, proses penilaian berdasarkan dari 6 area proses yaitu: 1)
Requirement Management (REQM), 2) Project Planning Management (PP), 3) Project
Monitoring and Control (PMC), 4) Measurement and Analysis (MA), 5) Process and
Product Quality Assurance (PPQA) dan 6) Configuration Management (CM), dan untuk
prosedur penilaiannya menggunakan status terpenuhi dan tidak terpenuhi.
Pemanfaatan CMMI untuk meningkatkan kualitas perangkat lunak, penelitiannya
ditujukan untuk membantu organisasi mengembangkan kualitas produk dan jasa,
terdapat 3 fase yang dilakukan yaitu fase analisa kebutuhan, fase pengukuran dan
analisis, dan fase rekomendasi.
Contoh implementasi dapat dilihat pada jurnal dibawah ini:
4
http://download.garuda.ristekdikti.go.id/article.php?article=1727692&val=12795
&title=SOFTWARE%20QUALITY%20ASSURANCE%20PADA%20PERUSAHAAN%20
PENGEMBANG%20PERANGKAT%20LUNAK%20SKALA%20KECIL%20DAN%20MEN
ENGAH
d. Alat dan Bahan
Peralatan
- Perangkat komputer dan kelengkapannya atau mesin sejenis
Bahan
- Manual Framework atau Metode
e. Prosedur Kerja
1) Bentuklah kelompok dengan jumlah anggota 5-6 orang.
2) Buatlah makalah yang berisi jenis-jenis metode penjaminan kualitas proses dan
produk pengembangan perangkat lunak dibagi dengan tiap anggota kelompok.
3) Rangkum prosedur pelaksanaan penjaminan kualitas perangkat lunak.
4) Sertakan daftar rujukan yang digunakan.
Makalah jenis-jenis metode penjaminan kualitas proses dan produk pengembangan
perangkat lunak
g. Kesimpulan
Mahasiswa mampu mengindetifikasi dan menentukan metode penjaminan kualitas
proses dan produk pengembangan perangkat lunak
h. Rubrik Penilaian
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
5
Acara 3
Pokok Bahasan : Menentukan Lingkup Quality Assurance untuk
Perangkat Lunak

1. Mahasiswa mampu Menggali kebutuhan aspek kualitas perangkat lunak yang akan
dikembangkan
2. Mahasiswa mampu Menyusun metrik kualitas perangkat lunak
3. Mahasiswa mampu Menentukan Batasan aktivitas penjaminan perangkat lunak
4. Mahasiswa mampu Menentukan Batasan nilai metrik kualitas perangkat lunak
5. Mahasiswa mampu menentukan keluaran dari proses review kualitas produk
perangkat lunak
b. Indikator
Ketepatan menentukan metrik kualitas berdasarkan metode dan acuan yang
dipilih.
c. Dasar Teori
Dalam menggali kebutuhan aspek analisis kualitas perangkat lunak ada beberapa hal
yang harus kita perhatikan, antara lain :
1) Material pendukung/bahan–bahan penyusunan objektif assurance diidentifikasi
sebagai dasar kegiatan berikutnya.
2) Material pendukung/bahan–bahan penyusunan objektif assurance
didokumentasikan sesuai standard dokumentasi yang ditetapkan.
3) Kualitas-kualitas perangkat lunak diidentifikasi sebagai dasar kegiatan berikutnya.
4) Semua pihak yang berkepentingan terhadap proses dan hasil assurance
diidentifikasi sesuai standar yang ditetapkan.
5) Prioritas kualitas perangkat lunak yang utama ditentukan sesuai standar yang
ditetapkan.
Tahapan selanjutnya adalah Menyusun metrics kualitas perangkat lunak :
1) Metrik kualitas diidentifikasi berdasarkan metode dan acuan yang dipilih.
2) Metrik kualitas dipilih berdasarkan kesesuaian dengan kebutuhan kualitas dan
prioritas yang ada.
3) Metriks kualitas yang telah dipilih didokumentasikan untuk menjadi acuan
penilaian kualitas perangkat lunak.
6
Dalam SQA juga ada beberapa elemen yang harus diperhatikan antara lain :
• Standards (Standar)
Standar perangkat lunak memainkan peran yang sangat penting dalam software
quality management. Sebagai bagian dari proses QA ini, alat dan metode untuk
mendukung penggunaan standar ini juga dapat dipilih. Tugas SQA adalah untuk
memastikan bahwa standar yang telah diimplementasikan diikuti dan bahwa semua
produk kerja sesuai dengan mereka.
• Reviews and audits (Ulasan dan audit)
Technical reiviews adalah kegiatan kontrol kualitas yang dilakukan oleh software
engineers untuk software engineers. Review harus memeriksa konsistensi dan
kelengkapan dokumen atau kode yang direview dan memastikan bahwa standar
kualitas telah diikuti. Namun, ulasan tidak hanya memeriksa kesesuaian dengan
standar, melainkan juga digunakan untuk membantu menemukan masalah dan
kelalaian dalam perangkat lunak atau dokumentasi proyek. Audit adalah jenis tinjauan
yang dilakukan oleh personel SQA dengan maksud untuk memastikan bahwa pedoman
kualitas diikuti untuk pekerjaan rekayasa perangkat lunak.
• Testing (Pengujian)
Software testing adalah fungsi kontrol kualitas yang memiliki satu tujuan utama,
yaitu untuk menemukan kesalahan. Tugas SQA adalah memastikan bahwa pengujian
direncanakan dengan baik dan dilakukan secara efisien sehingga memiliki
kemungkinan tertinggi untuk mencapai tujuan utamanya.
• Error/defect collection and analysis (Pengumpulan dan analisis kesalahan / cacat)
SQA mengumpulkan dan menganalisis data kesalahan dan cacat untuk lebih
memahami bagaimana kesalahan diperkenalkan dan kegiatan rekayasa perangkat
lunak apa yang paling cocok untuk menghilangkannya.
• Change management (Pengubahan manajemen)
Perubahan adalah salah satu aspek yang paling mengganggu dari setiap proyek
perangkat lunak. Jika tidak dikelola dengan baik, perubahan dapat menyebabkan
kebingungan, dan kebingungan hampir selalu mengarah pada kualitas yang buruk.
SQA memastikan bahwa praktik manajemen perubahan yang memadai telah dibentuk.
• Education (Edukasi)
Setiap software organization ingin meningkatkan software engineering practices.
Kontributor utama dalam peningkatan adalah pendidikan software engineers, manajer
mereka, dan stakeholder lainnya. Organisasi SQA memimpin dalam peningkatan
proses perangkat lunak dan merupakan pendukung dan sponsor utama program
pendidikan.
• Vendor management (Manajemen vendor)
7
Tugas organisasi SQA adalah untuk memastikan bahwa perangkat lunak yang
dihasilkan berkualitas tinggi dengan menyarankan praktik kualitas khusus yang harus
diikuti oleh vendor (bila mungkin), dan memasukkan mandat kualitas sebagai bagian
dari kontrak apa pun dengan vendor eksternal.
• Security management (Manajemen keamanan)
Dengan meningkatnya cybercrime dan peraturan pemerintah baru tentang privasi,
setiap organisasi perangkat lunak harus melembagakan kebijakan yang melindungi
data di semua tingkatan, membangun perlindungan firewall untuk WebApps, dan
memastikan bahwa perangkat lunak belum dirusak secara internal. SQA memastikan
bahwa proses dan teknologi yang tepat digunakan untuk mencapai software security
yang aman.
• Safety (Keamanan)
SQA mungkin bertanggung jawab untuk menilai dampak kegagalan perangkat
lunak untuk memulai langkah-langkah yang diperlukan untuk mengurangi risiko.
• Risk management (Manajemen risiko)
Meskipun analisis dan mitigasi risiko menjadi perhatian para software engineers,
organisasi SQA memastikan bahwa kegiatan manajemen risiko dilakukan dengan
benar dan bahwa rencana kontinjensi terkait risiko telah ditetapkan.
d. Alat dan Bahan
Peralatan
2) Formulir skenario uji dan hasil uji
Bahan
1) Template/standard dokumentasi proses review penjaminan kualitas proses
dan produk
2) Metrics penilaian
e. Prosedur Kerja
2) Buatlah makalah yang berisi jenis-jenis ruang lingkup penjaminan kualitas proses
dan produk pengembangan perangkat lunak dibagi dengan tiap anggota kelompok.
3) Sertakan daftar rujukan yang digunakan
perangkat lunak.
g. Kesimpulan
Mahasiswa mampu Menggali kebutuhan aspek kualitas perangkat lunak yang akan
dikembangkandan Menyusun metrik SQA
8
h. Rubrik Penilaian
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
9
Acara 4
Pokok Bahasan : Menentukan Lingkup Quality Assurance untuk
Perangkat Lunak

a. Mahasiswa mampu Menggali kebutuhan aspek kualitas perangkat lunak yang
akan dikembangkan
b. Mahasiswa mampu Menyusun metrik kualitas perangkat lunak
c. Mahasiswa mampu Menentukan Batasan aktivitas penjaminan perangkat lunak
d. Mahasiswa mampu Menentukan Batasan nilai metrik kualitas perangkat lunak
e. Mahasiswa mampu menentukan keluaran dari proses review kualitas produk
perangkat lunak
b. Indikator
Ketepatan menentukan metrik kualitas berdasarkan metode dan acuan yang
dipilih.
c. Dasar Teori
• Quality metrics merupakan salah satu tools SQA
• Quality metrics (menurut IEEE, 1990) adalah tingkat pengukuran kuantitatif yang
memiliki hal atribut kuantitatif yang diberikan
• Quality metrics harus mencakup dalam perangkat lunak untuk membantu
manajemen dalam 3 area dasar, yaitu :
1. Mengontrol proyek pengembangan perangkat lunak dan maintenance
2. Mendukung pengambilan keputusan
3. Menginisiasi tindakan yang korektif
• Tujuan utama dari metriks kualitas perangkat lunak, adalah :
1. Untuk memudahkan manajemen untuk melakukan intervensi manajerial
• Metrikdigunakan sebagai tool untuk memahami penyimpangan aktual dari
yang direncanakan
1. fungsional (kualitas) kinerja darikinerja yang direncanakan
2. timetable dan kinerjaanggaran darikinerja yang direncanakan
2. Untuk mengidentifikasi situasi yang memerlukan pengembangan dan
perbaikan proses maintenance dalam bentuk pencegahan atau tindakan
yang korektif
• General requirement dari metrik kualitas perangkat lunak, antara lain :
1. Relevant
10
• Berhubungan dengan atribut substansial
2. Valid
• Mengukur atribut yang diperlukan
3. Reliable
• Menghasilkan hasil yang sama bila diterapkan di bawah kondisi yang
sama
4. Comprehensive
• Berlaku untukberbagai macamimplementasidan situasi
5. Mutually exclusive
• Tidak mengukur atribut yang diukur dengan metrik lainnya
• Operative requirement dari metrik kualitas perangkat lunak, antara lain :
1. Mudah dan simple
• Pengumpulan data metrik simple dan ditunjukkan dengan sumber
daya yang minimal
2. Tidak memerlukan data yang independen
• Pengumpulan data metrik terintegrasi dengan sistem pengumpulan
data proyek lainnya, seperti employee attendances dan wages
3. Immune to biased interventions by interested parties
• Hasil yang diharapkan dari quality metrics adalah bebas dari
intervensi oleh pihak yang berkepentingan, seperti perubahan data
• Klasifikasi metrik ada 2, yaitu :
1. Process metrics, berhubungan dengan proses pengembangan perangkat
lunak (development software). Process metricsdibagi menjadi 4, yaitu :
• Software process quality metrics
• Software process timetable metrics
• Error removal effectiveness metrics
• Software process productivity metrics
2. Product metrics, berhubungan dengan proses pemeliharaan perangkat lunak
(maintenance software)
d. Alat dan Bahan
Peralatan
a) Perangkat komputer dan kelengkapannya atau mesin sejenis
b) Formulir skenario uji dan hasil uji
Bahan
a) Template/standard dokumentasi proses review penjaminan kualitas proses
dan produk
b) Metrics penilaian
e. Prosedur Kerja
11
2) Buatlah makalah yang berisi metriks ruang lingkup penjaminan kualitas produk
pengembangan perangkat lunak dibagi dengan tiap anggota kelompok.
perangkat lunak.
g. Kesimpulan
h. Rubrik Penilaian
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
12
Acara 5
Pokok Bahasan : Menentukan Lingkup Quality Assurance untuk Proses
Pengembangan Perangkat Lunak

dikembangkan
perangkat lunak
b. Indikator
Ketepatan menentukan metrik kualitas berdasarkan metode dan acuan yang dipilih.
c. Dasar Teori
• Quality metrics merupakan salah satu tools SQA
• Quality metrics (menurut IEEE, 1990) adalah tingkat pengukuran kuantitatif yang
memiliki hal atribut kuantitatif yang diberikan
• Quality metrics harus mencakup dalam perangkat lunak untuk membantu
manajemen dalam 3 area dasar, yaitu :
1. Mengontrol proyek pengembangan perangkat lunak dan maintenance
2. Mendukung pengambilan keputusan
3. Menginisiasi tindakan yang korektif
• Tujuan utama dari metriks kualitas perangkat lunak, adalah :
1. Untuk memudahkan manajemen untuk melakukan intervensi manajerial
• Metrikdigunakan sebagai tool untuk memahami penyimpangan
aktual dari yang direncanakan
1. fungsional (kualitas) kinerja darikinerja yang direncanakan
2. timetable dan kinerjaanggaran darikinerja yang direncanakan
2. Untuk mengidentifikasi situasi yang memerlukan pengembangan dan
perbaikan proses maintenance dalam bentuk pencegahan atau tindakan
yang korektif
• General requirement dari metrik kualitas perangkat lunak, antara lain :
1. Relevant
• Berhubungan dengan atribut substansial
13
2. Valid
• Mengukur atribut yang diperlukan
3. Reliable
• Menghasilkan hasil yang sama bila diterapkan di bawah kondisi yang
sama
4. Comprehensive
• Berlaku untukberbagai macamimplementasidan situasi
5. Mutually exclusive
• Tidak mengukur atribut yang diukur dengan metrik lainnya
• Operative requirement dari metrik kualitas perangkat lunak, antara lain :
1. Mudah dan simple
• Pengumpulan data metrik simple dan ditunjukkan dengan sumber
daya yang minimal
2. Tidak memerlukan data yang independen
• Pengumpulan data metrik terintegrasi dengan sistem pengumpulan
data proyek lainnya, seperti employee attendances dan wages
3. Immune to biased interventions by interested parties
• Hasil yang diharapkan dari quality metrics adalah bebas dari
intervensi oleh pihak yang berkepentingan, seperti perubahan data
• Klasifikasi metrik ada 2, yaitu :
1. Process metrics, berhubungan dengan proses pengembangan perangkat
lunak (development software). Process metricsdibagi menjadi 4, yaitu :
• Software process timetable metrics
• Error removal effectiveness metrics
• Software process productivity metrics
2. Product metrics, berhubungan dengan proses pemeliharaan perangkat lunak
(maintenance software)
d. Alat dan Bahan

Peralatan
Bahan
dan produk
14
e. Prosedur Kerja

perangkat lunak.
g. Kesimpulan
h. Rubrik Penilaian
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
15
Acara 6
Pokok Bahasan : Menentukan Lingkup Quality Assurance untuk Proses
Pengembangan Perangkat Lunak

dikembangkan
perangkat lunak
b. Indikator
Ketepatan menentukan metrik kualitas berdasarkan metode dan acuan yang dipilih.
c. Dasar Teori
1. Error density metrics
• Melibatkan 2 ukuran :
1. Software volume, menggunakan jumlah LOC
2. Errors counted, terkait dengan jumlah kesalahan kode (NCE)
pada WCE (weight number of code errors)
• Metrik densitas
2. Error severity metrics

• Digunakan untuk mendeteksi situasi yang merugikan darijumlah
peningkatan kesalahan yang parah, yaitu pada situasi
dimana error dan weighted error yang diukur dengan error density
metrics yang umumnya menurun
• Dua error severity metrics
16
Software process timetable metrics
• Metrik berdasarkan pada 2 pendekatan, yaitu :
• Metrik TTO dan ADMC berdasarkan pada data untuk semua

penjadwalan milestone yang relevan dalan rencana proyek
Error removal effectiveness metrics
• Pengembangan perangkat lunak dapat diukur efektifitas dari penghapusan
kesalahan oleh sistem SQA setelah periode operasional reguler (biasanya 6
atau 12 bulan) dari sistem
• Penggabungan metrik error record dari tahap pengembangan
denganfailures records disusun selama tahun pertama atau periode tertentu
Software process productivity metrics

• Termasuk metrik “langsung” yang berhubungan dengan proyek
produktivitas sumber daya manusia serta metrik “tidak langsung” yang
berfokus pada tingkat penggunaan kembali perangkat lunak
Product metrics, kebanyakan aktivitas yang digunakan dalam fase ini berkaitan untuk
menyediakan layanan pelanggan
Layanan pelanggan ada 2 tipe utama, yaitu :
0. Help Desk Services
• Menginstruksi metode aplikasi perangkat lunak untuk pelanggan
• Memberikan solusi masalah implementasi pelanggan
• Layanan HD tergantung pada kualitas user interface, user manual
• Berdasarkan pada customer calls
17
1. Corrective Maintenance Services
• Mengoreksi kesalahan perangkat lunak yang diidentifikasi oleh
pelanggan/pengguna atau terdeteksi oleh tim layanan pelanggan
sebelum ditemukannya oleh pelanggan
• Jumlah kesalahan perangkat lunak dan densitas mereka secara
langsung berhubungan dengan kualitas pengembangan perangkat
lunak
• Berdasarkan laporan kesalahan
Metrik produk perangkat lunak (software product metrics) dibagi menjadi 4, yaitu :
0. HD quality metrics
1. HD productivity and effectiveness metrics
2. Corrective maintenance quality metrics
3. Corrective maintenance, productivity, and effectiveness quality metrics
Software maintenance activities meliputi :
0. Corrective maintenance
• Mengoreksi kesalahan perangkat lunak yang terdeteksi
selama regular operration perangkat lunak
1. Adaptive maintenance
• Menyesuaikan perangkat lunak yang ada pada pelanggan baru
atau requirement baru
2. Functional improvement maintenance
• Menambahkan fungsi baru pada perangkat lunak yang
ada, improvement of reliability
HD quality metrics
• Tipe dari HD quality metrics
1. HD calls density metrics
• Tingkat permintaan pelanggan untuk layanan HD
• Diukur dengan jumlah panggilan
2. Severity of HD calls metrics

• Tujuan dalam mendeteksi satu jenis situasi yang merugikan, yaitu
semakin parahnya panggilan HD
• Metrik yang digunakan adalah Average Severity of HD calls (ASHC)
18
• ASHC menunjukkan kegagalan yang terdeteksi selama jangka waktu
satu tahun
• Success of the HD services
1. Metrik untuk keberhasilan layanan HD adalah kapasitas untuk memecahkan
masalah yang diajukan oleh customer calls tanpa waktu yang ditentukan
dalam kontrak pelayanan (avaibility)
2. Metrik membandingkan aktual dengan waktu yang ditetapkan untuk
penyediaan layanan HD
3. Metrik yang digunakan yaitu :
HD productivity and Effectiveness Metrics

• HD productivity, adalah totalsumber daya yang diinvestasikanselama periodeyang
ditentukan
• Ada 2 HD productivinity metrics, yaitu :
• HD effectiveness merupakan sumber daya yang diinvestasikan dalam responding

to customers HD calls
Corrective Maintenance Quality Metrics

• Dibagi menjadi 4 tipe :
1. Software system failures density metrics
2. Software system failures severity metrics
3. Failures of maintenance services metrics
4. Software system avaibility metrics
• Software system failures density metrics
1. Merelasikan jumlah dan/atau jumlah pengaruh dari kegagalan
2. Berdasarkan pada catatankegagalan yangdiidentifikasi selama operasi
normal sistem perangkat lunak
19
• Software system failures severity metrics
• Mendeteksi situasi yang merugikan dari kegagalan yang semakin parah
dalam maintenance software
• Hasil yang dapat memicu pengujian ulang dari semua atau bagian sistem
perangkat lunak
• Metrik digunakan pada Average Severity of Softwware System
Failures (ASSSF) yang berarti kegagalan perangkat lunak yang terdeteksi
selama jangka waktu satu tahun
• Failures of maintenance services metrics

• Layanan maintenance dapat gagal karena :
• Ketidakmampuan untuk menyelesaikan koreksi kegagalan pada
waktu itu
• Koreksi kegagalan yang dilakukan dan pengoreksian ulang yang
diperlukan
• Panggilan pelanggan yang berkaitan dengan masalah kegagalan perangkat
lunak yang seharusnya diselesaikan setelah panggilan sebelumnya yang
umumnya diperlakukan sebagai kegagalan layanan maintenance
• Banyak organisasi yang membatasi susunan waktu untuk mengulang
panggilan untuk tiga bulan
• Metrik dugunakan pada Maintenance Repeated repair Failure (MRepF)
• RepYF adalah jumlah pengulangan panggilan kegagalan perangkat lunak

(layanan kegagalan)
• Software system avaibility metrics
• Jenis tersedianya sistem perangkat lunak, yaitu :
• Full avaibility, dimana semua fungsi sistem perangkat lunak
melakukandengan benar
• Vital avaibility, dimana tidak ada fungsi vital yang gagal ( tapi fungsi
vital tidak mungkin gagal)
20
• Total unavaibility, dimana semua fungsi sistem perangkat lunak
gagal
• Sumber untuk semua ketersediaan metrik adalah pengguna failure record
• Metrik digunakan :
Software corrective maintenance productivity and effectiveness metrics

• Corrective maintenance productivity, berkaitan dengan total sumber daya manusia
yang diinvestasikan dalam menjaga sistem perangkat lunak yang diberikan
• Corrective maintenance effectiveness, berkaitan dengan sumber daya yang
diinvestasikan dalam koreksi dari kegagalan tunggal
• Dalam sistem software maintenance :
• Lebih sedikit sumber daya untuk tugas pemeliharaan –> high productivity
• Lebih sedikit sumber daya, rata-rata untuk mengoreksi satu kegagalan –>
sistem pemeliharaan perangkat lunak yang lebih efektif
• Terdapat tiga metrik :
d. Alat dan Bahan

Peralatan
Bahan
dan produk
e. Prosedur Kerja
21
perangkat lunak.
g. Kesimpulan
dikembangkandan Menyusun metrik SQA.
h. Rubrik Penilaian
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
22
Acara 7
Pokok Bahasan : Mengelola Risiko Penjaminan Kualitas

1. Mahasiswa mampu melakukan identifikasi risiko jika proses penjaminan perangkat
lunak tidak dilakukan
2. Mahasiswa mampu melakukan identifikasi risiko bisnis yang terkait dengan review
kualitas proses dan produk perangkat lunak
3. Mahasiswa mampu merencanakan mitigasi risiko
b. Indikator
Ketepatan mengidentifikasi faktor risiko pelaksanaan proses Quality Assurance (QA)
c. Dasar Teori
Dalam upaya untuk melakukan indentifikasi risiko jika proses penjaminan
perangkat lunak dan identifikasi risiko bisnis yang terkait dengan review kualitas proses
maka salah satu framework yang bisa gunakan adalan ISO 31000:2009. Prinsip risiko
merupakan sebuah pedoman yang dimiliki organisasi ataupun individu didalam melakukan
tindakan dan berfikir. Dengan pedoman maka tujuan organisasi akan menjadi jelas dan
terarah. Tim manajemen risiko harus memahami prinsip 11 yang telah di kembangkan
oleh ISO pada clause 3. Berikut merupakan penjelasan dari prisip nomor 3 :
1) Manajemen resiko menciptakan dan melindungi nilai Manajemen resiko
berkontribusi untuk mendemostrasikan pencapaian dari tujuan dan peningkatan
dari performa di berbagai aspek seperti kesehatan, keamanan, kepatuhan kepada
regulasi, penerimaan public, perlindungan lingkungan, kualitas produk,
manajemen proyek, efisiensi didalam operasional, kepemerintahan, dan reputasi.
2) Manajemen resiko merupakan bagian penting didalam seluruh proses kegiatan
organisasi. Manajemen resiko tidak merupakan aktifitas yang dapat berjalan
sendiri yang terpisah dari aktifitas proses utama dari organisasi. Manajemen resiko
merupakan bagian dari tanggung jawab dari manajemen dan bagian penting
didalam proses kegiatan organisasi, termasuk didalamnya perencanaan strategi,
dan seluruh proyek dan perubahan proses manajemen.
3) Manajemen resiko merupakan bagian dari pembuatan keputusan. Manajemen
resiko membantu para pembuat keputusan untuk membuat keputusan yang tepat,
memprioristaskan tindakan dan membedakan antara alternative tindakan yang
ada.
23
4) Manajemen resiko secara jelas didalam memperlakukan ketidakpastian
(uncertainty). Manajemen resiko secara explicit atau jelas didalam menjelaskan
sifat ketidakpastian, dan bagaimana ketidakpastian tersebut harus berlakukan.
5) Manajemen resiko merupakan pendekatan sistematis, terstruktur, dan tepat
waktu. Manajemen resiko merupakan pendekatan sistematis , tepat waktu, dan
terstruktur yang berperan didalam memberikan hasil yang efisien, konsisten, dapat
sebanding dan dapat diandalkan.
6) Manajemen resiko berlandaskan dari informasi terbaik yang tersedia. Input dari
manajemen resiko adalah berdasarkan sumber informasi seperti data terdahulu,
pengalaman, umpan balik (feedback) dari stakeholder, pengamatan, perkiraan dan
keputusan ahli (expert judgement). Tetapi, pengambil keputusan harus
memberitahukan batasan dari data atau modeling ataupun kemungkinan perbedan
pada tiap ahli.
7) Manajemen resiko dapat disesuaikan. Manajemen resiko disesuaikan dengan
konteks eksternal dan internal organisasi dan risk profilenya.
8) Manajemen resiko mempertimbangkan faktor manusaia dan budaya. Manajemen
resiko mengenali kemampuan, tanggapan, dan niat dari pihak eksternal dan
internal yang dapat memfasilitasi atau dapat menghalangi pencapaian tujuan dari
organisasi.
9) Manajemen resiko adalah transparan dan inclusive (mencakup keseluruhannya)
Manajemen resiko merupakan kesesuaian dan tepatnya keikutsertaan dari
stakeholder dan tentunya para pembuat keputusan di semua level di organisasi,
memastikan bahwa manajemen resiko selalu sama (relevant) dan selalu up-todate.
Keterlibatan juga memperbolehkan para stakeholder dapat secara pantas
digabarkan dan mencatat pandangan para stakeholder didaam menentukan risk
criteria.
10) Manajemen resiko adalah bersifat dinamis, berulang, dan bertindak cepat didalam
menghadapi perubahan. Manaemen resiko secara berkelanjutan memahami dan
bertindak kepada perubahan. Ketika kejadian eksternal dan internal terjadi,
perubahan konteks dan pengetahuan berubah , pengawasan, dan peninjauan ulang
(review) dari resiko berlangsung, muncul, berubah dan sebagian lainnya hilang.
11) Manajemen resiko memfasilitasi keberlangsungan dari kemajuan organisasi
d. Alat dan Bahan
Peralatan
Bahan
- Template/standard dokumentasi proses review penjaminan kualitas proses
dan produk
24
e. Prosedur Kerja
2) Buatlah makalah yang berisi hal hal yang menjadi prinsip pengelolaan resiko
penjaminan kualitas produk pengembangan perangkat lunak dibagi dengan tiap
anggota kelompok.
Makalah beberapa hal prinsip dalam pengelolaan resiko penjaminan kualitas proses dan
produk pengembangan perangkat lunak.
g. Kesimpulan
Mahasiswa mampu mengidentifikasi resiko yang mungkin terjadi pada saat
pelaksanaan review kualitas
h. Rubrik Penilaian
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
25
Acara 8
Pokok Bahasan : Mengelola Risiko Penjaminan Kualitas

1. Mahasiswa mampu Melakukan identifikasi risiko jika proses penjaminan perangkat
lunak tidak dilakukan
2. Mahasiswa mampu Melakukan identifikasi risiko bisnis yang terkait dengan review
kualitas proses dan produk perangkat lunak
3. Mahasiswa mampu Merencanakan mitigasi risiko
b. Indikator
Ketepatan mengidentifikasi faktor risiko pelaksanaan proses Quality Assurance (QA)
c. Dasar Teori
Risk Assessment Pada proses ini tim manajemen resiko akan melakukan penilaian atau
assessment dengan menggunakan metode qualitative dan quantitative. Pada proses ini
terdapat langkahlangkah yang harus dilakukan, antara lain :
1) Risk identification
Merupakan proses identifikasi dari sumber resiko, area yang akan berdampak,
kejadian, penyebab dan kemungkinan dampak yang akan ditimbulkan
(consequence/impact). Tujuan dilakukan identifikasi resiko adalah memberikan daftar
resiko yang lengkap bedasarkan resiko yang dapat membuat, meningkatkan, mencegah,
menurunkan, mempercepat atau menghambat dari pencapaian tujuan. Tim manajemen
resiko harus memastikan semua kemungkinan resiko yang akan terjadi pada tahap ini,
karena setelah melalui tahapan ini resiko tidak akan diikutkan kedalam analisis
selanjutnya. Organisasi dan tim manajemen resiko dapat menentukan teknik dan tool
didalam melakukan identifikasi resiko, tetapi organisasi dan tim harus dapat memastikan
teknik dan tool 19 yang digunakan, efektif didalam mengidentifikasi resiko. Didalam
identifikasi resiko, tim dan organisasi menunjuk orang yang berpengalaman didalam
mengidentifikasi resiko.
2) Risk analysis
Merupakan proses pengembangan dari identifikasi resiko, dengan cara mengerti lebih
jauh sifat dari resiko. Proses analisis resiko akan menjadi input atau masukan dari risk
evaluation terkait keputusan, metode, dan strategi yang akan diambil. Analisis resiko
mempertimbangkan dampak positif dan negatif dari resiko yang akan terjadi dan
mempertimbangkan kemungkinan terjadinya resiko. Tim manajemen resiko harus
mempertimbangkan resiko yang mungkin akan mempengaruhi banyak tujuan (objective).
26
Tim juga akan mempertimbangkan efektifitas dan efisiensi dari control (pengawasan) yang
telah ada. Di dalam melakukan proses analisi, tiap anggota tim harus memiliki
kepercayaan yang tinggi dan didukung argument yang kuat terkait asumsi dari analisis
yang telah dilakukan, dan dikomunikasikan kepada pengambil keputusan. Faktor
perbedaan opini, ketidak pastian, ketersedian, kualitas, jumlah dan batasan dari informasi
harus di catat dan dapat dibicarakan bersama-sama dengan stakeholder maupun
pengambil keputusan
3) Risk evaluation
Pada tahap ini tim manajemen resiko akan melakukan evaluasi terhadap resiko yang
telah di analisis, sehingga dapat membantu didalam membuat keputusan. Pada tahap ini
tim menentukan resiko yang akan memerlukan tindakan lebih lanjut yang akan di
lanjutkan pada proses berikutnya yaitu risk treatment dan menentukan prioritas terkait
resiko yang akan diberikan tindakan terlebih dahulu. Tim akan membandingkan level
resiko yang ditemukan pada saat proses analisis resiko dengan kriteria resiko yang telah
dibuat pada tahap atau proses. Dengan membandingkan analisa tersebut, akan 20
mempermudah tim di dalam memberikan tindakan terkait resiko yang ada. Pada proses
ini tidak menutup kemungkinan, tim akan melakukan evaluasi lebih jauh terkait temuan
dari resiko yang ada.
4) Risk treatment atau risk response
Adalah sebuah aktifitas yang dilakukan untuk memberikan penanganan terhadap
risiko. Terdapat berbagai cara untuk memberi penanganan atau penanggulangan terhadap
risiko, diantaranya menghindari risiko dengan tidak melakukan atau memulai aktifitas
yang dapat menimbulkan risiko tersebut, mengurangi dampak yang ditimbulkan dengan
memberikan tanggapan yang tepat, menghilangkan sumber dari risiko, dan membagi
risiko tersebut dengan pihak ketiga atau outsourcing.
d. Alat dan Bahan
Peralatan
Bahan
- Template/standard dokumentasi proses pengelolaan resiko penjaminan
kualitas proses dan produk
e. Prosedur Kerja
2) Buatlah makalah yang berisi hal hal yang menjadi penilaian resiko penjaminan
kualitas produk pengembangan perangkat lunak dibagi dengan tiap anggota
kelompok.
27
Makalah beberapa hal prinsip dalam penilaian resiko penjaminan kualitas proses dan
produk pengembangan perangkat lunak.
g. Kesimpulan
Mahasiswa mampu mengidentifikasi resiko yang mungkin terjadi pada saat
pelaksanaan review kualitas
h. Rubrik Penilaian
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
28
Acara 9
Pokok Bahasan : Mendefenisikan Sumber Daya yang dibutuhkan

1. Mahasiswa mampu Menentukan kebutuhan sumber daya proses pelaksanaan
review kualitas proses dan produk pengembangan perangkat lunak
2. Mahasiswa mampu menentukan alat bantu penjaminan perangkat lunak yang
digunakan
b. Indikator
Ketepatan mengidentifikasi kualifikasi pelaksana proses penjaminan berdasarkan
objektif, batasan, dan keluaran pelaksanaan penjaminan
c. Dasar Teori
Dalam menentukan kebutuhan sumber daya ada bberapa hal yang harus diperhatikan,
antara lain :
1) Kualifikasi pelaksana proses penjaminan diidentifikasi berdasarkan objektif,
batasan, dan keluaran pelaksanaan penjaminan.
2) Waktu pelaksanaan tiap tahapan pekerjaan review ditentukan sesuai dengan
metoda Quality Assurance (QA) yang telah ditentukan.
3) Kebutuhan sumber daya pelaksanaan review didokumentasikan untuk setiap
tahapan pekerjaan
d. Alat dan Bahan
Peralatan
Bahan
- Template/standard dokumentasi mendefenisikan sumber daya yang
dibutuhkan
e. Prosedur Kerja
2) Buatlah makalah yang berisi hal hal yang menjadi menjadi sumber daya yang
dibutuhkan dalam penjaminan kualitas proses dan produk pengembangan
perangkat lunak dibagi dengan tiap anggota kelompok.
29
Makalah beberapa hal prinsip dalam menentukan kebutuhan sumberdaya proses
pelaksanaan review kualitas penjaminan kualitas proses dan produk pengembangan
perangkat lunak.
g. Kesimpulan
Mahasiswa mampu menentukan kebutuhan sumberdaya proses pelaksanaan review
kualitas proses dan produk pengembangan perangkat lunak dalam berdasarkan objektif,
batasan, dan keluaran pelaksanaan penjaminan
h. Rubrik Penilaian
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
30
Acara 10
Pokok Bahasan : Mendefenisikan Sumber Daya yang dibutuhkan

1. Mahasiswa mampu Menentukan kebutuhan sumber daya proses pelaksanaan
review kualitas proses dan produk pengembangan perangkat lunak
2. Mahasiswa mampu menentukan alat bantu penjaminan perangkat lunak yang
digunakan
b. Indikator
Ketepatan mengidentifikasi kualifikasi pelaksana proses penjaminan berdasarkan
objektif, batasan, dan keluaran pelaksanaan penjaminan
c. Dasar Teori
Dalam mementukan alat bantu penjaminan perangkat lunak yang digunakan maka
harus memperhatikan beberapa hal berikut ini :
1) Alat bantu diidentifikasi sesuai dengan metode dan acuan Quality Assurance (QA)
yang telah ditentukan
2) Alat bantu yang tersedia dianalisis kesesuaiannya dengan metode pengembangan
yang telah ditentukan
d. Alat dan Bahan
Peralatan
Bahan
- Template/standard dokumentasi mendefenisikan sumber daya yang
dibutuhkan
e. Prosedur Kerja
2) Buatlah makalah yang berisi cara menentukan alat bantu yang digunakan dalam
penjaminan kualitas proses dan produk pengembangan perangkat lunak dibagi
dengan tiap anggota kelompok.
Makalah beberapa hal prinsip dalam menjadi alat bantu yang dibutuhkan dalam
penjaminan kualitas proses dan produk pengembangan perangkat lunak.
31
g. Kesimpulan
Mahasiswa mampu menentukan alat bantu pelaksanaan proses penjaminan
berdasarkan objektif, batasan, dan keluaran pelaksanaan penjaminan
h. Rubrik Penilaian
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
32
Acara 11
Pokok Bahasan : Integrasi Penjaminan Kualitas ke dalam organisasi
pengembang
Acara Praktikum/Praktek: Minggu 6/1
1. Mahasiswa mampu menentukan struktur pemanfaatan sumber daya yang
sesuai dengan organisasi
2. Mahasiswa mampu menentukan pembagian tugas dan tanggung jawab
SDM dalam pelaksanaan penjaminan kualitas
3. Mahasiswa mampu menyusun prosedur acuan pelaksanaan penjaminan
kualitas perangkat lunak
b. Indikator
Ketepatan dalam menjelaskan peran SDM pada SQA, ketepatan dalam menyusun
prosedur acuan pelaksanaan penjaminan kualitas perangkat lunak.
c. Dasar Teori
1. Pengorganisasian Penjaminan Kualitas Perangkat Lunak
Basis organisasi SQA (Software Quality Assurance) mencakup manajer, personel
pengujian, unit SQA, dan praktisi yang tertarik pada kualitas perangkat lunak (wali
SQA, anggota komite SQA, dan anggota forum SQA). Semua aktor ini berkontribusi
pada kualitas perangkat lunak. Tujuan utama dari basis organisasi SQA adalah sebagai
berikut:
- Untuk mengembangkan dan mendukung implementasi komponen SQA.
- Untuk mendeteksi penyimpangan dari prosedur dan metodologi SQA.
- Untuk menyarankan perbaikan pada komponen SQA.
2. Peran manajemen dalam SQA
Tanggung jawab manajemen puncak (melalui eksekutif yang bertanggung jawab
atas kualitas perangkat lunak), manajemen departemen, dan manajemen proyek
meliputi:
- Definisi kebijakan mutu
- Tindak lanjut implementasi kebijakan mutu yang efektif
- Alokasi sumber daya yang cukup untuk mengimplementasikan kebijakan mutu
- Penugasan staf yang memadai
- Tindak lanjut kepatuhan terhadap prosedur jaminan kualitas
- Solusi masalah jadwal, anggaran, dan hubungan pelanggan.
33
3. SQA Unit
Unit dan penguji perangkat lunak ini adalah satu-satunya bagian dari basis
organisasi SQA yang mengabdikan diri penuh waktu untuk masalah SQA. Semua
segmen lain dari basis organisasi SQA (staf manajerial dan profesional) hanya
menyumbangkan sebagian waktu mereka untuk masalah kualitas perangkat lunak.
Dengan demikian, tugas unit SQA adalah sebagai penggerak utama, pemrakarsa, dan
koordinator sistem SQA dan penerapannya. Tugas ini dapat dipecah menjadi beberapa
peran utama:
- Persiapan program kualitas tahunan
- Konsultasi dengan staf internal dan pakar luar tentang perangkat lunak
- masalah kualitas
- Pelaksanaan audit penjaminan mutu internal
- Kepemimpinan berbagai komite penjaminan mutu
- Mendukung komponen infrastruktur penjaminan mutu yang ada dan
- pembaruan, dan pengembangan komponen baru.
4. SQA trustees, committees and forums
SQA trustees adalah anggota tim pengembangan dan pemeliharaan yang memiliki
minat khusus dalam kualitas perangkat lunak dan siap untuk mencurahkan sebagian
waktu mereka untuk masalah ini. Kontribusi mereka meliputi:
- Memecahkan masalah kualitas tim atau unit lokal
- Mendeteksi penyimpangan dari prosedur dan instruksi kualitas
- Memulai perbaikan dalam komponen SQA
- Melaporkan ke unit SQA tentang masalah kualitas di tim atau unit mereka.
Anggota komite SQA (SQA Committees) adalah anggota dari berbagai unit
pengembangan dan pemeliharaan perangkat lunak, dan biasanya ditunjuk untuk
layanan jangka atau ad hoc. Masalah utama yang ditangani oleh komite adalah:
1) Solusi masalah kualitas perangkat lunak.
2) Analisis catatan masalah dan kegagalan serta catatan lainnya, diikuti
dengan inisiasi tindakan korektif dan pencegahan bila perlu.
3) Inisiasi dan pengembangan prosedur dan instruksi baru; memperbarui
materi yang ada.
4) Inisiasi dan pengembangan komponen SQA baru dan peningkatan
komponen yang ada.
Forum SQA terdiri dari para profesional dan praktisi yang bertemu dan/atau
memelihara situs Internet secara sukarela untuk mendiskusikan masalah kualitas yang
berkaitan dengan proses pengembangan dan pemeliharaan. Mereka berbagi
pengalaman dan kesulitan mereka serta mencoba untuk memulai perbaikan dalam
34
proses perangkat lunak. Oleh karena itu, forum dapat dianggap sebagai sumber
informasi dan inisiatif SQA yang penting.
5. Peninjauan Kontrak (Contract review)
Perangkat lunak dapat dikembangkan dalam kerangka kontrak yang dinegosiasikan
dengan pelanggan atau sebagai tanggapan atas perintah internal yang berasal dari
departemen lain. Pesanan internal mungkin memerlukan permintaan untuk
mengembangkan sistem perangkat lunak firmware untuk disematkan dalam produk
perangkat keras, pesanan untuk produk perangkat lunak untuk dijual sebagai paket,
atau pesanan untuk pengembangan perangkat lunak administratif untuk diterapkan di
dalam perusahaan. Dalam semua kasus ini, unit pengembangan berkomitmen pada
spesifikasi fungsional, anggaran, dan jadwal yang disepakati. Oleh karena itu, kegiatan
tinjauan kontrak harus mencakup pemeriksaan rinci terhadap (a) rancangan proposal
proyek dan (b) rancangan kontrak. Secara khusus, kontrak kegiatan peninjauan
meliputi:
• Klarifikasi kebutuhan pelanggan
• Tinjauan jadwal proyek dan perkiraan kebutuhan sumber daya
• Evaluasi kapasitas staf profesional untuk melaksanakan proyek yang diusulkan
• Evaluasi kapasitas pelanggan untuk memenuhi kewajibannya
• Evaluasi risiko pembangunan.
Pendekatan serupa diterapkan dalam tinjauan kontrak pemeliharaan. Tinjauan
tersebut memperhitungkan bahwa selain koreksi kesalahan, layanan pemeliharaan
mencakup adaptasi perangkat lunak dan aktivitas pengembangan perangkat lunak
terbatas demi peningkatan kinerja (disebut "pemeliharaan peningkatan
fungsionalitas").
d. Alat dan Bahan
Alat:
- Laptop atau komputer
Bahan:
- Materi SQA
e. Prosedur Kerja
1. Bentuklah kelompok dengan jumlah anggota 5-6 orang.
2. Buatlah makalah yang berisi peran SDM pada SQA dibagi dengan tiap anggota
kelompok.
3. Rangkum prosedur pelaksanaan penjaminan kualitas perangkat lunak.
4. Sertakan daftar rujukan yang digunakan.
f. Hasil dan pembahasan
Makalah peran SDM SQA
35
g. Kesimpulan
Mahasiswa mampu memahami peran Sumber Daya Manusia pada aktivitas
penjaminan kualitas perangkat lunak.
h. Rubrik
No Indikator Skor*
Kekompakan tim baik, susunan makalah baik dan ketepatan dalam
1 1 2 3 4
menjelaskan dari tugas ditunjang dengan bukti referensi
Kekompakan tim baik, susunan makalah kurang dan ketepatan dalam
2 1 2 3 4
Kekompakan tim baik, susunan makalah kurang dan tetapi kurang
3 1 2 3 4
tepat dalam menjelaskan tugas
Kelompopk tidak kompak, susunan makalah kurang, ketidaktepatan
4 1 2 3 4
dalam menjelaskan tugas
Jumlah skor
36
Acara 12
Pokok Bahasan : Integrasi Penjaminan Kualitas ke dalam organisasi
pengembang
1. Mahasiswa mampu menentukan struktur pemanfaatan sumber daya yang
sesuai dengan organisasi
2. Mahasiswa mampu menentukan pembagian tugas dan tanggung jawab
SDM dalam pelaksanaan penjaminan kualitas
3. Mahasiswa mampu menyusun prosedur acuan pelaksanaan penjaminan
b. Indikator
Ketepatan dalam menjelaskan peran SDM pada SQA, ketepatan dalam menyusun
prosedur acuan pelaksanaan penjaminan kualitas perangkat lunak.
c. Dasar Teori
1) Peninjauan Kontrak (Contract Review)
Beberapa situasi dapat menyebabkan perusahaan perangkat lunak (“pemasok”)
menandatangani kontrak dengan pelanggan. Yang paling umum adalah:
(1) Keikutsertaan dalam tender.
(2) Pengajuan proposal sesuai dengan RFP pelanggan.
(3) Penerimaan pesanan dari pelanggan perusahaan.
(4) Penerimaan permintaan atau pesanan internal dari departemen lain dalam
organisasi.
Review kontrak adalah komponen SQA yang dirancang untuk memandu review
draft proposal dan dokumen kontrak. Jika berlaku, tinjauan kontrak juga memberikan
pengawasan terhadap kontak yang dilakukan dengan calon mitra proyek dan
subkontraktor. Proses review sendiri dilakukan dalam dua tahap:
• Tahap Satu – Tinjauan draf proposal sebelum diajukan ke calon pelanggan
(“peninjauan draf proposal”). Tahap ini meninjau draft proposal akhir dan dasar
proposal: dokumen persyaratan pelanggan, rincian tambahan pelanggan dan
penjelasan tentang persyaratan, perkiraan biaya dan sumber daya, kontrak yang
ada atau draft kontrak pemasok dengan mitra dan subkontraktor.
• Tahap Dua – Review draft kontrak sebelum penandatanganan (“contract draft
review”). Tahap ini meninjau draft kontrak berdasarkan proposal dan pemahaman
(termasuk perubahan) yang dicapai selama sesi negosiasi kontrak.
37
Proses peninjauan dapat dimulai setelah draf dokumen yang relevan telah
diselesaikan. Orang-orang yang melakukan tinjauan secara menyeluruh
memeriksa draf sambil mengacu pada berbagai subjek tinjauan yang
komprehensif.
2) Tujuan peninjauan draf proposal
Sembilan tujuan peninjauan draf proposal yang memastikan kegiatan berikut telah
dilaksanakan dengan baik:
1. Persyaratan pelanggan telah diklarifikasi dan didokumentasikan.
2. Pendekatan alternatif untuk melaksanakan proyek telah diperiksa.
3. Aspek formal dari hubungan antara pelanggan dan perusahaan perangkat
lunak telah ditentukan.
4. Identifikasi risiko pembangunan.
5. Estimasi sumber daya dan jadwal proyek yang memadai telah disiapkan.
6. Pemeriksaan kapasitas perusahaan sehubungan dengan proyek.
7. Pemeriksaan kemampuan nasabah untuk memenuhi komitmennya.
8. Definisi kondisi partisipasi mitra dan subkontraktor.
9. Pengertian dan perlindungan hak milik.
d. Alat dan Bahan
Alat:
- Laptop
Bahan:
- Template review proposal
- Template draf kontrak review
e. Prosedur Kerja
1) Carilah template review proposal dan template review draf kontrak.
2) Edit kedua template tersebut, sesuaikan dengan topik perangkat lunak yang
kelompok Anda akan kembangkan.
3) Diskusikan dengan kelompok Anda jawaban dari pertanyaan-pertanyaan
berikut.
- Review kontrak dapat dilakukan oleh “orang dalam” (anggota tim proposal
organisasi atau anggota staf lainnya) atau oleh “orang luar”.
(1) Apa keuntungan dan kerugian mempekerjakan orang luar dibandingkan
dengan orang dalam untuk review draf proposal?
(2) Apa keuntungan dan kerugian mempekerjakan orang luar dibandingkan
dengan orang dalam untuk tinjauan draf kontrak?
- Penyedia Perangkat Lunak Nasional sangat tertarik dengan area BI (Business
Intelligence) yang baru berkembang untuk perusahaan perdagangan
elektronik. Karena perusahaan sangat ingin mendapatkan pengalaman di
38
bidang ini, mereka sangat tertarik untuk memenangkan tender yang
dikeluarkan oleh salah satu produsen kosmetik terkemuka. Tim proposal
memperkirakan bahwa untuk memenangkan kontrak, proposal mereka tidak
boleh melebihi jumlah $650 000. Dengan demikian, kutipan mereka adalah
$647.000. Karena semua anggota tim menyadari bahwa biaya penyelesaian
proyek oleh pengembangan perusahaan yang tidak berpengalaman
departemen secara substansial akan melebihi jumlah ini, mereka memutuskan
bahwa ada sedikit gunanya dalam upaya investasi untuk memperkirakan biaya
aktual proyek.
(1) Apakah Anda setuju dengan keputusan tim untuk tidak memperkirakan
biaya proyek?
(2) Jika Anda tidak setuju, apa argumen Anda yang mendukung estimasi biaya?
3) Buatlah 1 dokumen yang memuat template review dan jawaban dari
pertanyaan di atas.
- Template contract & proposal review yang disesuaikan dengan topik
pengembangan perangkat lunak masing-masing kelompok dan jawaban
pertanyaan diskusi
g. Kesimpulan
Mahasiswa mampu memahami prosedur contract & proposal review pada aktivitas
h. Rubrik
No Indikator Skor*
1 1 2 3 4
2 1 2 3 4
3 1 2 3 4
4 1 2 3 4
Jumlah skor
39
Acara 13
Pokok Bahasan : Memverifikasi Pelaksanaan Tahapan Pengembangan
Perangkat Lunak
1. Mahasiswa mampu mengumpulkan hasil tahapan pengembangan
perangkat lunak
2. Mahasiswa mampu menghitung nilai metriks berdasarkan data-data
tersedia
3. Mahasiswa mampu membuat dokumen test plan untuk pengujian
perangkat lunak.
b. Indikator
Ketepatan dalam menjelaskan perbedaan verifikasi, validasi dan kualifikasi pada
aktifitas SQA, serta ketepatan dalam menyusun dokumen test plan untuk
pengujian perangkat lunak.
c. Dasar Teori
1. Verifikasi, Validasi dan Kualifikasi
Tiga aspek jaminan kualitas produk perangkat lunak (laporan, kode, dll.) diperiksa
di bawah rubrik verifikasi, validasi dan kualifikasi. IEEE Std 610.12-1990 (IEEE, 1990)
mendefinisikan aspek-aspek tersebut sebagai berikut:
• Verifikasi – Proses mengevaluasi sistem atau komponen untuk menentukan
apakah produk dari fase pengembangan tertentu memenuhi kondisi yang
diterapkan pada awal fase itu.
• Validasi – Proses mengevaluasi sistem atau komponen selama atau pada
akhir proses pengembangan untuk menentukan apakah memenuhi
persyaratan yang ditentukan.
• Kualifikasi – Proses yang digunakan untuk menentukan apakah suatu sistem
atau komponen cocok untuk penggunaan operasional.
Menurut definisi IEEE, verifikasi memeriksa konsistensi produk yang dikembangkan
dengan produk yang dikembangkan pada fase sebelumnya. Saat melakukannya,
pemeriksa mengikuti proses pengembangan dan mengasumsikan bahwa semua fase
pengembangan sebelumnya telah diselesaikan dengan benar, baik seperti yang
direncanakan semula atau setelah penghapusan semua cacat yang ditemukan. Asumsi
ini memaksa pemeriksa untuk mengabaikan penyimpangan dari persyaratan asli
pelanggan yang mungkin telah diperkenalkan selama proses pengembangan.
40
Validasi mewakili kepentingan pelanggan dengan memeriksa sejauh mana
kepatuhan terhadap persyaratan awalnya. Tinjauan validasi yang komprehensif
cenderung meningkatkan kepuasan pelanggan dari sistem. Kualifikasi berfokus pada
aspek operasional, di mana pemeliharaan menjadi isu utama. Komponen perangkat
lunak yang telah dikembangkan dan didokumentasikan.
Tabel 1 Durasi kegiatan jaminan kualitas (Quality Assurance) – contoh
sistem pemantauan pasien
No. kegiatan penjaminan mutu / Durasi kegiatan Durasi koreksi dan
Quality Assurance Activity penjaminan mutu perubahan (hari)
/ Quality
Assurance (hari)
1 Tinjauan desain definisi kebutuhan 2 1
2 Tinjauan desain analisis unit kamar 2 2
pasien
3 Tinjauan desain analisis unit kontrol 1 2
4 Tinjauan desain dari desain awal 1 1
5 Inspeksi desain unit kamar pasien 1 2
6 Inspeksi desain unit kontrol 1 3
7 Review desain prototipe unit kamar 1 1
pasien
8 Tinjauan desain prototipe unit 1 1
kontrol
9 Inspeksi desain terperinci untuk 3 3
setiap komponen antarmuka
perangkat lunak
10 Tinjauan desain rencana pengujian 3 1
untuk unit kamar pasien dan unit
kontrol
11 Tes unit kode perangkat lunak 4 2
untuk setiap modul antarmuka unit
kamar pasien
12 Uji integrasi kode perangkat lunak 3 3
unit kamar pasien
13 Uji integrasi kode perangkat lunak 2 3
unit kontrol
14 Uji sistem sistem perangkat lunak 10 5
yang telah selesai
41
15 Tinjauan desain manual pengguna 3 2
2. Metrik Proses dan Proyek Perangkat Lunak
Proses perangkat lunak dan proyek metrik merupakan :
- ukuran kuantitatif
- alat manajemen
- Mengukur efektivitas proses perangkat lunak dan proyek-proyek yang
dilakukan dengan menggunakan proses sebagai kerangka
Dasar kualitas dan produktivitas data dikumpulkan. Data dianalisis, dibandingkan
dengan rata-rata masa lampau, dan dinilai. Tujuannya adalah untuk menentukan
apakah kualitas dan produktivitas perbaikan telah terjadi. Data tersebut juga dapat
digunakan untuk menentukan area masalah. Solusi dapat dikembangkan dan proses
perangkat lunak dapat ditingkatkan.
a. Metrik Domain Proses
Metrik Proses merupakan kumpulan seluruh proyek pada jangka waktu tertentu.
Metrik Proses digunakan untuk membuat keputusan strategis. Tujuannya, memberikan
seperangkat indikator proses yang mengarah pada perbaikan proses perangkat lunak
dalam jangka panjang. Cara untuk mengetahui bagaimana tuk meningkatkan proses :
- Mengukur atribut tertentu dari proses
- Mengembangkan satu set metrik bermakna berdasarkan atribut tersebut
- Menggunakan metrik untuk memberikan indikator yang mengarah pada
strategi untuk perbaikan
Mengukur efektivitas proses dengan menggunakan satu set metrik berdasarkan
pada hasil/luaran dari proses seperti :
- Kesalahan ditemukan sebelum rilis dari perangkat lunak
- Cacat pengiriman ke dan dilaporkan oleh pengguna akhir
- Penyebaran produk kerja
- Usaha manusia yang dikeluarkan
- Waktu kalender yang dikeluarkan
- Kesesuaian dengan jadwal
- Waktu dan usaha untuk menyelesaikan setiap kegiatan generik
b. Metrik Domain Proyek
Metrik proyek memungkinkan manajer proyek perangkat lunak untuk :
- Menilai status proyek yang sedang berlangsung
- Melacak potensi risiko
- Mengungkap masalah dalam suatu daerah sebelum statutsnya menjadi
kritis
- Sesuaikan alur kerja atau tugas
42
- Mengevaluasi kemampuan tim proyek untuk mengontrol kualitas produk
kerja perangkat lunak
Banyak metrik yang sama yang digunakan pada kedua proses dan domain proyek.
Metrik proyek yang digunakan untuk membuat keputusan taktis. Metrik proyek
digunakan untuk menyesuaikan alur kerja proyek dan kegiatan teknis.
c. Pengukuran Perangkat Lunak
Dua kategori pengukuran perangkat lunak:
- Pengukuran Langsung :
o proses perangkat lunak (biaya, usaha, dll)
o produk perangkat lunak (baris kode yang dihasilkan, kecepatan
eksekusi, cacat dilaporkan dari waktu ke waktu, dll)
- Pengukuran Tidak Langsung :
o produk perangkat lunak (fungsi, kualitas, kompleksitas,
efisiensi, kehandalan, pemeliharaan, dll)
d. Metrik berorientasi Size (ukuran)
Diperoleh melalui normalisasi kualitas dan / atau produktivitas tindakan dengan
mempertimbangkan ukuran perangkat lunak yang dihasilkan. Seribu baris kode (Kilo
Line Of Code/KLOC) dipilih sebagai nilai normalisasi. Metrik mencakup:
- Kesalahan per KLOC - Kesalahan per orang-bulan
- Cacat per KLOC - KLOC per orang-bulan
- Dolar per KLOC - dolar per halaman dokumentasi
- Halaman dokumentasi per KLOC
e. Metrik berorientasi Fungsi
Metrik berorientasi fungsi menggunakan ukuran fungsi yang ditunjukkan oleh
aplikasi sebagai nilai normalisasi. Umumnya metrik ini menggunakan Titik Fungsi
(Function Point).
FP = Total * [0.65 + 0.01 * jumlah (nilai Faktor)
Nilai-nilai Titik Fungsi pada proyek-proyek masa lalu dapat digunakan untuk
perhitungan, misalnya, rata-rata jumlah baris kode per titik fungsi (misalnya, 60).
d. Alat dan Bahan
Alat:
- Laptop
Bahan:
- Buku Software Quality Assurance
e. Prosedur Kerja
1. Buatlah sebuah makalah dengan kelompok Anda yang berisi metrik-metrik
yang ada pada aktivitas penjaminan kualitas perangkat lunak selain yang sudah
dijelaskan pada dasar teori.
43
Makalah metrik penjaminan kualitas perangkat lunak
g. Kesimpulan
Mahasiswa memahami metrik penjaminan kualitas perangkat lunak
h. Rubrik
Indikator Skor*
No
1 1 2 3 4
2 1 2 3 4
3 1 2 3 4
4 1 2 3 4
Jumlah skor
44
Acara 14
Pokok Bahasan : Memverifikasi Pelaksanaan Tahapan Pengembangan
Perangkat Lunak
i. Capaian Pembelajaran Mata Kuliah (CPMK)

1. Mahasiswa mampu mengumpulkan hasil tahapan pengembangan
perangkat lunak
2. Mahasiswa mampu menghitung nilai metriks berdasarkan data-data
tersedia
3. Mahasiswa mampu membuat dokumen test plan untuk pengujian
perangkat lunak.
j. Indikator
Ketepatan dalam menjelaskan perbedaan verifikasi, validasi dan kualifikasi pada
aktifitas SQA, serta ketepatan dalam menyusun dokumen test plan untuk
pengujian perangkat lunak.
k. Dasar Teori
1. Test Plan
Rencana Uji (test plan) dapat didefinisikan sebagai dokumen yang mendefinisikan
ruang lingkup, tujuan, dan pendekatan untuk menguji aplikasi perangkat lunak.
Rencana Uji adalah istilah dan penyampaian. Rencana Uji adalah dokumen yang
mencantumkan semua aktivitas dalam proyek QA, menjadwalkannya, mendefinisikan
ruang lingkup proyek, peran & tanggung jawab, risiko, kriteria masuk & keluar, tujuan
pengujian, dan hal lain yang dapat Anda pikirkan.
Rencana Tes adalah seperti yang saya suka sebut sebagai 'dokumen super' yang
mencantumkan semua yang perlu diketahui dan dibutuhkan. Silakan periksa tautan ini
untuk informasi lebih lanjut dan sampel. Rencana Uji akan dirancang berdasarkan
persyaratan. Saat menugaskan pekerjaan ke teknisi pengujian, karena beberapa
alasan salah satu penguji digantikan oleh yang lain. Di sini, Rencana Uji diperbarui.
Strategi Pengujian menguraikan pendekatan pengujian dan segala sesuatu yang
mengelilinginya. Ini berbeda dari Rencana Uji, dalam arti bahwa strategi Uji hanya
bagian dari rencana uji. Ini adalah dokumen uji hardcore yang bersifat generik dan
statis. Ada juga argumen tentang pada tingkat apa strategi atau rencana pengujian
digunakan - tetapi saya benar-benar tidak melihat perbedaan yang mencolok.
45
Contoh: Test plan memberikan informasi tentang siapa yang akan menguji pada
jam berapa. Misalnya, Modul 1 akan diuji oleh “X tester”. Jika penguji Y menggantikan
X karena alasan tertentu, rencana pengujian harus diperbarui.
Rencana Uji adalah dokumen yang menyediakan informasi lengkap tentang tugas
pengujian yang terkait dengan Proyek Perangkat Lunak. Ini memberikan detail seperti
Lingkup pengujian, Jenis pengujian, Tujuan, Metodologi Pengujian, Upaya Pengujian,
Risiko & Kontinjensi, Kriteria Rilis, Hasil Uji, dll. Ini melacak kemungkinan pengujian
yang akan dijalankan pada sistem setelah pengkodean.
Rencana pengujian jelas akan berubah. Awalnya, rancangan rencana uji akan
dikembangkan berdasarkan kejelasan proyek saat itu. Rencana awal ini akan
dimodifikasi seiring berjalannya proyek. Manajer tim pengujian atau Pemimpin Tes
dapat menyiapkan dokumen rencana pengujian. Ini menjelaskan Spesifikasi dan dapat
berubah berdasarkan hal yang sama.
Apa yang harus diuji, kapan harus diuji, siapa yang akan diuji, dan bagaimana cara
menguji akan ditentukan dalam rencana pengujian. Rencana Uji akan memilah daftar
masalah, dependensi, dan risiko yang mendasarinya.
Isi Dokumen rencana uji (struktur rencana uji IEEE-829)
1. Pengenal Rencana Uji
2. pengantar
3. Item Tes
4. Masalah Risiko Perangkat Lunak
5. Fitur yang akan diuji
6. Fitur tidak untuk diuji
7. Mendekati
8. Item Kriteria Lulus/Gagal (atau) Kriteria Penerimaan
9. Kriteria Penangguhan dan Persyaratan Dimulainya Kembali
10. Hasil Uji
11. Tugas Tes
12. Persyaratan Lingkungan
13. Kepegawaian dan kebutuhan Pelatihan
14. tanggung jawab
15. Jadwal
16. Persetujuan
2. Test Case
Selama proses pengujian perangkat lunak, kasus uji mendefinisikan prasyarat
untuk pelaksanaan pengujian dan menawarkan wawasan tentang berbagai spesifikasi
dan persyaratan yang dinyatakan sebelum dimulainya pengujian. Sebagai bagian
integral dari proses, dokumen ini digunakan untuk mendefinisikan berbagai komponen
46
penting dari pengujian perangkat lunak seperti, input pengujian, kondisi eksekusi,
prosedur pengujian, dan hasil yang diharapkan. Tujuan utama dari dokumen ini adalah
untuk membantu penguji memenuhi tujuan pengujian serta persyaratan yang
dinyatakan sebelum dimulainya proses.
Jenis Test Case:
• Formal test case: Untuk merancang kasus uji formal, tim mengikuti format
standar, yang memungkinkan mereka membuat kasus uji yang menawarkan
kemudahan pemahaman kepada anggota tim lainnya dan yang mencakup
semua kemungkinan pengujian secara lengkap. Kasus uji formal selanjutnya
dibagi menjadi dua jenis kasus uji - positif dan negatif, yang terutama
dirancang untuk memastikan bahwa semua persyaratan aplikasi diuji dengan
benar oleh tim. Kasus uji formal juga menawarkan berbagai detail tentang
perangkat lunak seperti prasyarat, data input & output, antara lain.
• Informal test case: Kasus uji ini terutama dirancang untuk aplikasi dan
perangkat lunak tanpa persyaratan atau spesifikasi formal. Kasus uji informal
dapat ditulis dengan cara yang dianggap cocok oleh tim atau oleh individu yang
bertanggung jawab untuk membuat kasus uji. Selain itu, dalam kasus uji jenis
ini, input dan output sekarang diketahui oleh tim.
Dokumen test case menawarkan informasi lain-lain tentang proses pengujian
perangkat lunak. Dari persyaratan dasar hingga prosedur pengujian, semuanya
tercakup dalam dokumen ini, yang menawarkan tim kesempatan untuk
mengomunikasikan detail utama tentang proses dengan anggota tim lainnya serta
pemangku kepentingan. Rincian lain yang termasuk dalam dokumen ini adalah:
• Judul tes.
• Skenario pengujian.
• Deskripsi tes.
• Langkah & prosedur.
• Prasyarat.
• Hasil aktual & yang diharapkan.
• Lingkungan pengujian.
l. Alat dan Bahan
Alat:
- Laptop
Bahan:
- Template dokumen test plan dan test case
m. Prosedur Kerja
47
1. Carilah contoh dokumen test plan dan test case (untuk pengujian blackbox) dan
sesuaikan dengan topik pengembangan aplikasi yang kelompok Anda
kembangkan.
2. Dapat berupa aplikasi web ataupun mobile.
n. Hasil dan Pembahasan
- Dokumen test plan dan test case sesuai dengan aplikasi yang
dikembangkan
o. Kesimpulan
Mahasiswa mampu menyusun dokumen test plan maupun test case
p. Rubrik
No Indikator Skor*
1 Kekompakan tim baik, susunan dokumen (test plan dan test case) baik 1 2 3 4
Kekompakan tim baik, susunan dokumen (test plan dan test case)
2 1 2 3 4
kurang lengkap
Kekompakan tim cukup, susunan dokumen (test plan dan test case)
3 1 2 3 4
kurang
Kelompopk tidak kompak, susunan dokumen (test plan dan test case)
4 1 2 3 4
kurang
Jumlah skor
48
Acara 15
Pokok Bahasan : Melakukan Pengujian Kualitas Perangkat Lunak
Secara Manual (Web)

1) Mahasiswa mampu Menyiapkan data uji yang sesuai dengan kebutuhan
penggunaan perangkat lunak yang diuji
2) Mahasiswa mampu Menguasai penggunaan minimal satu standar proses
penjaminan kualitas perangkat lunak
3) Mahasiswa mampu Membaca dan memahami dokumen spefikasi disain
perangkatm lunak, spesifikasi produk perangkat lunak, dan skenario uji
perangkat lunak
b. Indikator
Ketepatan mengidentifikasi spesifikasi kebutuhan perangkat lunak yaitu pada
aplikasi web, spesifikasi perancangan perangkat lunak (pada aplikasi web), dan
spesifikasi produk aplikasi web yang diuji dan ketepatan pemilihan dan penggunaan
data uji.
c. Dasar Teori
White-box Testing
White Box Testing adalah salah satu cara untuk menguji suatu aplikasi atau
software dengan melihat modul untuk memeriksa dan menganalisis kode program
ada yang salah atau tidak. Jika modul ini dan telah diproduksi dalam output yang
tidak memenuhi persyaratan, kode akan dikompilasi ulang dan diperiksa lagi
sampai mencapai apa yang diharapkan singkatnya White Box Testing ini menguji
dengan cara melihat Pure Code dari suatu aplikai/software yang diuji tanpa
memperdulikan Tampilan atau UI dari aplikasi tersebut..
Teknik White-box Testing, sebagai berikut :
• Basis Path Testing
Basis path testing merupakan metode yang memungkinkan perancang
testcase untuk membuat pengukuran kompleksitas logikal dari rancangan
prosedural dan menggunakan pengukuran ini sebagai panduan untuk
mendefinisikan himpunan basis dari jalur eksekusi. Test case yang dibuat
untuk menguji himpunan basis dijamin akan mengeksekusi setiap statement
di dalam program sekurangnya sekali pada saat pengujian
• Flow Graph
49
Flow graph merupakan notasi sederhana untuk merepresentasi control flow.
• Cyclomatic Complexity
Cyclomatic complexity digunakan untuk mengetahui jumlah jalur yang perlu
dicari. Cyclomatic complexity adalah metric software yang menyediakan
ukuran kuantitatif dari kompleksitas logikal program. Nilai yang dihitung bagi
cyclomatic complexity menentukan jumlah jalur-jalur yang independen dalam
kumpulan basis suatu program dan memberikan jumlah tes minimal yang
harus dilakukan untuk memastikan bahwa semua pernyataan telah dieksekusi
sekurangnya satu kali.
Cyclomatic complexity mempunyai fondasi dalam teori graph dan dapat
dihitung dengan satu dari tiga cara :
• Jumlah region sama dengan cyclomatic complexity.
• Cyclomatic complexity, V(G), untuk sebuah flow graph, G, didefnisikan
sebagai: V(G) = E – N + 2 E adalah jumlah edge pada flow graph, dan N
adalah jumlah node pada flow graph.
• Cyclomatic complexity, V(G), untuk flow graph, G, juga didefinisikan
sebagai: V(G) = P + 1 P adalah jumlah predicate nodes yang terdapat pada
flow graph G.
• Graph Matrix
Prosedur untuk membuat flow graph dan menentukan himpunan basis path dapat
diterima berdasarkan mekanisme. Untuk mengembangkan software yang
membantu pengujian basis path, sebuah struktur data yang disebut graph matrix,
dapat sangat bermanfaat. Graph matrix adalah matriks kotak yang ukurannya
(jumlah baris dan kolom) sama untuk jumlah node pada flow graph. Setiap baris
dan kolom berhubungan dengan node yang teridentifikasi, dan data matriks
berhubungan dengan koneksi (edge) antara
• Kelemahan White Box-Testing:
a) Sangat mahal untuk dilakukan karena membutuhkan tester yang terampil
untuk melakukan pengujian.
b) Pada perangkat lunak yang jenisnya besar, metode white box testing ini
dianggap boros karena melibatkan banyak sumberdaya untuk
melakukannya.
c) Tidak mempedulikan Tampilan UI aplikasinya.
• Penggunaan metode pengujian white box dilakukan untuk :
a) Memberikan jaminan bahwa semua jalur independen suatu modul

digunakan minimal satu kali
b) Menggunakan semua keputusan logis untuk semua kondisi true atau
false
50
c) Mengeksekusi semua perulangan pada batasan nilai dan operasional
pada setiap kondisi.
d) Menggunakan struktur data internal untuk menjamin validitas jalur
keputusan.
d. Alat dan Bahan

Peralatan
Bahan
dan produk
e. Prosedur Kerja
1) Mendefinisikan semua alur logika yang ada di aplikasi web pada fitur
register dan login website
2) Menstrukturkan scenario pengujian pada pada fitur register dan login
website dengan menggunakan salah satu Teknik White Box testing pada
aplikasi web
3) Mengevaluasi semua hasil pengujian dengan menggunakan metrics
pengujian
4) Melakukan pengujian secara menyeluruh
5) Membuat Dokumentasi hasil pengujian

Dokumentasi hasil pengujian pada fitur register dan login website
g. Kesimpulan
Mahasiswa mampu melaksanakan pengujian statis pada fitur pada fitur register
dan login website
h. Rubrik Penilaian
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
51
Acara 16
Secara Manual (Web)

1. Mahasiswa mampu Menyiapkan data uji yang sesuai dengan kebutuhan
2. Mahasiswa mampu Menguasai penggunaan minimal satu standar proses
3. Mahasiswa mampu Membaca dan memahami dokumen spefikasi disain
perangkat lunak
b. Indikator
aplikasi web, spesifikasi perancangan perangkat lunak (pada aplikasi web), dan spesifikasi
produk aplikasi web yang diuji dan ketepatan pemilihan dan penggunaan data uji.
c. Dasar Teori
1. Black-box Testing
Pada Black Box Testing dilakukan pengujian yang didasarkan pada detail aplikasi
seperti tampilan aplikasi, fungsi-fungsi yang ada pada aplikasi, dan kesesuaian alur fungsi
dengan bisnis proses yang diinginkan oleh customer. Black-box Testing ini lebih menguji
ke Tampilan Luar(Interface) dari suatu aplikasi agar mudah digunakan oleh Customer.
Pengujian ini tidak melihat dan menguji souce code program. Black-box Testing bekerja
dengan mengabaikan struktur control sehingga perhatianya hanya terfokus pada informasi
domain.
Keuntungan dari Black-box Testing :
• Penguji tidak perku memiliki pengetahuan tentang baasa pemograman
tertentu
• Pengujian yang dilakukan berdasarkan sudut pandang user agar dapat
mengungkapkan inkosistensi atau ambiguitas dalam spesifikasi.
• Programmer dan tester memiliki ketergantungan satu sama lain
Kekurangan Black-box Testing :
• Uji kasus sulit disain tanpa spesifikasi yang jelas
52
• Kemungkinan memiliki pengulangan tes yang sudah dilakukan oleh
programmer
• Beberapa bagian back end tidak diuji sama sekali.
2. Teknik Black-box Testing

a) Equivalence Partitioning: Cara kerja teknik ini adalah dengan melakukan
partition atau pembagian menjadi beberapa partisi dari input data.
b) Boundary Value Analysis: Teknik ini lebih fokus kepada boundary,
dimana adakah error dari luar atau sisi dalam software, minimum,
maupun maximum nilai dari error yang didapat.
c) Fuzzing: Fuzz merupakan teknik untuk mencari bug / gangguan dari
software dengan menggunakan injeksi data yang terbilang cacat
ataupun sesi semi-otomatis.
d) Cause-Effect Graph: Ini adalah teknik testing dimana menggunakan
graphic sebagai pacuannya. Dimana dalam grafik ini menggambarkan
relasi diantara efek dan penyebab dari error tersebut.
e) Orthogonal Array Testing: Dapat digunakan jika input domain yang
relatif terbilang kecil ukurannya, tetapi cukup berat untuk digunakan
dalam skala besar.
f) All Pair Testing: Dalam teknik ini, semua pasangan dari test case di
desain sedemikian rupa agar dapat di eksekusi semua kemungkinan
kombinasi diskrit dari seluruh pasangan berdasar input parameternya.
Tujuannya testing ini adalah memiliki pasangan test case yang
mencakup semua pasangan tersebut.
g) State Transition: Testing ini berguna untuk melakukan pengetesan
terhadap kondisi dari mesin dan navigasi dari UI dalam bentuk grafik.
d. Alat dan Bahan
Alat:
Bahan:
dan produk
e. Prosedur Kerja
1) Mendefinisikan semua alur logika yang ada di aplikasi web pada fitur register
dan login website
53
website dengan menggunakan salah satu Teknik Black Box testing pada
aplikasi web
pengujian

Dokumentasi hasil pengujian pada fitur register dan login website
Skenario Kasus Hasil yang Hasil Kesimpulan
Pengujian Pengujian diharapkan Pengujian
g. Kesimpulan
dan login website
h. Rubrik Penilaian
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
54
Acara 17
Secara Manual (Mobile)

perangkat lunak
b. Indikator
aplikasi mobile, spesifikasi perancangan perangkat lunak (pada aplikasi mobile),
dan spesifikasi produk aplikasi mobile yang diuji dan ketepatan pemilihan dan
penggunaan data uji.
c. Dasar Teori
1. White-box Testing
White Box Testing adalah salah satu cara untuk menguji suatu aplikasi atau software
dengan melihat modul untuk memeriksa dan menganalisis kode program ada yang salah
atau tidak. Jika modul ini dan telah diproduksi dalam output yang tidak memenuhi
persyaratan, kode akan dikompilasi ulang dan diperiksa lagi sampai mencapai apa yang
diharapkan singkatnya White Box Testing ini menguji dengan cara melihat Pure Code dari
suatu aplikai/software yang diuji tanpa memperdulikan Tampilan atau UI dari aplikasi
tersebut.
2. Teknik White-box Testing, sebagai berikut :
• Basis Path Testing.
Basis path testing merupakan metode yang memungkinkan perancang
testcase untuk membuat pengukuran kompleksitas logikal dari rancangan
prosedural dan menggunakan pengukuran ini sebagai panduan untuk
mendefinisikan himpunan basis dari jalur eksekusi. Test case yang dibuat
untuk menguji himpunan basis dijamin akan mengeksekusi setiap statement
di dalam program sekurangnya sekali pada saat pengujian
55
• Flow Graph
Flow graph merupakan notasi sederhana untuk merepresentasi control flow.
• Cyclomatic Complexity
Cyclomatic complexity digunakan untuk mengetahui jumlah jalur yang perlu
dicari. Cyclomatic complexity adalah metric software yang menyediakan
ukuran kuantitatif dari kompleksitas logikal program. Nilai yang dihitung bagi
cyclomatic complexity menentukan jumlah jalur-jalur yang independen dalam
kumpulan basis suatu program dan memberikan jumlah tes minimal yang
harus dilakukan untuk memastikan bahwa semua pernyataan telah dieksekusi
sekurangnya satu kali.
Cyclomatic complexity mempunyai fondasi dalam teori graph dan dapat
dihitung dengan satu dari tiga cara :
• Jumlah region sama dengan cyclomatic complexity.
• Cyclomatic complexity, V(G), untuk sebuah flow graph, G, didefnisikan
sebagai: V(G) = E – N + 2 E adalah jumlah edge pada flow graph, dan N
adalah jumlah node pada flow graph.
• Cyclomatic complexity, V(G), untuk flow graph, G, juga didefinisikan
sebagai: V(G) = P + 1 P adalah jumlah predicate nodes yang terdapat pada
flow graph G.
• Graph Matrix
Prosedur untuk membuat flow graph dan menentukan himpunan basis path
dapat diterima berdasarkan mekanisme. Untuk mengembangkan software yang
membantu pengujian basis path, sebuah struktur data yang disebut graph matrix,
dapat sangat bermanfaat. Graph matrix adalah matriks kotak yang ukurannya
(jumlah baris dan kolom) sama untuk jumlah node pada flow graph. Setiap baris
dan kolom berhubungan dengan node yang teridentifikasi, dan data matriks
berhubungan dengan koneksi (edge) antara
• Kelemahan White Box-Testing:
a) Sangat mahal untuk dilakukan karena membutuhkan tester yang terampil
untuk melakukan pengujian.
b) Pada perangkat lunak yang jenisnya besar, metode white box testing ini
dianggap boros karena melibatkan banyak sumberdaya untuk
melakukannya.
c) Tidak mempedulikan Tampilan UI aplikasinya.
• Penggunaan metode pengujian white box dilakukan untuk :
a) Memberikan jaminan bahwa semua jalur independen suatu modul

digunakan minimal satu kali
56
b) Menggunakan semua keputusan logis untuk semua kondisi true atau false
c) Mengeksekusi semua perulangan pada batasan nilai dan operasional pada
setiap kondisi.
d) Menggunakan struktur data internal untuk menjamin validitas jalur
keputusan.
d. Alat dan Bahan
Alat:
Bahan:
dan produk
e. Prosedur Kerja
1) Mendefinisikan semua alur logika yang ada di aplikasi mobile pada fitur
register dan login mobile
dengan menggunakan salah satu Teknik White Box testing pada aplikasi
mobile
pengujian
Dokumentasi hasil pengujian pada fitur register dan login mobile
g. Kesimpulan
dan login mobile
h. Rubrik Penilaian
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
57
Acara 18
Secara Manual (Mobile)
Acara Praktikum/Praktik : Minggu 9/4

perangkatm lunak, spesifikasi produk perangkat lunak, dan skenario uji perangkat
lunak
b. Indikator
Ketepatan mengidentifikasi spesifikasi kebutuhan perangkat lunak yaitu pada aplikasi
mobile, spesifikasi perancangan perangkat lunak (pada aplikasi mobile), dan spesifikasi
produk aplikasi mobile yang diuji dan ketepatan pemilihan dan penggunaan data uji.
c. Dasar Teori
1. Black-box Testing
Pada Black Box Testing dilakukan pengujian yang didasarkan pada detail aplikasi
seperti tampilan aplikasi, fungsi-fungsi yang ada pada aplikasi, dan kesesuaian alur fungsi
dengan bisnis proses yang diinginkan oleh customer. Black-box Testing ini lebih menguji
ke Tampilan Luar(Interface) dari suatu aplikasi agar mudah digunakan oleh Customer.
Pengujian ini tidak melihat dan menguji souce code program. Black-box Testing bekerja
dengan mengabaikan struktur control sehingga perhatianya hanya terfokus pada informasi
domain.
Keuntungan dari Black-box Testing :
• Penguji tidak perku memiliki pengetahuan tentang baasa pemograman tertentu
• Pengujian yang dilakukan berdasarkan sudut pandang user agar dapat
mengungkapkan inkosistensi atau ambiguitas dalam spesifikasi.
• Programmer dan tester memiliki ketergantungan satu sama lain
Kekurangan Black-box Testing :
• Uji kasus sulit disain tanpa spesifikasi yang jelas
• Kemungkinan memiliki pengulangan tes yang sudah dilakukan oleh programmer
• Beberapa bagian back end tidak diuji sama sekali.
2. Teknik Black-box Testing
58
1) Equivalence Partitioning: Cara kerja teknik ini adalah dengan melakukan
partition atau pembagian menjadi beberapa partisi dari input data.
2) Boundary Value Analysis: Teknik ini lebih fokus kepada boundary, dimana
adakah error dari luar atau sisi dalam software, minimum, maupun maximum
nilai dari error yang didapat.
3) Fuzzing: merupakan teknik untuk mencari bug / gangguan dari software
dengan menggunakan injeksi data yang terbilang cacat ataupun sesi semi-
otomatis.
4) Cause-Effect Graph: Ini adalah teknik testing dimana menggunakan graphic
sebagai pacuannya. Dimana dalam grafik ini menggambarkan relasi diantara
efek dan penyebab dari error tersebut.
5) Orthogonal Array Testing: dapat digunakan jika input domain yang relatif
terbilang kecil ukurannya, tetapi cukup berat untuk digunakan dalam skala
besar.
6) All Pair Testing: dalam teknik ini, semua pasangan dari test case di desain
sedemikian rupa agar dapat di eksekusi semua kemungkinan kombinasi diskrit
dari seluruh pasangan berdasar input parameternya. Tujuannya testing ini
adalah memiliki pasangan test case yang mencakup semua pasangan tersebut.
7) State Transition: Testing ini berguna untuk melakukan pengetesan terhadap
kondisi dari mesin dan navigasi dari UI dalam bentuk grafik.
d. Alat dan Bahan
Alat:
Bahan:
dan produk
e. Prosedur Kerja
1) Mendefinisikan semua alur logika yang ada di aplikasi web pada fitur register
dan login website
aplikasi mobile dengan menggunakan salah satu Teknik Black Box testing
pada aplikasi mobile
pengujian
59
Dokumentasi hasil pengujian pada fitur register dan login mobile
Skenario Kasus Hasil yang Hasil Kesimpulan
Pengujian Pengujian diharapkan Pengujian
g. Kesimpulan
Mahasiswa mampu melaksanakan pengujian statis pada fitur pada fitur register dan login
mobile
h. Rubrik Penilaian
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
60
Acara 19
Secara Otomatis (Mobile)

1. Mahasiswa mampu melakukan pengujian perangkat lunak secara otomatis
2. Mahasiswa mampu menyusun dokumen hasil pengujian perangkat lunak
b. Indikator
Keberhasilan dalam menggunakan tools dalam pelaksanaan pengujian perangkat
lunak, ketepatan dalam menyusun dokumen hasil pengujian perangkat lunak.
c. Dasar Teori
1. Pengujian Perangkat Lunak Otomatis
Pengujian otomatis adalah aplikasi perangkat lunak untuk mengotomatisasi proses
manual yang digerakkan oleh manusia untuk meninjau dan memvalidasi produk perangkat
lunak. Sebagian besar proyek perangkat lunak agile dan DevOps modern sekarang
menyertakan pengujian otomatis sejak awal. Namun, untuk sepenuhnya menghargai nilai
pengujian otomatis, ada baiknya untuk memahami seperti apa kehidupan sebelum
diadopsi secara luas.
Kembali ketika pengujian manual adalah norma, itu adalah praktik umum bagi
perusahaan perangkat lunak untuk mempekerjakan tim QA penuh waktu. Tim ini akan
mengembangkan kumpulan 'rencana pengujian,' atau daftar periksa langkah demi
langkah yang menegaskan fitur proyek perangkat lunak berperilaku seperti yang
diharapkan. Tim QA kemudian akan secara manual menjalankan daftar periksa ini setiap
kali pembaruan atau perubahan baru didorong ke proyek perangkat lunak, kemudian
mengembalikan hasil rencana pengujian ke tim teknik untuk ditinjau dan pengembangan
lebih lanjut untuk mengatasi masalah.
Proses ini lambat, mahal, dan rawan kesalahan. Pengujian otomatis membawa
keuntungan besar untuk efisiensi tim dan ROI tim jaminan kualitas. Pengujian otomatis
menempatkan tanggung jawab kepemilikan di tangan tim teknik. Rencana pengujian
dikembangkan bersamaan dengan pengembangan fitur peta jalan reguler kemudian
dijalankan secara otomatis oleh alat integrasi berkelanjutan perangkat lunak. Pengujian
otomatis mempromosikan ukuran tim QA yang ramping dan memungkinkan tim QA untuk
fokus pada fitur yang lebih sensitif.
Continuous delivery (CD) adalah tentang mengirimkan rilis kode baru secepat mungkin
kepada pelanggan. Pengujian otomatis sangat penting untuk tujuan itu. Tidak ada cara
61
untuk mengotomatiskan pengiriman ke pengguna jika ada langkah manual yang memakan
waktu dalam proses pengiriman. CD adalah bagian dari jalur penyebaran yang lebih besar.
CD adalah penerus dan juga bergantung pada continuous integration (CI). CI bertanggung
jawab penuh untuk menjalankan pengujian otomatis terhadap setiap perubahan kode baru
dan memverifikasi bahwa perubahan tersebut tidak merusak fitur yang sudah ada atau
memperkenalkan bug baru. CD dipicu setelah langkah integrasi berkelanjutan melewati
rencana pengujian otomatis.
Hubungan antara pengujian otomatis, CI, dan CD ini menghasilkan banyak manfaat
bagi tim perangkat lunak berkecepatan tinggi. Pengujian otomatis memastikan kualitas di
setiap tahap pengembangan dengan memastikan komitmen baru tidak menimbulkan bug
apa pun, sehingga perangkat lunak tetap siap digunakan setiap saat.
Pengujian otomatis dapat meningkatkan efisiensi tim QA. Beberapa manfaat antara
lain:
• Akurasi yang lebih tinggi
• Kemampuan pelaporan yang lebih baik
• Peningkatan cakupan
• Peningkatan efisiensi sumber daya
• Deteksi bug yang ditingkatkan
• Peningkatan penggunaan kembali
2. Unit Testing
Unit testing adalah suatu pekerjaan yang harus dilakukan ketika mengembangkan
suatu produk, terutama produk software. Karena pekerjaan ini sangat penting untuk
memastikan kualitas setiap komponen yang ada di dalamnya. Umumnya, unit testing
dikerjakan oleh seorang software tester atau software developer. Nah, pada kesempatan
kali ini kita akan membahas secara lengkap tentang unit testing dan berbagai tools yang
biasa digunakan. unit testing adalah suatu jenis software testing yang dilakukan untuk
menguji coba suatu bagian ataupun komponen yang ada pada software. Unit tersebut bisa
berbentuk fungsi, kode, metode, prosedur, modul ataupun objek itu sendiri.
Unit testing dilakukan agar bisa memastikan setiap unit kode yang terdapat pada
software bisa berjalan sebagaimana mestinya. Laman resmi SmartBear menjelaskan
“smaller is better”, maksudnya, semakin kecil unit yang diuji, maka Anda akan melihat
dan juga memastikan kinerja software tersebut semakin detail.
3. Tools Unit Testing
Seperti yang sudah dijelaskan sebelumnya, unit testing adalah suatu pengujian
software yang dilakukan secara manual ataupun otomatis dengan menggunakan alat
bantu atau tools khusus. Tapi, kebanyakan developer saat ini lebih memilih metode
otomatis. Berikut ini adalah beberapa tools yang bisa Anda pilih untuk melakukan unit
testing.
62
• JUnit: tools unit testing untuk aplikasi yang menggunakan bahasa
pemrograman Java
• NUnit: framework unit testing untuk aplikasi yang menggunakan bahasa
pemrograman .NET
• JMockit: tools unit testing untuk aplikasi yang berbasis open source
• EMMA: tools untuk menganalisis dan melaporkan kode yang menggunakan
bahasa pemrograman Java
• PHPUnit: tools unit testing untuk PHP programmer
d. Alat dan Bahan
Alat:
- Laptop
Bahan:
- Android studio
e. Prosedur Kerja
• Membuat pengujian lokal
Logika aplikasi dapat dievaluasi menggunakan pengujian unit lokal saat Anda perlu
menjalankan pengujian lebih cepat dan tidak memerlukan fidelitas serta keyakinan yang
terkait dengan menjalankan pengujian di perangkat sebenarnya. Dengan pendekatan ini,
Anda biasanya dapat memenuhi hubungan dependensi menggunakan Robolectric atau
framework tiruan, seperti Mockito. Biasanya, jenis dependensi yang terkait dengan
pengujian menentukan alat mana yang Anda gunakan:
Jika memiliki dependensi pada framework Android, khususnya yang membuat
interaksi kompleks dengan framework, sebaiknya Anda menyertakan dependensi
framework menggunakan Robolectric.
Jika pengujian memiliki dependensi minimal pada framework Android, atau jika
pengujian hanya bergantung pada objek Anda sendiri, Anda dapat menyertakan
dependensi tiruan menggunakan framework tiruan seperti Mockito.
• Menyiapkan lingkungan pengujian
1) Dalam project Android Studio, Anda harus menyimpan file sumber untuk pengujian
unit lokal di module-name/src/test/java/. Direktori ini sudah ada saat Anda membuat
project baru.
2) Anda juga perlu mengonfigurasi dependensi pengujian untuk project Anda agar dapat
menggunakan API standar yang diberikan oleh framework JUnit 4. Jika pengujian Anda
perlu berinteraksi dengan dependensi Android, sertakan Robolectric atau library
Mockito untuk menyederhanakan pengujian unit lokal Anda.
3) Di file build.gradle tingkat teratas aplikasi, tentukan library berikut sebagai
dependensi:
63
• Membuat class pengujian unit lokal
Class pengujian unit lokal Anda harus ditulis sebagai class pengujian JUnit 4. JUnit
adalah framework pengujian unit yang paling populer dan banyak digunakan untuk Java.
JUnit 4 memungkinkan Anda untuk menulis pengujian dengan cara yang lebih rapi dan
fleksibel daripada versi pendahulunya karena JUnit 4 tidak mengharuskan Anda untuk
melakukan hal-hal berikut:
1) Perluas class junit.framework.TestCase.
2) Berikan awalan pada nama metode pengujian Anda dengan kata kunci 'test'.
3) Gunakan class dari paket junit.framework atau junit.extensions.
4) Untuk membuat class pengujian JUnit 4 dasar, buat class yang berisi satu atau
beberapa metode pengujian. Sebuah metode pengujian dimulai dengan anotasi @Test
dan berisi kode untuk menerapkan serta memverifikasi fungsionalitas tunggal dalam
komponen yang ingin Anda uji.
5) Contoh berikut menunjukkan cara mengimplementasikan class pengujian unit lokal.
Metode pengujian emailValidator_CorrectEmailSimple_ReturnsTrue memverifikasi
bahwa metode isValidEmail() di aplikasi yang diuji menampilkan hasil yang benar.
Kotlin:
64
Java:
Untuk membuat pengujian dapat dibaca yang mengevaluasi apakah komponen-

komponen dalam aplikasi Anda menunjukkan hasil yang diharapkan, sebaiknya
gunakan library Truth dan class dari Android Assertion, seperti yang ditunjukkan di
contoh sebelumnya. Untuk mempelajari lebih lanjut jenis validasi logika yang didukung
oleh Truth dan Android Assertion, lihat bagian yang menjelaskan cara membuat
pernyataan yang lebih mudah dibaca.
Jika Anda lebih senang membandingkan antara hasil yang diharapkan dengan hasil
sebenarnya menggunakan metode junit.Assert atau Hamcrest matchers (seperti
metode is() dan equalTo()), Anda dapat menggunakan library tersebut sebagai
gantinya.
• Menyertakan dependensi framework
Jika pengujian Anda berinteraksi dengan beberapa dependensi framework Android,
atau berinteraksi dengan dependensi tersebut secara kompleks, gunakan artefak
Robolectric yang diberikan oleh Pengujian AndroidX. Robolectric menjalankan kode
framework Android asli dan kode framework native palsu di JVM lokal atau di
perangkat sebenarnya.
Contoh berikut menunjukkan cara membuat pengujian unit yang menggunakan
Robolectric:
app/build.gradle
65
MyLocalUnitTestClass
o Kotlin
o Java
66
• Menyertakan class android builder
Jika membuat pengujian unit lokal yang dijalankan di lingkungan Robolectric atau
di perangkat sebenarnya, Anda dapat menggunakan builder yang disediakan
Pengujian AndroidX untuk beberapa class framework umum. Builder tersebut
memungkinkan Anda untuk membuat instance dari class berikut tanpa perlu
menggunakan tiruan atau refleksi:
- ApplicationInfo
- PackageInfo
- MotionEvent
- MotionEvent.PointerCoords
- MotionEvent.PointerProperties
• Menggunakan class utilitas parcelables
Selain itu, library juga memberikan class utilitas untuk objek Parcelable. Dengan
memberikan objek Creator, class ini melakukan unmarshal kepada objek Parcelable
yang diberikan, lalu melakukan marshal kepada objek Parcelable duplikat.
• Menyertakan dependensi tiruan
Secara default, Plugin Android untuk Gradle menjalankan pengujian unit lokal Anda
terhadap versi modifikasi library android.jar, yang tidak berisi kode aktual. Sebagai
gantinya, metode yang memanggil ke class Android dari pengujian unit Anda akan
memunculkan pengecualian. Perilaku ini memastikan Anda hanya menguji kode Anda
dan tidak bergantung pada perilaku tertentu dari platform Android (yang belum dibuat
atau ditiru secara eksplisit).
• Meniru dependensi android
Jika Anda memiliki dependensi Android minimal serta perlu menguji interaksi
spesifik antara komponen dan dependensinya dalam aplikasi, gunakan framework
tiruan untuk menghentikan dependensi eksternal dalam kode Anda. Dengan begitu,
Anda dapat dengan mudah menguji apakah komponen berinteraksi dengan
dependensi menggunakan cara yang diharapkan. Dengan mengganti dependensi
Android dengan objek tiruan, Anda dapat memisahkan pengujian unit dari sistem
Android lainnya sambil memverifikasi bahwa metode yang benar dalam dependensi
tersebut dipanggil. Framework tiruan Mockito untuk Java (versi 1.9.5 dan yang lebih
tinggi) menawarkan kompatibilitas dengan pengujian unit Android. Dengan Mockito,
Anda dapat mengonfigurasi objek tiruan untuk menampilkan nilai tertentu saat
dipanggil.
Untuk menambahkan objek tiruan ke pengujian unit lokal Anda menggunakan
framework ini, ikuti model pemrograman berikut:
67
1) Sertakan dependensi library Mockito dalam file build.gradle, seperti yang
dijelaskan dalam Menyiapkan lingkungan pengujian Anda.
2) Di awal definisi class pengujian unit, tambahkan anotasi
@RunWith(MockitoJUnitRunner.class). Anotasi ini memberi tahu runner
pengujian Mockito untuk memvalidasi bahwa penggunaan framework sudah
benar dan menyederhanakan inisialisasi objek tiruan Anda.
3) Untuk membuat objek tiruan untuk dependensi Android, tambahkan anotasi
@Mock sebelum deklarasi kolom.
4) Untuk menghentikan perilaku dependensi, Anda dapat menentukan kondisi
dan mengembalikan nilai saat kondisi terpenuhi dengan menggunakan metode
when() dan thenReturn().
Contoh berikut menunjukkan cara membuat pengujian unit yang menggunakan objek
Context tiruan.
o Kotlin
68
o Java
• Menjalankan pengujian unit lokal

1) Untuk menjalankan pengujian unit lokal, gunakan langkah-langkah berikut:
2) Pastikan project Anda disinkronkan dengan Gradle dengan mengklik Sync Project
di toolbar.
3) Jalankan pengujian Anda dengan salah satu cara berikut:
4) Untuk menjalankan pengujian tunggal, buka jendela Project, lalu klik kanan
pengujian dan klik Run .
5) Untuk menguji semua metode di suatu class, klik kanan class atau metode di file
pengujian dan klik Run .
6) Untuk menjalankan semua pengujian di suatu direktori, klik kanan pada direktori
dan pilih Run tests .
Plugin Android untuk Gradle mengompilasi kode pengujian unit lokal yang terletak di
direktori default (src/test/java/), membuat aplikasi pengujian, dan menjalankannya
69
secara lokal menggunakan class runner pengujian default. Android Studio kemudian
menampilkan hasilnya di jendela Run.
f. Tugas Praktikum
1) Lakukan pengujian unit pada fitur login/registrasi aplikasi mobile yang kelompok
Anda kembangkan.
2) Buat dokumen hasil testing yang telah dilakukan.
g. Hasil dan Pembahasan
Dokumen hasil testing
h. Kesimpulan
Mahasiswa mampu melakukan unit testing pada aplikasi mobile yang dikembangkan.
i. Rubrik
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
70
Acara 20
Secara Otomatis (Web)

1. Mahasiswa mampu melakukan pengujian perangkat lunak secara otomatis
2. Mahasiswa mampu menyusun dokumen hasil pengujian perangkat lunak
b. Indikator
Keberhasilan dalam menggunakan tools dalam pelaksanaan pengujian perangkat
lunak, ketepatan dalam menyusun dokumen hasil pengujian perangkat lunak.
c. Dasar Teori
1. Pengujian Perangkat Lunak Otomatis
Pengujian otomatis adalah aplikasi perangkat lunak untuk mengotomatisasi proses
manual yang digerakkan oleh manusia untuk meninjau dan memvalidasi produk perangkat
lunak. Sebagian besar proyek perangkat lunak agile dan DevOps modern sekarang
menyertakan pengujian otomatis sejak awal. Namun, untuk sepenuhnya menghargai nilai
pengujian otomatis, ada baiknya untuk memahami seperti apa kehidupan sebelum
diadopsi secara luas.
Kembali ketika pengujian manual adalah norma, itu adalah praktik umum bagi
perusahaan perangkat lunak untuk mempekerjakan tim QA penuh waktu. Tim ini akan
mengembangkan kumpulan 'rencana pengujian,' atau daftar periksa langkah demi
langkah yang menegaskan fitur proyek perangkat lunak berperilaku seperti yang
diharapkan. Tim QA kemudian akan secara manual menjalankan daftar periksa ini setiap
kali pembaruan atau perubahan baru didorong ke proyek perangkat lunak, kemudian
mengembalikan hasil rencana pengujian ke tim teknik untuk ditinjau dan pengembangan
lebih lanjut untuk mengatasi masalah.
Proses ini lambat, mahal, dan rawan kesalahan. Pengujian otomatis membawa
keuntungan besar untuk efisiensi tim dan ROI tim jaminan kualitas. Pengujian otomatis
menempatkan tanggung jawab kepemilikan di tangan tim teknik. Rencana pengujian
dikembangkan bersamaan dengan pengembangan fitur peta jalan reguler kemudian
dijalankan secara otomatis oleh alat integrasi berkelanjutan perangkat lunak. Pengujian
otomatis mempromosikan ukuran tim QA yang ramping dan memungkinkan tim QA untuk
fokus pada fitur yang lebih sensitif.
Continuous delivery (CD) adalah tentang mengirimkan rilis kode baru secepat mungkin
kepada pelanggan. Pengujian otomatis sangat penting untuk tujuan itu. Tidak ada cara
71
untuk mengotomatiskan pengiriman ke pengguna jika ada langkah manual yang memakan
waktu dalam proses pengiriman. CD adalah bagian dari jalur penyebaran yang lebih besar.
CD adalah penerus dan juga bergantung pada continuous integration (CI). CI bertanggung
jawab penuh untuk menjalankan pengujian otomatis terhadap setiap perubahan kode baru
dan memverifikasi bahwa perubahan tersebut tidak merusak fitur yang sudah ada atau
memperkenalkan bug baru. CD dipicu setelah langkah integrasi berkelanjutan melewati
rencana pengujian otomatis.
Hubungan antara pengujian otomatis, CI, dan CD ini menghasilkan banyak manfaat
bagi tim perangkat lunak berkecepatan tinggi. Pengujian otomatis memastikan kualitas di
setiap tahap pengembangan dengan memastikan komitmen baru tidak menimbulkan bug
apa pun, sehingga perangkat lunak tetap siap digunakan setiap saat.
Pengujian otomatis dapat meningkatkan efisiensi tim QA. Beberapa manfaat antara
lain:
• Akurasi yang lebih tinggi
• Kemampuan pelaporan yang lebih baik
• Peningkatan cakupan
• Peningkatan efisiensi sumber daya
• Deteksi bug yang ditingkatkan
• Peningkatan penggunaan kembali
2. Unit Testing
Unit testing adalah suatu pekerjaan yang harus dilakukan ketika mengembangkan
suatu produk, terutama produk software. Karena pekerjaan ini sangat penting untuk
memastikan kualitas setiap komponen yang ada di dalamnya. Umumnya, unit testing
dikerjakan oleh seorang software tester atau software developer. Nah, pada kesempatan
kali ini kita akan membahas secara lengkap tentang unit testing dan berbagai tools yang
biasa digunakan. unit testing adalah suatu jenis software testing yang dilakukan untuk
menguji coba suatu bagian ataupun komponen yang ada pada software. Unit tersebut bisa
berbentuk fungsi, kode, metode, prosedur, modul ataupun objek itu sendiri.
Unit testing dilakukan agar bisa memastikan setiap unit kode yang terdapat pada
software bisa berjalan sebagaimana mestinya. Laman resmi SmartBear menjelaskan
“smaller is better”, maksudnya, semakin kecil unit yang diuji, maka Anda akan melihat
dan juga memastikan kinerja software tersebut semakin detail.
3. Tools Unit Testing
Seperti yang sudah dijelaskan sebelumnya, unit testing adalah suatu pengujian
software yang dilakukan secara manual ataupun otomatis dengan menggunakan alat
bantu atau tools khusus. Tapi, kebanyakan developer saat ini lebih memilih metode
otomatis. Berikut ini adalah beberapa tools yang bisa Anda pilih untuk melakukan unit
testing.
72
• JUnit: tools unit testing untuk aplikasi yang menggunakan bahasa
pemrograman Java
• NUnit: framework unit testing untuk aplikasi yang menggunakan bahasa
pemrograman .NET
• JMockit: tools unit testing untuk aplikasi yang berbasis open source
• EMMA: tools untuk menganalisis dan melaporkan kode yang menggunakan
bahasa pemrograman Java
• PHPUnit: tools unit testing untuk PHP programmer
d. Alat dan Bahan
Alat:
- Laptop
Bahan:
- PHP Unit
e. Prosedur Kerja
1) Lakukan instalasi aplikasi PHP unit. Dapat di download pada link
https://phpunit.de/, pada tutorial ini menggunakan versi 8.
2) Pertama-tama kita membutuhkan framework PHPUnit. Halaman website PHPUnit
dapat ditemukan pada alamat https://phpunit.de/. Saat ini PHPUnit sudah
mencapat versi 9. Nah, untuk latihan kali ini kita akan gunakan versi 8 yang
terdaftar secara default pada repository Composer. Silahkan buka folder latihan-
php-unit, lalu jalankan perintah ini pada CLI :
Tampilannya akan seperti di bawah ini:
73
3) Jika Anda buka folder latihan-php-unit sekarang akan terisi file composer.json,
composer.lock beserta folder vendor. Sampai sini kita sudah berhasil meinstall PHP
Unit.
4) Membuat class contoh. Dalam kasus sekarang kita ceritanya mempunyai sebuah
library yang ingin kita test. Library ini kita beri nama Wordcount.php. Yang berisi
sebuah method untuk menghitung jumlah kata dalam kalimat. Silahkan buat
sebuah file bernama Wordcount.php berisi kode berikut :
5) Membuat test. Untuk membuat test kita membutuhkan komponen class dari
PHPUnit. Komponen tersebut sudah terinstall dalam folder vendor saat
menjalankan Composer. Sekarang buatlah file bernama SimpleTest.php pada
folder latihan-php-unit berisi kode berikut ini :
Pada kode tersebut kita use komponen PHPUnit yang sudah ada dalam folder
vendor. Lalu kita juga require class yang sudah kita bikin sebelumnya yaitu
74
Wordcount.php. Dalam kode kita juga membuat class bernama SimpleTest yang meng-
extend TestCase milik PHPUnit. Dalam penggunaannya, kita minimal harus membuat
sebuah method dalam TestCase, disini kita berinama testCountWords.
Sebenernya penamaannya bebas terserah teman-teman, nama pada contoh diatas
adalah nama yang paling relevan dengan kasus kita. Pada method testCountWords kita
membuat instance dari class yang ingin kita test, lalu menjalankan assertEquals.
6) Jalankan Test. Silahkan buka folder proyek latihan-php-unit lalu jalankan perintah
ini :
Disini kita memanggil binary program phpunit dan memerintah untuk mengetest file
SimpleTest.php yang sudah kita buat sebelumnya. Silahkan klik enter/run maka hasilnya
akan seperti ini :
Perintah assertEqual akan membandingkan parameter pertama (output yang diinginkan)

dan paramater kedua (method yang di run), jika match, berarti test berhasil. Kita hanya
membandingkan hasil yang diinginkan dengan hasil real output class yang ingin di test.
Jika sesuai ekspektasi maka si class tersebut berjalan dengan baik. Jika ternyata saat di
test hasil tidak sama, berarti class kita ada bug / error. String "My name is Joko" harus
selalu mengeluarkan hasil 4.
f. Tugas praktikum
1) Lakukan pengujian unit pada fitur login/registrasi aplikasi web yang kelompok
Anda kembangkan.
2) Buat dokumen hasil testing yang telah dilakukan.
75
g. Hasil dan Pembahasan
Dokumen hasil testing
h. Kesimpulan
Mahasiswa mampu melakukan unit testing pada aplikasi web yang dikembangkan.
i. Rubrik
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
76
Acara 21
Pokok Bahasan : Melakukan Pengujian Keamanan Perangkat Lunak

1. Mahasiswa mampu menentukan aspek keamanan perangkat lunak yang akan diuji
2. Mahasiswa mampu melaksanakan pengujian keamanan perangkat lunak
3. Mahasiswa mampu menilai kebijakan mengenai keamanan yang digunakan
b. Indikator
Keberhasilan dalam menggunakan tools dalam pelaksanaan pengujian keamanan
perangkat lunak, ketepatan dalam menyusun dokumen hasil pengujian perangkat
lunak.
c. Dasar Teori
1. Pengujian Keamanan Perangkat Lunak
Security testing adalah jenis pengujian perangkat lunak yang dilakukan untuk
mengidentifikasi kerentanan serta memastikan bahwa data dan sumber daya sistem di
dalamnya sudah terlindungi dengan baik dari para penyusup. Pengujian ini dilakukan
dengan tujuan untuk menemukan semua celah dan kelemahan sistem yang dapat
mengakibatkan hilangnya informasi atau reputasi perusahaan.
Pada umumnya, security testing akan dilakukan setiap kali Anda melakukan perubahan
pada sistem yang Anda kembangkan. Meskipun demikian, perusahan-perusahaan perlu
menyadari bahwa security testing perlu dilakukan secara berkala karena peretas akan
selalu mencari cara untuk menyusup ke dalam sistem. Dengan rutin melakukan security
testing, Anda dapat menjamin bahwa sistem yang digunakan selalu memiliki tingkat
keamanan yang baik.
Dalam security testing khususnya yang dilakukan pada situs website dan aplikasi, akan
ada empat area utama yang akan diperhatikan. Keempat area tersebut adalah:
• Network security: Pengujian ini dilakukan untuk mencari kerentanan dalam
infrastruktur jaringan.
• System software security: Pengujian untuk menilai bagaimana tingkat
kelemahan berbagai perangkat lunak tempat aplikasi bekerja seperti operating
system, database system, dan lain-lain.
• Client-side application security: pengujian ini dapat memastikan bahwa sisi
klien seperti browser tidak dapat dimanipulasi.
• Server-side application security: pengujian untuk memastikan bahwa sisi
server memiliki keamanan yang kuat dan dapat memblokir beragam gangguan.
77
2. Jenis-jenis pengujian keamanan perangkat lunak
a) Vulnerability scanning
Vulnerability Scanning (vuln scan) adalah pengujian keamanan yang
dilakukan melalui software otomatis untuk memindah aplikasi web. Software ini
akan mencari kerentanan keamanan yang ada di dalam sistem seperti pembuatan
Cross site scripting, SQL Injection, Command Injection, Path Traversal, serta
konfigurasi server yang tidak aman. Tool ini sering disebut sebagai bagian dari
Dynamic Application Security Testing (DAST).
Secara garis besar, Vulnerability Scanning memiliki beberapa jenis
pemindaian, yaitu:
• External vulnerability scans:
External vulnerability scans merupakan penilaian kerentanan yang
dilakukan dengan menargetkan ekosistem IT yang tidak dibatasi untuk
penggunaan internal. Pemindaian ini akan fokus pada beberapa area seperti
applications, ports, websites, services, networks, dan sistem yang dapat
diakses dari luar oleh customer atau user.
• Internal vulnerability scans:
Internal vulnerability scans adalah pemindaian yang memiliki target
utama jaringan internal perusahaan. Pemindaian ini akan mengidentifikasi
kerentanan di dalam jaringan untuk menghindari kerusakan. Pemindaian
internal juga memungkinkan perusahaan atau organisasi untuk bisa
melindungi dan memperkuat sistem keamanan aplikasi dari dalam.
b) Security scanning
Security scanning merupakan pemindaian yang digunakan untuk menemukan
kerentanan atau modifikasi file yang tidak diinginkan dalam aplikasi berbasis web,
situs web, jaringan, atau sistem file. Pemindaian ini dapat dilakukan secara
otomatis ataupun manual. Pemindaian ini akan memberikan Anda insight yang
mendalam serta menyediakan rekomendasi solusi untuk memperbaiki masalah
yang ditemukan.
Security scanning dapat dilakukan sebagai one-time check atau pemeriksaan
satu kali. Meskipun demikian, sebagian besar perusahaan pengembang perangkat
lunak lebih memilih untuk melakukan pemindaian keamanan secara teratur untuk
memastikan sistem yang dikembangkan benar-benar aman.
c) Penetration testing
Penetration testing adalah proses pengujian dengan melakukan simulasi
serangan cyber terhadap sistem yang akan diuji. Pengujian ini akan dilakukan
secara manual oleh pentester profesional dan bersertifikat menggunakan beragam
pentest tools dan teknik. Ketika pengujian penetration testing dilakukan, Anda
78
akan menemukan beragam kerentanan yang dapat dieksploitasi oleh para penjahat
cyber. Dengan demikian, maka proses penambalan atau perbaikan dapat segera
dilakukan sebelum pihak peretas menemukannya.
d) Risk assessment
Melalui risk assessment, risiko keamanan yang dihadapi oleh aplikasi, software,
dan jaringan akan diidentifikasi dan dianalisis. Risiko keamanan tersebut kemudian
akan diklasifikasikan ke dalam beberapa kategori yaitu tinggi, sedang, dan rendah.
Salah satu jenis security testing ini dapat membantu Anda memastikan bahwa
kontrol keamanan cyber yang Anda lakukan sebelumnya sudah sesuai dengan
risiko keamanan yang dihadapi organisasi/perusahaan Anda.
e) Security auditing
Security Auditing adalah metode terstruktur untuk mengevaluasi langkah-
langkah keamanan di dalam perusahaan. Dengan melakukan audit secara rutin,
Anda akan terbantu dalam mengidentifikasi titik lemah dan kerentanan dalam
infrastruktur IT perusahaan, memverifikasi kontrol keamanan, memastikan
kepatuhan terhadap peraturan keamanan, dan masih banyak lagi.
f) Ethical hacking
Ethical hacking merupakan pengujian keamanan yang dilakukan menggunakan
semua teknik peretasan dan teknik serangan komputer terkait lainnya. Proses
pengujian ini dilakukan oleh ethical hacker yang sudah memperoleh izin untuk
menjelajahi infrastruktur IT perusahaan secara lebih luas.
g) Posture assessment
Posture Assessment mengacu pada metodologi yang dilakukan untuk
meningkatkan kemampuan manajemen risiko di perusahaan. Sebagian besar
orang menganggap bahwa posture Assessment merupakan gabungan dari
beberapa jenis security testing yaitu Ethical Hacking, Security Scanning, dan Risk
Assessment.
Penilaian ini dapat menjadi langkah berharga untuk mengetahui bagaimana
kondisi keamanan perusahaan. Dengan melakukan Posture Assessment, sebuah
Anda akan memiliki pandangan yang jelas tentang status keamanan perusahaan
serta mampu mengidentifikasikan ancaman keamanan yang mungkin terjadi.
3. Metode atau Pendekatan Pengujian Keamanan Perangkat Lunak
a) Tiger box
Metodologi pengujian ini pada umumnya dilakukan melalui laptop atau OS yang
memiliki seperangkat alat untuk hacking. Dengan metodologi ini, penguji dapat
mengevaluasi kerentanan serangan cyber.
79
b) Black box
Black box testing adalah metode pengujian perangkat lunak dimana struktur
atau desain internal dari item yang perlu diuji tidak diketahui oleh penguji.
Pengujian black box juga sering disebut sebagai functional testing atau closed-box
testing.
c) Grey box
Grey Box testing dilakukan pada suatu perangkat lunak dengan informasi
fungsionalitas internal yang terbatas. Biasanya, pihak penguji akan memiliki
beberapa pengetahuan dasar tentang kode dan algoritma perangkat lunak.
Meskipun demikian informasi tersebut tetap terbatas sehingga pengujian akan
tetap dilakukan secara normal dari sudut pandang penguji.
4. Tools pengujian keamanan perangkat lunak
a) Intruder
b) Owasp
c) Acunetix
d) Wireshark
e) W3af
d. Alat dan Bahan
Alat:
- Laptop
Bahan:
- Security testing process
- Test plan
- Test scenario
e. Prosedur Kerja
1) Diskusikan dengan kelompok Anda untuk membuat dokumen test plan untuk
security testing mulai dari requirements hingga fase support.
2) Sesuaikan prosesnya dengan pengembangan aplikasi web atau mobile yang
kelompok Anda kembangkan (dapat memilih salah satu web atau mobile).
3) Buatlah test scenario untuk pengujian keamanan perangkat lunak pada fitur
login/registrasi pada aplikasi Anda.
4) Lakukan pengujian keamanan aplikasi Anda dengan pendekatan Black Box dan
dokumentasikan hasilnya.
Dokumen test plan, test scenario dan hasil testing pengujian keamanan perangkat
lunak yang dikembangkan.
80
g. Kesimpulan
Mahasiswa mampu melakukan security testing pada aplikasi mobile/web yang
dikembangkan.
h. Rubrik
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
81
Acara 22
Pokok Bahasan : Menyusun rekomendasi penjaminan kualitas
perangkat lunak bagi stakeholder

1. Mahasiswa mampu membuat rekomendasi penjaminan yang bersifat preventif
terhadap risiko dibuat
2. Mahasiswa mampu membuat rekomendasi penjaminan yang bersifat korektif untuk
peningkatan kualitas dibuat.
b. Indikator
Ketepatan dalam menyusun dokumen rekomendasi penjaminan yang bersifat
preventif maupun korektif yang ditujukan kepada stakeholder.
c. Dasar teori
1. Tindakan Preventif dan Korektif
Corrective Actions and Preventive Actions (CAPA) adalah kegiatan yang tidak
dimaksudkan untuk menangani koreksi segera dari cacat yang terdeteksi tetapi untuk
menghilangkan penyebab cacat tersebut di seluruh departemen pengembangan perangkat
lunak. Dengan mempromosikan peningkatan efektivitas dan efisiensi yang berkelanjutan,
proses CAPA telah menjadi salah satu alat utama yang digunakan untuk mencapai tujuan
berorientasi kinerja SQA: pemenuhan persyaratan fungsional dan manajerial sekaligus
mengurangi biaya pelaksanaan pengembangan perangkat lunak, pemeliharaan, dan
jaminan kualitas. kegiatan. Pentingnya CAPA dalam setiap sistem SQA ditekankan oleh
standar ISO 9000–3 (lihat ISO, 1997, Bagian 4.14 dan ISO/IEC, 2001).
Tindakan korektif merupakan proses umpan balik yang diterapkan secara teratur yang
mencakup pengumpulan informasi tentang kualitas ketidaksesuaian, identifikasi dan
analisis sumber penyimpangan serta pengembangan dan asimilasi praktik dan prosedur
yang lebih baik, bersama dengan pengendalian penerapannya dan pengukuran hasilnya.
Gambar 1 Proses tindakan korektif
82
Tindakan pencegahan merupakan proses umpan balik yang diterapkan secara teratur
yang mencakup pengumpulan informasi tentang potensi masalah kualitas, identifikasi dan
analisis penyimpangan dari standar kualitas, pengembangan dan asimilasi praktik dan
prosedur yang lebih baik, bersama dengan pengendalian penerapannya dan pengukuran
hasilnya.
Gambar 2 Proses tindakan preventif
Keberhasilan operasi dari proses CAPA meliputi kegiatan sebagai berikut:

1. Pengumpulan informasi
2. Analisis informasi
3. Perancangan solusi dan metoda yang dikembangkan
4. Penerapan metoda yang dikembangkan
5. Follow up
Proses secara teratur dibentuk oleh aliran informasi dari berbagai sumber. Dalam
rangka untuk memperkirakan keberhasilan proses, umpan balik tertutup diterapkan untuk
mengontrol arus informasi, untuk pelaksanaan perubahan hasil secara praktek dan
prosedur bersama-sama dengan pengukuran hasil.
Gambar 3 Proses tindakan korektif dan preventif
2. Perbedaan antara koreksi cacat (defect) dan tindakan korektif dan preventif
83
Koreksi cacat adalah aktivitas terbatas yang diarahkan pada solusi langsung dari cacat
yang terdeteksi dalam proyek atau sistem perangkat lunak. Tindakan korektif dan
pencegahan lebih luas cakupannya, kegiatan ini dimaksudkan untuk memulai dan
memandu kinerja tindakan di seluruh organisasi yang akan menghilangkan penyebab
kesalahan yang diketahui atau potensial.
3. Pengembangan Solusi
Solusi untuk mengidentifikasi penyebab dari kesalahan sistem perangkat lunak yang
berulang diperlukan untuk:
1. Menghilangkan terulangnya jenis kesalahan yang telah terdeteksi
2. Kontribusi peningkatan efisiensi dengan memungkinkan produktivitas yang
lebih tinggi dan jadwal yang lebih singkat.
Beberapa petunjuk sebagai solusi yang biasanya dilakukan:
· Memperbarui prosedur yang terkait. Perubahan bisa mengacu kepada
sekumpulan prosedur,dari segala sesuatu yang terkait dengan tahapan
kerja yang spesifik dari pengembangan perangkat lunak atau
pemeliharaannya (misalnya, perubahan gaya komentar software,
perubahan prosedur review klausul kontrak yang berhubungan dengan
proposal untuk proyek kecil) dengan prosedur yang bersifat umum
(misalnya perubahan prosedur perekrutan karyawan, perubahan jumlah
maksimum dan minimum peserta dalam ulasan desain formal).
· Perubahan disini prakteknya, termasuk memperbarui instruksi kerja yang
relevan (jika memang ada).
· Beralih ke alat pengembangan yang lebih efektif dan tahan terhadap
kesalahan yang sudah terdekteksi
· Pengembangan dalam pelaporan, termasuk perubahan isi laporan,
frekuensi laporan dan penyerahan laporan. Arahan ini bertujuan agar
kesalahan dapat teridentifikasi lebih dini.
· Pelaksanaan training, retraining dan pembaharuan staff. Arah ini diambil
hanya dalam kasus-kasus ketika kekurangan pelatihan yang sama
ditemukan di beberapa tim.
Perlu dicatat bahwa:
· Dalam banyak kasus, solusi yang dianjurkan menggabungkan beberapa
item tindakan dari satu tindakan atau beberapa tindakan.
· Mengubah dan memperbarui prosedur dan instruksi kerja perlu dibahas
dan disetujui oleh badan yang ditugaskan untuk pengembangan dan
pemeliharaan.
84
d. Alat dan bahan
- Laptop
- Standar penyusunan dokumen CAPA (ISO 9000-3)
e. Prosedur kerja
1. Diskusikan dengan kelompok Anda untuk menyusun dokumen rekomendasi yang
bersifat preventif.
2. Sesuaikan penyusunan dengan proses yang telah dijelaskan pada dasar teori.
3. Kembangkan tabel berikut menjadi dokumen yang CAPA yang baik.
No Masalah yang Dampak dari Penyebab Tindakan Target
mungkin muncul masalah yang preventif penyelesaian
muncul
1
2

Dokumen rekomendasi tindakan preventif
g. Kesimpulan
Mahasiswa mampu menyusun dokumen rekomendasi tindakan preventif pada kegiatan
h. Rubrik
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
85
Acara 23
Pokok Bahasan : Menyusun rekomendasi penjaminan kualitas
perangkat lunak bagi stakeholder
Acara Practicum/Praktik : Minggu 11/2

1. Mahasiswa mampu membuat rekomendasi penjaminan yang bersifat preventif
terhadap risiko dibuat
2. Mahasiswa mampu membuat rekomendasi penjaminan yang bersifat korektif untuk
peningkatan kualitas dibuat.
b. Indikator
Ketepatan dalam menyusun dokumen rekomendasi penjaminan yang bersifat
preventif maupun korektif yang ditujukan kepada stakeholder.
c. Dasar teori
1. Rencana Tindakan Korektif
Rencana tindakan korektif adalah serangkaian tindakan untuk menghilangkan
masalah. Rencana tindakan korektif adalah tentang mengatasi akar penyebab masalah,
bukan hanya memperbaiki gejala yang telah ditemukan.
Setiap kali Anda memiliki ketidaksesuaian, Anda akan mengambil langkah-langkah
untuk memperbaiki ketidaksesuaian, tetapi apa yang Anda perbaiki adalah perbedaan
antara koreksi sederhana dan tindakan korektif. Dengan koreksi, Anda akan mengatasi
masalah yang paling jelas sehingga Anda dapat menghapus ketidaksesuaian dan membuat
proses dapat diterima untuk dilanjutkan. Ini adalah koreksi, yang mungkin merupakan
bagian dari tindakan penahanan.
Sebaliknya, jika Anda melihat masalah yang mengakibatkan ketidaksesuaian, dan
menyelidiki penyebab masalah itu sampai Anda memahami penyebabnya – yang
merupakan awal dari rantai yang mengakibatkan ketidaksesuaian (dikenal sebagai akar
penyebab) – dan Anda mengambil tindakan untuk memperbaiki akar penyebab ini
sehingga tidak dapat terjadi lagi, Anda telah mengambil tindakan korektif untuk masalah
tersebut.
2. Menyusun Tindakan korektif
Ketika Anda telah mengidentifikasi akar penyebab masalah, sekarang saatnya untuk
membuat rencana tindakan korektif untuk menghilangkannya. Beberapa hal yang perlu
dipikirkan saat mempersiapkan rencana tindakan korektif Anda meliputi:
86
• Sepenuhnya menilai akar penyebab – Sudahkah kita menilai sepenuhnya akar
penyebab, atau mungkinkah ada penyebab mendasar lebih lanjut dari apa yang
telah diidentifikasi?
• Menilai risiko dan peluang perubahan – Selalu penting untuk memastikan bahwa
perubahan yang telah Anda putuskan tidak akan menyebabkan lebih banyak
masalah, tetapi dengan versi baru standar ISO ada persyaratan untuk mengatasi
risiko dan peluang yang hadir saat Anda akan melakukan perubahan. Misalnya,
dengan membuat perubahan proses untuk mengatasi akar masalah, apakah ada
risiko bahwa keluaran proses akan menyebabkan masalah lebih lanjut di bisnis
Anda, atau bahkan di situs pelanggan Anda? Jika Anda telah mengidentifikasi
tindakan korektif yang baik untuk satu proses, apakah ada peluang bahwa ini
dapat diterapkan untuk proses lain untuk mencegah masalah terjadi di masa
depan?
• Identifikasi langkah-langkah yang diperlukan – Langkah-langkah apa yang
diperlukan untuk menghilangkan akar penyebab dari proses tersebut?
• Menilai jadwal & biaya – Bagaimana jadwal pelaksanaannya? Berapa biaya dan
laba atas investasi? Apakah ada alternatif lain yang perlu dinilai? Apakah rencana
ini layak?
• Rencanakan penilaian di sepanjang jalan – Saat Anda mengerjakan rencana Anda,
apakah Anda perlu membuat perubahan? Menilai apakah rencana tersebut bekerja
saat Anda melanjutkan dapat membantu memastikan bahwa penilaian akhir Anda
untuk efektivitas akan memberikan hasil yang otentik.
• Rencana untuk penilaian efektivitas – Sebelum memulai rencana, bagaimana kita
mengetahui bahwa perubahan benar-benar berhasil? Akankah indikator kinerja
utama meningkat? Apakah kita harus menunggu selama beberapa bulan untuk
memastikan masalahnya tidak kembali (yang berarti kita tidak mengatasi akar
masalahnya)?
d. Alat dan bahan
- Laptop
- Standar penyusunan dokumen CAPA (ISO 9000-3)
e. Prosedur kerja
1. Diskusikan dengan kelompok Anda untuk menyusun dokumen rekomendasi yang
bersifat korektif.
2. Sesuaikan penyusunan dengan proses yang telah dijelaskan pada dasar teori.
3. Kembangkan tabel berikut menjadi dokumen yang CAPA yang baik.
87
No Masalah yang Dampak dari Penyebab Tindakan Target
mungkin muncul masalah yang korektif penyelesaian
muncul
1
2

Dokumen rekomendasi tindakan korektif
g. Kesimpulan
Mahasiswa mampu menyusun dokumen rekomendasi tindakan korektif pada kegiatan
h. Rubrik
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
88
Acara 24
Pokok Bahasan : Mengevaluasi pelaksanaan penjaminan kualitas
perangkat lunak

1. Mahasiswa mampu mendokumentasikan hasil pelaksanaan penjaminan kualitas
perangkat lunak
2. Mahasiswa mampu meninjau kembali pelaksanaan penjaminan kualitas perangkat
lunak
3. Mahasiswa mampu meninjau kembali pelaksanaan tindakan perbaikan kualitas
b. Indikator
Ketepatan dalam mendokumentasikan seluruh pelaksanaan penjaminan kualitas
perangkat lunak dan meninjau pelaksanaannya.
c. Dasar teori
Software Quality Assurance ( SQA ) memiliki peran yang sangat penting untuk setiap
proses pengembangan perangkat lunak. SQA dapat membantu meningkatkan
produktivitas developer, meningkatkan kualitas produk, meningkatkan kepercayaan klien
terhadap layanan perusahaan, menghemat biaya dan waktu pengembangan, dan masih
banyak lagi.
Berdasarkan standar internasional ISO 9126, software dapat dinilai kualitasnya
berdasarkan beberapa karakteristik, yaitu:
1. Functionality (fungsionalitas)
Fungsionalitas merupakan faktor penting untuk setiap produk. QA harus memastikan
bahwa produk yang dikembangkan menyediakan fungsi yang diterapkan dengan benar
serta sesuai dengan kebutuhan user.
2. Reliability (Keandalan)
Reliability didefinisikan sebagai kemampuan suatu sistem untuk terus berfungsi ketika
digunakan dalam periode waktu tertentu. Faktor keandalan juga dapat dilihat dari
performance produk ketika menghadapi suatu kondisi. Sebagai contoh, ketika koneksi
mati selama 20 detik dan menyala kembali, produk harus bisa recover dan bekerja kembali
secara otomatis.
3. Usability (Kebergunaan)
89
Aplikasi harus dapat digunakan dengan mudah oleh pengguna. Agar produk mudah
untuk dioperasi dan dinavigasi, maka penting bagi pihak pengembang untuk mengetahui
siapa yang akan menjadi pengguna dari produk tersebut.
4. Efficiency (Efisiensi)
Karakteristik ini berkaitan dengan sumber daya sistem yang digunakan ketika software
dijalankan. Sumber daya seperti jumlah ruang disk, memori, kapasitas prosesor, dan lain-
lain harus dapat digunakan secara efisien oleh software yang dikembangkan.
5. Maintainability (Maintabilitas)
Software harus memiliki karakteristik maintainability yaitu kemampuan untuk bisa
dimodifikasi. Maintainability juga dapat didefinisikan sebagai kemampuan software untuk
mengidentifikasi dan memperbaiki kesalahan.
6. Portability (Portabilitas)
Kemampuan perangkat lunak untuk ditransfer dari satu lingkungan ke lingkungan lain.
Software harus dapat beradaptasi dengan baik ketika digunakan pada program komputer
yang berbeda seperti DOS, windows, dan lain-lain.
d. Alat dan Bahan
- Laptop
- Dokumen pelaksanaan kegiatan penjaminan kualitas perangkat lunak

e. Prosedur Kerja
1. Buatlah sebuah laporan pelaksanaan kegiatan penjaminan kualitas perangkat lunak
dengan kelompok Anda.
2. Dokumen laporan berisi:
- Halaman judul
- Kata pengantar
- Daftar isi
- Bab 1 pendahuluan
- Bab 2 penyusunan test case
- Bab 3 hasil software test & dokumen rekomendasi
- Bab 4 kesimpulan dan saran
- Daftar pustaka
Laporan kegiatan penjaminan kualitas perangkat lunak
g. Kesimpulan
Mahasiswa mampu menyusun laporan dan mengevaluasi kegiatan penjaminan
90
h. Rubrik
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
91
Acara 24
Pokok Bahasan : Mengevaluasi pelaksanaan penjaminan kualitas
perangkat lunak

1. Mahasiswa mampu mendokumentasikan hasil pelaksanaan penjaminan kualitas
perangkat lunak
2. Mahasiswa mampu meninjau kembali pelaksanaan penjaminan kualitas perangkat
lunak
3. Mahasiswa mampu meninjau kembali pelaksanaan tindakan perbaikan kualitas
b. Indikator
Ketepatan dalam mendokumentasikan seluruh pelaksanaan penjaminan kualitas
perangkat lunak dan meninjau pelaksanaannya.
c. Dasar teori
d. Alat dan Bahan
- Laptop
- Dokumen pelaksanaan kegiatan penjaminan kualitas perangkat lunak

e. Prosedur Kerja
1. Buatlah sebuah laporan pelaksanaan kegiatan penjaminan kualitas perangkat lunak
dengan kelompok Anda.
2. Dokumen laporan berisi:
- Halaman judul
- Kata pengantar
- Daftar isi
- Bab 1 pendahuluan
- Bab 2 penyusunan test case
- Bab 3 hasil software test & dokumen rekomendasi
- Bab 4 kesimpulan dan saran
- Daftar pustaka
Laporan kegiatan penjaminan kualitas perangkat lunak
92
g. Kesimpulan
Mahasiswa mampu menyusun laporan dan mengevaluasi kegiatan penjaminan
h. Rubrik
No Indikator Skor*
1 1 2 3 4
4 1 2 3 4
menjelaskan tugas
Jumlah skor
93

(30 Sept) BKPM WORKSHOP SQA

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

(30 Sept) BKPM WORKSHOP SQA

Diunggah oleh

Hak Cipta:

Format Tersedia

BKPM

(BUKU KERJA PRAKTIK MAHASISWA)

TIF3605 WORKSHOP KUALITAS PERANGKAT LUNAK

PROGRAM STUDI TEKNIK INFORMATIKA

POLITEKNIK NEGERI JEMBER

WORKSHOP PENGEMBANGAN PERANGKAT LUNAK

Trismayanti Dwi P, S.Kom., M.Cs Intan Sulistyaningrum S., S.Pd., M.Eng

Hendra Yufit Riskiawan, S.Kom., M.Cs

Jember, 6 September 2021

a. Capaian Pembelajaran Mata Kuliah (CPMK)

a. Capaian Pembelajaran Mata Kuliah (CPMK)

a. Capaian Pembelajaran Mata Kuliah (CPMK)

a. Capaian Pembelajaran Mata Kuliah (CPMK)

a. Capaian Pembelajaran Mata Kuliah (CPMK)

d. Alat dan Bahan

f. Hasil dan Pembahasan

a. Capaian Pembelajaran Mata Kuliah (CPMK)

2. Error severity metrics

• Metrik TTO dan ADMC berdasarkan pada data untuk semua

Software process productivity metrics

2. Severity of HD calls metrics

HD productivity and Effectiveness Metrics

• HD effectiveness merupakan sumber daya yang diinvestasikan dalam responding

Corrective Maintenance Quality Metrics

• Failures of maintenance services metrics

• RepYF adalah jumlah pengulangan panggilan kegagalan perangkat lunak

Software corrective maintenance productivity and effectiveness metrics

d. Alat dan Bahan

a. Capaian Pembelajaran Mata Kuliah (CPMK)

a. Capaian Pembelajaran Mata Kuliah (CPMK)

a. Capaian Pembelajaran Mata Kuliah (CPMK)

a. Capaian Pembelajaran Mata Kuliah (CPMK)

i. Capaian Pembelajaran Mata Kuliah (CPMK)

a. Capaian Pembelajaran Mata Kuliah (CPMK)

a) Memberikan jaminan bahwa semua jalur independen suatu modul

d. Alat dan Bahan

f. Hasil dan Pembahasan

a. Capaian Pembelajaran Mata Kuliah (CPMK)

2. Teknik Black-box Testing

f. Hasil dan Pembahasan

a. Capaian Pembelajaran Mata Kuliah (CPMK)

a) Memberikan jaminan bahwa semua jalur independen suatu modul

a. Capaian Pembelajaran Mata Kuliah (CPMK)

a. Capaian Pembelajaran Mata Kuliah (CPMK)

Untuk membuat pengujian dapat dibaca yang mengevaluasi apakah komponen-

• Menjalankan pengujian unit lokal

a. Capaian Pembelajaran Mata Kuliah (CPMK)

Tampilannya akan seperti di bawah ini:

Perintah assertEqual akan membandingkan parameter pertama (output yang diinginkan)

a. Capaian Pembelajaran Mata Kuliah (CPMK)

a. Capaian Pembelajaran Mata Kuliah (CPMK)

Gambar 1 Proses tindakan korektif

Gambar 2 Proses tindakan preventif

Keberhasilan operasi dari proses CAPA meliputi kegiatan sebagai berikut:

Gambar 3 Proses tindakan korektif dan preventif

f. Hasil dan pembahasan

a. Capaian Pembelajaran Mata Kuliah (CPMK)

f. Hasil dan pembahasan

a. Capaian Pembelajaran Mata Kuliah (CPMK)

- Dokumen pelaksanaan kegiatan penjaminan kualitas perangkat lunak

a. Capaian Pembelajaran Mata Kuliah (CPMK)

- Dokumen pelaksanaan kegiatan penjaminan kualitas perangkat lunak

Anda mungkin juga menyukai