TESTING SISTEM INFORMASI

Testing Proses menganalisa suatu entitas software untuk mendeteksi perbedaan antara kondisi yang ada dengan kondisi yang diinginkan (defect / error / bugs) dan mengevaluasi fitur-fitur dari entitas software (standar IEEE1059) Testing akan melakukan Verifikasi Deteksi Error Validasi

Testing Verifikasi  Are we building the system right? Validasi  Are we building the right system ? Deteksi Error  Apakah program tidak ada error?

Manfaat Testing Meningkatkan kepercayaan, tingkat resiko yang dapat diterima Menyediakan informasi untuk deteksi error secara dini Menyediakan informasi yang dapat mencegah terjadinya error Mencari error dan kelemahan sistem Mencari sejauh apa kemampuan dari sistem Menyediakan informasi untuk kualitas produk software

Penyebab Terjadi nya Error Paton, Ron. Software Testing ISBN 0-672-32798-8. 2005. Sams Publishing

Cost Effect

REVIEW Kenapa harus dilakukan Testing? Kapan Testing Dilakukan? Bagaimana hubungan antara fase pembangunan, waktu testing dan cost?

Software Tester Individu / tim yang bertugas untuk melakukan testing terhadap suatu software Prinsip Software Tester Menemukan bugs software Memposisikan diri sebagai customer Menemukan sedini mungkin

ST dikategorikan baik jika ST harus menguasai knowledge seperti programmer Pendekatan yang disiplin dan metodologis memerlukan kerja keras dan dedikasi setara programmer Tidak semua perusahaan memandang ST sebagai profesi yang penting.

Sifat-sifat Penjelajah  suka hal2 baru Pemecah masalah  mengerti bagaimana memecahkan bugs Pantang menyerah  terus mencari bugs2 yang tersembunyi Kreatif  mampu mencari bugs2 yang tidak terpikirikan

Perfectionis  Berorientasi untuk menghasilkan produk yang sempurna Diplomatis dan komunikatif  Mampu berkomunikasi dengan programmer Selektif  Mampu memilih dan memilah mana yang perlu dicari bug nya, dan mana yang tidak

Is it bugs? Software tidak melakukan sesuatu seperti yg dinyatakan dalam spesifikasi produk Software melakukan sesuatu yang seharusnya tidak perlu dilakukan Software melakukan sesuatu yang tidak disebutkan dalam spesifikasi produk Software tidak melakukan sesuatu seperti spesifikasi, tetapi seharusnya software melakukan itu Software sulit dipahami, sulit digunakan dan lambat

Mustahil mencari bugs secara menyeluruh. Why? Jumlah kemungkinan input yang sangat besar Jumlah kemungkinan output yang sangat besar Jumlah jalur menuju pembuatan software sangat besar Spesifikasi software bersifat subjektif Input yang sangat besar  misal dalam menguji kalkulator sederhana, anda akan mencoba mengiputkan 1+1, kemudian 1+1+1 dan seterusnya// Output yang sangat besar idem Jalur menuju software sangat besar  Software Tester musti memiliki sudut pandang yang sama dengan pembuat software

Paradoks Pestisida Software yang menjalani pengujian yang sama dan berulang akhirnya akan membangun resistensi sendiri

Tidak Semua Bug perlu diperbaiki Alasan nya : Tidak terdapat waktu yang cukup Bukan bugs yang sebenarnya (salah paham, beda persepsi) Terlalu beresiko untuk diperbaiki Tidak sepadan dengan usaha perbaikan nya

Prinsip – Prinsip Testing Testing yang komplit tidak mungkin Testing merupakan pekerjaan kreatif dan sulit Alasan penting dilakukan testing adalah untuk mencegah terjadinya error Testing berbasis pada resiko Testing harus direncanakan Testing membutuhkan independensi

