System Acceptance Testing Sistem Acceptance Test Bertujuan untuk

System Acceptance Testing

Sistem Acceptance Test Bertujuan untuk menguji apakah sistem sudah sesuai dengan apa yang tertuang dalam spesifikasi fungisonal sistem (validation), l Test akan dilakukan oleh pengembang dan hasil akan dinilai oleh pengguna, l Terdiri dari dua tahapan: Sebelum pengiriman dan setelah instalasi, l Melibatkan semua aspek sistem: hardware, software aplikasi, environment software, tempat, dan operators l

Test Dokumentasi l Test Filosofi l Test Plan l Test specifications l Test logs l Test summary l Commissioning Report l Certificate of Acceptance

Test Filosofi l 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 l Jadwal test: l – 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) l 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 l 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 l 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 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 l Semua pengujian pada pre-delivery sudah dilakukan 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: l 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) l 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 l Pengambil alihan (takeover) user setuju bahwa peralatan sudah sesuai dengan kebutuhan yang ditambahkan dengan garansi utk periode tertentu terbebas dr kesalahn l Penerimaan (acceptance) adalah user setuju bahwa software/aplikasi sudah sesuai dengan kebutuhan

Best Practice Testing l 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, l 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 l Automated environment generator (Drake): automated generate of various environment (more operating systems, more versions, and code that runs on multiple platforms) Tools DRAKE l

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. l 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. l

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. l 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. l

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. l Benchmark trends menggunakan banyak disiplin dari beberapa area. Hal ini menunjukkan beberapa model dari beberapa pakar pengembang sistem. l Bug bounties: memberikan rewards bagi penguji dalam hal menemukan bug dlm software, l

Kesalahan Klasik dalam Proses Pengujian l l l 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 l l l l 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 l Use cases is visually requirements description is based on UML (Unified Modeling Language).

Pembentukan Test Case l Pembentukan test case berdasarkan basic flow (sistem berjalan dg normal) dan alternate flow (alternatif jalannya sistem).

Contoh l Flow Normal : Logon -> Select “Create Schedule” -> Obtain Course Information -> Select Course -> Submit Schedule -> Display Completed Course l Alternate Flow: Unidentified Student; Quit at anytime; Unfulfilled Prerequisite, Course Full, Schedule Conflict; Course Catalog Unavailable; Course Registration is Closed.

Use Case 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: 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 data values with which to test. 1.

Step One: Generate Scenarios l 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 Alternate A 1 A 2 A 4 A 5 A 3

Step Two: Identify Test Cases Id Scenario Stud. Id Pass word Course Prereq. Course Schedule Test Result Selected Fulfilled Open RC 1 1: Successful Registration V V V Schedule and Confirmation Number Displayed RC 2 2: Unidentified student I N/A N/A N/A Err. Msg. : Back To Login RC 3 3: valid user quits V V N/A N/A Login screen appeared RC 4 4: course registration system unavailable V V N/A N/A Err. Msg. : back to step 2 RC 5 5: registration closed V V N/A N/A Err. Msg. : back to step 2 RC 6 6: Coure Full 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 I back to step 4

Step Three: Identify Data Values to Test l to substitute actual data values for the Is and Vs