Iterative Testing Sebagai Pembanding Model Based Testing Untuk Teknik

Evaluasi Pengembangan Perangkat Lunak

Thomas Edyson Tarigan, S.Kom1, DR. Azhari SN, M.T2

1
Stmik Akakom Yogyakarta, 55198
E-mail : tarigan@akakom.ac.id
2
Fakultas FMIPA, Universitas Gadjah Mada, Yogyakarta
E-mail : arisn.softcomp@gmail.com

ABSTRAK

Kegiatan pengujian dimulai selama pengembangan sistem dan mencakup semua tahap yang sudah
ditentukan oleh masing - masing model pengujian. Beberapa pengembangan sistem, pengujian yang
dilakukan setelah fase coding, namun mungkin pada akhirnya akan menyebabkan perangkat
lunak tersebut akan menemukan banyak bug, sehingga perangkat lunak tersebut tidak dapat
digunakan dengan maksimal.
Pada tulisan ini akan dibandingkan model iterative testing dan model based testing untuk
melakukan pengujian pada perangkat lunak. yang bertujuan untuk melihat lebih dalam
keunggulan dan kelemahan masing masing model pengujian, sehingga pengembang sistem dapat
menentukan model pengujian yang lebih baik untuk model ini.
Model based testing memiliki dampak yang signifikan terhadap kualiats pengujian terhadap
sistem. Namun banyak industri masih bergantung pada metode pengujian yang bersifat tradisional.
keprihatinan terbesar terhadap model based testing adalah kebutuhan pengetahuan formal dan
biaya awal yang tinggi untuk memperkenalkan model ini.[1].
Pengujian iteratif dapat diterapkan di seluruh proses pengembangan perangkat lunak. karena
perubahan lebih mudah dan lebih murah untuk mengimplementasikan dalam tahap awal
pembangunan. Langkah awal dalam proses iteratif adalah untuk mengembangkan prototipe.
Prototipe harus dievaluasi oleh kelompok kerja ataupun kelompok yang tidak terkait langsung
dengan pengembangan perangkat lunak yang bertujuan untuk agar tidak terjadi bias pendapat.
Proses harus diulang sampai masalah pengguna telah berkurang pada tingkat yang memadai.

Keyword : Model based testing, Iterative testing dan Pengujian

INTISARI
Untuk membangun sebuah perangkat lunak salah satu tahapan yang harus dilakukan
adalah melakukan perancangan sistem, untuk itu dibutuhkan suatu metode yang akan
digunakan untuk melakukan perancangan perangkat lunak yang akan dibangun. Ada
beberpa metode yang dapat digunakan untuk melakukan perancangan perangkat
lunak, untuk menentukan metode yang digunakan maka banyak parameter yang
digunakan untuk melakukan pemilihan metode. Pada tulisan ini akan dibandingkan
dua metode yaitu Metode Iterative Testing dengan Model Based Testing untuk
melakukan pengujian terhadap perangkat lunak yang akan dibangun.

Keyword : Model based testing, Iterative testing dan Pengujian

 PENDAHULUAN