Testabilitas & Atributnya Adalah seberapa mudah suatu program komputer dapat dites (James Bach) Atribut Operability “Semakin baik software bekerja, akan membuat software di tes dengan lebih efisien” Observability “Apa yang anda lihat, adalah apa yang anda tes” Controllability “Semakin baik kita dapat mengendalikan software, makin banyak testing dapat diotomatisasi dan dioptimalisasi” Operability “Semakin baik Software berkerja, akan membuat software dites dengan lebih efisien.”  Observability “Apa yang Anda lihat, adalah apa yang Anda tes.”  Controllability “Semakin baik kita dapat mengendalikan software, makin banyak testing dapat diotomatisasi dan dioptimalisasi.”

Testabilitas & Atributnya (2) Decomposability “Dengan pengendalian batasan testing, dapat lebih cepat dalam mengisolasi masalah dan melakukan testing ulang” Simplicity “Semakin sedikit yang di tes, semakin cepat dilakukan tes” Stability “Semakin sedikit perubahan, semakin sedikit masalah/gangguan” Understandability “Semakin banyak informasi yang kita miliki, kita akan dapat melakukan tes lebih baik”  Decomposability “Dengan pengendalian batasan testing, dapat lebih cepat dlm mengisolasi masalah dan melakukan testing ulang.”  Simplicity “Semakin sedikit yang dites, semakin cepat dilakukan tes.”  Stability “Semakin sedikit perubahan, semakin sedikit mslh / gangguan”  Understandability “Semakin banyak informasi yang kita miliki, kita akan dapat melakukan tes lebih baik.”

Jenis Pengujian Software White Box vs Black Box Statik vs Dinamik

Black Box Kita tidak tahu proses yang ada di dalam nya

White Box Mengetahui Proses di dalam nya

Pengujian Spesifikasi Termotivasi oleh  Pengujian dilakukan sedini mungkin Ada 2 macam spesifikasi Spesifikasi Tertulis Spesifikasi TidakTertulis? Manfaatkan orang-orang level atas

Pengujian spesifikasi (Tingkat Tinggi) Bertindak seolah2 menjadi customer Pahami kebutuhan customer Jangan berasumsi Jangan melupakan keamanan software Meneliti standar dan pedoman yang ada Standard lebih tegas Pedoman lebih opsional

Pengujian spesifikasi (Tingkat Tinggi) Checklist Atribut Spesifikasi Spesifikasi produk yang baik memiliki 8 atribut penting, yaitu Lengkap Akurat Presisi, jelas, tidak ambigu Konsisten Relevan Layak dicapai Bebas kode ? Teruji

Pengujian spesifikasi (Tingkat Tinggi) Checklist terminologi spesifikasi Daftar yang berisikan permasalahan kata-kata yang sering dijumpai, misalnya : Selalu, setiap, semua, tidak pernah, tidak akan  TEGAS Beberapa, kadang-kadang, sering, biasanya  TIDAK TEGAS

BLACK BOX TESTING

Pendahuluan Fokus pada faktor Fungsionalitas dan spesifikasi Perangkat Lunak Fokus pada informasi domain Tidak membutuhkan pengetahuan mengenai,alur internal, struktur Software Under Test Bukan alternatif dari ujicoba whitebox, tetapi merupakan pendekatan yang melengkapi untuk menemukan kesalahan lainnya

Kategori Kesalahan (Black Box) Fungsi – fungsi yang salah atau hilang Kesalahan Interface Kesalahan dalam struktur data Kesalahan dalam akses database eksternal Kesalahan performa Kesalahan inisialisasi dan terminasi

Pertanyaan Black Box Testing Bagaimana validitas fungsionalitasnya diuji? Jenis input seperti apa yang akan menghasilkan kasus uji yang baik? Apakah sistem sensitif terhadap nilai input tertentu? Bagaimana batasan-batasan kelas diisolasi? Berapa rasio data dan jumlah data yang dapat di toleransi oleh sistem? Apa akibat dari kombinasi spesifik data pada sistem operasi?

