LECTURE NOTES

ISYS6507
Testing and System Implementation
Week ke - 1

Testing as a part of Software Engineering

[process model]

ISYS6507 – Testing and System Implementation

 LEARNING OUTCOMES

1. LO1: Explain the basis of Foundation System Testing

OUTLINE MATERI :

1. Foundation of a Test Project

2. Waterfall

3. Prototyping

4. Scrum

ISYS6507 – Testing and System Implementation

 ISI MATERI

A. Introduction

Testing aplikasi atau software testing, merupakan bagian dari software

engineering selama proses pembangunan maupun pengembangan aplikasi. Hal ini
dilakukan sebagai upaya untuk koreksi maupun adaptasi aplikasi dalam melihat
evolusi teknologi, pekerjaan maupun perkembangan dunia bisnis.
Ada banyak proses model didalam software engineering yang ada tetapi
pada materi ini hanya 3 saja yang akan dibahas. Karena 3 proses model tersebut
sudah mewakili perkembangan proses model atau software engineering yaitu
waterfall yang mewakili classical software engineering, prototyping yang
mewakili evolution software engineering dan scrum yang mewakili agile software
engineering.
Setiap pembangunan atau pengembangan aplikasi pasti memiliki
kelemahan yaitu terjadinya bug sistem baik itu dari fungsional maupun
pemrosesan datanya. Supaya hal tersebut tidak terjadi diperlukan adanya quality
control product application yaitu dengan menggunakan testing.

B. Waterfall Model

Terlebih dahulu mulai dari proses model yang paling sering digunakan dalam
• Deskripsikan waterfall process?
proposal proyek, skripsi maupun yang sering dibicarakan Masyarakat mengenai
• Bagaimana pelaksaanaan
software engineering yaitu model waterfall. Model ini tidak hanya 1 teori saja tetapi
waterfall process pada
kenyataannya?
banyak teori yang menerangkan model ini seperti Pressman, Alan Denis, Satziner dll.

• Di mana posisi testing pada

waterfall process?

Gambar 1.1 Waterfall (Sumber: Pressman 2014)

Metode waterfall merupakan proses develop aplikasi yang sangat

sequential, jika suatu proses belum selesai maka tidak akan dilanjutkan ke proses
selanjutnya. Perhatikan pada gambar 1.1 yang ditandai lingkaran merah. Testing
berada pada proses construction. Pada proses construction ada dua langkah yang
terjadi didalamnya yaitu code dan testing. Code artinya coding atau membuat
coding aplikasi. Sedangkan test ada dibawah code, hal ini bisa diasumsikan bahwa
pertama testing dilakukan pada setiap langkah code dan yang kedua test tidak bisa
dilakukan jika code belum selesai. Jika anda mempelajari sejarah waterfall model
maka test dilakukan setelah code, secara tidak langsung sama seperti asumsi yang

ISYS6507 – Testing and System Implementation

 kedua bukan? Sehingga dengan testing dapat memberikan kata cukup untuk
pelanggan maupun user.
Pertanyaan yang berikutnya adalah level apakah testing yang digunakan
pada Asumsi jika kita menggunakan waterfall yang sifatnya sequential maka level
testing pada waterfall model yang biasanya dilakukan adalah functional testing.
Untuk materi level testing akan dibahas pada topik berikutnya.

C. Prototyping Model

• Deskripsikan prototyping
process?
• Berapa iterasi yang dilakukan
pada prototyping process?

• Di mana posisi testing pada

prototyping process?

Gambar 1.2 Prototype (Sumber: Pressman, 2014)

Prototyping dimulai dengan komunikasi dengan stakeholder untuk

