TESTING

I. Dasar-Dasar Testing Sistem

I.1. Extended Test Effort
I.1.1.Test Granularity







Test Granularity
a. White Box (Structural) Testing
 Disebut juga structural test, glass box test, code based test, dan design based test.
 Menemukan bug dalam low level operations, Chips, subassemblies dan interfaces
 Didasarkan pada bagaimana suatu sistem beroperasi dan cenderung mengenali dengan sederhana bug yang terisolasi.
 Software, test ini dikembangkan dengan melihat kode dan struktrur datanya.
 Hardware, membandingkan spesifikasi chip pada pembacaan di oscilloscope atau Volt Meter.
b. Black Box (Behavioral) Testing
 Disebut juga behavioral test, sering digunakan untuk menemukan bug dalam high level operations, profil operasional dan customer scenarios.
 Didasarkan pada apa yang sistem harus lakukan.
 Fokusnya adalah keadaan external dari sistim ketika ditest.
c. Live Test
 Meliputi customer ketika suatu software atau hardware diperkenalkan dengan harapan akan menemukan kesalahan bila digunakan oleh user, contohnya Beta testing.
 Test ini merupakan perilaku yang lengkap dari sistem, karena user hanya mememperhatikan tentang apa yang sistim lakukan bukan bagaimana sistim program melakukannya.
 Fokusnya kesalahan yang diperoleh dari pengalaman.
 Test ini bentuk yang semprna untuk technical support, marketing, dan sales peusahaan, dimana orang-orang tersebut tidak mengetahui teknik test tetapi mengetahui produk dengan baik sekali.

I.1.2. Test Execution Phases
 Unit Testing, meliputi pengetesan bagian dari kode yang ukurannya tidak ditentukan batasnya dalam praktek tetapi umumnya fungsi atau subroutine.
 Integration Testing, pengetasan yang menemukan bug dalam hubungannya dan interface antara komponen dan grup komponen dari sistim ketika ditest.
 Fuction Testing, pengetesan dari fungsi spesifikasi software atau hardware ketika dieksekusi
 System Testing, Pengetesan mengunakan keseluruhan sistem untuk menemukan bug dalam variasi operasi sistem.
 Acceptance Testing, Pengetesan yang menemukan kebutuhan dari sistem ketika ditest.

I.1.2.1. Tahapan Pengetesan
Tahap-Tahap Pengetesan

I.1.2.2. Alasan Phases Test Approach
 Structural testing membangun produk menjadi stabil.
 Structural testing memulai dengan membagi-bagi menjadi bagian-bagian sehingga memudahkan test.
 Dapat mendeteksi bug lebih efisien
 Dapat membandingkan metrik dari proyek dengan standar industri.
 Menambah kepercayaan dan keyakinan terhadap produk secara psikologis

I.2. Kualitas Sistem
 Biasanya menentukan kualitas sistem dilihat dari bug yang dapat ditemukan dalam suatu program, tetapi untuk menemukan bug juga tidak mudah.
 Bisa saja suatu program pada saat dilakukan pengetesan tidak ditemukan bug, dan ternyata setelah digunakan banyak bug yang keluar.
 Hal ini dapat terjadi bila cara pengetesan sistem kurang baik.
 Sehingga dapat disimpulkan bahwa belum tentu pada saat dilakukan test bug tidak ditemukan berarti sistem tersebut sudah baik, ini tergantung juga pada cara pengetesan, maka cara pengetesan merupakan faktor yang sangat penting dalam melakukan sistem testing


High-fidelity test system


Low-fidelity test system

I.2.1 Karakteristik Kualitas software pada ISO 9126
a. Functionality, Kemampuan Software untuk memenuhi ketetapan dari kebutuhan tidak langsung user
 Suitability, kemampuan Software untuk menyediakan sekumpulan fungsi dimana ketepatan tugas (task) tertentu dibuat oleh User
 Accuracy, kemampuan Software untuk menyediakan kebenaran atau kesepakatan hasil atau efeknya
 Interoperability, kemampuan Software untuk berinteraksi dengan sistem tertentu yang lain
 Compliance, kemampuan Software untuk mengikuti standar yang berhubungan, perjanjian, regulasi, hukum dan aturan yang hampir sama
 Security, kemampuan Software untuk melindungi akses yang tidak sah, walau sengaja atau tidak sengaja pada program dan data
