Mata Kuliah Modul Minggu Pokok Bhs

: : : :

Testing & Implementasi Sistem Informasi 11 11

Perancangan Testing dan Pengembangan Sistem (bagian 02)

______________________________________________________
Materi bahasan : 1. Testing TerOtomasi 2. Testing dengan Spesifikasi yang Berevolusi 3. Testing Berorientasi Objek 4. Testing workbenches 1. Testing TerOtomatisasi 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.

a. Alasan Mengapa otomatisasi testing dibutuhkan? Testing selalu dihadapkan pada masalah jadual yang ketat. Testing sering diulang-ulang banyak kali. Testing berkemungkinan untuk dijalankan selama 24 jam sehari, atau tidak pada
jam kerja.

Testing

dapat

dilakukan

dengan

lebih

cepat

dan

akurat,

dimana

ketidakkonsistenan manusia dapat diminimalkan.

Dokumentasi testing dapat dilakukan secara konsisten, sehingga dapat diaudit

secara penuh dan berkala.

Script testing dapat menjadi aset yang dapat digunakan kembali untuk testing
yang sama pada proyek testing yang lain.

Mempercepat dalam peninjauan kembali terhadap testing itu sendiri. Dapat meningkatkan proses.
b. Otomatisasi testing hendaknya dimulai dari hal yang paling mudah terlebih dahulu, dan secara bertahap meningkatkan kompleksitas dari kasus yang diotomatisasi. c. Bagaimanapun, testing secara manual untuk beberapa kasus masih tetap diperlukan, dan pengembangan otomatisasi testing harus selalu berdasar pada pertimbangan-pertimbangan praktis.

11

Testing dan Implementasi SI Ratna Mutu Manikam, S.Kom. MT.

Pusat Pengembangan Bahan Ajar Universitas Mercu Buana

d. Berdasarkan pada cara pengembangan otomatisasi tes, terdapat dua macam kelompok tes, yaitu:

Sanity test
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.

Tes keseluruhan
Selesaikan secara komplit rangkaian-rangkaian tes yang telah ditetapkan. Mungkin membutuhkan beberapa jam atau mungkin beberapa hari untuk

menyelesaikannya. e. Efisiensi otomatisasi testing ditandai dengan terjadinya peningkatan dalam hal:

Duplikasi
Tes dapat diduplikasi untuk kasus yang berbeda. Berguna bagi load dan stress testing untuk menduplikasi tes dalam jumlah

besar.

Pengulangan
Tes yang sama dapat berlaku berulangkali. Berguna bagi regression testing untuk memastikan modifikasi yang secara

tidak langsung mempengaruhi sistem. Menurut studi dari Quality Assurance Institute [QAQ95A], yang menggunakan ukuran jumlah test cases dalam membandingkan tes manual dan tes otomatis, dimana digunakan 1750 test cases dan ditemukan 700 errors, didapatkan hasil sebagaimana terdapat pada tabel berikut:

f.

Tabel 1-3 Testing terOtomasi vs Manual Kelebihan dari otomatisasi testing, adalah sebagai berikut:

Mampu melakukan testing secara lebih menyeluruh, dan dapat meningkatkan

kinerja regression testing.

11

Testing dan Implementasi SI Ratna Mutu Manikam, S.Kom. MT.

Pusat Pengembangan Bahan Ajar Universitas Mercu Buana

 Durasi waktu yang lebih pendek dalam pelaksanaan testing, sehingga dapat
memperbanyak waktu pemasaran atau pun hal strategis lainnya.

Meningkatkan produktivitas dari pemakaian sumber daya, dimana tester sangat

sulit didapatkan dan mahal. Disamping itu tingkat kepercayaan akan keberhasilan proyek testing pun dapat ditingkatkan.

Mengurangi kesalahan dan keteledoran tester, seperti tidak terdeteksinya error,

kecerobohan dalam menekan tombol, dll.

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. g. Sedangkan kekurangan dari otomatisasi tes, antara lain: Membutuhkan waktu untuk inisialisasi tes. 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. Membutuhkan waktu beberapa minggu pembelajaran agar didapatkan tingkat kemampuan yang diharapkan. Tetap tidak dapat sepenuhnya menghilangkan testing manual. Umumnya 50 75% test cases tidak dapat diotomatisasi (tergantung pada lingkungannya). Membutuhkan biaya investasi yang dapat mencapai US$ 30000 untuk lisensi pengguna tunggal. Terdapatnya batasan teknis, baik terhadap lingkungan sistem operasi, tipe aplikasi, waktu respon, dll. Beberapa alat bantu otomatisasi masih berorientasi pada programmer, sehingga tidak cocok untuk pengguna akhir yang awam pemrograman. Kesulitan dalam memfokuskan tes untuk diotomatisasi, dimana kasus-kasus yang beresiko tinggi dapat dicakup secara keseluruhan. 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 h. Organisasi harus menghindari hambatan-hambatan yang dapat menyebabkan kegagalan dari implementasi otomatisasi testing, dengan memastikan pemenuhan dari hal-hal sebagai berikut:

