Software Quality Assurance

(Jaminan Kualitas Perangkat Lunak)

Software Quality Assurance (SQA) diaplikasikan secara menyeluruh pada proses pengembangan
software. SQA meliputi :
1. analisis, perancangan, pengkodean, dan metode serta peralatan ujicoba.
2. Tinjauan ulang teknikal secara formal yang diaplikasikan pada setiap tahapan pengembangan software.
3. Strategi ujicoba dengan banyak tahapan (multitiered).
4. Pengawasan terhadap dokumentasi software dan perubahan yang dialaminya.
5. Suatu prosedur untuk menjamin pemenuhan standar pengembangan software (jika ada).
6. Mekanisme pengukuran dan laporan .
Setiap pengembang software pasti setuju jika dikatakan bahwa kualitas software merupakan salah satu
tujuan yang penting. Banyak definisi mengenai kualitas software, tetapi disini kualitas software didefinisikan
sebagai :
penyesuaian kebutuhan fungsional dan performa yang ditetapkan secara eksplisit, standar
pengembangan yang terdokumentasi secara eksplisit, dan karakteristik implisit yang diharapkan dari
seluruh software yang dikembangkan secara professional.
Definisi diatas menjelaskan 3 hal penting, yaitu :
1. Kebutuhan software merupakan pondasi/dasar dari kualitas yang akan diukur. Sedikitnya penyesuaian
terhadap kebutuhan, maka semakin tidak berkualitas.
2. Standar yang dispesifikasikan mendefinisikan sekumpulan kriteria pengembangan yang memandu
pengembangan software. Jika kriteria tidak disertakan, maka dapat dipastikan hasil akhir akan
berkualitas rendah.
3. Terdapat kebutuhan implisit (implicit requirements) yang terkadang tidak disebutkan (misalkan,
keinginan untuk kemampuan pemeliharaan yang mudah). Jika software menyesuaikan kepada
kebutuhan eksplisit, tetapi tidak kepada kebutuhan implisit, maka kualitas software akan dipertanyakan.

Faktor-faktor kualitas software(Software quality factors)

Faktor-faktor yang dapat mempengaruhi kualitas software dibagi menjadi 2 kategori :
1. Faktor-faktor yang dapat diukur secara langsung (misalkan : error )
2. Faktor-faktor yang dapat diukur secara tidak langsung (misalkan : usability dan maintainability).

Ayuliana/Testing dan Implementasi/Feb2011

