Transcript System Acceptance Testing

System Acceptance Testing
Sistem Acceptance Test

Bertujuan untuk menguji apakah sistem sudah
sesuai dengan apa yang tertuang dalam spesifikasi
fungisonal sistem (validation),
 Test akan dilakukan oleh pengembang dan hasil
akan dinilai oleh pengguna,
 Terdiri dari dua tahapan: Sebelum pengiriman dan
setelah instalasi,
 Melibatkan semua aspek sistem: hardware,
software aplikasi, environment software, tempat,
dan operators
Test Dokumentasi

Test Filosofi
 Test Plan
 Test specifications
 Test logs
 Test summary
 Commissioning Report
 Certificate of Acceptance
Test Filosofi

Untuk meyakinkan bahwa sistem sudah
memiliki:
– Keamanan dan keselamatan dalam operasional
– Kehandalan,
– Dapat dirawat secara cost-effective,
– Dapat dimodifikasi untuk menyesuaikan
dengan perubahan kebutuhan operasional
Test Plan

Merupakan dokumentasi yang menjelaskan jadwal
untuk pre-delivery dan site acceptance test
 Jadwal test:
– Urutan Test yang menyatakan kaitan antara test satu
dengan yang lainnya dan masing-masing test tersebut
sesuai dengan salah satu kebutuhan user
– Test Method -> spesifikasi test
– Resource provision: mendefinisikan pembagian
tanggung jawab dan waktu untuk setiap resource test
Test Plan (2)

Prosedur umum pengujian: menspesifikasikan
keseluruhan prosedur untuk melakukan
pengaturan dan set-up pengoperasian acceptance
test. Prosedur mencakup:
– Supervisi dan inviligator-> konfirmasi terhadap
prosedur pengetesan yg dilakukan oleh supervisi dan
approver
– Jadwal dan Lokasi: prosedur dan tanggung jawab untuk
mengatur jadwal dan tempat pengujian
– Perubahan perencanaan: prosedur ketika terjadi
perubahan jadwal
Test Plan (3)
– Kegagalan test: prosedur yg hrs dilakukan
ketika terjadi kesalahan spt: jumlah
pengulangan , penyesuaian kapan dilakukan test
setelah modifikasi
– Hasil test: prosedur utk mendokumentasi,
menyimpulkan dan mereview hasil pengujian
– Kriteria kelengkapan test: mendefinisikan
kriteria sukses kelengkapan test untuk predelivery dan site acceptance test.
Spesifikasi Test

Setiap test yg akan dilakukan harus
dispesifikasikan secara detail oleh pengembang
dan disetujui oleh user. Spesfikasi tsb terdiri dari:
– Judul dan referensi tunggal
– Tujuan yang secara spesifik sesuai dengan Functional
Requirement
– Lokasi pengujian
– Syarat Pengujian: mis.: nilai marginal input, supplies,
dan lingkungan yang digunakan
– Konfiguasi Test: versi dan isu hardware, software, test
dan bantuan simulasi
Spesifikasi Test (2)
– Spesifikasi input dan output
– Detail prosedur operasional pengujian
– Hasil yang dinginkan dan batasan utk
penerimaan (dlm model data numerik / check
list event, informasi sec. Garfis)
– Format untuk merekam hasil, details kesalahan
dan instruksi utk melakukan test ulang,
perekaman terhadap retensi dan analisis
Pre-Delivery Test

Dilakukan melalui simulasi terhadap tempat yang
implementasi sistem. Hal penting yang dilakukan
dlm melakukan pre-delivery test:
– Syarat utk memulai pengujian: konfiramsi terhadap
kebenaran data, dokumen, software aplikasi dan test
khusus atau software simulasi, dan ketersediaan
lingkungan yg sesuai, pelayanan dan personal yg cocok,
– Hardware dan software: pembuatan standard atau issue
level HW dan SW yg akan digunakan dlm pengujian
– Preliminary HW test: melakukan pengujian
performance-acceptance HW
– Test Plan
Pre-delivery Test (2)
– Prosedur Test
– Test Log: Log semua operasi dan kejadian selama test
(yg terencana maupun tidak) termasuk full detail
insiden, error, failure, retest, restart.
– System diagnostic: pendeteksian dan diagnosis fault yg
digunakan hrs tervalidasi (variasi fault dan kondisi outof-range)
– Functional Testing: functional testing yg menggunakan
sistem software hrs comprehensive. Simulasi inputs dan
respon hrs serealistik mungkin sesuai dg kondisi
tempat.
Pre-delivery Test (3)
– Test Summary: lsiting semua kegagalan test
(termasuk pengulangan), kejadian yg tidak
dapat dijelaskan dan non-conformances thd
Functional test
– Test Failure: aksi utk meresolve failure dan
masalah yg mucul selama pengujian,
– Kejelasan pengiriman,
Site Acceptance Test

