1. PROSES TESTING
Testing dan Implementasi Sistem
Dosen : Mei P. Kurniawan
Kelompok 3
Yulia Muharomah 09.12.4156
Zeptifa Wardani 09.12.4132
Ferry Dwi Laksono 09.12.4162
Dwi Sundari 09.12.4125
Tias Arini 09.12.4131
Sekolah Tinggi Ilmu Manajemen dan Komputer AMIKOM Yogyakarta
2012

2. PROSES TESTING
A. Kesalahan Pengujian
1. Fault (Kekeliruan)
Fault merupakan kesalahan pada sebuah baris kode atau lebih. Kesalahan
bisa saja tidak tampak pada program dengan indikasi perangkat lunak
bekerja sebagaimaa harapan pengembang. Bahkan mungkin untuk waktu
yang lama, sebuah baris program bisa saja tidak tersentuh oleh eksekusi
sehingga tidak tampak sebagai kekeliruan.
2. Eror (Kesalahan)
Hal yang akan muncul pada saat terjadi kekeliruan adalah kesalahan. Bila
kekeliruan dalam baris dieksekusi, perangkat lunak akan melakukan
operasi yang tidak sesuai dengan keinginan pengembang sehingga
menghasilkan respons yang salah.
3. Failure (Kegagalan)
Dalam beberapa kasus, kekeliruan akan muncul sebagai kegagalan.
Kegagalan perangkat lunak merupakan sederetan ketidakmampuan
perangkat lunak untuk menjalankan fungsinya. Misalnya kesalahan
keluaran perangkat lunak, proses eksekusi yang tidak normal, waktu
eksekusi dan kapasitas penyimpanan yang membengkak, dan lain-lain.
Kemudian failure masih dibagi lagi, yaitu :
- Requirement faillure
bug yang dilaporkan berhubungan dengan kegagalan sistem untuk
memenuhi kebutuhan.
- Non requirement failure

3. bug yang dilaporkan tidak memenuhi kebutuhan sistem, tetapi secara
signifikan mempengaruhi kualitas sistem dengan cara yang tidak dapat
diterima.
- Waiver failure
bug yang dilaporkan mendeskripsikan kegagalan, tetapi developer menuntut
dan menganggap hal tersebut tidak signifikan mempengaruhi kualitas dan user
experience.
- External failure
bug yang dilaporkan menunjukkan kegagalan karena faktor eksternal atau di
luar kontrol dari sistem yang diuji.
- Test failure
developer meyakini bahwa pengujian yang dikembalikan adalah invalid error.
B. Proses Pengujian Awal
Pengujian kadang-kadang disalah pahami sebagai kegiatan after the fact,
dilakukan setelah pemrograman sebuah produk dilakukan. Namun, pengujian harus
dilakukan setiap tahapan pengembangan produk. Penetapan pengujian data harus
diperoleh, kebenaran dan konsistesinya harus dipantau selama proses pengembangan.
Jika kita membagi siklus hidup pengembangan perangkat lunak menjadi
“Analisis Kebutuhan”,”Desain”,”Pemrograman/Konstruksi” dan “Operasi dan
Pemeliharaan” maka pengujian harus dilakukan di setiap tahapan pengembangan
tersebut jika pengujian menemukan kesalahan dan pernyataan masalah atau desain
bisa mendatangkan biaya terlalu tinggi. Tidak hanya kesalahan utama yang harus
diperbaiki, tetapi seluruh struktur dibangun diatasnya juga harus diubah. Oleh karena
itu, pengujian tidak boleh terisolasi sebagai kegiatan inspeksi, tetapi harus melibatkan
seluruh SDLC untuk menghasilkan produk yang berkualitas.

