PERTEMUAN V PENGUJIAN TESTING PERANGKAT LUNAK

(1)

PERTEMUAN V

PENGUJIAN TESTING PERANGKAT LUNAK

TESTING & IMPLEMENTASI

(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 aplikasi, environment software, tempat, dan operators

(3)

Test Dokumentasi

• Test Filosofi

• Test Plan

• Test specifications

• Test logs

• Test summary

• Commissioning Report

• Certificate of Acceptance

(4)

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

(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 tanggung jawab dan waktu untuk setiap resource test

(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 perubahan jadwal

(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 kriteria sukses kelengkapan test untuk pre-delivery dan site acceptance test.

(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 bantuan simulasi

(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 dan instruksi utk melakukan test ulang, perekaman terhadap retensi dan analisis

(10)

Pre-Delivery Test

• Dilakukan melalui simulasi di tempat implementasi sistem. Hal penting yang dilakukan dlm melakukan pre-delivery test:

• Syarat utk memulai pengujian: konfirmasi 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

(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 tempat.

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

• Kejelasan pengiriman,

(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 konsekuensi dr

masalah yg akan muncul selama pre-delivery test hrs dijadikan sebagai test tambahan

(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 komprehensif

• Extended running

(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, keselematan, keamanan, dan back-up

(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 bahwa software/aplikasi sudah sesuai dengan kebutuhan

(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 biasanya bervariasi.

Variasi adalah kombinasi kondisi input tertentu untuk menghasilkan konidisi

(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 memverifikasi operasi dan log kesalahan,

(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 user experience shg terbentuk image kualitas yg baik.

(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 testing task can be the writing of test cases -> need a automatically test tools.

(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 generate of various environment (more operating systems, more versions, and

(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 otomatis atau

membentuk metrik coverage lebih denkat dengan dekomposisi aplikasi.

(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 pengembangan yg baik akan

menunjukkan mean time yg cenderung meningkat setelah setiap bug diperbaiki.

(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 melihat code coverage yang dihasilkan, dan menyaring test cases ke suatu minimal set.

(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 hal

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

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

(28)

Generating the Test Case from Use Case

• Use cases is visually requirements description is based on UML (Unified Modeling Language).

(29)

Pembentukan Test Case

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

(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

Unavailable; Course Registration is Closed.

(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 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 Basic Flow Alternate Flow 4

(32)

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. (setiap use case, buat satu set lengkap skenario use case)

• For each scenario, identify at least one test case and the conditions that will make it "execute." (setiap skenario, identifikasi setidaknya satu kasus dan kondisi yang akan "dieksekusi“)

• For each test case, identify the data values with which to test. (setiap kasus diuji, diidentifikasi nilai data yang akan digunakan untuk

menguji)

(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

(34)

Step Two: Identify Test Cases

Îd ^Scenario ^{Stud. Id} ^Pass^word ^Course^Selected ^Prereq.^Fulfilled ^CourseÔpen ^ScheduleÔpen 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

(35)

Step Three: Identify Data Values to Test

• to substitute actual data values for the Is and Vs

(36)

(37)

WASALAM

#stay@home #Stayhealthy