b. Reliability, Kemampuan Software untuk memaintain tingkatan kinerjanya untuk waktu tertentu
 Maturity, atribut Software yang dihubungkan pada frekuensi kegagalan dari kelemahan software
 Fault Tolerance, kemampuan Software memaintain tingkatan kinerja tertentu pada kasus kelemahan software atau kesalahan pengunaan dari interface tertentu
 Recoverability, kapabilitas Software untuk kembali pada tingkatan kinerjanya dan memperbaiki data secara langsung akibat kasus kerusakan tersebut
c. Usability, Atribut Software yang berhubungan dengan jumlah kebutuhan penggunaannya
 Understanability, atribut Software yang berhubungan dengan kebutuhan user untuk mengerti dasar logika konsep software
 Learnability, atribut Software yang berhubungan dengan kebutuhan user untuk untuk belajar aplikasi software
 Operability, atribut Software yang berhubungan dengan kebutuhan user untuk operasi dan kontrol software
d. Efficiency, Hubungan antara tingkatan kinerja software dangan jumlah sumber daya yang digunakan
 Time Behaviour, atribut Software yang berhubungan dengan respon software, waktu proses, dan throughput ketika kinerja fungsinya berjalan
 Resource Behaviour, atribut Software yang berhubungan dengan jumlah sumber daya yang digunakan software dan durasi penggunaan kinerja fungsinya berjalan
e. Maintainability, Kemampuan Software untuk dibuat modifikasi tertentu
 Analysability, atribut Software yang berhubungan dengan kebutuhan kurangnya diagnosa, menyebabkan kegagalan identifikasi bagian yang dimodifikasi
 Changeabilty, atribut Software yang berhubungan dengan kebutuhan modifikasi, penghilanag kerusakan atau perubahan lingkungan software
 Stability, atribut Software yang berhubungan resiko yang tidak diduga dari efek modifikasi
 Testability, atribut Software yang mempengaruhi untuk testing setelah modifikasi
f. Portability, Kemampuan Software ditranfer dari satu lingkungan kelainnya
 Adaptability, kemampuan Software beradaptasi pada lingkungan tertentu yang berbeda
 Installability, atribut Software yang berhubungan jumlah kebutuhan install software pada lingkungan tertentu
 Conformance, kemampuan Software mengikuti standar atau perjanjian yang berhubungan dengan portability
 Replaceability, kemampuan Software diganti dengan potongan/bagian software yang lain
















Software Quality Level


I.2.2. Metoda Dalam Kualitas Resiko
I.2.2.1. Metoda Informal Penilaian Kualitas Resiko
 Penilaian ini berdasakan pada prioritas user, sehingga metoda yang digunakan menjadi informal
 Untuk mengembangkan kategori utama, maka tahapan test di bagi manjadi Component Testing, Integration Testing, System Testing dan Acceptance Testing

a. Component Testing
a1. State
 Pada beberapa kompter khususnya sitem Telephony, komponen atau sekumpulan computer melaksanakan sesuatu yang disebut oleh ilmu computer sebg state machine.
 Secara informal state machine adalah suatu sistem yang menggerakkan/memindahkan suatu kondisi menjadi kondisi lain bila respon (diasosiasikan sbg output dan state berikutnya) pd suatu input bergantung pada state saat ini dan input.
 State machines menyajikan suatu variasi dari kualitas resiko yang dihubungkan dengan State machines kesemua dan atau individu states.
