Dokumen ini membahas pentingnya pengujian perangkat lunak dalam pengembangan sistem untuk meminimalkan kesalahan dan meningkatkan kepuasan pengguna. Materi mencakup proses pengujian, definisi acceptance criteria, user story, serta teknik pengujian seperti unit testing, load testing, dan security testing. Penekanan diberikan pada pemahaman kebutuhan pengguna dan proses bisnis sebelum melakukan pengujian untuk memastikan hasil yang efektif.

1. Software Testing
Management
Fahri Firdausillah, M.CS

2. Profil
Fahri Firdausillah, S.Kom, M.Cs
( Python, Java, PHP )
[ Android, Django, Odoo ]
Jenjang Pendidikan:
● Madrasah Qudsiyyah Kudus
● Teknik Informatika UDINUS
● Master of Database Technology
UTeM
Jabatan saat ini:
● Dosen TI (S1) UDINUS
● Ka. Pengelola Data & Informasi
Ekstra kegiatan:
● Pembina DOSCOM (Dinus Open
Source Community)
● SCRUM Master tim
pengembang SMK-Polri

3. Konten Materi
1. Kenapa harus pengujian?
2. Apa yang harus diuji?
a. Proses Bisnis & User Story
b. Acceptance Criteria & Test Case
3. Talk (list) is cheap
a. Application Testing
b. Unit Testing
4. Pengujian Lain
a. Server load testing
b. Security Testing
c. Finally, User Acceptance Testing

4. “Testers don’t like to break things; they like
to dispel the illusion that things work.”—
Kaner, Bach, Pettichord

5. Pengujian Perangkat Lunak itu Penting.
● 80% error dan crash yang terjadi di Windows dan Office
disebabkan oleh 20% dari keseluruhan bug yang terdeteksi.
● “A system is never finished being developed until it ceases to
be used.” — Jerry Weinberg
● Debugging itu 2 kali lebih susah dilakukan dibandingkan
menulis kode pertama kali.
● Tanpa testing yang benar hanya ada 2 kemungkinan:
○ User akan meninggalkan aplikasi kita
○ atau User akan menghantui kita dengan laporan error

6. (N)Ever doing Testing?
The good news is,
● Kita semua pastinya sudah melakukan testing pada semua program
yang pernah kita buat.
● Did you check the features and experiment using them? That’s
known as exploratory testing and is a form of manual testing.
But the bad news is,
● “No amount of testing can prove a software right, a single test can
prove a software wrong.”— Amir Ghahrai

7. “We only see what we know.”—
Goethe

8. Yang harus Diingat
● Kita tidak bisa menguji apa yang tidak kita ketahui .
● Sebelum pengujian kita harus memahami proses bisnis
dan kebutuhan pengguna terlebih dahulu.
● In some degree, kita juga perlu punya akses ke koding
dan basis data aplikasi.
● (salah satu) cara paling mudah memetakan kebutuhan
pengguna dalam pengujian adalah User Story.

9. User Story
● Deskripsi singkat dan sederhana
tentang fitur yang diceritakan
dari perspektif pengguna yang
meminta fitur tersebut.
● Dari user story, developer bisa
membuat checklist kebutuhan
teknis untuk menyelesaikan user
story tersebut.
● User story menjaga agar
kebutuhan perangkat lunak
tidak bias dengan keinginan
developer.

10. Pengguna tidak tahu apa yang diinginkan
● Don’t listen what they say, pay attention to what they do.
● Jika kita bertanya seperti apa software yang ingin dibuat,
hanya ada 2 kemungkinan jawaban:
○ No Spec: tidak tahu apa yang sebenarnya diinginkan
○ Over spec: terlalu banyak permintaan bahkan yang tidak penting

11. Petakan proses bisnis pada User Story

12. Acceptance Criteria
● Acceptance Criteria adalah definisi teknis tentang apa saja yang
harus dipenuhi pada suatu User Story.
● Misalkan untuk user story
“Sebagai peserta seminar, saya ingin bisa registrasi online,
sehingga saya bisa mendaftar seminar dengan cepat”
contoh acceptance criteria-nya adalah:
● Pengguna tidak dapat submit form sebelum mengisi field penting.
● Pengguna dapat mentransfer pembayaran melalui virtual account
● Form terjaga dari SPAM agar tidak ada bot yang memenuhi pendaftaran
● Setelah mendaftar pengguna mendapatkan email konfirmasi

13. Test Case
● Langkah terakhir adalah mendefinisikan Test Case sebagai panduan.
● Yang perlu diingat, Test Case bersifat organik. Artinya jika suatu saat
terdapat bukti test case yang dibuat tidak relevan, maka harus diubah.
● Contoh dokumen test case adalah sebagai berikut:

14. “Talk is Cheap, Show me
the Code” — Linus Torvald

