Proses Testing

10.1. Proses Testing

Perencanaan, perancangan dan performa dari testing ditangani seluruhnya dalam proses pengembangan software. Kegiatan ini dibagi menjadi beberapa fase, diawali pada tahap perancangan dan diakhiri ketika software diinstall pada sisi pelanggan. Proses testing ini digambarkan dalam gambar

10.1.1. Menentukan Fase Metodologi Testing

Masalah utama dalam harus dihadapi dalam metodologi testing :  Kesesuaian dengan standar kualitas software yang dibutuhkan  Strategi testing software

Keputusan tentang dua masalah diatas adalah dasar dan harus dibuat sebelum perencanaan dimulai :

Menentukan Metodologi Testing

Merencanakan Testing

Merancang Testing

Melakukan Testing

Gambar 10.1. Proses Testing

Menentukan standar kualitas perangkat lunak yang sesuai

Tingkat standar mutu yang dipilih untuk proyek terutama tergantung pada karakteristik dari aplikasi perangkat lunak.

Contoh:

1. Sebuah paket perangkat lunak untuk monitor tempat tidur pasien rumah sakit memerlukan standar perangkat lunak berkualitas tertinggi dengan mempertimbangkan kemungkinan terburuk akibat kegagalan perangkat lunak.

2. Sebuah paket yang dikembangkan untuk menangani informasi umpan balik untuk karyawan internal organisasi program pelatihan dapat dilakukan dengan standar kualitas perangkat lunak

tingkat menengah, dengan asumsi bahwa biaya kegagalan relatif rendah (atau jauh lebih rendah dibandingkan dengan Contoh 1).

3. Sebuah paket perangkat lunak telah dikembangkan untuk dijual ke berbagai organisasi luas. Prospek penjualan membenarkan standar mutu yang lebih tinggi dari paket perangkat lunak akan custom-made tidak memiliki kesamaan karakteristik dengan pengembang untuk melayani

pelanggan tunggal. Contoh-contoh ini menggambarkan kriteria utama yang akan diterapkan ketika memilih standar kualitas

perangkat lunak: evaluation of nature dan magnitude of expected damages diharapkan kerusakan pada kasus kegagalan sistem. Kerusakan ini dapat mempengaruhi pelanggan dan pengguna di satu sisi, dan pengembang di sisi lain. Secara umum, semakin tinggi tingkat yang diharapkan dari kerusakan akibat kegagalan, semakin tinggi standar kualitas perangkat lunak yang sesuai. Jenis kerusakan tertentu kepada pelanggan dan pengguna serta pengembang tercantum pada Tabel 10.1.

Tabel 10.1. Klasifikasi Kerugian dari Kerusakan Software

a) Kerusakan terhadap pelanggan atau pengguna Tipe Kerusakan

Contoh

Membahayakan

kehidupan Sistem monitoring pasien rumah sakit manusia

keselamatan

Sistem persenjataan luar angkasa Mempengaruhi penggunaan fungsi organisasi Penjualan sistem e-business yang penting dan tidak ada sistem pengganti

Sistem inventori multi-ware house Berakibat terhadap fungsi dari sebuah Peralatan elektronik yang terkomputerisasi perusahaan sen Mempengaruhi pemenuhan pengelompokan system penjualan Front-Desk dapat diganti fungsi tetapi sudah tersedia sebuah pengganti

oleh mekanisme manual

Mempengaruhi fungsi dari perangkat lunak  Tanggapan yang lambat untuk transaksi untuk aplikasi bisnis

sebuah system penjualan point-of- sale (POS)

 Karena sebuah kesalahan, informasi yang diberikan secara teratur pada satu layar  Karena sebuah kesalahan, informasi yang diberikan secara teratur pada satu layar

Mempengaruhi berfungsinya piranti perangkat  Game komputer lunak untuk pelanggan khusus

 Pendidikan Pribadi  Word prosesor

Mempengaruhi fungsi dari aplikasi firmware  Aplikasi pengatur dalam rumah tangga tapi tanpa mempengaruhi

tanpa fungsionalitas yang merugikan  Kegagalan sistem sekunder (misalnya, yang menampilkan suhu luar pada system automobile)

Ketidaknyamanan pengguna tetapi tidak  Penyimpangan tetapi tidak menyimpang mencegah pemenuhan

dari tampilan asli

Tabel 10.1. Klasifikasi Kerugian terhadap Pengembang Software

b) Kerugian terhadap pengembang software Tipe Kerusakan

Contoh

