SystemAcceptanceTesting

(1)

(2)

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

(3)

Test Dokumentasi



Test Filosofi



Test Plan



Test specifications



Test logs



Test summary



Commissioning Report

(4)

Test Filosofi



Untuk meyakinkan bahwa sistem sudah

memiliki:

– _{Keamanan dan keselamatan dalam operasional} – _Kehandalan,

– _{Dapat dirawat secara cost-effective,}

– _{Dapat dimodifikasi untuk menyesuaikan}

(5)

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}

(6)

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}

(7)

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}

(8)

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}

(9)

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}

(10)

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

(11)

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 out-of-range)

– _{Functional Testing: functional testing yg menggunakan}

sistem software hrs comprehensive. Simulasi inputs dan respon hrs serealistik mungkin sesuai dg kondisi

(12)

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,

(13)

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}

(14)

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

(15)

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,}

(16)

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

(17)

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}

(18)

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

(19)

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

(20)

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}

(21)

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

(22)

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

(23)

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

(24)

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}

(25)

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

(26)

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

(27)

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

(28)

Generating the Test Case

from Use Case

 Use cases is visually requirements description is

(29)

Pembentukan Test Case



Pembentukan test

case berdasarkan

basic flow (sistem

berjalan dg

normal) dan

alternate flow

(alternatif

(30)

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

(31)

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 5 Basic Flow Alternate Flow 3 Alternate Flow 1

Scenario 6 Basic Flow Alternate Flow 3 Alternate Flow 1 Alternate Flow 2

(32)

Three

-step process for generating

test cases from a fully-detailed use

case:

1.

For each use case, generate a full

set of use-case scenarios.

2.

For each scenario, identify at

least one test case and the

conditions that will make it

"execute."

3.

For each test case, identify the

(33)

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 Starting Flow Alternate

1: Successful Registration Basic Flow

2: Unidentified User Basic Flow A1

3: User quits Basic Flow A2

4: Course Catalog Unavailable Basic Flow A4

5: Registration Clossed Basic Flow A5

(34)

Step

Two

:

Identify Test Cases

Id Scenario Stud. Id Pass

word Course _Selected Prereq._Fulfilled Course_Open Schedule_Open Test Result

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

(35)

Step Three: Identify

Data Values to Test



to substitute actual data values for