4. C. Proses Pengujian Akhir
Proses pengujian akhir sulit untuk ditentukan karena kebanyakan aplikasi
perankat lunak modern sangat kompleks dan berjalan sebagai lingkungan
interdependen dan pengujian lengkap pun tidak pernah bisa dilakukan. Kapan
menghentikan pengujian? Menjadi salah satu pertanyaan yang paling sulit bagi
perekayasa penguji. Faktor uum dalam memutuskan untuk berhenti adalah :
1. Tenggat waktu (deadline) yaitu tenggat rilis dan pengujian
2. Kasus-kasus pengujian diselesaikan dengan presentase tertentu yang
dilewatkan
3. Biaya pengujian habis
4. Pemenuhan kode/fungsionalitas/persyaratan menjangkau titik yang telah
ditentukan
5. Tingkat pada bug yang dapat ditemukan terlalu kecil
6. Beta atau pengujian alfa telah berakhir periodenya
7. Risiko dalam proyek dapat diterima dibawah batas.
Pada kenyataannya, keputusan menghentikan pengujian berdasarkan pada
tingkat risiko yang dapat diterima oleh manajemen. Sebagai catatan, pengujian adalah
proses yang tidak pernah berakhir dan tidak pernah mengaggap bahwa pengujian
100% telah selesai, kita hanya dapat meminimalkan risiko pegiriman produk kepada
klien dengan X pengujian yang sudah diselesaikan. Risiko dapat diukur oleh aalisis
risiko, tetapi durasi kecil/anggaran rendah/ randahnya sumber daya proyek, dapat
disimpulkan dengan :
1. Mengukur pemenuhan pengujian

5. 2. Jumlah siklus pengujia
3. Jumlah bug prioritas tinggi
D. Automatic Testing
Otomatisasi testing adalah alat bantu yang digunakan untuk mempermudah proses
dan dokumentasi tes, mengefisienkan eksekusi dari tes, dan mempermudah
pengukuran pada tes. Sehingga diharapkan dapat memberikan peningkatan yang
cukup besar dalam manajemen proses, meminimalkan keterlibatan manusia, dan
replikasi pekerjaan. Otomatisasi testing adalah area yang paling tinggi tingkat
perkembangannya dalam industri testing.
Alasan untuk melakukan otomatisasi proses software adalah untuk meningkatkan
kualitas dan produktifitas kerja. Organisasi membutuhkan suatu strategi otomatisasi
untuk menuntun dalam menggunakan metode-metode dan teknik-teknik baru. Hal ini
membutuhkan pengetahuan tentang apa yang dibutuhkan, pengetahuan terhadap apa
yang fisibel, dan pengembangan suatu rencana yang telah ditetapkan.
Alasan dibutuhkannya otomatisasi testing Mengapa otomatisasi testing
dibutuhkan? Dari uraian singkat di atas, terdapat beberapa alasan pentingnya
melakukan otomatisasi testing, adalah sebagai berikut:
1. Testing selalu diharapkan pada masalah jadwal yang ketat2. Testing sering diulang
- ulang banyak sekali
3. Testing berkemungkinan untuk sijalankan 24 jam sehari, atau tidak pada jam kerja.
4. Testing dapat dilakukan dengan lebih cepat dan akurat, dimana ketidaksonsistenan
manusai dapat diminimalkan.
5. Dokumentasi testing dapat dilakukan secara konsisten, sehingga dapat diaudit
secara penuh dan berkala.

6. 6. Script testing dapat menjadi aset yang dapat digunakan kembali untuk testing yang
sama pada proyek testing yang lain.
7. Mempercepat dalam peninjauan kembali terhadap testing itu sendiri
8. Dapat meningkatkan proses
Dikarenakan ujicoba software menghabiskan sekitar 40% dari total usaha yang
diperlukan untuk sebuah proyek pengembangan software, maka tools tools yang
dapat mengurangi waktu uji sangat dibutuhkan. Dengan melihat manfaat
potensialnya, maka dibentuklah generasi pertama dari automated test tools. Miller
mendeskripsikannya menjadi beberapa kategori, diantaranya :
1. Static Analyzer,
program sistem analisis ini mendukung untuk pembuktian dari pernyataan tanpa
bukti statis, perintah-perintah yang lemah dalam struktur program dan format.
2. Code Auditors,
sebuah filter dengan kegunaan khusus yang digunakan untuk memeriksa kualitas
software untuk memastikan bahwa software tersebut telah memenuhi standars
pengkodean minimum
3. Assertion Processors,
sistem preprocessor/postprocessor ini digunakan untuk memberitahukan programmer
dengan menyediakan klaim, yang disebut assertion, yaitu mengenai suatu perilaku
program yang benar-benar ditemukan saat pelaksanaan program riil.
4. Test File Generators,
merupakan pembangun processor, dan dipenuhi dengan definisi awal nilai, file
masukan yang serupa untuk program yang sedang diujikan.

