Validasi Sistem

CHAPTER
10
Pengujian
Langkah 4: Validasi
Langkah ini memberikan kesempatan untuk mengevaluasi sistem dalam mode yang dapat dieksekusi. Meskipun langkah-
langkah verifikasi sebelumnya memastikan bahwa sistem akan berfungsi seperti yang ditentukan, tidak sampai perangkat
lunak dijalankan sebagai sistem, ada jaminan lengkap bahwa itu akan berfungsi dengan baik.
Menguji pengorbanan dapat dilakukan di antara berbagai fase siklus hidup. Semakin
banyak pengujian verifikasi yang dilakukan selama fase persyaratan, desain, dan program, semakin
sedikit pengujian validasi yang perlu dilakukan. Di sisi lain, ketika hanya pengujian verifikasi minimal
yang dilakukan selama fase awal, pengujian validasi ekstensif mungkin diperlukan selama fase pengujian.
Gambaran
Meskipun penguji terutama menggunakan dokumentasi sistem untuk melakukan pengujian verifikasi, mereka
menggunakan data pengujian dan skrip pengujian untuk melakukan pengujian validasi.
Pengujian validasi mencoba untuk mensimulasikan lingkungan operasional sistem. Pengujian validasi hanya efektif
jika lingkungan pengujian setara dengan lingkungan produksi.
Ada dua jenis pengujian validasi. Yang pertama adalah pengujian yang diimplementasikan pengembang ke
perangkat lunak seperti yang ditentukan. Paling tidak, ini adalah pengujian unit dan pengujian integrasi unit. Jenis
pengujian kedua menguji bahwa sistem perangkat lunak yang dikembangkan dapat beroperasi di lingkungan produksi.
Artinya, menguji bahwa berbagai komponen sistem dapat diintegrasikan secara efektif. Meskipun jenis pengujian
kedua ini dapat dilakukan oleh pengembang perangkat lunak, metode yang lebih disukai adalah menggunakan penguji
independen. Jenis pengujian dinamis kedua ini dibahas dalam Bab 12.
409
410 Bab 10
Objektif
Tujuan dari langkah ini adalah untuk menentukan apakah sistem perangkat lunak bekerja dengan benar dalam
mode yang dapat dieksekusi. Perangkat lunak dijalankan dalam lingkungan pengujian dalam mode yang kira-kira
sama seperti dalam lingkungan operasional. Pengujian harus dilakukan dengan berbagai cara yang diperlukan untuk
mengatasi 15 masalah yang dijelaskan dalam proses pengujian ini, dengan setiap penyimpangan dari hasil yang
diharapkan dicatat. Tergantung pada tingkat keparahan masalah, perubahan yang tidak terungkap mungkin perlu
dilakukan pada perangkat lunak sebelum ditempatkan dalam status produksi. Jika masalahnya luas, mungkin perlu
untuk menghentikan pengujian sepenuhnya dan mengembalikan perangkat lunak ke pengembang.
Kekhawatiran
Pengujian validasi menyajikan kepada penguji kekhawatiran berikut:
- - Perangkat lunak tidak dalam mode yang dapat diuji. Langkah-langkah pengujian sebelumnya tidak akan dilakukan
secara memadai untuk menghilangkan sebagian besar cacat dan/atau fungsi yang diperlukan tidak akan diinstal,
atau diinstal dengan benar dalam perangkat lunak.
Dengan demikian, pengujian akan menjadi macet dalam mengidentifikasi masalah yang seharusnya telah
diidentifikasi sebelumnya.
- - Waktu/sumber daya yang tidak memadai. Karena keterlambatan dalam pengembangan atau kegagalan untuk menganggarkan
waktu dan sumber daya yang cukup untuk pengujian, penguji tidak akan memiliki waktu atau sumber daya yang diperlukan
untuk menguji perangkat lunak secara efektif. Di banyak organisasi TI, manajemen bergantung pada pengujian untuk
memastikan bahwa perangkat lunak siap untuk produksi sebelum ditempatkan dalam produksi. Ketika waktu atau sumber
daya yang memadai tidak tersedia, manajemen mungkin masih mengandalkan penguji ketika mereka tidak dapat melakukan
pengujian seperti yang diharapkan.
- - Masalah signifikan tidak akan terungkap selama pengujian. Kecuali pengujian direncanakan dan dilaksanakan
secara memadai, masalah yang dapat menyebabkan kesulitan operasional yang serius mungkin tidak terungkap.
Hal ini dapat terjadi karena penguji pada langkah ini menghabiskan terlalu banyak waktu untuk mengungkap
cacat daripada mengevaluasi kinerja operasional perangkat lunak.
meja kerja
Gambar 10-1 mengilustrasikan meja kerja untuk menjalankan tes dan mencatat hasil. Ini menunjukkan bahwa penguji
menggunakan lingkungan pengujian pada titik ini dalam siklus hidup pengujian. Semakin dekat lingkungan ini
menyerupai lingkungan operasional yang sebenarnya, pengujian menjadi lebih efektif. Jika data pengujian tidak
dibuat sebelumnya dalam proses pengujian, data tersebut perlu dibuat sebagai bagian dari langkah ini. Tes kemudian
dijalankan dan hasilnya dicatat. Laporan pengujian harus menunjukkan apa yang berhasil dan apa yang tidak berhasil.
Laporan pengujian juga harus memberikan pendapat penguji mengenai apakah dia yakin perangkat lunak siap untuk
dioperasikan pada akhir langkah pengujian ini.
Langkah 4: Pengujian Validasi 411
MELAKUKAN MEMERIKSA
operasional
Tes MENGOLAH LAGI
Lingkungan
Tugas 1
Membangun Tes
Data/Skrip
Tes
Rencana
tes
Tugas 2 Menjalankan Tes
Benar? Laporan
Menjalankan
tes
Tes
Program
Perpustakaan
Tugas 3
Catatan
Hasil tes
Sistem/Program
Dokumentasi
Gambar 10-1 Meja kerja untuk menjalankan tes dinamis dan mencatat hasil.
Memasukkan
Pengujian validasi sistem aplikasi memiliki beberapa input baru. Banyak aspek dari proses
perkembangan yang tidak tersedia untuk evaluasi selama fase pengujian. Oleh karena itu, pengujian
selama fase ini harus bergantung pada kecukupan pekerjaan yang dilakukan selama fase sebelumnya.
Hasil yang tersedia selama pengujian validasi meliputi:
Rencana pengujian sistem (dapat mencakup rencana pengujian unit) Data pengujian
dan/atau skrip pengujian
Hasil tes verifikasi sebelumnya

Masukan dari sumber pihak ketiga, seperti operator komputer
Bagian II dari buku ini membahas lingkungan pengujian. Memastikan bahwa lingkungan pengujian
mewakili lingkungan operasional sangat penting untuk pengujian sistem dan pengujian integrasi sistem
perangkat lunak ke sistem lain di lingkungan operasional. Lingkungan pengujian kurang penting untuk
pengujian unit yang dilakukan pengembang dan pengujian integrasi unit. Untuk jenis pengujian itu, yang
penting adalah data pengujian menyertakan kriteria pengujian dunia nyata.
Lingkungan pengujian harus mencakup alat untuk melakukan pengujian secara efektif. Misalnya, sulit untuk
melakukan pengujian regresi kecuali lingkungan pengujian menyertakan alat tangkap/ pemutaran. Demikian juga, sulit
untuk membuat sejumlah besar data pengujian tanpa alat yang dapat membantu menghasilkan kondisi pengujian.
Sedangkan pengujian verifikasi terutama merupakan fungsi manual, pengujian validasi biasanya memerlukan satu atau
lebih alat uji perangkat lunak.
412 Bab 10
Lakukan Prosedur
Langkah ini melibatkan tiga tugas berikut:

1. Membangun data uji.
2. Jalankan tes.
3. Catat hasil tes.
Tugas 1: Membangun Data Uji

Konsep data uji sederhana: untuk memungkinkan penguji membuat kondisi pemrosesan yang representatif. Bagian kompleks
dari pembuatan data uji adalah menentukan transaksi mana yang akan disertakan.
Pengalaman menunjukkan bahwa tidak ekonomis untuk menguji setiap kondisi dalam sistem aplikasi. Pengalaman lebih
lanjut menunjukkan bahwa sebagian besar latihan pengujian kurang dari setengah instruksi komputer. Oleh karena itu,
mengoptimalkan pengujian melalui pemilihan transaksi pengujian yang paling penting adalah aspek kunci dari alat pengujian
data pengujian.
Beberapa alat uji adalah metode terstruktur untuk merancang data uji. Misalnya, bukti kebenaran, analisis aliran data, dan
analisis aliran kontrol semuanya dirancang untuk mengembangkan kumpulan data uji yang ekstensif. Sayangnya, meskipun
sangat efektif, alat ini membutuhkan waktu dan upaya yang signifikan untuk diterapkan, dan hanya sedikit organisasi yang
mengalokasikan anggaran yang cukup. Dengan demikian, personel TI seringkali tidak cukup terlatih untuk menggunakan alat
ini.
Sumber Data Tes/Script Tes

Pengujian validasi yang efektif mengharuskan Anda mengumpulkan semua data/skrip pengujian yang mewakili jenis
pemrosesan yang akan terjadi di lingkungan operasional. Anda dapat menentukan beberapa transaksi ini dengan
mempelajari dokumentasi pengembangan perangkat lunak; transaksi pengujian lainnya mungkin tidak terlihat jelas
dari dokumentasi dan memerlukan penguji yang berpengalaman untuk memastikan bahwa datanya akurat dan
lengkap.
Data/skrip pengujian dapat berasal dari salah satu sumber berikut:
- - Dokumentasi sistem. Penguji dapat menggunakan data uji dan skrip untuk menguji spesifikasi sistem yang
terdokumentasi. Misalnya, jika dokumentasi menunjukkan bahwa pelanggan tidak dapat melebihi batas kredit
yang telah ditetapkan, penguji dapat membuat data pengujian yang akan memvalidasi bahwa pelanggan tidak
dapat membeli barang jika melebihi batas kredit mereka.
- - Gunakan kasus.
Penguji harus mendapatkan dari pengguna aplikasi jenis transaksi yang akan
mereka gunakan. Ini sering disebut sebagai kasus penggunaan.
Dengan kata lain, ada transaksi pengujian yang menguji apakah perangkat lunak akan bekerja untuk memproses
transaksi oleh pengguna saat mereka menggunakan perangkat lunak.
- - Generator uji. Generator uji, seperti namanya, dapat membuat kondisi pengujian untuk digunakan oleh
penguji. Namun, jenis data uji yang dapat dihasilkan tergantung pada kemampuan pembuat data uji.
Kekhawatiran atas generator uji adalah bahwa sebagian besar tidak memiliki kemampuan untuk
menghasilkan data yang menguji hubungan timbal balik seperti tingkat gaji dan dolar pembayaran.
- - Data produksi. Penguji dapat menggunakan file produksi sendiri, atau mereka dapat mengekstrak
data tertentu darinya.
- - Database. Penguji membutuhkan database untuk menguji banyak aplikasi perangkat lunak. Mereka dapat
menggunakan salinan database atau database langsung yang memiliki fitur yang akan memblokir data agar tidak
diperbarui sebagai hasil dari pemrosesan data uji.
- - Profil operasional.
Penguji, bersama dengan pemangku kepentingan sistem perangkat lunak, dapat
menganalisis jenis pemrosesan yang terjadi di lingkungan operasional. Ini sangat berguna saat
menguji kondisi kesalahan atau saat menguji sistem dengan tegangan atau beban.
- - Data/skrip uji yang dibuat secara individual. Penguji dapat membuat data/skrip mereka sendiri berdasarkan
pengetahuan mereka tentang di mana kesalahan paling mungkin terjadi.
Menguji Desain File

Untuk merancang file data pengujian yang memadai, penguji harus memahami standar departemen TI dan
kebijakan terkait lainnya, memasukkan ketentuannya dalam transaksi dan prosedur yang disimulasikan, dan
menyediakan format input dan output untuk semua jenis transaksi yang akan diproses. Untuk mendapatkan
pengetahuan ini, penguji harus meninjau dan menganalisis diagram alur sistem, instruksi pengoperasian, dan
dokumentasi lainnya.
Pengetahuan ini dapat mengingatkan tim penguji terhadap kemungkinan kelemahan sistem yang harus
dirancang transaksi uji uniknya.
Agar efektif, file pengujian harus mencakup transaksi dengan berbagai data valid dan tidak valid—data
valid untuk menguji operasi pemrosesan normal dan data tidak valid untuk menguji kontrol terprogram.
Hanya satu transaksi uji yang harus diproses terhadap setiap catatan induk. Hal ini memungkinkan evaluasi yang
terisolasi dari pengendalian program tertentu dengan memastikan bahwa hasil pengujian tidak akan dipengaruhi oleh
transaksi pengujian lain yang diproses terhadap catatan induk yang sama. Jenis kondisi umum yang akan diuji
meliputi:
- - Pengujian atas transaksi yang terjadi secara normal.