Kerugian keuangan Kerusakan yang mengakibatkan luka fisik Kerusakan yang dibayar oleh organisasi karena mall fungsi Pengembalian uang pembelian dari pelanggan Pembiayaan yang tinggi terhadap perbaikan sistem

Kerugian non kuantitatif Dampak terhadap penjualan mendatang Mengurangi penjualan saat ini

Ada beberapa hal yang harus diikutkan dalam menentukan strategi testing software :  Strategi testing : apakah seharusnya strategi testing big bang atau incremental diadopsi ?

 Bagian mana dari perencanaan testing yang seharusnya dilaksanakan berdasarkan model testing white box ?  Bagian mana dari perencanaan testing yang seharusnya dilakukan berdasarkan model testing otomatis ?

10.1.2. Perencanaan Testing

Perencanaan testing melibatkan :  Unit testing  Integrasi testing  Sistem testing

Beberapa pertanyaan dalam testing meliputi :  Apa yang akan ditesting ?  Source mana yang akan dilakukan sebagai kasus testing ?  Siapa yang melaksanakan testing ?  Dimana testing dilaksanakan ?  Kapan mengakhiri testing ?

Persoalan yang mempengaruhi level resiko software Persoalan aplikasi /modul :

 Magnitude (besarnya aplikasi)  Kerumitan dan kesulitan  Prosentase dari

Untuk apa pengujian diadakan?

Pendekatan langsung untuk pengujian yang sempurna akan merekomendasikan penuh dan perangkat lunak komprehensif dibutuhkan untuk melakukan unit test untuk semua unit individu, integrasi tes untuk semua unit integrasi, dan sistem test untuk menguji paket perangkat lunak secara keseluruhan.

Menerapkan rencana " straightforward " memastikan kualitas perangkat lunak tingkat atas tetapi memerlukan investasi sumber daya yang luas dan jadwal yang diperpanjang. Pertanyaan- pertanyaan tertentu pasti akan timbul sehubungan dengan situasi umum yang berkaitan dengan manfaat dari pendekatan semacam itu. Sebagai contoh:

 Apakah dibenarkan untuk melakukan unit test untuk sebuah modul terdiri dari 98% software yang digunakan kembali?

 Apakah tes unit wajib untuk modul sederhana yang menggambarkan versi ke-12 dari modul dasar yang berulang kali diterapkan oleh tim pengembang selama tiga tahun terakhir?

Hanya dalam kasus yang jarang itu dibenarkan untuk menguji "keseluruhan". Biasanya, kelayakan pengujian "keseluruhan" sangat terbatas. Terlepas dari kinerja daftar tes ditentukan dalam kontrak atau diperlukan oleh prosedur pengembang (misalnya beban tes untuk sistem secara keseluruhan), beberapa pertimbangan urutan preferensi kami untuk tes yang akan diterapkan. Faktor-faktor dalam memutuskan suatu pengujian:

 unit modul yang harus diuji  integrasi yang harus diuji  menentukan prioritas pengalokasian sumber daya pengujian kepada individu perangkat

lunak

Dalam menentukan apa yang harus dimasukkan dan apa yang dikecualikan dari sistem tes, tes unit dan integrasi yang sudah direncanakan harus dipertimbangkan. Untuk kualitas perangkat lunak aplikasi dan modul yang tidak dicakup oleh unit tes, integrasi dan sistem tes, kami mengandalkan cek kode yang dilakukan oleh programmer dan pemimpin timnya dan inspeksi kode dan walkthrough yang diprakarsai oleh tim pengembang.

Rating unit, integrasi dan aplikasi

Metode untuk unit rating (modul), integrasi dan aplikasi untuk menentukan prioritas dalam rencana pengujian didasarkan pada dua faktor:

 Faktor A: tingkat kerusakan. Tingkat kerusakan hasil dalam kasus modul atau aplikasi gagal.

 Faktor B: tingkat risiko perangkat lunak. Tingkat risiko merupakan probabilitas kegagalan.

10.1.3. Rancangan Testing

Template dari Rencana Testing Software (STP=Software Test Plan) : 1 Lingkup dari testing

1.1 Paket software yang akan ditest (nama, versi dan perbaikan) 1.2 Dokumen yang menyediakan dasar dari perencanaan testing (nama dan versi dari tiap dokumen)

2 Lingkungan testing 2.1 Tempat testing 2.2 Hardware dan konfigurasi organisasi yang dibutuhkan 2.3 Partisipasi organisasi 2.4 Orang yang berkedudukan/berpengaruh yang dibutuhkan 2.5 Persiapan dan pelatihan yang diperlukan oleh tim testing