11

Testing dan Implementasi SI Ratna Mutu Manikam, S.Kom. MT.

Pusat Pengembangan Bahan Ajar Universitas Mercu Buana

 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.

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.

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 prosesproses pendukung lainnya, seperti manajemen konfigurasi dari data tes. 2. Testing dengan Spesifikasi yang Berevolusi

a. Dalam pendekatan waterfall terdapat serangkaian fase terencana, dengan suatu

penanda akhir fase sebelum bergerak ke fase berikutnya. b. Fase-fase utama, adalah: analisa, disain, pemrograman, testing, dan instalasi. c. Pendekatan perfase, secara tak langsung memberikan komitmen terhadap proyek, dan membangun kendali pada proses pengembangan. Pendekatan Waterfall Model waterfall bekerja dengan baik, namun terdapat kendala-kendala sebagai berikut:
Pelanggan biasanya tidak mengetahui apa yang mereka inginkan hingga mereka

melihatnya. Harapan akan spesifikasi dapat didefinisikan secara keseluruhan di depan, kadang tidak realistik.
Keberadaan sekuensial fase-fase secara linear, penanda akhir fase, manajemen

review, dan dokumentasi yang dibutuhkan, menjadikan proses membutuhkan waktu yang lama dalam menyerahkan produk.
Sistem yang diserahkan biasanya tidak sesuai dengan yang dibutuhkan, sebagian

karena kebutuhan ini telah berubah dalam kurun waktu tunggu, dan sebagian lagi karena pengguna tidak pernah diikutsertakan secara mendalam dalam pendefinisian kebutuhan sistem.

Sistem yang diserahkan dapat menjadi tidak fleksibel, tidak dikembangkan untuk
mengakomodasi perubahan dan sulit untuk dirawat.

11

Testing dan Implementasi SI Ratna Mutu Manikam, S.Kom. MT.

Pusat Pengembangan Bahan Ajar Universitas Mercu Buana

 Bila terjadi perubahan spesifikasi selama proyek berlangsung, kebanyakan tim

pengembang tidak menyimpan definisi kebutuhan dan dokumen disain yang terkini. Pendekatan Prototyping Pendekatan prototyping, spiral / iterasi, dan rapid application development (RAD) terhadap pengembangan sistem adalah reaksi terhadap keterbatasan model waterfall. Pendekatan Spiral Pendekatan spiral / iterasi dikembangkan untuk lebih memberdayakan proses pengembangan dan perawatan sistem, melalui:
Memperlihatkan hasil dengan cepat, dalam bentuk prototype atau pengerjaan

sistem di awal dengan fungsional awal yang terbatas.

Mendukung pengguna

untuk berpartisipasi secara material dalam proses.

Bereksperimen dengan reaksi terhadap suksesi tiap iterasi pembangunan sistem.

Memungkinkan sistem dapat berevolusi dari waktu ke waktu, dan menjadi fleksibel
serta mudah untuk diubah.

Sistem pelatihan profesional terhadap RAD atau metodologi prototyping. Otorisasi dan pemberdayaan tim untuk menyelesaikan pekerjaan. Menerapkan konsep rekayasa software, dimana analisa, disain, pengkodean, dam
testing dilakukan secara paralel dalam suatu sekuensial fase yang linier.

Penggunaan pemrograman visual, alat bantu berorientasi obyek dalam

pengembangan dan modifikasi. Namun pendekatan prototyping, antara lain:
Proyek menjadi sulit diprediksi, dengan sedikit pengendalian dan cenderung

spiral / iterasi, RAD juga masih memiliki kendala,

mudah lepas kendali.

Arsitektur sistem biasanya tak terencana. Dengan makin meningkatnya perubahan-perubahan yang terjadi setiap waktu,

kadangkala sistem menjadi tidak dapat dirawat.

Fleksibilitas dan kemudahan perubahan dapat menjadi kontra produktif. Kebutuhan

