Testing dan Implementasi Sistem Dasar-dasar Testing

Isu-Isu Seputar Testing Sistem itu “Buggy“ yang di akibatkan oleh : Sistem pengembangan tidak terencana. Sistem pengembangan yang kurang baik dan terencana. Testing ditampilkan dengan gambaran yang menakutkan Batas waktu menjadi hambatan bagi testing Testing bukan organisasi dan ilmu Testing tidak ditampilkan sebagai suatu karir yang menjanjikan Teknologi baru ataupun lama menyulitkan situasi

Testabilitas Idealnya, perekayasa software mendisain program komputer, sistem ataupun produk dengan menempatkan testabilitas dalam benaknya. Hal ini akan memungkinkan untuk membantu testing dalam mendisain test case yang efektif dan lebih mudah. Secara sederhana, menurut James Bach, testabilitas software adalah seberapa mudah (suatu program komputer) dapat dites. Kadang-kadang programer mau membantu proses testing dan suatu daftar item disain yang mungkin, fitur, dan lain-lain, akan sangat membantu jika dapat bekerja sama dengan mereka.

Daftar sekumpulan karakteristik software yang dapat di test Operability “Semakin baik Software berkerja, akan membuat software 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.”

Daftar sekumpulan karakteristik software yang dapat di test Decomposability “Dengan pengendalian batasan testing, kita dapat lebih cepat dalam mengisolasi masalah dan melakukan testing ulang yang lebih baik.” Simplicity “Semakin sedikit yang dites, semakin cepat kita melakukannya.” Stability “Semakin sedikit perubahan, semakin sedikit masalah / gangguan testing.”

Daftar sekumpulan karakteristik software yang dapat di test Understandability “Semakin banyak informasi yang kita miliki, kita akan dapat melakukan tes lebih baik.”

Attribut penanda testing yang baik Suatu testing yang baik mempunyai kemungkinan yang tinggi dalam menentukan error. Untuk mencapai tujuan ini, tester harus mengerti software dan berusaha untuk mengembangkan gambaran dalam benaknya tentang bagaimana kira-kira software akan dapat gagal (fail). Idealnya, kelas-kelas dari failure dicari. Suatu tes yang baik tidak tumpang tindih (redundant). Waktu dan sumber daya testing terbatas. Tak ada satupun titik dalam pelaksanaan testing yang mempunyai tujuan yang sama dengan testing yang lain. Tiap testing harus mempunyai tujuan yang berbeda Suatu tes yang baik harus memberikan hasil yang terbaik [KAN93]. Dalam suatu grup tes yang mempunyai batasan intensi, waktu, sumber daya yang sama, akan melakukan eksekusi hanya pada subset dari tes ini. Dalam kasus tertentu, tes yang mempunyai kemungkinan tertinggi dalam memperoleh kelas error seharusnya digunakan.

Attribut penanda testing yang baik Suatu tes yang baik harusnya tidak terlalu sederhana namun juga tidak terlalu komplek. Walau kadang kala memungkinkan untuk mengkombinasikan serangkaian tes ke dalam satu test case, efek samping yang mungkin diasosiasikan dengan pendekatan ini adalah adanya error yang tidak terdeteksi. Umumnya, tiap tes harus dieksekusi secara terpisah.

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)

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 Y2K

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, 3GL, 4GL, SQL, RDBMS) Pemrograman (seperti C++, VB, OO)

Kemampuan Tester yang Diharapkan COLLARD [COL97A] menyatakan bahwa kemampuan tester dibedakan menjadi tiga grup besar, yaitu : Kemampuan fungsional dari subyek yang menjadi acuan Basis teknologi Teknik – teknik testing dan QA

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 kulitas yang rendah.

Personalitas Tester Atribut negatif yang patut dihindari Sedikit empati terhadap pengembang (developers) – mudah terpengaruh secara emosional yang kekanak-kanakan dalam hubungannya dengan pengembang (developers). Kurang berdiplomasi – menciptakan konflik dengan pengembang (developers) dengan menunjukan wajah yang tak bersahabat. Seorang tester akan tersenyum bila bertatap muka dengan pengembang (developers) saat menemukan defect, dan memberikan laporan defect yang disertai perhitungan statistik terjadinya defect dan bug. Skeptis – meminta informasi dari pengembang (developers) dengan penuh kecurigaan (tidak percaya). Keras kepala – tidak dapat fleksibel dalam mendiskusikan suatu proposal.

Personalitas Tester Selain itu seorang tester perlu mengetahui hambatan yang akan dihadapi dalam berkerjasama dengan pengembang (developers), dimana pengembang (developers) pada umumnya akan cenderung untuk melarikan diri dan bersembunyi darinya, bila mereka merasa hal-hal sebagai berikut: Percaya bahwa tester akan mengganggu perkerjaan mereka dan manambahkan kerumitan dengan masalah-masalah yang terjadi akibat keberadaan tester. Takut untuk mendiskusikan hal-hal yang berkaitan dengan pengembangan yang sedang dilakukan, dimana hal tersebut akan dapat digunakan untuk menjatuhkan mereka.

