Dasar Dasar TestingRudi Susanto

“Testing merupakan tugas yang tak dapatdihindari ditiap bagian dari tanggung jawab

pengembangan suatu sistem software”

William Howden

1

Obyektifitas Materi

• Memberikan landasan yang cukup dalammemahami dasar-dasar testing (sepertiobyektifitas, prinsip-prinsip dasar testing dantestabilitas).

• Memberikan gambaran secara umum tentangsiklus hidup testing dan integrasinya didalam siklus hidup pengembangan software.

2

Materi :

• ƒObyektifitas Testing

• Misi dari Tim Testing

• Psikologi Testing

• Prinsip – prinsip Testing

• Moto Testing

3

2.1 Obyektifitas Testing

Bagaimana testing yang obyektif?

Secara umum obyektifitas dari testing adalah untukmelakukan verifikasi, validasi dan deteksierror untuk menemukan masalah dan tujuan daripenemuan ini adalah untuk membenahinya.

4

obyektifitas testing | pendapat

• ‰Meningkatkan kepercayaan bahwa sistem dapat digunakandengan tingkat resiko yang dapat diterima.

• Menyediakan informasi yang dapat mencegah terulangnyaerror yang pernah terjadi.

• Menyediakan informasi yang membantu untuk deteksierror secara dini.

• Mencari error dan kelemahan atau keterbatasan sistem.• Mencari sejauh apa kemampuan dari sistem.• Menyediakan informasi untuk kualitas dari produk software

5

2.2 Misi dari Tim Testing

• Apa Misi dari Tim testing?

• Misi dari tim testing tidak hanya untuk melakukan testing, tapi jugauntuk membantu meminimalkan resiko kegagalan proyek.

• Mengeksplorasi, mengevaluasi, melacak, dan melaporkan kualitasproduk, sehingga tim lainnya dari proyek dapat membuatkeputusan terhadap pengembangan produk.

• Penting diingat !! Tester tidak melakukan pembenahan ataupembedahan kode, tidak mempermalukan atau melakukankomplain pada suatu individu atau tim, hanya menginformasikan.

• Tester adalah individu yang memberikan hasil pengukuran darikualitas produk.

6

2.3 Psikologi Testing

Apa keinginan mendasarmu sebagai seorang tester?

Pengembangan dilakukan secara konstruktif, maka testing adalahdestruktif. Seorang pengembang bertugas membangun, sedangkanseorang tester justru berusaha untuk menghancurkan.

Programer harus berorientasi pada “zero defect minded”, maka tester harus mempunyai keinginan yang mendasar untuk “membuktikankode gagal (fail), dan akan melakukan apa saja untuk membuatnyagagal.”

Jadi bila seorang tester hanya ingin membuktikan bahwa kode beraksisesuai dengan fungsi bisnisnya, maka tester tersebut telah gagaldalam menjalankan tugasnya sebagai tester.

7

2.4 Prinsip-Prinsip Testing

• ‰Testing yang komplit tidak mungkin.• Testing merupakan pekerjaan yang kreatif dan

sulit.• Alasan yang penting diadakannya testing adalah

untuk mencegah terjadinya errors.• Testing berbasis pada resiko.• Testing harus direncanakan.• Testing membutuhkan independensi.

8

‰2.4.1 Testing yang komplit tidak mungkin

• Domain masukan yang sangat banyak

• Kompleksitas: bagaimana seorang tester dapat menyatakan suatu bug adalah bug bilahal tersebut ada dalam spesifikasi?

• Jalur Program: terdapat sangat banyak jaluryang mungkin dilewati pada suatu program untuk dites secara komplit

9

Berapa kemungkinan jalur test?

Ada lima Jalur dari A ke X, yaitu: ABCX, ABDEGX, ABDEHX, ABDFIX, danABDFJX

Berapa kemungkinan jalurpengujian?

10

2.4.2 Testing merupakan pekerjaan yang kreatif dan sulit.

• Untuk melakukan testing secara efektif, harusmengetahui keseluruhan sistem.

• Sistem tidak sederhana atau tidak mudahuntuk dipahami

• Melakukan testing dibutuhkan:1.‰Kreatifitas.2.‰Pengetahuan bisnis.‰3.Pengalaman testing.‰4.Metodologi Testing

11

2.4.3 Alasan yang penting diadakannya testing adalah untuk mencegah terjadinya error.

