Web Engineering 2010 Pertemuan ke-06

1. Web Engineering 2010 • Pertemuan ke-06 Pengujian dan Kebergunaan Aplikasi Web (Testing &Usability) Husni husni@if.trunojoyo.ac.id 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. Testingdan 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 Usabilityadalah 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. 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: • 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 • Errordalam contentWeb: • 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 bahasaPengujian 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. 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 http://)?

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. 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 JUnittermasuk: • 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 • JUnitdigunakan secara luas di industri • JUnitdapat 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 (testcase) harus berada pada client dan server

27. Ekstensi JUnitlain • HttpUnit • Memparse hasil HTML ke dalam DOM • Navigasi link yang mudah dan membetuk populasi • Berguna untuk uji penerimaan (acceptance) terotomasi • CanooWebTest • HttpUnitdi 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. 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. Usabilitydalam 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 Implementation Operation WebEngineering Analysis Design Coding Testing Maintenance

35. User-Centered vs. Usage-Centered

36. Analisis Kebutuhan • SystemsAnalysts & UsabilityExpertssebagai 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-useatau 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 feedbackdari pengguna potensial • Pakar usabilitymenyediakan input setelah putaran pertama ini.

38. Interaksi dan Rancangan • Designerdan 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, 7 + 2 (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"