Menurut McCall terdapat 3 aspek penting dari suatu produk software, yaitu : karakteristik operasional,
kemampuan perubahan ketika software sudah berjalan, dan kemampuan beradaptasi terhadap lingkungan baru,
seperti terlihat pada gambar diatas.
Berdasarkan gambar diatas, McCall menyediakan beberapa dekripsi yaitu :
1. Correctness (kebenaran), tingkat pemenuhan program terhadap kebutuhan yang dispesifikasikan dan
memenuhi tujuan/misi pengguna.
2. Reliability (Keandalan), tingkat kemampuan program yang diharapkan dapat menampilkan fungsi yang
dimaksud dengan presisi yang ditetapkan.
3. Efficiency (efisiensi), jumlah sumberdaya yang diproses dan kode yang diperlukan oleh program untuk
melaksanakan fungsinya.
4. Integrity (Integritas), tingkat kemampuan pengawasan akses terhadap data atau software oleh orang-orang
tertentu.
5. Usability, usaha yang diperlukan untuk mempelajari, mengoperasikan, menyiapkan masukan dan
mengartikan keluaran program.
6. Maintainability, usaha yang diperlukan untuk menetapkan dan memperbaiki kesalahan dalam program.
7. Flexibility, usaha yang diperlukan untuk memodifikasi program operasional.
8. Testability, usaha yang diperlukan untuk menguji program untuk memastikan bahwa program melaksanakan
fungsi yang telah ditetapkan.
9. Portability, usaha yang diperlukan untuk memindahkan program dari hardware/lingkungan sistem software
tertentu ke yang lainnya.
10. Reusability, tingkat kemampuan program/bagian dari program yang dapat dipakai ulang dalam aplikasi
lainnya, berkaitan dengan paket dan lingkup dari fungsi yang dilakukan oleh program.
11. Interoperability, usaha yang diperlukan untuk menggabungkan satu sistem dengan sistem lainnya.
Untuk membentuk pengukuran langsung mengenai faktor-faktor kualitas tidaklah mudah. Terdapat
beberapa ukuran (metric) yang didefinisikan dan penilaiannya diukur secara objektif. Pengukuran biasanya
dalam bentuk checklist dengan menggunakan skala 0-10. McCall menetapkan beberapa pengukuran yang
dapat digunakan, diantaranya :
1. Auditability, kemudahan yaitu penyesuaian terhadap standar yang dapat diperiksa.
2. Accuracy, ketepatan perhitungan dan kontrol.
3. Communication commonality, tingkatan dimana interface standar, protokol dan bandwidth digunakan.
4. Completeness, tingkatan dimana implementasi lengkap dari fungsi yang dibutuhkan telah tercapai.
5. Conciseness, kepadatan program dalam jumlah baris kode.
6. Consistency, penggunaan rancangan dan teknik dokumentasi dalam satu bentuk diseluruh proyek
pengembangan software.
7. Data commonality, penggunaan struktur dan tipe data standar diseluruh program.
8. Error tolerance, kerusakan yang muncul ketika program menemukan kesalahan/kegagalan.
9. Execution efficiency, performa run-time suatu program.
10. Expandability, tingkatan dimana rancangan arsitektural, data atau prosedur dapat dikembangkan.
11. Generality, lingkup aplikasi potensial dari suatu komponen program.
12. Hardware independece, tingkatan dimana software dipisahkan dari hardware yang mengoperasikannya.
13. Instrumentation, tingkatan dimana pengawasan program memiliki operasi tersendiri dan
mengidentifikasikesalahan yang terjadi.
14. Modularity, kemandirian fungsional dari suatu komponen program.
15. Operability, kemudahan pengoperasian program.
16. Security, ketersediaan mekanisme yang mengontrol atau menproteksi program dan data.
17. Self-documentation, tingkatan dimana kode sumber menyediakan dokumentasi yang berarti.
18. Simplicity, tingkatan dimana program dapat dimengerti tanpa kesulitan.
19. Software system independence, tingkatan dimana program mandiri terhadap feature bahasa pemrograman
nonstandar, karakteristik sistem operasi, dan batasan-batasan lingkungan lainnya.
20. Traceability, kemampuan penelusuran ulang representasi rancangan atau komponen program yang
sesungguhnya dengan kebutuhan awal (requirements).
Ayuliana/Testing dan Implementasi/Feb2011

21. Training, tingkatan dimana software membantu dalam user yang baru dalam penerapan sistem.
Keterhubungan antara faktor-faktor kualitas software dengan ukuran-ukuran (metrics) yang digambarkan dalam
tabel :