Untuk menguji kemampuan sistem komputer dalam
memproses data yang valid secara akurat, file pengujian harus menyertakan transaksi yang biasanya terjadi.
Misalnya, dalam sistem penggajian, transaksi akan mencakup perhitungan gaji reguler, pembayaran lembur,
dan beberapa jenis pembayaran premi lainnya (seperti pembayaran shift), serta menyiapkan catatan induk
untuk karyawan baru dan memperbarui catatan induk yang ada. untuk karyawan lainnya.
- - Pengujian menggunakan data yang tidak valid. Pengujian keberadaan atau efektivitas pengendalian terprogram
memerlukan penggunaan data yang tidak valid. Contoh pengujian untuk menyebabkan data yang tidak valid
ditolak atau "ditandai" meliputi hal berikut:
- - Memasukkan karakter alfabet ketika karakter numerik diharapkan, dan sebaliknya.
- - Menggunakan nomor rekening atau identitas yang tidak valid.
- - Menggunakan data yang tidak lengkap atau tidak relevan dalam bidang data tertentu atau menghilangkannya sama sekali.
414 Bab 10
- - Memasukkan jumlah negatif ketika hanya jumlah positif yang valid, dan sebaliknya.
- - Memasukkan kondisi tidak logis dalam bidang data yang seharusnya terkait secara logis.
- - Memasukkan kode transaksi atau jumlah yang tidak sesuai dengan kode atau jumlah yang
ditetapkan oleh prosedur operasi atau tabel kendali.
- - Memasuki transaksi ataukondisi yang akan melanggar batas yang ditetapkan oleh hukum
atau prosedur operasi standar.
- - Pengujian untuk melanggar pemeriksaan edit yang telah ditetapkan. Berdasarkan dokumentasi sistem, auditor
harus dapat menentukan rutinitas edit mana yang termasuk dalam program komputer yang akan diuji. Dia
kemudian harus membuat transaksi percobaan untuk melanggar suntingan ini untuk melihat apakah itu benar-
benar ada.
Mendefinisikan Tujuan Desain
Sebelum mengolah data uji, tim uji harus menentukan hasil yang diharapkan. Setiap perbedaan antara
hasil aktual dan yang telah ditentukan menunjukkan kelemahan dalam sistem. Tim penguji harus
menentukan pengaruh kelemahan pada keakuratan data file induk dan pada keandalan laporan dan
produk komputer lainnya.
Salah satu alat uji yang dijelaskan sebelumnya dalam buku ini adalah matriks fungsi/ pengujian. Matriks ini
mencantumkan fungsi perangkat lunak di satu sisi dan tujuan pengujian di sisi lain. Melengkapi matriks ini
akan membantu membuat file kondisi pengujian yang akan mencapai tujuan pengujian untuk setiap fungsi
perangkat lunak. Tujuan lain dari file tes adalah untuk memastikan bahwa cakupan tes yang diinginkan terjadi.
Cakupan mungkin mencakup cakupan persyaratan serta cakupan cabang.
Memasukkan Data Uji

Setelah jenis transaksi pengujian ditentukan, data pengujian harus dimasukkan ke dalam sistem menggunakan
metode yang sama dengan pengguna. Untuk menguji input dan pemrosesan komputer, penguji harus memastikan
bahwa semua data yang diperlukan untuk pemrosesan transaksi telah dimasukkan. Misalnya, jika pengguna
memasukkan data dengan melengkapi template entri data, penguji harus menggunakan template itu juga.
Menerapkan File Uji Terhadap Program Yang

Memperbarui Catatan Master
Ada dua pendekatan dasar untuk menguji program untuk memperbarui database dan/atau file produksi. Pada
pendekatan pertama, salinan rekaman master aktual dan/atau rekaman master simulasi digunakan untuk
menyiapkan file master terpisah. Pada pendekatan kedua, rutinitas khusus yang digunakan selama pengujian akan
menghentikan penguji memperbarui catatan produksi.
Untuk menggunakan pendekatan pertama, tim pengujian harus memiliki bagian dari file induk organisasi yang
disalin untuk membuat file master pengujian. Dari cetakan file ini, tim memilih catatan yang cocok untuk pengujian.
Penguji kemudian memperbarui file pengujian dengan data yang valid dan tidak valid dengan menggunakan program
pemrosesan transaksi organisasi. Penguji bisa
mensimulasikan catatan induk dengan menyiapkan dokumen sumber dan memprosesnya dengan program yang digunakan
organisasi untuk menambahkan catatan baru ke file induknya. Prosedur untuk menggunakan rekaman yang disimulasikan
sebagai data uji sama dengan untuk rekaman yang disalin.
Keuntungan menggunakan catatan simulasi adalah bahwa mereka dapat disesuaikan untuk kondisi tertentu dan mereka
menghilangkan kebutuhan untuk mencari dan menyalin catatan organisasi yang sesuai.
Keuntungan ini biasanya diimbangi ketika banyak catatan diperlukan karena pembuatannya dapat menjadi rumit dan memakan
waktu jika dibandingkan dengan prosedur yang relatif sederhana untuk menyalin bagian dari file induk organisasi.
Seringkali, pendekatan yang paling praktis adalah dengan menggunakan file master uji yang merupakan kombinasi dari
rekaman master yang disalin dan disimulasikan. Dalam pendekatan ini, rekaman yang disalin digunakan bila memungkinkan dan
rekaman yang disimulasikan hanya digunakan jika diperlukan untuk menguji kondisi yang tidak ditemukan dalam rekaman yang
disalin.
Dengan menggunakan rekaman master yang disalin dan disimulasikan dalam file pengujian terpisah,
penguji menghindari komplikasi dan bahaya menjalankan data pengujian dalam pemrosesan reguler yang dijalankan terhadap
file master saat ini. Kerugian dari rekaman yang disalin dan disimulasikan adalah bahwa program komputer harus dimuat dan
peralatan disiapkan dan dioperasikan hanya untuk tujuan audit, sehingga melibatkan biaya tambahan.
Membuat dan Menggunakan Data Uji
Berikut ini adalah proses yang disarankan untuk membuat dan menggunakan data uji:
1. Mengidentifikasi sumber daya tes. Pengujian menggunakan data uji dapat menjadi proses yang luas atau terbatas
seperti yang diinginkan. Sayangnya, banyak pemrogram mendekati pembuatan data uji dari perspektif "kami akan
melakukan pekerjaan sebaik mungkin" dan kemudian mulai mengembangkan transaksi uji. Ketika waktu berakhir,
pengujian selesai. Pendekatan yang direkomendasikan menyarankan bahwa jumlah sumber daya yang dialokasikan
untuk membuat data uji harus ditentukan dan kemudian dikembangkan proses yang menciptakan data uji paling
penting dalam waktu yang ditentukan untuk membuat data uji.
2. Mengidentifikasi kondisi pengujian. Penguji harus menggunakan matriks fungsi/pengujian untuk mengidentifikasi kondisi yang akan
diuji.
3. Kondisi tes peringkat. Jika sumber daya terbatas, penggunaan maksimum sumber daya tersebut akan diperoleh
dengan menguji kondisi pengujian yang paling penting. Tujuan pemeringkatan adalah untuk mengidentifikasi
kondisi pengujian prioritas tinggi yang harus diuji terlebih dahulu.
Peringkat tidak berarti bahwa kondisi pengujian peringkat rendah tidak akan diuji. Pemeringkatan dapat
digunakan untuk dua tujuan: pertama, untuk menentukan kondisi mana yang harus diuji terlebih dahulu; dan
kedua, dan sama pentingnya, untuk menentukan jumlah sumber daya yang dialokasikan untuk setiap kondisi
pengujian. Misalnya, jika pengujian deduksi FICA adalah kondisi dengan peringkat yang relatif rendah, hanya satu
transaksi pengujian yang dapat dibuat untuk menguji kondisi tersebut, sedangkan untuk kondisi pengujian
dengan peringkat yang lebih tinggi, beberapa transaksi pengujian dapat dibuat.
4. Pilih kondisi untuk pengujian. Berdasarkan peringkat, kondisi yang akan diuji harus dipilih. Pada titik
ini, kondisinya harus sangat spesifik. Misalnya, "menguji FICA" adalah kondisi yang wajar untuk
mengidentifikasi dan memberi peringkat, tetapi untuk
416 Bab 10
menciptakan kondisi pengujian khusus itu terlalu umum. Tiga situasi pengujian dapat diidentifikasi—seperti
karyawan yang pendapatannya dari tahun ke tahun melebihi pemotongan FICA maksimum; seorang
karyawan yang pendapatan periode berjalannya akan melebihi perbedaan antara pendapatan tahun ini dan
pengurangan maksimum; dan seorang karyawan yang pendapatannya dari tahun ke tahun lebih dari satu
jumlah periode pembayaran di bawah potongan FICA maksimum. Setiap situasi pengujian harus
didokumentasikan dalam matriks pengujian. Ini adalah versi rinci dari matriks pengujian yang dimulai selama
fase persyaratan.
5. Tentukan hasil pemrosesan yang benar. Hasil pemrosesan yang benar untuk setiap situasi pengujian harus
ditentukan. Setiap situasi pengujian harus diidentifikasi dengan nomor unik, dan kemudian dibuat log dari
hasil yang benar untuk setiap kondisi pengujian. Jika sistem tersedia untuk secara otomatis memeriksa
setiap situasi pengujian, formulir khusus mungkin diperlukan karena informasi ini mungkin perlu dikonversi
ke media yang dapat dibaca mesin.
Waktu yang tepat untuk menentukan hasil pemrosesan yang benar adalah sebelum
transaksi pengujian dibuat. Langkah ini membantu menentukan kewajaran dan kegunaan
transaksi pengujian. Proses tersebut juga dapat menunjukkan apakah ada cara untuk
memperluas efektivitas transaksi uji, dan apakah kondisi yang sama telah diuji oleh
transaksi lain.
6. Buat transaksi percobaan. Metode pembuatan transaksi yang dapat dibaca mesin
bervariasi berdasarkan aplikasi dan aturan pengujian. Metode paling umum untuk
membuat transaksi uji meliputi:
- - Entri kunci
- - Generator uji-data
- - Formulir masukan yang disiapkan pengguna
- - Data produksi
7. Persyaratan uji dokumen. Baik situasi pengujian maupun hasil pengujian harus
didokumentasikan.
8. Melakukan tes. Penguji harus menjalankan sistem yang dapat dieksekusi menggunakan kondisi pengujian atau
lingkungan produksi yang disimulasikan.
9. Verifikasi dan perbaiki hasil tes. Hasil pengujian harus diverifikasi dan koreksi yang diperlukan
untuk program yang dilakukan. Masalah yang terdeteksi sebagai hasil pengujian tidak hanya
disebabkan oleh cacat sistem, tetapi juga karena cacat data pengujian. Penguji harus menyadari
kedua situasi.
Contoh Aplikasi Penggajian