7. 5. Test Data Generators
merupakan sistem analisis otomatis yang membantu pengguna aplikasi dalam
memilih data uji yang menyebabkan program berperilaku khusus.
6. Test Verifiers,
tool ini mengukur cakupan uji internal, terkadang berhubungan dengan uji struktur
kontrol dari objek uji, dan melaporkan cakupan nilai untuk para ahli jaminan
kualitas
7. Test Harnesses.
Tools ini mendukung pemrosesan uji coba dengan (1) meng-instal program kandidat
dalam lingkungan uji, (2) berikan input data, dan (3) simulasikan dengan
menggunakan stubs perilaku dari modul-modul subordinat.
8. Output Comparators,
tool ini membuatnya sangat memungkinkan untuk membantingkan sekumpulan
output dari suatu program dengan sekumpulan output dari proses sebelumnya(yang
telah diarsipkan) untuk menentukan perbedaan diantara keduanya.
Dunn menambahkan tool otomatis diatas, dantaranya :
1. Symbolic Execution System,
tool ini penampilkan ujicoba program dengan menggunakan input aljabar, dari pada
nilai data numerik,. Software yang diuji akan menguji satu class data uji dari pada
satu kasus uji spesifik. Output yang dihasilkan dalam bentuk aljabar dan dapat
dibandingkan dengan output yang diharapkan yang telah ditulis dalam bentuk aljabar.

8. 2. Environment Simulator,
merupakan tool untuk sistem berbasis komputer khusus, yang mampu untuk menguji
model lingkungan eksternal dari suatu software realtme, dan mensimulasikan kondisi
operasi sesungguhnya secara dinamis.
3. Data Flow Analyzer,
tool ini melacak aliran data yang melewati sistem, dan berusaha untuk
menemukandata reference yang belum didefinisikan , peng-indeks-an yang salah, dan
kesalahan data terkait lainnya.
Manual Testing VS Automated Testing
Test Step Manual Autimated Precent
Testing Testing Improve
Test plan development 32 40 -25%
Test case development 262 117 55%
Test execution 466 23 95%
Test result analyses 117 58 50%
Defect tracking 117 23 80%
Report creation 96 16 83%
1090 277 75%
Total hours
E. Kualitas Software

9. Kualitas Software didefinisikan sebagai kesesuaian yang diharapkan pada
semua perangkat lunak yang dibangun berkaitan dengan fungsi perangkat
lunak yang diutamakan dan untuk kerja perangkat lunak, standar
pembangunan perangkat lunak yang terdokumentasi dan karakteristik yang
ditunjukkan oleh perangkat lunak. Definisi ini menekankan pada tiga hal,
yaitu :
1. Kebutuhan perangkat lunak adalah dasar ukuran kualitas perangkat lunak,
jika perangkat lunak tidak sesuai dengan kebutuhan yang ditentukan,
kualitasnya pun berkurang.
2. Jika menggunakan sebuah standar untuk pembangunan perangkat lunak,
maka perangkat lunak dianggap kurang berkualitas jika tidak memenuhi
standar tersebut.
3. Sering kali ada kualitas yang secara langsung diutarakan (tersurat) seperti
kemudahan penggunaan dan pemeliharaan yang baik. Kualitas perangkat
lunak dipertanyakan jika tidak memenuhi kebutuhan ini.
Sedangkan definisi kualitas menurut The Internasional Standarts Organization
(ISO) adalah totalitas fitur-fitur dan karakteristik-karakteristik dari produk
atau layanan yang berpengaruh pada kemampuan untuk memenuhi kebutuhan
tertentu atau kebutuhan yang tersirat.
Faktor kualitas operasi produk
1. Correcnes
Memperluas sebuah program yang memenuhi spesifikasi dan tujuan pengguna.
2. Portability.