* Apakah transisi dari suatu ke yang lainnya terjadi pada kondisi yang lebih baik ?
* Apakah output yang dihasilkan memiliki kebenaran ?
* Apakah input yang diterima utuk setiap atate memiliki kebenaran ?
a.2. Transactions
Komponen mempunyai transaksi dengan user atau dengan komponen lainnya memiliki/menghadirkan variasi resiko mis : Dalam mengcreate file baru ? ; Apakah ada file tempelete ?; Bagaimana produk merespon file ilegal ?
a.3. Code Coverage
 Struktur pola dasar resiko sangat memperhatikan keberadaan untested code componen.
 Area ini sering menghandel/ menyebabkan kondisi yang tidak dinamis mis pada over temp critical condition, seharusnya test tersebut merusak konfigurasi test, tetapi bagaimana jika sistem mati pada saat kejadian berlangsung.
a.4. Data Flow Coverage
 Merupakan transfer data melalui parameter lingkungan data global atau penyimpanan DB dari suatu komponen kelainnya.
 Pertambahan program untuk import, export, link data dari lain program mengcreate Data Flow yang komplek.
 User kadang-kadang menganggap hal ini aneh.
a.5. Functionality
 Setiap komponen melaksanakan beberapa fungsi untuk operasi internal spt kalkulasi, formating.
 Kualitas resiko secara fungsional pada umumnya mempunyai 2 tipe :
* Fungsi yang dilaksanakan tidak benar
* Terdapat bagian fungsi yang bekerja tidak benar/ kuang benar.
a.6. User interface
 Kualitas resiko untuk area ini hampir sama dengan functionality, tetapi area ini juga memasukan pertanyaan yang meliputi pemakaian promps dan massage yang dimengerti, aliran kontrol, ketepatan warna skema dan grafik.
 Selama phase componen test, user interface testing meliputi prototipe interface atau penggunaan perbagian. Pengujian tidak harus menguji keseluruhan interface tetapi tiap screen dibuat maket/contoh.
a.7. Mechanical live
Setiap objek yang dapat difleksibelkan atau digerakan oleh keterbatasan pada sejumlah gerakan yang dikerjakan/ditanggung, misalnya : Keyboard break, contacks fail, pemasangan cracks dan lain sebagainya.
a.8. Signal Quality
Setiap sirkuit yang memproses data apakah itu digital ataupun analog akan dibatasi oleh kualitas input signal mis adanya noise.


b. Integration Testing
b.1. Component atau Subsystem Interfaces
Setiap fungsi, bus, konektor memungkinkan terjadinya kesalahfahaman antara dua atau lebih komponen untuk teknik pengembangannya, kesalahaman ini terjadi dengan sendirinya bila dua komponen membenarkan suatu kesalahan bersama.
b.2. Functionality
Fokusnya pada fungsional yang membutuhkan kebenaran operasi pada dua atau lebih komponen dari aliran data antara komponen.
b.3. Kapasitas dan volume
Kapasitas (statik ) dan volume (dinamik) dari pipa harus matching dengan kebutuhan aplikasi dan harapan user, dimana makin besar lingkungan (jaringannya) makin banyak variasi resikonya.
b.4. Penanganan Kesalahan dan Recover
Tidak aada yang meramalkan dengan pasti kesalahan yang akan terjadi, tetapi dengan menggunakan integration test kesalahan yang umum terjadi dapat ditangani lebih awal.
b.5. Data Quality
Jika suatu produk stores, retrives dan shared significant amount of data, khususnya yang memiliki link yang sulit, relationshipnya dan integritas data, seharusnya dipertimbangkan untuk ditest walaupun produk penanganan datanya dapat dipercaya. Misalnya pada penggunaan spreedsheet.
b.6. Performance/kinereja
Seperti pada kapasitas dan volume, performance perhatiannya berlaku pada banyaknya subsistem dan komponen dalan suatu produk
b.7. User Interface
Bila functionality diintegrasikan ke sistem seharusnya test melalui user interface, jika menggunakan prototipe ini merupakan suatu option.

c. System Testing & Acceptance Testing
c.1. Functionality
Selama test system seharusnya mempertimbangkan functionality dalam bentuk semua urutan
c.2. User Interface
 Testing dapat difokuskan pada penghilangan prilaku menggangu yang muncul setiapkali dikoneksi dengan interface.
 Penggunaan prototipe adalah langkah terbaik.
 Pada system test pertama kali akan terlihat kelengkapan user interface dengan semua perintah dan aksi yang didapat

