Testing (Pengujian Perangkat Lunak)
Adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain, dan pengkodean. Pentingnya pengujian perangkat lunak dan implikasinya yang mengacu pada kualitas perangkat lunak tidak dapat terlalu ditekan karena melibatkan sederetan aktivitas produksi di mana peluang terjadinya kesalahan manusia sangat besar dan arena ketidakmampuan manusia untuk melakukan dan berkomunikasi dengan sempurna maka pengembangan perangkat lunak diiringi dengan aktivitas jaminan kualitas. Meningkatnya visibilitas (kemampuan) perangkat lunak sebagai suatu elemen sistem dan “biaya” yang muncul akibat kegagalan perangkat lunak, memotivasi dilakukannya perencanaan yang baik melalui pengujian yang teliti. Pada dasarnya, pengujian merupakan satu langkah dalam proses rekayasa perangkat lunak yang dapat dianggap sebagai hal yang merusak daripada membangun.
Desain Test Case:
- Pengujian white-box
- pengujian black-box
- Integrasi Bottom-Up
- Integrasi Top-Down.
Pengujian white-box
berfokus pada struktur control program. Test case dilakukan untuk memastikan bahwa semua statemen pada program telah dieksekusi paling tidak satu kali selama pengujian dan bahwa semua kondisi logis telah diuji. Pengujian basic path, tehnik pengujian white-box, menggunakan grafik (matriks grafiks) untuk melakukan serangkaian pengujian yang independent secara linear yang akan memastikan cakupan.
Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program dan pengujian loop menyempurnakan tehnik white-box yang lain dengan memberikan sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi. Pengujian black-box didesain untuk mengungkap kesalahan pada persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program.
berfokus pada struktur control program. Test case dilakukan untuk memastikan bahwa semua statemen pada program telah dieksekusi paling tidak satu kali selama pengujian dan bahwa semua kondisi logis telah diuji. Pengujian basic path, tehnik pengujian white-box, menggunakan grafik (matriks grafiks) untuk melakukan serangkaian pengujian yang independent secara linear yang akan memastikan cakupan.
Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program dan pengujian loop menyempurnakan tehnik white-box yang lain dengan memberikan sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi. Pengujian black-box didesain untuk mengungkap kesalahan pada persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program.
Tehnik pengujian black-box
berfokus pada domain informasi dari perangkat lunak, dengan melakukan test case dengan menpartisi domain input dari suatu program dengan cara yang memberikan cakupan pengujian yang mendalam.
gambar perbandingan pengujian black box dan whiteboxMetode pengujian graph-based
mengeksplorasi hubungan antara dan tingkah laku objek-objek program. Partisi ekivalensi membagi domain input ke dalam kelas data yang mungkin untuk melakukan fungsi perangkat lunak tertentu. Analisis nilai batas memeriksaa kemampuan program untuk menangani data pada batas yang dapat diterima.Metode pengujian yang terspesialisasi meliputi sejumlah luas kemampuan perangkat lunak dan area aplikasi. GUI, arsitektur client/ server, dokumentasi dan fasilitas help dan sistem real time masing-masing membutuhkan pedoman dan tehnik khusus untuk pengujian perangkat lunak.
mengeksplorasi hubungan antara dan tingkah laku objek-objek program. Partisi ekivalensi membagi domain input ke dalam kelas data yang mungkin untuk melakukan fungsi perangkat lunak tertentu. Analisis nilai batas memeriksaa kemampuan program untuk menangani data pada batas yang dapat diterima.Metode pengujian yang terspesialisasi meliputi sejumlah luas kemampuan perangkat lunak dan area aplikasi. GUI, arsitektur client/ server, dokumentasi dan fasilitas help dan sistem real time masing-masing membutuhkan pedoman dan tehnik khusus untuk pengujian perangkat lunak.
Integrasi Top-Down
adalah pendekatan incremental dengan menggerakkan ke bawah melalui hirarki control, dimulai dengan control utama. Strategi intergrasi top-down memeriksa control mayor atau keputusan pada saat awal di dalam proses pengujian. Pada struktur program yang difaktorkan dengan baik, penarikan keputusan terjadi pada tingkat hirarki yang lebih tinggi sehingga terjadi lebih dulu.
Strategi top-down kelihatannya tidak sangat rumit, tetapi di dalam praktenya banyak menimbulkan masalah logistic. Biasanya masalah ini terjadi jika dibutuhkan pemrosesan di dalam hirarki pada tingkat rendah untuk menguji secara memadai tingkat yang lebih tinggi.
Strategi top-down kelihatannya tidak sangat rumit, tetapi di dalam praktenya banyak menimbulkan masalah logistic. Biasanya masalah ini terjadi jika dibutuhkan pemrosesan di dalam hirarki pada tingkat rendah untuk menguji secara memadai tingkat yang lebih tinggi.
Pengujian Integrasi Bottom-up
memulai konstruksi dan pengujian dengan modul atomic (modul pada tingkat paling rendah pada struktur program). Karena modul diintegrasikan dari bawah ke atas, maka pemrosesan yang diperlukan untuk modul subordinate ke suatu tuingkat yang diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi. Strategi integrasi bottom-up dapat diimplementasi dengan langkah-langkah:
memulai konstruksi dan pengujian dengan modul atomic (modul pada tingkat paling rendah pada struktur program). Karena modul diintegrasikan dari bawah ke atas, maka pemrosesan yang diperlukan untuk modul subordinate ke suatu tuingkat yang diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi. Strategi integrasi bottom-up dapat diimplementasi dengan langkah-langkah:
- modul tingkat rendah digabung ke dalam cluster (build) yang melakukan subfungsi perangkat lunak spesifik.
- Driver (program control untuk pengujian) ditulis untuk mengkoordinasi input dan output test case
- cluster diuji
- driver diganti dan cluster digabungkan dengan menggerakkannya ke atas di dalam struktur program.
Uji Sistem
Uji sistem: Sistem software diuji keseluruhan. Ini memverifikasi semua elemen secara langsung untuk memastikan bahwa semua fungsi dan performance sistem diterima dalam lingkungan target.
Terbagi menjadi 4 bagian yaitu:Uji sistem: Sistem software diuji keseluruhan. Ini memverifikasi semua elemen secara langsung untuk memastikan bahwa semua fungsi dan performance sistem diterima dalam lingkungan target.
- Recovery Testing : sistem tes yang menekan software untuk gagal dengan cara yang bervariasi dan memverifikasi perbaikan sendiri dengan baik
- Security Testing : usaha untuk memverifikasi mekanisme perlindungan yang dibuat dalam sistem apakah akan melindunginya dengan semestinya.
- Stress Testing : didesain untuk menghadapi program dengan situasi abnormal.
- Pengujian instalasi : didesain untuk menguji prosedur instalasi dan software pendukungnya
Area fokus adalah:
— Fungsi dan performance sistem
— Reliability(ketersediaan) dan recoverability (kemampuan menutup/recovery test) sistem
— Instalasi (uji instalasi) sistem
— Perilaku pada kondisi tertentu (uji tekanan dan load) sistem
— Operasi user (acceptance test/alpha test/) sistem
— Integrasi dan kolaborasi hardware dan software
— Integrasi software eksternal dan sistem
— Fungsi dan performance sistem
— Reliability(ketersediaan) dan recoverability (kemampuan menutup/recovery test) sistem
— Instalasi (uji instalasi) sistem
— Perilaku pada kondisi tertentu (uji tekanan dan load) sistem
— Operasi user (acceptance test/alpha test/) sistem
— Integrasi dan kolaborasi hardware dan software
— Integrasi software eksternal dan sistem
Penguji sistem : uji engineer pada orang-orang ITG atau SQA.Saat sebuah sistem akan dikeluarkan sebagai sebuah produk software, suatu proses pengujian yang disebut pengujian beta sering digunakan.Rencana Ujin Rencana uji berhubungan dengan mengeset standar untuk pengujian proses dibanding penggambaran pengujian produk.
Test plan/rencana uji terdiri atas:
- standar untuk proses pengujian
- resource yang diperlukan (hardware, software dan engineer)
- jadwal pengujian (pengujian task dan milestones)
- uji item (apa yang harus diuji)
- prosedur recording test(hasil test harus secara sistematis direkam)
- constraint
Test planning adalah sebuah dari suatu test manager.
Sebuah test plan adalah output dari perencanaan.
IMPLEMENTASI ENTEPRISE SISTEM- standar untuk proses pengujian
- resource yang diperlukan (hardware, software dan engineer)
- jadwal pengujian (pengujian task dan milestones)
- uji item (apa yang harus diuji)
- prosedur recording test(hasil test harus secara sistematis direkam)
- constraint
Test planning adalah sebuah dari suatu test manager.
Sebuah test plan adalah output dari perencanaan.
(Gambar berikut)
Enterprise system adalah sistem berbasis software untuk membantu pengelolaan sistem informasi pada suatu organisasi dengan skala besar. Skala besar berarti volume transaksi yang besar, concern terhadap kualitas informasi yang tinggi, mengintegrasikan berbagai proses bisnis, lintas bidang (horisontal) maupun lintas strata (vertikal). Contoh dari ES adalah ERP (Enterprise Resource Planning) atau e-Business secara umum, e-Government, dan ingrated software lainnya.
Implementasi SI
Masalah terbesar dari implementasi SI adalah untuk mengetahui kebutuhan dari user, apalagi dengan karakter proyek :
· Sistem yang melibatkan multi-organisasi/divisi (penggunanya dari beberapa role dan divisi)
· Bisnis proses yang kompleks
· Kebutuhan yang sangat spesifik dan customized.
Dengan karakter proyek yang semacam ini, tidak cukup bagi seorang system analyst (SA) menentukan kebutuhan hanya dengan teknik wawancara, observasi ataupun kuesioner. Banyak kasus ditemui, bahwa pada akhirnya apa yang kita dapatkan dari proses analisa kebutuhan di awal proyek, tidak match dengan kebutuhan sesungguhnya dari pengguna sistem, sehingga sistem akhirnya tidak dapat digunakan dengan baik. Masalah lain adalah di sisi waktu. Teknik-teknik seperti itu seringkali sangat time consuming, sangat membutuhkan waktu yang lama. Sering juga tim developer dihadapkan situasi bahwa tidak semua stakeholder proyek memiliki kepedulian yang sama dengan yang lain. Seorang manajer tidak mengetahui kebutuhan detail dari staf-staf operasional, sementara itu staf operasional mungkin juga tidak memahami sepenuhnya spirit, goal dari SI. JAD merupakan sebuah teknik yang berfokus pada keterlibatan dan komitmen pengguna dalam menentukan kebutuhan dan merancang (desain) aplikasi. JAD biasanya dilakukan dalam bentuk tim yang merupakan gabungan dari seluruh stakeholder proyek, yang bekerja dalam bentuk workshop-workshop atau forum diskusi.
Kenapa workshop ? karena teknik JAD ini bukanlah sekedar rapat-rapat, yang biasa dilakukan dalam sebuah proyek dan melibatkan seluruh stakeholder proyek. JAD adalah tim yang nantinya akan membuat rancangan dan mengawasi, memonitor bersama jalannya proyek.
Siapa yang perlu terlibat ?
Secara garis besar yang perlu terlibat adalah :
Sukses / gagalnya proyek
Project Success Factors % of Responses
1. keterlibatan pemakai 15.9%
2. dukungan manajemen eksekutif 13.9%
3. kebutuhan yg jelas 13.0%
4. perencanaaan yg sesuai 9.6%
5. harapan yg realistis 8.2%
6. proyek terkecil 7.7%
7. staff yg kompeten 7.2%
8. pemilik 5.3%
9. visi dan sasaran yg jelas 2.9%
10.kerja keras, staff dipusatkan 2.4%
Lainnya 13.9%
Project Challenged Factors % of Responses
1. tidak ada masukkan dari pemakai 12.8%
2. kebutuhan & spesifikasi tg tdk sempurna 12.3%
3. mengubah kebutuhan dan spesifikasi 11.8%
4. tidak ada dukungan dr manajemen eksekutif 7.5%
5. ketidakmampuan teknologi 7.0%
6. tidak ada sumber daya 6.4%
7. harapan yg tdk realistis 5.9%
8.sasaran tdk jelas 5.3%
9. batasan waktu tdk realistis 4.3%
10. teknologi baru 3.7%
Lainnya 23.0%
Project Impaired Factors % of Responses
1. kebutuhan tdk lengkap 13.1%
2. tidak ada masukan/keterlibatan dr pemakai 12.4%
3. tidak ada sumber daya 10.6%
4. harapan yg tdk realistis 9.9%
5. tidak ada dukungan dr manajemen eksekutif 9.3%
6. perubahan kebutuhan dan spesifikasi 8.7%
7. tidak ada perencanaan 8.1%
8. tidak diperlukan sama sekali 7.5%
9. tidak ada manajemen IT 6.2%
10. buta teknologi 4.3%
Lainnya 9.9%
Istilah
DMV : the California department of motor vehicles
Banco itamarti : bank brazil
Confirm : American airlines utk penyewaan mobil di hotel marriott
& hilton
SUMBER:
http://images.google.co.id/imgres?imgurl=http://i.msdn.microsoft.com/ms998233.f06mtf02(en-us,MSDN.10).gif&imgrefurl=http://msdn.microsoft.com/en-us/library/ms998233.aspx&usg=__x7eNCvZefD6_51hxb2GbSb9PGMg=&h=260&w=450&sz=13&hl=id&start=10&tbnid=fyDeiz2K66J2gM:&tbnh=73&tbnw=127&prev=/images%3Fq%3Dwhite%2Bbox%2Btesting%26gbv%3D2%26hl%3Did%26sa%3DG
http://rpl07.wordpress.com/2007/06/21/strategi-pengujian-software-oleh-ardi-f-5105-100-118/
Masalah terbesar dari implementasi SI adalah untuk mengetahui kebutuhan dari user, apalagi dengan karakter proyek :
· Sistem yang melibatkan multi-organisasi/divisi (penggunanya dari beberapa role dan divisi)
· Bisnis proses yang kompleks
· Kebutuhan yang sangat spesifik dan customized.
Dengan karakter proyek yang semacam ini, tidak cukup bagi seorang system analyst (SA) menentukan kebutuhan hanya dengan teknik wawancara, observasi ataupun kuesioner. Banyak kasus ditemui, bahwa pada akhirnya apa yang kita dapatkan dari proses analisa kebutuhan di awal proyek, tidak match dengan kebutuhan sesungguhnya dari pengguna sistem, sehingga sistem akhirnya tidak dapat digunakan dengan baik. Masalah lain adalah di sisi waktu. Teknik-teknik seperti itu seringkali sangat time consuming, sangat membutuhkan waktu yang lama. Sering juga tim developer dihadapkan situasi bahwa tidak semua stakeholder proyek memiliki kepedulian yang sama dengan yang lain. Seorang manajer tidak mengetahui kebutuhan detail dari staf-staf operasional, sementara itu staf operasional mungkin juga tidak memahami sepenuhnya spirit, goal dari SI. JAD merupakan sebuah teknik yang berfokus pada keterlibatan dan komitmen pengguna dalam menentukan kebutuhan dan merancang (desain) aplikasi. JAD biasanya dilakukan dalam bentuk tim yang merupakan gabungan dari seluruh stakeholder proyek, yang bekerja dalam bentuk workshop-workshop atau forum diskusi.
Kenapa workshop ? karena teknik JAD ini bukanlah sekedar rapat-rapat, yang biasa dilakukan dalam sebuah proyek dan melibatkan seluruh stakeholder proyek. JAD adalah tim yang nantinya akan membuat rancangan dan mengawasi, memonitor bersama jalannya proyek.
Siapa yang perlu terlibat ?
Secara garis besar yang perlu terlibat adalah :
- Sponsor. Sponsor ini berarti project owner, memiliki kedudukan yang cukup tinggi dalam organisasi dan sebagai pengambil keputusan tertinggi dalam pengelolaan sistem informasi. Satu hal yang penting dilakukan oleh seorang project owner adalah komitmen yang kuat akan implementasi SI yang dilakukan. Without the executive sponsor's commitment, people do not show up for workshops on time or sometimes at all. Schedules change and projects are delayed. In short, without an executive sponsor, there is no project!
- Business Users. Business User ini terdiri dari 2 jenis, yaitu real end user dan representative end user. Real end user adalah person yang melakukan pekerjaan real di lapangan. Dalam kasus, ini adalah operator-operator. Sedangkan representative end user adalah person yang mengetahui seharusnya bisnis proses itu dilakukan, memahami spirit dan goal dari sistem yang dikelolanya. Biasanya ini adalah kepala bagian, manajer, atau operator senior.
- System Analyst (Tim Developer). Person/tim ini yang akan in-charge dari sisi teknologi dan proses engineeringnya.
- System Experts. Tidak semua referensi mencantumkan peran ini. Perannya lebih seperti konsultan yang memahami seluk beluk bisnis proses dari sisi konseptual dan berbasis pengalaman.
- Facilitator. Seorang fasilitator berfungsi sebagai moderator dan mengarahkan setiap aktivitas JAD yang melibatkan banyak pihak, untuk menjadi efektif. Seorang fasilitator harus memiliki kecakapan yang baik dalam berkomunikasi, memberikan stimulus-stimulus dan trik-trik agar diskusi bisa berjalan dengan baik.
Sukses / gagalnya proyek
Project Success Factors % of Responses
1. keterlibatan pemakai 15.9%
2. dukungan manajemen eksekutif 13.9%
3. kebutuhan yg jelas 13.0%
4. perencanaaan yg sesuai 9.6%
5. harapan yg realistis 8.2%
6. proyek terkecil 7.7%
7. staff yg kompeten 7.2%
8. pemilik 5.3%
9. visi dan sasaran yg jelas 2.9%
10.kerja keras, staff dipusatkan 2.4%
Lainnya 13.9%
Project Challenged Factors % of Responses
1. tidak ada masukkan dari pemakai 12.8%
2. kebutuhan & spesifikasi tg tdk sempurna 12.3%
3. mengubah kebutuhan dan spesifikasi 11.8%
4. tidak ada dukungan dr manajemen eksekutif 7.5%
5. ketidakmampuan teknologi 7.0%
6. tidak ada sumber daya 6.4%
7. harapan yg tdk realistis 5.9%
8.sasaran tdk jelas 5.3%
9. batasan waktu tdk realistis 4.3%
10. teknologi baru 3.7%
Lainnya 23.0%
Project Impaired Factors % of Responses
1. kebutuhan tdk lengkap 13.1%
2. tidak ada masukan/keterlibatan dr pemakai 12.4%
3. tidak ada sumber daya 10.6%
4. harapan yg tdk realistis 9.9%
5. tidak ada dukungan dr manajemen eksekutif 9.3%
6. perubahan kebutuhan dan spesifikasi 8.7%
7. tidak ada perencanaan 8.1%
8. tidak diperlukan sama sekali 7.5%
9. tidak ada manajemen IT 6.2%
10. buta teknologi 4.3%
Lainnya 9.9%
Istilah
DMV : the California department of motor vehicles
Banco itamarti : bank brazil
Confirm : American airlines utk penyewaan mobil di hotel marriott
& hilton
SUMBER:
http://images.google.co.id/imgres?imgurl=http://i.msdn.microsoft.com/ms998233.f06mtf02(en-us,MSDN.10).gif&imgrefurl=http://msdn.microsoft.com/en-us/library/ms998233.aspx&usg=__x7eNCvZefD6_51hxb2GbSb9PGMg=&h=260&w=450&sz=13&hl=id&start=10&tbnid=fyDeiz2K66J2gM:&tbnh=73&tbnw=127&prev=/images%3Fq%3Dwhite%2Bbox%2Btesting%26gbv%3D2%26hl%3Did%26sa%3DG
http://rpl07.wordpress.com/2007/06/21/strategi-pengujian-software-oleh-ardi-f-5105-100-118/
Tidak ada komentar:
Posting Komentar