REKAYASA PERANGKAT LUNAK

Performing User Interface Design & Testing

Strategies
B Y GR O UP 5

Ezza Muhammad Firmansyah

Latifah Rahma
Saifudin Anwar
Interface Design
Easy to Learn ?
Easy to Use ?
Easy to Understand ?
Golden Rules
1. Place the user in control.
2. Reduce the user’s memory load.
3. Make the interface consistent.
Place the User in
Control
• Tetapkan mode interaksi dengan cara yang tidak memaksa
pengguna melakukan tindakan yang tidak perlu atau tidak
diinginkan.
• Berikan interaksi fleksibel.
• Izinkan interaksi pengguna menjadi interruptible dan undoable.
• Rampingkan interaksi saat tingkat keterampilan meningkat dan
biarkan interaksi disesuaikan.
• Sembunyikan internal teknis dari pengguna biasa.
• Desain untuk interaksi langsung dengan objek yang muncul di
layar.
Reduce the User’s Memory Load

• Ku r an gi per mi nt aan akan memor i j ang ka p en d ek .

• Tet apkan d ef aul t yang berm ak na.
• Tet apkan p i nt asan yan g i nt u i t i f .
• Tat a l et ak vi s ual ant ar muk a h ar us di d asark an p ada
met af o ra dun i a n yat a.
• Men gun gk ap kan i n fo rm as i s ecar a pr og resi f .
Make the Interface Consistent

• Izi n kan peng gu na u nt u k menemp at kan t ugas saat i n i ke

dal am k on t ek s yan g berm ak na.
• P er t ahank an ko nsi s t en si di sel ur u h rang kai an apl i k as i .
• Ji k a mod el i n t erakt i f mas a l al u t el ah menci p t ak an
har ap an peng gu na, j ang an memb uat p eru bahan kecual i
ad a al as an ku at un t uk m el ak uk an ny a.
 User Interface
Design Models
US ER M ODE L IMP LE ME NTATIO N M ODEL
Profil semua end user dari system gambar mental pengguna tentang
apa itu antarmuka

DES IGN MOD E L ME N TA L MO DE L

realisasi desain model user
(SY ST EM PE R C E PTI ON)
antarmuka "look and feel" ditambah
dengan informasi pendukung yang
menggambarkan sintaks dan
semantik antarmuka
User nterface Design Process
I
IN T E R FACE ANA LYS I S
Analisis antarmuka berarti pemahaman mengenai
• (1) orang-orang (end user) yang akan berinteraksi dengan sistem
melalui antarmuka;
• (2) tugas yang harus dilakukan end user untuk melakukan pekerjaan
mereka,
• (3) konten yang disajikan sebagai bagian dari antarmuka 
• (4) lingkungan di mana tugas-tugas ini akan dilakukan.
User nalysis
A

• Apakah pengguna terlatih profesional, teknisi, juru tulis, atau pekerja manufaktur?
• Tingkat pendidikan formal apa yang dimiliki rata-rata pengguna?
• Apakah pengguna mampu belajar dari bahan tertulis atau sudahkah mereka menyatakan
keinginan untuk pelatihan kelas?
• Apakah pengguna ahli mengetik atau fobia keyboard?
• Berapa kisaran usia komunitas pengguna?
• Apakah pengguna akan diwakili secara dominan oleh satu jenis kelamin?
• Bagaimana pengguna mendapat kompensasi untuk pekerjaan yang mereka lakukan?
• Apakah pengguna bekerja pada jam kantor normal atau apakah mereka bekerja sampai
pekerjaan selesai?
• Apakah perangkat lunak menjadi bagian integral dari pekerjaan yang dilakukan pengguna
atau hanya akan digunakan sesekali?
• Apa bahasa lisan utama di antara pengguna?
• Apa akibatnya jika pengguna membuat kesalahan dengan menggunakan sistem?
• Apakah pengguna ahli dalam masalah yang dibahas oleh sistem?
• Apakah pengguna ingin tahu tentang teknologi yang berada di belakang antarmuka?
Task ysis and Modeling
Anal

Tujuan analisis tugas adalah untuk menjawab pertanyaan berikut:

• Pekerjaan apa yang akan dilakukan pengguna?
• Tugas dan subtugas apa yang akan dilakukan?
• Apa objek domain masalah spesifik yang akan dimanipulasi pengguna?
• Apa urutan tugas kerja — alur kerja?
• Apa itu hierarki tugas?

• Use-case mendefinisikan interaksi dasar

• Elaborasi tugas menyempurnakan tugas interaktif
• Elaborasi objek mengidentifikasi objek antarmuka (kelas)
• Analisis alur kerja mendefinisikan bagaimana proses kerja diselesaikan ketika beberapa orang
(dan peran) terlibat
Analysis of Display Content
•Apakah berbagai jenis
data ditugaskan untuk
lokasi geografis yang
konsisten di layar?
•Bisakah pengguna
menyesuaikan lokasi layar
untuk konten?
•bagaimana laporan besar
dipartisi untuk
kemudahan
pemahaman?
Interface Design Steps
• Analisis Lingkungan Kerja
• Apakah sistem akan ditempatkan di lokasi yang ramah pengguna?
• akankah dua orang atau lebih membagikan informasi?
• apakah ada pencahayaan yang tepat?
• akses keyboard / mouse?
Interface Design Steps
• Menggunakan informasi yang dikembangkan selama analisis
antarmuka, tentukan objek antarmuka dan tindakan (operasi).
• Tetapkan kejadian (tindakan pengguna) yang akan menyebabkan
kondisi antarmuka pengguna berubah. Model perilaku ini.
• Gambarkan setiap kondisi antarmuka karena akan terlihat seperti end
user.
• Tunjukkan bagaimana pengguna menginterpretasikan keadaan sistem
dari informasi yang diberikan melalui antarmuka.
Design Issues
• Waktu merespon
• Fasilitas bantuan
• Menangani kesalahan
• Pelabelan menu dan perintah
• Aksesibilitas aplikasi
• Penginternasionalan
WebApp Interface Design
Antarmuka harus
- memberikan indikasi WebApp yang telah diakses
- beri tahu pengguna lokasinya di hierarki konten.

Antarmuka harus selalu membantu pengguna memahami opsi saat ini

- fungsi apa yang tersedia?
- tautan apa yang ditayangkan?
- konten apa yang relevan?

Antarmuka harus memudahkan navigasi.

Berikan "peta" (diimplementasikan dengan cara yang mudah dimengerti) di mana
pengguna berada dan jalur apa yang dapat diambil untuk pindah ke tempat lain dalam
WebApp.
Interface Design Principles

M AI NTAIN W O R K
AN TIC IPATIO N FO C US
PR ODUC T IN TE GR I T Y

C OM M UNIC ATION FITT’S LAW R EAD AB I LI T Y

C ON SISTENC Y HUM AN INTER FAC E

T R AC K S TATE
OB J EC TS
C O NTR OLLED
AU TONO M Y LATEN C Y R EDUC TIO N V IS IB L E NAVI GAT ION

E FFIC IEN C Y LEAR N AB ILITY

Interface Design Workflow
• Tinjau informasi yang terkandung dalam model analisis dan sempurnakan sesuai
kebutuhan.
• Kembangkan sketsa kasar tata letak antarmuka WebApp.
• Memetakan sasaran pengguna ke dalam tindakan antarmuka spesifik.
• Tetapkan serangkaian tugas pengguna yang terkait dengan setiap tindakan.
• Gambar layar Storyboard untuk setiap tindakan antarmuka.
• Perbaiki tata letak antarmuka dan storyboard menggunakan input dari desain estetika
Aesthetic Design

• Jangan takut white space.

• Tekankan konten.
• Atur elemen tata letak dari kiri atas ke kanan bawah.
• Navigasi grup, konten, dan fungsi secara geografis di dalam halaman.
• Jangan memperpanjang real estat Anda dengan bilah gulir.
• Pertimbangkan resolusi dan ukuran jendela browser saat mendesain tata letak.
Software Testing
Strategies
Software Testing

Testing adalah proses aktivitas program dengan

maksud tertentu untuk menemukan kesalahan
sebelum pengiriman ke pengguna akhir (end-user).
What Testing Shows

errors

requirements conformance

performance

