Isu-isu utama yang akan diangkat berkaitan dengan pelaksanaan pengujian adalah efektivitas dan efisiensi pengujian. Dengan kata lain, usaha yang terus menerus untuk diarahkan dalam pengurangan persentase kesalahan tidak terdeteksi yang tersisa di perangkat lunak atau sistem yang diuji pada satu sisi, dan untuk kinerja pengujian dengan mnghabiskan sumber daya lebih sedikit di sisi lain.

Perencanaan, perancangan dan pelaksanaan pengujian dilakukan selama proses pengembangan perangkat lunak. Kegiatan ini dibagi secara bertahap, dimulai pada tahap desain dan berakhir ketika perangkat lunak diinstal di lokasi pelanggan.

Isu utama bahwa metodologi pengujian harus bersaing adalah:

  • Standar kualitas perangkat lunak yang diperlukan,
  • Strategi pengujian perangkat lunak.

Keputusan tentang kedua isu ini sangat mendasar dan harus dilakukan sebelum perencanaan dimulai.

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 memonitor pasien tidur rumah sakit yang membutuhkan perangkat lunak standar kualitas tertinggi dengan mempertimbangkan konsekuensi terburuk jika perangkat lunak gagal atau tidak berjalan semestinya.
  • Contoh 2: Sebuah paket yang dikembangkan untuk menangani informasi umpan balik untuk karyawan internal organisasi program pelatihan bisa dilakukan dengan standar kualitas perangkat lunak tingkat menengah, dengan asumsi bahwa biaya kegagalan relatif rendah (atau jauh lebih rendah dibandingkan dengan Contoh 1).
  • Contoh 3: Sebuah paket perangkat lunak telah dikembangkan untuk dijual ke berbagai organisasi. Prospek penjualan membenarkan standar kualitas yang lebih tinggi daripada sebuah paket perangkat lunak buatan memiliki karakteristik serupa belum dikembangkan untuk melayani pelanggan tunggal.

 

Contoh-contoh ini menggambarkan kriteria utama yang akan diterapkan ketika memilih standar kualitas perangkat lunak: evaluasi sifat dan besarnya kerusakan yang diperkirakan jika terjadi kegagalan sistem. Kerusakan ini dapat mempengaruhi pelanggan dan pengguna di satu sisi, dan pengembang di sisi lain. Secara umum, semakin tinggi tingkat yang dapat diperkirakan dari kerusakan akibat kegagalan, semakin tinggi standar kualitas yang sesuai adri perangkat lunak.

Menentukan strategi pengujian perangkat lunak

Isu-isu yang harus diputuskan antara lain:

  • Strategi pengujian: Apakah strategi pengujian bigbang atau incremental yang akan diadopsi? Jika pengujian incremental  lebih baik, apakah  pengujian dilakukan secara bottom-up atau top-down?
  • Bagian mana dari rencana pengujian yang harus dilakukan sesuai dengan model white box testing?
  • Bagian mana dari rencana pengujian yang harus dilakukan sesuai dengan model pengujian otomatis?

 

Perencanaan pengujian

Pengujian yang akan direncanakan meliputi:

  • Unit pengujian
  • Integrasi pengujian
  • Sistem pengujian

Sementara menghadapi tes unit dengan unit kecil dari perangkat lunak atau modul, integrasi menghadapi tes dengan beberapa unit yang menggabungkan ke dalam sistem. Sistem tes merujuk ke paket perangkat lunak seluruh / sistem. Adalah tugas perencana untuk mempertimbangkan hal-hal berikut sebelum memulai rencana tes khusus:

  • Apa yang akan diuji?
  • Sumber-sumber apa yang digunakan untuk uji kasus?
  • Siapa yang melakukan pengujian?
  • Dimana tempat melakukan pengujian?
  • Kapan harus mengakhiri pengujian?

 

Apa yang akan diuji?

Pendekatan langsung untuk pengujian yang sempurna akan merekomendasikan rencana pengujian perangkat lunak lengkap dan komprehensif yang  melakukan uji unit untuk semua unit individu, uji integrasi  untuk semua integrasi unit, dan uji sistem untuk menguji paket perangkat lunak secara keseluruhan. Menerapkan rencana secara “langsung” memang  memastikan kualitas perangkat lunak yang tinggi tetapi juga memerlukan investasi sumber daya yang luas dan jadwal yang panjang.