• Konsep siklus dari testing:Testing bukan untuk satu fase pengembangansaja.‰Hasil Testing diasosiasikan pada tiap fasepengembangan.

Aksi pendisainan tes adalah salah satumekanisme yang paling efektif untuk mencegaherror … Proses yang direncanakan untuk dapatdites akan dapat menemukan dan menghilangkanmasalah tiap tahap pengembangan (Beizer 1983)

12

2.4.4 Testing berbasis pada resiko.

• ‰Sumber daya dan biaya yang dibutuhkan untuk melakukantesting berdasarkan pada skala prioritas, kompleksitas dankesulitan testing

• Biaya dari keterlambatan pengiriman produk (dimanasalah satu kemungkinan besar penyebabnya adalah testing)

• Kemungkinan adanya suatu defect (berdasarkanpengalaman beroperasi dan prioritas sejarah terjadinyadefect)

• Biaya yang disebabkan oleh defect, bilamana defect tersebut menyebabkan error yang akan membawa kerugianbaik secara langsung ataupun tak langsung bagi pelanggan(berkaitan dengan kewajiban bisnis bagi pengembangterhadap kerugian yang terjadi pada pelanggan)

13

2.4.5 Testing harus direncanakan

• Testing yang baik butuh pemikiran denganpendekatan secara keseluruhan, disain tes danpenetapan hasil yang diinginkan untuk tiapkasus tes (test case) yang dipilih

14

2.4.6 Testing butuh kebebasan.

• Bila menginginkan adanya pengukuran yang tak bias maka dibutuhkan pula tester yang tak bias.

• Apa yang disebut Tester yang independen (taktergantung/bebas):‰Pengamat yang tidak bias‰Orang yang bertujuan untuk mengukur kualitassoftware secara akurat

• Testing yang paling efektif harus dilakukan oleh pihakketiga. Sangat efektif artinya testing menemukankemungkinan kesalahan yang sangat tinggi.

15

Kunci yang mempengaruhi kinerja dari

testing | 6 prinsip testing

• ‰Wawasan dan kreatifitas tiap individu yang terlibat.

• Pengetahuan dan pemahaman terhadapaplikasi yang dites

• Pengalaman testing

• Metodologi testing yang digunakan

• Usaha dan sumber daya yang dipakai

16

2.5 Moto Testing

• Testing merupakan suatu eksperimen danmembutuhkan suatu pendekatan tertentu.

• hipotesa eksperimen> mendisain eksperimen > eksperimen > data tes dianalisa> apakahhipotesa terbukti? (tipe-tipe dan kuantitasdefect)

17

2.5 Moto Testing

• Test case yang bagus adalah yang mempunyaikemungkinan tinggi dalam mendeteksi defect yang sebelumnya belum ditemukan, bukan yang dapatmemperlihatkan bahwa program telah bekerja denganbenar.

• Tidak mungkin untuk mengetes program Anda sendiri.• Bagian yang dibutuhkan dari tiap test case adalah

deskripsi dari keluaran yang diharapkan.• Jangan pernah mengubah program untuk membuat

testing lebih mudah (kecuali pada perubahan yang permanen).

• Pastikan bahwa testabilitas adalah suatu obyektifitas kuncidalam disain software Anda.

18

SOAL

1. Apa misi dari Tim testing?

2. Hal apa yang tidak boleh dilakukan tester dalam menjalankan tugas?

3. Tester dinyatakan gagal dalam menjalankantugasnya apabila?

4. Kenapa testing yang komplit tidak mungkindilakukan?

19

Jawaban

1. Misi dari tim testing tidak hanya untuk melakukantesting, tapi juga untuk membantu meminimalkanresiko kegagalan proyek

2. Tester tidak melakukan pembenahan ataupembedahan kode, tidak mempermalukan ataumelakukan komplain pada suatu individu atau tim

3. Bila seorang tester hanya ingin membuktikan bahwakode beraksi sesuai dengan fungsi bisnisnya

4. Karena jumlah kemungkinan kombinasi test case yang amat besar.

20

Testabilitas dan Tester

21

2.6 Isu-Isu Seputar Testing

• Sistem itu “Buggy“ yang di akibatkan oleh :

– Sistem pengembangan tidak terencana.

– Sistem pengembangan yang kurang baik danterencana.