an indication
of quality
Strategic Approach

 Untuk melakukan pengujian yang efektif, Anda harus

melakukan tinjauan teknis yang efektif. Dengan
melakukan ini, banyak kesalahan akan dihilangkan
sebelum dimulai pengujian.
 Pengujian dimulai pada tingkat komponen dan bekerja
"luar" menuju integrasi seluruh sistem berbasis komputer.
 teknik pengujian yang berbeda sesuai untuk pendekatan
rekayasa perangkat lunak yang berbeda dan di berbagai
titik dalam waktu.
 Pengujian dilakukan oleh pengembang perangkat lunak
dan (untuk proyek-proyek besar) sebuah kelompok uji
independen.
 Pengujian dan debugging merupakan aktivitas yang
berbeda, tetapi debugging harus diakomodasi dalam
setiap strategi pengujian.
 V&V

• Verification mengacu pada serangkaian tugas yang

memastikan perangkat lunak yang benar menerapkan
fungsi tertentu..
• Validation mengacu pada satu set yang berbeda dari
tugas-tugas yang memastikan bahwa perangkat lunak
yang telah dibangun dapat dilacak dengan kebutuhan
pelanggan.
 Who Tests the Software?

developer independent tester

Memahami sistem Harus belajar tentang sistem,
namun, akan menguji "lembut" namun, akan mencoba untuk memecahkannya
dan, didorong oleh "delivery" dan, didorong oleh kualitas
 Testing Strategy

System engineering

Analysis modeling
Design modeling

Code generation Unit test

Integration test
Validation test

System test
 Testing Strategy

 Kita mulai dengan ' testing-in-the-small ' dan bergerak ke arah ' testing-in-
the-large '
 Untuk perangkat lunak konvensional
 Modul (komponen) adalah fokus awal kami
 Integrasi modul berikut
 Untuk perangkat lunak OO
 fokus kami saat “pengujian di kecil” perubahan dari modul individu (pandangan
konvensional) untuk kelas OO yang meliputi atribut dan operasi dan menyiratkan
komunikasi dan kolaborasi
 Strategic Issues

 Tentukan persyaratan produk dengan cara yang terukur jauh sebelum pengujian
dimulai.
 Negara menguji tujuan eksplisit.
 Memahami pengguna perangkat lunak dan mengembangkan profil untuk setiap
kategori pengguna.
 Mengembangkan rencana pengujian yang menekankan “pengujian siklus cepat.”
 Membangun “kuat” perangkat lunak yang dirancang untuk menguji dirinya sendiri
 Gunakan ulasan teknis yang efektif sebagai filter sebelum pengujian
 Melakukan tinjauan teknis untuk menilai strategi pengujian dan uji kasus sendiri.
 Mengembangkan pendekatan perbaikan terus-menerus untuk proses pengujian.
 Unit Testing

modul
menjadi
diuji

hasil

perangkat lunak
insinyur
uji kasus
 Unit Testing

modul
menjadi
diuji
antarmuka
struktur data lokal
kondisi batas
jalur independen
jalur penanganan kesalahan

uji kasus
 Unit Test Environment

driver
antarmuka
struktur data lokal

Modul kondisi batas

jalur independen
jalur penanganan kesalahan

stub stub

uji kasus
HASIL
 Integration Testing Strategies

Pilihan:
• pendekatan “big bang”
• strategi pembangunan inkremental
Top Down Integration

A
modul atas diuji dengan
Rintisan bertopik

B F G

Rintisan bertopik diganti satu di

waktu, "kedalaman pertama"
C
sebagai modul baru yang terintegrasi,
beberapa bagian dari tes adalah re-run
D E
Bottom-Up Integration
A

B F G

driver diganti satu per satu

waktu, "kedalaman pertama"
C

modul pekerja dikelompokkan ke dalam

membangun dan terintegrasi
D E

gugus
Sandwich Testing

A
modul atas adalah
diuji dengan bertopik

B F G

modul pekerja dikelompokkan ke dalam

membangun dan terintegrasi
D E

gugus
 Regression Testing
 pengujian regresi adalah re-eksekusi beberapa bagian
