LECTURE NOTES
Dasar-Dasar Proyek Pengujian
(The Foundation of Test Project)
Hendra Achmadi, S.Kom, MM, MAcc. RFP
LEARNING OUTCOMES
• Mahasiswa akan dapat menerangkan peranan tahap pengujian dan tahap implementasi
pada rangkaian siklus hidup pengembangan sistem perangkat lunak.
• Mahasiswa akan dapat menghasilkan perencanaan pengujian (test plan) suatu proyek
pengujian perangkat lunak.
• Mahasiswa akan dapat menyimpulkan hasil proses pengujian yang dilakukan.
• Mahasiswa akan dapat mendesain laboratorium pengujian.
• Mahasiswa akan dapat menciptakan tim pengujian berdasarkan kualifikasi yang
dibutuhkan.
OUTLINE MATERI :
• Testing
• Purpose of software testing
• Testing & Implementation Phases in SDLC
• The basic of system testing
• Test Granularity
• IS THE “WHITE-BOX/BLACK-BOX” MODEL WRONG?
Dasar-Dasar Proyek Pengujian
1. PENDAHULUAN
Kesalahan/kegagalan perangkat lunak di Amerika Serikat mendatangkan kerugian sebesar US$59.5 milyar setiap tahunnya, lebih dari sepertiga dari kerugian ini sekitar US$22.2 milyar dapat ditiadakan dengan memperbaiki proses pengujian. Dari hal tersebut dapat dipastikan proses pengujian yang benar dan tepat dapat mengurangi kerugian dan memungkinkan perusahaan mendapatkan keuntungan (kepercayaan konsumen terhadap kualitas dari produk).
Dalam pengembangan perangkat lunak/aplikasi terdapat proses yang disebut dengan Pengujian (testing), yang dimaksud dengan pengujian dalam perangkat lunak/aplikasi adalah:
• Proses menjalankan program atau sistem dengan maksud mencari kesalahan/kegagalan pada perangkat lunak/aplikasi. atau
• Kegiatan yang berfokus melakukan evaluasi terhadap kemampuan atau ciri-ciri dari sebuah program atau sistem dan menentukan bahwa hasil yang didapat sudah memenuhi kebutuhan.
Proses pengujian bertujuan untuk mencari kegagalan/kesalahan pada perangkat lunak, dan sudah dapat dipastikan bahwa tidak ada satupun perangkat lunak/aplikasi yang bebas dari kegagalan/kesalahan. Yang menjadi pertanyaan adalah kapan proses pengujian perangkat lunak akan berakhir?
• Ketika menyelesaikan pengujian dari sistem secara umum sudah tidak dapat dilakukan, dikarenakan biaya yang terlalu besar.
• Ketika sumber daya pengujian sudah habis.
• Ketika perangkat lunak yang dihasilkan sudah memenuhi kebutuhan.
• Ketika keuntungan dalam melanjutkan proses pengujian tidak dapat melakukan justifikasi terhadap biaya tambahan.
Siklus Pengembangan Sistem/Perangkat Lunak (SDLC) Tahapan dalam SDLC sebagai berikut:
Pengujian (testing) adalah suatu proses pemeriksaan terhadap sistem informasi apakah sudah menghasilkan hasil yang diharapkan dan diinginkan dalam suatu kondisi tertentu. Sedangkan Implementasi (implementation) adalah suatu proses yang mengubah sistem lama dengan sistem yang baru. Ada 4 pendekatan dalam mengubah sistem:
• Melakukan perubahan secara Paralel: Sistem lama dan sistem baru berjalan secara bersamaan sampai kurun waktu tertentu.
• Melakukan perubahan secara Langsung: Sistem lama dihentikan dan sistem baru mulai berjalan pada titik waktu tertentu.
• Melakukan perubahan secara Pilot: Menjalankan sistem baru dengan sistem pilot.
• Melakukan perubahan secara Bertahap: Menjalankan komponen/bagian dari sistem baru dengan tahapan-tahapan.
2. APA YANG MUNGKIN ANDA UJI? Pengujian Granularitas (Test Granularity)
Di banyak kesempatan tesing biasanya dilakukan di luar dari tim yang independen, dan yang baik adalah dilakukan dengan tim yang dapat dimanage. Disamping itu pengujian granularitas mengacu kepada tindakan yang dilakukan pada saat pengujian.
• Test granularity refers to the fineness or coarseness of a test’s focus. A fine-grained test case allows the tester to check low-level details, often internal to the system; a coarsegrained test case provides the tester with information about general system behavior.
• Test granularity can be thought of as running along a spectrum ranging from structural (white-box) to behavioral (black-box and live) tests
Pengujian granularitas terdiri dari:
• Pengujian Struktural (structural test/white-box)
Pengujian struktural mencari kesalahan/kegagalan dalam operasi tingkat rendah, seperti pada baris program yang dibuat oleh programmer, skema basis data maupun pada perangkat keras seperti komponen elektronik (kompatibilitas). Pengujian ini berdasarkan kepada bagaimana sistem ini bekerja pada lingkungan yang ditempatinya. Sebagai contoh aplikasi internet banking, pengujian struktural yang dilakukan adalah apakah aplikasi internet banking tersebut dapat berfungsi dengan baik diberbagai jenis browser (IE, Mozilla, Opera, Chrome, dll), skema basis datanya (hubungan antar tabel). Pengujian struktural dapat dilakukan oleh seorang yang ahli dalam bahasa pemograman dan menguasai pengetahuan teknis pengujian struktural.
• Pengujian Perilaku (behavioral test/black box)
Pengujian perilaku digunakan untuk mencari kesalahan/kegagalan dalam operasi tingkat tinggi, yang mencakup kemampuan dari perangkat lunak, operasional/tata laksana, skenario pemakai. Fungsi dari pengujian ini berdasarkan kepada apa yang dapat dilakukan oleh sistem. Untuk melakukan pengujian perilaku seseorang harus mengerti lingkup dari aplikasi, solusi bisnis yang diberikan oleh aplikasi, dan tujuan sistem dibuat. Pengujian perilaku sebaiknya dilakukan oleh penguji yang mengerti merancangan sistem/aplikasi dengan kemampuan yang tinggi, sehingga mereka dapat menemukan kesalahan/kegagalan yang sering terjadi pada rancangan sistem tertentu secara efektif. Selain itu penguji harus mengerti isu-isu teknologi terkini seputar sistem yang sedang dilakukan pengujian, penguji juga mengerti mengenai pengujian perilaku secara khusus, agar dapat menemukan kesalahan/kegagalan dengan tepat. Pengujian perilaku yang baik, seperti pengujian struktural yang baik, terstruktur, menggunakan metoda, dan melakukan pengujian yang berulang-ulang sehingga didapati kelemahan dari sistem dan kegagalan/kesalahan sistem. Pengujian perilaku adalah teknik pengujian yang sering digunakan oleh organisasi pengujian independen. Contoh pengujian perilaku pada aplikasi internet banking, maka pengujian yang dilakukan adalah menjalankan aplikasi, memeriksa apakah semua fungsi pada aplikasi berjalan dengan baik.
• Pengujian Langsung (live tests)
IS THE “WHITE-BOX/BLACK-BOX” MODEL WRONG?
The “white-box/black-box” model is widespread. Glenford Myers contrasts “white-box”and “black-box” approaches in The Art of Software Testing, a pioneering book. Cem Kaner,Jack Falk, and Hung Nguyen refer to test cases as following a “glass-box” or “black-box” The model is also handy. With my clients, I have found that the use of the “white-box” and “black-box” models to explain the type of testing used in particular projects or phases helps make communication easier. The concepts are quite intuitive.
However, the model is not ubiquitous. Bill Hetzel, in The Complete Guide to Software
Testing, describes six types of test cases: requirements-based, design-based, code-based,
randomized (especially in terms of the underlying data), extracted (from live data), and abnormal (or extreme). Of these, he does point out that requirement-based tests are “blackbox,” design- and code-based tests are “white box,” and extracted tests are “live.” However, the index contains neither the phrase “black-box” nor “white-box.”
Some argue that the model is an oversimplification, and a dangerous one at that. Boris Beizer, who wrote a book called Black Box Testing, has had second thoughts about the phrase, which he describes in his essay, “The Black Box Vampire.” He argues that the better model is to think in terms of the “structural” and “behavioral” spectrum, with a fault model (i.e., how the bugs were created) providing an orthogonal testing dimension as well. He argues that the “white-box/black-box” model makes testing look simpler than it is, encourages a possibly negative division of test work between programmers and testers, feeds into the mindset that testers are lower skilled than programmers, and fosters a false belief that “black-box” testing is about demonstrating compliance to requirements. Who’s right? To me, the issue is the usefulness of the abstraction or simplification of the rich set of techniques available. I find the abstractions intuitive and clarifying, Although I don’t get too hung up on the matter. I prefer to think in terms of quality risks, and then let the choice of critical quality risks drive the selection of test techniques.
Tahapan Pengujian (Test Phases) Berikut tahapan dalam pengujian.
• Pengujian Unit (Unit Testing)
Pengujian unit adalah pengujian terhadap baris program (code), function atau subroutine dalam program. Uji ini biasanya dilakukan oleh programmer terhadap program yang dibuatnya atau program dari programmer lainnya.
• Pengujian Komponen atau Sub Sistem (Component or Subsystem Testing)
• Pengujian Integrasi atau Produk (Integration or Product Testing)
Pengujian integrasi atau produk, pengujian untuk menemukan kegagalan/kesalahan hubungan atau antarmuka antara beberapa komponen dan group komponen pada sistem yang sedang diuji coba.
• Pengujian String (String Testing)
Tahapan ini jarang dilakukan, pengujian string biasanya menggunakan scripts. Contoh dari pengujian string adalah seperti proses enkripsi dan dekripsi.
• Pengujian Sistem (System Testing)
Pengujian sistem adalah pengujian yang dilakukan terhadap keseluruhan sistem yang telah digabungkan. Seperti unjuk kerja, proses intalasi, dan kesesuaian printer.
• Pengujian Penerimaan oleh Pemakai (User Acceptance Test)
Pengujian ini adalah menguji kesesuaian sistem terhadap kebutuhan pemakai dan dilakukan oleh pemakai itu sendiri. Para vendor-vendor perangkat lunak biasanya menggunakan uji ini, biasa disebut dengan pengujian Beta.
• Pengujian Pilot (Pilot Test)
Pengujian pilot adalan pengujian yang dilakukan oleh sebagian dari pemakai, dan pada lingkungan sebenarnya (lingkungan pemakai). Perangkat lunak/sistem diinstall pada komputer pemakai, dan pemakai menjalankan perangkat lunak sesuai dengan kondisi yang ada.
Keuntungan menggunakan tahapan pengujian adalah: 9 Pengujian struktural menjamin stabilitas dari produk.
9 Pengujian struktural dengan menggunakan pendekatan komponen/per bagian dapat dilakukan pengujian terlebih dahulu.
9 Berdasarkan pendekatan diatas maka dimungkinkan kegagalan/kesalahan dapat ditemukan secara dini.
9 Dapat mengumpulkan matrik yang lebih baik dan dapat menggunakan teknik best-practise dalam pengujian yang dilakukan.
3. APA YANG SEHARUSNYA ANDA UJI? Definisi Kualitas Perangkat Lunak
• Fitur yang menentukan unjuk kerja dan kepuasan dari produk perangkat lunak.
• Terbebas dari keluhan pemakai, klaim, pengembalian produk, pembuatan kembali dan kerusakan lainnya.
• Pemakai dan konsumen akan menjadi wasit terhadap kualitas ketika mereka mengalami ketidakpuasan terhadap produk, dan mereka membuat keluhan, mengembalikan produk, atau menghubungi technical support.
Resiko Perbedaan Pengalaman dari Kualitas (The Perils of Divergent Experiences of Quality)
Gambar 1.5 dibawah ini menjelaskan antara cakupan kualitas resiko dengan cakupan pemakaian konsumen, dimana nilai sistem pengujian yang bagus berada di sisi kanan dari bagan, dimana cakupan pemakaian konsumen tinggi dan cakupan kualitas resiko juga tinggi.
Metode Informal untuk Melakukan Penilaian Kualitas Resiko (Informal Methods for Assesing Quality Risks)
• The Usual Suspects
Untuk daftar kategori kualitas resiko yang utama, diawali dengan menjabarkan proses pengujian ke dalam; pengujian komponen, pengujian integrasi dan pengujian sistem.
9 Pengujian Komponen States
Transactions Code coverage Data flow coverage Functionality User interface Mechanical life Signal quality 9 Pengujian Integrasi
Component or subsystem interfaces Functionality
Capacity and volume
Error/disaster handing and recovery Data quality
9 Pengujian Sistem
Capacity and Volume
Reliability, availability, and stability Error/disaster handling and recovery Stress
Performance
Date and time handing Localization
Networked and distributed environments Configuration options and compatibility Security
Environment
Power input, consumption, and output Shock, vibration and drop
Installation, cut-over, setup, and initial configuration Documentation and packaging
Maintainability
Alpha, beta and other live tests
• Memeriksa dan Melengkapi Daftar (Checking and Completing Your List)
Untuk memeriksa dan melengkapi daftar dapat memanfaatkan sumber daya berikut: 9 Peer Review
Peer review adalah rekan kerja dalam satu tim yang dapat diminta bantuannya untuk melakukan evaluasi atau memberikan pendapat mengenai daftar yang dibuat.
9 Bersumber dari Internal
Pakar dari internal bisa terdiri dari pemasaran, penjualan, help desk, business analyst, dimana mereka biasa berhubungan dengan konsumen dan mengetahui keinginan dari konsumen terhadap produk.
9 Bersumber dari Eksternal
9 Mengusulkan Kualitas Resiko
Sumber informasi lainnya bisa didapatkan dari Manajer Proyek dan Manajer Pengembangan, mereka dapat memberikan masukan dan perubahan yang berarti.
FMEA: Metode Formal untuk Memahami Kualitas Resiko
Failure Mode and Effect Analysis (FMEA) adalah teknik untuk memahami dan memprioritaskan mode kegagalan yang mungkin (atau kualitas risiko) dalam fungsi sistem, fitur, atribut, perilaku, komponen dan antarmuka. Gambar 1.6 adalah contoh FMEA, dimana kolom yang ada berisikan:
• System function or feature
• Potential failure mode(s)-Quality risk(s)
• Potential effect(s) of failure
• Critical
• Severity
• Potential cause(s) of failure
• Priority
• Detection Method(s)
• Likelihood
• RPN (Risk Priority Number)
• Recommended Action
• Who/When
• References
• System Function and Feature : Deskripsi dari fungsi sistem yang akan ditest
• Potential Failure Modes-Quality Risk: Setiap fungsi dan fitur mengidentifikasikan tipe failure apa yang anda tentukan
• Ptential Effect of Failure: Setiap kegagalan dapat berefek ke 1 atau banyak cara, fokus pada yang berefek secara umum
• Critical ?: Apakah efeknya critical bagi user ? • Severity : Jika skala 1-5 maka akan dibagi menjadi :
1. Loss of Data, hardware damage or a safety issues 2. Loss of functionality with no workaround
3. Loss of functionality with a workaround 4. Partial Loss of functionality
5. Cosmetic or trivial
• Potential failure : List semua kemungkinan yang menimbulkan kegagalan • Priority : Skala 1 sd 5:
1. Complete loss of system value 2. Unacceptable loss of system value
5. Negligible reduction in system value • Detection Method
• Likelihood : Dampaknya bagi user dengan skala 1 sd 5 1. Certain to affect all users
2. Likely to impact some users 3. Possible impact on some users 4. Limited impact to few users 5. Unimaginable in actual usage
• RPN( Risk Potential Number) : From 1 (Most dangerous quality risk) to 125 ( Least dangerous quality risk)
• Recommended Action • Who/When
• Reference : Seperti spesifikasi produk dan dokumen yang dibutuhkan • Action Results
4. APA YANG DAPAT ANDA UJI? Jadwal, Sumber Daya dan Anggaran
Menyesuaikan Jadwal Pengujian Ke Dalam Proyek (Fitting a Test Schedule into The
Project)
Gunakan pendekatan “work-breakdown-structure”, yang mana merupakan pendekatan
“top-down” dalam penyusunan jadwal pengujian. Dapat dimulai dengan kategori yang besar dari
pekerjaan dan setelah itu jabarkan ke dalam beberapa bagian dengan pendekatan intuisi, terutama
pada tahap awal ketika tidak diketahui rincian dari pekerjaan. Fase-fase utama dalam pengujian:
• Perencanaan (planning)
• Kofigurasi (configuration)
• Penugasan (taffing)
• Pembangunan Pengujian (test development)
• Pelasanaan Pengujian (test execution)
Waktu yang dibutuhkan untuk menjalankan pengujian adalah sesuatu yang dapat diatur dan
diukur oleh Manajer Pengujian. Akurasi dari penjadwalan membutuhkan partisipasi dari para
kontributor yang terlibat. Estimasi pengujian sangat sulit untuk dilakukan secara sempurna,
Estimasi Sumber Daya dan Merencanakan Anggaran (Estimating Resource and Creating a
Budget)
Berikut ini adalah sumberdaya yang dibutuhkan dalam proses pengujian, dimulai dengan
kategori yang umum:
• Staf (Staffs): kategori ini termasuk di dalamnya adalah karyawan tetap, kontraktor dan konsultan.
• Perangkat Pengujian (Test Tools): adalah perangkat-perangkat yang dibutuhkan dalam proses pengujian, dalam pengujian perangkat lunak, perangkat pengujian yang
dibutuhkan antara lain: code coverage analyzers, scripting utilities, GUI test automation
• Fasilitas dan Pengeluaran Tambahan (Facilities and overhead): yang termasuk dalam kategori ini adalah biaya perjalanan, ruang laboratorium, perangkat komputer dan
perangkat jaringan lainnya.
• Lingkungan Pengujian (Test Environment): ketegori ini termasuk didalamnya perangkat keras, perangkat lunak, contoh rekayasa, dan prototipe eksperimental.
• Laboratorium Eksternal (External Labs): kategori ini digunakan jika dibutuhkan pengujian lingkungan, kinerja, dan kebutuhan lainnya.
Negosiasi Proyek Pengujian (Negotiating a Livable Test Project)
Pada saat melakukan negosiasi dengan Manajemen mengenai program pengujian yang dilakukan
akan ada beberapa pertanyaan yang muncul:
• Manajemen resiko seperti apa yang akan dihadapi?
• Berapa lama waktu yang dibutuhkan?
• Berapa besar biaya yang dibutuhkan?
• Bagaimana dengan pengembalian Investasi?
Ketika bertemu dengan Manajemen, “bahasa” yang dipergunakan adalah “bahasa” Manajemen,
SIMPULAN
1. Pengujian (testing) adalah suatu proses pemeriksaan terhadap sistem informasi apakah sudah menghasilkan hasil yang diharapkan dan diinginkan dalam suatu kondisi tertentu.
2. Pengujian Granularitas terbagi menjadi 3 bagian yakni: structural test (white box), behavioral test (black box) dan live test. Behavioral Test paling banyak digunakan oleh perusahaan yang bergerak dalam bidang pengujian perangkat lunak.
3. Tahapan pengujian (test phases) terdiri dari: Unit testing, component/subsystem testing, integration/ product testing, string testing, system testing, user acceptance test, dan pilot testing.
4. Dalam sistem pengujian ada 2 jenis pengujian yang menentukan sebuah kualitas uji, yakni High Fidelity Test dan Low Fidelity Test.
5. Dalam melakukan pengujian kualitas terdapat resiko ada 2 metode yakni: Metode Informal dan Metode Formal.
6. Dalam pelaksanaan proses pengujian ada 3 hal utama yang menunjang keberhasilan dari proses pengujian, yakni Jadwal, Sumber daya dan Anggaran.