Dalam membuat dua ulasan tentang sistem penggajian sipil otomatis, Kantor Akuntansi Umum AS menggunakan
file uji untuk menguji program komputer agen untuk memproses data gaji dan cuti. Kasus ini menunjukkan
pendekatan pengembangan file uji mereka.
Pertama, semua dokumentasi yang tersedia ditinjau untuk bagian manual dan otomatis dari setiap sistem.
Untuk memahami operasi manual, mereka mewawancarai penggajian
supervisor dan juru tulis, meninjau undang-undang dan peraturan yang berkaitan dengan gaji dan cuti, dan
membiasakan diri dengan prosedur operasi penggajian standar. Untuk bagian otomatis dari setiap sistem,
mereka mewawancarai perancang sistem dan pemrogram dan meninjau dokumentasi sistem dan program
serta prosedur operasi.
Setelah memperoleh pengetahuan kerja dari setiap sistem, mereka memutuskan untuk menguji program komputer yang
digunakan untuk memperbarui catatan induk penggajian dan yang digunakan untuk menghitung gaji dua mingguan dan hak
cuti. Meskipun mereka terutama memperhatikan program khusus ini, mereka memutuskan bahwa program lain yang
digunakan dalam siklus pemrosesan penggajian dua mingguan normal (seperti program untuk menghasilkan laporan riwayat
gaji dan cuti, catatan cuti, dan laporan tabungan) juga harus diuji untuk melihat bagaimana mereka akan menangani data uji.
Mereka kemudian merancang file uji simulasi transaksi gaji dan cuti untuk menguji efektivitas
pengendalian internal, kepatuhan terhadap undang-undang dan peraturan yang berlaku, dan kecukupan
prosedur operasi penggajian standar. File uji termasuk transaksi yang terdiri dari data yang valid dan tidak
valid. Transaksi ini didasarkan pada prosedur dan peraturan yang ditentukan dan dirancang untuk memeriksa
efektivitas pengendalian internal dalam proses penggajian setiap instalasi. Mereka menggunakan satu
transaksi untuk setiap master record yang dipilih.
Metode terbaik untuk mendapatkan catatan induk penggajian yang sesuai untuk pengujian, mereka memutuskan, adalah dengan
menggunakan salinan catatan induk yang sebenarnya, dilengkapi dengan catatan simulasi yang disesuaikan untuk kondisi pengujian yang
tidak ditemukan dalam catatan yang disalin.
Oleh karena itu, mereka memperoleh duplikat dari file induk penggajian masing-masing agen dan
memiliki bagian yang dicetak dalam salinan yang dapat dibaca. Dari cetakan ini, mereka memilih catatan master tertentu untuk
digunakan pada setiap transaksi pengujian. Ketika tidak ada catatan yang disalin yang muncul pada cetakan yang sesuai dengan
spesifikasi transaksi tertentu, mereka membuat catatan induk yang disimulasikan dengan menyiapkan dokumen sumber dan
memprosesnya dengan program yang digunakan oleh setiap instalasi untuk menambahkan catatan bagi karyawan baru ke file
induknya. Mereka kemudian menambahkan rekaman simulasi ke rekaman yang disalin untuk membuat file master pengujian.
Mereka selanjutnya menyiapkan kertas kerja yang dimasukkan, untuk setiap transaksi
pengujian, nomor kontrol yang ditetapkan untuk transaksi, jenis dokumen masukan yang akan digunakan, dan
sifat serta tujuan pengujian. Mereka telah menentukan hasil akhir yang benar untuk semua transaksi
pengujian dan mencatat hasil ini di kertas kerja untuk dibandingkan dengan hasil aktual.
Dengan bantuan dari personel kantor penggajian, mereka selanjutnya mengkodekan transaksi uji ke dokumen
sumber. Data kemudian dimasukkan kunci dan kunci diverifikasi. Mereka kemudian memproses data pengujian
terhadap program penggajian agen aktual dan membandingkan hasil pengujian dengan hasil yang telah ditentukan
untuk melihat apakah ada perbedaan.
Mereka menemukan bahwa kedua sistem menerima dan memproses beberapa transaksi uji yang tidak valid yang
seharusnya ditolak atau ditandai oleh kontrol komputer terprogram. Kontrol manual alternatif tidak ada atau kurang
efektif sepenuhnya karena dapat dilewati atau dikompromikan melalui penipuan, pengabaian, atau kesalahan yang
tidak disengaja. Mereka merekomendasikan agar sistem kontrol otomatis diperkuat untuk memastikan penggajian
yang akurat dan melindungi pemerintah dari pembayaran yang tidak semestinya.
Salinan kertas kerja mereka menguraikan kondisi pengujian diilustrasikan pada Gambar 10-2.
BAGAIMANA SISTEM DENGAN KONTROL YANG EFEKTIF
AKAN MENANGANI TRANSAKSI
Potong kembali ke maksimum

Menolak dengan pasti
menghitung dengan benar

Secara otomatis
Secara otomatis
Proses tanpa
menyesuaikan cuti
Kesalahan cetak
yang diizinkan
TES
keadaan
pengurangan
catatan
jumlah
Menolak
pesan
TRANSAKSI TUJUAN
1. Tinggalkan wajib bidang Untuk menentukan apakah sistem akan menerima catatan x x
kosong pada master induk dengan data penting yang hilang. Jika data yang hilang
karyawan baru catatan. akan menyebabkan pembayaran yang salah, catatan induk
harus ditolak dengan peringatan yang sesuai; jika data yang
hilang hanya untuk tujuan administratif, kondisi tersebut
harus ditandai dengan pesan kesalahan.
2. Masukkan salah kode, Untuk menentukan apakah sistem akan menerima data yang x x
seperti amal, asuransi tidak valid ke dalam catatan induk karyawan. Program harus
jiwa, mencetak pesan kesalahan untuk mengidentifikasi data yang
iuran serikat pekerja, perkawinan tidak valid dan menolak pemrosesan lebih lanjut dari
transaksi tersebut.
status, dll. (Catatan: Satu
kode yang salah per
catatan induk.)
3. Masukkan yang tidak valid Untuk menentukan apakah sistem akan menerima x x
cuti tahunan kategori cuti tahunan yang tidak valid. Peraturan federal
berdarah. telah menetapkan kategori cuti tahunan sebagai 4, 6,
atau 8, tergantung pada jumlah layanan yang dapat
dikreditkan.
Gambar 10-2 Transaksi penggajian yang umum untuk disertakan dalam file pengujian.

Secara otomatis
Secara otomatis
Proses tanpa
menyesuaikan cuti
Kesalahan cetak
yang diizinkan
TES
keadaan
pengurangan
catatan
jumlah
Menolak
pesan
TRANSAKSI TUJUAN
4. Mengubah bidang di Untuk menentukan apakah mungkin untuk x x

master rec- tidak aktif mengubah bidang dalam catatan induk tidak aktif
pesanan. dan apakah ada kontrol yang memadai atas
perubahan tersebut. Pemrosesan arsip tidak aktif
harus dipisahkan dari pemrosesan arsip aktif yang
normal untuk menghilangkan kemungkinan
pembayaran gaji yang belum diterima atau
manipulasi arsip untuk orang yang tidak berstatus
gaji.
5. Mengubah pekerjaan- Untuk menentukan apakah sistem akan menolak

cuti tahunan ee pembaruan yang tidak valid. Kategori cuti tahunan
kategori sebelum didasarkan pada jumlah layanan yang dapat dikreditkan
akan diubah. yang dimiliki seorang karyawan, dihitung dari tanggal
perhitungan layanan karyawan. Pegawai dengan masa
kerja kurang dari 3 tahun termasuk dalam kategori 4;
karyawan dengan masa kerja 3 sampai 15 tahun termasuk
dalam kategori 6; karyawan dengan masa kerja lebih dari
15 tahun termasuk dalam kategori 8.
Program harus menolak setiap upaya untuk mengubah
kategori cuti sebelum waktunya diubah.
Gambar 10-2 (lanjutan)



Secara otomatis
Secara otomatis
Proses tanpa
menyesuaikan cuti
Kesalahan cetak
yang diizinkan
keadaan
pengurangan
catatan
TES
jumlah
Menolak
pesan
TRANSAKSI TUJUAN
6. Promosikan seorang jenderal Untuk menentukan apakah sistem menolak transaksi x x

jadwal (GS) em- ployee yang tidak valid. Peraturan federal menyatakan bahwa
di atas kelas 5 sebelum karyawan GS di atas kelas 5 harus berada di kelas
satu tahun di kelas telah setidaknya satu tahun sebelum mereka dapat
berlalu. dipromosikan.
7. Berikan karyawan GS gaji yang Untuk menentukan bagaimana sistem menangani transaksi x
sesuai dengan tingkatannya ini. Peraturan federal menyatakan bahwa karyawan GS
meningkat sebelum satu harus berada di kelas setidaknya satu tahun sebelum
memenuhi syarat untuk kenaikan gaji di dalam kelas.
tahun di kelas telah berlalu.
Sistem harus "menandai" transaksi sebagai peningkatan
langkah kualitas (yang memiliki efek yang sama seperti
peningkatan dalam kelas tetapi dapat terjadi tanpa
karyawan tersebut naik kelas selama satu tahun).
8. Mengubah pekerjaan- ee Untuk menentukan apakah sistem menerima data yang x x

grade atau gaji tidak kompatibel. Program harus memiliki kontrol gaji dan
tahunan sehingga kelas yang akan menolak transaksi jenis ini dari
grade/step dan tingkat pemrosesan lebih lanjut.
gaji tahunan tidak
kompatibel.



Secara otomatis
Secara otomatis
Proses tanpa
menyesuaikan cuti
Kesalahan cetak
yang diizinkan
keadaan
pengurangan
catatan
TES
jumlah
Menolak
pesan
TRANSAKSI TUJUAN
9. Mengubah karyawan Untuk menentukan apakah kategori cuti tahunan x

perhitungan layanan diubah dengan benar, dengan pesan yang dicetak
tanggal untuk menunjukkan untuk menunjukkan perubahan tersebut. Jika
bahwa kategori cuti akan kategori cuti tidak diubah secara otomatis, pesan
berubah.
harus dicetak.
10. Bayar tidak aktif Untuk menentukan apakah sistem akan menghitung x x
karyawan. pembayaran untuk karyawan yang
tidak aktif (karyawan yang telah dipisahkan tetapi
catatannya disimpan dalam file induk yang sama
dengan yang digunakan untuk karyawan aktif).
11. Bayar tidak ada Untuk menentukan apakah sistem akan x x

karyawan. menghitung gaji untuk karyawan tanpa
catatan dalam file induk.
12. Masukkan dua kartu waktu Untuk menentukan apakah sistem akan x x
dan kehadiran untuk menghitung gaji dua kali untuk karyawan
karyawan yang sama. yang sama.
13. Bayar karyawan GS Untuk menentukan apakah sistem x x

untuk 80 jam kerja menolak hak WB untuk karyawan GS.
pada shift kedua hak
untuk
papan upah (WB)
karyawan.



Secara otomatis
Secara otomatis
Proses tanpa
menyesuaikan cuti
Kesalahan cetak
yang diizinkan
keadaan
pengurangan
catatan
TES
jumlah
Menolak
pesan
TRANSAKSI TUJUAN
14. Membayar karyawan GS Sama seperti di atas. x x

untuk 80 jam kerja
dengan hak shift ketiga-
untuk WB karyawan.
15. Bayar karyawan WB untuk 80 Untuk menentukan apakah sistem x x

jam kerja pada shift menolak hak GS untuk karyawan WB.
malam yang berbeda-
hak dasar untuk
seorang karyawan GS.
16. Membayar karyawan Untuk memverifikasi keakuratan perhitungan x

WB untuk 20 jam pembayaran premi (lembur). Uang lembur adalah 1 dan
lembur. 1/2 kali gaji reguler.
17. Bayar karyawan GS untuk Sama seperti di atas. Premi = 10 persen. x

20 jam pembayaran
diferensial malam.
18. Bayar karyawan WB Sama seperti di atas. Premi = 7 1/2 x

selama 80 jam pada persen.
giliran kedua.
19. Bayar karyawan WB selama Sama seperti di atas. Premi = 10 persen. x

80 jam pada shift ketiga.



Secara otomatis
Secara otomatis
Proses tanpa
menyesuaikan cuti
Kesalahan cetak
yang diizinkan
keadaan
pengurangan
catatan
TES
jumlah
Menolak
pesan
TRANSAKSI TUJUAN
20. Membayar karyawan GS Sama seperti di atas. Pembayaran liburan adalah gaji x
untuk 8 jam gaji liburan. reguler dua kali lipat.
21. Bayar karyawan WB Sama seperti di atas. x

untuk 8 jam gaji
liburan.
22. Membayar karyawan GS untuk Sama seperti di atas. Premi hari Minggu adalah 25 persen x
8 jam pembayaran hari dari gaji reguler jika hari Minggu adalah hari kerja yang
Minggu (untuk pekerjaan hari dijadwalkan secara rutin.
Minggu yang tidak
kerja lembur).

untuk 8 jam gaji hari
Minggu.
24. Bayar karyawan GS Sama seperti di atas. x

untuk 10 jam
pembayaran lingkungan
dengan premi berikut:
a) 4 persen
b) 8 persen
c) 25 persen
d) 50 persen



Secara otomatis
Secara otomatis
Proses tanpa
menyesuaikan cuti
Kesalahan cetak
yang diizinkan
keadaan
pengurangan
catatan
TES
jumlah
Menolak
pesan
TRANSAKSI TUJUAN

untuk 10 jam
pembayaran lingkungan
dengan premi berikut:
a) 4 persen
b) 8 persen
c) 25 persen
d) 50 persen
26. Membayar karyawan GS-1, Untuk memverifikasi keakuratan perhitungan x
2, 3, 4, 5, 6, atau 7 pembayaran premi. Untuk karyawan GS yang tingkat
untuk 10 jam lembur. gaji pokoknya tidak melebihi gaji
GS-10/1, tingkat lembur adalah 1 dan 1/2 kali
tingkat gaji pokok.
27. Membayar karyawan Sama seperti di atas. Untuk karyawan GS yang x

GS-10, 11, 12, atau 13 tingkat gaji pokoknya sama dengan atau melebihi
untuk 10 jam lembur. tarif GS-10/1, tarif lembur adalah satu dan 1/2
kali tarif per jam untuk GS-10/1.



Secara otomatis
Secara otomatis
Proses tanpa
menyesuaikan cuti
Kesalahan cetak
yang diizinkan
keadaan
pengurangan
catatan
TES
jumlah
Menolak
pesan
TRANSAKSI TUJUAN
28. Bayar GS-14 Untuk menguji batasan gaji maksimum. x x