10. Kemudahan pemindahan software ke platform lain. Portability pada software, sangat
tergantung kepada teknologi yang digunakan. Pemilihan teknologi didasari oleh
pertimbangan yang matang berdasarkan hasil analisis terhadap calon pengguna. Jika
calon pengguna menggunakan platform yang heterogen, maka portability adalah hal
yang sangat penting. Namun portability akan berkurang prioritasnya ketika calon
pengguna menggunakan spesifikasi teknologi yang seragam.
3. Reliability.
Software dapat diandalkan untuk melakukan apa yang seharusnya dilakukan.
Reliability adalah atribut yang tidak dapat ditawar. Hal ini dapat dicapai dengan
melakukan proses analisis kebutuhan calon pengguna dengan baik. Dengan
menganalisa masalah calon pengguna, lalu menyimpulkan solusi dari maka engineer
dapat lebih menjamin reliability dari suatu software. Selain dari sisi analisis
kebutuhan, pengujian sistem dengan mekanisme yang baik juga dapat meningkatkan
reliability software. Pengujian sistem adalah fase untuk memastikan bahwa sistem
sudah dapat berjalan sesuai dengan yang diharapkan oleh pengembang perangkat
lunak.
4. Efficiency.
Software dapat melakukan pekerjaan dengan waktu kerja dan penggunaan
resource yang ekonomis. Efficiency adalah atribut yang seringkali tidak diperhatikan.
Umumnya hal tersebut terjadi, karena tim pengembang fokus kepada spesifikasi
fungsional sistem. Ketika spesifikasi fungsional sudah terpenuhi, maka modul
software dianggap telah mencapai kualitas yang baik. Efficiency seringkali tidak
terasa dibutuhkan pada aplikasi sistem informasi yang tidak melakukan proses yang
rumit. Namun untuk proses yang rumit, efficiency menjadi hal yang sangat penting
untuk diperhatikan. Efficiency dapat dicapai dengan disain yang baik dan code
review terhadap hasil implementasi disain yang dilakukan. Selain itu, pada saat

11. pengujian (testing), perlu dilakukan stress testing, suatu proses pengujian yang
menekankan pada kemampuan software pada saat melakukan proses pada keadaan
yang tersulit (contohnya adalah dikarenakan oleh data yang sangat banyak).
5. Maintainabily
Software mudah dipelihara (maintain) dan diubah.
6. Testability.
Software mudah dievaluasi dengan melakukan pengujian (testing). Testability akan
berpengaruh terhadap reliability. Engineer dapat menyimpulkan bahwa suatu
software sudah cukup reliable untuk direlease adalah berdasarkan hasil pengujian.
Karena itu, testability adalah atribut yang sangat penting dalam pengembagan
software.
7. Integrity
Memperluas akses untuk perangkat lunak atau data tanpa diotorisasi dan tidak
dikontrol
8. Fleksibelity
Software mampu untuk beradaptasi dan bekerja dengan efektif sesuai dengan apa
yang dibutuhkan user.
9. Useability
Software mudah dipahami sehingga memudahkan proses pemeliharaan. Usaha yang
dibutuhkan untuk mempelajari, mengoperasikan, mempersiapkan masukan, dan
menerjemahkan keluaran

12. 10. Interoperability
Kemampuan untuk membedakan system dan mengorganisasikan unuk bekerjasama
(inter operate). Dan interfacenya sangat compatible untuk bekerja dengan system
lainnya diwaktu ini ataupun dikemudianhari, tanpa implementasi.
11. Reuseability
Segmen dari sourcecode dapat digunakan kembali untuk menambahkan fungsi baru.
Pengukuran Perangkat Lunak
Pertanyaan pertama yang muncul ketika membahas pengukuran kualitas perangkat
lunak, adalah apa yang sebenarnya mau kita ukur.
Kualitas perangkat lunak dapat dilihat dari sudut pandang proses pengembangan
perangkat lunak (process) dan hasil produk yang dihasilkan (product).
Dan penilaian ini tentu berorientasi akhir ke bagaimana suatu perangkat lunak dapat
dikembangkan sesuai dengan yang diharapkan oleh pengguna. Hal ini berangkat dari
pengertian kualitas (quality) menurut IEEE Standard Glossary of Software
Engineering Technology [3] yang dikatakan sebagai:
The degree to which a system, component, or process meets customer or user
needs or expectation.
Dari sudut pandang produk, pengukuran kualitas perangkat lunak dapat menggunakan
standard dari ISO 9126 atau best practice yang dikembangkan para praktisi dan
pengembang perangkat lunak.
Taksonomi McCall adalah best practice yang cukup terkenal dan diterima banyak
pihak, ditulis oleh J.A. McCall dalam technical report yang dipublikasikan tahun
1977 [1].

