Obyektifitas Testing Misi dari Tim Testing Psikologi Testing

*Obyektifitas Testing *�Misi dari Tim Testing *Psikologi Testing *Prinsip – prinsip Testing *Moto Testing *

*Secara umum obyektifitas dari testing adalah untuk melakukan verifikasi, validasi dan deteksi error untuk menemukan masalah dan tujuan dari penemuan ini adalah untuk membenahinya. *

* Meningkatkan kepercayaan bahwa sistem dapat digunakan dengan tingkat resiko yangdapat diterima. * Menyediakan informasi yang dapat mencegah terulangnya error yang pernah terjadi. * Menyediakan informasi yang membantu untuk deteksi error secara dini. * Mencari error dan kelemahan atau keterbatasan sistem. * Mencari sejauh apa kemampuan dari sistem. * Menyediakan informasi untuk kualitas dari produk software. *

*Misi dari tim testing tidak hanya untuk melakukan testing, tapi juga untuk membantu meminimalkan resiko kegagalan proyek. *

*Bagi pengembangan berprilaku konstruktif, dan bagi testing berprilaku destruktif *

*Testing yang komplit tidak mungkin. *�Testing merupakan pekerjaan yang kreatif dan sulit. *�Alasan yang penting diadakannya testing adalah untuk mencegah terjadinya errors. *�Testing berbasis pada resiko. *�Testing harus direncanakan. *�Testing membutuhkan independensi *

*Domain Masukan *Kompleksitas *Jalur Program *

*Kreatifitas. *�Pengetahuan bisnis. *Pengalaman testing. *Metodologi Testing. *

*�Testing bukan untuk satu fase pengembangan saja. *�Hasil Testing diasosiasikan pada tiap fase pengembangan. *

* Sumber daya dan biaya yang dibutuhkan untuk melakukan testing berdasarkan pada skala prioritas, kompleksitas dan kesulitan testing * �Biaya dari keterlambatan pengiriman produk (dimana salah satu kemungkinan besar penyebabnya adalah testing) * Kemungkinan adanya suatu defect (berdasarkan pengalaman beroperasi dan prioritas sejarah terjadinya defect) * �Biaya yang disebabkan oleh defect, bilamana defect tersebut menyebabkan error yang akan membawa kerugian baik secara langsung ataupun tak langsung bagi pelanggan (berkaitan dengan kewajiban bisnis bagi pengembang terhadap kerugian yang terjadi pada pelanggan). *

Rencana Tes Disain Tes Pernyataan obyektifitas testing Spesifikasi tes yang dikembangkan Deskripsi pendekatan tes Deskripsi pengelompokan tes Sekelompok tugas untuk mencapai obyektifitas testing *

*Pengamat yang tidak bias *�Orang yang bertujuan untuk mengukur kualitas software secara akurat *

* Test case yang bagus adalah yang mempunyai kemungkinan tinggi dalam mendeteksi defect yang sebelumnya belum ditemukan, bukan yang dapat memperlihatkan bahwa program telah bekerja dengan benar. * �Satu dari kebanyakan masalah sulit dalam testing adalah pengetahuan akan kapan untuk berhenti. * �Tidak mungkin untuk mengetes program Anda sendiri. * �Bagian yang dibutuhkan dari tiap test case adalah deskripsi dari keluaran yang diharapkan. * �Hindari testing yang tidak produktif atau di awang-awang. * Tulis test case untuk kondisi yang valid dan tak valid. * �Inspeksi hasil dari tiap tes. *

* Semakin meningkatnya jumlah defect yang terdeteksi dari suatu bagian program, kemungkinan dari keberadaan defect yang tak terdeteksi juga meningkat. * �Tunjuklah programer terbaik Anda untuk melakukan testing. * �Pastikan bahwa testabilitas adalah suatu obyektifitas kunci dalam disain software Anda. * �Disain dari sistem seharusnya seperti tiap modul yang diintegrasikan ke dalam sistem hanya sekali. * �Jangan pernah mengubah program untuk membuat testing lebih mudah (kecuali pada perubahan yang permanen). * � Testing, seperti tiap aktifitas kebanyakan yang lain, testing juga harus dimulai dengan obyektifitas. *

* Sistem itu “ Buggy “ * Testing ditampilkan deng an gambaran yang menakutkan * Batas waktu menjadi hambatan bagi testi ng * Testing bukan organisasi dan ilmu * Manajemen pendukung untuk tes t ing kurang dari ideal * Testing tidak ditampilkan sebagai suatu karir yang menjanjikan * Teknol ogi baru ataupun lama menyulitkan situasi *

*Operability *Observability *Controllability *Decomposability *Simplicity *Stability *Understandability *