Semua pengujian pada pre-delivery sudah
dilakukan dan diterima. Hal tambahan yang
dilakukan :
– Delivery check: pengecekan terhadap kerusakan HW,
SW dan dokumnetasi selama pengiriman,
– Test Hardware: tidak terdapat kerusakan selama
pengimpanan dan pengiriman, sudah instal dg baik,
beroperasi dg baik di lingkungan tempat yg akan
diinstal (listrik, ruangan, dll)
– Modifikasi pre-delivery test: semua modifikasi sebagai
konsekuensi dr masalah yg akan muncul selama predelivery test hrs dijadikan sebagai test tambahan
Site Acceptance Test (2)
– Pengujian terhadap semua peralatan
– Pendukung kebutuhan:
 jadual pengujian di site:
–
–
–
–
Test validasi HW
Test HW dengan hubungan ke site
Fault validation testing: respon out-ot limit input
Functional testing: pengujian functional system yg
komprehensif
– Extended running
Site Acceptance Test (3)

Aspek lain yg hrs diperhatikan:
– Training staf yg akan mengoperasikan sistem
– Training staf yg akan merawat sistem
– Kebutuhan lainnya untuk tuning system, mis.:
max throughput, max. efisiensi, minimum cost
– Pembuktian lainnya spt sistem alarm,
keselematan, keamanan, dan back-up
Pengambil alihan dan
Penerimaan

Pengambil alihan (takeover) user setuju
bahwa peralatan sudah sesuai dengan
kebutuhan yang ditambahkan dengan
garansi utk periode tertentu terbebas dr
kesalahn
 Penerimaan (acceptance) adalah user setuju
bahwa software/aplikasi sudah sesuai
dengan kebutuhan
Best Practice Testing

Basic Practice:
– Functional Specifications menggambarkan fungsi
keseluruhan sistem shg keuntungannya adalah aktifitas
pengujian dapat dilakukan secara paralel dengan proses
pengembangan code.
– Reviews dan Inspection: melakukan Reviews dan
inspeksi (debugging) terhadap kode sumber.
– Kriteria formal entry dan exit setiap proses
pengembangan sistem dilakukan insoeksi terhadap
parameter entry dan exit.
– Functional test – variations: jumlah test cases yg dibuat
biasanya bervariasi. Variasi adalah kombinasi kondisi
input tertentu untuk menghasilkan konidisi output yg
spesifik.
Basic Practice (2)
– Multi-platform testing: pengujian pada semua
platform mesin.
– Internal Betas: pengujian yg dilakukan oleh
sejumlah user tertentu sebelum dilakukan
pengiriman.
– Automated test execution: meminimalkan
jumlah kerja manual pada saat pengujiaan
sehingga memperoleh nilai coverage yang lebih
tinggi. Test tool (oracle) yg digunakan
memverifikasi operasi dan log kesalahan,
Foundational
– Skenario User: membuat skenario user yang
menguji fungisonalitas aplikasi,
– Pengujian Usabilitas: tidak saja melakukan
pengujian usabilitas, tetapi juga menyediakan
suatu metode feetback untuk meningkatkan
user experience shg terbentuk image kualitas yg
baik.
Foundational (2)
– Requirements dalam perencanaan test.
Kebutuhan(user requirements) adalah
parameter yg digunakan dalam pengetesan,
dimana sistem yg dikembangkan hrs sesuai
dengan kebutuhan user tsb, Sehingga dlm
merancang test, kebutuhan user harus sudah
diketahui dg jelas.
– Automated test generation: Almost 30% of the
testing task can be the writing of test cases ->
need a automatically test tools.
Incremental



Kedekatan antara Tim penguji dan pengembang sehingga
dapat mengoptimalkan proses pengujian,
Code coverage : Konsep Code coverage berbasiskan pada
notasi struktural code. Code coverage adalah metrik yg
numerik yang mengukur elemen code (brach, statement,
path dan data) yg sudah diujikan. Penggunaan tool
pengujian code coverage dapat membantu mempercepat
proses pengujian
Automated environment generator (Drake): automated
generate of various environment (more operating systems,
more versions, and code that runs on multiple platforms) Tools DRAKE
Incremental (2)

Testing untuk membantu pengiriman sesuai
dengan permintaan. Menguji proses pengiriman
spt e-commerce, dimana tingkat interaksi dengan
pelanggan merupakan faktor yg sangat kompetitif.
 State task diagram menggambarkan operasi
fungsional suatu aplikasi atau modul dalam bentuk
state diagram. Keuntungannnya adalah
memungkinkan pembuatan test cases secara
otomatis atau membentuk metrik coverage lebih
denkat dengan dekomposisi aplikasi.
Incremental(3)


Memory resource failure simulation: utk menemukan bug
software yaitu loss memory yang disebabkan oleh
lemahnya pengaturan heap atau banyaknya garbage
collection. Terdapat tool yang dapat menguji memory
failure dan melihat kekurangan memory.
Statistical testing. Metode pengujian statistik ini mengukur
waktu interfailure selama pengoperasian sistem untuk
mengestimasi kehandalan sistem. Suatu proses
pengembangan yg baik akan menunjukkan mean time yg
cenderung meningkat setelah setiap bug diperbaiki.
Incremental (3)
– Check-in tests for code: Idenya adalah untuk
menghubungkan antara automatic test program
(biasanya regression test) dengan sistem change
control. Artinya setiap dilakukan perubahan
code, maka dilakukan regression test.
– Minimizing regression test cases dengan
melihat code coverage yang dihasilkan, dan
menyaring test cases ke suatu minimal set.
Incremental (4)