dari tes yang telah dilakukan untuk memastikan bahwa
perubahan belum disebarkan efek samping yang tidak
diinginkan
 Setiap kali software dikoreksi, beberapa aspek dari
konfigurasi software (program, dokumentasi, atau data
yang mendukungnya) berubah.
 pengujian regresi membantu untuk memastikan bahwa
perubahan (karena pengujian atau karena alasan lain)
tidak memperkenalkan perilaku yang tidak diinginkan
atau kesalahan tambahan.
 pengujian regresi dapat dilakukan secara manual,
dengan re-mengeksekusi subset dari semua kasus uji
atau menggunakan alat capture / playback otomatis.
 Smoke Testing

 Pendekatan umum untuk menciptakan “build harian” untuk perangkat

lunak produk
 Pengujian smoke dengan langkah:
 komponen perangkat lunak yang telah diterjemahkan ke dalam kode
diintegrasikan ke dalam “membangun.”
• Sebuah membangun termasuk file semua data, perpustakaan, modul dapat
digunakan kembali, dan komponen rekayasa yang diperlukan untuk
melaksanakan satu atau lebih fungsi produk.
 Serangkaian tes ini dirancang untuk mengekspos kesalahan yang akan
membuat membangun dari benar melakukan fungsinya.
• Maksud harus untuk mengungkap “show stopper” kesalahan yang memiliki
kemungkinan tertinggi melemparkan proyek perangkat lunak di belakang
jadwal.
 Membangun terintegrasi dengan lainnya membangun dan seluruh
produk (dalam bentuk yang sekarang) adalah asap diuji setiap hari.
• Pendekatan integrasi mungkin top down atau bottom up.
 Object-Oriented Testing

 dimulai dengan mengevaluasi kebenaran dan konsistensi

analisis dan desain model
 perubahan strategi pengujian
 konsep 'unit' memperluas karena enkapsulasi
 integrasi berfokus pada kelas dan eksekusi mereka di
sebuah 'benang' atau dalam konteks skenario penggunaan
 validasi menggunakan metode black box konvensional
 desain uji kasus menarik pada metode konvensional,
tetapi juga mencakup fitur-fitur khusus
 Broadening the View of “Testing”

Hal ini dapat dikatakan bahwa tinjauan analisis OO

dan model desain ini sangat berguna karena
konstruksi semantik yang sama (misalnya, kelas,
atribut, operasi, pesan) muncul di analisis, desain,
dan tingkat kode. Oleh karena itu, masalah dalam
definisi atribut kelas yang ditemukan selama
analisis akan menghindari efek samping yang
mungkin terjadi jika masalah tidak ditemukan
sampai desain atau kode (atau bahkan iterasi
berikutnya dari analisis).
 Testing the CRC Model

1. Kembali model CRC dan model-hubungan objek.

2. Periksa deskripsi masing-masing kartu indeks CRC untuk
menentukan apakah tanggung jawab didelegasikan adalah bagian
dari definisi kolaborator.
3. Invert koneksi untuk memastikan bahwa setiap kolaborator yang
meminta layanan menerima permintaan dari sumber yang layak.
4. Menggunakan koneksi terbalik diperiksa pada langkah 3,
menentukan apakah kelas-kelas lain mungkin diperlukan atau
apakah tanggung jawab yang benar dikelompokkan antara kelas.
5. Tentukan apakah tanggung jawab secara luas diminta mungkin
digabungkan menjadi tanggung jawab tunggal.
6. Langkah 1 sampai 5 diterapkan iteratif untuk setiap kelas dan
melalui setiap evolusi dari model analisis.
 OO Testing Strategy

 pengujian kelas adalah setara dengan unit testing

 operasi dalam kelas diuji
 perilaku negara kelas diperiksa
 integrasi diterapkan tiga strategi yang berbeda
 benang berbasis pengujian-terintegrasi set kelas yang
dibutuhkan untuk merespon satu input atau event
 menggunakan berbasis pengujian-terintegrasi set kelas
yang dibutuhkan untuk merespon satu kasus penggunaan
 klaster pengujian-terintegrasi set kelas diminta untuk
menunjukkan salah satu kolaborasi
 WebApp Testing- I

 Model konten untuk webapp ditinjau kesalahan