Berkaitan dengan itu , pertanyaan-pertanyaan tertentu yang umum akan muncul :

Situasi yang berkaitan dengan manfaat dari pendekatan semacam itu. Sebagai contoh:

  • Apakah dibenarkan untuk melakukan pengujian unit  untuk sebuah modul yang terdiri dari 98% perangkat lunak yang reuse ?
  • Apakah pengujian unit wajib dilakukan pada  modul sederhana yang menampilkan modul versi 12 dari modul dasar yang digunakan berulang kali oleh tim pengembang selama tiga tahun terakhir?

Hanya dalam kasus yang jarang itu dibenarkan untuk menguji “segalanya”. Biasanya, kelayakan pengujian “segalanya” sangat terbatas. Terlepas dari kinerja dari daftar tes yang ditentukan dalam kontrak atau diperlukan oleh prosedur pengembang (misalnya beban tes untuk sistem secara keseluruhan), beberapa pertimbangan untuk tes yang akan diterapkan, antara lain :

  • Unit modul mana yang harus diuji?
  • Integrasi mana yang harus diuji?
  • Prioritas menentukan pengalokasian sumber daya pengujian kepada sistem aplikasi perangkat lunak individu. Akibatnya,aplikasi yang mendapat prioritas rendah  diuji dengan hanya beberapa jenis tes atau tidak termasuk dalam pengujian sistem sama sekali.

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

 

Rating Unit, Integrasi dan Aplikasi

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

  • Faktor A: Keparahan tingkat kerusakan.Seberapa parah tingkat yang dihasilkan jika suatu modul atau aplikasi gagal.
  • Faktor B: Tingkat resiko perangkat lunak. Tingkat risiko merupakan probabilitas kegagalan. Dalam rangka untuk menentukan tingkat risiko unit, modul, integrasi atau aplikasi, isu-isu yang mempengaruhi risiko memerlukan pemeriksaan. Masalah ini dapat diklasifikasikan sebagai modul / masalah aplikasi dan programmer.

 

Isu yang mempengaruhi tingkat risiko perangkat lunak

1. Masalah Modul / aplikasi

  • Magnitude
  • Kompleksitas dan kesulitan
  • Persentase dari perangkat lunak asli (vs persentase  perangkat lunak yang digunakan kembali)</div>

2. Masalah Programmer

  • Kualifikasi profesional
  • Pengalaman pada subjek modul tertentu
  • Ketersediaan dukungan profesional (cadangan dari pengetahuan dan pengalaman)
  • Kenalan dengan programmer dan kemampuan untuk mengevaluasi kemampuannya

Penting untuk dicatat bahwa ada masalah yang merupakan kasus khusus dari masalah umum dalam menentukan intensitas kegiatan jaminan mutu yang cukup. Oleh karena itu, ada logika yang mendasari dalam mencapai  prioritas pengujian perangkat lunak yang lebih tinggi.

Para perencana harus mempertimbangkan dua sumber utama kasus uji – contoh kasus uji kehidupan nyata dan / atau uji kasus sintetik – yang paling tepat dengan kebutuhan mereka. Setiap komponen dari rencana pengujian, berurusan dengan pengujian unit, integrasi atau  sistem, membutuhkan keputusan individu tentang uji kasus dan sumber mereka masing-masing :

  • Penggunaan sumber tunggal atau gabungan kasus uji atau keduanya
  •  Berapa banyak uji kasus dari masing-masing sumber harus dipersiapkan
  • Karakteristik uji kasus

 

Siapa yang melakukan pengujian?

Siapa yang akan melakukan berbagai tes ditentukan pada tahap perencanaan :

  • Uji integrasi ,  terutama uji unit, umumnya dilakukan oleh tim pengembangan perangkat lunak. Dalam beberapa kasus itu adalah unit pengujian yang melakukan pengujian.
  • Uji sistem biasanya dilakukan oleh tim uji independen (pengujian tim internal atau pengujian tim konsultan eksternal).
  • Dalam kasus sistem perangkat lunak yang lebih besar, lebih dari satu tim pengujian dapat digunakan untuk melakukan pengujian sistem. Keputusan prasyarat yang akan dibuat pada kasus yang harus dipertimbangkan adalah alokasi tes sistem antara internal dan tim pengujian eksternal.