Topik 5

Testing dan Usability

Andi M. Yusuf, S.S., S.Pd., M.Kom.

 Outline

• Pengantar
• Dasar-dasar Pengujian (Testing) di Web
• Metode dan teknik untuk menguji Aplikasi
Web
• Pengujian aplikasi Web Otomatis
• Dasar-dasar Kegunaan (Usability) di Web
• Rangkuman

2
PENGantar

3
 Testing dan Usability
• Testing (Pengujian)
–Memeriksa kesesuaian aplikasi versus persyaratan desainnya
–Berorientasi untuk aspek fungsional
• Usability (Kebergunaan)
–Merancang dan memverifikasi kesesuaian aplikasi versus
kemampuan pengguna dan kemampuan interaksi
–Berorientasi untuk aspek non-fungsional
• Pengujian dan Usability adalah aspek ortogonal
–Pada beberapa kasus keduanya sedikit tumpang tindih!

4
 Pentingnya Pengujian
• Secara tradisional, pengujian telah berfokus pada
persyaratan fungsional - tidak cukup untuk
aplikasi Web.

• Di Web, pengujian adalah ukuran penting (kritis)

jaminan mutu (kualitas).
–Memenuhi harapan pengguna
–Menemukan kesalahan dan kekurangan
–Banyak pengguna, banyak platform
–Perilaku perangkat lunak pihak ketiga
5
 Pentingnya Pengujian
• "Misi kritis" aplikasi Web
• Desain yang buruk mengarah ke waktu yang
hilang, produktivitas
• Website Anda berbicara untuk organisasi Anda
–Pelanggan memiliki pilihan
–Mudah datang, mudah pergi
• Beragam konteks
–Proliferasi perangkat web-enabled
–Peningkatan adopsi oleh kelompok-kelompok
kebutuhan khusus – misal: orang tua
6
Apa saja keunikan pengujian aplikasi Web?

DASAR-DASAR PENGUJIAN DI WEB

7
 Terminologi
• Testing: Sebuah kegiatan yang dilakukan untuk
mengevaluasi kualitas produk untuk
memperbaikinya dengan mengidentifikasi cacat
dan masalah.
• Error: hasil aktual yang menyimpang dari yang
diharapkan.
Hasil yang kita harapkan (secara teoritis) berasal dari
definisi persyaratan yang kita buat.
Paling sering, tujuan / konsen/ harapan para
stakeholder menjadi dasar pengujian.
• Test case: sehimpunan input, kondisi
pelaksanaan, dan hasil yang diharapkan untuk
pengujian suatu objek.
8
 Tujuan Pengujian
• Tujuan utama: menemukan kesalahan, TIDAK
menunjukkan bahwa tidak ada.
• Cakupan tes lengkap adalah mustahil, jadi
pengujian berfokus pada mengurangi risiko
terbesar
–Di mana potensi kerugian terbesar?
–Apa saja sumber risiko ini?
• Memulai pengujian sedini mungkin - bahkan
dengan sumber daya terbatas dan waktu.

9
 Tingkat Pengujian
• Unit tests:
–Pengujian unit "atomik" - kelas, halaman web, dll – secara
independen. (Pengembang)
• Integration tests:
–Uji interaksi unit (Tester & Pengembang)
• System tests:
–Pengujian keseluruhan sistem, yang terintegrasi (tim Dedicated)
• Acceptance tests:
–“Real-world” tests – pengujian dalam kondisi yang sedekat
mungkin dengan lingkungan "hidup" yang mungkin (Klien)
• Beta tests:
–Informal, tes produk-lebar yang dilakukan oleh pengguna
“friendly".
10
 Peran Tester