karyawan cukup Pembayaran tambahan, seperti lembur,
uang lembur untuk perbedaan malam, hari libur dan pembayaran
melebihi maksimal hari Minggu, dapat dibayarkan sejauh itu tidak
gaji ibu menyebabkan pembayaran agregat untuk
keterbatasan. periode dua mingguan melebihi tarif GS-15/10.
Program ini harus memotong kembali
pembayaran maksimum ini.
29. Bayar GS-14 Sama seperti di atas. Program tidak boleh x

karyawan cukup memotong gaji lingkungan karena tidak tunduk
gaji lingkungan pada batasan gaji maksimum.
melebihi gaji
maksimum
keterbatasan.
30. Bayar premi yang cukup Sama seperti di atas. Program tidak boleh x
kepada karyawan WB memotong gaji karena karyawan WB tidak
membayar melebihi memiliki batasan gaji maksimum.
gaji maksimum
keterbatasan.
31. Bayar karyawan GS Untuk menentukan apakah sistem akan membayar kurang x x
untuk satu jam gaji dari pembayaran liburan minimum dua jam.
liburan.



Secara otomatis
Secara otomatis
Proses tanpa
menyesuaikan cuti
Kesalahan cetak
yang diizinkan
keadaan
pengurangan
catatan
TES
jumlah
Menolak
pesan
TRANSAKSI TUJUAN
32. Bayar karyawan WB Sama seperti di atas. x x

selama satu jam
bayar Liburan.
33. Bayar karyawan GS untuk Untuk menentukan apakah sistem membatasi pembayaran hari x x
40 jam gaji hari Minggu. Minggu hingga maksimum 32 jam yang diperbolehkan.
34. Bayar karyawan WB Untuk memverifikasi keakuratan pembayaran premi. x

selama 80 jam pada Peraturan federal menyatakan bahwa upah lembur untuk seorang
shift kedua dan 10 karyawan yang secara teratur bekerja pada shift
jam untuk lembur kedua atau ketiga akan dihitung masing-masing sebesar 1
memasuki shift ketiga. dan 1/2 kali tingkat shift kedua atau ketiga.
35. Membayar karyawan WB Sama seperti di atas. x

selama 80 jam pada shift
ketiga dan 10 jam untuk
lembur pada shift pertama.
36. Mengisi penuh waktu Untuk menentukan apakah cuti sakit dan cuti x
karyawan untuk 80 tahunan akan bertambah ketika seorang karyawan
jam cuti tanpa penuh waktu membebankan 80 jam LWOP. Kredit
cuti sakit harus dikurangi 4 jam, dan kredit cuti
bayaran (LWOP).
tahunan harus dikurangi 4, 6, atau 8 jam, tergantung
pada kategori cuti tahunan.



Secara otomatis
Secara otomatis
Proses tanpa
menyesuaikan cuti
Kesalahan cetak
yang diizinkan
keadaan
pengurangan
catatan
TES
jumlah
Menolak
pesan
TRANSAKSI TUJUAN
37. Mengisi penuh waktu Untuk menentukan apakah kelebihan cuti x x x

karyawan untuk lebih tahunan dibebankan ke LWOP. (Sistem harus secara
cuti tahunan dari otomatis mengurangi gaji karyawan untuk LWOP.)
karyawan memiliki.
38. Mengisi penuh waktu Untuk menentukan apakah kelebihan cuti sakit x x x
karyawan untuk lebih dibebankan pada cuti tahunan atau LWOP. (Sistem
cuti sakit daripada yang harus secara otomatis menyesuaikan catatan cuti dan
dimiliki karyawan. mengurangi gaji untuk LWOP, jika diperlukan.)
39. Mengisi penuh waktu Untuk menentukan apakah sistem akan memotong x x
karyawan untuk 99 kembali hingga maksimum 80 jam untuk pembayaran
jam tahunan reguler dalam periode pembayaran.
berangkat (19 jam
lebih dari periode dua
mingguan reguler).
40. Mengisi penuh waktu Sama seperti di atas. x x

karyawan untuk 99
jam cuti sakit.



Secara otomatis
Secara otomatis
Proses tanpa
menyesuaikan cuti
Kesalahan cetak
yang diizinkan
keadaan
pengurangan
catatan
TES
jumlah
Menolak
pesan
TRANSAKSI TUJUAN
41. Mengisi penuh waktu Sama seperti di atas. Total jam kerja dan cuti tidak x x
karyawan untuk 80 boleh melebihi 80 dalam satu periode pembayaran.
jam gaji reguler dan 80
jam
cuti tahunan dalam periode
pembayaran yang sama.
42. Mengisi penuh waktu Untuk menentukan apakah sistem menandai cuti militer x
karyawan untuk lebih dari 120 jam. Peraturan federal menyatakan bahwa seorang
cukup jam cuti karyawan tidak dapat mengenakan biaya lebih dari 120 jam untuk
militer ke cuti militer dalam satu tahun gaji.
melebihi 120 jam Karena ada pengecualian-pengecualian tertentu, sistem
total. harus mengingatkan pegawai penggajian tentang
kelebihan dan tidak boleh menolak atau mengurangi

transaksi.
43. Buat lump-sum Untuk menentukan apakah sistem secara tepat x x

pembayaran cuti tahunan mengecualikan kelebihan cuti tahunan dalam
kepada karyawan terpisah pembayaran cuti lump-sum.
yang melebihi saldo cuti
tahunan.



Secara otomatis
Secara otomatis
Proses tanpa
menyesuaikan cuti
Kesalahan cetak
yang diizinkan
keadaan
pengurangan
catatan
TES
jumlah
Menolak
pesan
TRANSAKSI TUJUAN
44. Bayar karyawan paruh Untuk menentukan apakah sistem memberikan cuti tahunan x
waktu GS untuk 32 jam dan cuti sakit untuk karyawan paruh waktu dengan benar.
reguler Untuk setiap 20 jam kerja, seorang karyawan paruh waktu
membayar.
menerima satu jam cuti sakit. Jika dalam kategori cuti 4,
seorang karyawan membutuhkan 20 jam kerja untuk
mendapatkan satu jam cuti tahunan; jika dalam kategori cuti
6, karyawan membutuhkan 15 jam kerja untuk mendapatkan
satu jam cuti tahunan; dan jika dalam kategori cuti 8,
karyawan tersebut membutuhkan 10 jam kerja untuk
mendapatkan satu jam cuti tahunan.
45. Buat lump-sum Untuk menentukan apakah sistem akan melakukan x x

pembayaran cuti tahunan- pembayaran cuti tahunan sekaligus kepada karyawan
ment kepada karyawan aktif. Pembayaran ini harus dilakukan hanya untuk
yang aktif. karyawan yang terpisah.

430 Bab 10
Membuat Data Uji untuk Pengujian Tegangan/Beban
Tujuan dari stress/load testing adalah untuk memverifikasi bahwa sistem dapat bekerja dengan baik ketika
program internal atau batasan sistem telah terlampaui. Ini mungkin mengharuskan volume besar transaksi
dimasukkan selama pengujian.
Berikut ini adalah langkah-langkah yang disarankan untuk menentukan data uji yang diperlukan untuk pengujian tegangan/beban:
1. Mengidentifikasi input data yang digunakan oleh program. Metode yang disukai untuk mengidentifikasi
keterbatasan adalah dengan mengevaluasi data. Setiap elemen data harus ditinjau untuk menentukan
apakah itu menimbulkan batasan sistem. Ini adalah metode yang lebih mudah daripada mencoba
mengevaluasi program. Metode ini juga membantu dalam membedakan antara batasan sistem dan
program. Keuntungan lain adalah bahwa data mungkin perlu dievaluasi hanya sekali, daripada
mengevaluasi banyak program individu.
2. Identifikasi data yang dibuat oleh program. Ini akan menjadi elemen data yang tidak dimasukkan ke dalam sistem
tetapi dimasukkan dalam catatan data internal atau keluaran. Jika penguji mengetahui data input dan output,
mereka dapat dengan mudah mengidentifikasi elemen data yang baru dibuat.
3. Tantang setiap elemen data untuk kemungkinan keterbatasan. Penguji harus mengajukan pertanyaan
berikut tentang setiap elemen data. J Ya jawaban untuk salah satu pertanyaan berarti batasan telah
diidentifikasi.
- - Bisakah nilai data dalam bidang melebihi ukuran elemen data ini?
- - Apakah nilai dalam bidang data terakumulasi?
- - Apakah data disimpan sementara di komputer?
- - Apakah informasi dalam elemen data disimpan dalam program sampai transaksi berikut
dimasukkan?
- - Jika elemen data mewakili entitas akuntansi, apakah nomor yang digunakan untuk mengidentifikasi entitas akuntansi
itu sendiri memberikan batasan di masa mendatang, seperti menggunakan bidang satu karakter untuk
mengidentifikasi distrik penjualan?
4. Batasan dokumen. Dokumentasi membentuk dasar untuk pengujian volume. Setiap batasan sekarang harus
dievaluasi untuk menentukan tingkat pengujian yang diperlukan.
5. Lakukan pengujian volume. Pengujian mengikuti sembilan langkah yang diuraikan di bagian sebelumnya,
“Membuat dan Menggunakan Data Pengujian.”
Membuat Skrip Tes

Beberapa karakteristik scripting berbeda dengan pengembangan data batch test. Perbedaan tersebut
antara lain sebagai berikut:
- - Prosedur entri data yang diperlukan. Prosedur pengujian mengambil signifikansi yang
lebih besar dalam
scripting. Orang yang menggunakan skrip perlu mengetahui detail cara memasukkan transaksi melalui
terminal. Ini mungkin lebih kompleks daripada sekadar membuat kondisi pengujian.
-- Penggunaan paket perangkat lunak. Scripting adalah tugas yang sangat sulit dan kompleks untuk dilakukan secara
manual, terutama ketika script harus diulang beberapa kali. Oleh karena itu, sebagian besar penguji menggunakan
jenis paket perangkat lunak pengambilan/pemutaran, yang memungkinkan penangkapan transaksi saat
dimasukkan melalui terminal, dan kemudian mengulanginya saat skrip digunakan kembali. Ada banyak dari ini di
pasar, meskipun mereka ditujukan terutama pada mainframe IBM.
- - Urutanperistiwa. Script memerlukan urutan transaksi. Dalam sistem batch, pengurutan sering
ditangani dengan menyortir selama eksekusi sistem; namun, dengan skrip, urutannya harus
ditentukan sebelumnya.
- - Hentikan prosedur. Pengujian batch berlanjut sampai batch selesai atau pemrosesan berhenti secara
tidak normal. Skrip mungkin dapat dilanjutkan, tetapi hasilnya tidak akan berarti; oleh karena itu, skrip
harus menunjukkan kapan harus berhenti, atau jika kondisi tertentu terjadi, ke mana harus pergi
dalam skrip untuk melanjutkan pengujian.
Untuk mengembangkan, menggunakan, dan memelihara skrip pengujian, penguji harus melakukan lima langkah berikut:
1. Tentukan tingkat pengujian.

2. Mengembangkan skrip tes.
3. Jalankan skrip pengujian.
4. Analisis hasilnya.
5. Memelihara skrip pengujian.
Menentukan Tingkat Pengujian

Ada lima level pengujian untuk skrip, sebagai berikut:
- - Skrip unit. Mengembangkan skrip untuk menguji unit/modul tertentu.
- - Skrip pseudo-konkurensi. Mengembangkan skrip untuk menguji ketika dua atau lebih pengguna
mengakses file yang sama pada waktu yang sama.
- - skrip integrasi. Menentukan bahwa berbagai modul dapat dihubungkan dengan benar.
- - Skrip
regresi. Menentukan bahwa bagian sistem yang tidak berubah tetap tidak berubah ketika sistem
diubah. (Catatan: Ini biasanya dilakukan dengan informasi yang ditangkap pada sistem perangkat
lunak pengambilan/pemutaran.)
- - Skripstres/kinerja. Menentukan apakah sistem akan bekerja dengan benar ketika
ditekankan pada kapasitasnya.
Mengembangkan Skrip Tes

Biasanya, alat tangkap/pemutaran digunakan untuk mengembangkan skrip pengujian.
Pengembangan naskah melibatkan beberapa pertimbangan, sebagai berikut:
432 Bab 10
Program yang akan diuji Memproses pertanyaan

