Dasar-Dasar Testing.

Slides:



Advertisements
Presentasi serupa
Testing & Implementation System
Advertisements

Overview Komponen Sistem SQA
Rekayasa Perangkat Lunak dan Proses Software
BAB 8 PENGUJIAN PERANGKAT LUNAK
Testing dan Implementasi Sistem
Testing dan Implementasi Sistem
Testing dan Implementasi Sistem
TESTING DAN QA SOFTWARE PERTEMUAN 5 & 6
Testing.
Teknik Pengujian Perangkat Lunak
U NIVERSITAS B INA D ARMA P ALEMBANG L AILI A DHA, M.K OM /T EKNIK I NFORMATIKA /2013.
Pengembangan perangkat lunak
TEKNIK PENGUJIAN PERANGKAT LUNAK
Testing dan Implementasi Sistem
Testing & Implementation System
TESTING DAN QA SOFTWARE PERTEMUAN 9
U NIVERSITAS B INA D ARMA P ALEMBANG L AILI A DHA, M.K OM /T EKNIK I NFORMATIKA /2013.
U NIVERSITAS B INA D ARMA P ALEMBANG L AILI A DHA, M.K OM /T EKNIK I NFORMATIKA /2013.
Testing Pertemuan ke 2.
Testing dan Implementasi Sistem
Kriteria Rekayasa Perangkat Lunak (lanjutan)
TEKNIK TESTING DAN STRATEGI TESTING
Testing dan implemantasi sistem
Testing.
Systems Development Life Cycle
Riskha Dwi Anggraeni Software Testing. Software testing adalah proses untuk menganalisa sebuah software Mendeteksi antara kondisi sekarang dengan kondisi.
VALIDASI SOFTWARE (Nelly Sofi).
Testing dan implementasi sistem
Tim RPL Teknik Informatika 2017
TEKNIK PENGUJIAN PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
Metodologi Pengembangan Sistem Informasi
Rekayasa Perangkat Lunak Metode Pengujian Perangkat Lunak
WHITE BOX TESTING PENGUJIAN BASIS PATH
Strategi Testing Rika Harman, S.Kom.,M.S.I.
Testing dan Implementasi Sistem Informasi
SIKLUS HIDUP PEMBANGUNAN SOFTWARE
Matakuliah : Konsep object-oriented
Strategi Pengujian Perangkat Lunak & Sistem
Testing dan Implementasi
Dasar – dasar pengujian perangkat lunak
Black Box Testing.
Testing dan Implementasi Sistem [3-sks (3-0)]
Dasar-dasar Pengujian Perangkat Lunak
TESTING DAN IMPLEMENTASI SISTEM
Testing & Implementasi
TESTING DAN IMPLEMENTASI PERTEMUAN 2
Testing dan Implementasi SI220A
Testing dan implementasi si
Validasi dan Verifikasi Software
TEKNIK PENGUJIAN PERANGKAT LUNAK
TEKNIK PENGUJIAN PERANGKAT LUNAK
TESTING DAN QA SOFTWARE PERTEMUAN 14
TESTING DAN QA SOFTWARE PERTEMUAN 18
Dasar-dasar Pengujian Perangkat Lunak
TESTING DAN QA SOFTWARE PERTEMUAN 10 & 11
Testing dan Implementasi
Metodologi Pengembangan Sistem Informasi
Pengujian Perangkat Lunak
TESTING DAN QA SOFTWARE PERTEMUAN 9
TEKNIK PENGUJIAN PERANGKAT LUNAK
TESTING DAN QA SOFTWARE PERTEMUAN 13
Tim RPL Teknik Informatika 2018
Dasar-dasar Pengujian Perangkat Lunak
Dasar-dasar Pengujian Perangkat Lunak
Dasar-dasar Pengujian Perangkat Lunak
Fathiah, S.T.,M.Eng Universitas Ubudiyah Indonesia
Fathiah, S.T.,M.Eng Universitas Ubudiyah Indonesia
WHITE BOX TESTING PENGUJIAN BASIS PATH
PENGANTAR Testing dan implementasi sistem. Definisi testing Testing adalah proses menganalisa suatu entitas software untuk mendeteksi perbedaan antara.
Transcript presentasi:

Dasar-Dasar Testing

Materi : Obyektifitas Testing ƒMisi dari Tim Testing Psikologi Testing Prinsip – prinsip Testing Moto Testing Materi :

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

Pendapat dari praktisi 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. Pendapat dari praktisi

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

Bagi pengembangan berprilaku konstruktif, dan bagi testing berprilaku destruktif Psikologi Testing

Prinsip-Prinsip Testing 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 Prinsip-Prinsip Testing

Testing yang komplit tidak mungkin dilakukan Domain Masukan Kompleksitas Jalur Program Testing yang komplit tidak mungkin dilakukan

Jalur Program

Testing merupakan pekerjaan yang kreatif dan sulit Kreatifitas. ‰Pengetahuan bisnis. Pengalaman testing. Metodologi Testing. Testing merupakan pekerjaan yang kreatif dan sulit

Konsep siklus dari testing ‰Testing bukan untuk satu fase pengembangan saja. ‰Hasil Testing diasosiasikan pada tiap fase pengembangan. Konsep siklus dari testing

Testing berbasis pada resiko. 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). Testing berbasis pada resiko.

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

Testing butuh kebebasan. Pengamat yang tidak bias ‰Orang yang bertujuan untuk mengukur kualitas software secara akurat Testing butuh kebebasan.

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. Moto Testing

Moto Testing (lajutan) 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. Moto Testing (lajutan)

Isu-Isu Seputar Testing 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 Isu-Isu Seputar Testing

Testabilitas Operability Observability Controllability Decomposability Simplicity Stability Understandability Testabilitas

Kemampuan Tester yang Diharapkan Kemampuan fungsional dari subyek yang menjadi acuan ‰ Basis teknologi ‰ Teknik-teknik testing dan QA Kemampuan Tester yang Diharapkan

Pemahaman terhadap metodologi 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 ƒY2K

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)

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.

Kategori utama defect dari software 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. Kategori utama defect dari software

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-biaya testing 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 testing

Biaya-biaya defects Biaya biaya Internal Biaya-biaya Eksternal 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 Terjadinya Failure dari tugas-tugas yang hanya dapat dilakukan sekali Biaya atas hilangnya kesempatan akibat keterlambatan pengiriman Biaya penggantian produk Biaya rekonfigurasi sistem Biaya pembenahan software Biaya dukungan teknisi Kecelakaan atau kematian Biaya-biaya defects

Model siklus hidup (life cycle model)

Siklus Hidup Testing

Aktifitas Testing Perencanaan Akusisi Pengukuran ƒRencana pendekatan umum ƒMenentukan obyektivitas testing ƒMemperjelas rencana umum Akusisi ƒDisain tes ƒMenerapkan tes Pengukuran ƒEksekusi tes ƒCek terminasi ƒEvaluasi hasil Aktifitas Testing

Tiga Tingkatan Testing 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. Tiga Tingkatan Testing

Praktik unit testing Tujuan ‰Pelaku ‰Apa yang dites ‰Kapan selesai ƒ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. Praktik unit testing

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

Praktik acceptance testing 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. Praktik acceptance testing