• Tester (Penguji) ideal memiliki sikap "destruktif".
• Sangat sulit bagi pengembang untuk
“menghancurkan" pekerjaan mereka sendiri.
• Namun, proyek-proyek Web fokus berat pada
test unit, membuatnya lebih rentan terhadap
kesalahan.
• Beberapa panduan:
–Ada orang lain dalam tim Web melakukan tes.
–Tester terbaik adalah orang yang mendapatkan bug
yang paling banyak (untuk diperbaiki).
11
 Spesifikasi Rekayasa Web
• Error dalam content Web:
–Ditemukan terutama melalui proofreading - sangat
mahal
–Tes alternatif : Spell-check, meta-information
• Struktur hypertext:
–Apakah setiap halaman dapat diakses melalui link?
–Apakah setiap link halaman ke struktur hypertext
bekerja?
–Apakah ada link yang rusak?
–Apa yang terjadi ketika pengguna men-klik “Back" pada
browsernya?
12
 Spesifikasi Rekayasa Web
• Subjektif persyaratan untuk presentasi
–Kenyamanan di mata yang melihat (estetika).
–Tester harus membedakan perilaku yang diterima
dari yang salah.
–Pengujian Presentasi di Web meminjam dari
penerbitan cetak (tampilan).
• Multi-platform delivery
–Dapatkah diuji pada setiap perangkat?
–Dapatkah dibuat kasus uji pada setiap perangkat?
–Simulator sering tersedia, namun mungkin buggy.
13
 Spesifikasi Rekayasa Web
• Ketersediaan Global
–Pengujian konten dinamis dalam beberapa bahasa
Pengujian untuk kesulitan tata letak karena berbagai
teks panjang.
• Usia Muda & Multi-disiplinnya Tim Web
–Keengganan untuk menerima metode pengujian.
–Kurangnya pengetahuan pengujian.
–Bangunan konsensus yang diperlukan.
–Mungkin melakukan pengujian terlalu banyak,
sama buruknya dengan terlalu sedikit.
14
 Spesifikasi Rekayasa Web
• Banyak komponen sistem
–Third-party; platform berbeda.
–Pengujian integrasi dan konfigurasi komponen juga
diperlukan.
• Ketidakmatangan metode uji
–Paket uji yang cocok untuk teknologi baru sering tidak
ada, atau ada tetapi dirancang dengan jelek.
• Perubahan terus menerus
–Perubahan persyaratan, perangkat keras, perangkat
lunak.
–Tes ulang setelah setiap upgrade besar.
15
Bagaimana kita dapat menguji aplikasi Web?

METODE DAN TEKNIK UNTUK

MENGUJI APLIKASI WEB

16
 Pengujian Link
• Menemukan link yang rusak
–Dapat diotomatiskan dengan spider
–Tidak membantu untuk halaman tanpa link masuk
(incoming link).
• Mendapatkan halaman terpencil (orphan)
–Orphan adalah halaman tanpa link kembali ke struktur
navigasi.
–Pengguna mendapatkan frustrasi dan meninggalkan.
• Menangkap statistik
–Dalam dan lebarnya navigasi.
–Jarak antara dua dua halaman terkait.
–Jumlah link.
–Waktu muat (load time).
17
 Pengujian Browser
• Browser bervariasi, berdasarkan :
–Pabrikan
–Versi
–Sistem Operasi
–Perangkat
–Konfigurasi (stylesheets, JavaScript on/off)
–Standard kepatuhan W3C
• Pertanyaan penting untuk diajukan:
–Bagaimana status dikelola?
–Dapat halaman web (dinamis) dibookmark?
–Dapatkah pengguna membuka banyak jendela (window)?
–Apa yang terjadi saat cookie dan/atau scripting dimatikan?
18
 Pengujian Beban
• Apakah sistem memenuhi waktu respon dan
throughput yang dibutuhkan?
• Profil beban – jenis akses, kunjungan per hari,
jenis transaksi, transaksi per sesi, dll yang
diharapkan
• Harus menentukan rentang nilai untuk waktu
respon dan throughput.
• Mengevaluasi hasil untuk mencari kemacetan
(bottleneck).
19
 Pengujian Tekanan

