Pengujian perangkat lunak tidak diragukan lagi merupakan konsumen terbesar dari sumber daya jaminan kualitas perangkat lunak. Dalam sebuah survei yang dilakukan pada bulan November 1994, Perry (1995) menemukan bahwa rata-rata, 24% dari anggaran pembangunan proyek dialokasikan untuk pengujian. Selain itu, 32% dari anggaran manajemen proyek direncanakan untuk kegiatan pengujian. Sehubungan dengan sumber daya waktu, rata-rata 27% dari waktu proyek adalah jadwal untuk pengujian. Peserta Survei juga mengindikasikan bahwa mereka berencana untuk mengalokasikan waktu secara substansial lebih (45% rata-rata) untuk percobaan tapi bahwa tekanan biasanya timbul menjelang akhir dari proyek dan umumnya manajer proyek dipaksa untuk mengurangi lamanya penjadwalan waktu pengujian.

 

Definisi

Definisi klasik menurut Myers (1979),

Pengujian adalah proses menjalankan program dengan maksud menemukan kesalahan.

Definisi tersebut menyangkut kegiatan mulai dari cek kode yang dilakukan oleh seorang pemimpin tim untuk menjalankan percobaan dari perangkat lunak yang dilakukan oleh seorang rekan, serta tes yang dilakukan oleh suatu unit pengujian, semua bisa dianggap kegiatan pengujian.

Definisi lain menurut IEEE

  1. Proses mengoperasikan sistem atau komponen dalam kondisi tertentu, mengamati atau merekam hasil, dan membuat evaluasi terhadap beberapa aspek dari sistem atau komponen.
  2. Proses analisis item perangkat lunak untuk mendeteksi perbedaan antara yang ada dan kondisi yang diperlukan (yaitu  bug) dan mengevaluasi fitur-fitur dari item perangkat lunak

 

Definisi menurut Galin :

Pengujian perangkat lunak adalah proses formal yang dilakukan oleh tim khusus  pengujian di mana suatu unit perangkat lunak, beberapa unit perangkat lunak yang terintegrasi atau paket perangkat lunak yang diperiksa secara keseluruhan dengan menjalankan program pada komputer.

Semua pengujian yang berkaitan dilakukan menurut prosedur uji yang disetujui pada kasus uji yang disetujui.

 

Karakteristik utama dari pengujian perangkat lunak :

  • Formal-Rencana uji perangkat lunak merupakan bagian dari pengembangan proyek dan rencana mutu,    dijadwalkan di muka dan item sentral muncul dalam perjanjian pembuatan perangkat lunak yang ditandatangani antara pelanggan dan pengembang. Dengan kata lain,  pengujian perangkat lunak secara ad hoc oleh rekan atau pemeriksaan berkala oleh pemimpin tim pemrograman tidak dapat dianggap sebagai tes perangkat lunak.
  • Tim penguji khusus – Sebuah tim independen atau eksternal konsultan yang mengkhususkan diri dalam pengujian ditugaskan untuk melaksanakan tugas ini terutama dalam rangka untuk menghilangkan bias dan untuk menjamin pengujian yang efektif oleh para profesional terlatih. Selain itu, secara umum diterima bahwa tes yang dilakukan oleh pengembang sendiri akan menghasilkan hasil yang buruk, sebagai individu yang mengembangkan produk asli akan menemukan kesulitan untuk mengungkapkan kesalahan yang mereka tidak diidentifikasikan lebih awal. Namun, unit test terus dilakukan oleh pengembang di banyak organisasi.
  • Menjalankan program – Segala bentuk kegiatan jaminan kualitas yang tidak melibatkan menjalankan perangkat lunak, untuk pemeriksaan contoh kode, tidak dapat dianggap sebagai kegiatan ujian
  • Prosedur pengujian disetujui – Proses pengujian yang dilakukan berdasarkan suatu rencana uji dan prosedur pengujian yang telah disetujui sebagai sesuai dengan prosedur SQA diadopsi oleh organisasi yang berkembang
  • Uji kasus disetujui – kasus uji yang akan diperiksa didefinisikan secara penuh oleh rencana uji. Tidak ada kelalaian atau penambahan diharapkan terjadi selama pengujian. Dengan kata lain, sekali proses telah dimulai, Penguji tidak diperkenankan untuk menerapkan kebijaksanaan dengan menghilangkan batu ujian jika dianggap berlebihan atau dengan menambahkan ujian baru, meskipun mungkin menjanjikan.

 

Tujuan Pengujian Perangkat Lunak