3 Perincian testing 3.1 Identifikasi testing

3.2 Tujuan testing 3.3 Referensi berseberangan terhadap rancangan dokumen yang relevan dan kebutuhan dokumen 3.4 Kelas testing 3.5 Level testing (unit, integrasi, sistem) 3.6 Kebutuhan kasus testing 3.7 Kebutuhan kusus (pengukuran terhadap response time, kebutuhan keamanan) 3.8 Data yang akan dicatat

4 Jadwal testing (untuk masing-masing test/ group test) termasuk perkiraan waktu 4.1 Persiapan 4.2 Testing 4.3 Perbaikan kesalahan 4.4 Testing mundur

Tes/uji desain dilakukan berdasarkan rencana pengujian perangkat lunak yang didokumentasikan oleh STP. Prosedur Pengujian dan uji kasus database test / file didokumentasikan dalam "Prosedur pengujian perangkat lunak" (software test procedure) dokumen dan " file uji kasus" (test case file) dokumen atau dalam satu dokumen yang disebut " deskripsi test perangkat lunak" (software test description/STD). Sebuah template untuk STD disajikan dalam Frame 10.3.

Frame 10.3 Deskripsi Tes Perangkat Lunak (STD) - template

1 Ruang Lingkup tes

1.1 paket perangkat lunak yang diuji (nama, versi dan revisi)

1.2 Dokumen-dokumen yang menyediakan dasar untuk tes yang dirancang (nama dan versi untuk setiap dokumen)

2 Lingkup Pengujian (untuk masing-masing tes)

2.1 Uji identifikasi (rincian tes didokumentasikan dalam STP)

2.2 Keterangan rinci dari sistem operasi dan konfigurasi hardware dan pengaturan switch yang diperlukan untuk tes

2.3 Petunjuk untuk memuat perangkat lunak

3 Proses pengujian

3.1 Petunjuk untuk input, rincian setiap langkah dari proses input

3.2 Data yang akan dicatat selama pengujian

4 uji kasus (untuk setiap kasus)

4.1 Rincian identifikasi uji kasus

4.2 Input data dan pengaturan sistem

4.3 Hasil sementara yang diharapkan (jika berlaku)

4.4 Hasil yang diharapkan (numerik, pesan, aktivasi peralatan, dll)

5 Tindakan yang harus diambil jika terjadi kegagalan program / penghentian

6 Prosedur untuk diterapkan sesuai dengan ringkasan hasil tes

10.1.4. Penerapan Testing

Umumnya, tahap pelaksanaan tes terdiri dari serangkaian tes, koreksi dari kesalahan yang terdeteksi dan re-tes (uji regresi). Pengujian mencapai akhir ketika hasil tes ulang memuaskan para pengembang. Proses tahap implementasi diilustrasikan pada Gambar 10.2. Pengujian dilakukan dengan menjalankan uji kasus sesuai dengan prosedur pengujian. Dokumentasi prosedur pengujian dan uji kasus data-base / file terdiri dari "deskripsi test perangkat lunak" (software test description/STD), disajikan di Frame 10.3.

Template Laporan Testing Software : 1 Testing identifikasi, tempat, jadwal dan partisipan

1.1 Testing identifikasi software (nama, versi, perbaikan) 1.2 Dokumen yang menyediakan dasar testing (nama, versi tiap dokumen) 1.3 Tempat testing 1.4 Waktu mulai dan selesai untuk tiap bagian testing 1.5 Anggota tim testing 1.6 Partisipan yang lain 1.7 Waktu yang diperlukan untuk melakukan testing

2 Lingkungan testing 2.1 Konfigurasi hardware dan perusahaan 2.2 Persiapan dan Pelatihan sebelum testing

3 Hasil testing 3.1 Identifikasi testing 3.2 Hasil kasus testing Identifikasi kasus testing Identifikasi tester Hasil nya : OK atau Gagal Jika gagal: gambaran yang jelas dari hasilnya/ permasalahan

4 Tabel kesimpulan untuk total keseluruhan kesalahan, sebarannya dan tipe nya 4.1 Kesimpulan dari testing yang dilakukan 4.2 Perbandingan dengan hasil testing sebelumnya

5 Kejadian khusus dan usulan/pendapat tester 5.1 Kejadian khusus dan tanggapan yang tidak terperkirakan 5.2 Penemuan permasalahan selama testing 5.3 Usulan untuk perubahan lingkungan testing termasuk persiapan testing 5.4 Perubahan untuk perubahan atau perbaikan dalam prosedur testing dan file kasus testing