0604M Testing dan Implementasi LECTURE N
0604M –Testing dan Implementasi
LECTURE NOTES
Dasar-Dasar Proyek Pengujian
(The Foundation of Test Project)
Hendra Achmadi, S.Kom, MM, MAcc. RFP
Hnd2106@gmail.com
0604M –Testing dan Implementasi
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
•
Testing & Implementation Phases in SDLC
•
Test Granularity
•
WRONG?
•
Purpose of software testing
•
The basic of system testing
IS THE “WHITE-BOX/BLACK-BOX” MODEL
Test Phase
0604M –Testing dan Implementasi
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:
1. System Investigation
2. System Analyst
3. System Design
4. Programming
5. Testing
6. Implementation
7. Operation
8. Maintenance
0604M –Testing dan Implementasi
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
Rentang pengujian ini terdiri dari struktural sampai perilaku, seperti yang tertera pada gambar
1.1.
0604M –Testing dan Implementasi
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)
Pengujian langsung (live tests) adalah pengujian sistem yang dilakukan oleh pemakai,
tenaga ahli konten, dan pemakai lainnya yang masih berhubungan dengan sistem.
Dibeberapa kondisi didapati penguji diminta untuk mencari kekurangan dari sistem
yang diuji. Pengujian ini biasa dikenal dengan Beta Testing. Penguji yang biasa
melakukan pengujian langsung adalah technical support, business analyst/pemakai,
tenaga penjual/pemasar. Pengujian langsung biasa dilakukan oleh vendor-vendor besar
pembuat perangkat lunak, untuk mendapatkan masukan-masukan dari para penguji
mengenai perangkat lunak yang dibuat.
0604M –Testing dan Implementasi
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 komponen atau sub sistem dimana penguji berfokus kepada
kegagalan/kesalahan yang terdapat pada sub bagian dalam sistem.
0604M –Testing dan Implementasi
• 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.
9 Tahapan menyediakan milestones yang nyata sehingga dapat dilakukan
pengukuran waktu penyelesaian dari pengujian.
0604M –Testing dan Implementasi
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.3 dan 1.4 menjelaskan mengenai 2 jenis dari sistem pengujian, High Fidelity Test
System dan Low Fidelity Test System. Dalam gambar 1.3, sistem pengujian A memungkinkan
penguji untuk mencakup kualitas resiko produk lebih besar dan cakupannya sesuai dengan
pengalaman kualitas dari konsumen A. Sedangkang sistem pengujian B, pada gambar 1.4,
cakupan kualitas resiko produk lebih kecil, dan proposi yang dilakukan uji tidak mencakup
pengalaman kualitas dari konsumen B.
0604M –Testing dan Implementasi
0604M –Testing dan Implementasi
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
Performance
User Interface
0604M –Testing dan Implementasi
9 Pengujian Sistem
Functionality
User interface
State
Transactions
Data Quality
Operations
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
Sumber informasi eksternal bisa didapatkan dari majalah-majalah, hasil
survey terhadap konsumen. Sehingga bisa didapatkan apa yang menjadi
harapan dari konsumen terhadap suatu produk.
0604M –Testing dan Implementasi
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
• Action Result
0604M –Testing dan Implementasi
•
•
•
•
•
•
•
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
3. Possibly acceptable reduction in system value
4. Acceptable reduction is system value
0604M –Testing dan Implementasi
•
•
•
•
•
•
•
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
Gambar 1.7 mengambarkan mengenai hubungan antara Fitur, Jadwal, Biaya dan Kualitas. Tanda
panah yang berputar searah jarum jam mengindikasikan perbaikan selama tahapan perencanaan.
Perbaikan ini menyeimbangkan antara fitur, jadwal, biaya dan kualitas. Ketika proses
implementasi dimulai (tahap pengujian), fitur diatur menjadi lebih kaku, jadwal tidak dapat
diubah, dan anggaran meningkat.
0604M –Testing dan Implementasi
Menyesuaikan Jadwal Pengujian Ke Dalam Proyek (Fitting a Test Schedule into The
Project)
Gunakan pendekatan “work-breakdown-structure”, yang mana merupakan pendekatan “topdown” 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,
tetapi dapat dilakukan dengan mengikuti aturan pada manajemen proyek yang baik. Gambar 1.8
mengambarkan fase sistem pengujian, releases dan siklus.
0604M –Testing dan Implementasi
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
system.
0604M –Testing dan Implementasi
• 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,
yang mencakup biaya, waktu, resiko dan keuntungan.
0604M –Testing dan Implementasi
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.
7. Dengan menggunakan failure mode dan effect analysis table kita bisa memperkirakan
lebih detail tentang kemungkinan kesalahan dan efek yang ditimbulkannya pada sebuah
sistem
0604M –Testing dan Implementasi
DAFTAR PUSTAKA
1. Black, Rex. (2009). Managing The Testing Process. 3st Ed., Microsoft Press, Redmond,
Washington 98052-6399 ISBN 0-7356-0584-X , chapter 1
LECTURE NOTES
Dasar-Dasar Proyek Pengujian
(The Foundation of Test Project)
Hendra Achmadi, S.Kom, MM, MAcc. RFP
Hnd2106@gmail.com
0604M –Testing dan Implementasi
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
•
Testing & Implementation Phases in SDLC
•
Test Granularity
•
WRONG?
•
Purpose of software testing
•
The basic of system testing
IS THE “WHITE-BOX/BLACK-BOX” MODEL
Test Phase
0604M –Testing dan Implementasi
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:
1. System Investigation
2. System Analyst
3. System Design
4. Programming
5. Testing
6. Implementation
7. Operation
8. Maintenance
0604M –Testing dan Implementasi
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
Rentang pengujian ini terdiri dari struktural sampai perilaku, seperti yang tertera pada gambar
1.1.
0604M –Testing dan Implementasi
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)
Pengujian langsung (live tests) adalah pengujian sistem yang dilakukan oleh pemakai,
tenaga ahli konten, dan pemakai lainnya yang masih berhubungan dengan sistem.
Dibeberapa kondisi didapati penguji diminta untuk mencari kekurangan dari sistem
yang diuji. Pengujian ini biasa dikenal dengan Beta Testing. Penguji yang biasa
melakukan pengujian langsung adalah technical support, business analyst/pemakai,
tenaga penjual/pemasar. Pengujian langsung biasa dilakukan oleh vendor-vendor besar
pembuat perangkat lunak, untuk mendapatkan masukan-masukan dari para penguji
mengenai perangkat lunak yang dibuat.
0604M –Testing dan Implementasi
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 komponen atau sub sistem dimana penguji berfokus kepada
kegagalan/kesalahan yang terdapat pada sub bagian dalam sistem.
0604M –Testing dan Implementasi
• 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.
9 Tahapan menyediakan milestones yang nyata sehingga dapat dilakukan
pengukuran waktu penyelesaian dari pengujian.
0604M –Testing dan Implementasi
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.3 dan 1.4 menjelaskan mengenai 2 jenis dari sistem pengujian, High Fidelity Test
System dan Low Fidelity Test System. Dalam gambar 1.3, sistem pengujian A memungkinkan
penguji untuk mencakup kualitas resiko produk lebih besar dan cakupannya sesuai dengan
pengalaman kualitas dari konsumen A. Sedangkang sistem pengujian B, pada gambar 1.4,
cakupan kualitas resiko produk lebih kecil, dan proposi yang dilakukan uji tidak mencakup
pengalaman kualitas dari konsumen B.
0604M –Testing dan Implementasi
0604M –Testing dan Implementasi
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
Performance
User Interface
0604M –Testing dan Implementasi
9 Pengujian Sistem
Functionality
User interface
State
Transactions
Data Quality
Operations
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
Sumber informasi eksternal bisa didapatkan dari majalah-majalah, hasil
survey terhadap konsumen. Sehingga bisa didapatkan apa yang menjadi
harapan dari konsumen terhadap suatu produk.
0604M –Testing dan Implementasi
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
• Action Result
0604M –Testing dan Implementasi
•
•
•
•
•
•
•
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
3. Possibly acceptable reduction in system value
4. Acceptable reduction is system value
0604M –Testing dan Implementasi
•
•
•
•
•
•
•
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
Gambar 1.7 mengambarkan mengenai hubungan antara Fitur, Jadwal, Biaya dan Kualitas. Tanda
panah yang berputar searah jarum jam mengindikasikan perbaikan selama tahapan perencanaan.
Perbaikan ini menyeimbangkan antara fitur, jadwal, biaya dan kualitas. Ketika proses
implementasi dimulai (tahap pengujian), fitur diatur menjadi lebih kaku, jadwal tidak dapat
diubah, dan anggaran meningkat.
0604M –Testing dan Implementasi
Menyesuaikan Jadwal Pengujian Ke Dalam Proyek (Fitting a Test Schedule into The
Project)
Gunakan pendekatan “work-breakdown-structure”, yang mana merupakan pendekatan “topdown” 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,
tetapi dapat dilakukan dengan mengikuti aturan pada manajemen proyek yang baik. Gambar 1.8
mengambarkan fase sistem pengujian, releases dan siklus.
0604M –Testing dan Implementasi
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
system.
0604M –Testing dan Implementasi
• 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,
yang mencakup biaya, waktu, resiko dan keuntungan.
0604M –Testing dan Implementasi
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.
7. Dengan menggunakan failure mode dan effect analysis table kita bisa memperkirakan
lebih detail tentang kemungkinan kesalahan dan efek yang ditimbulkannya pada sebuah
sistem
0604M –Testing dan Implementasi
DAFTAR PUSTAKA
1. Black, Rex. (2009). Managing The Testing Process. 3st Ed., Microsoft Press, Redmond,
Washington 98052-6399 ISBN 0-7356-0584-X , chapter 1