c.3. States
State machines dapat eksis pada tingkatan sistem sebagaimana tingkatan komponen, misalnya pada voice mail system.
c.4. Transaction
Transaksi akan terjadi untuk print file, pengiriman file dan lain-lain.
c.5. Data Quality
Selama tahapan test system resiko kualitas data yang awalnya di kover oleh test integration harus direvisi ulang, karena kekomplesitasan dari data sering meningkat setiap kali produk diintegrasikan
c.6. Operations
Sistem yang komplek spt database dan server sering membutuhkan administrator. Operasi ini membuat pekerjaan maintenance penting kadang-kadang mejadi pekerjaan off line mis backup file dan restore file atau juga migrasi dari satu sistem operasi ke sistem operasi yang lain.
c.7. Capacity & Volume
Seharusnya kapasitas dan volume direvisi ulang walaupun telah telah dikover oleh integrations test, tetapi pendekatan yang digunakan adalah black box test.
c.8. Reliability & Stability
Resiko kualitas pada area ini termasuk dapat menerima failure rates (mean time between failures atau MTBF), tidak dapat menerima recovery time (mean time to repair atau MTTR), dan ketidak mamapuan sistem untuk berfungsi pada kondisi yang legiminate tanpa kesalahan.
c.9. Error/Disaster handling & Recovery
Seperti juga untuk kapasitas dan volume perlu direvisi ulang terutama untuk external failure.
c.10. Stress
Gabungan dari tiga diatas (Capacity &Volume; Reliability & Stability; Error/Disaster handling & Recovery)
c.11. Performance
Revisi ulang dari Integration Test, tetapi lebih difokuskan pada pendekatan prilaku.
c.12. Date & Time Handling
Penggunaan waktu yang berbeda dari beberapa zone, pengukuran atau aturan tanpa menggunaan waktu standard akan mempengaruhi kualitas resiko.
c.13. Localization
Masalah lokasi diasosiasikan dalam penggunaan huruf/bahasa misal untuk keyboard, dilain hal untuk hardware masalah voltage, dialtone telepon.


c.14. Networked & Distribution Enviroments
Bila produk dipakai pada lingkungan yang berbeda akan menimbul;kan resiko kualitas misal untuk standard waktu apakh waktu internasional atau bukan ? sebab jika berkomunikasi secara international akan mempengaruhi standard telephone.
c.15. Configuration Options & Compatibility
Variasi sw, hw dan jaringan yang membingungkan dapat mengcreate problem pada sitem, mis apakh driver cocok atau tidak ?
c.16. Standards Complaince
Bug yang tidak berbahaya dihubungkan pada standard tidak menimbulkan reaksi sehingga produk secara legal dan efektif tidak terhalang dipasaran
c.17. Security
 Merupakan pengetesan dalam penulisan pasword, pengupdatean, pengcopian dll
 Bilamana implementasi keamanan merupakan ciri-ciri utama dari suatu dan hal tersebut tidak hanya untuk semua produk perlu ada pengetesan
c.18. Enviroment
Setiap produk memiliki resiko terhadap lingkungan, mis temperatur, kelembaban, debu, jamur dll.
c.19. Power Input, Consumption & Output.
Semua komputer membutuhkan atau berada dalam lingkungan gelombang elektrik, perubahan dalam hal tersebut menyebabkan panas atau radiasi elektro magnetik dan mempengaruhi baik langsung maupun tidak langsung terhadap kerusakan device (komponen).
c.20. Shock, Vibration & Drop
 Pada saat ini banyak komputer yang moveable, yakni dapat dipindah-pindahkan, akibatnya komputer tersebut akan mengalami, goncangan, vibrasi dan jatuh (kadang-kadang)
 Test sistem pada phase ini akan menemukan apakh sistem berubah setelah mengalami hukum grafitasi.
c.21. Instalation, Cut Over, SETUP & Initial Configuration
 Setiap produk akan mengalami pemakaian awal
 Apakah proses instalasi bekerja ?
 Dapatkah data bermigrasi dari sistem lama ?
 Pada multiuser situasi, konfigurasi termasuk juga membuat kreasi user account dan Bagaimana jika user ingin mengunistall program ?