13. Di lain pihak, dari sudut pandang proses, standard ISO 9001 dapat digunakan untuk
mengukur kualitas perangkat lunak. Dan diskusi tentang ini berkembang dengan
munculnya tema kajian tentang CMM (The Capability Maturity Model) yang
dikembangkan di Software Engineering Institute, Carnegie Mellon University serta
beberapa kajian lain seperti SPICE (Software Process Improvement and Capability
dEtermination) dan BOOTSTRAP. CMM, SPICE dan BOOTSTRAP mengukur
kualitas perangkat lunak dari seberapa matang proses pengembangannya.
Tulisan ini akan mencoba fokus ke bagaimana mengukur perangkat lunak dilihat dari
sudut pandang produk.
Parameter dan metode pengukuran
When you can measure what you are speaking about, and express it in
numbers, you know something about it. But when you can not measure it,
when you can not express it in numbers, your knowledge is of a meagre and
unsatisfactory kind.
(Lord Kelvin)
Pendekatan engineering menginginkan bahwa kualitas perangkat lunak ini dapat
diukur secara kuantitatif, dalam bentuk angka-angka yang mudah dipahami oleh
manusia. Untuk itu perlu ditentukan parameter atau atribut pengukuran. Menurut
taksonomi McCall, atribut tersusun secara hirarkis, dimana level atas (high-level
attribute) disebut faktor (factor), dan level bawah (low-level attribute) disebut dengan
kriteria (criteria). Faktor menunjukkan atribut kualitas produk dilihat dari sudut
pandang pengguna. Sedangkan kriteria adalah parameter kualitas produk dilihat dari
sudut pandang perangkat lunaknya sendiri. Faktor dan kriteria ini memiliki hubungan
sebab akibat (cause-effect) . Tabel 1 menunjukkan daftar lengkap faktor dan kriteria
dalam kualitas perangkat lunak menurut McCall.
Tabel 1: Faktor dan Kriteria dalam Kualitas Perangkat Lunak

14. Kualitas software diukur dengan metode penjumlahan dari keseluruhan kriteria dalam
suatu faktor sesuai dengan bobot (weight) yang telah ditetapkan. Rumus pengukuran
yang digunakan adalah:
Fa = w1c1 + w2c2 + … + wncn
Dimana:
Fa adalah nilai total dari faktor a
wi adalah bobot untuk kriteria i
ci adalah nilai untuk kriteria i
Kemudian tahapan yang harus kita tempuh dalam pengukuran adalah sebagai berikut:
Tahap 1: Tentukan kriteria yang digunakan untuk mengukur suatu faktor
Tahap 2: Tentukan bobot (w) dari setiap kriteria (biasanya 0 <= w <= 1)
Tahap 3: Tentukan skala dari nilai kriteria (misalnya, 0 <= nilai kriteria <=
10)
Tahap 4: Berikan nilai pada tiap kriteria
Tahap 5: Hitung nilai total dengan rumus Fa = w1c1 + w2c2 + … + wncn
CONTOH PENGUKURAN PERANGKAT LUNAK
Untuk mempermudah pemahaman, akan diberikan sebuah contoh pengukuran
kualitas perangkat lunak dari faktor usabilitas (usability). Yang akan diukur adalah
dua buah perangkat lunak yang memiliki fungsi untuk mengkontrol peralatan
elektronik (electronic device). Perangkat lunak yang pertama bernama
TukangKontrol, sedangkan kedua bernama Caktrol. Contoh dan hasil pengukuran
dapat dilihat pada Table 2 dan 3.

15. Tabel 2: Contoh Pengukuran Usabilitas Dua Perangkat Lunak
Tabel 3: Hasil Pengukuran Usabilitas Dua Perangkat Lunak
Dari penghitungan yang ada di Tabel 3, dapat kita simpulkan bahwa dari faktor
usabilitas, kualitas dari perangkat lunak bernama TukangKontrol lebih baik daripada
Caktrol. Nilai total TukangKontrol untuk faktor usabilitas adalah 16.8, sedangkan
Caktrol adalah 10.2 (dari maksimum total nilai 20).

16. DAFTAR PUSTAKA
S Presman, Roger.2002.Rekayasa Perangkat Lunak Pendekatan Praktisi.Penerbit
Andi:Yogyakarta
Simarmata, Janner.2010.Rekayasa Perangkat Lunak.Penerbit Andi:Yogyakarta