Strategi Testing

Rika Harman, S.Kom.,M.S.I

Strategi Testing Secara Umum

• Strategi testing software mengintegrasikan metodemetode disain test cases

software ke dalam suatu rangkaian tahapan yang terencana dengan baik

sehingga pengembangan software dapat berhasil.

• Strategi menyediakan peta yang menjelaskan tahap-tahap yang harus

dilakukan sebagai bagian dari testing, dan membutuhkan usaha, waktu, dan

sumber daya bilamana tahap-tahap ini direncanakan dan dilaksanakan.

• Strategi testing harus menjadi satu kesatuan dengan perencanaan tes,

disain test case, ekesekusi tes, dan pengumpulan serta evaluasi data hasil

testing.

• Strategi testing software harus cukup fleksibel untuk dapat mengakomodasi

kustomisasi pendekatan testing. Pada saat yang bersamaan, harus juga

cukup konsisten dan tegas agar dapat melakukan perencanaan yang

masuk akal dan dapat melakukan manajemen perkembangan kinerja

proyek.

Pendekatan Strategi Testing

1. Sejumlah strategi testing software diadakan untuk menyediakan kerangka

testing bagi pengembang software dengan karekteristik umum sebagai

berikut:

a. Testing dimulai dari tingkat komponen terkecil sampai pada integrasi

antar komponen pada keseluruhan sistem komputer tercapai.

b. Teknik testing berbeda-beda sesuai dengan waktu penggunaannya.

c. Testing dilakukan oleh pengembang software dan (untuk proyek

besar) dilakukan oleh suatu grup tes yang independen.

d. Testing dan debugging adalah aktifitas yang berlainan, tapi

debugging harus diakomodasi disetiap strategi testing.

Verifikasi & Validasi

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

2. Menurut Boehm [BOE81]:

a. Verifikasi “Are we building the product right?”

“Apakah sistem yang dikembangkan sudah benar = melakukan pengujian

terhadap sistem apakah sudah sesuai dengan yang diharapkan”

b. Validasi “Are we building the right product?”

c. Apakah sistem dikembangkan dengan cara yang

benar=melakukan pengujian apakah sistem sudah sesuai dengan

spesifikasinya

3. 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 [WAL89]. Walaupun testing memainkan

peran yang sangat penting dalam V & V, namun masih diperlukan

aktifitasaktifitas yang lainnya.

a. Testing merupakan basis terakhir dimana kualitas dapat dinilai dan error

dapat diidentifikasi.

b. Tapi testing tidak boleh dipandang sebagai jaring pengamanan.

c. “Anda tidak dapat melakukan tes terhadap kualitas. Jika kualitas tidak ada

sebelum Anda memulai testing, maka kualitas juga tidak akan ada saat

Anda selesai melakukan testing.”

d. Kualitas dibangun ke dalam software sepanjang proses rekayasa software.

e. Penerapan dari metode-metode dan alat-alat bantu, formal technical

review yang efektif, menejemen dan pengukuran yang solid mengarahkan

pada kualitas yang dikonfirmasikan pada saat pelaksanaan testing

berlangsung.

f. Miller [MIL77] menghubungkan testing software terhadap jaminan kualitas

dengan menyatakan bahwa “ motivasi yang patut digaris bawahi dari

testing adalah untuk memberikan dukungan kualitas software dengan

metode-metode yang dapat diaplikasikan secara ekonomis dan efektif baik

pada sistem berskala besar atau sistem berskala kecil

Pengorganisasian testing software

1. Mengurangi resiko terjadinya konflik, dan mempersiapkan diri bilamana

konflik tetap terjadi.

2. Ada sejumlah konsepsi salah, yang akan mempengaruhi diskusi

sebelumnya menjadi salah jalan, yaitu:

a. Pengembang software tidak perlu melakukan testing sama sekali.

b. Software diberikan pada orang lain (tak dikenal kredibilitasnya), yang

akan melakukan tes pada software tersebut tanpa pemahaman dan

salah arah.

c. Tester baru bekerja atau ikut serta ke dalam proyek, hanya bilamana

tahap testing pada proyek tersebut dimulai.

Strategi Testing

System TestingValidation TestingIntegration Testing

Unit Testing

Code

DesignRequirements

System Engineering

Tahapan Testing

UnitTest

IntegrationTest

Higt-OrderTest

Testing“Direction”

Code

Design

Requirements

Kriteria pemenuhan testing

“Kapan kita dapat menyelesaikan testing – bagaimana kita

dapat mengetahui apa yang dites telah cukup?”

Isu-Isu Strategi Testing

a. Betapapun bagusnya strategi testing akan gagal jika serangkaian isu-isu

strategi testing berikut ini tidak dipertimbangkan dengan baik.

