Software Testing : Proses Pengujian

Leave a comment

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.

Software Testing : Artifak

Leave a comment

Artifak yang dihasilkan dalam proses pengujian (testing) yang dikelompokkan berdasarkan orang yang perperan (Role) digambarkan sebagai berikut.

Yang dihasilkan oleh seorang Test Manager:

  • Test Plan, merupakan dokumen yang berisi definisi tujuan dan sasaran pengujian dalam lingkup iterasi (atau proyek), item-item yang menjadi target pengujian, pendekatan yang akan diambil, sumber daya yang dibutuhkan dan point untuk diproduksi.
  • Test Evaluation Summary, mengatur dan menyajikan analisis ringkasan dari hasil test (Test Results) dan ukuran-ukuran kunci pengujian untuk keperluan review dan penilaian yang biasanya dilakukan oleh para pemangku kepentingan kualitas kunci (key quality stakeholder). Selain itu, Test Evaluation Summary mungkin berisi pernyataan umum kualitas relatif dan memberikan rekomendasi untuk pengujian di masa yang akan datang.

More

Software Testing : Strategi Pengujian

Leave a comment

Tujuan dari pengujian perangkat lunak dibagi menjadi 2 yaitu:

1. Langsung

  • Mengidentifikasi error sebanyak-banyaknya pada sebuah perangkat lunak.
  • Melakukan tindakan koreksi pada error-error yang telah teridentifikasi di dalam perangkat lunak dan melakukan pengujian ulang, sehingga kualitas perangkat lunak dapat dikategorikan sebagai acceptable.
  • Melakukan pengujian secara efektif dan efisien sesuai budget dan waktu yang disediakan.

2. Tidak Langsung

  • Sebagai sebuah dokumentasi yang dapat dijadikan acuan untuk digunakan dalam melakukan pencegahan terjadinya error serupa (error prevention).

 

Untuk menaksir kualitas produk, diperlukan beberapa jenis pengujian yang bisa dikategorikan menjadi :

  • Dimensi Kualitas : Pengujian berfokus pada suatu karakteristik mayor kualitas
  • Tingkat Pengujian :  Pengujian strategi target, kategori umum elemen perangkat lunak
  • Tipe Pengujian : Uji individual memiliki suatu tujuan yang spesifik, biasanya terbatas pada sebuah dimensi kualitas.

  

Dimensi Kualitas

Ada beberapa pola untuk menentukan masalah kualitas ; hampir sama dengan masalah-masalah yang muncul di setiap sistem. Ada berbagai cara untuk memaparkan masalah-masalah kualitas, masing-masing didesain untuk membantu kita untuk mengetahui alasan dimensi kualitas yang paling penting dalam konteks kita. Aspek-aspek berikut umumnya ditaksir untuk kebanyakan produk:

  •  Reliability : Perangkat lunak dapat ditebak dan konsisten
  •  Functionality : Perangkat lunak memenuhi use case yang dibutuhkan atau behavior yang diinginkan
  •  Performance : Fokus untuk memastikan fungsionalitas sistem dapat disediakan selama menyediakan kebutuhan non-fungsional dari sistem
  • Usability : Prangkat lunak mudah digunakan oleh end-user

 

Tingkat Pengujian

Pada segmen ini, pengujian dibagi menjadi beberapa bagian yang disebut juga dengan siklus pengujian. Tiap siklus bertugas melakukan pengujian pada target yang berbeda, dari elemen sistem yang terendah seperti unit atau komponen sampai testing pada keseluruhan sistem.

Empat tingkat pengujian yang digunakan mempunyai tujuan berikut

  • Unit Testing : Elemen uji terkecil dari sistem
  • Integration Testing : Unit yang terintegrasi diuji
  • System testing : Aplikasi dan sistem yang lengkap diuji
  • Acceptance Testing : Aplikasi dan sistem yang lengkap diuji oleh end-user untuk menentukan kesiapan pemakaian

 

Tipe Pengujian

Terdapat berbagai macam tipe pengujian, tiap tipe berfokus pada objektif yang harus dipenuhi seperti melakukan pengujian pada karakteristik dan atribut pada perangkat lunak atau melakukan deteksi fault dan failure di dalam sistem. Pengujian dilakukan pada setiap siklus hidup di dalam RUP, pengujian dilakukan pada satu unit kode, unit-unit yang terintegrasi atau keseluruhan sistem atau aplikasi. Di bawah ini merupakan beberapa tipe test yang biasa digunakan:

  • Benchmark Testing
  • ConfigurationTesting
  • Functional Test
  • Installation Test
  • Integrity Test
  • Load Test
  • Performance Test
  • Stress Test

Regression Testing

adalah sebuah strategi pengujian yang dilakukan dengan cara melakukan uji yang sebelumnya telah dilakukan pada suatu perangkat lunak  dan melakukannya lagi pada perangkat lunak yang sama tetapi dengan versi terbaru untuk memastikan agar kualitas perangkat lunak tetap terjaga dan tidak mengalami regresi atau penurunan kualitas justru karena ditambah kapabilitas baru didalamnya. Tujuan dari regression test adalah untuk memastikan 2 hal berikut:

  • Defect atau cacat yang diidentifikasi pada eksekusi awal dari pengujian dapat segera diambil tindakan lanjutan
  • Melakukan pengecekan apakah perubahan pada line kode di dalam sistem malah menjadi sebuah defect atau memunculkan defect yang lama.

 

Strategi Pengujian

Terdapat 2 strategi pengujian yang umum digunakan:

  • “Big Bang Testing” : melakukan pengujian perangkat lunak secara utuh, artinya melakukan pengujian pada pakt perangkat lunak  hanya jika paket tersebut  telah lengkap dan tersedia.
  • “Incremental Testing”: melakukan pengujian perangkat lunak perbagian, artinya pengujian dilakukan pada modul-modul yang telah tersedia (unit testing), pengujian dilanjutkan pada grup dari beberapa modul yang telah diuji yang terhubung dengan modul-modul baru (integration test). Setelah keseluruhan paket perangkat lunak selesai dilakukan maka dilakukan system test, yaitu melakukan pengujian terhadap paket perangkat lunak secara utuh.

 

Terdapat 2 strategi pengujian incremental : bottom-up dan top-down

  • Top-down testing: Pengujian dilakukan pertama pada modul dengan struktur paling kompleks dan memiliki hierarki paling tinggi di dalam perangkat lunak (main modul) dan berlanjut sampai pada modul dengan level terendah.
  • Bottom-up testing: Pengujian dilakukan dimulai dengan modul dengan hierarki paling rendah berlanjut sampai main modul.

Software Testing : Definisi dan Tujuan

Leave a comment

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.