Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

Sekolah Tinggi Manajemen Informatika & Teknik Komputer Surabaya Dasar-dasar Testing.

Presentasi serupa


Presentasi berjudul: "Sekolah Tinggi Manajemen Informatika & Teknik Komputer Surabaya Dasar-dasar Testing."— Transcript presentasi:

1 Sekolah Tinggi Manajemen Informatika & Teknik Komputer Surabaya Dasar-dasar Testing

2  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

3  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.

4 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.”

5 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.”

6 Understandability “Semakin banyak informasi yang kita miliki, kita akan dapat melakukan tes lebih baik.”

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

8  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.

9  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 )

10  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

11  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)

12  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

13  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.

14  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.

15  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.

16  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 ClassDeskripsi TransientMuncul untuk input tertentu PermanentMuncul untuk semua input RecoverableSistem dapat memperbaiki secara otomatis UnrecoverableSistem tidak dapat memperbaiki secara otomatis Non-corruptingFailure tidak merusak data CorruptingFailure yang merusak sistem data

17  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

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

19  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

20  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.

21

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

23 IV. System Testing  Pengujian terhadap integrasi sub-system, yaitu keterhubungan antar sub-system V. 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)

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

25  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.

26 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 Acceptance test System Integration test Sub-System Integration test Service

27  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.

28 28/15


Download ppt "Sekolah Tinggi Manajemen Informatika & Teknik Komputer Surabaya Dasar-dasar Testing."

Presentasi serupa


Iklan oleh Google