Strategi testing software berfokus pada empat tahapan yaitu unit testing, integration testing, validation testing, dan system testing. Unit testing memeriksa fungsi komponen secara individual, integration testing mengintegrasikan komponen, validation testing memastikan kesesuaian dengan kebutuhan, dan system testing menguji seluruh sistem. Terdapat berbagai teknik testing sesuai dengan tahapan dan tingkat abstraksi yang diuji.

1. Strategi Testing

2. Apa beda pintar & cerdas?
Pintar = menang di atas kertas.
Cerdas = menang di lapangan

3. Kerangka Testing Software
• Kerangka testing software, yaitu suatu kumpulan tahapan yang terbentuk
dari teknik disain test case dan metode testing tertentu, harus didefinisikan
untuk proses dari software.

4. Sejumlah strategi testing software diadakan untuk menyediakan kerangka
testing bagi pengembang software dengan karekteristik umum sebagai berikut:
1. ‰Testing dimulai dari tingkat komponen terkecil sampai pada integrasi antar
komponen pada keseluruhan sistem komputer tercapai.
2. ‰Teknik testing berbeda-beda sesuai dengan waktu penggunaannya.
3. ‰Testing dilakukan oleh pengembang software dan (untuk proyek besar)
dilakukan oleh suatu grup tes yang independen.
4. ‰Testing dan debugging adalah aktifitas yang berlainan, tapi
debugging harus diakomodasi disetiap strategi testing.
Pendekatan Strategi Testing

5. • Suatu strategi testing software harus mengakomodasi testing pada tingkat
rendah yang dibutuhkan untuk verifikasi suatu segmen source code kecil,
apakah telah diimplementasi dengan benar. Demikian juga halnya testing
pada tingkat tinggi yang digunakan untuk validasi fungsi-fungsi sistem
mayor terhadap kebutuhan / permintaan pelanggan.
• Suatu strategi harus menyediakan tuntunan bagi praktisioner dan
sekumpulan batasan pencapaian bagi manajer. Karena tahap-tahap dari
strategi testing biasanya terjadi pada waktu dimana tekanan batas waktu
mulai muncul, perkembangan kinerja harus dapat diukur dan masalah harus
diidentifikasi sedini mungkin.

6. • Testing software sering dikaitkan dengan verifikasi dan validasi (V & V).
Dimana verifikasi merupakan sekumpulan aktifitas yang memastikan
software telah melakukan fungsi tertentu dengan benar. Sedangkan
validasi merupakan sekumpulan aktifitas berbeda dari verifikasi yang
memastikan bahwa software yang dibangun dapat dilacak terhadap
kebutuhan / permintaan pelanggan.
Verifikasi dan validasi

7. Menurut Boehm :
Verifikasi “Are we building the product right?”
“Apakah kita telah membuat produk dengan benar?”
Validasi “Are we building the right product?”
“Apakah kita telah membuat produk yang benar?”

8. • V&V meliputi kebanyakan aktifitas SQA, yaitu:
✓ formal technical review,
✓ audit konfigurasi dan kualitas,
✓ pemonitoran kinerja,
✓ simulasi,
✓ studi fisibilitas,
✓ review dokumentasi,
✓ review database,
✓ analisa algoritma,
✓ testing pengembangan,
✓ testing kualifikasi, dan
✓ testing instalasi.

9. • Pada setiap proyek software, biasanya akan terjadi konflik kepentingan yang
berbeda-beda di saat testing dimulai.
• Umumnya, testing software dilakukan oleh pengembang software itu
sendiri.
Pengorganisasian testing software

10. • Pengembang software selalu bertanggung jawab untuk
✓ melakukan testing unit (komponen) program,
✓ memastikan tiap unit berfungsi sebagaimana pada disain
✓ Melakukan testing struktur program secara keseluruhan

11. • Grup tes independen adalah bagian dari tim proyek pengembangan
software yang akan ikut serta selama aktifitas spesifikasi dan terus ikut
(perencanaan dan spesifikasi prosedur tes) sepanjang suatu proyek yang
besar.
• Laporan grup tes independen dalam banyak kasus diberikan pada
organisasi SQA, dan independensi tak akan tercapai bila masih berada di
dalam bagian organisasi rekayasa software.

12. • Tujuan dari grup tes independen adalah :
✓ Untuk menghindari masalah-masalah yang berkaitan dengan
membiarkan pembuat melakukan tes hal yang telah dibuatnya sendiri.
✓ Untuk menghindari konflik antar kepentingan.
✓ Untuk menemukan kesalahan yang terjadi pada software

13. Proses rekayasa software dapat dipandang sebagai suatu spiral
sebagaimana diilustrasikan pada gambar.
Pada awalnya, rekayasa sistem mendefinisikan tugas software
dan mengarahkan pada analisa kebutuhan software, dimana domain kriteria
informasi, fungsi, tingkah laku, kinerja, hambatan, dan validasi software telah
ditetapkan. Bergerak ke dalam sepanjang spiral, dari disain hingga berakhir
pada coding. Dalam pengembangan software komputer, proses bergerak dari
luar ke dalam mengikuti jalur spiral yang akan menurunkan tingkat abstraksi di
setiap belokan.
Strategi testing software