Instrumented versions for MTTF (mean Time Test
Failure) dimana hasil pengujian beta test yang
mengirim feedback ke pengembang memiliki
beberapa keutungan: sebagai kontrol kualitas
produk, mengukur mean time between failure utk
produk yg sama yg dilakukan oleh user yg
berbeda, meningkatkan kinerja diagnosis sistem.
 Benchmark trends menggunakan banyak disiplin
dari beberapa area. Hal ini menunjukkan beberapa
model dari beberapa pakar pengembang sistem.
 Bug bounties: memberikan rewards bagi penguji
dalam hal menemukan bug dlm software,
Kesalahan Klasik dalam
Proses Pengujian





Peranan Testing: siapa yang melakukan pengujian
layanan team testing dan bagaimana mengujinya?
Planning the Testing Effort: Bagaimana
seharusnya pengorganisasian team work?
Personnel Issues: siapa yang harus melakukan
test?
Tester at Work: perancangan, penulisan dan
perawatan individual tests.
Technology Rampant: quick technological untuk
hard problems.
Peranan dari Penguji







Memikirkan tim penguji bertanggung jawab
untuk menjaga kualitas,
Memikirkan bahwa tujuan pengujian adalah untuk
menemukan bugs. Thinking that the purpose of
testing is to find bugs.
Not finding the important bugs.
Not reporting usability problems.
No focus on an estimate of quality (and on the
quality of that estimate).
Reporting bug data without putting it into context.
Starting testing too late (bug detection, not bug
reduction)
Generating the Test Case
from Use Case

Use cases is visually requirements description is
based on UML (Unified Modeling Language).
Pembentukan Test Case

Pembentukan test
case berdasarkan
basic flow (sistem
berjalan dg
normal) dan
alternate flow
(alternatif
jalannya sistem).
Contoh
Flow Normal : Logon -> Select “Create
Schedule” -> Obtain Course Information ->
Select Course -> Submit Schedule ->
Display Completed Course
 Alternate Flow: Unidentified Student; Quit
at anytime; Unfulfilled Prerequisite, Course
Full, Schedule Conflict; Course Catalog
Unavailable; Course Registration is Closed.

Use Case Scenario
Scenario 1 Basic Flow
Scenario 2 Basic Flow Alternate Flow 1
Scenario 3 Basic Flow Alternate Flow 1 Alternate Flow 2
Scenario 4 Basic Flow Alternate Flow 3
Scenario 5 Basic Flow Alternate Flow 3 Alternate Flow 1
Scenario 6 Basic Flow Alternate Flow 3 Alternate Flow 1 Alternate Flow 2
Scenario 7 Basic Flow Alternate Flow 4
Scenario 8 Basic Flow Alternate Flow 3 Alternate Flow 4
Three-step process for generating
test cases from a fully-detailed use
case:
1.
2.
3.
For each use case, generate a full
set of use-case scenarios.
For each scenario, identify at
least one test case and the
conditions that will make it
"execute."
For each test case, identify the
data values with which to test.
Step One: Generate
Scenarios

Read the use-case textual description and identify each
combination of main and alternate flows -- the scenarios
-- and create a scenario matrix.
Scenario Name
1: Successful Registration
2: Unidentified User
3: User quits
4: Course Catalog Unavailable
5: Registration Clossed
6: Cannot Enroll
Starting Flow
Basic Flow
Basic Flow
Basic Flow
Basic Flow
Basic Flow
Basic Flow
Alternate
A1
A2
A4
A5
A3
Step Two: Identify Test Cases
Id
Scenario
Stud. Id Pass
word
Course Prereq.
Course Schedule Test Result
Selected Fulfilled Open
Open
RC1
1: Successful
Registration
V
V
V
V
V
V
Schedule and
Confirmation
Number
Displayed
RC 2
2: Unidentified
student
I
N/A
N/A
N/A
N/A
N/A
Err. Msg.:
Back To Login
RC 3
3: valid user
quits
V
V
N/A
N/A
N/A
N/A
Login screen
appeared
RC 4
4: course
registration
system
unavailable
V
V
N/A
N/A
N/A
N/A
Err. Msg.:
back to step 2
RC 5
5: registration
closed
V
V
N/A
N/A
N/A
N/A
Err. Msg.:
back to step 2
RC 6
6: Coure Full
V
V
V
V
I
V
back to step 3
RC 7
7: Pre-req. Not
fulfilled
V
V
V
I
V
V
back to step 4
RC 8
8: Schedule
Conflict
V
V
V
V
V
I
back to step 4
Step Three: Identify
Data Values to Test

to substitute actual data values for
the Is and Vs