Lingkungan operasi Pustaka program
Komponen skrip Status/isi file
Organisasi naskah Pertimbangan keamanan Mulai dan
Entri skrip terminal Entri otomatis transaksi hentikan pertimbangan Prosedur
skrip Entri manual transaksi skrip masuk
Pengeditan transaksi Prosedur keluar
Opsi pengaturan
Navigasi transaksi Navigasi menu
Sumber transaksi Prosedur keluar
File yang terlibat Opsi permintaan ulang
Input dan output terminal komunikasi API
Lingkungan operasi online
Terminal tunggal versus banyak terminal
Pengaturan tanggal
Ketergantungan tanggal dan waktu Pertanyaan
Inisialisasi file Inisialisasi
versus pembaruan Organisasi pengujian unit
layar Inisialisasi aman
Organisasi pengujian semu-bersamaan
Pemulihan file
Organisasi pengujian integrasi
Opsi kata sandi
Organisasi uji regresi
Perbarui opsi
Penguji dapat menggunakan Kertas Kerja 10-1 sebagai bantuan untuk mengembangkan skrip pengujian. Tabel 10-1 merangkum
strategi pengembangan.
Tabel 10-1 Strategi Pengembangan Skrip
TES LAJANG GANDA LAJANG GANDA

TINGKAT TERMINAL TRANSAKSI TRANSAKSI TERMINAL
Satuan x x
bersamaan x x
Integrasi x x
Regresi x x
Menekankan x x
Menjalankan Skrip Tes

Penguji dapat menjalankan skrip pengujian baik secara manual atau dengan menggunakan alat tangkap/pemutaran. Pertimbangan yang
harus disertakan saat menggunakan alat tangkap/pemutaran meliputi hal berikut:
Pengaturan lingkungan
Pustaka program
Status/isi file
Tanggal dan waktu
Beberapa mode kedatangan terminal

Ketergantungan serial (cross-terminal) Opsi
pemrosesan
Deteksi kios
Sinkronisasi berbagai jenis data input Volume input
Tingkat kedatangan input
CATATAN Enggan untuk menggunakan skrip secara ekstensif kecuali jika alat perangkat lunak menggerakkan skrip.
Menganalisis Hasil
Setelah menjalankan skrip pengujian, penguji harus membandingkan hasil aktual dengan hasil yang diharapkan.
Banyak dari ini seharusnya dilakukan selama eksekusi skrip, menggunakan instruksi operator yang disediakan.
Perhatikan bahwa jika alat perangkat lunak pengambilan/pemutaran digunakan, analisis akan lebih ekstensif setelah
eksekusi. Analisis harus mencakup hal-hal berikut:
- - Komponen sistem
- - Keluaran terminal (layar)
- - Isi file
- - Variabel lingkungan, seperti
- - Status log
- - Data kinerja (hasil stres)
- - Keluaran di layar
- - Urutan pemrosesan keluaran
- - Kesesuaian layar dengan spesifikasi
- - Kemampuan untuk memproses tindakan
- - Kemampuan untuk menelusuri data

434 Bab 10
Memelihara Skrip Tes

Setelah dikembangkan, skrip pengujian perlu dipelihara agar dapat digunakan selama
pengembangan. Area berikut harus dimasukkan ke dalam prosedur pemeliharaan skrip:
Pengidentifikasi untuk setiap
skrip Tujuan skrip
Program/unit diuji dengan skrip ini

Versi data pengembangan yang digunakan untuk menyiapkan skrip Kasus uji
termasuk dalam skrip
Tugas 2: Jalankan Tes

Pengujian validasi yang efektif harus didasarkan pada rencana pengujian yang dibuat jauh lebih awal dalam siklus hidup.
Pengujian fase pengujian merupakan puncak dari pekerjaan sebelumnya yang mempersiapkan fase ini. Tanpa persiapan ini,
tes mungkin tidak ekonomis dan tidak efektif.
Berikut ini dijelaskan beberapa metode pengujian suatu sistem aplikasi. Penguji dapat
menggunakan Kertas Kerja 10-2 untuk melacak kemajuan mereka.
- - Manual, regresi, dan pengujian fungsional (reliabilitas).Pengujian manual memastikan bahwa orang yang
berinteraksi dengan sistem otomatis dapat menjalankan fungsinya dengan benar. Pengujian regresi
memverifikasi bahwa apa yang sedang diinstal tidak memengaruhi bagian mana pun dari aplikasi yang
sudah diinstal atau aplikasi lain yang dihubungkan oleh aplikasi baru. Pengujian fungsional memverifikasi
bahwa persyaratan sistem dapat dilakukan dengan benar ketika mengalami berbagai keadaan dan
transaksi berulang.
- - Pengujian fungsional dan regresi (kopling).
Fase pengujian harus memverifikasi bahwa aplikasi yang diuji
dapat berkomunikasi dengan benar dengan sistem aplikasi yang saling terkait. Kedua pengujian
fungsional dan regresi direkomendasikan. Pengujian fungsional memverifikasi bahwa setiap fungsi baru
saling terhubung dengan benar, sedangkan pengujian regresi memverifikasi bahwa segmen sistem
aplikasi yang tidak berubah yang terhubung dengan aplikasi lain masih berfungsi dengan baik.
- - Pengujian kepatuhan
- - Otorisasi.
Pengujian harus memverifikasi bahwa aturan otorisasi telah diterapkan dan
dipatuhi dengan benar. Kondisi pengujian harus mencakup transaksi atau proses yang tidak
sah untuk memastikan bahwa mereka ditolak, serta memastikan transaksi yang diotorisasi
diterima.
- - Pertunjukan. Kriteria kinerja ditetapkan selama fase persyaratan. Kriteria ini harus diperbarui
jika persyaratan berubah selama fase selanjutnya dari siklus hidup. Banyak kriteria yang
dapat dievaluasi selama fase pengujian, dan kriteria yang dapat diuji harus diuji. Namun,
mungkin perlu menunggu sampai sistem ditempatkan ke dalam produksi untuk
memverifikasi bahwa semua kriteria telah tercapai.
- - Keamanan. Penguji harus mengevaluasi kecukupan prosedur keamanan dengan mencoba

melanggarnya. Misalnya, individu yang tidak berwenang harus mencoba mengakses atau
memodifikasi data.
- - Pengujian fungsional
- - Integritasberkas. Penguji harus memverifikasi kontrol atas integritas file.

Misalnya, jika integritas bergantung pada berfungsinya total kontrol independen yang
tepat, fungsi tersebut harus diuji bersama dengan segmen otomatis dari sistem aplikasi.
Selain itu, pembaruan file yang memadai harus dilakukan sehingga kontrol integritas
dapat diuji selama beberapa iterasi dalam menjalankan sistem aplikasi.
- - jejak audit. Penguji harus menguji fungsi jejak audit untuk memastikan bahwa transaksi sumber dapat
dilacak ke total kontrol, bahwa transaksi yang mendukung total kontrol dapat diidentifikasi, dan
bahwa pemrosesan satu transaksi atau seluruh sistem dapat direkonstruksi menggunakan jejak audit
informasi. Biasanya disarankan untuk membuat daftar bagian dari file jejak audit untuk memastikan
bahwa itu lengkap berdasarkan transaksi uji yang dimasukkan.
- - Ketepatan. Pengujian kebenaran fungsional memverifikasi bahwa aplikasi berfungsi sesuai dengan
persyaratan yang ditentukan pengguna. Karena personel TI biasanya memusatkan pengujian mereka
pada verifikasi bahwa persyaratan jalur utama berfungsi dengan benar, Anda mungkin ingin
menekankan masalah pengujian lainnya selama pengujian validasi, atau menekankan transaksi yang
dimasukkan secara tidak benar untuk menguji validasi data dan fungsi deteksi kesalahan.
- - Pengujian pemulihan (kontinuitas pengujian). Jika pemrosesan harus dilanjutkan selama
periode ketika sistem otomatis tidak beroperasi, prosedur pemrosesan alternatif harus diuji.
Selain itu, pengguna sistem aplikasi harus dilibatkan dalam pengujian pemulihan lengkap
sehingga tidak hanya sistem otomatis yang diuji, tetapi prosedur untuk melakukan aspek
pemulihan manual juga diuji. Ini mungkin melibatkan sengaja menyebabkan sistem gagal
sehingga prosedur pemulihan dapat diuji.
- - Tes
stres (tingkat layanan). Aplikasi di bawah tekanan untuk memverifikasi bahwa sistem dapat
menangani pemrosesan volume tinggi. Pengujian stres harus berusaha menemukan tingkat
pemrosesan di mana sistem tidak dapat lagi berfungsi secara efektif. Dalam sistem online, ini
dapat ditentukan oleh volume transaksi, sedangkan dalam sistem batch, ukuran batch atau
volume besar jenis transaksi tertentu dapat menguji tabel internal atau kemampuan pengurutan.
- - Pengujian sesuai dengan metodologi. Pengujian harus dilakukan sesuai dengan kebijakan dan
prosedur pengujian organisasi. Metodologi harus menentukan jenis rencana pengujian yang
diperlukan, teknik dan alat pengujian yang direkomendasikan, serta jenis dokumentasi yang
diperlukan. Metodologi juga harus menentukan metode untuk menentukan apakah tes
berhasil.
- - Pengujian dukungan manual (kemudahan penggunaan). Keberhasilan akhir dari sistem ditentukan oleh
apakah orang dapat menggunakannya. Karena ini sulit untuk dievaluasi sebelum pengujian validasi,
penting bahwa sistem dievaluasi dalam lingkungan pengujian yang serealistis mungkin.
436 Bab 10
- - Inspeksi(pemeliharaan). Modifikasi yang dibuat selama siklus hidup pengembangan sistem

menyediakan salah satu metode pengujian pemeliharaan sistem aplikasi. Untungnya,
perubahan ini dilakukan oleh para pengembang yang akrab dengan sistem aplikasi. Sistem
yang telah selesai harus diperiksa oleh kelompok independen, lebih disukai oleh spesialis
pemeliharaan sistem. Standar pengembangan sistem harus dirancang dengan
mempertimbangkan pemeliharaan.
- - Pengujian bencana (portabilitas). Pengujian bencana mensimulasikan masalah di lingkungan asli
sehingga lingkungan pemrosesan alternatif dapat diuji. Meskipun tidak mungkin untuk
mensimulasikan semua lingkungan di mana sistem aplikasi dapat dipindahkan, mengetahui bahwa itu
dapat mentransfer antara dua lingkungan yang berbeda memberikan kemungkinan besar bahwa
gerakan lain tidak akan menyebabkan komplikasi besar.
- - Pengujian operasi (kemudahan pengoperasian). Pengujian dalam fase ini harus dilakukan
oleh staf operasi normal. Personil pengembangan proyek tidak boleh diizinkan untuk
melatih atau membantu selama proses pengujian. Hanya dengan memiliki personel operasi
normal yang melakukan pengujian, kelengkapan instruksi dan kemudahan pengoperasian
sistem dapat dievaluasi dengan benar.
Tugas 3: Catat Hasil Tes

Penguji harus mendokumentasikan hasil pengujian sehingga mereka tahu apa yang dicapai dan apa yang tidak
dicapai. Atribut berikut harus dikembangkan untuk setiap kasus uji:
- - Kondisi. Menceritakan apa adanya.
- - Kriteria. Memberitahu apa yang seharusnya.
Kedua atribut inilah yang menjadi dasar suatu temuan. Jika perbandingan antara keduanya memberikan
sedikit atau tidak ada konsekuensi praktis, tidak ada temuan.
- - Memengaruhi. Memberitahukan mengapa perbedaan antara apa yang ada dan apa yang seharusnya menjadi signifikan.
- - Menyebabkan. Menceritakan alasan penyimpangan.
Pernyataan masalah yang dikembangkan dengan baik mencakup masing-masing atribut ini. Ketika satu atau lebih
atribut ini hilang, pertanyaan hampir selalu muncul, seperti:
- - Kondisi. Apa masalahnya?

- - Kriteria. Mengapa kondisi saat ini tidak memadai?
- - Memengaruhi. Seberapa signifikan?
- - Menyebabkan. Apa yang bisa menyebabkan masalah?
Mendokumentasikan pernyataan masalah pengguna melibatkan tiga tugas, yang dijelaskan di