• Bagaimana sistem berperilaku dalam kondisi tak-

normal / ekstrim?
• Pengujian harus memberitahu Anda …
–Jika sistem memenuhi waktu tanggapan dan
throughputs target
–Jika sistem merespon dengan pesan kesalahan yang
sesuai. (Yaitu degradasi tertata)
–Jika sistem crash (seharusnya TIDAK!)
–Seberapa cepat sistem sembuh pada operasi normal.

20
 Pengujian Berkelanjutan
• Mensimulasikan penggunaan selama jangka
waktu yang panjang
• Pengujian untuk kesalahan yang "pop up" karena
sumber daya tersebut tidak dirilis oleh suatu
operasi.
–Koneksi database yang tak dilepas
–Kebocoran memory lainnya
• Biasanya, menjalankan operasi beberapa kali
tidak menghasilkan error, maka perlu untuk
pengujian terus-menerus.
21
 Pengujian Keamanan
• Skema uji sistematis sangat dianjurkan.
• Pengujian untuk pembetulan kesalahn tidaklah cukup
–Apakah data rahasia terpapar secara tidak sengaja?
–Apa yang terjadi jika input data tidak lengkap?
–Apa yang terjadi jika kita menyuntikkan kode berbahaya?
–Halaman terenkripsi SSL
• Apakah kerja sudah bersertifikasi SSL?
• Apa yang terjadi jika kita mencoba mengakses halaman/situs yang
terproteksi dengancara yang tak-aman (misal http://)?

22
 Pengembangan Test-Driven
• Terinspirasi oleh pendekatan uji-pertama kali yang
digunakan di XP (eXtreme Programming); dapat
digunakan dalam semua jenis proyek.
• Pengujian harus ditulis sebelum pelaksanaan.
–Setiap unit memiliki tes.
–Saat tes gagal, pengembang hanya perlu mengubah kode
agar pengujian berhasil dijalankan.

• Pengembang dapat berkonsentrasi pada langkah-

langkah kecil, sementara masih membuat kode bersih
yang bekerja.
• Lebih banyak tekanan menyebabkan ebih banyak
pengujian.
23
Bagaimana kita dapat mengurangi biaya pengujian aplikasi web?

PENGUJIAN APLIKASI WEB

OTOMATIS

24
 Mengenal JUnit
• Framework pengujian Java Open source yang digunakan
untuk menuliskan dan menjalankna uji terotomasi yang
dapat berulang (repeatable automated test)
• Suatu struktur untuk penulisan test drivers
• Fitur JUnit termasuk:
–Pernyataan untuk pengujian hasil yang diharapkan
–Fitu uji fitur untuk berbagi data pengujian bersama
–Paket uji untuk memudahkan mengorganisir dan menjalankan tes
–Grafis dan pengeksekusi (runner) uji tekstual
• JUnit digunakan secara luas di industri
• JUnit dapat digunakan sebagai program Java stand alone
(command line) atau di dalam IDE seperti Eclipse

25
 Mengenal Cactus

• Dibangun di atas framework Junit

• Dimaksudkan untuk menguji JSP, Servlets,
EJBs, Filters, dan custom tags
• Arsitektur kompleks yang mempunyai JVM
client memanggil JVM server aplikasi J2EE
• Kelas-kelas kasus uji (test case) harus berada
pada client dan server

26
 Ekstensi JUnit lain
• HttpUnit
–Memparse hasil HTML ke dalam DOM
–Navigasi link yang mudah dan membetuk populasi
–Berguna untuk uji penerimaan (acceptance) terotomasi
• Canoo WebTest
–HttpUnit di dalam Ant
• JUnitPerf
–Membungkus suatu uji JUnit
–Mengukur kinerja yang diinginkan dan toleren
terhadap scalability
27
 Keuntungan Pengujian Otomatis

• Beberapa uji mustahil dikejakan secara

manual.
–Test beban dan tekanan.
–Test link untuk situs web besar.
• Lebih banyak uji yang dapat dijalankan dalam
waktu lebih sedikit.
• Ketika memperbarui aplikasi, dapat
mendeteksi kesalahan yang disebabkan oleh
efek samping terhadap fungsi tidak berubah.
28
 Kerugian Pengujian Otomatis

• Harapan terhadap pengujian otomatis sering

terlalu tinggi.
–Otomasi tidak meningkatkan efektifitas.
–Jika uji dirancang secara jelek,
mengotomatisasikannya tidak secara ajaib
memperbaikinya.
• Otomatis itu mahal
–Infrastruktur uji eksekusi harus dirawat.
–Biaya lisensi dan biaya pelatihan
29
Bagaimana merancang aplikasi Web yang dapat digunakan?

DASAR-DASAR USABILITY DI WEB

30
 Definisi Usability
• Definisi standard ISO/IEC (1998):
–“Sejauh mana suatu produk dapat digunakan oleh
pengguna tertentu dalam konteks penggunaan yang
ditetapkan untuk mencapai target yang ditetapkan
secara efektif, efisien, dan memuaskan.”
• Usability engineering adalah proses terus
menerus, tapi kritis
–Menentukan model Pengguna dan Tugas
–Secara iteratif menguji dan mengevaluasi kembali
–Metode berbasis Pengguna vs Pakar
31
 Usability dalam Aplikasi Web
• Spesifikasi usability software tradisional tidak
dapat langsung dibawa ke ranah Web:
–Orang menggunakan aplikasi Anda segera.
–Tidak ada manual atau pelatih (trainer).
–Tanpa wiraniaga.
• Bagaimana mengelompokkan pengguna?
–Pertama kali atau berikutnya?
–Ahli atau pemula?
–Broadband atau dial-up?
–Desktop atau mobile?
32
 Masalah Utama
• Informasi kontak - alamat atau nomor telepon hilang
atau tak berlaku
• Fungsi Search tidak terlihat atau tidak jelas fungsinya
• Tidak ada cara mudah untuk kembali ke titik kritis
• Halaman yang harus memuat cepat namun tidak
(misalnya halaman utama atau halaman link kunci)
• "Apa yang baru" ternyata sudah usang (lama)
• Tombol “Back” memerlukan suatu data repost

33
 Usability Engineering

• Terdiri dari 4 fase yang pada dasarnya paralel

dengan proses Web Engineering
Usability Engineering

Analysis Design Implementation Operation

Web Engineering
Analysis Design Coding Testing Maintenance

34
User-Centered vs. Usage-Centered

Fase Titik Fokus

User-Centered Usage-Centered
(Tradisional) (Web)

Requirements Meetings, interviews, Competitive analysis;

focus groups Task analysis &
models
Design & User requirements Models
Implementation Direct user Inspection & remote
participation testing
Operation Training, evaluation Log file analysis;
of help-desk logs server stats; user
feedback analysis
35
 Analisis Kebutuhan
• Systems Analysts & Usability Experts sebagai
pelopor:
–Analisis yang kompetitif
–Definisikan tujuan kuantitatif/kualitatif
• Information, Entertainment, Exchange (Siegel)
• Buat jadi konkrit dan dapat diuji (testable)!
–User-centered: Bangun profil pengguna
–Usage-centered
• Analisis tugas
• Ease-of-use atau Ease-of-learning?

36
 Interaksi dan Rancangan

• Awalnya, Interface Designer membangun suatu

model konseptual
–Presentation: Storyboards & Paper mock-ups
–Navigation: Card-sorting
–Berdasarkan pada use cases inti
–Memperlihatkan struktur dasar
• Mendapatkan feedback dari pengguna potensial
• Pakar usability menyediakan input setelah
putaran pertama ini.
37
 Interaksi dan Rancangan
• Designer dan coder kemudian dapat menguraikan
rinciannya
• Pengujian pengguna tambahan:
–Prototypes – menunjukkan beberapa fungsi
–Uji usability – nyata konteks, tugas yang nyata.
• Pengujian remote usability
–Contoh pengguna yang mewakili
–Software client-Logging
–Web-cams jika memungkinkan
–Validitas eksternal yang lebih baik & biaya lebih rendah
(?)
38
 Penulisan Kode & Pasca Deployment

• Ahli Usability mengasumsikan peran dari

manajer Quality Assurance.
–Konsistensi?
–Pedoman & standar yang diamati?
–Melekat ke requirement (saat ini) ?

• Bawa pengguna yang sama kembali untuk

pengujian, jika mungkin.
• Dokumen, dokumen, dokumen!
39
 Panduan Desain Umum
• Pedoman desain merepresentasikan praktek
terbaik
• OK bagi pengguna “umum”
–Kemampuan kognitif normal
–Kemampuan audiovisual normal
• Beberapa pedoman mungkin tidak cocok untuk
pengguna dengan kebutuhan khusus.
–Misal: Elemen navigasi bagi penderita skizofrenia
• Teknik rekayasa usability yang lebih ketat (yang
telah dibahas) harus digunakan
40
 Pengolahan Informasi Manusia
• Kognisi manusia memainkan peran penting
dalam desain antarmuka pengguna.
–Persepsi
• Positioning, grouping, arranging
• Perceiving shapes dan relationships
–Memory
• Keterbatsan dari memory kerja
• Chunking, 7 + 2 (Miller)
–Atensi
• Berfokus pada salah satu aspek
• Pergerakan, skema warna
41
 Pedoman – Waktu Respon
• Meningkatnya waktu respon maka kepuasan
pengguna menurun
–Saat lebih dari 3 detik, pengguna sadar dia sedang
menunggu
–Setelah 10 detik, pengguna menyerah
• Optimalkan, atau minimalkan grafis
• Pertimbangkan memecah halaman besar.
• <img> - gunakan atribut “width” & “height”

• Jangan lupakan pengguna dial-up!

–Ukuran home page sebaiknya < 50Kb
–Memberikan peringatan (MPG – 2.5Mb)
42
 Pedoman – Efisiensi

• Minimalkan jarak antara elemen dapat diklik

(sambil menjaga ukuran efektif)
• Hindari perubahan yang sering antara mouse
dan keyboard
• Tab yang ramah untuk browser berbasis teks
• Minimalkan klik untuk menyelesaikan tugas
(rule of thumb: tidak lebih dari 4 klik)

43
 Pedoman – Warna
• Warna memiliki arti yang berbeda tergantung
pada pengguna yang melihat warna
–Perbedaan budaya
–Arti spesifik domain
–Warna yang hangat dan dingin (cool)
• Pastikan semua informasi yang disampaikan
dengan warna juga tersedia tanpa warna.
• Minimalkan jumlah warna
• Hindari warna ekstrim, warna yang sangat jenuh
• Bagaimana tampilan situs Anda di LCD? CRT?

44
 Pedoman – Layout Teks
• Screen vs. Kertas
• Pertimbangkan ukuran jendela yang berbeda
–Hindari layout lebar yang tetap
–Hindari banyak kolom (biasanya)
• Keterbacaan (Readability)
–Sans-serif untuk screen, serif untuk dicetak
–Hindari pola, latar belakang kontras rendah
–Paragraf pendek
• Izinkan ukuran huruf yang dipilih pengguna
45
 Pedoman – Struktur Halaman

• Pertimbangan tampilan
• Gunakan posisi relatif, sebaiknya tidak absolut.
• Scroll vertikal baik digunakan; scroll horisontal
TIDAK.
• Elemen penting harus SELALU terlihat.
• Membuat halaman ramah cetak atau sediakan
style alternatif & tombol cetak.

46
 Panduan – Navigasi
• Sediakan pengguna suatu model dari situs
web
– Elemen navigasi intuitif
–Peta situs (site map)
–Breadcrumbs (remah roti)
• Menu dropdown
–Pro: Pemanfaatan space yang efisien
–Kontra: Informasi kunci tersembunyi

47
 Panduan – Multicultural
• Lokasi biasanya bukan constraint di Web.
• “Denominator budaya umum terkecil ”:
–Hindari warna yang terlalu ekspresif
–Simbol
–Bahasa
–Representasi informasi (format date/time)

• Sediakan elemen form secara konsisten

48
 Panduan – Konsistensi

• Konsistensi tetap meminimalkan belajar,

pengguna tidak mau harus berpikir!
• Identitas dapat diatur oleh komponen yang
konsisten
–Header: beranda, logo, navigasi, cari, bantuan
–Footer: penulis, modifikasi, hubungi
• Desain yang konsisten dapat menghindari
pengguna “tersesat”, terutama saat melompat
ke berbagai sub-unit organisasi situs.
49
 Aksesibilitas Web Lebih Lanjut
• Jumlah orang cacat yang memanfaatkan Web
akan semakin besar.
• Tim Berners-Lee menegaskan bahwa akses
universal ke Web adalah penting.
• 20% dari populasi dunia memiliki cacat,
setidaknya pada satu inderanya.
• Kunci penting:
–Merancang untuk kebutuhan khusus tidak selalu
memerlukan reinventing aplikasi Anda.
–Melakukan hal itu juga dapat membantu pengguna
"umum"

50
 Web Accessibility Initiative (WAI)
• Web Content Accessibility Guidelines 2.0 (WCAG,
2008) dipublikasikan oleh W3C’s WAI
• 12 Panduan
• 4 Grup
1) Perceivable (dpt dipahami dgn jelas)
2) Operable
3) Understandable
4) Robust (kuat)
• Mendefinisikan Kelompok Kebutuhan Khusus
• Tingkat Kesesuaian (A, AA, AAA)

