Pengujian dan Kebergunaan Aplikasi Web

Presentasi berjudul: "Pengujian dan Kebergunaan Aplikasi Web"— Transcript presentasi:

1 Pengujian dan Kebergunaan Aplikasi Web
Web Engineering 2010 Pertemuan ke-06 Pengujian dan Kebergunaan Aplikasi Web (Testing &Usability) Husni Husni.trunojoyo.ac.id Komputasi.wordpress.com

2 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

3 PENGantar

4 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!

5 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

6 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

7 DASAR-DASAR PENGUJIAN DI WEB
Apa saja keunikan pengujian aplikasi Web? DASAR-DASAR PENGUJIAN DI WEB

8 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.

9 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.

10 Tingkat Pengujian Unit tests: Integration tests: System 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".

11 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).

12 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?

13 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.

14 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.

15 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.

16 METODE DAN TEKNIK UNTUK MENGUJI APLIKASI WEB
Bagaimana kita dapat menguji aplikasi Web? METODE DAN TEKNIK UNTUK MENGUJI APLIKASI WEB

17 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).

18 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?

19 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).

20 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.

21 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.

22 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

23 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.

24 PENGUJIAN APLIKASI WEB OTOMATIS
Bagaimana kita dapat mengurangi biaya pengujian aplikasi web? PENGUJIAN APLIKASI WEB OTOMATIS

25 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

26 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

27 Ekstensi JUnit lain HttpUnit Canoo WebTest JUnitPerf
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

28 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.

29 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

30 DASAR-DASAR USABILITY DI WEB
Bagaimana merancang aplikasi Web yang dapat digunakan? DASAR-DASAR USABILITY DI WEB

31 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

32 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?

33 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

34 Usability Engineering
Terdiri dari 4 fase yang pada dasarnya paralel dengan proses Web Engineering Usability Engineering Analysis Design Coding Testing Maintenance Implementation Operation Web Engineering

35 User-Centered vs. Usage-Centered
Fase Titik Fokus User-Centered (Tradisional) Usage-Centered (Web) Requirements Meetings, interviews, focus groups Competitive analysis; Task analysis & models Design & Implementation User requirements Direct user participation Models Inspection & remote testing Operation Training, evaluation of help-desk logs Log file analysis; server stats; user feedback analysis

36 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?

37 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.

38 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 (?)

39 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!

40 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

41 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, (Miller) Atensi Berfokus pada salah satu aspek Pergerakan, skema warna

42 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)

43 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)

44 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?

45 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

46 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.

47 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

48 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

49 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.

50 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"

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

52 That’s almost all for day…
RINGKASAN

53 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"

54 Daftar Referensi Bacaan Utama Referensi lain
Kappel, G., Proll, B. Reich, S. & Retschitzegger, W. (2006). Web Engineering, Wiley & Sons. Bab 7 dan 11. Referensi lain Kent Beck, eXtreme Programming Explained

55 Tool Pengujian JUnit.org - http://www.junit.org
Cactus - Clover - dbUnit - HttpUnit - Canoo WebTest -

56 Tool Usability Pengembangan Pengujian
Toolbar pengembang Firefox ( Pengujian Daftar konprehensif dari tool WAI

57 Pertanyaan?