UJI KUALITAS PL

BY FEBRI NOVA LENTI

 PENDAHULUAN
SOFTWARE TESTING
Software Testing : adalah suatu proses untuk menentukan apakah
PL sudah memenuhi requirement dan mengidentifikasi cacat PL
tsb.
Jika ditemukan ketidaksesuaian , tim tester /Penguji melaporkan
cacat cacat tersebut kepada tim developer.
Jadi aturan main tim tester adalah memenuhi tanggung jawab
yang diembannya yaitu melakukan pengecekan lalu
melaporkannya, bukan untuk menentukan keputusan apakah PL
layak di kerjakan / lanjutkan atau tidak.
 KOMPOSISI TIM TESTER

Siapa saja yang bisa masuk dalam komposisi tim Tester ?

Beberapa kategori yang bisa masuk dalam tim tester adalah:
1. Pelanggan PL : yaitu bagian / departemen yang menginginkan
pengembangan Pl itu
2. Pengguna PL : Individu / Kelompok yang akan memakai PL
3. Pengembang PL : Individu / kelompok yang mengemban
tanggung jawab dalam menulis requirement, desain,
membangun, mengubah dan memelihara PL
 KOMPOSISI TIM TESTER (2)
4. Penguji / Tester : individu / kelompok yg punya skill khusus membuat fungsi
pengecekan (bisa sub bagian pengembang, kelompok independen
atau gabungan keduanya )
5. Manajemen Pelayanan Informasi : Individu / Kelompok yang bertanggung jawab
terhadap pelayanan informasi dari suatu organisasi contoh Simjar,
divisi IT, Bagian TIK, ...
6. Manajemen Organisasi Senior /CEO : CEO organisasi / ekseskutif senior lainnya
7. Auditor : satu atau lebih individu yang mempunyai tanggung jawab untuk
mengevaluasi keefektifan, efisiensi dan kecukupan kendalidalam area
pelayanan informasi. Pengujian akan dianggap sebagai sebuah
kendali bagi fungsi audit
 CACAT ( DEFECT)

Cacat adalah: suatu kondisi berbeda dari suatu attribut produk yang diiinginkan
Perbedaan tersebut bisa berasal dari 2 sudut pandang :
1. cacat dari segi Spesifikasi Produk : yaitu pengembangan produk berbeda dari yg diinginkan
2. cacat dari segi harapan pelanggan / user : sesuatu yg user / pelanggan inginkan tidak terdapat
pada produk yang dibangun
Cacat secara umum dibagi dalam 3 kategori :
◦ 1. Kesalahan (Wrong) : spec diimplementasikan tidak benar
2. Kehilangan (Missing) : suatu spec atau requirement yg diinginkan tidak ada dalam produk yang
dibangun
3 ekstra (Extra) : sebuah requirement yang tidak ditetapkan tergabung dalam produk yang dibangun . Ini
tetap dianggap cacat
CACAT VS KERUSAKAN (FAILURE)

Sebuah cacat yg tergabung dalam sistem PL dapat dikategorikan sebagai wrong, misssing atau
extra. Ia dapat ditemukan dalam PL itu sendiri atau dalam petunjuk manual atau dokumentasi.
Setiap cacat yang menyebabkan kesalahan dalam operasi atau mempunyai pengaruh negatif
terhadap user / pelanggan disebut sebagai - kerusakan (Failure)
Perhatian utama terhadap cacat adalah jika sampai pada kerusakan
Beberapa cacat tidak pernah menyebabkan samapi kerusakan, disisi lain 1 cacat dapat
menyebabkan sejuta kerusakan. Contoh menyebabkan hilang atau rusaknya memori yg
menyimpan data supplier / pelanggan. Atau mengacau panggilan telpon, ....
 MENDEFENISIKAN STRATEGI