Menurut Myers [2], pengujian perangkat lunak adalah proses atau serangkaian
proses, yang dirancang untuk memastikan bahwa kode komputer melakukan apa
yang dirancang untuk melakukan apa yang sudah dirancang dan tidak melakukan
sesuatu yang tidak diinginkan. Software pengujian menjadi penting untuk perusahaan
untuk menjamin kualitas produk terlepas dari apakah metodologi yang digunakan.
Perangkat lunak otomatisasi pengujian adalah salah satu pendekatan utama yang
telah diterapkan untuk mengurangi biaya pengujian dan waktu pengujian dan
verifikasi hasil pengujian.
Secara umum pengujian bertujuan untuk memberikan informasi kepada
stackholder tentang kualitas produk atau jasa yang diuji. Pengujian juga dapat
memberikan pandangan selain itu tujuan lainnya adalah memahami resiko dari
implementasi perangkat lunak tersebut. Pengujian perangkat lunak tidak terbatas
hanya pada proses eksekusi sebuah program atau aplikasi tetapi juga menemukan bug
pada perangkat lunak yang di uji.
Pada 1970-an pertengahan, Goodenough dan Gerhart mengemukakan
pertanyaan yang mungkin paling penting dalam pengujian perangkat lunak : Apa
kriteria uji untuk pengujian perangkat lunak? Sejak itu sejumlah besar cakupan kriteria
telah diajukan dan diselidiki untuk menguji kemampuan mendeteksi kesalahan, sering
juga disebut sebagai "efektivitas".[3]
Kegiatan pengujian harus dimulai pada siklus awal pengembangan sistem dan
melakukan semua tahapannya. Namun, dalam beberapa buku teks rekayasa perangkat
lunak, sistem life cycle pengembangan sistem menunjukkan bahwa pekerjaan uji
dilakukan setelah akhir fase coding. [4]
Pengujian Iteratif adalah pengujian yang diulangi, atau iterasi beberapa kali. Pengujian
iteratif bertujuan untuk meningkatkan kualitas desain yang dirancang.
Sedangkan model based testing (MBT) adalah : teknik untuk generate secara otomatis
pengujian kasus menggunakan model dari spesifikasi kebutuhan dan skenario
perangkat lunak . Untuk menggunakannya, beberapa jenis model perangkat lunak
dibuat dalam bentuk model formal (seperti metode formal, UML diagram, dll)
tujuannya untuk menggambarkan perilaku perangkat lunak atau perilaku sistem.
Tulisan ini akan menyajikan proses perbandingan metode pengujian
perangkat lunak model iterative testing dengan model based testing yang bertujuan
untuk memperoleh model yang baik dalam menentukan model pengujian dalam
pengembangan perangkat lunak. adapun cara yang dilakukan adalah dengan merinci
tentang bagaimana iterative dan model based melakukan proses pengujian. pada
bagian 2, penjelasan tentang model based testing dan iterative testing. pada bagian 3,
menyajikan hasil dan pembahasan dibagian 4, penutup.

PEMBAHASAN

1. Model Based Testing (MBT)