• Testing ditampilkan dengan gambaran yang menakutkan

• Batas waktu menjadi hambatan bagi testing

• Testing tidak ditampilkan sebagai suatu karir yangmenjanjikan

• Manajemen pendukung untuk testing kurang dari ideal

• Teknologi baru ataupun lama menyulitkan situasi

22

2.7 Testabilitas

• Testabilitas software adalah seberapa mudah(suatu program komputer) dapat dites.

• Idealnya, perekayasa software mendisainprogram komputer, sistem ataupun produkdengan menempatkan testabilitas dalambenaknya mudah mendisain test case yang efektif dan lebih mudah.

23

Daftar sekumpulan karakteristik software yang dapat di test

Operability

“Semakin baik Software berkerja, akan membuatsoftware dites dengan lebih efisien.”

Observability

“Apa yang Anda lihat, adalah apa yang Anda tes.”

Controllability“Dengan semakin baik kita dapat mengendalikan software,semakin banyak testing dapat diotomatisasi dan

dioptimalisasi.”24

Daftar sekumpulan karakteristik software yang dapat di test

Decomposability“Dengan pengendalian batasan testing, kita dapatlebih cepat dalam mengisolasi masalah danmelakukan testing ulang yang lebih baik.”Simplicity“Semakin sedikit yang dites, semakin cepat kitamelakukannya.”Stability“Semakin sedikit perubahan, semakin sedikitmasalah / gangguan testing.”

25

Daftar sekumpulan karakteristik software yang dapat di test

Understandability

“Semakin banyak informasi yang kita miliki, kita akandapat melakukan tes lebih baik.”

26

Attribut penanda testing yang baik

• Testing yang baik itu bagaimana?

• Suatu testing yang baik mempunyai kemungkinanyang tinggi dalam menentukan error. Tester harusmengerti software dan berusaha untukmengembangkan gambaran dalam benaknya tentangbagaimana kira-kira software akan dapat gagal (fail).

• Suatu tes yang baik tidak tumpang tindih(redundant). Tak ada satupun titik dalampelaksanaan testing yang mempunyai tujuan yang sama dengan testing yang lain.

27

Attribut penanda testing yang baik

• Suatu tes yang baik harus memberikan hasilyang terbaik . Tes yang mempunyaikemungkinan tertinggi dalam memperolehkelas error harus digunakan.

• Suatu tes yang baik harusnya tidak terlalusederhana namun juga tidak terlalu komplek.

28

2.8 Kemampuan Tester yang Diharapkan

• Kemampuan tester yang menjadi permintaan pada umumnya:

– Kemampuan secara umum

• Mempunyai kemampuan analisa yang kuat dan terfokus

• Mempunyai kemampuan komunikasi yang baik

• Mempunyai latar belakang QA

– Pemahaman terhadap metodologi

• Pengembangan rencana tes

• Pembuatan dan perawatan lingkungan tes

• Standar tes

• Dokumentasi tes (seperti test cases dan procedure test)

29

2.8 Kemampuan Tester yang Diharapkan

• Pengetahuan akan pendekatan testing– Integration testing– Acceptance Testing– Stress / Volume Testing– Regression testing– Functional testing– End-To-End Testing– GUI Testing

• Pengetahuan tentang sistem(berhubungan dengan pasar dari organisasi bersangkutan)– Perbankan/Keuangan– Produk Komersial– Telecom– Internet

30

Kemampuan Tester yang Diharapkan

• Pengetahuan dan pengalaman akan penggunaan alat bantu testing

– Alat bantu capture atau playback (seperti WinRunner)

– Alat bantu Load testing (seperti LoadRunner, RoboTest)

• Kemampuan terhadap linkungan testing

– Mainframe (seperti MVS, JCL).

– Client – Server (seperti WinNT, UNIX)

• Kemampuan terhadap aplikasi

– Dokumentasi (seperti office, excel, word, Lorus Notes)

– Database (seperti oracle, access, SQL)

– Pemrograman (seperti C++, VB)

31

Kemampuan Tester yang Diharapkan

• Kemampuan tester dibedakan menjadi tiga grup besar, yaitu :

– Kemampuan fungsional dari subyek yang menjadi acuan

– Basis teknologi

– Teknik – teknik testing dan QA

32

2.9 Personalitas Tester