15. Tahapan Testing Software
Proses dari sudut pandang prosedural, testing dalam kontek rekayasa
software sebenarnya merupakan rangkaian dari empat tahapan yang
diimplementasikan secara sekuensial, sebagaimana diperlihatkan pada
gambar. Pada awalnya, fokus tes terletak pada tiap komponen secara
individual, memastikan apakah fungsi dari komponen tersebut dapat
dikategorikan sebagai suatu unit. Oleh karena itu diberi nama unit testing.
Unit testing akan sangat banyak menggunakan teknik white box testing,
memeriksa jalur tertentu dalam suatu struktur kendali dari modul untuk
memastikan cakupan yang komplit dan deteksi error yang maksimum.
Selanjutnya, komponen-komponen harus disusun atau diintegrasikan
sampai pada bentuk paket software yang komplit.

16. Tahapan Testing Software

17. Tahapan Testing Software
Unit testing  unit yang fokus tes terletak pada tiap komponen secara
individual
Tugas unit testing  memastikan apakah fungsi dari komponen tersebut
dapat dikategorikan sebagai suatu unit.
Unit testing akan sangat banyak menggunakan teknik white box testing,
memeriksa jalur tertentu dalam suatu struktur kendali dari modul untuk
memastikan cakupan yang komplit dan deteksi error yang maksimum.
Selanjutnya, komponen-komponen harus disusun atau diintegrasikan
sampai pada bentuk paket software yang komplit.

18. Tahapan Testing Software
Integration testing  berkaitan dengan hal-hal yang berhubungan dengan
masalah-masalah verifikasi dan konstruksi program.
Teknik disain test case black box lebih dominan dipakai selama integrasi,
walaupun demikian sejumlah tertentu white box testing akan juga digunakan
untuk memastikan cakupan dari jalur kendali mayor. Setelah software telah
diintegrasikan (dikonstruksi), sekumpulan tes tingkat tinggi dilakukan.

19. Tahapan Testing Software
Kriteria validasi (ditetapkan dalam analisa kebutuhan), harus dites.
Validation testing  merupakan bagian akhir yang memastikan software telah
memenuhi semua fungsional, tingkah laku, dan kinerja sebagaimana yang
diharapkan. Teknik black box testing digunakan secara eksklusif selama
validasi.

20. Tahapan Testing Software
Tahapan terakhir, high-order testing, berada di luar daerah rekayasa
software dan masuk ke dalam kontek yang lebih luas dari rekayasa sistem
komputer.
System testing melakukan verifikasi bahwa semua elemen terikat satu
dengan yang lain sebagaimana mestinya, dan keseluruhan fungsi / kinerja
sistem dicapai.
Saat validasi software, harus dikombinasikan dengan elemen sistem
yang lain (seperti hardware, manusia, databases).

21. Pertanyaan klasik yang muncul setiap waktu saat
mendiskusikan testing software, “Kapan kita dapat
menyelesaikan testing – bagaimana kita dapat mengetahui
apa yang dites telah cukup?” Sayangnya, tak ada
jawaban yang definitif untuk pertanyaan ini, namun
ada beberapa respon pragmatis dan tuntunan empiris.
Kriteria pemenuhan testing

22. Salah satu respon pragmatis, menyatakan : “Anda tak akan
pernah menyelesaikan testing, cara yang sederhana,
adalah memindahkan tanggung jawab testing dari anda
(perekayasa software) ke pelanggan anda.” Setiap waktu
pelanggan / pengguna mengeksekusi suatu program
komputer, maka program telah dites. Karena hal inilah
dibutuhkan adanya aktifitas lain dari SQA.

23. Musa dan Ackerman [MUS89] mengembangkan suatu model kesalahan software (yang didapat
selama testing) sebagai fungsi dari waktu eksekusi, dengan berdasarkan pada pemodelan
statistik dan teori reliabilitas. Model ini disebut sebagai logarithmic Poisson execution-time
model, dengan bentuk:
f(t) = (1 / p) ln (l0 p t + 1)
dimana f(t) = Jumlah error kumulatif yang diharapkan terjadi saat software di tes
untuk suatu waktu eksekusi, t.
l0 = Inisial dari intensitas error dari software (error per unit waktu) saat awal testing.
P = Pengurangan secara eksponensial intesitas error saat error telah diperbaiki.
Intensitas error, l(t) dapat diturunkan dengan menurunkan derivasi dari f(t):
l(t) = l0 / (l0 p t + 1)

24. • Dengan manggunakan persamaan l(t) di atas, tester dapat memprediksi
turunnya errors dari hasil kinerja proses testing. Intensitas error aktual
dapat di-plot terhadap kurva prediksi (gambar 4.3). Jika, karena alasan
tertentu yang masuk akal, data aktual yang didapat selama testing dan
logarithmic Poisson execution time model, berdekatan antar satu dengan
yang lainnya di tiap titik data, maka model tersebut dapat digunakan untuk
memprediksi total waktu testing yang dibutuhkan untuk mencapai intensitas
error yang rendah dan dapat diterima.

25. • Dengan pengumpulan data pengukuran selama testing software dan
pembuatan model reliabilitas software yang ada, memungkinkan untuk
mengembangkan tuntunan yang berarti untuk menjawab pertanyaan:
“Kapan kita dapat menyelesaikan testing?” Walaupun masih terdapat
perdebatan, namun pendekatan empiris yang ada ini lebih baik
untuk dipertimbangkan pemakaiannya, daripada hanya berdasarkan pada
intuisi secara kasar.

27. TERIMA KASIH