Failures, Faults Failure: output yang tidak benar/tidak sesuai ketika sistem dijalankan Fault: kesalahan dalam source code yang mungkin menimbulkan failure ketika code yg fault tsb dijalankan Failure Class Deskripsi Transient Muncul untuk input tertentu Permanent Muncul untuk semua input Recoverable Sistem dapat memperbaiki secara otomatis Unrecoverable Sistem tidak dapat memperbaiki secara otomatis Non-corrupting Failure tidak merusak data Corrupting Failure yang merusak sistem data

Test data dan Test cases Test data: Input yang yang direncanakan digunakan oleh sistem. Test cases: Input yang digunakan untuk menguji sistem dan memprediksi output dari input jika sistem beroperasi sesuai dengan spesifikasi

Pengertian Defect dari Software Menurut Kaner, Falk, dan Nguyen [KAM93A], ada 13 kategori utama defect dari software, yaitu : User interface errors - sistem memberikan suatu tampilan yang berbeda dari spesifikasi. Error handling – pengenalan dan perlakuan terhadap error bila terjadi. Boundary – related errors - perlakuan terhadap nilai batasan dari jangkauan mereka yang mungkin tidak benar. Calculation errors - perhitungan arimatika dan logika yang mungkin tidak benar. Initial and later states - fungsi gagal pada saat pertama digunakan atau sesudah itu.

Lanjutan pengertian defect Control flow errors - pilihan terhadap apa yang akan dilakukan berikutnya tidak sesuai untuk status saat ini. Errors in handling or interpreting data - melewatkan dan mengkonversi data antar sistem (dan mungkin komponen yang terpisah dari sistem) dapat menimbulkan error. Race conditions - bila dua event diproses akan maka salah satu akan diterima berdasarkan prioritas sampai pekerjaan selesai dengan baik, baru pekerjaan berikutnya. Bagaimanapun juga kadang-kadang event lain akan diproses terlebih dahulu dan dapat menghasilkan sesuatu yang tidak diharapkan atau tidak benar

Lanjutan pengertian defect Load conditions - saat sistem dipaksa pada batas maksimum, masalah akan mulai muncul, seperti arrays, overflow, diskfull. Hardware - antar muka dengan suatu device mungkin tidak dapat beroperasi dengan benar pada suatu kondisi tertentu seperti device unavailable. Source and Version Control - program yang telah kadaluwarsa mungkin akan dapat digunakan lagi bila ada revisi untuk memperbaikinya. Documentation - pengguna tak dapat melihat operasi yang telah dideskripsikan dalam dokumen panduan. Testing errors - tester membuat kesalahan selama testing dan berpikir bahwa sistem berkelakuan tak benar.

Proses defect testing

Proses Testing Unit testing Module Testing Sub-system Testing Pengujian masing-masing unit komponen program untuk meyakinkan bhw sudah beroperasi secara benar Module Testing Pengujian terhadap koleksi unit-unit komponen yang saling berhubungan. Sub-system Testing Pengujian terhadap koleksi module-module yang membentuk suatu sub-system (aplikasi)

Proses Testing System Testing Acceptance Testing Pengujian terhadap integrasi sub-system, yaitu keterhubungan antar sub-system Acceptance Testing Pengujian terakhirs sebelum sistem dipakai oleh user. Melibatkan pengujian dengan data dari pengguna sistem. Biasa dikenal sebagai “alpha test” (“beta test” untuk software komersial, dimana pengujian dilakukan oleh potensial customer)

Proses Testing Unit Testing Module Testing Sub-system Testing System Acceptance Testing User Testing Component Testing Integration Testing

Rencana Pengujian Proses testing Deskripsi fase-fase utama dalam pengujian Pelacakan Kebutuhan Semua kebutuhan user diuji secara individu Item yg diuji Menspesifikasi komponen sistem yang diuji Jadual Testing Prosedur Pencatatan Hasil dan Prosedur Kebutuhan akan Hardware dan Software Kendala-kendala Mis: kekuranga staff, alat, waktu dll.

Hubungan antara rencana pengujian dan proses pengembangan system Specific's Kebutuhan Spesifikasi System Perancangan System Detail Perancangan Acceptance Test plan System Integration Test plan Sub-System Integration Test plan Module and Unit code and test System Integration test Sub-System Integration test Acceptance test Service

Prioritas Testing Hanya test yang lengkap yg dapat meyakinkan sistem terbebas dari kesalahan, tetapi hal ini sangat sulit dilakukan. Prioritas dilakukan terhadap pengujian kemampuan sistem, bukan masing-masing komponennya. Pengujian untuk situasi yg tipikal lebih penting dibandingkan pengujian terhadap nilai batas.

Terimakasih