Materi Perkuliahan Menjalankan test Menganalisa hasil Melaporkan hasil ke developer dan manager (overview)

Tahap-tahap Pengujian : Tentukan apa yang akan diukur melalui pengujian Bagaimana pengujian akan dilaksanakan Membangun suatu kasus uji (test case), yaitu sekumpulan data atau situasi yang akan digunakan dalam pengujian. Tentukan hasil yang diharapkan atau hasil sebenarnya Jalankan kasus pengujian bandingkan hasil pengujian dan hasil yang diharapkan.

Menjalankan test Testing aplikasi desktop Testing aplikasi server Testing aplikasi web

Testing aplikasi desktop Jenis : Functionality Configuration Compatibility

Testing aplikasi server Jenis : Volume Testing Stress Testing Performance Testing Recovery Testing.

Volume Testing Menemukan kelemahan di sistem terkait dengan bagaimana “handling” dari sistem jika diberikan data yang besar dalam kurun waktu yang singkat

Stress Testing Untuk memastikan bahwa sistem memiliki kapasitas untuk menghandle pemrosesan transaksi dalam jumlah besar selama “peak period”

Performance Testing Dapat dilakukan secara paralel dengan volume dan stress testing karena yang ingin diketahui adalah bagaimana kinerja sistem pada semua kondisi load, baik itu jam-jam sibuk atau sebaliknya Biasanya terkait dengan response time dan rata-rata proses yang dapat diselesaikan dalam berbagai macam konfigurasi dan kondisi pemrosesan Harus mencakup semua konfigurasi hardware dan sistem (laptop VS desktop, LAN vs WAN, dll)

Recovery testing Data recovery Server recovery

Data Recovery Testing Kemampuan data recovery dan system restart dapat menghemat waktu dan uang ketika terjadi kegagalan pada sistem produksi Ada bermacam-macam level teknologi RAID (Redundant Array of Inexpensive Disks) yang merupakan framework untuk menyebarkan data di beberapa database atau file server dan memastikan data dapat direcovery jika terjadi kegagalan pada salah satu server. Yang perlu dites adalah recovery options untuk sistem RAID kita ketika memonitor performa sistem tersebut

Server Recovery Server recovery testing harus mencakup testing recovery dari jenis error : GPPE errors  ketika terjadi operasi prosesor yang invalid IOPE errors  ketika server mengeksekusi path yang invalid NMI errors (hardware generated errors)  ketika terjadi kegagalan RAM atau fluktuasi power Break Points  ketika suatu stack corrupted yang mengakibatkan invalid return point atau ketika pointer merefer ke lokasi yang invalid

Data Security Testing Menguji akses kontrol untuk tool yang dipergunakan pihak ketiga Menguji prosedur untuk kontrol akses ke tabel database tertentu Menguji pemakaian password yang terenkripsi / transmisi data Menguji pemakaian user name bayangan (shadow user name) untuk user yang memiliki akses write dan read.

Automated Server Testing Tools. Stored procedures dan data base triggers sebaiknya diuji dengan driver modules yang mengakses langsung ke database layer Salah satu contoh automated testing tool adalah LoadRunner/XL yang menguji sisi server dari aplikasi multi-user Client-Server untuk perencanaan kapasitas dan menentukan konfigurasi server yang mendukung kinerja database

Automated Server Testing Tools. Blue Lagoon Software yang menyediakan tool untuk menguji link antara client dan server Mercury/Blue Lagoon Software juga menyediakan SQL Profiler yang menyimpan dan memperlihatkan statistik tentang SQL command yang ter-embed dalam aplikasi C-S

Network Security Testing Menguji parameter dan konfigurasi jaringan (firewall, web server, mail server dll) Menguji transmisi media jaringan Menguji koneksi WAN/MAN/LAN Menguji kinerja network provider

NEXT TIME

Testing aplikasi web Testing untuk aplikasi web memiliki banyak kesamaan dengan testing untuk aplikasi client server, tetapi aplikasi web lebih sulit karena tingkat kompleksitasnya lebih tinggi  interaksi komponen (teknologi) yang dipergunakan tidak terbatas Browser OS Aplikasi plugin, dll

Cont’d Idealnya semua komponen dan fungsi yg ada pada sisi client dan server harus dites (tapi sgt jarang bisa dilakukan)  pendekatan terbaik agar tetap sesuai dengan batasan waktu dan budget : Mengecek requirement project Mensetting prioritas sesuai hasil risk analysis Tentukan fokus testing yg dilakukan

Risk analysis Risk analysis yang dilakukan harus mempertimbangkan : seberapa mirip lingkungan test dengan lingkungan produksi (idealnya akan mirip) fungsionalitas mana yang sangat kritikal terhadap tujuan pembuatan website area mana yang memerlukan interaksi DB yang lebih banyak

Cont’d tipe permasalahan seperti apa yang akan lebih sering dikomplain area mana dari suatu situs yang akan lebih sering dibuka aspek mana yang memiliki resiko keamanan lebih tinggi