menentukan tujuan dibangunnya software, mengidentifikasi permasalahan dan
persyaratan, serta menguraikan proses bisnis. Sehingga definisi kebutuhan proses
bisnis lebih lanjut menjadi wajib. Prototyping memiliki desain cepat dalam
pembuatan model bisnis dan representasi design proses bisnis dalam bentuk user
interface atau yang lebih dikenal sebagai front end. Dengan kata lain proses bisnis
pada prototyping menghasilkan front end. Front end inilah yang digunakan sebagai
media komunikasi antara developer dengan stakeholder. Kunci dari prototyping
bahwa stakeholder harus setuju bahwa prototype dibangun untuk mendefinisikan
persayaratan dan permasalahan dari stakeholder. Walaupun akan terjadi iterasi
hingga ditemui kesepakatan.
Proses yang terjadi pada back end diabaikan terlebih dahulu hingga seluruh
proses bisnis selesai didefinisikan ke dalam design user interface. Setelah terjadi
kesepakatan barulah proses developing back end dimulai. Setelah back end selesai
mulailah proses penggabungan dengan front end sehingga menjadi aplikasi yang
sesuai permintaan stakeholder.
Jika dengan asumsi yang sama seperti proses waterfall maka proses testing
berada pada construction setelah melewati pembangunan front end dan back end.
Hal ini berarti level testing pada prototyping berada pada level functional testing.

ISYS6507 – Testing and System Implementation

 D. Scrum
• Apakah backlog bisa diasumsikan
sebagai fitur?
• Berapa proses yang terjadi dalam
sebuah sprint?
Gambar 1.3 Scrum (Sumber: Pressman, 2014)
Scrum menekankan pada pola penggunaan seperangkat proses dari
software engineering yang terbukti efektif untuk proyek development aplikasi yang
ketat, mengubah persyaratan bisnis dan kekritisan bisnis. Seperangkat proses yang
dimaksud adalah requirements, analysis, design, evolution, and delivery menjadi
sebuah perangkat yang dinamakan sebagai sprint. Beberapa istilah di dalam scrum
sebagai berikut:
Backlog — daftar prioritas persyaratan proyek atau fitur yang memberikan nilai
bisnis bagi pelanggan. Item dapat ditambahkan ke backlog kapan saja (ini adalah
bagaimana perubahan diperkenalkan). Manajer produk menilai backlog dan
memperbarui prioritas sesuai kebutuhan.
Sprint — terdiri dari unit kerja yang diperlukan untuk mencapai persyaratan yang
ditentukan dalam backlog yang harus dimasukkan ke dalam kotak waktu14
(biasanya 30 hari). Perubahan (misalnya, item pekerjaan backlog) tidak
diperkenalkan selama sprint. Oleh karena itu, sprint memungkinkan anggota tim
bekerja dalam lingkungan jangka pendek, tetapi stabil.
Rapat scrum — adalah rapat singkat (biasanya 15 menit) yang diadakan setiap
hari oleh tim Scrum. Tiga pertanyaan kunci diminta dan dijawab oleh semua
anggota tim [Noy02]:
o Apa yang Anda lakukan sejak rapat tim terakhir?
o Apa kendala yang Anda hadapi?
o Apa yang Anda rencanakan untuk dicapai pada pertemuan tim berikutnya?
Scrum Master adalah Seorang pemimpin tim, memimpin rapat dan menilai
tanggapan dari setiap orang. Pertemuan Scrum membantu tim untuk mengungkap
potensi masalah sedini mungkin. Juga, pertemuan harian ini mengarah pada
ISYS6507 – Testing and System Implementation
 "sosialisasi pengetahuan" [Bee99] dan dengan demikian mempromosikan struktur
tim yang mengatur dirinya sendiri.
Demo — berikan peningkatan perangkat lunak kepada pelanggan sehingga fungsi
yang telah diterapkan dapat ditunjukkan dan dievaluasi oleh pelanggan. Penting
untuk dicatat bahwa demo mungkin tidak berisi semua fungsi yang direncanakan,
tetapi fungsi-fungsi yang dapat dikirim dalam waktu-kotak yang didirikan.
Dengan asumsi yang sama berarti level testing pada scrum berada pada unit
testing, karena setiap bagian dari seluruh project berada pada sprint bukan backlog.
Kemudian setiap sprint disatukan dengan backlog, berarti pada penyatuan backlog
ada testing integrasi. Serta terakhir setelah seluruh sistem menjadi satu kesatuan
barulah dilakukan pada level functional dan untuk presentasi ke klien bisa
menggunakan User Acceptance Test atau cukup hingga level functional saja.

E. Extreme Programming

Extreme Programming, merupakan bagian dari pengmbangan Agile, yang