mengungkap.
 Model antarmuka ditinjau untuk memastikan bahwa
semua kasus penggunaan dapat ditampung.
 Model desain untuk webapp ditinjau untuk
kesalahan navigasi mengungkap.
 User interface diuji untuk kesalahan mengungkap
dalam presentasi dan / atau mekanik navigasi.
 Setiap komponen fungsional adalah unit diuji.
 WebApp Testing- II
 Navigasi seluruh arsitektur diuji.
 The webapp diimplementasikan dalam berbagai
konfigurasi lingkungan yang berbeda dan diuji untuk
kompatibilitas dengan masing-masing konfigurasi.
 tes keamanan dilakukan dalam upaya untuk
mengeksploitasi kerentanan dalam webapp atau
dalam lingkungannya.
 tes kinerja dilakukan.
 The webapp diuji oleh populasi dikontrol dan
dimonitor dari pengguna akhir. Hasil interaksi mereka
dengan sistem dievaluasi untuk konten dan navigasi
kesalahan, kekhawatiran kegunaan, kekhawatiran
kompatibilitas, dan kehandalan WebApp dan kinerja.
 High Order Testing

 pengujian validasi
 Fokus pada persyaratan perangkat lunak
 pengujian sistem
 Fokus pada integrasi sistem
 Alpha / Beta testing
 Fokus pada penggunaan pelanggan
 pengujian pemulihan
 memaksa software gagal dalam berbagai cara dan memverifikasi bahwa pemulihan benar
dilakukan
 pengujian keamanan
 memverifikasi bahwa mekanisme perlindungan dibangun ke dalam sistem akan, pada
kenyataannya, melindunginya dari penetrasi yang tidak tepat
 stress testing
 mengeksekusi sebuah sistem dengan cara yang sumber daya tuntutan dalam jumlah normal,
frekuensi, atau volume
 Pengujian kinerja
 menguji kinerja run-time dari perangkat lunak dalam konteks sistem yang terintegrasi
Proses Debugging
 Debugging Effort

waktu yang dibutuhkan

untuk mendiagnosa
gejala dan
waktu yang dibutuhkan menentukan
untuk memperbaiki kesalahan sebab
dan perilaku
tes regresi
 Symptoms & Causes

gejala dan penyebab mungkin

terpisah secara geografis

Gejala mungkin hilang saat

masalah lain adalah tetap

Penyebab mungkin karena

kombinasi non-kesalahan

Penyebab mungkin karena sistem

atau kesalahan compiler

gejala Penyebab mungkin karena

asumsi bahwa setiap orang
sebab percaya

Gejala mungkin intermiten

Consequences of Bugs

infectious
damage

catastrophic
extreme
serious
disturbing

annoying
mild
Bug Type

Bug Categories: Terkait fungsi bug,

sistem yang berhubungan bug, bug data, coding bug,
bug desain, bug dokumentasi, standar
violations, etc.
Debugging Techniques

brute force / testing

backtracking

induction

deduction
 Correcting the Error
 Apakah penyebab bug direproduksi di bagian lain dari program ini?
Dalam banyak situasi, cacat program yang disebabkan oleh
pola yang salah dari logika yang dapat direproduksi di tempat
lain.
 Apa yang "bug berikutnya" mungkin diperkenalkan oleh memperbaiki
aku akan membuat? Sebelum koreksi dibuat, kode sumber (atau,
lebih baik, desain) harus dievaluasi untuk menilai kopling
logika dan struktur data.
 Apa yang bisa kita lakukan untuk mencegah bug ini di tempat
pertama?Pertanyaan ini adalah langkah pertama menuju
pembentukan perangkat lunak statistik pendekatan jaminan
kualitas. Jika Anda memperbaiki proses serta produk, bug akan
dihapus dari program saat ini dan dapat dihilangkan dari
semua program masa depan.
 Final Thoughts

 Berpikir - sebelum Anda bertindak untuk benar

 Gunakan alat untuk mendapatkan wawasan tambahan
 Jika Anda berada di jalan buntu, mendapatkan bantuan
dari orang lain
 Setelah memperbaiki bug, penggunaan regresi pengujian
untuk mengungkap efek samping