Catatan pertemuan 3 testing

Prinsip-prinsip testing.

1. Testing yang komplit (dilakukan secara meyeluruh) tidak memungkinkan dilakukan

Maka dari itu menggunakan prinsip pareto(20% 80%) karena batasan waktu.
a. Kombinasi testcase yang besar (semakin banyak kombinasi input yang akan dihasilkan maka
semakin besar testcasenya)
 Pertimbangan domain masukan yang mungkin sangat besar jumlahnya (masukan
yang valid, tidak valid, masukan yang diedit, dll)
 Kompleksitas user interface dan desain. Semakin kompleks UI yang dihasilkan maka
akan semakin sulit testing secara menyeluruh.
 Jalur program (flow graph) yang mungkin dapat dilewati sangat banyak
b. Harus dilakukan test ulang, setiap ada perbaikan pada masing-masing bug
Yang sifatnya major ditest dari awal setelah diperbaiki oleh developer. Hanya modul yang
salah saja, jika modul saling berintegrasi maka harus diuji lagi.

2. Testing merupakan pekerjaan yang kreatif dan sulit

Mitos yang salah tentang testing :
a. Testing itu mudah. Hal ini sering dibicarakan oleh programmer.
b. Tiap orang dapat melakukan testing dengan sendirinya padahal testing bukanlah hal yang
sederhana karena
 Untuk dapat melakukan testing yang efektif harus mengetaui keseluruhan sistem.
Harus mengetahui alur sistem, harus memahami coding, harus mengetahui proses
bisnis
 Sistem sendiri tidak sederhana (mudah dipahami).
Sistem tidak sederhana. Sistem harus didokumentasikan setelah jadi untuk
mempermudah pemeliharaan sistem.

3. Testing berbasis pada resiko, walaupun testing secara keseluruhan tidak dapat dilakukan, tidak
berarti bahwa testing yang efektif tidak dapat dilakukan testing merupakan hasil pertimbangan
risiko dan ekonomi. Pengujian ini memprioritaskan pengujian fitur dan fungsi pada PL
berdasarkan fungsi kegagalan, fungsi kepentingan, kemungkinan dan dampak kegagalan PL.
Testing dipengaruhi oleh berbagai pertimbangan :
a. Sumber daya dan biaya yang dibutuhkan untuk melakukan testing menurut skala prioritas
(menentukan skala prioritas, dari sisi ekonomi, waktu, sumber daya, dsb), kompleksitas
(kalau sumber daya dan biaya terbatas maka testcase tidak perlu banyak atau kompleks),
dan kesulitan testing
b. Biaya dari keterlambatan pengiriman produk (kemungkinan besar disebabkan testing)
Harus tepat waktu dan tiak boleh terlambat. Jika terlambat maka produk tidak bisa diclose.
Terlalu banyak atau terlalu detail menguji maka produk / proyek akan terlambat.
Seorang tester harus jeli akan berapa lama waktu yang diberikan untuk menguji.
c. Kemungkinan adanya suatu defect.
Mencari modul yang paling banyak defect yang kira-kira paling berpengaruh dan merugikan
oleh user. Jangan sampai user yang menemukan defect tersebut.
 Defect diperbaiki oleh programmer. Jika tidak ada waktu untuk menyelesaikan defect
tersebut maka proyek akan gagal. Apakah defect harus diperbaiki atau tidak, apakah jika
diperbaiki malah berdampak lebih besar pada user.

d. Biaya yang disebabkan oleh defect, bilamana defect tersebut menyebabkan error yang
membawa kerugian langsung maupun tak langsung bagi user.

4. Testing harus direncanakan butuh pemikiran dengan pendekatan secara keseluruhan, desain tes
dan penetapan hasil yang diinginkan untuk setiap kasus tes (test case) yang dipilih
a. Test plan : dokumen yang mencakup keseluruhan tujuan testing dan pendekatan testong
b. Test design : dokumen yang mendefiniskan apa yang telah dipilih untuk dites dan hasil yang
diharapkan test direncanakan dan didesain sebelum kode dibuat.

Perencanan test sangat penting yaitu :

a. Untuk dapat menjaga arah pelaksanaan tes agar tidak menyimpang dari tujuan tes itu
sendiri (mengukur kualitas SW). Fokus pada prioritas (harus tertuju pada test plan dan test
design untuk membuat test case). Karena tester mencari kesalahan sebanyak-banyaknya
sekreatif mungkin sehingga tester menguji modul yang lain yang tidak perlu diuji.
b. Menjagakesesuaian penggunaan sumber data dan jadwal proyek dengan menetapkan apa
yang akan dites dan kapan berhenti
c. Membatu tester fokus terhadap apa yang akan dites (membuat tes case)

5. Testing butuh independensi (tidak terpengaruh pada yang lain), testing yang paling efektif
adalah yang dilakukan oleh pihak ketiga.
Pihak pertama : developer sistem.
Pihak kedua = user / project sponsor (orang yang memberikan proyek tersebut = orang yang
menginisiasi proyek terebut harus dilakukan)
Pihak ketiga = tester.
Tester tidak boleh dari pihak pertama karena memungkinkan tidak bias atau tidak dapat
menemukan kesalahan dari proyek yang dibuat.
Tester memiliki sudut pandang sebagai tester, dengan merusak sistem hingga mencari
masalahnya.

Testability : variable / aspek yang bisa dilihat dari perangkat lunak mudah diuji atau tidak, bisa diuji atau
tidak.

a. Operability : semakin baik sistem bekerja, semakin efisien sistem di test. Perangkat lunak yang
baik dari keseluruhan fungsinya, semakin baik perangkat lunak maka makin efisien dan mudah
diuji.
b. Observability : apa yang dilihat adalah apa yang diuji. Tidak boleh membandingkan dengan
perangkat lunak yang lain.
 c. Controllability : semakin baik software dapat dikontrol, testing semakin dapat diotomasi dan
lebih optimal. Terkait dengan operability.
d. Decomposability : dengan mengontrol scope dari testing, kita dapat mengisolasi masalah lebih
cepat dan melakukan testing ulang dengan lebih smart.
Harus paham apa saja fungsi dan modul dari perangkat lunak yang diuji.
Semakin mudah sistem itu mudah dipahami modulnya maka akan semakin mudah diuji.
Jika sistem sulit dipahami dan tidak ada batasan maka akan sulit untuk diuji.
e. Simplicity : semakin sedikit yang dites, semakin cepat kita dapat melakukan pengetesan.
Semakin mudah sistem tersebut maka semakin mudah diuji.
f. Stability : semakin sedikit perubahan, semakin sedikit gangguan terhadap pengetesan
Memastikan sistem sudah selesai, tidak ada perubahan. Jika sistem diupdate bisa jadi tester
menguji ulang dari awal.
g. Understanbility : semakin banyak informasi (seperti dari aplikasi sejenis yang pernah diuji) yang
didapatkan, semakin smart kita melakukan teting

Good testing

Testing dikatakan baik jika :

1. Keungkinan mendapatkan masalah tinggi. Yang sifat nya major. Berlomba-lomba mencari
masalah
2. Tidak redudan -> resource terbatas, tiap tes yang dilakukan harus memiliki tujuan yang berbeda.
Modul hanya cukup diuji satu kali tidak perlu diuji berulang-ulang karena akan memakan banyak
waktu.
3. Test case tidak terlalu simple atau tidak terlalu kompleks.