SystemAcceptanceTesting
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 performanceacceptance 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:
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
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
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 performanceacceptance 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:
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
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