Tujuan Langsung :

  • Untuk mengidentifikasi dan mengungkapkan sebagai kesalahan sebanyak mungkin  dalam perangkat lunak yang diuji.
  • Untuk membawa perangkat lunak diuji, setelah memperbaiki kesalahan yang diidentifikasi dan melakukan pengujian ulang, pada tingkat kualitas yang memadai.
  • Untuk melakukan tes yang diperlukan secara efisien dan efektif, dalam keterbatasan anggaran dan penjadwalan.

Tujuan Tidak Langsung :

  • Untuk menyusun catatan kesalahan perangkat lunak untuk digunakan dalam pencegahan kesalahan (dengan tindakan perbaikan dan pencegahan).

Dalam banyak hal, disiplin tes bertindak sebagai penyedia layanan kepada disiplin lain. Pengujian berfokus terutama pada evaluasi atau menilai kualitas produk, menggunakan sejumlah praktek inti:

  1. Menemukan dan dokumen kegagalan dalam produk perangkat lunak: cacat,  masalah
  2. Menyarankan manajemen pada kualitas yang dirasakan pada perangkat lunak
  3. Mengevaluasi asumsi yang dibuat dalam spesifikasi rancangan dan persyaratan melalui demonstrasi nyata
  4. Memvalidasi bahwa produk perangkat lunak yang dibuat bekerja sesuai rancangan
  5. Memvalidasi bahwa persyaratan diterapkan secara tepat
Sebuah perbedaan menarik yang ada antara pengujian dan disiplin ilmu RUP lain :
Pada dasarnya disiplin Test bertugas menemukan dan mengekspos kelemahan dalam produk perangkat lunak. Untuk mendapatkan manfaat terbesar, kita memerlukan filosofi atau pola pikir yang berbeda dari yang digunakan dalam disiplin Persyaratan, Analisis dan Desain, dan Implementasi. Sementara tiga disiplin tersebut fokus pada kelengkapan, konsistensi, dan kebenaran, disiplin Test berfokus pada apa yang hilang, salah, atau tidak konsisten.
Upaya pengujian yang baik didorong oleh pertanyaan seperti ini:
  • Bagaimana suatu perangkat lunak dapat gagal?
  • Dalam situasi apa yang mungkin ada sehingga perangkat lunak ini gagal bekerja sesuai perkiraan?
Disiplin Test menantang asumsi, risiko, dan ketidakpastian yang melekat dalam karya disiplin lain, dan mengalamatkan kekhawatiran mereka menggunakan demonstrasi nyata dan evaluasi yang tidak memihak. Kita ingin menghindari dua hal ekstrem potensial:
  • Pendekatan yang tidak sesuai atau secara efektif menantang perangkat lunak dalam mengekspos kelemahan dan  masalah yang melekat.
  • Pendekatan yang tidak tepat negatif atau merusak akan mengadopsi suatu pendekatan negatif, kita  merasa tidak mungkin untuk pernah mempertimbangkan produk perangkat lunak dari kualitas yang dapat diterima. Mengambil pendekatan seperti itu dapat menjauhkan upaya Test dari disiplin lain.
Informasi yang disajikan dalam berbagai survei dan esai menyatakan bahwa pengujian perangkat lunak menghabiskan 30% sampai 50% dari biaya pengembangan perangkat lunak. Oleh karena itu, agak mengejutkan untuk dicatat bahwa sebagian besar orang percaya bahwa perangkat lunak komputer belum diuji dengan baik sebelum itu disampaikan. Kontradiksi ini berakar dalam beberapa isu kunci:
  1. Pengujian perangkat lunak sangat sulit. Bagaimana cara kita mengukur berbagai kondisi dimana program yang diberikan dapat berhasil atau gagal?
  2. Biasanya, pengujian dilakukan tanpa metodologi yang jelas, menciptakan hasil yang bervariasi dari proyek untuk proyek dan dari organisasi ke organisasi. Sukses bergantung terutama pada faktor kualitas dan keterampilan individu dalam tim penguji
  3. Alat Produktivitas digunakan secara tidak efisien atau tidak sama sekali, yang membuat aspek pengujian melelahkan dan tidak teratur. Selain kurangnya pelaksanaan tes otomatis, banyak upaya pengujian dilakukan tanpa alat yang memungkinkankita secara efektif mengelola luasnya Data Uji dan Hasil Uji
  4. Fleksibilitas dari penggunaan dan kompleksitas perangkat lunak membuat pengujian lengkap menjadi tujuan yang mustahil. Penggunaan strategi yang disusun dan alat-alat yang tepat dapat meningkatkan produktivitas dan efektivitas pengujian perangkat lunak.

 

Referensi :

Galin, Daniel. Software Quality Assurance From Theory to Implementation. Pearson. 2004.

Kruchten, Philippe. The Rational Unified Process : An Introduction, Third Edition.

About these ads