• Atribut positif yang patut dikembangkan– Terencana, sistematis, dan berhati-hati (tidak sembrono) –

pendekatan logis terhadap testing.– Bermental juara – seperti penerapan standar kualitas yang tinggi

dalam bekerja dalam suatu proyek.– Berpendirian teguh - tidak mudah menyerah– Praktikal – menyadari terhadap apa yang dapat dicapai terhadap

batasan waktu dan anggaran tertentu.– Analitikal – memiliki intiusi dalam mengambil suatu pendekatan

untuk menggali error.– Bermoral baik – berjuang untuk kualitas dan sukses, mengerti dan

menyadari akan biaya-biaya yang terjadi terhadap suatu kulitasyang rendah.

33

2.9 Personalitas Tester

• Atribut negatif yang patut dihindari– Sedikit empati terhadap pengembang (developers) – mudah

terpengaruh secara emosional yang kekanak-kanakan dalamhubungannya dengan pengembang (developers).

– Kurang berdiplomasi – menciptakan konflik dengan pengembang(developers) dengan menunjukan wajah yang tak bersahabat.Seorang tester akan tersenyum bila bertatap muka denganpengembang (developers) saat menemukan defect, danmemberikan laporan defect yang disertai perhitungan statistikterjadinya defect dan bug.

– Skeptis – meminta informasi dari pengembang (developers) denganpenuh kecurigaan (tidak percaya).

– Keras kepala – tidak dapat fleksibel dalam mendiskusikan suatuproposal.

34

Defect Software

35

Defect itu?

1. Defect adalah hal-hal yang tergabung dalamsistem software (dapat ditemukan dalamsoftware, dokumentasi dan tata kerja manual), yang pada awalnya tidak mempunyai dampakapapun, hingga akhirnya mempunyaiberpengaruh pada user/customer danpengoperasian sistem (yang disebut cacat)

2. Defect yang menyebabkan suatu error dalampengoperasian atau berdampak negative padauser/customer disebut Failure

36

13 kategori utama defect dari software*

1. ‰User interface errors - sistem memberikan suatu tampilan yang berbedadari spesifikasi.

2. Error handling – pengenalan dan perlakuan terhadap error bila terjadi.

3. Boundary – related errors - perlakuan terhadap nilai batasan dari jangkauanmereka yang mungkin tidak benar.

4. Calculation errors - perhitungan arimatika dan logika yang mungkin tidakbenar.

5. Initial and later states - fungsi gagal pada saat pertama digunakan atausesudah itu.

6. Control flow errors - pilihan terhadap apa yang akan dilakukan berikutnyatidak sesuai untuk status saat ini.

7. Errors in handling or interpreting data - melewatkan dan mengkonversidata antar sistem (dan mungkin komponen yang terpisah dari sistem) dapatmenimbulkan error.

*Menurut Kaner, Falk, dan Nguyen37

13 kategori utama defect dari software*

8. Race conditions - bila dua event diproses akan maka salah satu akan diterimaberdasarkan prioritas sampai pekerjaan selesai dengan baik, baru pekerjaanberikutnya. Bagaimanapun juga kadang-kadang event lain akan diproses terlebihdahulu dan dapat menghasilkan sesuatu yang tidak diharapkan atau tidak benar.

9. Load conditions - saat sistem dipaksa pada batas maksimum, masalah akan mulaimuncul, seperti arrays, overflow, diskfull.

10. Hardware - antar muka dengan suatu device mungkin tidak dapat beroperasidengan benar pada suatu kondisi tertentu seperti device unavailable.

11. Source and Version Control - program yang telah kadaluwarsa mungkin akandapat digunakan lagi bila ada revisi untuk memperbaikinya.

12. Documentation - pengguna tak dapat melihat operasi yang telah dideskripsikandalam dokumen panduan.

13. Testing errors - tester membuat kesalahan selama testing dan berpikir bahwasistem berkelakuan tak benar.

*Menurut Kaner, Falk, dan Nguyen38

Biaya-Biaya yang Berkaitandengan Testing* dan Defects

*Biaya-biaya testing

39

Biaya-Biaya yang Berkaitandengan Testing dan Defects*

*Biaya-biaya Defects

40

Biaya relatif tahap pengembangan*

*Menurut studi dari Martin dan MC Clure

41

Hubungan usaha testing terhadapbiaya failure.

42

Hubungan usaha testing terhadapbiaya failure.