dapat hilang kendali, atau dibatalkan dari suatu versi dan ditambahkan kembali pada versi berikutnya, sehingga tak pernah mencapai akhir proyek. Perbedaan model prototyping, spiral / iterasi, RAD dengan model waterfall

11

Testing dan Implementasi SI Ratna Mutu Manikam, S.Kom. MT.

Pusat Pengembangan Bahan Ajar Universitas Mercu Buana

Model water fall

Dalam model waterfall, testing berdasarkan pada dokumen spesifikasi atau definisi
kebutuhan.

Dokumen-dokumen ini diharapkan dapat diselesaikan secara komplit, benar dan

tidak berubah secara esensial, setidaknya selama proyek berlangsung.

Berdasarkan salinan dokumen-dokumen ini, tester mempelajari dan menganalisa

sistem dan mengembangkan rencana tes. Model prototyping, spiral / iterasi, dan RAD

Sedangkan spesifikasi dan definisi produk pada pendekatan prototyping, spiral / iterasi, dan RAD tidak tetap dan terus berevolusi secara tak pasti. Suatu definisi kebutuhan dan disain sistem berkemungkinan tidak akan pernah didokumentasikan, karena cepatnya pergerakan proyek; spesisikasi dapat dalam bentuk tak formal dan tak lebih dari koleksi memo-memo dan pertemuan sekilas dimana perkembangan didiskusikan.

Dan satu-satunya cara untuk melakukan testing adalah ikut masuk ke dalam keseluruhan proses spiral dari pengembangan. Tester harus sangat dekat dengan usaha pengembangan (beresiko kehilangan prespektif yang independen), dan melakukan tes versi baru segera setelah terselesaikan.

Testing tiap iterasi dilakukan secara singkat, dan fokus tiap iterasi tes harus mengutamakan fitur yang ditambahan atau diubah. Idealnya, harus menggunakan alat bantu otomasi dalam melakukan tes regresi, yang dapat digunakan untuk melakukan tes secara singkat terhadap produk versi baru yang dirilis.

Solusi permasalahan atau kendala pada pendekatan prototyping, spiral/iterasi, dan RAD Menetapkan suatu obyektifitas dan cakupan yang jelas di depan, dan jangan sampai keluar dari batasan yang ditetapkan selama proses pengembangan berlangsung. Pernyataan obyektifitas tidak perlu detil, namun dapat menentukan arah proyek. Menetapkan titik penilaian kembali secara periodek, untuk memastikan proyek masih sesuai dengan obyektifitas dan cakupan, dan proyek masih dalam arah yang tepat. Merencanakan secara bertahap, dan secara bertingkat menstabilkan sistem dalam kinerja spiral.

11

Testing dan Implementasi SI Ratna Mutu Manikam, S.Kom. MT.

Pusat Pengembangan Bahan Ajar Universitas Mercu Buana

 Spiral awal, yang biasanya hanya bersifat internal dan tidak untuk pelanggan

eksternal, tak dapat ditetapkan keberhasilannya dalam memenuhi kebutuhan, sehingga perbandingan alokasi sumber daya pengembangan dan testing dapat menjadi 5:1.
Harapan reliabilitas sangat rendah pada iterasi awal. Saat sistem mulai stabil,

rata-rata perubahan kode dari iterasi ke iterasi seharusnya menurun sekitar 20%.
Dan pada akhir spiral, sebelum kepastian dicapai, perbandingan alokasi sumber

daya pengembangan dan testing adalah 2:1 atau bahkan 1:1. 3. Testing Berorientasi Obyek Untuk melakukan testing sistem OO yang mencukupi, harus dilakukan tiga hal berikut:

definisi testing harus diperluas untuk mencakup teknik penemuan error yang
diaplikasikan ke dalam model OOA dan OOD;

strategi unit testing akan menjadi kurang berarti dan strategi integrasi harus
berubah secara signifikan;