PENGUJIAN PL
Pengujian SI adalah bagian dari problem solving. Sebagaimana beberapa aktivitas problem solving,
menentukan kevalidan solusi adalah bagian dari proses. Pengujian adalah teknik yang digunakan
untuk menentukan apakah solusi menyelesaikan persoalan.
Strategi pengujian meliputi 3 tahap :
1. Menunjukkan kevalidan PL pada setiap tahap pengembangan SDLC
2. Menentukan kevalidan akhir sistem terhadap keperluan dan kebutuhan user
3. Menguji watak sistem dengan mengeksekusi sistem dengan samoel data tes
Kebutuhan Pengujian/ validasi terhadap PL berbeda beda , tergantung 4 faktor :
1. Ukuran / besar PL : kebutuhan pengujian PL yg besar dengan yg kecil tentunya berbeda
 MENDEFENISIKAN STRATEGI
PENGUJIAN PL (2)
2 Kekritisan domain PL : PL yg domainnya kritis memerlukan teknik dan strategi
pengujian yg berbeda
3. Keunikan domain PL : strategi dan teknik pengujian PL yg domainnya unik
tentu berbeda dengan yg domainnya umum.
4. Alokasi Biaya Pengujian : Besarnya alokasi biaya untuk pengujian tentunya
akan mempengaruhi pemilihan metode dan jumlah pengujian yang dilakukan
Untuk setiap proyek PL, tidak hanya kebutuhan produk saja tapi kebutuhan
validasi sebaiknya ditentukan dan terinci pada perencanaan proyek.
 RESIKO RESIKO STRATEGIS
SISTEM KOMPUTER
Resiko : adalah suatu kondisi yang dapat menyebabkan
kehilangan.
Suatu pendekatan efektif dari pengujian adalah mengidentifkasi
dan mengevaluasi resiko resiko dalam system computer
Hukum Resiko : Resiko tidak bisa dihilangkan
Manajemen Resiko ?
1. Mengurangi / memperkecil probabilitas terjadinya resiko
 RESIKO RESIKO STRATEGIS
SISTEM KOMPUTER (2)
2. mengurangi / menghilangkan efek kehilangannya
Pengembangan suatu PL juga memiliki resiko. Beberapa
resiko resiko yg ada pada suatu sistem komputer , sbb :
1. Hasil yang tidak benar
2. Transaksi yang tidak diizinkan akan tetapi diterima oleh
sistem
3. Kehilangan kesatuan / integritas file komputer
 RESIKO RESIKO STRATEGIS
SISTEM KOMPUTER (3)
4. Pemrosesan gagal direkonstruksi
5. Pemrosesan tidak berlanjut
6. Penurunan penyediaan pelayanan terhadap user
7. Keamanan sistem kurang
8. Pemrosesan yang bertentangan dengan kebijakan /
regulasi pemerintah
9. Hasil sistem yg tidak dpt dicapai
 RESIKO RESIKO STRATEGIS
SISTEM KOMPUTER (4)
10. Sistem sulit digunakan
11. Program tidak dapat dipelihara
12. Sistem tidak dapat berkoneksi dengan system lain
13. Level Performansi tidak dapat diterima
14. Sistem sulit dioperasikan
 RESIKO RESIKO STRATEGIS
SISTEM KOMPUTER (5)
Sebuah pendekatan pengujian yang efektif akan mengidentifikasi
dan mengevaluasi resiko resiko dlm system komputer.
Suatu keputusan dapat dibuat seperti seberapa banyak resiko
dapat diterima dan kemudian suatu rencana tes didesain untuk
menerima tujuan tsb.
Setiap jenis resiko menentukan seberapa banyak pengujian
dilakukan atau tipe tipe pengujian apa saja yg diperlukan pd
sistem
 NILAI EKONOMIS PENGUJIAN
Seorang manajer pelayanan informasi melukiskan pengujian
sbb:
Pengujian yang terlalu sedikit adalah kejahatan
Pengujian yg terlalu banyak adalah suatu dosa
Resiko dari kelebihan pengujian (over testing) adalah
penggunaan sumber daya sumber daya yg tdk penting dlm
pengujian sistem komputer, akibatnya menjadi tidak berarah
atau biaya pengujian membengkak jauh melebihi nilai cacat yg
terdeteksi
 NILAI EKONOMIS PENGUJIAN