faktor faktor seperti project requirement, risk analysis, budget dan schedule menentukan kategori testing yang mana yang sesuai dengan project web yang dilaksanakan

Kategori testing web Load testing Security testing Link testing HTML validation dll

Penjelasan Load testing Testing dengan load yang sudah diatur rangenya untuk menentukan pada poin mana respons time sistem turun atau bahkan gagal sama skali. Server yang dipakai, seting konfigurasi yang dipergunakan, script CGI, desain database dan faktor-faktor lain bisa juga memberikan pengaruh Testing bisa dilakukan dengan 2 cara Testing keseluruhan komponen dibawah kondisi yang bermacam-macam Testing masing-masing komponen

Security testing Menguji semua fungsi yg berhubungan dengan firewall, enkripsi, autentikasi, transaksi, akses database Menguji perlindungan yang diberikan Selain permasalahan kontrol akses di sisi client (password dan enkripsi) juga ada permasalahan di sisi server spt siapa yg berhak mempublish dan memodifikasi file html, siapa yang memiliki wewenang untuk melakukan publikasi final, yang meng-approve suatu file graphics, file sound dan halaman layout

Link testing HTML validation Untuk menentukan apakah link dari suatu situs baik itu ke internal dan external web pages bekerja Web yg memiliki banyak link ke situs luar perlu link testing yg dijadwal secara teratur  kenapa ? HTML validation Ditentukan oleh audience yg dituju, jenis browser yang kemungkinan akan dipakai dan seberapa sesuai dengan standar html, microsoft atau ekstensi lainnya

NEXT TIME

Tool yang dipergunakan Load testing Curl-Loader, StressTester, Proxy Sniffer, Funkload, Loadea, LoadManager, webStress, WAPT, FORECAST, dll Security testing Hailstorm, OWASP Security testing tools, GamaSec, Wikto, add-ons di firefox  SQL Inject Me 0.4.0

Link testing HTML validation WebLight, HTML PowerTools, Broken Link Preventer, W3C Link Checker HTML validation WebLight, HTML PowerTools, W3C CSS Validation Service, W3C HTML Validation Service

NEXT TIME

Menganalisa hasil

Melaporkan hasil ke developer dan manager Pelaporan hasil ke developer dan manager  melalui dokumentasi  agar lebih mudah dimengerti, dibuatlah standar yang mengatur dokumentasi testing (standar tersebut bersifat universal) Pendokumentasian testing Standar dokumentasi testing

Outline Pendokumentasian testing Standar dokumentasi testing Bug tracking

Testing yang dilakukan harus didokumentasikan Tujuan pendokumentasian testing : Menyediakan data terkait dengan kesiapan peluncuran sistem Menyediakan data terkait dengan long term detection dari permasalahan suatu fungsi

Isi dari dokumentasi testing Functional testing status Berapa persen : Selesai ditest Ditest dengan status defect masih open Tidak ditest Expected vs actual defect detected hasil analisa antara jumlah defect yang diharapkan akan muncul (pada fase planning) dan jumlah defect yang benar-benar muncul

Defect detected vs corrected hasil analisa antara jumlah defect yang sudah dideteksi (dan belum terselesaikan) dengan jumlah defect yang sudah diperbaiki Defect distribution menjelaskan lokasi defect ditemukan (modul atau fungsi)

Testing action menjelaskan tentang ringkasan kegiatan testing yang sudah dilakukan. Ex : apakah ada testing yang molor dari jadwal yang telah ditentukan, testing bagian apa, karena apa

Standar dokumentasi testing Standar IEEE 829 Mengatur dokumentasi standar untuk : Testplan Test design specification Test case specification Test procedure specification Test item transmittal report Test log Test incident report Test summary report

Bug tracking/defect tracking Tujuan dari testing adalah menemukan sebanyak mungkin defect/bug Penyebabnya: Berbeda dengan spesifikasi produk Berbeda dengan keinginan user Setelah ditemukan, defect tersebut harus disampaikan ke developer – dilaporkan atau direkam

Tujuan utama dari merekam/melaporkan bug/defect Untuk memperbaiki defect Untuk melaporkan status dari aplikasi Untuk memperoleh statistik yang dipergunakan untuk mengembangkan ekspektasi defect untuk pengembangan aplikasi mendatang Untuk meng-improve proses pengembangan software

Item yang harus dilaporkan dalam defect tracking : Nama defect Sumber Defect severity Defect priority Status Detil deskripsi PIC untuk memperbaiki defect

Setelah dilakukan perbaikan oleh developer, harus dilakukan retest terhadap perbaikan tersebut untuk memastikan bahwa perbaikan yang dilakukan tidak bermasalah di tempat lain Diperlukan mekanisme problem tracking

Informasi yang diperlukan pada problem tracking Bug identifier Status terbaru Test case identifier Nama tester Tanggal testing Tanggal pelaporan bug

PIC untuk perbaikan Deskripsi penyebab bug Deskripsi perbaikan Tanggal perbaikan Tester untuk retest Tanggal retest Hasil retest