disain test case harus bertanggung jawab terhadap karakteristik unik software OO.
Kebenaran Model OOA dan OOD Notasi dan sintaksis digunakan untuk menggambarkan model analisa dan disain akan sangat terkait dengan metode analisa dan disain tertentu yang digunakan pada proyek. Karenanya kebenaran sintaksis dinilai berdasarkan pada ketepatan penggunaan simbologi, dan tiap model direview untuk memastikan ketepatan konvensi pemodelan yang akan dirawat. Selama analisa dan disain, kebenaran simantik harus dinilai berdasarkan pada pemenuhan model terhadap domain masalah yang sebenarnya. Konsistensi Model OOA dan OOD Konsistensi model OOA dan OOD dinilai dengan memperhatikan hubungan antar entitas dalam model. Untuk menilai konnsistensi, tiap class dan koneksinya dengan class lain harus diperiksa. Model Class-Responsibility-Colaboration dan diagram hubungan obyek dapat digunakan untuk membantu aktivitas ini. Model CRC berupa kartu berindex, yang tersusun dari nama class, tipe class, karakteristik class, tanggung jawab class (operasi yang ada), dan kolaborator-

11

Testing dan Implementasi SI Ratna Mutu Manikam, S.Kom. MT.

Pusat Pengembangan Bahan Ajar Universitas Mercu Buana

nya (class-class lain yang mengirim pesan dan yang bergantung pada pemenuhan tanggung jawabnya) a. Disain Test Case untuk Software OO Ada beberapa pendekatan menurut Berard :

Setiap test case harus secara unik diidentifikasikan dan harus secara explisit diasosiasikan dengan class yang akan ditest. Tujuan dari test case harus telah ditentukan. Daftar langkah langkah test harus dibangun dan berisi : Daftar dari status object yang akan ditest. Daftar dari message dan operasi yang akan diperiksa sebagai konsekuensi dari test case. Daftar perkecualian yang mungkin terjadi dari obyek yang dites. Daftar kondisi external (perubahan yang terjadi pada lingkungan external yang harus ada pada software agar dapat dites) Informasi pendukung yang akan digunakan untuk membantu pemahaman atau pengimplemenntasian dari tes.

b. Unit Testing dalam Kontek OO Enkapsulasi menentukan definisi dari class dan obyek.

Unit testing tidak melakukan tes pada tiap modul secara individual,
namun unit terkecil yang dites adalah class atau obyek yang di-enkapsulasi. Dalam OO kita tak dapat melakukan tes operasi tunggal dalam suatu isolasi, tapi harus dalam bagian dari class. Testing class untuk software OO sama dengan unit testing untuk software konvensional Tak seperti testing software konvensional, yang cenderung berfokus pada detil algoritma dari modul dan aliran data sepanjang interface modul, testing class untuk software OO ditentukan oleh operasi dari class yang dienkapsulasi dan tingkah laku dari class. c. Integration Testing dalam Kontek OO 1) Karena software OO tidak mempunyai struktur kendali dalam bentuk hirarkhi, strategi integrasi konvennsional (top-down / bottom-up integration) menjadi tak berarti. 2) Ada 2 strategi untuk testing integrasi dari sistem OO, yaitu:

11

Testing dan Implementasi SI Ratna Mutu Manikam, S.Kom. MT.

Pusat Pengembangan Bahan Ajar Universitas Mercu Buana

 Thread-based

Testing,

mengintegrasikan

sekumpulan

class

yang

dibutuhkan dalam merespon satu input atau event terhadap sistem. Tiap thread diintegrasikan dan dites secara individual. Used-based Testing, memulai konstruksi dari sistem dengan melakukan testing class-class (disebut independent class) yang menggunakan sangat sedikit (jika ada) class server. Setelah itu dilanjutkan dengan melakukan testing terhadap dependent class yang menggunakan independent class yang telah dites. Proses testing berlanjut terus hingga keseluruhan sistem selesai dikonstruksikan. d. Cluster Testing adalah suatu langkah dalam testing integrasi dalam software OO. Disini, suatu kluster mengkolaborasi class (ditentukan oleh CRC dan model hubungan obyek) diperiksa dengan mendisain test cases yang dapat untuk menemukan error dalam kolaborasi. e. Validation Testing dalam Kontek OO

Seperti pada validasi software konvensional, validasi software OO berfokus Test cases dapat diturunkan dari model tingkah laku obyek dan dari diagram alur

pada aksi user dan output dari sistem. kejadian (event) yang dibuat sebagai bagian dari OOA. f. Re- testing on Inheritance (Regression testing of Classes) Dalam teori testing ulang, suatu fungsi yang tidak diubah setelah diturunkan, adalah tidak perlu.

Fitur class yang sudah ditest perlu ditest ulang pada class yang menurunkannya. Dalam hal ini karakteristik yang sudah ditest sebelumnya kemudian di modifikasi
pada turunannya memerlukan test case yang berbeda.

Berapa banyak re- test diperlukan? Jawaban tergantung pada spesifik risk vs
economic tradeoff dari subclass yang menurunkan object.