*Kemampuan fungsional dari subyek yang menjadi acuan *� Basis teknologi *� Teknik-teknik testing dan QA *

*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)

*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 * �Y 2 K

*Pengetahuan dan pengalaman akan penggunaan alat bantu testing * �Alat bantu capture atau playback (seperti Win. Runner) * �Alat bantu Load testing (seperti Load. Runner, Robo. Test) *Kemampuan terhadap linkungan testing * �Mainframe (seperti MVS, JCL). * �Client – Server (seperti Win. NT, UNIX) *Kemampuan terhadap aplikasi * �Dokumentasi (seperti office, excel, word, Lorus Notes) * �Database (seperti oracle, access, 3 GL, 4 GL, SQL, RDBMS) * �Pemrograman (seperti C++, VB, OO)

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

*Atribut negatif yang patut dihindari * �Sedikit empati terhadap pengembang (developers) mudah terpengaruh secara emosional yang kekanakan 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.

* 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. �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. * �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.

Biaya Pencegahan Defects Biaya Penialaian dan Evaluasi Defects Pelatihan staf Review disain Analisa kebutuhan Inspeksi kode Pembuatan protipe awal Glass-box testing Disain fault-tolerant Black-box testing Defensive programming Pelatihan tester Analisa kegunaan Beta testing Spesifikasi yang jelas Otomatisasi tes Dokumentasi internal yang akurat Usability testing * Evaluasi terhadap reliabilitas dari alat bantu pengembangan (sebelum membelinya) atau komponen lain dari produk yang potensial. Pre-release out-box testing oleh staf customer service

Biaya biaya Internal Pembenahan bugs Terbuangnya waktu Regression Testing Hilangnya data Terbuangnya waktu in-house user Kerugian bisnis Terbuangnya waktu tester Tercorengnya nama baik Terbuangnya waktu penulis Keluarnya karyawan akibat frustasi Terbuangnya waktu pemasaran Hilangnya potesial presentasi Terbuangnya promosi Kegagalan pelanggan karena software Biaya langsung dari keterlambatan pengiriman Biaya-biaya Eksternal * Biaya atas hilangnya kesempatan akibat keterlambatan pengiriman Terjadinya Failure dari tugas-tugas yang hanya dapat dilakukan sekali Biaya penggantian produk Biaya rekonfigurasi sistem Biaya pembenahan software Biaya dukungan teknisi Kecelakaan atau kematian

* Perencanaan * �Rencana pendekatan umum * �Menentukan obyektivitas testing * �Memperjelas rencana umum * Akusisi * �Disain tes * �Menerapkan tes * Pengukuran * �Eksekusi tes * �Cek terminasi * �Evaluasi hasil *

* Unit testing * Testing penulisan kode-kode program dalam satuan unit terkecil secara individual. * � System Testing * Proses testing pada sistem terintegrasi untuk melakukan verifikasi bahwa sistem telah sesuai spesifikasi. * � Acceptance Testing * Testing formal yang dilakukan untuk menentukan apakah sistem telah memenuhi kriteria penerimaan dan memberdayakan pelanggan untuk menentukan apakah sistem dapat diterima atau tidak. *

* * * Tujuan * �Konfirmasi bahwa modul telah dikode dengan benar. �Pelaku * �Biasanya programer. �Apa yang dites * * * �Fungsi (Black Box). �Kode (White Box). �Kondisi ekstrim dan batasan-batasan. �Kapan selesai * �Biasanya saat programer telah merasa puas dan tidak diketahui lagi kesalahan. �Alat bantu * �Tidak biasa digunakan. �Data * �Biasanya tidak didata. *

* Tujuan * �Merakit modul menjadi suatu sistem yang bekerja. Dan menentukan kesiapan untuk melakukan Acceptance Test. * Pelaku * �Pemimpin tim atau grup tes. * * �Kebutuhan dan fungsi sistem. �Antarmuka sistem. * �Biasanya bila mayoritas kebutuhan telah sesuai dan tidak ada kesalahan mayor yang ditemukan. * � Apa yang dites * � Kapan selesai * �Alat bantu * * �Sistem pustaka dan pustaka test case. �Generator, komparator dan simulator data testing. * * �Data kesalahan yang ditemukan. �Test case. * � Data *

* Tujuan * �Mengevaluasi kesiapan untuk digunakan. * �Pelaku * �Pengguna akhir atau agen. * �Apa yang dites * �Fungsi mayor. * �Dokumentasi. * �Prosedur. * �Kapan selesai * �Biasanya bila pengguna telah merasa puas atau tes berjalan dengan lancar / sukses. * �Alat bantu * �Komparator. * �Data * �Formalitas dokumen. *