P. 1
Definisi Testing

Definisi Testing

|Views: 956|Likes:
Published by Yuez spectrum

More info:

Published by: Yuez spectrum on Apr 12, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

06/18/2014

pdf

text

original

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 diharapkan.  Menurut standar ANSI/IEEE 1059 Testing adalah proses menganalisa suatu entitas software untuk apakah telah memenuhi kebutuhan atau hasil yang

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 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. untuk menekankan tiga hal penting, yaitu: 1. kebutuhan perangkat lunak merupakan fondasi yang memulainya kualitas diukur. Kurangnya penyesuaian terhadap kebutuhan juga Definisi tersebut berfungsi software memiliki kecenderungan untuk mengalami

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.

Maintainabilitas Fleksibilitas; Testabilitas

Portabilitas Reusabilitas Interoperabilitas

REVISI PRODUK

TRANSISI PRODUK

OPERASI PRODUK

Kebenaran :

Reliabilitas

Usabilitas

Integritas

Efisiensi

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

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 mengakomodasi testing software harus cukup fleksibel Pada untuk saat dapat yang

kustomisasi pendekatan

testing.

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

2.15

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

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
22

dapat beroperasi sebagaimana control design untuk menunjang 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: StartUp 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 voltagenya. 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.
23

9. Melakukan linearisasi 0%, 25%, 50%, 75%, 100%. 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

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->