bagian berikut.
Mendokumentasikan Penyimpangan
Pernyataan masalah berasal dari proses perbandingan. Pada dasarnya, pengguna membandingkan "apa adanya"
dengan "apa yang seharusnya". Ketika penyimpangan diidentifikasi antara apa yang sebenarnya ada dan apa yang
menurut pengguna benar atau tepat, langkah penting pertama menuju pengembangan pernyataan masalah telah
terjadi. Sulit untuk memvisualisasikan jenis masalah apa pun yang dalam beberapa hal tidak dicirikan oleh
penyimpangan ini. "Apa adanya" dapat disebut sebagai pernyataan kondisi. "Apa yang seharusnya" bisa disebut
kriteria. Konsep-konsep ini adalah dua yang pertama, dan paling mendasar, atribut dari pernyataan masalah.
Mendokumentasikan penyimpangan berarti menggambarkan kondisi seperti yang ada saat ini dan kriteria yang mewakili apa
yang diinginkan pengguna. Penyimpangan yang sebenarnya adalah perbedaan, atau kesenjangan, antara "apa adanya" dan "apa yang
diinginkan".
Pernyataan kondisi mengungkap dan mendokumentasikan fakta sebagaimana adanya. Apa itu
fakta? Jika seseorang memberi tahu Anda sesuatu terjadi, apakah itu "sesuatu" fakta? Atau apakah itu hanya fakta
jika seseorang memberi tahu Anda bahwa itu fakta? Deskripsi pernyataan kondisi, tentu saja, sangat bergantung
pada sifat dan luasnya bukti atau dukungan yang diperiksa dan dicatat.
Untuk fakta-fakta yang membentuk pernyataan kondisi, profesional TI jelas akan berusaha keras untuk memastikan
bahwa informasi tersebut akurat, didukung dengan baik, dan kata-kata sejelas dan setepat mungkin.
Pernyataan kondisi harus mendokumentasikan sebanyak mungkin atribut berikut yang
sesuai untuk masalah: Kegiatan
yang terlibat Prosedur yang
digunakan untuk
melakukan pekerjaan Keluaran/hasil
masukan
Pengguna/pelanggan yang dilayani
Kekurangan dicatat
Kriteria adalah pernyataan pengguna tentang apa yang diinginkan. Itu dapat dinyatakan dalam istilah negatif
atau positif. Misalnya, ini dapat menunjukkan kebutuhan untuk mengurangi keluhan atau penundaan serta waktu
penyelesaian pemrosesan yang diinginkan.
Seringkali, "seharusnya" berhubungan terutama dengan akal sehat atau kewajaran umum, dan pernyataan
kondisi sebenarnya berbicara sendiri. Situasi ini harus hati-hati dibedakan dari keinginan pribadi atau subjektif,
gagasan fantastis. Tidak ada ruang untuk subjektivitas seperti itu dalam mendefinisikan apa yang diinginkan.
Sebisa mungkin, kriteria harus berhubungan langsung dengan pernyataan kondisi. Misalnya, jika volume
diharapkan meningkat, jumlah pengguna yang dilayani telah berubah, atau proses pengguna telah berubah,
mereka harus dinyatakan dalam istilah yang sama seperti yang digunakan dalam mendokumentasikan
pernyataan kondisi.
Kertas Kerja 10-3 memberikan ruang untuk mendeskripsikan masalah dan mendokumentasikan
pernyataan kondisi dan pernyataan kriteria. Perhatikan bahwa bagian tambahan dapat ditambahkan ke Kertas
Kerja 10-3 untuk menjelaskan penyimpangan. Namun, jika pernyataan kondisi dan pernyataan kriteria ditulis
dengan benar, penyimpangan harus dapat ditentukan dengan mudah.
438 Bab 10
Mendokumentasikan Efek
Sedangkan legitimasi pernyataan masalah mungkin berdiri atau jatuh pada kriteria, perhatian yang diterima
pernyataan masalah setelah dilaporkan sangat tergantung pada signifikansinya. Signifikansi dinilai
berdasarkan efeknya.
Efisiensi dan ekonomi adalah ukuran efek yang berguna dan sering dapat dinyatakan dalam istilah
kuantitatif seperti dolar, waktu, unit produksi, jumlah prosedur dan proses, atau transaksi. Sedangkan
efek masa lalu tidak dapat dipastikan, potensi efek masa depan dapat ditentukan. Kadang-kadang efek
tidak berwujud tetapi tetap sangat penting.
Efek sering dianggap hampir bersamaan dengan dua atribut pertama (kondisi dan kriteria) dari masalah.
Peninjau mungkin mencurigai efek buruk bahkan sebelum mereka dengan jelas merumuskan atribut-atribut
lain ini dalam pikiran mereka. Setelah pernyataan kondisi diidentifikasi, peninjau dapat mencari kriteria tegas
untuk mengukur efek yang dicurigai.
Mereka mungkin berhipotesis beberapa kriteria alternatif, yang diyakini cocok berdasarkan pengalaman dalam
situasi serupa. Mereka mungkin menyimpulkan bahwa efek di bawah setiap hipotesis sangat berbeda atau
tidak masuk akal sehingga yang benar-benar dibutuhkan adalah kriteria yang lebih tegas—katakanlah,
kebijakan formal di area di mana tidak ada kebijakan saat ini. Penyajian pernyataan masalah mungkin berkisar
pada kriteria yang hilang ini, meskipun kecurigaan terhadap efek mungkin merupakan jalur awal.
Peninjau harus berusaha untuk mengukur efek masalah dimanapun praktis. Meskipun pengaruhnya dapat
dinyatakan dalam istilah naratif atau kualitatif, hal itu seringkali tidak menyampaikan pesan yang tepat kepada
manajemen; misalnya, pernyataan seperti "Layanan akan tertunda," atau "Waktu komputer tambahan akan
diperlukan" tidak benar-benar memberi tahu apa yang terjadi pada organisasi.
Mendokumentasikan Penyebabnya
Dalam beberapa kasus, penyebabnya mungkin terlihat jelas dari fakta yang disajikan. Dalam kasus lain,
penyelidikan diperlukan untuk mengidentifikasi asal usul masalah.
Sebagian besar temuan melibatkan satu atau lebih penyebab berikut:
- - Ketidaksesuaian dengan standar, prosedur, atau pedoman

- - Ketidaksesuaian dengan instruksi, arahan, kebijakan, atau prosedur yang diterbitkan dari otoritas yang
lebih tinggi
- - Ketidaksesuaian dengan praktik bisnis yang diterima secara umum sebagai hal yang wajar
- - Mempekerjakan praktik yang tidak efisien atau tidak ekonomis
Penentuan penyebab suatu kondisi biasanya memerlukan pendekatan ilmiah, yang

meliputi langkah-langkah berikut:
1. Mendefinisikan masalah (kondisi yang menghasilkan temuan).
2. Mengidentifikasi alur kerja dan/atau informasi yang mengarah pada kondisi tersebut.
3. Identifikasi prosedur yang digunakan dalam menghasilkan kondisi tersebut.

4. Identifikasi orang-orang yang terlibat.
5. Menciptakan kembali keadaan untuk mengidentifikasi penyebab suatu kondisi.
Dokumentasikan penyebab masalah pada Kertas Kerja 10-3.
Periksa Prosedur
Kertas Kerja 10-4 adalah daftar periksa kontrol kualitas untuk langkah ini. Tanggapan Ya menunjukkan praktik pengujian yang
baik, dan Tidak ada tanggapan yang memerlukan penyelidikan tambahan. Kolom Komentar disediakan untuk menjelaskan
Tidak ada tanggapan dan untuk mencatat hasil investigasi.
Keluaran
Pengujian validasi memiliki tiga keluaran berikut:
Transaksi uji untuk memvalidasi sistem perangkat lunak Hasil

dari pelaksanaan transaksi tersebut Varians dari hasil yang
diharapkan
Pedoman
Pengujian validasi adalah garis pertahanan terakhir terhadap cacat yang memasuki lingkungan operasional.
Jika tidak ada pengujian yang terjadi sebelum fase pengujian, tidak masuk akal untuk mengharapkan
pengujian pada titik ini untuk menghilangkan semua cacat. Pengalaman menunjukkan bahwa sulit bagi fase
pengujian untuk lebih dari 80 persen efektif dalam mengurangi cacat. Jelas, semakin sedikit jumlah cacat yang
memasuki tahap pengujian, semakin sedikit jumlah cacat yang masuk ke lingkungan produksi.
Pada akhir fase pengujian, sistem aplikasi ditempatkan ke dalam produksi. Tahap pengujian memberikan
kesempatan terakhir bagi pengguna untuk memastikan bahwa sistem berfungsi dengan baik. Untuk alasan ini,
pengguna harus banyak terlibat dalam pengujian sistem aplikasi.
Departemen TI memiliki kesempatan untuk mengevaluasi sistem aplikasi selama fase program.
Selama fase ini, mereka menentukan apakah sistem berfungsi sesuai dengan kebutuhan. Langkah
pengujian paling baik dilakukan oleh kelompok selain tim proyek. Ini bukan untuk mengatakan bahwa
tim proyek tidak boleh terlibat atau membantu, melainkan bahwa tim tidak boleh menjadi pihak yang
dominan dalam fase pengujian. Jika individu yang sama bertanggung jawab untuk pengujian fase
program dan pengujian fase pengujian, tidak perlu ada dua fase yang berbeda. Jika layanan informasi
memikul tanggung jawab pengujian selama fase program, dan pengguna menerimanya selama fase
pengujian, kedua fase tersebut saling melengkapi.
440 Bab 10
Sebuah kelompok uji independen harus diberi tanggung jawab untuk menguji sistem untuk
menentukan apakah sistem bekerja sesuai dengan kebutuhannya. Karena masalah komunikasi,
mungkin ada perbedaan antara spesifikasi sistem yang dibangun dan persyaratan yang diharapkan
pengguna. Idealnya, tim pengujian telah mengembangkan kondisi pengujian dari fase persyaratan,
dan selama fase pengujian harus menemukan cacat yang tersisa dalam sistem aplikasi.
Ringkasan
Bab ini menjelaskan cara menguji perangkat lunak aplikasi secara dinamis. Pengujian validasi tidak boleh fokus pada
penghapusan cacat, melainkan pada apakah sistem dapat melakukan seperti yang ditentukan dalam mode
operasional. Karena pengujian penuh tidak praktis, pengujian validasi harus berkonsentrasi pada aspek operasional
yang paling penting bagi pengguna. Langkah selanjutnya adalah menganalisis hasil pengujian dan melaporkan
hasilnya.
KERTAS KERJA 10-1 Mengembangkan Naskah Tes
Tes masuk Mengharapkan Operator