Faktor-faktor kualitas yang dideskripsikan oleh McCall dan kawan-kawan merepresentasikan sejumlah
checklist yang disarankan. Hewlett-Packard telah membuat sejumlah faktor-faktor kualitas yang disingkat
FURPS, yaitu Functionality, Usability, Reliability, Performance, Supportability. Dimana atribut-atribut untuk
setiap faktor seperti tersebut dibawah ini :
1. Functionality, diperkirakan dengan mengevaluasi sejumlah feature dan kemampuan program, fungsi-fungsi
umum yang disediakan, dan keamanan terhadap keseluruhan sistem.
2. Usability, diperkirakan dengan mempertimbangkan faktor manusia, keseluruhan estetika, konsistensi, dan
dokumentasi.
3. Reliability, dievaluasi dengan mengukur frekuensi dan penanganan kesalahan, keakuratan hasil output,
jangka waktu antar kesalahan (Mean Time Between Failure), kemampuan untuk recover dari kesalahan dan
kemampuan prediksi program.
4. Performance, diukur dengan mengevaluasi kecepatan pemrosesan, waktu respon, konsumsi sumberdaya,
keluaran dan efisiensi.
5. Supportablity, kombinasi kemampuan untuk memperpanjang program, kemampuan adaptasi dan
kemampuan layanan (ketiga atribut ini merepresentasikan maintainability) sebagai tambahan untuk
kemampuan ujicoba, kesesuaian, kemampuan penyusunan (kemampuan untuk mengorganisir dan

Ayuliana/Testing dan Implementasi/Feb2011

mengatur elemen-elemen penyusunan software), kemudahan dengan apa sistem dapat diinstalasi dan
kemudahan dengan apa masalah-masalah dapat dilokasikan.
Software Quality Assurance
Jaminan kualitas merupakan aktivitas mendasar untuk setiap bisnis yang menghasilkan produksi yang
digunakan oleh orang lain. Diawal abad ke-20, jaminan kualitas merupakan tanggungjawab yang ditawarkan
oleh produsen yang membuat suatu produk. Jaminan kualitas secara formal diperkenalkan pertamakalinya oleh
Bell Laboratory pada tahun 1916 dan berkembang cepat serta meluas keseluruh dunia. Disaat ini, setiap
perusahaan telah memiliki mekanisme untuk menentukan kualitas dari produknya.
Sejarah jaminan kualitas dalam pengembangan perangkat lunak sejajar/paralel dengan sejarah dalam
pembuatan hardware. Diawal tahun 1950 dan 1960 kualitas perangkat lunak merupakan tanggung jawab dari
pembuat program. Standar untuk jaminan kualitas perangkat lunak diperkenalkan dalam kontrak pengembangan
perangkat lunak militer selama tahun 1970 dan mulai berkembang secara pesat secara komersil.
SQA merupakan pola aksi yang terencana dan sistematis yang dibutuhkan untuk memastikan kualitas
suatu software. Lingkup dari SQA dalam software sangat beragam , mencakup : pembuat software, manajer
proyek , customer, sales peoples, dan orang-orang yang dilayani dalam SQA. Orang-orang yang melaksanakan
SQA harus dapat melihat software dari sudut pandang konsumen.
Aktivitas-aktivitas SQA (SQA Activities)
SQA terdiri dari berbagai jenis aktivitas yang terhubung dengan 7 aktivitas utama, yaitu :
1. Aplikasi metode-metode teknikal (Application of technical methods)
Kualitas software didesain kedalam sebuah produk atau sistem. Pada kenyataannya SQA dimulai dengan
sekumpulan metode teknikal dan tool yang membantu analis untuk mencapai spesifikasi dengan kualitas
yang tinggi dan para perancang membangun desain yang berkualitas tinggi.
2. Mengadakan review teknikal formal (conduct of formal technical reviews)
Ketika spesifikasi (atau prototype) dan desain telah dibuat, maka masing-masing harus di perkirakan untuk
kualitas. Aktivitas utama yang memenuhi penaksiran kualitas adalah formal technical review (FTR). FTR
merupakan pertemuan khusus yang diadakan oleh staff teknikal dengan tujuan untuk menemukan masalah.
Dalam berbagai situasi, review merupakan hal yang efektif seperti ujicoba dalam mengungkap kerusakan
dalam software.
3. Ujicoba perangkat lunak (software testing)
Ujicoba software mengkombinasikan strategi beberapa tahapan/langkah dengan sejumlah desain metode uji
kasus yang membantu memastikan pendeteksian kesalahan yang efektif. Banyak pengembang software
menggunakan ujicoba software sebagai jaminan kualitas.
4. Pelaksanaan standar (enforcement of standards)
Tingkatan dimana prosedur dan standar formal diaplikasikan dalam proses pengembangan software, sangat
bervariasi antara satu perusahaan dengan yang lainnya. Dalam banyak kasus, standar ditentukan oleh
konsumen atau pembuat kebijakan. Jika standar disediakan(secara formal tertulis) maka aktivitas SQA
harus dilaksanakan untuk memastikan standar-standar tersebut dilakukan.
5. Pengawasan terhadap perubahan (control of change)
Ancaman utama dalam kualitas software adalah perubahan yang dilakukan terhadap sumber. Setiap
perubahan yang dilakukan pada software sangat potensial untuk menghasilkan kesalahan atau membuat
efek sampingan yang mengakibatkan kesalahan. Proses pengawasan perubahan memberikan kontribusi
secara langsung terhadap kualitas software dengan permintaan perubahan yang diformalkan. Pengawasan
perubahan diaplikasikan selama pengembangan software dan setelahnya, atau selama tahapan
pemeliharaan software.
6. Pengukuran (measurement)
Pengukuran (measurement) merupakan aktivitas yang melengkapi setiap bidang pengembangan. Tujuan
utama dari SQA adalah untuk menelusuri kualitas software dan memperkirakn pengaruh dari perubahan
secara metodologi maupun prosedur pada peningkatan kualitas software. Untuk itu, ukuran-ukuran software
(software metrics) harus dikumpulkan.
7. Penyimpanan catatan dan laporan (record keeping and reporting)
Penyimpanan catatan dan perekaman (record keeping and recording) pada SQA menyediakan prosedur
untuk mengumpulkan dan penyebaran informasi SQA. Hasil dari review, audit, pengawasan perubahan,
ujicoba, dan aktivitas SQA lainnyaharus menjadi bagian dari record history untuk proyek dan harus
disebarkan untuk staff pengembangan untuk pengetahuan.