b. Tom Gilb [GIL95] memberikan argumentasinya terhadap isu-isu tersebut,

agar strategi testing software dapat diimplementasikan dengan sukses.

a. Spesifikasi kebutuhan produk agar dapat dikuantisasi, harus ditetapkan

jauh sebelum testing dimulai. Walau obyektifitas testing adalah untuk

menemukan errors, suatu strategi yang bagus juga menilai karakteristik

kualitas, seperti portabilitas, maintainabilitas, dan usabilitas Dimana hal

usabilitas. ini seharusnya dispesifikasikan dengan suatu cara tertentu yang

dapat diukur, sehingga hasil testing tidak membingungkan.

b. Nyatakan obyektifitas testing secara eksplisit. Obyektifitas testing tertentu

harus dinyatakan dalam bentuk yang dapat diukur. Contoh, efektifitas tes,

cakupan tes, waktu error rata-rata, biaya untuk menemukan dan

memperbaiki error, frekuensi terjadinya error, dan jam kerja tes per tes

regresi, yang kesemuanya harus dinyatakan di dalam rencana tes [GIL95].

• Memahami pengguna software danmengembangkan profil untuk tiap

kategori pengguna. Use-cases yang menjelaskan skenario interaksi untuk

tiap kelas pengguna dapat mengurangi usaha testing keseluruhan dengan

fokus pada penggunaan aktual dari produk.

• Mengembangkan rencana testing yang berdasar pada “rapid cycle

testing”. Gilb [GIL95] merekomendasikan tim perekayasa software untuk

belajar melakukan tes pada siklus yang ketat (2 persen dari usaha proyek)

dari penggunaan pelanggan. Umpan balik yang dihasilkan dapat digunakan

untuk mengendalikan tingkat kualitas dan strategi tes yang bersangkutan.

• Membuat software yang tegar (robust), yang didisain untuk melakukan

tes dirinya sendiri. Software seharusnya didisain dengan menggunakan

teknik antibugging. Sehingga software dapat mendiagnosa klas-klas klas

error tertentu. Sebagai tambahan, disain seharusnya mengakomodasi

otomatisasi testing dan regression testing.

• Gunakan Formal Technical Review (FTR) yang efektif sebagai filter

testing tertentu. FTR dapat seefektif testing dalam mencakup error.

Dengan alasan ini, review dapat mengurangi sejumlah usaha testing, yang

dibutuhkan untuk menghasilkan software berkualitas tinggi.

• Lakukan Formal Technical Review untuk menilai strategi tes dan test

cases itu sendiri. FTR dapat mencakup ketidakkonsistenan,

penyimpangan dan error dari pendekatan testing. Hal ini akan menghemat

waktu dan mengembangkan kualitas produk.

• Kembangkan pendekatan pengembangan yang berkelanjutan untuk

proses testing. Strategi tes harus diukur. Pengukuran yang dikumpulkan

selama testing harus digunakan sebagai bagian dari pendekatan kendali

proses secara statistik untuk testing software.

Unit Testing

a. Unit testing berfokus pad usaha verifikasi pada unit terkecil dari disain

software – komponen atau modul software.

b. Penggunaan diskripsi disain tingkat komponen sebagai tuntunan, jalur

kendali yang penting dites untuk menemukan errors, terbatas pada modul

tersebut.

c. Kompleksitas relatif terhadap tes dan errors yang dicakup dibatasi oleh

batasan-batasan dari cakupan yang telah ditetapkan pada unit testing.

d. Unit testing berorientasi white box, dan tahapan dapat dilakukan secara

paralel pada banyak komponen.

Hal-hal yang perlu diperhatikan pada unit testing

1. Tes yang terdapat pada unit testing:

a. Modul antar muka dites untuk memastikan aliran informasi telah berjalan

seperti yang diharapkan (masuk dan keluar dari unit program yang dites).

b. Struktur data lokal diperiksa untuk memastikan penyimpanan data telah

merawat integritasnya secara temporal selama tahap eksekusi algoritma.

c. Batasan kondisi dites untuk memastikan modul beroperasi dengan benar

pada batasan yang telah ditetapkan untuk limitasi atau batasan pemrosesan.

d. Semua jalur independen (basis paths) pada struktur kendali diperiksa untuk

memastikan semua pernyataan dalam modul telah dieksekusi minimal sekali.

e. Semua jalur penanganan kesalahan dites.

f. Tes aliran data antar modul dibutuhkan sebelum inisialisasi tes lainnya. Jika

data tidak masuk dan keluar dengan benar, semua tes lainnya disangsikan.

Sebagai tambahan, struktur data lokal harus diperiksa dan akibat pada data

global ditentukan (jika memungkinkan) selama unit testing.