c.22. Documentation & Packaging
Kesalahan tidak perlu terjadi mungkin dapat terjadi misalnya memasng 100v pada 220 V, termasuk vibrasi, shock dan drop.
c.23. Maintainability
Setiap sistem yang terlampau sederhana untuk kebutuhan operatornya akan memungkinkan terjadinya resiko kesalahan pada perwatannya, mis : dapatkah mengupgrade software atau menambah memory ?
c.24. Beta
Setiap produk secara umum baik sw atau hw tidak ada yang sebaik untuk penggunaan dan lingkungan user sendiri, untuk itu perlu mempertimbangkan dalam bentuk beta testing atau release program dalam bentuk pertama, kedua dan seterusnya.

 Pengecekan dan Kelengkapan Metoda Informal
* Membuat daftar :
• Resiko tidak penting dan user tidak perhatian
• Resiko tidak kritis tapi user sangat memperhatikan
* Membuat Pembanding dengan team
* Masukan dari Internal Experts
* Masukan dari Sumber External
* Usulan dari Kualitas Resiko (Lihat Contoh pada buku referensi)


Contoh Analisis Kualitas Resiko Informal untuk Hypothetical Word Processor


I.2.2.3. Metoda Formal Untuk Pengertian Kualitas Resiko
 Pengujian dengan menggunakan teknik lebih formal untuk mendefinisikan kualitas risk
 Pendekatan ini dapat memetakan kebutuhan, spesifikasi, dan asumsi team proyek yang diinputkan kedalam kualitas resiko spesifik dan efeknya
 Pendekatan dapat merangking resiko menurut prioritasnya dan memperbaikinya dalam perintah selanjutnya
 Pendekatan ini menggunakan Failure Mode and Effect Analysis (FMEA), yaitu merupakan pendekatan formal untuk pemetaan kebutuhan, spesifikasi dan asumsi tim proyek kedalam spesifik quality risk.



Contoh FMEA untuk Hypothetical File Server
 System Function or Feature
Analisis fungsi sistem dimulai dari sini, dalam melakukan breakdown deskripsi dari fungsi sistem yang akan dianalisis bila terlampau detil akan sulit dibaca sedangkan bila terlampau sedikit akan sulit mengetahui failure ada pada fungsi yang mana
 Potential Failure Mode(s) – Quality Risk(s)
* Pada kolom ini terdapat fungsi yang spesifik atau ciri-cirinya tetapi bukan kategorinya.
* Pada kolom ini entrynya seharusnya sudah menemukan suatu failure.
* Quality risk diasosiasikan dengan kehilangan fungsi sistem yang spesifik.
* Tiap spesifik fungsi atau ciri-cirinya dapat mempunyai banyak mode failure.
 Potential effect of failure
Tiap failure mode dapat memberikan efek pada user dari berbagai hal, oleh sebab itu sebaiknya input dalam bentuk umum lebih baik daripada dalam bentuk antisipasi terhadap kemungkinannya.
 Critical
Pada kolom ini diisi ya atau tidak, dimana potential effect akan memberikan/mempunyai konsekuensi yang kritis bagi user.
 Severity (kerumitan)
* Kolom ini merupakan kerumitan yang absolut dari mode failure dalam pertanyaan, mengabaikan segala kemungkinan.
* Digunakan suatu skala dari 1 s/d 5, yaitu :
1. Kehilangan data atau problem keamanan.
2. Kehilangan fungsi tanpa workaround
3. Kehilangan fungsi dengan workaround
4. Kehilangan sebagian fungsi
5. Hal-hal yang kecil.
* Workaround, suatu langkah untuk menghindari bug tanpa memperbaikinya.
 Potential Cause(s) of failure
Kolom ini merupakan daftar dari triger failure mis: OS error, dll.
 Priority