Ayuliana/Testing dan Implementasi/Feb2011

TINJAUAN ULANG PERANGKAT LUNAK (SOFTWARE REVIEW)

Software review merupakan filter selama proses pengembangan software. Review diaplikasikan pada
beberapa titik selama pengembangan software dan dilakukan untuk membongkat cacat yang kemudian dapat
dihilangkan. Software review dilakukan untuk memperbaiki aktivitas pengembangan software yang seperti
analisis, perancangan dan pengkodean.
Sebuah tinjauan ulang/review merupakan suatu cara yang memanfaatkan keberagaman sekelompok
orang untuk :
1. Mengetahui peningkatan yang diperlukan oleh suatu produk seseorang atau tim
2. Mengkonfirmasikan bahwa peningkatan bagian-bagian suatu produk tidak diiinginkan atau tidak
diperlukan
3. Pencapaian pekerjaan secara teknis yang lebih seragam, atau sedikitnya lebih dapat diramalkan, mutu
yang dapat dicapai tanpa tinjauan ulang, dalam rangka membuat pekerjaan teknis yang lebih dapat
dikendalikan
Terdapat banyak jenis tinjauan ulang yang dapat dilaksanakan sebagai bagian dari pengembangan
software. Presentasi formal dari sebuat rancangan software bagi konsumer, pihak manajemen dan staf teknikal
adalah berkas tinjauan ulang. Sebuat tinjauan ulang teknik formal yang dilakukan oleh pengembang software
merupakan alat utama dalam meningkatkan kualitas perangkat lunak.
Defect Amplification Model dapat digunakan untuk mengilustrasikan pembentukan dan pendeteksian
kesalahan selama perancangan awal, perancangan detail dan tahapan pengkodean dalam proses
pengembangan software

Defect Amplification Model

Setiap kotak merepresentasikan satu tahapan pengembangan. Pada setiap tahapan, kesalahan dapat
terjadi. Sebuah review bisa saja gagal untuk menemukan kesalahan yang baru ataupun kesalahan dari tahapan
sebelumnya. Terkadang, kesalahan yang berasal dari tahapan sebelumnya akan mengalami penguatan (Faktor
penguat X). Kotak pada bagian kanan merupakan persentase efisiensi pendeteksian kesalahan.

Ayuliana/Testing dan Implementasi/Feb2011

Defect Amplification No Review

Defect Amplification Review Conducted

Ayuliana/Testing dan Implementasi/Feb2011

REVIEW TEKNIKAL FORMAL (Formal Technical Review)