15. What, Testing kok koding?
● Ship fast, fail fast
● Testing yang baik berulang sepanjang pengembangan software ,
bukan cuman sekedar di akhir proses.
● Penambahan / perubahan fitur harus dipastikan tidak membuat
modul yang lain jadi Error.
● Manusia memiliki kelebihan di aktivitas kreatif, komputer memiliki
kelebihan di aktivitas berulang.
● Kita yang mendesain puluhan / ratusan test case , komputer yang
menjalankannya berulang-kali.

16. (Web) Application Testing dengan Selenium
● Selenium dapat membuka browser secara otomatis serta
melakukan click & input pada beberapa elemen tampilan sesuai
dengan skenario uji.
● Skenario test yang akan kita lakukan di sini adalah:
1
Buka
urladm
in
pada
brow
ser
2
Inputkan
usernam
e
&
passw
d
3
Click
login
dan
m
asuk
adm
in
4
M
asuk
ke
halam
an
Transaksi
5
Tam
bahkan
transaksibaru
6
Pastikan
transaksitam
bah

17. Uji Tiap Bagian dengan Unit Testing
● Integration Test relatif lebih memakan waktu karena harus
melibatkan beberapa komponen sekaligus.
● Selain itu, pengujian bersifat superfisial, dan cenderung susah
untuk menyentuh hal teknis sehingga susah untuk di-debug.
● Sebagai pelengkap perlu dilakukan Unit Test untuk menguji kode
sumber dengan lebih komprehensif.
● Sebagai contoh, di sini kita akan menguji dua unit secara khusus
yaitu model transaksi dan view / tampilan transaksi:

18. Testcase untuk UnitTest Model
Description Procedure Expected Output
Uji input data melalui model secara langsung
Uji minimal input create object Transaction dengan parameter
[user, jumlah, judul]
Object transaction sesuai
parameter serta:
● default status: valid
● default jenis:
pengeluaran
Uji input semua field create object Transaction dengan semua field
sebagai parameter
Object transaction sesuai
dengan inputan parameter
Uji perhitungan saldo pemasukan dikurangi pengeluaran
Uji hitung saldo create 3 object Transaction dengan 1
pemasukan dan 2 pengeluaran, kemudian
gunakan TransactionRepo.get_saldo() untuk
menghitung saldo transaksi user tertentu
Nilai saldo adalah
pemasukan dikurangi
pengeluaran

19. Testcase untuk Unit Test View
Description Procedure Expected Output
Uji tampilan dasbor tanpa login tidak menampilkan transaksi apapun
Uji tampilan tanpa
login
Buka URL default (localhost/) tanpa
melakukan login terlebih dahulu
● Halaman mengandung teks “tidak
ada transaksi”
● Halaman tidak megandung teks
“Tampilkan semua list keuangan”
Uji tampilan dasbor dengan login hanya menampilkan transaksi user tersebut
Uji tampilan dengan
login
1. Create 1 object User2
2. Create 1 object transaksi baru
dengan User2.
3. Login dengan User1
4. Buka URL default
● Halaman mengandung transaksi
oleh User1
● Halaman tidak mengandung
transaksi oleh User1
Prasyarat:
● Create object User1 terlebih dahulu
● Create 3 object transaction milik User1 terlebih dahulu

20. Developers work with mindset of
"how to make this work?".
A good tester is thinking about
"how to break this?"

21. Ukur Batas Kemampuan Aplikasi
● Kita juga harus memastikan
performa aplikasi sesuai dengan
kebutuhan jumlah calon pengguna.
● Pengujian performa, juga digunakan
untuk mendapatkan spesifikasi
hardware yang tepat.
● Atau memastikan optimasi
konfigurasi / algoritma yang
digunakan sesuai yang diinginkan.
● Tool yang sering digunakan adalah
Apache JMeter atau Python Locust .

22. Serang Sendiri Aplikasimu (PenTest)
● Keamanan juga merupakan hal yang sangat penting, karena
seringkali motif serangan hacker adalah Vulnerability.
● Beberapa serangan keamanan aplikasi web & mobile yang sering
dilakukan adalah:
○ Brute force login.
○ SQL injection.
○ Man in The middle.
● Sebaiknya penetration testing dilakukan oleh orang yang ahli di
bidang keamanan jaringan dan aplikasi.

23. UAT: Pastikan Bisa Digunakan User
● Kita boleh menggunakan teknologi terbaru, arsitektur paling keren,
tampilan termodis, bahkan test coverage 100%.
● Tapi jika pengguna akhir tidak dapat menggunakan aplikasi kita,
semua itu jadi sia-sia.
● Setelah semua pengujian teknis yang kita lakukan, kita tetap
memerlukan Beta Tester.
● Bahkan aspek terkecil, berpotensi menjadi masalah jika tidak sesuai
dengan kebiasaan pengguna.
● Contoh, pengguna yang terbiasa klik tombol untuk Save, akan
bingung ketika menggunakan Auto Save.

24. “Don’t worry if it doesn’t work right. If
everything did, you’d be out of a job.”
(Mosher’s Law of Software Engineering)

25. Questions & Answers