Barang Oleh Urutan Tindakan Hasil instruksi
KERTAS KERJA 10-2 Tahap Uji Proses Uji
FAKTOR UJI: Pengujian Manual, Regresi, dan Fungsional (Keandalan)
PENILAIAN
Sangat Ade- Ade- tidak ada-
KRITERIA UJI quate quate quate T/A UJI YANG DIREKOMENDASIKAN
1. Apakah data yang tidak sesuai dengan spesifikasi Verifikasi bahwa program validasi data menolak data yang tidak sesuai dengan
elemen data individu telah diuji? spesifikasi elemen data.
2. Apakah pengujian telah dilakukan untuk menolak Verifikasi bahwa sistem menolak hubungan data yang tidak
hubungan data yang tidak sesuai dengan spesifikasi sesuai dengan spesifikasi sistem.
sistem?
3. Apakah pengidentifikasi yang tidak valid telah diuji? Verifikasi bahwa program menolak pengidentifikasi yang tidak valid.
4. Apakah pengujian telah dilakukan untuk memverifikasi bahwa Konfirmasikan bahwa sistem mendeteksi nomor urut yang hilang.
nomor urut yang hilang akan terdeteksi?
5. Apakah pengujian telah dilakukan untuk memverifikasi bahwa Verifikasi bahwa sistem akan mendeteksi total batch yang tidak akurat.
total bets yang tidak akurat akan terdeteksi?
6. Apakah pengujian telah dilakukan untuk menentukan bahwa Verifikasi bahwa program akan merusak data yang hilang dari kumpulan
data yang hilang dari batch atau data terjadwal yang hilang dan data terjadwal yang tidak tiba tepat waktu.
akan terdeteksi?
7. Apakah pengujian telah dilakukan untuk memverifikasi bahwa bagian Lakukan uji regresi untuk memastikan bahwa bagian program yang tidak berubah
sistem yang tidak berubah tidak terpengaruh oleh data yang tidak tidak terpengaruh oleh data yang tidak valid.
valid?
8. Apakah hasil yang diperoleh dari proses recovery sudah Verifikasi kebenaran hasil yang diperoleh dari proses
benar? pemulihan.
KERTAS KERJA 10-2 (lanjutan)
FAKTOR UJI: Pengujian Kepatuhan (Otorisasi)
PENILAIAN
1. Apakah prosedur manual memastikan bahwa Uji prosedur manual untuk memverifikasi bahwa prosedur otorisasi diikuti.
otorisasi yang tepat telah diterima? Verifikasi bahwa program menerapkan aturan otorisasi otomatis.
2. Apakah aturan otorisasi otomatis
telah diuji? Konfirmasikan bahwa pengidentifikasi sebenarnya untuk otorisasi disertakan
3. Apakah nama dan pengidentifikasi otorisasi saat ini telah dalam program.
dimasukkan sebagai bagian dari pengujian? Verifikasi bahwa program otorisasi menolak Keamanan
4. Apakah transaksi yang tidak sah telah dimasukkan ke dalam sistem transaksi yang tidak sah.
untuk menentukan apakah transaksi tersebut akan ditolak?
5. Jika beberapa otorisasi diperlukan, apakah Verifikasi bahwa beberapa prosedur otorisasi
prosedur berfungsi dengan baik? bekerja dengan benar.
6. Jika otorisasi terbatas dalam ukuran transaksi yang dapat Verifikasi bahwa sistem dapat mengidentifikasi potensi pelanggaran batas otorisasi
mereka uji otorisasi, apakah beberapa transaksi di yang disebabkan oleh memasukkan beberapa transaksi di bawah batas.
bawah batas itu telah dimasukkan untuk menentukan
apakah sistem memeriksa pelanggaran batas?
7. Apakah prosedur untuk mengubah nama atau Verifikasi bahwa prosedur untuk mengubah aturan otorisasi suatu
pengenal individu yang berwenang untuk program berjalan dengan benar.
mengubah transaksi telah diuji?
8. Apakah prosedur untuk melaporkan pelanggaran Verifikasi bahwa laporan otorisasi disiapkan dan
otorisasi kepada manajemen telah diuji? disampaikan dengan benar.
(lanjutan)
FAKTOR UJI: Pengujian Fungsional (Integritas File)
PENILAIAN
1. Apakah kontrol penyeimbangan file telah diuji? Verifikasi bahwa prosedur untuk menyeimbangkan file berfungsi dengan benar.
2. Apakah total kontrol yang dipelihara secara Verifikasi bahwa total kontrol yang dipelihara secara independen dapat
independen telah diuji? mengkonfirmasi total kontrol file otomatis.
3. Apakah prosedur integritas telah diuji untuk memastikan bahwa Verifikasi bahwa total kontrol baru dengan benar mencerminkan transaksi
pembaruan dicatat dengan benar? yang diperbarui.
4. Apakah pengujian telah dilakukan untuk memastikan bahwa integritas Menyebabkan program gagal untuk menentukan apakah itu mempengaruhi integritas
dapat dipertahankan setelah kegagalan program? file.
5. Apakah data yang salah telah dimasukkan untuk menentukan apakah data Masukkan data yang salah untuk menentukan bahwa itu tidak dapat
tersebut dapat merusak integritas file? memengaruhi integritas total file.
6. Apakah prosedur manual untuk mengembangkan total Verifikasi bahwa prosedur manual dapat dilakukan dengan benar untuk
pengendalian independen telah diuji? menghasilkan total kontrol independen yang benar.
7. Jika beberapa file berisi data yang sama, apakah semua elemen data Ubah elemen data dalam satu file yang berlebihan di beberapa file untuk
yang serupa akan diubah secara bersamaan untuk memastikan memverifikasi bahwa file lain akan diubah sesuai dengan itu.
integritas semua file komputer?
8. Apakah kondisi file nil dan satu record telah Jalankan sistem dengan satu dan tanpa catatan pada setiap file.
diuji?
FAKTOR UJI: Pengujian Fungsional (Jejak Audit)
PENILAIAN
1. Apakah pengujian telah dilakukan untuk memverifikasi bahwa dokumen Verifikasi bahwa transaksi sumber yang diberikan dapat ditelusuri ke total
sumber dapat dilacak ke total pengendalian? kontrol yang sesuai.
2. Apakah pengujian telah dilakukan untuk memverifikasi bahwa Tentukan total kontrol bahwa semua transaksi pendukung dapat
semua data pendukung untuk total kontrol dapat diidentifikasi.
diidentifikasi?
3. Dapatkah pemrosesan satu transaksi Verifikasi bahwa pemrosesan satu transaksi dapat
direkonstruksi? direkonstruksi.
4. Apakah pengujian telah dilakukan untuk Periksa jejak audit untuk memverifikasi bahwa itu berisi informasi yang
memverifikasi bahwa jejak audit berisi sesuai.
informasi yang sesuai?
5. Apakah jejak audit akan disimpan untuk Verifikasi bahwa jejak audit ditandai untuk disimpan untuk jangka waktu yang sesuai.
periode waktu yang tepat?
Verifikasi bahwa dengan menggunakan prosedur jejak audit orang dapat
6. Apakah pengujian telah dilakukan untuk menentukan bahwa merekonstruksi pemrosesan.
orang dapat merekonstruksi pemrosesan dari prosedur
jejak audit? Tentukan biaya penggunaan jejak audit.
7. Apakah pengujian telah dilakukan untuk memverifikasi bahwa
jejak audit ekonomis untuk digunakan? Verifikasi dengan auditor bahwa jejak audit memuaskan untuk tujuan
8. Apakah jejak audit memenuhi mereka.
persyaratan tinjauan?
(lanjutan)
FAKTOR UJI: Pengujian Pemulihan (Pemrosesan Berkelanjutan)
PENILAIAN
1. Apakah bencana simulasi telah dibuat untuk Simulasikan bencana untuk memverifikasi bahwa pemulihan dapat terjadi setelah bencana.
menguji prosedur pemulihan? Verifikasi bahwa pemulihan dapat dilakukan langsung dari prosedur
2. Dapatkah orang melakukan operasi pemulihan.
pemulihan dari prosedur pemulihan? Lakukan tes pemulihan untuk menentukan bahwa itu dapat dilakukan dalam kerangka waktu
3. Apakah pengujian telah dirancang untuk menentukan pemulihan dapat yang diperlukan.
terjadi dalam kerangka yang diinginkan? Konfirmasikan dengan personel operasi bahwa mereka telah menerima pelatihan
4. Apakah personel operasi telah dilatih pemulihan yang sesuai.
dalam prosedur pemulihan? Verifikasi bahwa sistem dapat pulih dari masing-masing berbagai jenis
5. Apakah setiap jenis kegagalan sistem telah diuji? kegagalan sistem.
Simulasikan bencana sistem untuk memverifikasi bahwa prosedur manual sudah
6. Apakah prosedur pencadangan manual telah diuji menggunakan memadai.
volume penuh untuk kegagalan sistem? Verifikasi bahwa pengguna sistem dapat memasukkan data yang telah
7. Apakah prosedur manual telah diuji untuk terakumulasi selama kegagalan sistem dengan benar.
memasukkan data yang diterima selama waktu
henti ke dalam sistem setelah integritas sistem
dipulihkan? Mengharuskan prosedur pemrosesan alternatif manual
8. Dapatkah prosedur pemrosesan alternatif dilakukan dengan dilakukan secara eksklusif dari prosedur.
menggunakan prosedur manual?
FAKTOR UJI: Pengujian Stres (Tingkat Layanan)
PENILAIAN
1. Apakah batasan dari semua tabel internal dan batasan lainnya Konfirmasikan dengan pemimpin proyek bahwa semua batas proyek
telah didokumentasikan? didokumentasikan.
2. Apakah setiap unit yang didokumentasikan telah diuji? Verifikasi bahwa batas aplikasi telah diuji.
3. Apakah prosedur terprogram telah disertakan
sehingga transaksi yang tidak dapat diproses Konfirmasikan bahwa ketika lebih banyak transaksi yang dimasukkan daripada yang dapat
dalam kapasitas saat ini disimpan untuk ditangani sistem, transaksi tersebut disimpan untuk diproses nanti.
diproses nanti?
4. Apakah bagian input dari sistem telah
mengalami stress testing? Pastikan bahwa input yang berlebihan tidak akan mengakibatkan masalah sistem.
5. Apakah segmen manual dari sistem telah

mengalami stress testing? Pastikan bahwa ketika orang mendapatkan lebih banyak transaksi daripada yang dapat
mereka proses, tidak ada transaksi yang akan hilang.
6. Apakah sistem komunikasi
telah diuji stres? Verifikasi bahwa ketika sistem komunikasi diperlukan untuk memproses lebih
banyak transaksi daripada kemampuannya, transaksi tidak hilang.
7. Apakah prosedur telah ditulis yang menguraikan proses
yang harus diikuti ketika volume sistem melebihi Mengevaluasi kewajaran prosedur kelebihan
kapasitas? kapasitas.
8. Apakah pengujian menggunakan personel cadangan telah
dilakukan untuk memverifikasi bahwa sistem dapat Uji fungsi sistem saat dioperasikan oleh personel cadangan.
memproses volume normal tanpa kehadiran staf
reguler?
(lanjutan)
FAKTOR UJI: Uji Kepatuhan (Kinerja)
PENILAIAN
1. Dapatkah sistem dioperasikan pada volume yang diharapkan Verifikasi bahwa sistem dapat dioperasikan dengan dukungan manual yang
dengan dukungan manual yang diantisipasi? diantisipasi.
2. Dapatkah transaksi diproses pada volume yang Verifikasi bahwa biaya pemrosesan transaksi berada dalam toleransi yang
diharapkan dengan biaya yang diharapkan? diharapkan.
3. Apakah fase pengujian telah dilakukan sesuai Verifikasi dari laporan akuntansi bahwa fase pengujian telah
anggaran pengujian? dilakukan sesuai anggaran.
4. Apakah ada masalah yang ditemui dalam pengujian yang Konfirmasikan dengan pemimpin proyek bahwa masalah yang ditemukan tidak akan
akan mempengaruhi efektivitas biaya sistem? secara signifikan mempengaruhi efektivitas biaya sistem.
5. Apakah tahap pengujian menunjukkan bahwa manfaat yang Konfirmasikan dengan manajemen pengguna bahwa manfaat yang
diharapkan akan diterima? diharapkan harus diterima.
6. Akankah perubahan yang diproyeksikan pada perangkat keras dan Konfirmasikan dengan operasi komputer apakah perubahan yang diproyeksikan pada perangkat
perangkat lunak secara signifikan mengurangi biaya operasional atau keras dan perangkat lunak akan secara signifikan mengurangi biaya operasi dan pemeliharaan.
pemeliharaan?
Memeriksa kelengkapan program kerja tahap uji coba.
7. Apakah ada jadwal fase pengujian yang mengidentifikasi
tugas, orang, anggaran, dan biaya? Konfirmasikan dengan sumber independen tentang kelayakan teknologi
8. Apakah teknologi yang digunakan untuk implementasi implementasi.
terdengar?
FAKTOR UJI: Pengujian Kepatuhan (Keamanan)
PENILAIAN
1. Apakah risiko keamanan yang teridentifikasi memiliki Periksa kelengkapan perlindungan terhadap risiko
perlindungan yang memadai? keamanan yang teridentifikasi.
2. Apakah pengujian telah dilakukan untuk Mencoba melanggar keamanan fisik.
melanggar keamanan fisik?
3. Apakah pengujian telah dilakukan untuk melanggar Mencoba melanggar keamanan akses.
keamanan akses?
4. Apakah pengujian telah dilakukan untuk menentukan apakah Mencoba melanggar keamanan akses.
sumber daya komputer dapat digunakan tanpa izin?
5. Apakah pengujian telah dilakukan untuk menentukan apakah

prosedur keamanan memadai selama jam istirahat? Melakukan pelanggaran keamanan di luar jam kerja.
6. Apakah pengujian berulang dilakukan untuk
mencoba melanggar keamanan dengan upaya
terus-menerus? Melakukan pelanggaran keamanan berulang.
7. Apakah pengujian dilakukan untuk mendapatkan akses

ke program dan dokumentasi sistem?
Mencoba untuk mendapatkan akses ke program dan dokumentasi sistem.
8. Apakah karyawan cukup terlatih dalam
prosedur keamanan?
Pastikan bahwa karyawan mengetahui dan mengikuti prosedur
keamanan.
(lanjutan)
FAKTOR UJI: Tes Sesuai dengan Metodologi
PENILAIAN
1. Apakah pengujian memverifikasi bahwa pemrosesan Verifikasi bahwa hasil sistem operasional sesuai dengan
sistem sesuai dengan kebijakan dan prosedur organisasi? kebijakan dan prosedur organisasi.
2. Apakah pengujian memverifikasi bahwa pemrosesan
sistem sesuai dengan kebijakan dan prosedur Verifikasi bahwa hasil sistem operasional sesuai dengan
pemrosesan layanan informasi? kebijakan dan prosedur layanan informasi.
3. Apakah pengujian memverifikasi bahwa pemrosesan
sistem sesuai dengan akuntansi? kebijakan dan Verifikasi bahwa hasil sistem operasional sesuai dengan
prosedur? kebijakan dan prosedur akuntansi.
4. Apakah pengujian memverifikasi bahwa pemrosesan sistem sesuai
dengan peraturan pemerintah? Verifikasi bahwa hasil sistem operasional sesuai dengan
peraturan? peraturan pemerintah.
5. Apakah pengujian memverifikasi bahwa pemrosesan sistem
sesuai dengan standar industri? Verifikasi bahwa hasil sistem operasional sesuai dengan standar
industri.
6. Apakah pengujian memverifikasi bahwa pemrosesan sistem
sesuai dengan prosedur pengguna? Verifikasi bahwa hasil sistem operasional sesuai dengan
kebijakan dan prosedur departemen pengguna.
7. Apakah prosedur pengujian sesuai dengan rencana
pengujian? Verifikasi bahwa rencana pengujian telah dilaksanakan sepenuhnya.
8. Apakah pengujian telah memverifikasi bahwa data sensitif