FTR merupakan aktivitas SQA yang dilakukan oleh praktisi pengembang software. Tujuan dari FTR
adalah :
1. Untuk menemukan kesalahan dalam fungsi, logika atau implementasi untuk semua representasi
software
2. Untuk memverifikasi bahwa software yang sedang di-review telah memenuhi kebutuhan
3. Untuk memastikan bahwa software yang direpresentasikan sesuai dengan standar yang didefinisikan
diawal (predefined)
4. Untuk mendapatkan software yang dikembangkan dengan bentuk yang sama (uniform)
5. Untuk membuat suatu proyek lebih mudah diatur (manageable)
Sebagai tambahan, FTR diberikan sebagai pelatihan dasar, sehingga memungkinkan pengembang junior
mengamati pendekatan yang berbeda terhadap analisis, desain dan implementasi software.
Pertemuan Review (review meeting)
Ketika format FTR telah ditetapkan, maka diadakan pertemuan yang memiliki batasan-batasan :
1. Menyertakan sedikitnya 3 atau 5 orang (Khusus)
2. Persiapan yang baik harus ada tetapi harus memerlukan waktu tidak lebih dari 2 jam kerja untuk setiap
orangnya
3. Durasi dari pertemuan tidak lebih dari 2 jam
FTR difokuskan pada hal yang spesifik, seperti produk komponen dari software (spesifikasi kebutuhan, detail
desain modul). Akhir dari sebuah review, seluruh peserta FTR harus memutuskan :
1. Menerima produk tanpa modifikasi lanjutan
2. Menolak produk sampai dengan kesalahan yang ada teratasi (dan melakukan review kembali)
3. Menerima produk dengan syarat (kesalahan minor terdeteksi dan harus diperbaiki)
Laporan review dan penyimpanan catatan (Review Reporting and Record Keeping)
Selama FTR, terdapat peserta yang merekam seluruh hal yang telah dicapai, kemudian dirangkum pada akhir
dari meeting. Laporan rangkuman dari review menjawab 3 pertanyaan berikut :
1. Apa yang telah di-review?
2. Siapa yang me-review?
3. Apa yang ditemukan dan penanganannya?
Daftar hal-hal yang di-review memiliki 2 kegunaan : (1) Untuk identifikasi area masalah dalam produk dan (2)
untuk diberikan sebagai checklist aktifitas yang membimbing produser ketika perbaikan dilakukan.
Review Guidelines
Hal-hal dibawah ini merepresentasikan sekumpulan panduan minimum untuk FTR, yaitu :
1. Me-review produk, bukan pembuatnya
2. Buatlah Agenda dan tetap mengaturnya
3. Batasi debat dan bantahan
4. Menjelaskan area permasalahan, tetapi jangan berusahan untuk menyelesaikan setiap permasalahan yang
ada
5. Buatlah catatan
6. Batasi jumlah partisipan dan mintalah persiapan yang matang
7. Buatlah checklist untuk setiap produk yang akan direview
8. Alokasikan sumberdaya dan waktu untuk FTR
9. Selenggarakan pelatihan yang berarti untul seluruh reviewer
10. Review terlebih dahulu hasil review sebelumnya
Review Checklist
FTR dapat dilaksanakan pada setiap tahapan selama proses pengembangan software berlangsung. Berikut ini
merupakan checklist
yang dapat digunakan untuk menaksir produk yang merupakan bagian dari
pengembangan software :
1. Software engineering
Spesifikasi sistem mengalokasikan fungsi-fungsi dan performa untuk beberapa elemen yang fokus pada
masing-masing bagian, baik hardware maupun software. Quality assurance menaksir validasi tingkat
Ayuliana/Testing dan Implementasi/Feb2011