menggunakan pendekatan berorientasi objek sebagai paradigma pengembangan
yang digunakan dan mencakup seperangkat aturan dan praktik yang
• Jelaskan perihal CRC!
berlangsung dalam konteks empat aktivitas kerangka kerja: perencanaan, desain,
• Jelaskan refactoring coding!
pengkodean, dan pengujian. Gambar 1.4 yang mengilustrasikan proses XP dan
• Jelaskan pair programming!
mencantumkan beberapa gagasan dan tugas utama yang terkait dengan setiap
aktivitas kerangka kerja. Aktivitas utama XP diringkas di bagian berikut.

Gambar 1.4 Extreme Programming (Pressman, 2014)

Planning: Aktivitas perencanaan dimulai dengan mendengarkan dimana aktivitas

pengumpulan persyaratan yang memungkinkan anggota teknis tim XP untuk
memahami konteks bisnis perangkat lunak dan mendapatkan pengertian luas
tentang keluaran yang diperlukan serta fitur dan fungsionalitas utamanya.
Mendengarkan mengarah pada pembuatan serangkaian "cerita" (juga disebut cerita
pengguna) yang menggambarkan keluaran, fitur, dan fungsionalitas yang

ISYS6507 – Testing and System Implementation

diperlukan untuk perangkat lunak yang akan dibangun. Setiap cerita ditulis oleh
pelanggan dan ditempatkan pada kartu indeks. Pelanggan memberikan nilai (yaitu,
prioritas) pada cerita berdasarkan nilai bisnis keseluruhan dari posisi atau fungsi
tersebut. Anggota tim XP kemudian menilai setiap cerita dan mengenakan biaya
(diukur dalam minggu pengembangan). Jika cerita diperkirakan membutuhkan
waktu lebih dari tiga minggu pengembangan, pelanggan akan diminta untuk
membagi cerita menjadi cerita yang lebih kecil dan menetapkan kembali nilai dan
biaya. Penting untuk dicatat bahwa cerita baru dapat ditulis kapan saja. Pelanggan
dan pengembang bekerja sama untuk memutuskan bagaimana cerita akan
dikelompokkan di rilis berikutnya (langkah perangkat lunak berikutnya) untuk
dikembangkan oleh tim XP. Setelah komitmen dasar (kesepakatan tentang cerita
yang akan disertakan, tanggal penyelesaian, dan masalah proyek lainnya) dibuat
untuk rilis, tim XP akan memesan cerita yang akan dikembangkan dengan salah
satu dari tiga cara: (1) semua cerita akan dibuat dilaksanakan segera (dalam
beberapa minggu), (2) cerita bernilai tertinggi dipindahkan ke atas dalam
perencanaan dan diimplementasikan terlebih dahulu, atau (3) cerita yang paling
berisiko dipindahkan ke atas dalam perencanaan dan diimplementasikan terlebih
dahulu.
Design: Rancangan. Desain XP secara ketat mengikuti prinsip Keep It Simple
(tetap sederhana). Desain sederhana selalu lebih disukai daripada rendering yang
lebih kompleks. Selain itu, desainnya memberikan panduan implementasi untuk
sebuah cerita seperti yang tertulis - tidak kurang, tidak lebih. Merancang
fungsionalitas tambahan (karena pengembang menganggap ini akan diperlukan
nanti) tidak disarankan. XP mendorong penggunaan peta CRC sebagai mekanisme
yang efektif untuk memikirkan perangkat lunak dalam konteks berorientasi objek.
Peta CRC (Class Responsibility Collaborator) mengidentifikasi dan mengatur
kelas berorientasi objek yang relevan dengan peningkatan perangkat lunak saat ini.
Tim XP akan melakukan latihan desain mengikuti proses yang serupa dengan yang
dijelaskan. Jika masalah desain yang sulit muncul sebagai bagian dari desain
cerita, XP merekomendasikan untuk segera membuat prototipe operasional dari
bagian desain tersebut. Disebut solusi lonjakan, prototipe desain
diimplementasikan dan dievaluasi. Tujuannya adalah untuk mengurangi risiko saat
implementasi sebenarnya dimulai dan untuk memvalidasi perkiraan asli untuk
cerita dengan masalah desain. Refactoring bertujuan untuk mengontrol perubahan
ini dengan mengusulkan perubahan desain kecil yang dapat "meningkatkan desain
secara radikal". Namun, perlu dicatat bahwa upaya yang diperlukan untuk
refactoring dapat meningkat secara dramatis seiring dengan bertambahnya ukuran
aplikasi.
Coding: Setelah cerita dikembangkan dan desain awal diselesaikan, tim tidak akan
beralih ke kode, tetapi mengembangkan serangkaian tes unit yang akan
mempraktikkan setiap cerita untuk dimasukkan dalam rilis saat ini (peningkatan
perangkat lunak). Setelah pengujian unit dibuat, pengembang dapat lebih fokus