Proses dalam Black Box Testing Menganalisa kebutuhan dan spesifikasi perangkat lunak Pemilihan jenis input yang mungkin menghasilkan output yang benar Pengujian dilakukan dengan input-input yang benar-benar telah diseleksi Pembandingan output yang dihasilkan dengan output yang diharapkan Menentukan fungsionalitas yang harusnya ada pada perangkat lunak yang diuji

Kapan pengujian nya? Blackbox Testing dapat dilakukan di setiap level pembangunan sistem

Kelebihan & Kekurangan Dapat memilih subset test yang secara efektif dan efisien dapat menemukan cacat Membantu meminimalkan testing cost Kelemahan Tester tidak yakin sepenuhnya atas perangkat lunak yang telah diuji

Jenis – jenis BB Testing Equivalence Partitioning Boundary Value Analysis/Limit Testing Comparison Testing Sample Testing Robustness Testing Behavior Testing Requirement Testing Performance Testing Endurance Testing Cause-Effect Relationship Testing

Equivalence Partitioning Divide the input domain into classes of data for which test cases can be generated. Attempting to uncover classes of errors. Based on equivalence classes for input conditions. An equivalence class represents a set of valid or invalid states An input condition is either a specific numeric value, range of values, a set of related values, or a boolean condition. Equivalence classes can be defined by: If an input condition specifies a range or a specific value, one valid and two invalid equivalence classes defined. If an input condition specifies a boolean or a member of a set, one valid and one invalid equivalence classes defined. Test cases for each input domain data item developed and executed.

Example 1 Requirements of the subprogram to be tested (initial&final state) The subprogram takes an integer input in the range [-100,100] The output of the subprogram is the sign of the input value (the value 0 is considered positive) Two valid equivalence class The input range [-100,0] which contains the subset of integer, will produce negative sign as an output The input range [0,100] will produce positive sign Two invalid equivalence class The integers strictly less than -100 The integers strictly more than -100

Rules Equivalence Partitioning (1) If a condition concerning the input data specifies a range of values (e/g: the counter can take values 1 to 999), define a valid equiv. Class [1,999] and two invalid equivalence class (counter < 1, and counter > 99). If a condition concerning the input data specifies the number of values (a thing can contain 1 to 6 name), define a valid equivalence class and two invalid equivalence classes (no name and more than 6 names) If a condition concerning the input data specifies a set of values and the CSU tested processes each value differently (e/g: BUS, TAXI, TRUCK, TRAIN), define a valid equivalence class for each value and an invalid equivalence class (e/g MOTORCYCLE).

Rules Equivalence Partitioning (2) If an input condition is expressed by a sentence containing ‘must be’ (e/g the first character must be a letter), define a valid equivalence class ( a letter) and an invalid equivalence class ( not a letter)

Example 2 Requirements Three valid equivalence class Given three values, represent the length of side of triangle, determine if it is equilateral, isosceles and scalene Three valid equivalence class 3 equal values positive 3 positive values and 2 which are equal and the sum of two is greater than the third value 3 positive values and the sum of two values is greater than the third value Two invalid equivalence classes 2 positive values and a negative/zero 3 positive values such that the sum of two is equal/less

Boundary Value Analysis (BVA) Large number of errors tend to occur at boundaries of the input domain. BVA leads to selection of test cases that exercise boundary values. BVA complements equivalence partitioning. Rather than select any element in an equivalence class, select those at the ''edge' of the class. Examples: For a range of values bounded by a and b, test (a-1), a, (a+1), (b-1), b, (b+1). If input conditions specify a number of values n, test with (n-1), n and (n+1) input values. Apply 1 and 2 to output conditions (e.g., generate table of minimum and maximum size). If internal program data structures have boundaries (e.g., buffer size, table limits), use input data to exercise structures on boundaries.