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

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

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.

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

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. 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.

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.

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

Testing

Autimated

Testing

Precent

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%

Total hours

1090 277 75%

E. Kualitas Software

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.

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

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

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].

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

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 awi adalah bobot untuk kriteria ici 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 faktorTahap 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 kriteriaTahap 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.

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).

DAFTAR PUSTAKA

S Presman, Roger.2002.Rekayasa Perangkat Lunak Pendekatan Praktisi.Penerbit

Andi:Yogyakarta

Simarmata, Janner.2010.Rekayasa Perangkat Lunak.Penerbit Andi:Yogyakarta