dilindungi secara memadai? Konfirmasikan dengan pengguna kelengkapan tes untuk
memverifikasi data sensitif dilindungi.
FAKTOR UJI: Pengujian Fungsional (Kebenaran)
PENILAIAN
1. Apakah prosedur originasi transaksi Verifikasi bahwa prosedur originasi transaksi berjalan sesuai
normal berfungsi sesuai dengan dengan persyaratan sistem.
spesifikasi?
2. Apakah prosedur input berfungsi Verifikasi bahwa prosedur input bekerja sesuai dengan
sesuai dengan spesifikasi? persyaratan sistem.
3. Apakah prosedur pemrosesan berfungsi sesuai Verifikasi bahwa prosedur pemrosesan bekerja sesuai dengan
dengan spesifikasi? persyaratan sistem.
4. Apakah prosedur penyimpanan penyimpanan Verifikasi bahwa prosedur penyimpanan penyimpanan bekerja
berfungsi sesuai dengan spesifikasi? sesuai dengan persyaratan sistem.
5. Apakah prosedur keluaran berfungsi Verifikasi bahwa prosedur keluaran bekerja sesuai dengan
6. Apakah prosedur penanganan kesalahan Verifikasi bahwa prosedur penanganan kesalahan bekerja sesuai dengan
berfungsi sesuai dengan spesifikasi? persyaratan sistem.
7. Apakah prosedur manual berfungsi Verifikasi bahwa prosedur manual bekerja sesuai dengan
8. Apakah prosedur penyimpanan data Verifikasi bahwa prosedur penyimpanan data bekerja sesuai dengan
berfungsi sesuai dengan spesifikasi? persyaratan sistem.
(lanjutan)
FAKTOR UJI: Pengujian Dukungan Manual (Kemudahan Penggunaan)
PENILAIAN
1. Apakah petugas klerikal memahami Konfirmasikan dengan personel administrasi bahwa mereka memahami
prosedur? prosedurnya.
2. Apakah dokumen referensi mudah digunakan? Periksa hasil penggunaan dokumen referensi. Periksa
3. Apakah dokumen input dapat diisi dengan benar? pemrosesan untuk kebenaran.
4. Apakah dokumen keluaran digunakan dengan benar? Periksa kebenaran penggunaan dokumen keluaran. Identifikasi
5. Apakah pemrosesan manual selesai dalam kerangka waktu rentang waktu untuk pemrosesan manual.
yang diharapkan?
6. Apakah keluaran menunjukkan tindakan mana yang harus diambil Periksa output untuk prioritas indikasi penggunaan.
terlebih dahulu?
7. Apakah dokumen diidentifikasi dengan jelas mengenai

Periksa dokumen untuk kejelasan identifikasi.
penerima dan penggunaan?
8. Apakah petugas administrasi puas dengan Konfirmasikan dengan personel administrasi kemudahan
kemudahan penggunaan sistem? penggunaan sistem.

FAKTOR UJI: Inspeksi (Maintainability)
PENILAIAN
1. Apakah program berisi kode nonentrant? Tentukan semua pernyataan program adalah peserta. Periksa
2. Apakah program dapat dieksekusi? kewajaran hasil pemrosesan program. Memperkenalkan kesalahan ke
3. Bisakah kesalahan program ditemukan dengan cepat? dalam program.
4. Apakah program sesuai dengan Pastikan versi program yang dapat dieksekusi sesuai dengan
dokumentasi? dokumentasi program.
5. Apakah riwayat perubahan program tersedia? Periksa kelengkapan riwayat perubahan program. Periksa
6. Apakah kriteria pengujian disiapkan sehingga dapat kegunaan data uji untuk pemeliharaan.
digunakan untuk pemeliharaan?
7. Apakah hasil pengujian pemeriksaan mandiri disiapkan untuk

Periksa kegunaan hasil tes yang diharapkan untuk pemeliharaan.
digunakan selama pemeliharaan?
8. Apakah semua kesalahan yang terdeteksi selama

Verifikasi bahwa kesalahan yang terdeteksi selama pengujian telah diperbaiki.
pengujian dikoreksi?
(lanjutan)
FAKTOR UJI: Pengujian Bencana (Portabilitas)
PENILAIAN
1. Apakah lokasi pemrosesan alternatif dan/atau Konfirmasikan bahwa persyaratan situs alternatif telah
persyaratan telah diidentifikasi? diidentifikasi.
2. Apakah file data dapat dibaca di fasilitas baru? Jalankan file data di fasilitas baru.
3. Apakah program dapat dijalankan di fasilitas baru? Jalankan program di fasilitas baru.
4. Apakah petunjuk pengoperasian dapat digunakan di fasilitas Minta agar operator normal menjalankan sistem di fasilitas
baru? baru.
5. Apakah keluaran dapat digunakan di fasilitas baru? Periksa kegunaan output yang dihasilkan menggunakan fasilitas baru.
6. Apakah waktu pelaksanaan dapat diterima di Pantau waktu eksekusi di fasilitas baru.
fasilitas baru?
7. Apakah program dapat dikompilasi ulang di Kompilasi ulang program di fasilitas baru.
fasilitas baru?
8. Apakah prosedur pengguna dapat digunakan di fasilitas Meminta pengguna untuk mengoperasikan sistem di fasilitas baru.
baru?
FAKTOR UJI: Pengujian Fungsional dan Regresi (Coupling)
PENILAIAN
1. Apakah input dari sistem peralatan lain sudah benar? Verifikasi kebenaran data terkomputerisasi. Verifikasi
2. Apakah output ke aplikasi lain sudah
benar? kebenaran data terkomputerisasi. Verifikasi input aktual
3. Apakah input dari aplikasi lain sesuai dengan
dokumen spesifikasi? sesuai dengan spesifikasi. Verifikasi keluaran aktual sesuai
4. Apakah keluaran ke aplikasi lain sesuai
dengan dokumen spesifikasi? dengan spesifikasi. Lakukan pengujian regresi yang
5. Apakah masukan dari aplikasi lain memengaruhi fungsi
yang tidak terkait? sesuai.
6. Dapatkah persyaratan antarsistem diproses dalam
spesifikasi kerangka waktu? Pantau rentang waktu pemrosesan untuk kepatuhan terhadap
7. Apakah instruksi pengoperasian antarsistem sudah benar? spesifikasi.
8. Apakah tanggal penyimpanan pada file antar sistem sudah benar? Pastikan instruksi operasi antarsistem sudah benar. Konfirmasikan bahwa
tanggal penyimpanan file antarsistem sudah benar.
(lanjutan)
FAKTOR UJI: Uji Operasi (Kemudahan Pengoperasian)
PENILAIAN
1. Apakah instruksi pengoperasian dalam Verifikasi instruksi yang terdokumentasi sesuai dengan standar.
format yang benar?
2. Apakah operator telah diinstruksikan tentang cara Konfirmasikan dengan operator kelengkapan instruksi.
mengoperasikan aplikasi baru?
3. Apakah daftar panggilan masuk bermasalah telah disiapkan? Periksa daftar panggilan masuk.
4. Apakah petunjuk pengoperasian sudah lengkap? Tentukan instruksi operator yang lengkap. Periksa jadwal
5. Apakah operasi dan waktu pengujian yang untuk alokasi waktu yang wajar.
sesuai telah dijadwalkan?
6. Apakah prosedur penyimpanan data disiapkan? Verifikasi kelengkapan prosedur retensi.
7. Apakah operator normal berhasil Verifikasi bahwa operator dapat mengoperasikan sistem hanya dengan
menjalankan aplikasi? menggunakan instruksi operator.
8. Apakah rekomendasi operator untuk Pastikan bahwa rekomendasi operator telah ditinjau secara
perbaikan telah ditinjau? memadai.
KERTAS KERJA 10-3 Dokumentasi Soal Tes
Nama Perangkat Lunak yang Diuji
Masalah
Keterangan
Hasil nyata
Hasil yang diharapkan
Efek Deviasi
Penyebab Masalah
Lokasi Masalah
Direkomendasikan
Tindakan
458 Bab 10
KERTAS KERJA 10-4 Daftar Periksa Kontrol Kualitas
YA TIDAK T/A KOMENTAR
1. Apakah lingkungan pengujian yang sesuai telah

ditetapkan untuk melakukan pengujian dinamis
perangkat lunak aplikasi?
2. Apakah penguji terlatih dalam alat uji yang akan
digunakan selama langkah ini?
3. Apakah waktu yang cukup telah dialokasikan untuk langkah
ini?
4. Apakah sumber daya yang memadai telah ditetapkan untuk langkah
ini?
5. Apakah metode untuk membuat data uji sudah
sesuai untuk sistem ini?
6. Apakah data pengujian yang memadai telah dikembangkan untuk
menguji perangkat lunak aplikasi secara memadai?
7. Apakah semua teknik pengujian yang ditunjukkan dalam

rencana pengujian telah dijadwalkan untuk dieksekusi
selama langkah ini?
8. Apakah hasil yang diharapkan dari pengujian telah
ditentukan?
9. Apakah proses telah ditetapkan untuk
menentukan varians/deviasi antara hasil yang
diharapkan dan hasil aktual?
10. Apakah hasil yang diharapkan dan hasil aktual telah
didokumentasikan ketika ada penyimpangan di antara
keduanya?
11. Apakah dampak potensial dari setiap
penyimpangan telah ditentukan?
12. Apakah proses telah ditetapkan untuk memastikan bahwa
tindakan/penyelesaian yang tepat akan diambil pada semua
masalah pengujian yang teridentifikasi?

Validasi Sistem

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Validasi Sistem

Diunggah oleh

Hak Cipta:

Format Tersedia

CHAPTER

Pengujian validasi menyajikan kepada penguji kekhawatiran berikut:

dan/atau skrip pengujian

Hasil tes verifikasi sebelumnya

Langkah ini melibatkan tiga tugas berikut:

Tugas 1: Membangun Data Uji

Sumber Data Tes/Script Tes

Menguji Desain File

- - Pengujian atas transaksi yang terjadi secara normal.

Mendefinisikan Tujuan Desain

Memasukkan Data Uji

Menerapkan File Uji Terhadap Program Yang

Membuat dan Menggunakan Data Uji

Contoh Aplikasi Penggajian

Potong kembali ke maksimum

menghitung dengan benar

Potong kembali ke maksimum

menghitung dengan benar

4. Mengubah bidang di Untuk menentukan apakah mungkin untuk x x

5. Mengubah pekerjaan- Untuk menentukan apakah sistem akan menolak

Gambar 10-2 (lanjutan)

Potong kembali ke maksimum

menghitung dengan benar

6. Promosikan seorang jenderal Untuk menentukan apakah sistem menolak transaksi x x

8. Mengubah pekerjaan- ee Untuk menentukan apakah sistem menerima data yang x x

Gambar 10-2 (lanjutan)

Potong kembali ke maksimum

menghitung dengan benar

9. Mengubah karyawan Untuk menentukan apakah kategori cuti tahunan x

11. Bayar tidak ada Untuk menentukan apakah sistem akan x x

13. Bayar karyawan GS Untuk menentukan apakah sistem x x

Gambar 10-2 (lanjutan)

Potong kembali ke maksimum

menghitung dengan benar

14. Membayar karyawan GS Sama seperti di atas. x x

15. Bayar karyawan WB untuk 80 Untuk menentukan apakah sistem x x

16. Membayar karyawan Untuk memverifikasi keakuratan perhitungan x

17. Bayar karyawan GS untuk Sama seperti di atas. Premi = 10 persen. x

18. Bayar karyawan WB Sama seperti di atas. Premi = 7 1/2 x

19. Bayar karyawan WB selama Sama seperti di atas. Premi = 10 persen. x

Gambar 10-2 (lanjutan)

Potong kembali ke maksimum

menghitung dengan benar

21. Bayar karyawan WB Sama seperti di atas. x

23. Bayar karyawan WB Sama seperti di atas. x

24. Bayar karyawan GS Sama seperti di atas. x

Gambar 10-2 (lanjutan)

Potong kembali ke maksimum

menghitung dengan benar

25. Bayar karyawan WB Sama seperti di atas. x

27. Membayar karyawan Sama seperti di atas. Untuk karyawan GS yang x

Gambar 10-2 (lanjutan)

Potong kembali ke maksimum

menghitung dengan benar

28. Bayar GS-14 Untuk menguji batasan gaji maksimum. x x

29. Bayar GS-14 Sama seperti di atas. Program tidak boleh x

Gambar 10-2 (lanjutan)

Potong kembali ke maksimum

menghitung dengan benar

32. Bayar karyawan WB Sama seperti di atas. x x

34. Bayar karyawan WB Untuk memverifikasi keakuratan pembayaran premi. x

35. Membayar karyawan WB Sama seperti di atas. x

Gambar 10-2 (lanjutan)