* Priotitas menilai bagaimana keburukan dari mode failure akan mempengaruhi kemampuan suatu perusahaan untuk memasarkan produk tersebut selama siklus hidup pengembangan (SDLC), dengan asumsi bahwa akan dikeluarkan versi release terbaru.
* Skala yang digunakan 1 s/d 5
* Input yang diterima dari umumnya dari Sales Marketing atau Technical Support.
 Dectections Method(s)
* Kolom ini merupakan metoda yang ada atau prosedur untuk mendeteksi seperti aktifitas pengembangan atau vendor testing.
* Deteksi ini diharapkan dapat menemukan problem sebelum mempengaruhi use, diluar setiap test yang dilakukan.
 Dectections
* Angka pada kolom ini mempresentasikan kemungkinan dari metode deteksi yang ada pada kolom sebelumnya.
* Bila metoda deteksi yang digunakan yakin (atau memiliki keyakinan) untuk memperoleh failure model, maka kolom mengidentifikasikan resiko rendah, begitu juga sebaliknya.
* Digunakan skala 1 s/d 5
 RPN (Risk Priority Number)
* Kolom ini akan menunjukan bagaimana pentingnya untuk mentest failure mode secara khusus.
* RPN dihasilkan dari perkalian antara severity, priority value dan detecttion value, oleh sebab itu hasil perkaliannya antara 1 s/d 125.
 Recommended Action
* Kolom ini mengandung satu atau lebih tindakan yang sederhana untuk menaikan resiko prioritas (dalam artian membuat lebih sederhana).
* Untuk mentest, kebanyakan recommended action melibatkan suatu test case yang mempengaruhi pengamanan deteksi.
 Who/When ?
Kolom ini mengindikasikan siapa yang bertanggung jawab untuk setiap recommeded action dan kapan (phase test) dia bertanggung jawab.
 References
Kolom ini menampilkan referensi untuk informasi yang lebih dalam tentang quality risk, biasanya hal ini meliputi spesifikasi produk, dokumen kebutuhan dll.
 Action Result
Merupakan record pengaruh dari aksi yang diambilpada priority, severity, detection dan RPN, kolom ini digunakan setelah implementasi test bukan pada FMEA awal.

I.4. Schedule, Resources, & Budget
I.4.1. Cost, Schedule & Quality, ilustrasi gambar sebagai berikut :
 Arah jarum jam menunjukkan perbaikan selama langkah planning.
 Perbaikan ini merupakan balancing schedule, cost dan kualitas.
 Ketika implmentasi dari test dimulai maka akan sulit untuk mengubah jadwal yang sudah ditetapkan, budget akan meningkat seperti diatas.
 Dengan membatasi pada kotak (batas yang diinginkan) hubungan kualitas akan tampak pada garis ketiganya.

















Cost, Schedule and Quality

I.4.2. Mencocokan Schedule test kedalam proyek
 Pendekatan yang terbaik adalah pendekatan top down :
* Planning
* Configuration memperoleh hw dan sumber daya yang penting dan mentest lab
* Development, membangun test tools; mengcreate urutan test dan test case library; menempatkan laporan test tools pada tempatnya; dokumentasi bagaimana sistem bekerja.
* Test execution, running test; recording status test dan melaporkan hasilnya.
 Kendala yang dihadapi terhadap pendekatan ini antara lain :
* Mahalnya sumber daya
* Lamanya waktu/operasional penggunaan, untuk perangkat yang harus disewa.
* Kehilangan SDM
* Dll.
 Sehingga harus dibuat draft jadwal sebagai berikut : miliestone (lihat gambar).

Contoh Milesstone Testing

I.4.3. Penentuan Sumber daya dan Pembuatan Budget
 Staf
* Karyawan tetap
* Kontraktor
* Konsultan
 Test tools
* Software, meliputi code coverage analyzers, low level diagnostics programs dll.
* Hardware, meliputi oscilloscopes, table goncangan dan getaran, dan peralatan lainnya.
 Facilities & Overhead
* Biaya sewa
* Biaya transportasi
* Workstations
* dll.
 Test systems
* Melputi hw & sw
* Prototipe
* dll.
 External labs
* Penggunaan laboratorium eksternal
* Performance dari lokasi.
* dll