kebutuhan sistem dan layanan fungsi memeriksa kebutuhan diagnostik. Berikut beberapa daftar pertanyaan
yang fokus pada area-area penting dalam software engineering :
a) Apakah fungsi-fungsi utama telah didefinisikan dalam batasan dan bentuk yang telah ditetapkan?
b) Apakah interface antar elemen sistem telah didefinisikan ?
c) Apakah batasan performa telah ditentukan bagi keseluruhan sistem maupun setiap elemen sistem?
d) Apakah mekanisme untuk validasi dan verifikasi sistem telah ditetapkan ?
2. Software project planning
Tahapan ini menilai resiko dan mengembangkan estimasi sumber daya, biaya dan jadwal berdasarkan
alokasi software yang ada sebagai bagian dari aktivitas pengembangan sistem. Checklist yang dapat
digunakan :
a) Apakah terminologi sistem telah jelas ?
b) Apakah sumberdaya yang terperlukan tersedia dan mudah didapat?
c) Apakah seluruh resiko telah didefinisikan?
d) Apakah seluruh pekerjaan telah didefinisikan dan diurutkan? Apakah dengan pekerjaan paralel dapat
memberikan sumberdaya lebih ?
3. Software requirements analysis
Menitikberatkan pada kemampuan menelusur ulang kebutuhan sistem dan konsistensi serta ketepatan dari
model analisis. FTR yang dapat digunakan :
a) Apakah batasan informasi analisis telah lengkap, konsisten, dan akurat ?
b) Apakah pembagian masalah telah lengkap?
c) Apakah interface internal dan eksternal telah didefinisikan dengan tepat?
d) Apakah model data merefleksikan objek data, atributnya dan relasinya?
e) Apakah disediakan prototyping untuk para end user/costomer?
4. Software design
Meninjau ulang rancangan software dengan fokus kepada rancangan data, rancangan arsitektural dan
rancangan prosedural. Menitikberatkan kepada ketepatan algoritma yang diimplementasikan dalam
modul/program.
Pada review preliminary design :
a) Apakah kebutuhan software direfleksikan dalam arsitektur software?
b) Apakah efektivitas modular terpenuhi? Apakah modul-modul dapat berfungsi secara independen?
c) Apakah struktur data konsisten dengan batasan informasi ?
d) Apakah struktur data konsisten dengan kebutuhan software?
e) Apakah pemeliharaan telah dipertimbangkan ?
Pada saat perancangan :
a) Apakah algoritma yang digunakan dapat memenuhu fungsi yang diinginkan ?
b) Apakah logika algoritma yang digunakan sudah benar?
c) Apakah interface yang dihasilkan konsisten dengan rancangan arsitektural ?
d) Apakah penanganan kesalahan dan 'antibugging' telah dispesifikasikan ?
5. Coding
Kesalahan biasanya terjadi pada saat proses merubah rancangan kedalam sebuah bahasa pemrograman.
Memeriksa ulang program merupakan cara yang efektif untuk mencari kesalahan translasi. Checklist yang
digunakan paada fase perancangan memastikan bahwa algoritma yang benar telah diterapkan.
a) Apakah terdapat kesalahan eja dan pengetikan program?
b) Apakah terdapat ketidak sesuaian dengan standar pemrograman seperti cara penulisan, komentar, dan
prolog modul ?
c) Apakah terdapat komentar yang tidak benar/ambigu ?
d) Apakah tipe data dan deklarasi data telah sesuai ?
6. Software testing
Ujicoba software merupakan salah satu aktivitas jaminan kualitas. Kelengkapan dan efektivitas ujicoba
secara dramatis dapat meningkatkan dengan menilai rencana uji dan prosedur yang akan dilakukan.
Pada rencana ujicoba :
Ayuliana/Testing dan Implementasi/Feb2011

a) Apakah tahapan ujicoba utama telah diidentifikasikan dan diurutkan ?

b) Apakah kemampuan penelusuran kriteria validasi telah dibuat sebagai bagian dari analisis kebutuhan
software ?
c) Apakah rencana ujicoba konsisten dengan rencana proyek keseluruhan ?
d) Apakah jadwal ujicoba telah didefinisikan secara eksplisit ?
e) Apakah mekanisme penyimpanan catatan ujicoba telah disediakan ?
Pada prosedur ujicoba :
a) Apakah ujicoba white box dan black box telah dispesifikasikan ?
b) Apakah seluruh jalur logika yang independen telah diuji ?
c) Apakah penanganan kesalahan telah diuji ?
d) Apakah batasan-batasan nilai telah diuji ?
e) Apakah respon waktu performa telah diperiksa ?
7. Maintenance
Checklist review untuk pengembangan software sama halnya dengan tahap pemeliharaan software.
Terdapat beberapa pertimbangan yang harus tetap diperhatikan :
a) Apakah efek samping dari suatu perubahan telah dipertimbangkan ?
b) Apakah permintaan perubahan software telah didokumentasikan, dievaluasi dan disetujui ?
c) Apakah suatu perubahan yang dilaksanakan telah didokumentasikan dan dilaporkan kepada seluruh
pihak yang terkait ?

Ayuliana/Testing dan Implementasi/Feb2011