51
That’s almost all for day…

RINGKASAN

52
 Rangkuman
• Testing dan Usability merupakan masalah orthogonal
–Pengujian mencakup validasi persyaratan fungsional
–Ketergunaan cenderung mencakup validasi persyaratan
"non-fungsional" (tidak sepenuhnya tepat)
• Keduanya adalah bagian dari proses perancangan
aplikasi (Web) yang bagus
• Dapat secara parsial diotomasikan
• Perbedaan kunci:
–Pengujian berurusan terutama dengan pengembang
inhome dan (jarang) dengan pengembang eksternal dan end-
user
–Usability bergantung pada keahlian diluar "dunia teknologi"

53
 Daftar Referensi

• Bacaan Utama
–Kappel, G., Proll, B. Reich, S. & Retschitzegger, W.
(2006). Web Engineering, Wiley & Sons. Bab 7 dan
11.

• Referensi lain
–Kent Beck, eXtreme Programming Explained
–http://www.usability.gov/

54
 Tool Pengujian

• JUnit.org - http://www.junit.org
• Cactus - http://jakarta.apache.org/cactus
• Clover - http://www.thecortex.net/clover
• dbUnit - http://www.dbunit.org
• HttpUnit - http://www.httpunit.org
• Canoo WebTest - http://webtest.canoo.com

55
 Tool Usability

• Pengembangan
–Toolbar pengembang Firefox (
http://chrispederick.com/work/web-developer/)
• Pengujian
–http://www.fujitsu.com/global/accessibility/assistance/wi/
–http://webusability.com/usability_tools.htm
–http://wave.webaim.org/
• Daftar konprehensif dari tool WAI
–http://www.w3.org/WAI/ER/tools/complete
56
Pertanyaan?

57