Pendekatan utama MBT [5]
Ada tiga pendekatan utama MBT :
a. Online test berarti bahwa alat pengujian model langsung dihubungkan ke sistem
yang diuji dan menguji secara dinamis.
b. Offline generation of executable test berarti bahwa alat pengujian model based
menghasilkan uji kasus sebagai aset yang terbaca oleh komputer yang kemudian
dapat digunakan secara otomatis. Aset ini dapat berupa koleksi kelas phyton
yang mewujudkan hasil logika pengujian.
c. Offline generation of manually deployable test berarti bahwa alat pengujian model based
menghasilkan uji kasus sebagai aset yang terbaca oleh manusia yang dapat
kemudian digunakan secara manual. Aset ini misalnya berupa dokumen PDF
yang menjelaskan langkah langkah uji yang dihasilkan.
Ada beberapa langkah untuk implementasi model based testing : [10]
1. Membangun sebuah model
2. Input dan Output yang diharapkan
3. Menjalankan pengujian / test run
4. Membandingkan hasil output dengan hasil yang diharapkan.
5. Memutuskan tindakan lebih lanjut (apakah akan memodifikasi model,
generate kembali pengujian kasus, menghentikan pengujian, atau
memperkirakan kehandalan perangkat lunak (kualitas).

Untuk implementasi model based testing tersebut digambarkan sebagai berikut :[6]

Gambar 1 : Elemen Model Based Testing

Model adalah salah satu metode automated testing yang melakukan pengujian
berdasarkan model-model sistem, bisa Class Diagram, use case diagram, ER diagram.
Tetapi source terbesarnya adalah spesifikasi kebutuhan. Karena langkah pertama
MBT adalah membuat model baru yang sudah memiliki seluruh perilaku SUT
(System Under Test) dari model-model sistem sebelumnya.
Kelebihan MBT sendiri adalah dapat mengenerate test case secara otomatis dari
model yang telah dibuatnya. Dengan kata lain proses pengotomasian terjadi pada
praproses pengujian.

Proses umum model based testing akan menghasilkan sebagai berikut :

Langkah 1 :
Sebuah model SUT dibangun berdasarkan persyaratan atau spesifikasi dokumen yang
ada. Model ini mengkodekan perilaku yang dituju dan dapat berada pada berbagai
tingkat abstraksi.
Langkah 2 :
Seleksi kriteria pengujian didefenisikan. Secara umum, sulit untuk mendefinisikan
kasus tes yang baik. Pengujian kasus yang baik adalah yang kemungkinan akan
mampu mendeteksi kegagalan fatal dan dimungkinkan tanpa biaya yang mahal, dan
itu akan sangat membantu dengan mengidentifikasi kesalahan yang mendasarinya.
Langkah 3 :
Seleksi kriteria pengujian tersebut ditransformasikan menjadi spesifikasi pengujian
kasus. Spesifikasi pengujian kasus dirumuskan dalam bentuk konsep yang dapat
digunakan sebagai seleksi kriteria pengujian
Langkah 4 :
Setelah model dan spesifikasi pengujian kasus didefinisikan, test suite dihasilkan.
Himpunan uji kasus yang memenuhi spesifikasi uji kasus boleh kosong. Biasanya ada
banyak uji kasus yang memenuhi itu. Uji generator terjadi maka cenderung memilih
beberapa acak.

2. Iterative Testing
Iteratif desain adalah metodologi desain berdasarkan proses siklus
prototyping, menguji, menganalisa, dan memperbaiki pekerjaan yang sedang berjalan.
Dalam desain iteratif, interaksi dengan sistem yang dirancang digunakan sebagai
bentuk penelitian untuk menginformasikan dan berkembang proyek, sebagai versi
yang berurutan, atau iterasi dari desain diimplementasikan.[7]
Pengembangan dengan iterative merupakan sebuah pendekatan pada
pengembangan software yang lebih memusatkan gagasan pengembangan dalam
bentuk siklus, dari pada melakukan semuanya secara sekaligus. Metode ini tidak
sesuai pada semua jenis software namun dapat sangat bermanfaat dan sangat
menguntungkan pada pengaturan tertentu. Merupakan hal yang penting untuk
dipahami, bahwa pemgembangan iterative bukanlah merupakan sebuah
pengembangan yang tidak terencana atau spontan. Faktanya, proses pengembangan
software terstrukturisasi dengan baik.
Pada pengembangan iterative, memulainya dengan tahapan perencanaan
project, kemudian bergerak pada tahapan pengembangan lainnya dan pada akhirnya
merilis produk.
Sejalan dengan rilis produk, terdapat hasil yang diperoleh dari pengujian
produk (product testing) dan pengujian pada pengguna (user testings). Hasil tersebut
akan digabungkan dengan rilis selanjutnya. Dimana rilis software pada
pengembangan iterative dapat berupa rilis software di tahapan awal pengembangan,
bukan rilis produk pada publik.[8]
Pengujian merupakan teknik yang digunakan untuk memvalidasi proses,
harus didistribusikan dan dilakukan pada setiap tahap dari siklus pengembangan
perangkat lunak.
Sistem pengembangan dan desain uji harus dilakukan secara bersamaan. uji desain
harus disertakan disetiap tahapan siklus hidup, dan pengukuran harus terjadi pada
setiap akhir fase.
Pengembangan proyek dimulai dengan menspesifikasikan dan mengimplementasikan
arsitektur / prototype dari perangkat lunak yang telah dirancang sebelumnya.
Komponen perangkat lunak diciptakan dari kebutuhan bisnis yang
diidentifikasi, dan kemudian mengidentifikasi persyaratan lebih lanjut. Proses ini
kemudian diulang, sampai menghasilkan rancangan terbaik dari perangkat lunak
untuk setiap siklus dari model.
Pada iterative model pengujian yang dilakukan dengan langkah sebagai
berikut :[9]

Gambar 2 : Dasar Model Iterative Testing

Empat proses dasar dari model iteratif adalah:

a. Tahap requirement, kebutuhan untuk perangkat lunak dikumpulkan dan
dianalisis. Iterasi akhirnya harus menghasilkan spesifikasi yang lengkap.
b. Tahap desain, arsitektur perangkat lunak memenuhi persyaratan yang dirancang,
dalam hal ini dapat berupa desain baru, atau perbaikan dari desain sebelumnya.
c. Tahap implementasi, ketika software ini telah selesai pada phase coding, telah
terintegrasi dan telah diuji.
d. Tahap review, perangkat lunak dievaluasi, requirement di review, perubahan dan
penambahan requirement pada tahap ini dapat dilakukan.
3. Pengujian Software
Berikut ini merupakan gambaran siklus yang digunakan untuk melakukan pengujian
pengembangan software.

Gambar 3 : Detail Siklus Pengujian Pengembangan Software

Spesifikasi output dari setiap proses desain sistem adalah dokumen acuan untuk
perancang sistem dalam melakukan proses desain sistem dari fase berikutnya, dan
untuk penguji melakukan proses uji desain dari fase ini.
Sebagai contoh, ketika penguji bekerja di unit proses uji desain, programer secara
bersamaan melakukan coding modul (unit) program setelah modul spesifikasi
diselesaikan. Ketika sebuah modul telah dikodekan dan uji pekerjaan desain selesai,
penguji dapat melakukan unit testing pada modul.

4. Perbandingan Model
4.1 Iterative Testing
Rencana uji untuk proyek terdiri dari empat lapisan pengujian utama: Coding,
Integrasi, Jaminan Mutu dan Pengujian Penerimaan User. Masing-masing lapisan
dibangun bertahap untuk memastikan banyaknya kemungkinan kesalahan yang telah
ditemukan dan diperbaiki.
Rincian pengujian dengan model iterative testing adalah sebagai berikut:
 Gambar 4 : pengujian dengan model iterative testing

Pada level pengembangan sebaiknya sudah dapat memastikan bahwa

setidaknya 50% dari bug yang ada rancangan perangkat lunak sudah dapat dideteksi
dan dikoreksi sebelum pindah kelevel pengujian berikutnya. Pada level ini yang
dilakukan sebaiknya menverifikasi struktur internal, metode yang akan digunakan dan
menvalidasi hasil yang diharapkan sudah dilakukan.
Integration Testing : pengujian dilakukan oleh perancang sistem, analis sistem dan
coding reviwer untuk mengkonstruksi struktur program sambil melakukan pengujian
untuk menemukan kesalahan sehubungan dengan interface.
Untuk pengujian iterative sebaiknya menggunakan integrasi incremental karena
program dibangun dan diuji dalam modul modul kecil sehingga kesalahan lebih
mudah diisolasi dan diperbaiki. Dengan demikian apabila ada modul baru yang
ditambahkan, maka akan menjadi bagian dari pengujian iterative. Hal ini disebabkan
karena adanya :
Jalur aliran data baru
I/O baru
Logika kontrol baru
Pada titik ini diperkirakan sekitar 80% dari bug di sistem dikoreksi tetapi 100%
dokumentasi fungsional sudah harus tersedia untuk pengujian.
Quality Assurance Testing (QA) : pada tahap ini pengujian keamanan dilakukan. bug
yang ditemukan dari pengujian ini diberikan kepada tim pengembangan untuk
dimasukkan dalam iterasi mendatang. Pada penyelesaian pengujian QA 90% dari
kerusakan dalam sistem harus diperbaiki.
User Acceptance Testing : Setelah sistem telah memuaskan dan lulus pengujian tiga
tingkat sebelumnya selanjutnya dilakukan untuk Pengujian Penerimaan User. Jenis
pengujian yang biasanya dilakukan adalah melibatkan pengguna sistem dan
pengembang sistem dan stackholder, tujuan dari dilakukannya pengujian ini untuk
menvalidasi fungsionalitas dari sistem, sebelum sistem diproduksi.

4.2 Model Based Testing (MBT)

Untuk melakukan analisis terhadap model based testing pada tulisan ini akan
dilakukan berdasarkan aktifitas model based testing. Adapun aktifitas model based
testing dapat digambarkan sebagai berikut :
 Spesifikasi Model
Membuat Pengujian
Kebutuhan Formal
Model Oracle
dan
skenario

Hasil Input yang

diharapkan
SUT dan
Infrastruktur
Pengujian Hasil Output
Pengujian yang
input diharapkan

Run
Pengujian

Output yang
Output Hasil
diharapkan
Pengujian

Membandingkan Hasil
Pengujian Object
dan cakupan
kriteria

Pengujian
- Perbaiki Model
Berhasil dan
-GenerateKembali
Terjadi Kesalahan
-Stop Pengujian
-Perhitungkan
Keandalan

Gambar 5 : Aktifitas Model Based Testing

Permasalahan yang dijadikan kasus untuk pengujian adalah membuat

database yang berbasis web. Misalkan ada untuk sebuah form product seperti
dibawah ini
 Gambar 6 : Form Halaman Product

Maka dari form diatas selanjutnya pengembang sistem dapat membuat model
berikut :

Gambar 7 : sebagian e-commerce model

Dengan adanya model yang telah dibangun, maka batasan sistem yang
dibangun juga harus diperjelas, dan yang pasti umumnya fasilitas CRUD
merupakan bagian yang harus tersedia untuk tiap tiap entitas.
Untuk membangun sebuah form dengan fasilitas CRUD tentu harus ada validasi
pada form tersebut.
Validasi untuk form dalam pengembangan model merupakan bagian yang
penting, karena ini adalah dasar untuk menghasilkan coding yang dibuat.
Sebagai gambaran misalnya ketika form di submit apakah sudah dibisa dipastikan
input yang diberikan oleh user sudah benar? Maka dari itu perlunya dilakukan
validasi form.
Validasi form terdiri dari 3 kategori, yaitu :[11]
a. Single elemen
b. Multiple elemen
c. Entity association

Single elemen untuk validasi yang terjadi pada form hanya pada elemen saja.
Misalnya sebuah textfield tidak boleh kosong atau nilai yang dimasukkan harus
bersifat integer dan harus lebih besar dari nol. Model kategori seperti ini harus
telah dicapai dan disepakati bersama.
Multiple elements
Untuk melakukan validasi yang dapat mengecek bahwa semua atribut telah terisi
dengan baik dan benar, misalnya setelah user melakukan input data, maka user
harus memberikan centang pada checkbox sebagai persetujuan bahwa data yang
diisikan sudah benar.
Entity association mengacu pada hubungan kelas yang ada dalam domain
tersebut. Misalnya hubungan satu-ke-banyak.

A. Tools Eksekusi Pengujian

Ada beberapa tools yang dapat digunakan untuk melakukan melakukan
pengujian aplikasi web , yang dapat kita gunakan diantaranya :
Junit
JwebUnit
DbUnit
Jetty

B. Pengujian Kasus
Setiap pengujian kasus didefinisikan secara terpisah atau perbagian oleh file
XML, dimana XML berisi informasi yang dibutuhkan untuk melakukan input data
yang dibutuhkan. Proses pengujian dilakukan dengan menggunakan oracle
sebagai tools pengujian untuk mendapatkan output yang diharapkan. Karena ini
adalah aplikasi berbasis web maka inputan akan dilakukan dari browser ditangani
oleh Junit, sedangkan input untuk melakukan pengujian akan dilakukan oleh
JwebUnit. Jadi Oracle berisi database dan HTTP.
File XML akan digunakan untuk menguji menyimpan product baru. Elemen
dataset XML digunakan oleh DBUnit untuk mengatur database. Inputan elemen
XML berubah menjadi perintah JBUnit . Html elemen XML digunakan oleh
JWebUnit untuk memeriksa HTTP respon. Database XML elemen yang
digunakan oleh DBUnit untuk memeriksa keadaan akhir dari database. keadaan
akhir tergantung pada pengujian operasi CRUD.
5. Seleksi Kriteria Pengujian
Seleksi kriteria pengujian membantu pengembang untuk mengontrol pilihan
pengujian.
Mark Utting dan Bruno Legeard mengklasifikasikan kriteria seleksi menjadi enam
bagian :[12]
Struktur model cakupan kriteria
Cakupan kriteria data
Kesalahan kriteria model
Kriteria berbasis kebutuhan
Pengujian spesifikasi kasus secara jelas
Metode pengujian dengan statistik
Pada seleksi kriteria pengujian ini akan digunakan struktur model cakupan kriteria
dan kriteria berbasis kebutuhan, cakupan kriteria data.
Struktur model cakupan kriteria, kebutuhan awal yang harus dipenuhi dalam
membangun sistem menggunakan model based testing adalah tersedianya
 model, untuk aplikasi berbasis web model dibentuk dari permasalahan yang
ada dan berdasarkan data inputan dari user dan pengguna sistem. Model
dapat dibentuk misalnya dengan menggunakan UML.
Kriteria berbasis kebutuhan, dalam aplikasi berbasis web kebutuhan dasar
yang harus tersedia adalah CRUD, pengujian yang dapat dilakukan misalnya
pada button Update, ketika user mengklik button Update maka akan
ditampilkan secara detail data untuk satu entity yang dapat di update.
Cakupan kriteria data, penanganan data harus jelas, mana saja data yang
dianggap perlu, misalnya ketika menginputkan data identitas, semua data
atribut dianggap perlu maka dalam aplikasinya ketika user menginputkan data
pada form data dibuat data tidak boleh ada yang kosong.

6. Pengujian Script Generator

Pengujian script generator menggunakan kriteria berbasis kebutuhan, karena
pengujian yang akan dilakukan akan difocuskan pada proses yang mungkin terjadi
CRUD. Untuk itu akan dibagi kedalam dua bagian, bagian pertama dikenal pengujian
positif dan bagian kedua dikenal pengujian negatif.
Pengujian positif :
C1reate klik menu pada halaman web, klik tambah data, input data pada
form, klik button save
R1ead - klik menu pada halaman web, klik entity, klik button view.
U1pdate - klik menu pada halaman web, tentukan entity, klik update button,
ubah nilai data, klik button save.
D1elete klik menu pada halaman web, tentukan entity, klik button hapus,
klik button Ok.
Lebih lanjut pengujian positif, kejadian proses lain juga mungkin terjadi,
adapun kejadian yang mungkin terjadi ini, dinamakan dengan pengujian
negatif. Pengujian negatif tersebut adalah sebagai berikut :
C2reate - klik menu pada halaman web, klik tambah data, input nilai data
yang tidak benar, klik button save.
C3reate - klik menu pada halaman web, klik tambah data, input data pada
form, klik button cancel.
R2ead - klik menu pada halaman web, tidak memilih entity, klik button view.
U2pdate - klik menu pada halaman web, tidak memilih entity, klik button
update.
U3pdate - klik menu pada halaman web, pilih entity, klik button update,
ubah isi form dengan data yang tidak benar, klik button save.
U4pdate - klik menu pada halaman web, pilih entity, klik button update,
input data yang benar pada form, klik button cancel.
D2elete - klik menu pada halaman web, tidak pilih entity, klik button delete.
D3elete - klik menu pada halaman web, pilih entity, klik button cancel.
Dari pengujian script generator diatas akan dihasilkan sebagai berikut :

Pengujian Positif
Database Html Menampilkan
Membuat data baru,
C1 tidak merubah data yang List page, list entity baru
lain
Entity page, nilai entity
R1 Tidak berubah
ditampilkan
Berubah untuk record List page, update entitiy
U1
tertentu ditampilkan
Delete record tertentu,
List page, entitiy dihapus
D1 tidak merubah data yang
dari list
lain

Pengujian Negatif
Database Html Menampilkan
C2 Tidak berubah entity, pesan error ditampilkan
C3 Tidak berubah List, tidak ada perubahan pada list
R2 Tidak berubah List, tidak ada perubahan pada list
List, tidak ada perubahan pada
U2 Tidak berubah
list, error message ditampilkan
U3 Tidak berubah Entity, error message ditampilkan
U4 Tidak berubah List, tidak ada perubahan pada list
D2 Tidak berubah List, error message ditampilkan
D3 Tidak berubah List, tidak ada perubahan pada list

KESIMPULAN DAN SARAN

1. Kesimpulan
Sebagai penutup dari tulisan ini, akan dihasilkan berupa kesimpulan dari
perbandingan model iterative testing dengan model based testing, adapun
kesimpulannya adalah masing masing model memiliki kelebihan dan kelemahan
untuk tiap tiap model.
Adapun kelebihan iterative testing dibanding model based testing adalah :
a. Lebih kecil kemungkinan untuk terjadi bug dalam sistem yg dirancang, ini
disebabkan proses pengujian dilakukan pada setiap level tahapan dan tidak
hanya melibatkan kelompok kerja, juga melibatkan kelompok yang tidak
terkait langsung dengan proses pengembangan sistem. Sehingga komunikasi
yang baik terjadi antara pengembang sistem dan pengguna sistem.
b. Dengan prototipe kesalahan dan kelalaian dalam pengembangan dapat segera
diketahui.
c. Pengembang sistem dapat bekerja lebih baik dalam menentukan kebutuhan
pengguna sistem karena pengguna sistem berperan aktif dalam
pengembangan sistem sehingga pengembang sistem mengetahui apa yang
diharapkan pengguna sistem.
Sebaliknya iterative testing juga memiliki kelemahan, adapun kelemahannya :
a. Setiap iterasi bergantung prototipe sebelumnya, solusi final umumnya terjadi
apabila ada perbedaan nyata pada prototipe sebelumnya.
b. Proyek mungkin tidak akan pernah selesai karena akan lebih sering fokus
pada perubahan protipe, akibatnya dokumentasi, sistem backup dan recovery,
sistem performance dan security akan lebih terlupakan sehingga berdampak
terhadap pemeliharaan sistem menjadi lebih sulit.
c. Pengembang sistem kadang membuat implementasi yang sembarangan.

Kelebihan model based testing adalah :

a. Ditinjau dari sisi biaya lebih memungkinkan untuk mengurangi beban biaya
dan waktu pengembangan sistem.
b. Menggunakan model reuse, pada komponen yang sudah mewakili kebutuhan
umum.

Kelemahan model based testing adalah:

a. Model ini bersifat iteratif atau berulang-ulang prosesnya.
b. Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini.

2 Saran
Model itetative testing sebaik tidak digunakan untuk pengembangan sistem yang skala
ukuran proyek yang cukup besar karena waktu yang tidak terencana dan biaya lebih
mahal, lebih sulit dalam perawatan sistem.

DAFTAR PUSTAKA
[1] C. Torens, L. Ebrecht, K. Lemmer Starting Model-Based Testing based on Existing
Test Cases used for Model Creation (periodical style), IEEE International Conference
on Computer And Information Technology, 11th 2011.
[2] Myers, G.J.: The Art of Software Testing. Ed. John Wiley & Sons, Inc., Hoboken,
New Jersey. (2004).
[3] Atul Gupta Pankaj Jalote An approach for experimentally evaluating effectiveness and
efficiency of coverage criteria for software testing Published online: 8 January 2008 Int J
Softw PP.145160.
[4] B.Y. Tsai*, S. Stobart, N. Parrington and B.Thompson Iterative Design and
Testing within the Software Development Life Cycle School of Computing and
Information Systems, University of Sunderland, , (1997) pp.295309, Software
Quality Journal 6.
[5] Bhaswati Sadhukhan Model Based Testing Practices (periodical style-Accepted for
Publication), Idea, Approach & Solution, Global Business Services (GBS),
IBM(I) Pvt. Ltd, Kolkata, India.
[6] I. Schieferdecker, C. E. Vector Model-Based Testing IEEE Software Published
by the IEEE Computer Society pp.14-18, 2012.
[7] E. Zimmerman, Play as Research: The Iterative Design Process Final Draft: July 8,
2003.
[8] http://www.snyders.us/qa-iterative.htm
[9] B. Campbell,Dr. G. Ray Managing Iterative Testing in an Agile DevelopmentProject
Version 1.3 April 9, 2002.
[10] A. C. D. Neto, R. Subramanyan, M. Vieira and G. H. Travassos Characterization
of Model-based Software - Testing Approaches , Seimens Corporate Research,
August-2007.
[11] E. Escott, P. Strooper, P. King, and I. J. Hayes, Model-DrivenWeb Form
Validation with UML and OCL, in Proceedings of the 7th Model-Driven Web
Engineering Workshop, 2011.
[12] M. Utting, B. Legeard Practical Model-Based Testing: A Tools Approach [Kindle
Edition], 1 edition, November 27, 2006.