ISYS6507 – Testing and System Implementation

pada apa yang perlu diterapkan untuk lulus pengujian. Setelah kode selesai, kode
dapat segera diuji, memberikan umpan balik langsung kepada pengembang.
Konsep kunci dalam aktivitas Coding (dan salah satu aspek yang paling banyak
dibicarakan tentang XP) adalah pemrograman berpasangan. XP menganjurkan
agar dua orang bekerja sama pada satu workstation komputer untuk membuat kode
untuk sebuah cerita. Ini menyediakan mekanisme untuk pemecahan masalah waktu
nyata dan jaminan kualitas waktu nyata (kode ditinjau segera setelah dibuat). Itu
juga membuat pengembang tetap fokus pada masalah yang ada. Dalam praktiknya,
setiap orang mengambil peran yang sedikit berbeda. Misalnya, satu orang mungkin
berpikir tentang detail pengkodean dari bagian tertentu dari desain, sementara yang
lain mungkin memastikan bahwa standar pengkodean (bagian XP yang diperlukan)
diikuti atau bahwa kode untuk cerita lulus tes unit yang sebelumnya. Lari.
dikembangkan untuk memvalidasi kode terhadap cerita.
Testing: Pengujian unit yang dibuat harus diimplementasikan menggunakan
kerangka kerja yang memungkinkannya diotomatiskan (oleh karena itu, pengujian
dapat dilakukan dengan mudah dan berulang kali). Ini mendorong strategi
pengujian regresi dimana setiap kali kode diubah (yang sering terjadi, mengingat
filosofi pemfaktoran ulang XP). Karena pengujian unit individual diatur dalam
"rangkaian pengujian universal", pengujian integrasi dan validasi sistem dapat
dilakukan setiap hari. Ini memberi tim XP indikasi kemajuan yang berkelanjutan
dan juga dapat memberikan sinyal peringatan dini jika terjadi kesalahan. Tes yang
dilaukan pada XP adalah User Acceptance Test, disebut juga sebagai tes
pelanggan, ditentukan oleh pelanggan dan berfokus pada fitur dan fungsionalitas
sistem umum yang terlihat dan dapat direvisi oleh pelanggan. Tes penerimaan
berasal dari cerita pengguna yang diimplementasikan sebagai bagian dari rilis
perangkat lunak.

ISYS6507 – Testing and System Implementation

 KESIMPULAN

1. Posisi testing pada waterfall model berada pada contruction dan menggunakan
functional testing.

2. Posisi testing pada prototyping model berada pada contruction of prototype dan
menggunakan functional testing.

3. Posisi testing pada scrum berada pada pada setiap sprint dan product back log,
sehingga menggunakan seluruh level testing.

4. Posisi testing pada Xtreme Programming berada pada pada setiap CRC dan,
sehingga menggunakan unit testing dan sebelum release menggunakan User
Acceptance Test.

ISYS6507 – Testing and System Implementation

 DAFTAR PUSTAKA

1. Black, Rex. (2009). Managing the testing process: practical tools and techniques
for managing hardware and software testing. 03. Wiley. Indianapolis. ISBN:
9780470404157
2. Burnstein, Ilene. (2003). Practical Software Testing. Springer. New York. ISBN:
0-387-95131-8
3. Pressman, Roger. S. (2014). Software Engineering: A Practitioner's Approach. 8th
Edition. McGraw-Hill

ISYS6507 – Testing and System Implementation