(2)
Permasalahan yg paling banyak terjadi dalam pengujian
adalah sbb :
Kegagalan dalam mendefenisikan tujuan pengujian
Pengujian pada tahap yg salah dari siklus hidup
Penggunaan tes tes yg tidak efektif
Hubungan keefektifan testing dengan biaya di tunjukkan
pada kurva sbb :
NILAI EKONOMIS PENGUJIAN
(3)
NILAI EKONOMIS SDLC TESTING
 Suatu studi di IBM menunjukkan suatu sistem aplikasi selama siklus hidup
pengembangan system (SDLC) akan menghasilkan +- 60 cacat (defect)
 studi ini juga menunjukkan bahwa pengujian sampai dengan fase coding
efektif hanya mendeteksi 50 % cacat dan setelah fase coding efektif
mendeteksi 80 % cacat
 Studi ini dan studi sejenis lainnya juga menunjukkan bahwa terdapat plg
sedikit biaya 10 kali unit cacat yg dikeluarkan bila melakukan pengujian
pada fase coding dibanding fase sebelumnya,serta biaya 100 x unit cacat
jika pengujian dilakukan setelah fase coding
 Fakta fakta ini ditunjukkan pada gambar utk suatu system dengan perkiraan
1000 baris (1 KLOC)
 MENDEFENISIKAN TAKTIK
PENGUJIAN PL
 Taktik pengujian adalah dengan cara apa strategi pengujian di capai
 Untuk memahami taktik pengujian hrs memahami konsep
workbench
 Dalam IT workbench sering ditunjukkan sebagai step, fase atau task
task
 Fakta fakta ini ditunjukkan pada gambar utk suatu system dengan
perkiraan 1000 baris (1 KLOC)
 Fakta fakta ini ditunjukkan pada gambar utk suatu system dengan
perkiraan 1000 baris (1 KLOC)
 MENDEFENISIKAN TAKTIK
PENGUJIAN PL (2)
 workbench adalah suatu cara mengilustrasikan dan
mendokumentasikan aktifitas 2x khusus apa saja yang harus
dilakukan
Terdapat 4 komponen utk tiap tiap workbench :
1. Input -> mengurutkan kriteria atau deliverables need utk
membentuk kerja
2. Procedure to do -> task task atau proses yg akan
mengubah input
 MENDEFENISIKAN TAKTIK
PENGUJIAN PL (3)
3. Procedure to check -> proses proses yg menentukan
apakah output memenuji standar
4. Output -> kriteria akhir atau delivereables yg dihasilkan
workbench
Suatu tool tdk dianggap sebagai bagian dr workbench krn ia
tdk termasuk ke dalam salah satu dari prosedur pelaksanaan
Siapa yg harus mendefenisikan workbench ? Manager
process
 MENDEFENISIKAN TAKTIK
PENGUJIAN PL (4)
Sehingga jika dalam 1 siklus hidup terdapat 5-6 fase maka
ada 5-6 fase workbench
MENDEFENISIKAN TAKTIK
PENGUJIAN PL (5)
 MENDEFENISIKAN TAKTIK
PENGUJIAN PL (6 )
Contoh : workbench seorang programmer (fase coding) :
Produk input : desain + spec
Procedure to Do : suatu coding yg menghasilkan
program / modul
Procedure to check : pengujian tahap program
(debugging), jika pengecekan ok hasil
dirilis ke workbench berikutnya, jika
not ok produk di rework kembali
 MENDEFENISIKAN TAKTIK
PENGUJIAN PL (7 )
Output : source program / modul yg dirilis
Tools : work : bahasa pemrograman (C, Java, PHP, mysql)
Check : Desk Debugging dan program peer review
(jika pakai SDLC Testing)