Beberapa superclass mungkin tidak dipengaruhi oleh perubahan dalam class

yang diturunkannya g. Random testing Identifikasi operasi yang dapat digunakan pada class Definisikan constrain yang mungkin terjadi Identifikasi minimum test sequence, sequence yang mungkin terjadi

definisikan secara minimum dalam sejarahnya

11

Testing dan Implementasi SI Ratna Mutu Manikam, S.Kom. MT.

Pusat Pengembangan Bahan Ajar Universitas Mercu Buana

Jalankan berbagai macam test sequence secara random, terutama class

instance yang mempunyai sejarah yang kompleks h. Partitioning testing Menghemat banyak test case yang dibutuhkan oleh class yang banyaknya sama partitioning dalam konvensional software i. State based testing 1) 2) Kategori dan operasi test yang berjalan tergantung pada kemampuan dari Masalah yang mungkin terjadi class untuk berubah

Testing harus dapat memberikan semua report yang ada dan dapat
diakses oleh internal state dari object itu sendiri Informasi hiding : keadaan ini secara tidak langsung dapat diakses, tetapi dapat diakses jika class itu sudah di public j. Object-oriented testing

Komponen yang diuji adalah class-object. Lebih besar dibandingkan pengujian suatu function sehingga pendekatan whitebox testing perlu diperluas. Tidak jelasnya top suatu system untuk top-down integration dan testing.

k. Testing levels

Testing operations pada objects Testing object classes Testing clusters cooperating objects Testing OO system secara lengkap

l. Object class testing Complete test yang menguji class melibatkan

Testing semua operations suatu object Setting dan interrogating semua attribute object Menguji object untuk semua state(keadaan) yg mungkin

Inheritance akan mengakibatkan sulitnya perancangan object class tests seperti information yg diuji sulit dilokalisasi.

11

10

Testing dan Implementasi SI Ratna Mutu Manikam, S.Kom. MT.

Pusat Pengembangan Bahan Ajar Universitas Mercu Buana

m. Integrasi Object

Levels integrasi sedikit berbeda untuk sistem yang berorientasi object. Cluster testing digunakan untuk test integrasi and testing clusters terhadap cooperating objects Identifikasi clusters menggunakan knowledge dari operation objects dan system features yang diimplementasikan oleh cluster tersebut.

n. Approaches cluster testing

Use-case atau scenario testing

Testing

berdasarkan pada interaksi user dengan sistem. diujikan oleh user yg berpengalaman.

Keuntungannya

Object interaction testing

Tests

barisan interaksi object yang berhenti ketika suatu operation object tidak

memanggil service dari object lain. o. Scenario-based testing

Identifikasi scenarios dari use-cases dan menambahkannya dengan diagram interaksi yang menunjukkan object-object yang terlibat dalam scenario Lihat contoh scenario berikut ini pada sistem weather station ketika suatu report dibuat

p. Weather station testing

Thread pengeksekusian methode

CommsController:request WeatherStation:report WeatherData:summarise

Inputs dan outputs

Input report request dengan acknowledge yg sesuai serta output report akhir Dapat diujikan dengan membuat raw data dan meyakinkan bahwa dapat menghasilkan kesimpulan (summarize) yg sesuai. Gunakan raw data yg sama untuk menguji object WeatherData

4. Testing workbenches

11

11

Testing dan Implementasi SI Ratna Mutu Manikam, S.Kom. MT.

Pusat Pengembangan Bahan Ajar Universitas Mercu Buana

Testing merupakan suatu proses yg cukup mahal. Testing workbenches menyediakan tool-tool untuk mereduksi waktu yg dibutuhkan dan total cost pengujian

Kebanyakan testing workbenches merupakan open systems karena kebutuhan testing membutuhkan tergantung dr spesifikasi organisasi Sulit diintegrasikan dengan closed design dan analysis workbenches

Gambar : a testing workbench

Tetsing workbench adaptation

Scripts dibuat untuk user interface simulator dan model test data generator Test outputs harus disiapkan secara manual sebagai pembanding. Special-purpose file comparators harus dibuat

11

12

Testing dan Implementasi SI Ratna Mutu Manikam, S.Kom. MT.

Pusat Pengembangan Bahan Ajar Universitas Mercu Buana

11

13

Testing dan Implementasi SI Ratna Mutu Manikam, S.Kom. MT.

Pusat Pengembangan Bahan Ajar Universitas Mercu Buana