g. Pemilihan jalur eksekusi testing adalah tugas yang esensial selama unit

test. Test cases harus didisain untuk mencakup kesalahan dari komputasi

yang salah, komparasi yang tak benar atau alur kendali yang tak tepat.

Basis path dan loop testing adalah teknik yang efektif untuk hal ini.

• Kesalahan komputasi yang umum terjadi:Kesalahan prioritas aritmetik.Mode operasi campuran. Inisialisasi tak benar.Ketidakakuratan presisi.Ketidakbenaran representasi simbolik dari ekspresi.

• Komparasi dan alur kendali merupakan satu kesatuan. Biasanya perubahan alur kendali terjadi setelah komparasi.

1. Test case harus mencakup kesalahan:

a. Komparasi tipe data berbeda

b. Operator logika dan prioritas yang tak benar

c. Kemungkinan persamaan jika kesalahan presisi menjadikan presisi,

hasil dari persamaan tidak sebagaimana yang diharapkan.

d. Kesalahan komparasi antar variabel.

e. Terminasi loop yang tidak konsisten atau tidak semestinya.

f. Kegagalan keluar bilamana konflik iterasi terjadi.

g. Modifikasi variabel loop yang tidak semestinya.

2. Disain yang baik meliputi kondisi kesalahan yang diantisipasi dan jalur penanganan

kesalahan diset untuk dapat digunakan kembali atau proses pembersihan pada terminasi

saat kesalahan terjadi. Pendekatan ini disebut sebagai antibugging oleh Yourdon

[YOU75].

3. Kesalahan potensial yang harus dites saat evaluasi penanganan kesalahan:

a. Diskripsi kesalahan tidak jelas.

b. Catatan kesalahan tidak berfungsi untuk menghitung kesalahan.

c. Kondisi kesalahan menyebabkan interfensi sistem terhadap penangan kesalahan

tertentu.

d. Pemrosesan kondisi perkecualian tidak benar.

e. Diskripsi kesalahan tidak menyediakan informasi yang cukup untuk mengarahkan

penyebab kesalahan.

4. Batasan testing adalah tugas terakhir dari unit testing. Softwarekadang

gagal terhadap batasannya. Kesalahan kadang terjadi ketika elemen ke n

dari dimensi array ke n diproses, ketika repetisi ke i dari loop dilakukan,

ketika nilai maksimum dan minimum dihitung.

Prosedur-prosedur unit test

a. Setelah kode dikembangkan, dan diverifikasi terhadap p tingkat disain

komponen bersangkutan, disain test case dari unit test dimulai

b. Review informasi disain menyediakan tuntunan untuk menetapkan test

cases agar dapat mendekati keseluruhan cakupan kesalahan di tiap

kategori sebagaimana didiskusikan sebelumnya.

c. Tiap test case harus dihubungkan dengan hasil yang diharapkan.

• Karena komponen bukan program yang berdiri sendiri, drivers dan atau

stubs software harus dikembangkan untuk tiap unit test.

a. Pada kebanyakan aplikasi drivers tidak lebih dari “program utama”

yang menerima data test case, memasukkan data ke komponen yang

dites, dan mencetak hasil yang bersangkutan.

b. Stubs berlaku untuk menggantikan modul-modul yangmerupakan

subordinat (dipanggil oleh) komponen yang dites. Stub atau “dummy

subprogram” menggunakan antar muka modul subordinat, mungkin

melakukan manipulasi data minimal, mencetak masukan verifikasi, dan

mengembalikan kendali ke modul yang sedang dites.

• Drivers dan stubs menimbulkan biaya overhead. Karena software harus ada

penambahan kode (biasanya tidak berdasarkan disain formal), yang tidak

diikutsertakan saat produk software dirilis.

• Bila drivers dan stubs cukup sederhana, overhead yang sebenarnya

menjadi relatif rendah.

• Namun pada kenyataannya, kebanyakan komponen tidaklah cukup bila

hanya dilakukan tes dengan overhead yang rendah (sederhana).

• Pada kasus-kasus tertentu, testing dapat ditunda penyelesaiannya (kondisi

komplit) sampai tahap integration test (dimana drivers atau stubs juga

digunakan).

• Unit testing disederhanakan bila suatu komponen didisain dengan kohesi

tinggi.

• Bilamana hanya satu fungsi yang dialamatkan oleh suatu komponen, jumlah

test cases dapat dikurangi dan errors dapat lebih mudah untuk diprediksi

dan dicakup

• Ada beberapa situasi dimana sumber daya tidak mencukupi untuk

melakukan unit testing secara komplit.

• Untuk itu perlu melakukan pemilihan modul modul yang kritis dan yang

mempunyai cyclomatic complexity tinggi, untuk unit testing.