Download - Definisi Testing
BAB I
Pendahuluan
1.1 Definisi Testing
Menurut Hetzel 1973
Testing adalah proses pemantapan kepercayaan akan kinerja program atau
sistem sebagaimana yang diharapkan.
Menurut Myers 1979
Testing adalah proses eksekusi program atau sistem secara intens untuk
menemukan error.
Menurut Hetzel 1983 (Revisi)
Testing adalah tiap aktivitas yang digunakan untuk dapat melakukan
evaluasi suatu atribut atau kemampuan dari program atau sistem dan
menentukan apakah telah memenuhi kebutuhan atau hasil yang
diharapkan.
Menurut standar ANSI/IEEE 1059
Testing adalah proses menganalisa suatu entitas software untuk
mendeteksi perbedaan antara kondisi yang ada dengan kondisi yang
diinginkan (defects / error / bugs) dan mengevaluasi fitur-fitur dari entitas
software.
1.2 Definisi Testing Software
Testing software adalah proses mengoperasikan software dalam suatu
kondisi yang dikendalikan, untuk verifikasi apakah telah berlaku sebagaimana
telah ditetapkan, validasi apakah spesifikasi yang telah ditetapkan sudah
memenuhi keinginan atau kebutuhan dari pengguna yg sebenarnya.
Verifikasi adalah pengecekan atau pengetesan entitas-entitas,
termasuk software untuk pemenuhan dan konsistensi dengan melakukan
evaluasi hasil terhadap kebutuhan yang telah ditetapkan.
Validasi melihat kebenaran system, apakah proses yang telah ditulis
dalam spesifikasi adalah apa yang sebenarnya diinginkan atau dibutuhkan
oleh pengguna.( Are we building the right system?)
Deteksi error: Testing seharusnya berorientasi untuk membuat
kesalahan secara intensif, untuk menentukan apakah suatu hal tersebut
1
terjadi bilamana tidak seharusnya terjadi atau suatu hal tersebut tidak terjadi
dimana seharusnya mereka ada.
Beberapa pandangan praktisi tentang testing, adalah sebagai berikut :
• Melakukan cek pada program terhadap spesifikasi.
• Menemukan bug pada program.
• Menentukan penerimaan dari pengguna.
• Memastikan suatu sistem siap digunakan.
• Meningkatkan kepercayaan terhadap kinerja program.
• Memperlihatkan bahwa program bekerja dengan benar.
• Membuktikan bahwa error tidak terjadi.
• Mengetahui akan keterbatasan sistem.
• Mempelajari apa yang tidak dapat dilakukan oleh sistem.
• Melakukan evaluasi kemampuan sistem.
• Verifikasi dokumen.
• Memastikan bahwa pekerjaan telah terselesaikan.
Berikut ini adalah pengertian Testing yang dihubungkan dengan proses
verifikasi dan validasi software :
Testing software adalah proses mengoperasikan software dalam suatu
kondisi yang dikendalikan, untuk
• (1) verifikasi apakah telah berlaku sebagaimana telah ditetapkan (menurut
spesifikasi)
• (2) mendeteksi error
• (3) validasi apakah spesifikasi yang telah ditetapkan sudah memenuhi
keinginan atau kebutuhan dari pengguna yang sebenarnya.
Verifikasi adalah pengecekan atau pengetesan entitas-entitas, termasuk
software, untuk pemenuhan dan konsistensi dengan melakukan evaluasi
hasil terhadap kebutuhan yang telah ditetapkan. (Are we building the
system right?)
Validasi melihat kebenaran sistem, apakah proses yang ditulis dalam
spesifikasi adalah apa yang sebenarnya diinginkan atau dibutuhkan oleh
pengguna. (Are we building the right system?)
Deteksi error. Testing seharusnya berorientasi untuk membuat kesalahan
secara intensif, untuk menentukan apakah suatu hal tersebut terjadi
2
bilamana tidak seharusnya terjadi atau suatu hal tersebut terjadi dimana
seharusnya mereka ada.
Tujuan akhirnya adalah untuk mendapatkan informasi yang dapat
diulang secara konsisten (realible) tentang hal yang mungkin sekitar software
dengan cara termudah dan paling efektif, antara lain :
• Apakah software telah siap digunakan ?
• Apa saja resikonya ?
• Apa saja kemampuannya ?
• Apa saja keterbatasannya ?
• Apa saja masalahnya ?
• Apakah telah berlaku seperti yang diharapkan ?
1.3 Defini Kualitas
Menurut Crosby
Kualitas adalah pemenuhan terhadap kebutuhan
Menurut ISO-8402
Kualitas adalah keseluruhan dari fitur yang menjadikan suatu produk dapat
memuaskan atau dipakai sesuai kebutuhan dengan harga yang Terjangkau
3
Menurut W.E Perry
Kualitas adalah pemenuhan terhadap standar
Menurut R.Glass
Kualitas adalah tingkat kesempurnaan
Menurut J.Juran
Kualitas adalah tepat guna
4
BAB II
PEMBAHASAN
2.1 Hubungan testing dan kualitas
Software yang berkualitas adalah software yang bebas error dan bug
secara objektif, tepat waktu dan dana, sesuai dengan kebutuhan atau
keinginan dan dapat dirawat (maintainable).
Definisi objektif :
Suatu proses pembuktian yang terstruktur, terencana dan
terdokumentasi dengan baik Testing membuat kualitas dapat dilihat secara
objektif, karena testing merupakan pengukuran dari kualitas software. Testing
tidak dapat memastikan kualitas software, namun dapat memberikan jaminan
terhadap software pada suatu tingkat tertentu. Jaminan kualitas (Quality
Assurance – QA) mengukur kualitas proses yang digunakan untuk membuat
produk berkualitas. Testing merupakan bagian dari aktifitas QA. Proyek
pengembangan software memiliki kecenderungan untuk mengalami
kegagalan
2.2 Faktor-faktor kualitas secara umum
Kualitas software atau perangkat lunak didefinisikan sebagai,
konformasi terhadap kebutuhan fungsional dan kinerja yang dinyatakan
secara eksplisit, standar perkembangan yang didokumentasikan secara
eksplisit, dan karakteristik implisit yang diharapkan bagi semua perangkat
lunak yang dikembangkan secara profesional. Definisi tersebut berfungsi
untuk menekankan tiga hal penting, yaitu:
1. kebutuhan perangkat lunak merupakan fondasi yang memulainya
kualitas diukur. Kurangnya penyesuaian terhadap kebutuhan juga
menunjukkan resahnya kualitas.
2. Standar yang telah ditentukan menetapkan serangkaian kriteria
pengembangan yang menuntun cara perangkat lunak direkayasa. Jika
kriteria tersebut tidak diikuti, hampir pasti menimbulkan kualitas yang
kurang baik.
3. Ada serangkaian kebutuhan implisit yang sering tidak dicantumkan
(misalnya kebutuhan akan kemampuan pemeliharaan yan baik). Bila
5
perangkat lunak dapat berhasil menyesuaikan dengan kebutuhan
eksplisitnya, tetapi gagal memenuhi kebutuhan implisitnya, maka kualitas
perangkat lunak tersebut perlu diragukan.
Faktor yang mempengaruhi kualitas perangkat lunak dapat
dikategorikan ke dalam dua kelompok besar:
(1) faktor yang dapat secara langsung diukur (seperti, cacat per function
point)
(2) faktor yang hanya diukur secara tidak langsung (misalnya, usabilitas atau
maintainabilitas).
Pada masing-masing kasus, pengukuran harus terjadi. Kita harus
membandingkan perangkat lunak tersebut (dokumen, program, data) dengan
berbagai fakta dan sampi pada indikasi mengenai kualitas.
Gambar Faktor kualitas perangkat lunak McCall
memberikan gambaran-gambaran sebagai berikut:
Kebenaran: Tingkat di mana program memenuhi spesifikasinya dan
memenuhi sasaran misi pelanggan.
Reliabilitas: Tingkat di mana sebuah program dapat diharapkan melakukan
fungsi yang diharapkan dengan ketelitian yang diminta.
6
R E V IS I P R O D U K T R A N S IS I P R O D U K
O P E R A S I P R O D U K
K ebenaran : R e liab ilitas U sab ilitas In tegritas E fis iens i
M ain ta inab ilitasF leks ib ilitas ;T es tab ilitas
P ortab ilitasR eusab ilitasIn teroperab ilitas
Efisiensi: Jumlah sumber daya perhitungan dan kode yang diperlukan oleh
program untuk melakukan fungsinya.
Integritas: Tingkat di mana akses ke perangkat lunak atau data oleh orang
yang tidak berhak dapat dikontrol.
Usabilitas: Usaha yang dibutuhkan untuk mempelajari, mengoperasikan,
menyiapkan input, dan menginterprestasikan output suatu
program.
Maintainabilitas: Usaha yang diperlukan untuk mencari dan membetulkan
kesalahan pada sebuah program.
Fleksibilitas: Usaha yang diperlukan untuk memodifikasi program
operasional.
Testabilitas. : Usaha yang diperlukan untuk menguji sebuah program untuk
memastikan apakah program melakukan fungsi-fungsi yang
dimaksudkan.
Portabilitas. : Usaha yang diperlukan untuk memindahkan program dari
satu perangkat keras dan atau lingkungan sistem perangkat
lunak ke yang lainnya.
Reusabilitas. :Tingkat di mana sebuah program (atau bagian dari suatu
program) dapat digunakan kembali di dalam aplikasi yang
lain yang berhubungan dengan kemasan dan ruang lingkup
dari fungsi yang dilakukan oleh program.
Interoperabilitas : Usaha yang diperlukan untuk merangkai satu sistem
dengan yang lainnya.
2.3 Pentingnya kualitas software bagi organisasi
Agar dapat melakukan proses analisa, evaluasi, dan pengembangan
yang berkesinambungan u/ mencapai suatu proses pengembangan software
yang semakin lama semakin efektif, efisien, terukur, terkendali, dan dapat
diulang secara konsisten dalam menghasilkan suatu produk (software) yang
berkualitas dan tepat waktu dan pendanaan.
7
2.4 Prinsip Testing
Semua test seharusnya dapat dilacak dengan requirement dari customer :
Testing seharusnya direncanakan
Memenuhi prinsip pareto (80 % error dapat ditemukan dengan
tracing 20 % modul dalam program)
Dimulai dengan “kecil” dan berlanjut ke yang “ besar”
Testing yang lengkap (exhaustive) tidak dimungkinkan
Agar efektif, testing dapat dilakukan oleh pihak ketiga
2.5 Strategi Testing
Strategi testing software mengintegrasikan metode - metode disain
test cases software ke dalam suatu rangkaian tahapan yang
terencana dengan baik sehingga pengembangan software dapat berhasil.
Strategi menyediakan peta yang menjelaskan tahap - tahap yang
harus dilakukan sebagai bagian dari testing, dan membutuhkan usaha,
waktu, dan sumber daya bilamana tahap - tahap ini direncanakan dan
dilaksanakan.
Strategi testing harus menjadi satu kesatuan dengan perencanaan
tes, disain test case , ekesekusi tes, dan pengumpulan serta
evaluasi datahasil testing.
Strategi testing software harus cukup fleksibel untuk dapat
mengakomodasi kustomisasi pendekatan testing. Pada saat yang
bersamaan, harus juga cukup konsisten dan tegas agar dapat melakukan
perencanaan yang masuk akal dan dapat melakukan manajemen
perkembangan kinerja proyek.
2.6 Pendekatan Strategi Testing
Sejumlah strategi testing software diadakan untuk menyediakan
kerangka testing bagi pengembang software dengan karekteristik umum
sebagai berikut:
Testing dimulai dari tingkat komponen terkecil sampai pada integrasi
antar komponen pada keseluruhan sistem komputer tercapai. Teknik testing
berbeda - beda sesuai dengan waktu penggunaannya. Testing dilakukan
oleh pengembang software dan (untuk proyek besar) dilakukan oleh suatu
8
grup tes yang independen. Testing dan debugging adalah aktifitas yang
berlainan, tapi debugging harus diakomodasi disetiap strategi testing.
2.7 Unit Testing
Unit testing berfokus pad usaha verifikasi pada unit terkecil dari disain
software – komponen atau modul software.
Penggunaan diskripsi disain tingkat komponen sebagai tuntunan, jalur
kendali yang penting dites untuk menemukan errors , terbatas pada modul
tersebut. Kompleksitas relatif terhadap tes dan errors yang dicakup dibatasi
oleh batasan - batasan dari cakupan yang telah ditetapkan pada unit testing .
Unit testing berorientasi white box , dan tahapan dapat
dilakukansecara paralel pada banyak komponen.
2.8 Integrasi Testing ke Dalam Siklus Hidup Software
Secara umum, integrasi testing ke dalam siklus hidup software, dapat
dituliskan ke dalam bentuk tahapan dari siklus hidup software, sebagai
berikut :
1. Inisialisasi Proyek
a. Mengembangkan strategi tes secara garis besar.
b. Menetapkan pendekatan dan usaha tes secara keseluruhan.
2. Kebutuhan
a. Menetapkan kebutuhan testing.
b. Menetapkan penanggung jawab testing.
c. Mendisain prosedur tes dan tes berbasis kebutuhan, awal.
d. Melakukan tes dan validasi kebutuhan.
3. Disain antara
a. Menyiapkan rencana tes sistem dan spesifikasi disain, awal.
b. Menyelesaikan rencana acceptance test dan spesifikasi disain.
c. Menyelesaikan tes berdasarkan disain.
d. Melakukan tes dan validasi disain.
4. Pengembangan
a. Menyelesaikan rencana tes sistem.
b. Menyelesaikan prosedur tes dan tes berbasis kode, final.
c. Menyelesaikan disain modul atau unit tests.
d. Melakukan tes program.
e. Integrasi dan melakukan tes sub sistem.
9
f. Melakukan system test.
5. Implementasi
a. Melakukan acceptance test.
b. Tes perubahan dan perbaikan.
c. Evaluasi efektifitas testing.
6. Faktor penentu kasuksesan dari testing yang lainnya, adalah penerapan
teknik testing secara tepat yang diadopsi dan digunakan pada sepanjang
siklus hidup. Review merupakan alat bantu testing yang sangat
bermanfaat untuk digunakan pada sepanjang siklus hidup.
2.9 Testing Dengan Review
Pada awalnya review adalah alat bantu pengendalian manajemen.
Selama proyek berlangsung, manajemen memerlukan suatu penilaian dan
pengukuran kinerja proses yang telah berlangsung. Jadi obyektifitas dari
review adalah untuk mendapatkan informasi yang konsisten dan dapat
dipercaya, biasanya berupa status dan atau kualitas kerja. Terdapat banyak
jenis dari review, yaitu : kebutuhan, spesifikasi, disain, coding, prosedural,
dokumentasi, konversi, instalasi, implementasi, disain tes, prosedur tes dan
rencana tes. Review hadir dalam dua bentuk, yaitu (1) formal dan (2) tidak
formal. Yang dipandang sebagai teknik testing adalah review dalam bentuk
formal, dimana partisipan bertanggung jawab untuk melakukan kalkulasi
secara akurat dan menghasilkan laporan dari apa yang telah mereka
temukan bagi manajemen.
Rencana review secara minimum, harus terdiri dari :
a. Siapa saja yang diharapkan akan hadir.
b. Informasi yang dibutuhkan sebelum memulai review.
c. Kondisi awal yang harus dipenuhi sebelum review dilakukan.
d. Daftar kegiatan atau item atau indikasi lainnya yang bersangkutan
dengan apa yang akan dibahas.
e. Kondisi akhir atau kriteria yang harus dipenuhi agar review dapat
dinyatakan selesai.
f. Data dan dokumentasi disimpan.
10
2.10 Testing Kebutuhan
Testing suatu dokumen harus mempertimbangkan dua pertanyaan
dasar, yaitu :
a) Apakah ada kebutuhan yang hilang?
• Apakah semua fungsi yang dibutuhkan telah dialamatkan dengan
benar?
• Apakah kinerja yang dibutuhkan telah dispesifikasikan?
• Apakah kualitas software telah dispesifikasikan?
• Apakah software telah sepenuhnya didefinisikan?
b) Dapatkah suatu kebutuhan disederhanakan atau dihilangkan?
• Dapatkah kebutuhan dikombinasikan?
• Apakah ada kebutuhan yang sangat restriktif?
• Apakah ada kebutuhan yang redundansi atau kontradiksi?
Teknik-teknik yang berguna dalam testing kebutuhan, termasuk :
a) Matrik validasi kebutuhan.
b) Model atau prototipe.
c) Pengembangan secara bertahap.
d) Tabel keputusan dan grafik sebab dan akibat.
e) Penggrupan dan analisa kebutuhan.
2.11 Testing Desain Sistem
Sebagaimana pada testing kebutuhan, pada testing disain sistem juga
mempunyai dua pertanyaan dasar, yaitu :
a) Apakah solusi merupakan pilihan yang benar?
• Dapatkah disain dicapai dengan lebih sederhana?
• Apakah merupakan pendekatan alternatif yang terbaik?
• Apakah merupakan cara tercepat untuk melakukan pekerjaan?
b) Apakah solusi memenuhi kebutuhan?
• Apakah semua kebutuhan telah dicakup dalam disain?
• Apakah merupakan disain kerja?
• Apasaja sumber dan resiko dari kegagalan?
c) Simulasi dan model.
d) Kompetisi disain.
e) Kebutuhan dan disain test cases berbasis disain.
11
2.12 Otomatisasi Testing
Otomatisasi testing adalah alat bantu yang digunakan untuk
mempermudah proses dan dokumentasi tes, mengefisienkan eksekusi dari
tes, dan mempermudah pengukuran pada tes. Sehingga diharapkan dapat
memberikan peningkatan yang cukup besar dalam manajemen proses,
meminimalkan keterlibatan manusia, dan replikasi pekerjaan. Otomatisasi
testing adalah area yang paling tinggi tingkat perkembangannya dalam
industri testing. Mengapa otomatisasi testing dibutuhkan ?
1. Testing selalu dihadapkan pada masalah jadual yang ketat.
2. Testing sering diulang-ulang banyak kali.
3. Testing berkemungkinan untuk dijalankan selama 24 jam sehari, atau
tidak pada jam kerja.
4.Testing dapat dilakukan dengan lebih cepat dan akurat, dimana
ketidakkonsistenan manusia dapat diminimalkan.
5. Dokumentasi testing dapat dilakukan secara konsisten, sehingga dapat
diaudit secara penuh dan berkala.
6. Script testing dapat menjadi aset yang dapat digunakan kembali untuk
testing yang sama pada proyek testing yang lain.
7. Mempercepat dalam peninjauan kembali terhadap testing itu sendiri.
8. Dapat meningkatkan proses.
Otomatisasi testing hendaknya dimulai dari hal yang paling mudah
terlebih dahulu, dan secara bertahap meningkatkan kompleksitas dari kasus
yang diotomatisasi. Bagaimanapun, testing secara manual untuk beberapa
kasus masih tetap diperlukan, dan pengembangan otomatisasi testing harus
selalu berdasar pada pertimbangan-pertimbangan praktis.\
Berdasarkan pada cara pengembangan otomatisasi tes, terdapat dua
macam kelompok tes, yaitu :
a. Kesehatan Tes
• Jalankan sebelum testing secara keseluruhan dimulai, untuk
menentukan apakah sistem layak untuk digunakan untuk testing
secara keseluruhan.
• Jalankan secepatnya, kurang dari satu jam.
• Cek apakah ada kejutan yang tidak diinginkan terjadi.
12
b. Tes keseluruhan
• Selesaikan secara komplit rangkaian-rangkaian tes yang telah
ditetapkan.
• Mungkin membutuhkan beberapa jam atau mungkin beberapa hari
untuk menyelesaikannya.
Kelebihan dari otomatisasi testing, adalah sebagai berikut :
a. Mampu melakukan testing secara lebih menyeluruh, dan dapat
meningkatkan kinerja regression testing.
b. Durasi waktu yang lebih pendek dalam pelaksanaan testing, sehingga
dapat memperbanyak waktu pemasaran atau pun hal strategis
lainnya.
c. Meningkatkan produktivitas dari pemakaian sumber daya, dimana
tester sangat sulit didapatkan dan mahal. Disamping itu tingkat
kepercayaan akan keberhasilan proyek testing pun dapat ditingkatkan.
d. Mengurangi kesalahan dan keteledoran tester, seperti tidak
terdeteksinya error, kecerobohan dalam menekan tombol, dll.
e. Melakukan pencatatan secara detil tes log dan item-item yang diaudit,
dimana semua hasil eksekusi tes dapat disimpan secara tepat dan
teliti untuk proses debugging.
Sedangkan kekurangan dari otomatisasi tes, antara lain :
a. Membutuhkan waktu untuk inisialisasi tes.
b. Membutuhkan perawatan test cases, agar modifikasi tingkah laku
sistem yang dilakukan dapat dijaga konsistensinya dengan yang
lama, dan agar dapat menghindari keberadaan fitur yang tidak stabil.
c. Membutuhkan waktu beberapa minggu pembelajaran agar
didapatkan tingkat kemampuan yang diharapkan.
d. Tetap tidak dapat sepenuhnya menghilangkan testing manual.
Umumnya 50 - 75% test cases tidak dapat diotomatisasi (tergantung
pada lingkungannya).
e. Membutuhkan biaya investasi yang dapat mencapai US$ 30000
untuk lisensi pengguna tunggal.
f. Terdapatnya batasan teknis, baik terhadap lingkungan sistem
operasi, tipe aplikasi, waktu respon, dll.
13
g. Beberapa alat bantu otomatisasi masih berorientasi pada
programmer, sehingga tidak cocok untuk pengguna akhir yang awam
pemrograman.
h. Kesulitan dalam memfokuskan tes untuk diotomatisasi, dimana
kasus-kasus yang beresiko tinggi dapat dicakup secara keseluruhan.
i. Kurangnya stabilitas dan dukungan, dimana kebanyakan vendor
penyedia alat bantu otomatisasi tes tidak dapat dengan cepat
merespon terhadap bug yang terjadi pada alat bantu tesebut, serta
kurangnya ketersediaan pengguna yang berpengalaman dipasaran
kerja.
Organisasi harus menghindari hambatan-hambatan yang dapat
menyebabkan kegagalan dari implementasi otomatisasi testing, dengan
memastikan pemenuhan dari hal-hal sebagai berikut :
a. Identifikasi kebutuhan untuk melakukan otomatisasi testing, seperti
(1) analisa biaya dari usaha untuk berpindah ke otomatisasi,
(2) hasil analisa dari pengukuran yang mengindikasikan kebutuhan
untuk meningkatkan kinerja testing dengan melakukan
otomatisasi testing, dan
(3) keluhan dari tester karena pelaksanaan tes ulang secara
manual.
b. Dukungan organisasional, seperti
(1) kecukupan sumber daya dan anggaran untuk memesan alat
bantu, mengadakan pelatihan, dan melakukan evaluasi,
(2) dukungan dan pemahaman manajemen secara mendasar.
c. Proses testing yang telah stabil (terdefinsi dan termanajemeni
dengan baik), karena otomatisasi tes
(1) tidak membantu dalam penentuan apa yang akan dites, dan tes
mana yang akan diimplementasikan, tetap membutuhkan disain
tes,
(2) tidak dapat menertibkan kekacauan proses,
(3)membutuhkan proses-proses pendukung lainnya, seperti
manajemen konfigurasi dari data tes.
14
1. Tujuan Bug tracking database
• Mengkomunikasikan bug dengan jelas. Laporan kesalahan yang
ditulis dengan baik sesuai standar akan menjelaskan suatu masalah
lebih baik daripada menggunakan email atau catatan biasa.
• Memudahkan pemantauan dan pencarian bug yang pernah terjadi
dengan melakukan penomoran bug secara otomatis.
• Proses perbaikan dapat dilakukan berdasarkan prioritas dan efek
bug pada sistem, Pengelolaan bug dalam suatu siklus pengelolaan
dapat dilakukan dengan lebih baik. Untuk memantau agar bug yang
ada dapat diperbaiki secepat mungkin sesuai dengan prioritasnya.
• Memberikan informasi baru bagi pengembang, tester, dan
manajer. Bug Tracking Databases yang dirancang dengan baik akan
memberikan gambaran histori yang baik yang dapat digunakan
sebagai referensi kemudian hari. Sumber informasi bagi support
department.
2. siklus hidup pengelolaan kesalahan
- Review
Review setelah tester melakukan pengetesan bug report direview
oleh Test Manager
- Rejected
Rejected, bila bug report tidak jelas atau kurang informasi, maka
bug report tersebut ditolak untuk diperbaiki oleh si tester
- Open
Jika bug report sudah direview dan diterima maka bug report
tersebut open untuk dilihat oleh developer
- Assigned
Jika developer menerima bug report tersebut, kemudian menunjuk
developer untuk memperbaiki bug tersebut
- Test
Setelah diperbaiki oleh developer maka ditest kembali dan dilakukan
regression test
- Reopened
Jika perbaikannya masih ada yang salah, maka bug dibuka kembali
agar dapat diperbaiki oleh developer
15
- Closed
Jika bug sudah selesai diperbaiki, status bug sudah selesai maka
ditutup
- Deffered
Bila bug tersebut dianggap tidak perlu diperbaiki sekarang karena
mempunyai prioritas yang rendah, atau digunakan untuk versi yang
akan datang
model organisasi testing
Testing Manager memberi laporan kepada Development Manager.
Test Engineer dipimpin oleh seorang pemimpin (Lead Test Engineer)
yang akan mengkomunikasi-kan hasil testing langsung pada Development
Manager. Model ini cocok bila kita bekerja dalam suatu kelompok dengan
jumlah personel yang sedikit (jumlahnya hanya belasan).
Kesalahan pada Model Darsar Organisasi Testing Figure 9.1 :
Test group menjadi tidak independen. Proses testing tidak
mendapatkan akses terhadap sumber daya yang dibutuhkannya.Sumber
daya yang dimilikinya tidak hanya digunakan untuk testing.
Peranan testing menjadi tidak jelas, karena hanya digunakan sebagai
saran dalam pengembangan sistem, bahkan mungkin pelaku testing akan
bekerja sebagai developer juga.
Test Manager dan Development Manager keduanya memberi laporan
kepada Project Manager. Struktur organisasi testing ini bukan merupakan
solusi yang sempurna tetapi merupakan perbaikan dari struktur organisasi
16
testing sebelumnya. Dalam struktur ini test group masih tidak independen
seutuhnya, krn. Test Manager memberikan jawaban kpd. Project
Manager.
Kelebihannya, dalam struktur ini keterlibatan Project Manager dalam
proses pengembangan sistem menjadi berkurang. Bagian pengembangan
dan bagian testing memiliki pegawai dan budget yang terpisah.Unit testing
dalam organisasi menjadi lebih berperanan karena seluruh laporan
kesalahan langsung diberikan pada project management.
Kerugian : apabila dalam pelaksanaan suatu proyek ternyata tidak
sesuai dengan jadwal, maka test group harus memberikan rasa simpati
pada bagian pengembangan dan harus membantunya (melakukan kerja
lembur) untuk menyelesaikan proyek tersebut agar tepat waktu.
Merupakan model organisasi testing yang paling baik. Team tes dalam hal
ini benar2 independen.
Perhatian dan tujuan manajemen adalah untuk mempromosikan
keunggulan perusahaan, oleh karena itu manajemen akan menerima
laporan status tes dengan pikiran yang terbuka.
Masalah2 yang berkaitan dg pengaruh, alokasi dana, dan
sumberdaya manusia diminimumkan.
cara Distribusi
• Melibatkan vendor : perusahaan yang menyediakan produk yang
akan dintegrasikan pada produk yang sedang dikembangkan.
• Melibatkan organisasi testing independen.
• Melibatkan kantor pemasaran (terutama kantor di luar negeri
untuk melakukan testing lokalisasi)
• Melibatkan pemakai/pelanggan (beta testing)
2.13 Software Testing
White box :
Mengetahui internal dari software, design test dijalankan pada
semuainternal dari software untuk memastikan mereka beroperasi
berdasarkan spesifikasi dan design. Fokus utama: internal structures, logic
paths, control flows, data flows internal data structures, conditions, loops, etc.
17
Sering disebut juga glass-box testing, merupakan metode testing yang
menggunakan kontrol struktur dari rancangan prosedural untuk melakukan
test case.
Testing dilakukan untuk memastikan :
1.Semua path independen di eksekusipaling tidak sekali
2.Semua keputusan logikal dieksekusi untuk path yang benar dan yang
salah
3.Semua loop dieksekusi pada semua nilai batasnya
4.Semua strukturdata internal dicoba untuk memastikan kevalidan, Basis
Path testing & Control Structure Testing
Mengapa White Box Testing :
1. Banyak error dalam “special case” code yang jarang dieksekusi
2. Control Flow tidak dapat diprediksi secara akurat dalamblack-box
testing.
3. Typos error dapat terjadi dimana saja !
Black-box testing:
Mengetahui fungsi spesifik dari software, design test untuk
mendemonstrasikan setiap fungsi dan mengecek apakah terjadi error atau
tidak. Fokus utama: functions, operations, external interfaces, external data
and information.
Metode yang diambil adalah metode pengujian Black Box. Pengujian
Black Box adalah pengujian aspek fundamental sistem tanpa memperhatikan
struktur logika internal perangkat lunak. Metode ini digunakan untuk
mengetahui apakah perangkat lunak berfungsi dengan benar. Pada metode
ini data uji dibangkitkan, dieksekusi pada perangkat lunak dan kemudian
keluaran dari perangkat lunak dicek apakah telah sesuai dengan yang
diharapkan.
Faktor pengujian yang digunakan, antara lain :
1. Authorization
Menjamin data diproses sesuai dengan ketentuan manajemen yang
mana menyangkut proses transaksi secara umum yaitu otoritas bisnis.
2. Audit Trail
Menekankan pada kemampuan untuk mendukung proses yang terjadi.
Pemrosesan data secara keseluruhan berdasarkan retensi dari
18
kejadian yang cukup mendukung keakuratan, kelengkapam, batas
waktu dan otorisasi data.
3. Realiability
Menekankan bahwa aplikasi akan dilaksanakan dalam fungsi sesuai
yang diminta dalam periode waktu tertentu. Pembetulan proses
tersangkut kemampuan sistem untuk memvalidasi proses secara
benar.
4. Service levels
Service levels menekankan pada tingkat layanan yang diinginkan oleh
user, desain metode dan desain sistem untuk mencapai tingkat
layanan yang diinginkan user.
5. Correctness
Menjamin pada data yang dimasukan, proses dan output yang
dihasilkan dari aplikasi harus akurat dan lengkap.
2.14 Basis Patch – Testing
1. Proposed by Tom McCabe
2. Bertujuan untuk melakukan pengukuran kompleksitas logikal dari
rancangan prosedur dan menggunakannya sebagai guide untuk
menentukan set dari path yang dieksekusi.
3. Basic set akan dieksekusi oleh setiapstatement paling tidak sekali
4. Isu
a. Flow Graph Notation
pada flow graph:
- Panah disebut edges menggambarkan flow of control
- Lingkaran disebut nodes, menggambarkan satu atau lebih aksi
- Area yang dibatasi oleh edges dan nodes diebut regions
- Predicate Nodes adalahnodes yang mengandung kondisi
- Setiap procedural design dapat ditranslasikan ke flow graph
notation
b. CyclomaticComplexity
- Memberikan ukuran kuantitatif dari kompleksitas logikal.
19
- Nilainya memberikan jumlah dari independent path dalam basis
set dan upper bound dari jumlah test untuk memastikan bahwa
setiapstatement dieksekusi paling tidak satu kali.
- Independent path adalah setiap path padaprogram yang
mengenalkan paling tidak satu set baru statement yang sedang
diproses atau kondisi baru (mis. Edge baru).
- Contoh :
CyclomaticComplexity of 4. Dihitung dari:
1.Number of regions of flow graph.
2.#Edges -#Nodes + 2
3.#Predicate Nodes + 1
Independent Paths:
1.1, 8
2.1, 2, 3, 7b, 1, 8
3.1, 2, 4, 5, 7a, 7b, 1, 8
4.1, 2, 4, 6, 7a, 7b, 1, 8
Cyclomatic complexity menyediakanupper bound untuk jumlah
test yang dibutuhkan dan dapat menjamin, melingkupi, semua
statements dalam program.
c. Deriving Test Cases
Gunakan design atau code, gambarkan flow graph
- Tentukan cyclomatic complexity dari flow graph
- Tentukanbasis set dari independent path
- Siapkantest case yang akan memaksa eksekusi dari setiap path
dalam basis setNote. Beberapa path mungkin hanya dapat
dieksekusi sbg bagian dari test yang lain.
d. Graph Matrices
- Dapat mengotomatisasi turunan dari flow graph dan menentukan
set dari basis path
- Graph matrix:
- Adalah bujur sangkar dengan #sides sama dengan #nodes
- Baris dan kolom menggambarkan nodes
- Isi matriks menggambarkan edges
20
- Gunakan nilai 1 untuk menghitung cyclomatic complexity
- Untuk setiap baris, jumlahkan nilai kolom dan kurangkan
dengan 1
- Jumlahkan totalnya dan tambahkan dgn 1 = CC
- Link dapat diberikan bobot, sehingga dapat menentukan:
- Probabilitas bahwa sebuah link (edge) akan dieksekusi
- Waktu proses yang dihabiskan selama mengunjungi sebuah
link
- Memory danresource yang dibutuhkan selama mengunjungi
sebuah link
2.15 Control Struktur Testing
- Condition Testing
Condition testing bertujuan untuk melatih seluruh kondisi logika
dalam modul program
- Dapat mendefinisikan:
Relational expression: (E1 op E2),dimana E1 dan E2 adalah
ekspresi aritmatika.
Simple condition : variabel Boolean atau ekspresirelational,
kemungkinan didahului dengan sebuah operator NOT.
Compound condition : Gabungan dari dua atau lebih kondisi
sederhana, operator Boolean dan parentheses.
Boolean expression : kondisi tanpa ekspresirelational.
- Errors dalam ekspresi dapat berdasarkan pada:
Boolean operator error
Boolean variable error
Boolean parenthesis error
Relational operator error
Arithmetic expression error
Metodecondition testing fokus kepada testing setiap kondisi dalam
program
- Strategi meliputi:
Branch testing – eksekusi setiap branch paling tidak satu kali.
21
Domain Testing –menggunakan tiga atau empat test untuk setiap
operator relational.
Branch and relational operator testing – menggunakan condition
constraints
Contoh1: C1 = B1 & B2 dimana B1, B2 adalah boolean conditions.
Condition constraint of form (D1, D2) where D1 and D2 can be true
(t) or false(f).
The branch and relational operator test membutuhkan constraint set
{(t,t),(f,t),(t,f)} yang harus ditemukan dengan eksekusi dariC1.
Pencakupan constraint setmenjamin deteksi darirelational operator
errors.
2.16 Loop Testing
Fundamental loop bagi banyak algoritma
Dapat mendefinisikan loop dengan simple, concatenated,
nested,dan unstructured.
Definisi:
• Loop adalah sistem yang terintegrasi untuk menggabungkan
instrument field device (input) dari dan (output) ke lapangan dengan
sistem control yang jejaringnya dihubungkan dengan wiring.
• Open Loop adalah hubungan signal satu arah dari lapangan (input)
ke sistem kontrol atau sebaliknya (output) dari sistem kontrol ke
lapangan.
• Input dan output tidak mempunyai hubungan. Sehingga ketika action
output ke lapangan yang merubah proses, tidak ada feedback yang
diberikan ke loop.
• Closed Loop adalah siklus signal dari lapangan (input) ke sistem
kontrol kemudian diolah dan menghasilkan signal output yang akan
dikirimkan kembali ke final element di lapangan (output). Dan action
dari final element itu akan berpengaruh pada input.
• Single Loop adalah loop sederhana dapat berupa open loop atau
closed loop sederhana.
• Pre-Commissioning adalah aktivitas untuk memastikan bahwa setiap
instrument input devices, sistem control, dan instrument final element
dapat beroperasi sebagaimana control design untuk menunjang
22
proses. Pre-commissioning dapat juga disebut function test untuk
setiap loop.FGH/
• Commissioning adalah aktivitas untuk membuat suatu sistem ‘LIVE’
dan beroperasi secara normal. Commissioning melibatkan
multidisiplin dan multi loop. Instrument dan control sistem harus
dapat berfungsi normal untuk mengontrol sistem multidisiplin
(proses, electrical, mechanical) yang sedang berjalan dan juga
menjaga safety protection systemnya dalam kondisi kritikal. Contoh:
Instrument Air System, Separation System, Power Generation
System, Heating Medium System, dll. Start-Up adalah aktivitas untuk
menghidupkan semua sistem yang menunjang beroperasinya plant
secara keseluruhan. Seluruh field device input, logic control, final
element untuk berbagai sistem pada seluruh plant harus beroperasi
dan terkontrol sempurna sebagaimana desain proses.Contoh: Start-
Up semua system yang sudah pernah dicommissioning dengan
sequence sesuai dengan requirement process or utility. Jadi pada
dasarnya Pre-Commissioning untuk Instrument adalah Loop Check
dan langkah-langkahnya adalah sebagai berikut:
Loop Test untuk SMART Transmitter:
1. Memastikan bahwa Hook-Up installation sudah benar.
2. Memastikan bahwa wiring terminasi sudah benar dengan melakukan
cold wire test or continuity test end to end dari field device sampai
marshalling panel.
3. Memastikan polarity sudah benar.
4. Menyambungkan knife switch di marshalling panel.
5. Instrument harus terenergize, pastikan dari indicator atau check voltage-
nya.
6. Melakukan Trim yaitu check ZERO and SPAN.
7. Monitor di Engineering Work Station value yang dikirim dari lapangan
harus sesuai ZERO dan SPAN-nya.
8. Melakukan injeksi proses (pressure, level, temperature) pada transmitter
tapping point dan verify indikator lokal serta verify signal yang dikirim ke
Engineering Work Station.
9. Melakukan linearisasi 0%, 25%, 50%, 75%, 100%.
23
10. Loop Test Complete.
Loop Test untuk SMART Control Valve adalah:
1. Melakukan langkah-langkah seperti point 1- 4 seperti pada SMART
transmitter.
2. Check voltage pada terminal control valve.
3. Pastikan pada saat ZERO signal control valve fully closed.
4. Manual injeksi sinyal dari Engineering Work Station 0%, 25%, 50%, 75%,
100% dan Control Valve harus menunjukkan nilai travel linear yang
sama. Apabila tidak sama maka lakukan AUTO-CALIBRATION.
5. Check kondisi FAIL POSITION dengan melepas kabel atau mengisolate
air supply.
6. Untuk close loop lakukan setting AUTO pada faceplate workstation.
7. Check control action REVERSE or DIRECT.
8. Loop Test Complete
Loop Test untuk FIELDBUS Transmitter adalah:
1. Melakukan langkah-langkah seperti point 1- 5 pada SMART transmitter.
2. Request Control Engineer or Software Specialist untuk melakukan
Fieldbus configuration dan lakukan download.
3. Melakukan langkah-langkah seperti pada point 6-10 pada SMART
transmitter.
Loop Test untuk FIELDBUS Control Valve adalah:
1. Melakukan langkah-langkah seperti point 1- 2 pada SMART Control
Valve.
2. Request Control Engineer or Software Specialist untuk melakukan
Fieldbus configuration dan lakukan download.
3. Melakukan langkah-langkah seperti point 3- 8 pada SMART Control
Valve.
24