43

Siklus Hidup Testing

44

Siklus Hidup Software

45

Siklus Hidup Testing

46

Tahap-tahap pengujian V-Model

47

48

Hubungan pengujian dan proses pengembangansystem

SpesifikasiKebutuhan

SpesifikasiSystem

PerancanganSystem

DetailPerancangan

AcceptanceTest plan

System IntegrationTest plan

Sub-System IntegrationTest plan

Module andUnit code and

test

Acceptancetest

System Integration

test

Sub-System Integration

test

Service

Levels of Software Testing

49

Aktifitas Testing

• ‰ Perencanaanƒ -Rencana pendekatan umumƒ -Menentukan obyektivitas testingƒ -Memperjelas rencana umum

• Akusisiƒ -Disain tesƒ -Menerapkan tes ‰

• Pengukuranƒ -Eksekusi tesƒ -Cek terminasiƒ -Evaluasi hasil

50

Tiga Tingkatan Testing secara Umum

• ‰ Unit testingTesting penulisan kode-kode program dalam satuanunit terkecil secara individual.

• System TestingProses testing pada sistem terintegrasi untukmelakukan verifikasi bahwa sistem telah sesuaispesifikasi.

• Acceptance TestingTesting formal yang dilakukan untuk menentukanapakah sistem telah memenuhi kriteria penerimaandan memberdayakan pelanggan untuk menentukanapakah sistem dapat diterima atau tidak

51

Praktik unit testing

• ‰Tujuanƒ Konfirmasi bahwa modul telah dikode dengan benar.

• Pelakuƒ Biasanya programer.

• Apa yang ditesƒ Fungsi (Black Box).ƒ Kode (White Box).Kondisi ekstrim dan batasan-batasan.

• Kapan selesaiƒ Biasanya saat programer telah merasa puas dan tidak diketahui lagikesalahan.

• Alat bantuƒ Tidak biasa digunakan.

• Dataƒ Biasanya tidak didata.

52

Praktik system testing

• Tujuanƒ Merakit modul menjadi suatu sistem yang bekerja. Dan menentukan kesiapan untukmelakukan Acceptance Test.

• Pelakuƒ Pemimpin tim atau grup tes.

• Apa yang ditesƒ Kebutuhan dan fungsi sistem.ƒ Antarmuka sistem.

• Kapan selesaiƒ Biasanya bila mayoritas kebutuhan telah sesuai dan tidak ada kesalahan mayor yangditemukan

• ‰ Alat bantuƒ Sistem pustaka dan pustaka test case.ƒ Generator, komparator dan simulator data testing.

• ‰ Dataƒ Data kesalahan yang ditemukan.ƒ Test case.

53

Praktik acceptance testing

• ‰Tujuanƒ Mengevaluasi kesiapan untuk digunakan.

• Pelakuƒ Pengguna akhir atau agen.

• Apa yang ditesƒ Fungsi mayor.ƒ Dokumentasi.ƒ Prosedur.

• Kapan selesaiƒ Biasanya bila pengguna telah merasa puas atau tes berjalan denganlancar / sukses.

• Alat bantuƒ Komparator.

• Dataƒ Formalitas dokumen.

54

SOAL!

1. Apa yang dimaksud dengan Testtabilitas? 2. Sebutkan kemampuan secara umum yang harus

dimiliki tester! 3. Apa perbedaan testing dalam siklus hidup

pengembangan software, antara pandanganmasa lalu dan sekarang?

4. Sebutkan aktifitas testing secara umum! 5. Sebutkan tiga tingkatan testing secara umum!6. Hal apa saja yang dites pada tingkatan unit

testing!

55

Jawaban!

1. Testtabilitas adalah seberapa mudah (subuah program komputer) dapat dites

2. Mempunyai kemampuan analisa yang kuat danterfokus, mempunyai kemampuan komunikasi yang baik, mempunyai latar belakang QA.

3. Pada masa lalu testing dilakukan setelah tahap coding, tetapi sudut pandang testing sekarang merupakansuatu bagian dan menjadi satu kesatuan di dalamsiklus hidup software secara keseluruhan.

4. Perencanaan, Akusisi, Pengukuran5. Unit testing, System testing, Acceptance testing 6. Fungsi, kode, kondisi ekstrim dan batasan-batasan.

56

Terima kasih

57