BAB I

BAB I

Resiko Bisnis Ditujukan Pada Sistem Perangkat Lunak

plandocheckact

Apa itu software testing ?

Usaha pengembangan software adalah suatu proses. Siklus proses terdiri atas empat komponen sebagai berikut :

Menguji hanya melibatkan komponen cek dari plan-do-check-ack (PDCA) siklus. Pengembangan software bertanggung jawab atas ketiga komponen-komponen sisa. Regu pengembangan merencanakan proyek, membangun perangkat lunak; cek penguji untuk menentukan bahwa perangkat lunak sesuai kebutuhan dari pelanggan dan para pemakai. Peran pengujian adalah untuk memenuhi tanggung jawab cek yang ditugaskan kepada penguji; itu bukan untuk menentukan apakah perngkat lunak dapat ditempatkan ke dalam produksi yang merupakan tanggung jawab pelanggan, regu pengguna dan pengembangan.

Beberapa bagian yang terlibat dalam pengujian perangkat lunak adalah : pelanggan PL: bagian atau departemen yang menginginkan PL dibangun. pengguna PL: individu atau kelompok yang akan menggunakan PL pengguna PL: individu atau kelompok yang menerima atau mengembangkan tanggung jawab dalam menulis requirement, mendesain PL, membangun PL, dan mengubah atau memelihara PL sesuai kebutuhan.

penguji PL: individu atau kelompok yang membuat fungsi pengecekan pada PL (bisa terdiri dari bagian pengembang, kelompok independen atau kombinasi keduanya)

Manajemen pelayanan informasi: individu atau kelompok yang bertanggung jawab untuk pemenuhan misi pelayanan informasi. manajemen organisasi senior: CLO Organisasi dan eksekutif senior lainnya auditor: satu atau lebih individu yang mempunyai tanggung jawab untuk mengevaluasi keefektifan, efisiensi dan kecukupan kendali area pelayanan informasi. Pengujian akan dianggap sebagai sebuah kendali bagi fungsi audit.

Pengujian adalah teknik yang digunakan untuk menentukan apakah solusi menyelesaikan persoalan. Pengujian meliputi 3 tahap : menunjukkan kevalidan perangkat lunak pada setiap tahap pengembangan siklus hidup pengembang system. menentukan kevalidan akhir system terhadap keperluan dan kebutuhan user. pengujian watak system dengan mengeksekusi system dengan sampel data tes.

Suatu kesalahan adalah suatu perbedaan dari suatu atribut produk yang diinginkan. Ada 2 kategori kesalahan : kesalahan dari spesifikasi produk. Produk yang dibangun bervariasi dari produk yang diterapkan. variasi dari pemakai / pelanggan. Variasi ini adalah sesuatu yang diinginkan pemakai itu tidak di dalam produk yang dibangun, tetapi juga tidak diterapkan untuk tercakup di produk yang dibangun.

Masalah-masalah dalam proses dan tingkat kesalahan Kebanyakan kesalahan disebabkan oleh proses yang tidak bekerja dengan baik. Sebagai contoh, jika proses kebutuhan pemakai yang menyangkut proses itu tidak mengumpulkan informasi yang sesuai dengan itu. Jika proses pelatihan seorang programmer yang menambahkan perintah yang akan menyebabkan pengurangan terjadi, programmen akan menulis suatu garis kode kesalahan pada setiap kali ditambahkan perintah yang digunakan. Di dalam bukunya, Out of Crisis, Dr. W. Edwards Deming sering dinyatakan bahwa sedikitnya 90 persen dari semua kesalahan disebabkan oleh permasalahan proses.

Banyaknya kesalahan-kesalahan diproduksi dalam perangkat lunak yang dibangun akan tergantung pada apa yang menyangkut proses maturity, yaitu rendahnya variabilitas diijinkan di dalam proses. Sebagai contoh, semakin banyak sistem-sistem yang menyimpang dari proses yang digambarkan, semakin besar variabilitasnya. Menggunakan pengmebangan software yang ada di dalam proses kira-kira 90 persen dari semua kelompok pelayanan informasi yang dianggap sebagai proses belum maturitya atau proses dengan variabilitas besar, bisa kira-kira 60 kesalahan per ribu bentuk source program untuk diciptakan selama pengembangan. Sebagai contoh maturity, tingkat kesalahan ini berkurang.

PANDANGAN PERUSAHAAN TENTANG PENGUJIAN Pelaksana senior organisani berpikir menggunakan siklus PDCA dalam mengembangkan strategi perusahaan mereka. Perencanaan strategi diubah kedalam prakarsa perusahaan. Komponen dari rencana siklus PDCA yang dilakukan mudah untuk di mengerti. Pandangan dari pelaksana senior bahwa pemeriksaan komponen harus menunjukkan resiko dari perusahaan. Kemungkinan resikonya adalah, peristiwa yang tidak diinginkan terjadi. Peristiwa yang tidak diinginkan itu akan menghalangi organisasi tersebut dari kesuksesan menerapkan prakarsa bisnisnya. Sebagai contoh adanya resiko bahwa informasi yang digunakan dalam membuat keputusan bisnis akan menjadi salah atau terlambat. Jika resiko ini berubah menjadi kenyataan dan informasi ini terlambat atau salah, maka keputusan bisnis akan salah menyebabkan prakarsa bisnis gagal.

Alat alat kontrol merupakan cara yang digunakan oleh perusahaan untuk memperkecil resiko. Pengujian perangkat lunak adalah alat alat kontrolnya. Hal ini dapat memperkecil atau menghapuskan resiko seperti informasi yang datang terlambat atau cara yang salah dalam memproduksi. Demikianlah para pelaksana senior mengandalkan alat alat kontrol seperti pengujian perangkat lunak untuk membantu mereka dalam memenuhi tujuan perusahaan mereka.

Maksud dari alat alat kontrol seperti pengujian perangkat lunak adalah menyediakan informasi kepada pengelola sehingga mereka dapat bertindak lebih baik untuk situasi resiko tersebut.

Penguji harus memahami peran perusahaan mereka adalah untuk mengevaluasi resiko perusahaan dan untuk melaporkan hasil itu kepada pengelola. Gambaran dan pandangan tersebut, penguji harus memastikan mereka mengerti resiko perusahaan , kemudian mengembangkan uji strategi yang dipusatkan pada resiko itu. Resiko perusahaan yang paling tinggi perlu menerima lebih banyak sumber uji, sedangkan resiko perusahaan yang paling rendah perlu menerima sumber yang paling sedikit. Melalui ini, penguji diyakinkan bahwa mereka memusatkan pada hal yang penting kepada pengelola mereka berdasarkan pada penilaian sendiri.

Perangkat lunak yang didasarkan pada tanggung-jawab penguji Bagian ini menguraikan secara singkat lima tanggung-jawab test utama, komponen yang sesuai dari buku berhadapan dengan tanggung-jawab itu, dan tanggung jawab pekerjaan individu yang hampir bisa dipastikan bermanfaat bagi dari mempelajari bagian itu. Lima perangkat lunak test tanggung-jawab adalah:

Pengetahuan prinsip pengujian dan praktek- capters i saksama 3 menyediakan prinsip dan stategies yang dihubungkan dengan pengujian. ini akan kebanyakan manfaat ke senior IS manajement, para pemakai pelanggan sistim informasi, dan auditor.

Menguji strategi menunjuk mengapa pengujian harus dilakukan dan pendekatan yang paling efektif untuk memenuhi sasaran hasil test itu.

Pengujian taktik- pengujian taktik menjadi yang terperinci bagaimana cara dalam pengujian. Menguji metoda, tools, dan teknik Penilaian efektivitas pengujian adalah suatu sistem informasi spesifik

UJI KUALITAS PERANGKAT LUNAKBAB 2

Mendefinisikan Strategi Pengujian Perangkat Lunak

Mendefinisikan Strategi Pengujian Perangkat Lunak

Pengembangan Sistem Informasi adalah bagian dari problem solving. Menentukan kevalidan solusi adalah bagian dari proses. Pengujian adalah teknik yang digunakan untuk menentukan apakah solusi menyelesaikan persoalan.

Pengujian meliputi 3 tahap, yaitu : Menunjukkan kevalidan PL pada setiap tahap pengembangannya siklus hidup mengembangan sistem Menentukan kevalidan akhir sistem terhadap keperluan dan kebutuhan user Pengujian watak sistem dengan mengeksekusi sistem dengan sampel data tes

Resiko resiko Strategi Sistem Komputer Suatu resiko adalah kondisi yang dapat menyebabkan kehilangan. Suatu resiko selalu ada, walaupun kehilangan bisa tidak terjadi.

Jenis jenis resiko strategi yang diasosiasikan pada pengembangan sistem Komputer adalah :

Hasil yang tidak benar Transaksi yang tidak diizinkan akan diterima oleh sistem Kehilangan kesatuan / integritas file komputer Pemprosesan gagal direkonstruksi Pemprosesan tidak berlanjut Penurunan penyediaan pelayanan terhadap user Keamanan sistem yang kurang Pemprosesan yang bertentangan dengan kebijakan / regulasi pemerintah Hasil sistem yang tidak dapat dicapai Sistem sulit digunakan Program tidak dapat dipelihara Sistem tidak dapat berkoneksi dengan sistem lain Level performansi tidak dapat diterima Sistem sulit dioperasikanNilai Ekonomis Pengujian Permasalahan komputer umum

Akuntan kantor di U.S menyimpulkan kesalahan dalam aplikasi komputer yang mereka tinjau pada laporan yang berjudul Improvement Needed in Managing Auto mated Decision-making by Computer Throughout the federal Government (FGMSD-76-5). Hal ini beralasan bahwa permasalahan ini adalah khas pada kebanyakan sistem komputer, dengan begitu permasalahan itu harus tercakup di manapun program test. permasalahan ini menghasilkan aplikasi yang secara otomatis mulai tak ekonomis dan dapat digolongkan permasalahannya.Permasalahan perangkat lunak

Identifikasi permasalahan perangkat lunak biasanya sering disebabkan oleh keputusan yang buruk maka dibuatlah keputusan secara otomatis yang meliputi : Menentukan kriteria desain perangkat lunak yang tidak lengkap atau error dalam membuat keputusan Pencarian kesalahan program pada perangkat lunak yang disebabkan oleh konsumen atau perancang program, sehingga menghasilkan logika yang error biasanya ditunjukkan sebagai kesalahan pemprograman

Uji sebuah sistem bukan hanya sebuah isu, lebih dari itu, hal ini merupakan isu organisasi. Departemen SI dapat memverifikasikan apakah suatu struktur sistem dapat berfungsi dengan tepat, dan dapat memverifikasikan bahwa sistem dapat dieksekusi dan sesuai dengan fungsinya. Akan tetapi SI tidak dapat menguji untuk menentukan sistem yang dieksekusi itu membuat puas kebutuhan organisasi

Berikut 2 hal perkembangan teknologi yang menyebabakan suatu organisasi meninjau kembali pengujian :

1. integrasi Teknologi digunakan untu lebih mendekatkan kepada ari hari pada bisnis. Misalnya suatu bisnis tidak dapat berjalan tanpa teknologi komputer. Contoh, perusahaan penerbangan hanya dapat melakukan reservasi ketika sistem komputernya berjalan. 2. Sistem rantai Suatu komputer yang saling berhubungan pada siklus rantai, dapat mempengaruhi yang lain ketika ada suatu masalah

Pengujian kebijakan meliputi kriteria berikut : Definisi pengujian Sistem pengujian Evaluasi Standarisasi

Metode yang dapat digunakan pada pengujian kebijakan yaitu : Management yang direktif Pelayanan informasi kebijakan konsensus Bertemu pemakai

Pendekatan Terstruktur Untuk Pengujian

Jika ingin mengembangkan sistem dengan kualitas tinggi dan biaya murah, maka tahapan verifikasi/ pengujian tidak harus disendirikan dalam satu fase proses pengembangan, tapi ada di tiap tiap fase pengembangan.

Hasil studi menunjukkan bahwa umumnya kesalahan terjadi dalam fase desain. Berikut adalah gambar yang menunjukkan kesalahan sistem yang terjadi :

Pengujian yang semakin tepat dan pernyataan formal menyangkut produk pengembangan yang bersedia menerima masukan adalah suatu pengujian yang memerlukan analisa untuk mendukung verifikasi. Banyak dari metodologi pengembangan sistem yang baru mendorong produk perusahaan genap pada awal langkah-langkah pengembangan yang tepat.

Proses test yang direkomendasikan melibatkan pengujian di tiap-tiap tahap yang menyangkut jalan kehidupan. Pada tahap kebutuhan, yang ditekankan adalah ketika pengesahan untuk menentukan bahwa kebutuhan yang digambarkan memenuhi kebutuhan menyangkut organisasi. Selama tahap desain dan pemrograman, di tekankan pada verifikasi untuk memastikan bahwa program dan disain memenuhi kebutuhan yang digambarkan. Tahap pengujian dan instalasi,ditekankan pada pemeriksaan untuk menentukan bahwa sistem yang diterapkan memenuhi spesifikasi sistem. Pada tahap pemeliharaan, sistem akan diuji kembali untuk menentukan hasil perubahan dan jika tanpa perubahan maka berlanjut pada penyelesain.

Aktifitas Verifikasi Siklus Hidup

Tahap hidupJenis Aktivitas

Kebutuhan menentukan verifikasi yang mendekati menentukan kebutuhan yang cukup menghasilkan data pengujian yang fungsional menentukan kesesuaian disain dengan kebutuhan

Design Menentukan design yang cukup Menghasilkandata pengiujian struktur dan fungsional Menentukan kesesuaian dengan design

Pemrograman (membangun/memperbaiki) menentukan implementasi yang cukup Menghasilkan data pengujian struktur dan fungsiona untuk program.

Pengujian menguji system aplikasi

Instalasi menguji systemdidalam produksi

Pemeliharaan Memodifikasi dan pengujian kembali

Buku ini menguji tiap masing-masing yang menyangkut jalan kehidupan dan mendiskusikan pengujian aktivitas yang sesuai untuk tahap itu. Aktivitas berikut harus dilakukan pada beberapa tahap: Meneliti struktur produksi pada tahap ini untuk pengujian internal dan ketercukupan. Menetapkan Hasil test berdasar pada struktur pada tahap ini

Sebagai tambahan, berikut ini yang harus dilakukan selama desain dan memprogram : Menentukan struktur yang konsisten dengan struktur produksi selama tahap sebelumnya. Memperbaiki atau menggambarkan kembali test menetapkan hasil lebih awal.

KebutuhanVerifikasi aktivitas yang menemani kebutuhan dan definisi masalah anlysis tahap pengembangan software adalah sangat penting. Ketercukupan menyangkut kebutuhan harus secara menyeluruh dianalisa dan awal menguji kasus menghasilkan apa yang diharapkan (benar) jawabannya. Mengembangkan skenario dari penggunaan sistem diharapkan dapat membantu untuk menentukan arah hasil data test dan mengantisipasi. Test ini akan membentuk inti test akhir ditetapkan. Hasil test ini dan sesuai/perilaku yang diharapkan system, menjelaskan kebutuhan dan membantu jaminan yang mereka bisa menguji. Samar-samar atau Kebutuhan tidak bisa diuji akan tinggalkan kebenaran produk yang dikirimkan dengan ragu-ragu. Terlambat dalam penemuan kekurangan kebutuhan dapat sangat merugikan. Menetapkan pentingnya mutu perangkat lunak menujukan dan pentingnya harus membuat pengesahan langkah ini. Kedua-duanya kebutuhan pengesahan dan kebutuhan produk harus dibentuk/ditetapkan.

DesignOrganisasi [menyangkut] usaha verifikasi dan aktivitas manajemen test harus lekat terintegrasi dengan persiapan disain. Strategi pengujian yang umumnya mencakup metoda test dan ukuran-ukuran evaluasi test dirumuskan, dan suatu rencana test diproduksi. Jika memerlukan kritikan atau ukuran proyek, suatu regu test mandiri diorganisir. Sebagai tambahan, suatu test menjadwalkan dengan dapat mengamati kejadian waktu dibangun. Pada waktu yang sama, kerangka untuk jaminan mutu dan dokumentasi test harus dibentuk/ditetapkan.

Selama disain telah terperinci, alat pendukungan pengesahan harus diperoleh atau dikembangkan dan test prosedurnya harus diproduksi. Mengujilah data untuk melatih fungsi memperkenalkan sewaktu proses disain, seperti halnya kasus test dasar pada struktur sistem, harus dihasilkan. Seperti itu, pengembangan software berproses, suatu yang efektif satuan kasus test dibangun.

Sebagai tambahan terhadap menguji organisasi dan pembuatan kasus test, disainnya sendiri harus dianalisa dan diuji untuk kesalahan. Simulasi dapat digunakan untuk memverifikasi sifat interaksi subsistem dan struktur sistem, cara penyelesaian disain sangat digunakan oleh pengembang untuk memverifikasi arus dan struktur yang logis untuk sistem, sedangkan pemeriksaan disain harus dilakukan oleh regu test. Kasus, logika salah/cacat, modul menghubungkan tidak sepadan, struktur data ketidak tetapan, salah asumsi I/O, dan kurangnya alat penghubung pemakai dengan perhatian materi. Disain yang terperinci harus membuktikan untuk menjadi padu/sesuai, lengkap, dan konsisten dengan kebutuhan dan disain yang dipersiapan.

Pemrograman (membangun/memperbaiki)Pengujian nyata terjadi sepanjang langkah konstruksi pengembangan. Banyak alat dan teknik penguji yang ada untuk langkah pengembangan sistem ini. Kode walk-through dan kode pemeriksaan adalah teknik manual yang efektif. Teknik analisis statis mendeteksi kesalahan dengan penelitian karakteristik program seperti pemakaian bahasa dan arus data. Untuk ukuran program yang penting, mengotomatiskan alat, apakah diperlukan untuk melaksanakan analisa ini. Analisa dinamis, melakukan pengkodean yang benar-benar dilaksanakan, digunakan untuk menentukan pemenuhan test sampai berbagai teknik instrumentasi. Teknik verifikasi formal atau bukti adalah digunakan untuk menyediakan jaminan mutu lebih lanjut.

PengujianSepanjang proses test, hati-hati mengendalikan dan pengolahan informasi test atau kritis. Test menetapkan, hasil percobaan, dan laporan test harus disimpan dan didaftarkan di dalam suatu database. Karena nyaris sistem sangat kecil, mengotomatiskan perkakas adalah diperlukan untuk melakukan suatu pekerjaan, pekerjaan pembukuan sehari-hari sendiri menjadi terlalu besar untuk ditangani dengan tangan. Suatu pengarah test, membantu meneruskan data test, memenuhi alat penguji, membantu mengolah hasil percobaan, dan memberikan laporan apakah sesuai pada umumnya yang diperlukan.

InstalasiProses penempatan menguji program ke dalam produksi adalah suatu tahap penting yang secara normal dieksekusi di dalam suatu bahasa Spanyol dalam waktu singkat. Selama menguji tahap ini harus memastikan bahwa versi yang benar di program apakah sesuai ditempatkan ke dalam produksi; jika data itu ditambah atau diubah benar; dan bahwa semua kelompok dilibatkan mengetahui tugas-tugas mereka yang baru dan dapat melaksanakannya dengan tepat.

PemeliharaanLebih dari 50 persen biaya-biaya pembuatan suatu perangkat lunak sistem adalah dibelanjakan oleh atas pemeliharaan/maintenance. Ketika sistem digunakan, itu dimodifikasi yang mana untuk mengoreksi kesalahan atau untuk meningkatkan sistem yang aslinya. Setelah dimodifikasi masing-masing sistem harus diuji kembali. Seperti menguji kembali aktivitas factor-faktor kemunduran. Gol pengujian kemunduran adalah untuk memperkecil ongkos pengesahan kembali sistem. Yang pada umumnya hanya bagian sistemnya yang dilibatkan oleh modifikasi apakah diuji kembali. Bagaimanapun, berubahan pada tingkatan manap saja boleh mengharuskan test kembali, memverifikasi kembali, dan memperbaharui dokumentasi pada semua tingkat di berikutnya. Sebagai contoh, suatu perubahan disain memerlukan verifikasi kembali disain, menguji kembali unit, dan menguji kembali subsistem. Ujilah kasus yang dihasilkan selama pengembangan sistem apakah digunakan kembali atau digunakan setelah modifikasi sesuai. Mutu dokumentasi test yang dihasilkan selama pengembangan sistem dan yang dimodifikasi selama pemeliharaan akan mempengaruhi factor-faktor kemunduran pengujian. Jika test data kasus telah jadi dipelihara dan penataan, duplikasi usaha akan jadi diperkecil.

Sasaran pengujian adalah untuk mengurangi resiko yang tidak bisa dipisahkan di dalam sistem komputer. Strategi harus menunjuk resiko dan memberikan suatu proses yang dapat mengurangi resiko itu. Sistem saling berhubungan atau kemudian resiko menetapkan hasil sasaran untuk memproses pengujian. Dua komponen strategi pengujian adalah faktor Pengujian dan tahap Pengujian, digambarkan sebagai berikut: Faktor pengujian - Resiko atau isu yang perlu untuk ditujukan sebagai bagian dari strategi pengujian. Strategi akan memilih faktor yang perlu untuk ditujukan di dalam uji coba suatu sistem aplikasi spesifik. Tahap pengujian - Tahap siklus hidup pengembangan sistem di mana pengujian akan terjadi.Tidak semua faktor pengujian akan dapat digunakan untuk semua perangkat lunak sistem. Tim pengembangan akan membutuhkan untuk memilih dan menggolongkan faktor pengujian untuk perangkat lunak sistem yang spesifik yang sedang dikembangkan. Pertama kali ketika memilih dan mengatur, strategi untuk pengujian secara parsial akan digambarkan.

Tahap pengujian akan saling bertukar berdasar pada penggunaan metodologi pengujian. Sebagai contoh, Tahap pengujian menggunakan secara metodologi tradisional waterfall siklus hidup akan jauh lebih berbeda dari tahap di suatu metodologi sekarang seperti IBM' s AD/CYCLE.

Tes FaktorContoh

KetepatanMenjamin :Harga produk sesuai dengan fakturPembayaran harus di kalkulasiInventory yang ada sesuai dengan akumulasi

KesesuaianMenjamin :Harga disesuaikan oleh manajemenNilai untuk produk yang kembali telah disetujui oleh manajemenPembayaran pekerja yang lembur disesuaikan oleh supervisor

Integritas FileMenjamin :Jumlah detail record pada file mendukung total kendaliAlamat-alamat pelanggan harus benarRata-rata pembayaran pekerja harus benar

Tes FaktorContoh

Pengecekan keuanganMenjamin :Pembayaran pekerja dapat terjamin oleh dokumentasi yang mendukungPembayaran pajak penjualan pada sebuah Negara dapat terjamin oleh fakturPembayaran produksi untuk vendor dapat terjamin jika vendor tidak mengingkari dalam penerimaan pembayaran

Kelangsungan ProsesMenjamin :Transaksi dengan bank dapat berlangsung jikacomputer menjadi tidak operasionalPemulihan online system dapat terjadi dengan toleransi factor penentu

Tes FaktorContoh

Tingkat PelayananMenjamin :Waktu respon pada online system dengan toleransi waktuPemuatan waktu aplikasi dapat diselesaikan dengan penjadwalan aplikasiPergantian system dapat disesuaikan dengan jadwal

Kontrol AksesMenjamin :Programer tidak akan memberikan ijin untuk mengakses dataAkses akan dibatasi oleh systemMekanisme akses secara otomatis akan digunakan

Faktor TesDalam mendesain sebuah strategi pengujian, factor resiko menjadi sebuah basic atau objektif dari pengujian. Resiko dihubungkan dengan pengujian yang akan disebut dengan Test Factors pada buku ini. Sebenarnya factor tes itu sendiri tidak beresiko, mereka merupakan atribut dari software itu sendiri, jika mereka diinginkan dan tidak saat ini, sikap sebuah resiko agar sebuah software sukses, dan itu merupakan resiko bisnis. Sebagai cotoh, jika sebuah software tidak mudah digunakan, hasil sebuah pemrosesan mungkin tidak benar. Sebuah tes proses dapat mengurangi factor tes tersebut untuk ke level pengkhususan. Sebuah definisi factor tes berguna untuk tes proses untuk membangun sebuah logika seperti bagian lain pada layanan informasi.

Faktor-faktor Ujian: Ketepatan Integritas file Otorisasi Jejak audit Kesinambungan pengolahan Kwalitas pelayanan Kendali akses Pemenuhan Keandalan Rampas Penggunaan Maintabilitas Portabilitas Penggabungan Kinerja END

Pengembangan Taktik Pengujian Perangkat Lunak

Konsep WORKBENCHPendefinisian workbenches pada umumnya adalah tanggung jawab dari sebuah komite manajemen proses, yang sebelumnya lebih sering ditunjuk sebagai suatu komite standar. Ada 4 komponen untuk masing-masing workbench : Input : kriteria masukan atau yang bisa dikirimkan yang dibutuhkan untuk mewujudkan pekerjaan. Prosedur untuk mengerjakan : tugas-tugas kerja atau proses-proses yang akan mengubah input menjadi output Prosedur Pengecekan : proses-proses yang menentukan bahwa outputnya memenuhi standar standar yang ditentukan. Output : criteria keluaran atau yang dapat dikirimkan diproduksi dari workbench.

Catatan : toolsare tidak dianggap dari bagian workbench karena mereka tidak digabungkan baik kedalam prosedur-prosedur untuk mengerjakan atau prosedur untuk pengecekan. Konsep workbench dapat digunakan untuk menggambarkan langkah-langkah yang ada dalam system yang dibangun.Workbench programmer terdiri dari langkah-langkah ini : Memasukkan produk-produk (spek program) ditentukan untuk prosedur. Pekerjaan yang diwujudkan (Coding/debbuging), prosedur yang diikuti; sebuah produk atau yang bisa dikirimkan sementara untuk diproduksi. Pekerjaan dicek untuk meyakinkan produk memenuhi spesifikasi, standar,dan prosedur-prosedur yang diikuti. Apabila tidak ditemukan masalah, produk dilepas untuk produk workbench slanjutnya. Apabila ditemui masalah produk dikirim kembali untuk dikerjakan ulang.

Definisi-definisi pengujian dan konsep-konsep Pengawasan kualitas (pengawasan kualitas prosedur pengujian/cek workbench)1) proses-proses dimana pembetulan produk ditentukan dan aksi diawali ketika ketidak sesuaian dideteksi.2) fungsi urutan; pekerjaan yang dilakukan didalam sebuah proses untuk menjamin bahwa produk pekerjaan sesuai dengan standar/ syarat.

Jaminan kualitas 1) serangkaian sistematik dan terencana dari aktivitas-aktivitas perlu untuk menjamin produk dan jasa bebas kerusakan.2) fungsi staf, diciptakan untuk mendukung pelaksanaan menejemen kualitas keseluruhan.

Cacat :1) Suatu penyimpangan dari spesifikasi; yang hilang. salah. atau ekstra ( pandangan produsen). 2) Semua yang menyebabkan ketidak puasan pelanggan, baik di dalam spesifikasi atau bukan (pandangan pelanggan). Verifikasi merupakan semua aktivitas QC sepanjang seluruh lingkaran kehidupan yang memastikan bahwa produk mampu menemukan spesifikasi masukan mereka.

Validasi adalah " tahap pengujian " tentang lingkaran kehidupan, yang memastikan bahwa akhir/hasil produk menemui spesifikasinya. Pengujian Verifikasi Statis dilakukan tanpa melaksanakan pengkodean sistem.

Pengesahan Pengujian Dinamis atau Verifikasi dilakukan itu melaksanadengan mengeksekusi kode sistem.Kategori Test: Unit-Testing dilakukan pada posisi tunggal unit atau modul dari kode. Pengintegrasian - Pengujian dilakukan pada kelompok atau modul untuk memastikan kendali dan data dihantar dengan baik antar modul. Sistem:1. mengantisipasi kombinasi test yang ditentukan ketika dieksekusi dengan sukses, memuaskan manajemen ISIOP bahwa sistem memenuhi persyaratan ( yaitu., mengesahkan sistem dibangun dengan tepat);2. Suatu istilah umum yang membedakan jenis pesanan pengujian yang lebih tinggi dari unit penguji. Persetujuan pengujian (Accepted Testing) untuk memastikan bahwa sistem memenuhi kebutuhan menyangkut organisasi dan pengguna akhir atau pelanggan ( yaitu., mengesahkan bahwa sistem yang dibangun benar). Pengujian regresi setelah perubahan dibuat, untuk memastikan tidak mencari perubahan yang diperkenalkan.

Test Fungsional- Test kebutuhan bisnis (apa yang sistem harus lakukan).

Struktural Tests-Tests yang mengesahkan arsitektur sistem ( bagaimana sistem diterapkan). Black-Box Testing-Testing berdasar pada spesifikasi eksternal tanpa pengetahuan bagaimana sistem dibangun ( Lihat Gambar 3.4 untuk suatu perbandingan antara Black-Box Testing dan White-Box Testing). Umumnya, data sebagai pengendali. White-Box Testing-Testing yang didasarkan pada pengetahuan dari struktur kode internal dan logika. Umumnya logika sebagai pengendali.

Delapan langkah mengembangkan taktik pengujian :1. Memperoleh dan Mempelajari Strategi Testing Strategi Testing biasanya dibangun oleh tim yang telah terbiasa dengan resiko urusan diasosiasikan dengan perangkat lunak. Taktik dibangun oleh tim penguji. Termasuk kebutuhan dari tim penguji untuk memperoleh dan mempelajari strategi test. Dalam pembelajaran ini, tim penguji harus menanyakan hal berikut : Apa hubungan dari kepentingan di antara faktor test? Yang mana resiko tingkat tinggi paling signifikan? Kerusakan apa yang bisa terjadi terhadap pekerjaan, jika perangkat lunak gagal ke melakukan dengan tepat? Kerusakan apa yang bisa terjadi terhadap pekerjaan, jika perangkat lunak tidak terselesaikan tepat waktu? Siapa individu paling mengetahui dalam pemahaman dampak identifikasi resiko bisnis?2. Menentukan pengembangan tipe dari pengembangan proyekTipe proyek mengacu pada lingkungan/metodologi dimana perangkat lunak akan dikembangkan. Sebagai contoh, resiko-resiko yang berkaitan dengan usaha pegembangan tradisional berbeda dari resiko yang berkaitan dengan perangkat lunak.Pendekatan pengujian yang berbeda harus digunakan untuk tipe proyek yang berbeda, tepat seperti pendekatan pengembangan yang berbeda digunakan.3. Menentukan tipe dari system perangkat lunakTipe dari system perangkat lunak mengacu pada pemrosesan yang akan dilakukan oleh system tersebut. Langkah ini terdiri dari 16 tipe system perangkat lunak yang berbeda. Akan tetapi, system perangkat lunak tunggal mungkin menggabungkan lebih dari satu dari tipe ini. Mengidentifikasi kombinasi spesifik perangkat lunak pembangunan proyek bisa menolong menganalisa pelajaran-pelajaran yang dipelajari dari proyek yang terdahulu dengan tipe perangkat lunak yang sama.Tipe Karakteristik Taktik tes

Pengembangan system tradisional Menggunakan metodologi pengembangan system Pengguna tahu kebutuhan Pengembangan menentukan struktur Pengujian diakhir dari masing masing tugas/ langkah/ Fase Memverifikasi bahwa spesifikasi cocok dengan kebutuhan Menguji fungsi dan struktur

Pengembangan berulang/ prototype/ CASE Kebutuhan tidak diketahui Struktur dibatasi Memverifikasi bahwa alat CASE digunakan dengan tepat Memverifikasi prototype cocok dengan kebutuhan Pengujian fungsionalitas

Perawatan system Memodifikasi struktur Pengujian struktur Pekerjaan baik dengan metode peluncuran Memerlukan pengujian regresi

Perangkat lunak yang dibeli Struktur tidak diketahui Mungkin terdapat kerusakan Fungsionalitas dibatasidi didalam dukumentsi pengguna Dokumentasi mungkin berbeda dari perangkat lunak Memverifikasi fungsionalitas cocok dengan kebutuhan Pengujian fungsionalitas Pengujian cocok didalam lingkungan

A. Golongan (umum) - bisa dijalankan sebagai pekerjaan normal golongan dan membuat tidak ada aksi masukan/keluaran perangkat keras yang tidak biasa.B. Control kejadian mengerjakan proses real-time hasil data dari kejadian eksternal. Sebuah contoh mungkin program computer yang memproses data telemetri.C. Control proses menerima data dari sumber eksternal dan mengeluarkan perintah untuk sumber tersebut untuk mengontrol aksinya berdasarkan data yang diterima.D. Control prosedur mengontrol perangkat lunak lain. Sebagai contoh system operasi yang mengontrol eksekusi dari time shared dan golongan computer program.E. Model matematika maju menyerupai simulasi dan perangkat lunak strategi bisnis. Tapi memiliki kompleksitas tambahan dari penggunaan matematika yang banyak.F. Pemrosesan pesan menangani pesan masuk dan keluar, memroses teks, atau informasi yang terkandung didalamnya.G. Diagnose perangkat lunak mendeteksi dan mengisolasi error perangkat keras computer dimana perangkat lunak tersebut diam atau diperangkat keras lain yang bisa berkomunikasi dengan computer tersebut.H. Sensor dan pemrosesan sinyal menyerupai pemrosesan pesan, tepi membutuhkan proses yang lebih besar untuk menganalisa dan merubah masukan kedalam format pemrosesan data yang bisa digunakan.I. Simulasi mensimulasikan lingkungan situasi misi, perangkat keras lain: masukan dari ini untuk memungkinkan evaluasi yang lebih realistic dari program computer atau potongan perangkat keras.J. Manajemen basis data manajemen penyimpanan dan akses dari ( biasanya luas) grup-grup data. Perangkat lunak tersebut bisa juga menyiapkan laporan dalam format yang didefinisikan pengguna berdasarkan isi dari basis data.K. Akuisisi data menerima informasi secara waktu nyata dan menyimpannya dalam beberapa bentuk yang cocok untuk pemrosesan selanjutnya. sebagai contoh, perangkat lunak yang menerima data dari ruang penyelidikan dan merangkainya untuk analisis selanjutnya.L. Presentasi data memformat dan mengubah data seperlunya, untuk tampilan yang nyaman dipakai dan bisa dimengerti oleh manusia. Biasanya, tampilan itu untuk beberapa layar presentasi.M. Keputusan dan bantuan perencanaan menggunakan teknik kecerdasan buatan untuk menyediakan system pakar untuk mengevaluasi data dan menyediakan informasi tambahan dan pertimbangan untuk keputusan dan pembuat kebijakan.N. Pola dan pemrosesan citra menghasilkan dan memproses citra computer, perangkat lunak tersebut menganalisa lapangan data dan menghasilkan citra berdasarkan data yang tersimpan.O. Perangkat lunak system computer menyediakan servis untuk operasi program computer (misal, koordinasi pemrosesan komponen yang diperlukan untuk memenuhi kebutuhan).P. Alatalat pengembangan perangkat lunak menyediakan layanan untuk membantu pengembangan perngkat lunak ( misal, compiler, assembler, penganalisa statis dan dinamis).

4. Menentukan bidang proyekBidang proyek adalah seluruh aktifitas yang tergabung dalam system perangkat lunak yang sedang dites hal-hal mengenai spesifikasi/kebutuhan system yang perlu dipahami. Bidang dari pengembangan system baru berbeda dengan bidang dari pengubahan system yang telah ada. Langkah ini menjelaskan beberapa karakteristik yang dibutuhkan, tapi daftar ini harus diperluas untuk meliputi kebutuhanspesifik dari system perangkat lunak yang sedang di tes. Bidang dari proyek biasanya membatasi bidang dari usaha pengetesan. Pertimbangkan hal-hal berikut:

A. Pengembangan system baru: mengotomatiskan proses normal pada bisnis? proses bisnis yang mana yang akan/ tidak akan terpengaruhi? area bisnis yang mana yang akan/tidak terpengaruh? meng-interface-kan system yang sudah ada? system yang sudah ada akan tidak akan terpengaruh?

B. Perubahan pada system yang sudah ada: Apakah hanya memperbaiki? Apakah memelihara standarstandar teknis? Perbaikan untuk mengetahui cacat tersembunyi ditambah untuk peningkatan? sistem lain mempengaruhi? resiko regresi?

5. Identifikasikan Resiko TaktisResiko perencanaan merupakan urusan resiko tingkat tinggi dihadapi oleh sistem perangkat lunak; resiko taktis subset tingkat yang lebih rendah resiko strategis. Tujuan decomposing resiko strategis ke resiko taktis adalah untuk membantu membuat skenario percobaan yang akan alamat resiko itu. Sulit membuat skenario percobaan untuk resiko tingkat tinggi.Resiko taktis dibagi ke tiga kategori: Membangun resiko: resiko berasosiasi dengan aplikasi dan metode menggunakan membangun aplikasi Resiko teknis: resiko berasosiasi dengan teknologi menggunakan di membangun dan mengoperasikan aplikasi Ukuran resiko: resiko berasosiasi dengan besarnya dalam semua segi perangkat lunak

Workpaper 3.1, 3.2 dan 3.3 menyediakan metode untuk menaksir membangun, teknis, dan resiko ukuran. ini workpaper untuk;menjadi selesai oleh regu percobaan saling berinteraksi dengan pengembangan dan memilih akhir pengguna/costomer. setiap workpaper mengidentifikasi resiko, kelas untuk resiko, dan berat berasosiasi dengan resiko. pengenalan resiko dan berasosiasi berat disediakan sebagai bagian dari proses penilaian resiko taktis. berat penanda penghubung pentingnya setiap resiko di hubungan kepada resiko lain.

Untuk menyelesaikan sebuah workpaper, ikuti langkah-langkah berikut: Langkah 1 : pahami resiko dan menyediakan kelas untuk resiko itu. di paling hal, kelas akan [jadi] nilai 1 melalui 4, dengan penjelasan kolom kelas resiko workpaper. Langkah 2 : tentukan kelas yang dapat dipakai untuk menguji sistem perangkat lunak. Pilih salah satu dari daftar kelas untuk setiap resiko dan tempat ini di kolom kelas workpaper. Sebagai contoh, dalam membangun penilaian resiko, jika kamu bertekad bahwa berarti setiap waktu mayor terakhir dirubah untuk urusan lebih dari dua tahun, kamu akan mencatat bahwa kelas rendah menandakan, dan meletakkan 1 di kolom kelas. Langkah 3 : hitung dan akumulasikan nilai resiko. kelas kamu menyediakan di kolom kelas harus berlipat dengan berat untuk memperoleh sebuah nilai. Nilai untuk setiap workpaper akan diakumulasi dan menempatkan total nilai untuk workpaper 3.4(nilai analisis resiko workpaper). Bila Workpaper telah lengkap, kamu akan mempunyai penempatan nilai untuk nilai analisis resiko workpaper

Untuk melengkapi Nilai Analisis Resiko Workpaper, ikuti langkah-langkah berikut : Langkah 1 : hitung nilai rata-rata resiko untuk daerah resiko. Lakukan ini, jumlah nomer resiko di dalam worpaper dan membagi menjadi jumlah nilai workpaper 3.4 untuk memperoleh nilai rata-rata bagi daerah-daerah resiko. Lakukan hal yang sama untuk jumlah nilai resiko untuk software. Langkah 2 : Tempatkan kelas berdasarkan perbandingan. Setelah kamu mengerjakan resiko workpaper sebuah nomer waktu, kamu akan menghasilkan nilai rata-rata untuk sistem aplikasi anda. Perolehan total nilai untuk system aplikasi anda dan tingkat mereka dari tinggi ke rendah untuk setiap daerah resiko. Saat menentukan sebuah rata-rata untuk nilai tertinggi ketiga, nilai tengah ketiga dan nilai paling rendah ketiga. Rata-rata ini adalah komulatif kelas untuk aplikasi perusahaan anda, dan dapat selamanya dicatat dalam workpaper 3.4. Ini akan memungkinkan anda untuk membandingkan nilai sistem anda yang diuji kembali berdasarkan perbandingan kelas-kelas kamu dapat menentukan apakah sistem anda bekerja secara baik, sedang atau resiko rendah di setiap daerah resiko dan keseluruhan. Langkah 3 : daftar dasar workpaper 3.4 semua atribut resiko untuk worksheet menerima kelas resiko tinggi. Mengenal daerah (sebagai contoh, struktur) dan daftar spesifik resiko itu memberi sebuah kelas tinggi. Kemudian, untuk setiap resiko itu memberi perhatian test khusus dan datar workpaper 3.4

Jika proses penilaian telah lengkap, resiko taktis akan tergambar dengan baik, memungkinkan kepandaian untuk memahami setiap langkah untuk menanamkan ke rencana percobaan. Jelas, daerah-daerah resiko tinggi mungkin membutuhkan perhatian spesial; sebagai contoh, jika ukuran menaruh proyek di sebuah kelas resiko tinggi, maka usaha test ektra mungkin akan dibutuhkan, pusat memastikan sistem dapat mengendalikan volume atau ukuran trasaksi ditetapkan untuk software. Mengenai percobaan dapat dialamatkan dengan test khusus dirancang untuk evaluasi jarak resiko dan kecukupan kendali di sistem untuk alamat resiko.

6. Tentukan Bila Ujian Harus TerjadiSebelum langkah-langkah mengenali tipe proyek pengembangan, tipe sistem software, lingkungan proyek dan resiko teknis. Gunakan informasi, batas proses pengembangan bila test akan terjadi harus bertekad. Sebelum langkah-langkah mengenali apa tipe pengujian yang dibutuhkan terjadi, dan langkah ini akan memberitahukan kapan harus terjadi.Pengujian dapat dan harus terjadi sepanjang tahap sebuah proyek. Contoh aktivitas pengujian untuk melakukan selama tahap ini.A. Persyaratan tahap aktifitas Menentukan stategi pengujian Menentukan syarat kecukupan Menghasilkan kondisi pengujian fungsional

B. Desain tahap aktifitas Menentukan desain konsisten dengan keperluan Menentukan kecukupan desain Menghasilkan struktur dan kondisi pengujian fungsional

C. Program(membuat)tahap aktifitas Menentukan konsistensi dengan desain Menetukan kecukupan implementasi Menghasilkan struktur dan kondisi pengujian fungsional untuk program/satuan-satuan

. Uji tahap aktifitas " Menentukan yang menyangkut rencana pengujian" Uji sistem aplikasi E. tahap instalasi Aktivitas" Tempat menguji sistem ke dalam produksi F. tahap pemeliharaan Aktivitas" Modifikasi dan pengujian sebelumnya"

7. Membangun dan merencanakan suatu sitem pegujian Suatu rencana pengujian taktis harus dikembangkan untuk menguraikan kapan dan bagaimana caranya pengujian akan terjadi. Rencana pegujian ini akan menyediakan latar belakang informasi pada perangkat lunak yang sedang diuji, sasaran pegujian dan resiko, atas kepentingan dinas berfungsi untuk menjadi pegujian yang spesifik untuk dilakukan. Informasi atas bagaimana cara menciptakan detil dari rencana pegujian diuraikan pada sebagian 2 buku ini. acuan Bagian lain yang menyangkut buku ini untuk metodologi pengembangan. selain dari metedologi air terjun sebagai contoh, bab 15 sistem alamat klien server. Pegujian menjadi jalan pemetaan itu akan diikuti di dalam pelaksanaan pengujian. Rencana kemudian dirancang ke dalam pengujian spesifik dan rencana tingkat yang lebih rendah. Setelah pelaksanaan, kemudian hasil digulung sampai kepada hasil suatu laporan pengujian.Laporan tes pegujian tercantum di bab 20 buku ini yang dirancang di sekitar pegujian Perencanaan standarisasi. Merekomendasikan standar rencana test yang digambarkan di dalam figur 3.7. Adalah konsisten kebanyakan dari test diterbitkan merencanakan standar yang diterima.

8. Membangun Unit rencana pegujian Selama disain internal, sistem dibagi ke dalam unit atau komponen yang melakukan pengolahan yang terperinci. Masing-Masing unit ini perlu mempunyai rencana sendiri. Rencana dapat sederhana atau kompleks yang diharapkan pada mutunya. Yang penting untuk suatu rencana pegujian unit akan menentukan pengujian unit yang lengkap.Hal ini merupakan suatu gagasan yang tidak baik yang secara ekonomis untuk menyampaikan unit yang berisi kecacatan ke untuk tingkat pengujian yang lebih tinggi. Jadi, usaha ekstra dibelanjakan di dalam pegujian unit yang mengembangkan,merencanakan, menguji unit, dan yang meyakinkan unit adalah cacat sebelum membebaskan pengujian pengintegrasian dapat mempunyai payback(uang kembali) ini penting untuk mengurangi keseluruhan biaya-biaya pegujian. Suatu rencana test unit diusulkan diperkenalkan di didalam figur 3.8. Pegujian unit ini Rencananya konsisten secara luas pengujian unit yang diterima merencanakan standar. Bahwa pengujian yang melaporkan didalam bab 20 untuk unit berasumsi bahwa suatu test unit distandardisasi menggunakan perencanaan.

Berapa banyak waktu harus dihabiskan pada suatu taktik? Salah satu dari perkataan yang paling tua adalah " jika kamu gagal untuk merencanakan tidak apa apa bagi kebenaran pengujian. Waktu yang dihabiskan didalam perencanaan pegujian secara normal diganti banyak dengan pengujian yang lebih efektif dan efisien. Sebagai petunjuk, sekitar sepertiga total waktu test harus dihabiskan didalam strategi dan perencanaan taktis. Berkaitan dengan itu, kebanyakan dari waktu yang kira-kira 90 persen harus dihabiskan pada taktik. Di penyelesaian ini bagian dari pengujian, adalah sebaiknya untuk menjaga suatu pemeriksaan rencana pengujian. Bab 14 menyediakan suatu metodologi untuk memeriksa rencana pengujian.

Standar tes perencanaan system1. INFORMASI UMUM1.1. Rangkuman. Merangkum fungsi-fungsi pada software dan tes-tes yang akan dilakukan.1.2. Lingkungan dan Latar Belakang Pretest. Merangkum alur dari proyek. Mengindentifikasi spesifikasi tempat dan computer pengguna dimana test akan dilakukan. Menjelaskan beberapa test yang sudah dilakukan catatan dari hasilnya yang mempengaruhi test.1.3. Tujuan dari Test. Suatu keadaan yang harus dipenuhi oleh testing.1.4. Kadar Kecacatan. Perkiraan jumlah kecacatan untuk software.1.5. Referensi. Daftar referensi yang dapat dipakai, seperti :1. Pemberi wewenang yang meminta proyek2. Dokumen yang diterbitkan sebelumnya pada proyek.3. Dokumentasi yang berhubungan dengan proyek tersebut.2. PERENCANAAN2.1. Deskripsi Perangkat Lunak. Melengkapi grafik dan menjelaskan dengan singkat tentang input, output, dan fungsi-fungsi dari PL yang yang sedang dites sebagai kerangka deskripsi dari test.2.2. Tim Testing. Siapa yang berada di tim testing dan tugas dari timnya.2.3. Penjadwalan. Daftar dari lokasi, kegiatan dan tanggal dari test.2.4. Budgets. Daftar biaya yang dialokasikan dan checkpoint.2.5. Testing (checkpoint sistem). Identifikasi orgasisasi yang berpartisipasi dan chechkpoint system dimana PL akan ditest. 1. Perencanaan dan biaya. Menunjukkan jadwal yang mendetail tentang tanggal dan kegiatan pada suatu lokasi. 2. Kebutuhan, yang mencakup :i. Perlengkapan. Memperlihatkan periode penggunaan, tipe, dan jumlah dari perlengkapan yang dibutuhkan.ii. Perangkat Lunak. PL lain yang mungkin diperlukan untuk mendukung testing.iii. Anggota. Jumlah dan keahlian anggota yang tersedia baik dari pengguna maupun developer.

3. Testing Bahan, seperti :i. Dokumentasi sistemii. PL yang akan di uji dan medianya.iii. Input testiv. Dokumentasi inputv. Peralatan test4. Pelatihan pengujian. Menjelaskan rencana untuk melengkapi pelatihan dengan tujuan dari PL yang diuji. Menspesifikasi tipe-tipe pelatihan, anggota yang akan dilatih dan staff pelatihan.5. Pengelolaan test. Merinci test ke yang lebih spesifik.2.6. Testing (checkpoint system). Menjelaskan tentang perencanaan kedua dan checkpoint system yang berikutnya dimana PL akan diuji dimana PL akan diuji seperti pada 2.5.3. SPESIFIKASI DAN EVALUASI3.1. Spesifikasi1. Fungsi Bisnis. Daftar dari kebutuhan bisnis fungsional yang diperlukan yang telah dijelaskan oleh dokumentasi sebelumnya (deskripsi PL, 2.1).2. Fungsi Struktural. Daftar dari detail funsi structural yang akan dilatih saat test keseluruhan.3. Hubungan antar Fungsi. Daftar dari test yang akan dilakukan pada PL dan menghubungkannya ke fungsi fungsi diatas.4. Test Kemajuan. Menjelaskan kemajuan yang dibuat dari 1 test ke test selanjutnya agar siklus test terpenuhi.3.2. Metode dan keharusan1. Metodologi. Metode umum yang digunakan untuk testing.2. Perangkat Test. Spesifikasi dari perangkat pengujian yang digunakan.3. Jangkauan. Mengindikasikan jangkauan dari pengujian seperti : keseluruhan atau sebagian. 4. Pencatatan data. Mendiskusikan metode yang digunakan untuk mencatat data hasil test dan informasi lain tentang test tersebut.5. Keharusan. Mengindikasikan antisipasi keterbatasan pada saat test yang mengarah pada kondisi test, seperti interfaces, perlengkapan, anggota dan basis data.3.3. Evaluation1. Kriteria. Aturan yang digunakan untuk mengevaluasi hasil test, seperti jangkauan dari nilai data yang digunakan, kombinasi dari input, jumlah maksimal dari interupsi yang diijinkan.2. Reduksi Data. Teknik yang digunakan untuk memanipulasi data test ke bentuk yang cocok untuk evaluasi. 4. TEST DESCRIPTIONS4.1. Identifkasi Test. Menjelaskan tentang test yang akan dilakukan,1. Kontrol. Kontrol test, seperti manual, semiotomatis, atau input otomatis, susunan operasi, dan hasil pencatatan.2. Input. Input data dan input perintah yang digunakan dalam test.3. Output. Output data yang diharapkan sebagai hasil test dan beberapa pesan-pesan yang diproduksi.4. Prosedur. Menspesifikasi langkah-langkah dari prosedur untuk menyelesaikan test. Termasuk didalamnya setup test, inisialisasi, langkah dan terminasi.4.2. Identifikasi test. Perencanaan kedua dan test berikutnya dimana hampir sama dengan test di atas.

PENDEKATAN PENGUJIAN SIKLUS HIDUPPengujian siklus hidup berarti pengujian kemampuan secara paralel dengan pengembangan sistem. Selagi sistem dikembangkan, sebagai suatu rencana pengujian dan kondisi pengujian dikembangkan dan dieksekusi. Pada poin-poin yang ditentukan sepanjang siklus hidup, sistem diuji untuk memastikan bahwa system dikembangkan dengan baik dan dapat mendeteksi cacat cacat yang ada pada titik yang mungkin paling awal pada siklus hidup tersebut. Bab ini menjelaskan konsep dan metode menggunakan pengujian siklus hidup. Pendekatan pengujian siklus hidup, selagi muncul secara luas, perancangan akan mengurangi biaya pengujian. Bab ini menguraikan biaya biaya pengujian dan dan efek dari pengujian siklus hidup atas biaya biayanya.BIAYA DARI PENGUJIAN KOMPUTERAda dua kategori umum dari pengujian sebelum implementasi dan tonggak implementasi pengujian. Yang pertama meliputi aktivitas yang terjadi sebelum menempatkan sistem aplikasi dalam status operasional. Sasaran dari pengujian sebelum implementasi adalah untuk msenentukan bahwa fungsi sistem seperti yang ditetapkan dan kerusakan pada sistem dipindahkan sebelum system ditempatkan/ diteruskan pada produksi. Jenis yang kedua dari pengujian terjadi setelah system mulai dioperasikan dan secara normal mulai dipertimbangkan bagian dari pemeliharaan system.Ongkos membersihkan kecacatan system sebelum system memasuki produksi meliputi: Membuat cacat kedalam system Mengidentifikasi keberadaan dari cacat itu Mengoreksi cacat itu Pengujian untuk menentukan bahwa cacat dibersihkanCacat ditemukan setelah system mulai menghasilkan operasi biaya biaya berikut: Penetapan dan pengcodingan kedalam system Mendeteksi masalah didalam system aplikasi Melaporkan masalah ke layanan informasi atau user Mengoreksi masalah yang disebabkan oleh cacat tersebut1. beroperasi sistem sampai cacat dikoreksi.1. mengoreksi cacat.1. pengujian untuk menentukan yang cacat tidak ada lagi.1. mengintegrasikan yang dikoreksi program ke dalam produksi.pengujian perlu meliputi banyak beban biaya untuk menguji cacat yang tidak diketahui. beberapa organisasi mapan semua nama biaya biaya digunakan sebagai biaya coba coba. oleh karena itu, biaya coba - coba jarang dikenal untuk suatu organisasi. pengujian secara normal dianggap sebagai proses yang digunakan untuk temukan cacat dan meyakinkan bahwa sistem berfungsi dengan baik. bagaimanapun, ketika digambarkan, biaya membangun dan cacat mengoreksi jauh melebihi ongkos pendeteksian cacat itu.Nasional Kantor Standard telah memperkirakan bahwa menguji, mencakup koreksi cacat tidak membongkar sampai aplikasi memasuki produksi, meliputi sedikitnya satu setengah menyangkut kesisteman total pengembangan usaha. Biaya yang mahal cacat sistem disikapi dengan dua tantangan ke organisasi: bagaimana cara mengukur biaya pemindahan cacat dengan benar, dan bagaimana cara mengurangi biaya percobaan itu.mengukur biaya pemindahan cacatinstitut jaminan berkualitas mensurvei bahwa ada kira-kira 60 cacat didalam suatu sistem aplikasi per 1.000 pernyataan sumber, atau padanan. survei ini menunjukkan bahwa approximatelytwo-thirds, atau 40 ke luar dari cacat per 1.000 bentuk program terbuka, terjadi di dalam kebutuhan dan tahap desain sistem aplikasi. Kemudian, sementara cacat secara normal terdapat didalam tahap percobaan dalam sistem sistem daur pembangunan hidup ini terjadi pada awal awal proses.cacat membangun ke dalam sistem aplikasi meliputi:1. kebutuhan yang tidak sesuai ditafsirkan- melayani informasi (IS) orang-orang salah menafsir apa yang keinginan pemakai, tetapi dengan tepat menerapkan apa yang IS percaya orang-orang inginkan.1. para pemakai menetapkan kebutuhan yang salah- spesifikasi diberikan kepada IS diterapkan.1. kebutuhan salah direkam - Orang-Orang gagal untuk merekam spesifikasi [yang] dengan baik.1. desain spesifikasi salah - desain sistem aplikasi tidak mencapai kebutuhan sistem, tetapi desain ditetapkan mungkin dengan tepat diterapkan.1. spesifikasi program salah- spesifikasi desain adalah salah ditafsirkan, membuat spesifikasi program tidak akurat, tetapi program dapat dengan baik pengkodean untuk mencapai spesifikasi program yang benar.1. kesalahan pengkodean program -- program tidak diberi kode menurut spesifikasi program.1. program yang struktural atau kesalahan instruksi -kemampuan programming yang tidak sesuai pemanfaatan, menghasilkan cacat bisa dihubungkan dengan penyalahgunaan suatu instruksi program atau metod di mana instruksi digunakan.1. kesalahan masukan data - informasi program dan/atau sistem yang salah masuk ke komputer.1. pengujian kesalahan - test yang manapun mendeteksi suatu kesalahan yang bukan suatu kesalahan atau gagal untuk mendeteksi suatu kesalahan didalam sistem aplikasi.1. koreksi kesalahan salah mengira - sedang dalam proses dalam mengoreksi suatu kesalahan, kondisi yang dikoreksi berisi suatu cacat.1. kondisi yang dikoreksi menyebabkan cacat yang lain - sedang dalam proses dalam mengoreksi suatu cacat, koreksi memproses dirinya sendiri menyebabkan cacat tambahan untuk masuk ke sistem aplikasi.area dihubungkan dengan kaleng proses test yang pada umumnya siap dikenali. adalah menjadi penilaian dari biaya-biaya dihubungkan dengan area ini [semua] yang adalah sulit memperoleh. bagaimanapun, sampai total biaya pengujian dikenal, thew ongkos membongkar dan cacat mengoreksi yang tak dikenal.ada dua metoda untuk mengembangkan suatu perkiraan pengujian yang realistis. yang pertama minta seorang informasi pelayanan untuk mengidentifikasi semua di atas kondisi-kondisi dan usaha dan waktu mereka. selagi konsep ini bekerja didalam teori, dalam praktek sukar untuk merekam usaha dan waktu dihubungkan dengan membangkitkan cacat sampai cacat itu benar-benar dikenal. karena titik pembongkaran mungkin (adalah) banyak bulan atau minggu setelah cacat yang nyata dibangun ke dalam sistem, mungkin saja sukar untuk kembali dan memulihkan biaya-biaya ini. yang kedua, dan lebih praktis, pendekatan akan merekam banyaknya cacat temu sebagai hasil pengujian. studi IBM menunjukkan akan ada kira-kira 60 cacat per 1.000 bentuk program terbuka. ketika masing-masing cacat terbuka, akan dicatat, seperti halnya titik jalan kehidupan sistem memproses jika itu terbuka.harga yang sebenarnya untuk mendesain kembali dan mengoreksi sistem kemudian adalah merekam. ini menjadi biaya-biaya memerlukan untuk mengoreksi program oleh beberapa kumpulan kembali dan perubahan dokumentasi. biaya-biaya kemudian adalah dikalikan dengan suatu faktor yang menghadirkan keseluruhan dari permasalahan dan kesalahan dihubungkan dengan cacat sebagai berikut:1. cacat ditemui selama kebutuhan dan desain- memberi beban kepada benar akan menjadi keseluruhan dari biaya dihubungkan dengan koreksi dari cacat.1. cacat dikoreksi selama sistem ini menguji tahap - memberi beban kepada benar harus dikalikan dengan tahap faktor 10.1. cacat mengoreksi setelah sistem memasuki produksi - memberi beban kepada benar harus dikalikan dengan tahap faktor 100.ongkos mutu meningkatkan seperti jalan kehidupan sistem maju ( lihat figur 4.1). selagi ini adalah suatu studi tua,itu masih menerima sebagai sah didalam industri.Pengurangan Biaya PengujianIlmu ekonomi dari pengujian computer secara jelas dibuktikan dengan metode pengurangan biaya untuk menempatkan kerusakan tersebut lebih cepat dari system perkembangan siklus hidup. Keadaan ini diawali dengan pengujian Selama tahap syarat dari siklus hidup dan pengujian berlanjut dimana masih berhubungan dengan siklus hidup. Tujuan dari pengujian berfungsi untuk mendeteksi kesalahan dengan cepat di siklus hidup yang mungkin terjadi

Konsep Pengujian Siklus HidupPengujian siklus hidup meliputi pengujian yang berlanjut dari system selama proses pengembangan. Penetapan sebelumnya, hasil dari proses perkembangan adalah pemeriksaan untuk menetapkan kebenaran sebuah alat. Pemeriksaan ini mengidentifikasi kemungkinan pengurangan point tercepat. Pengujian siklus hidup tidak bias terjadi hingga susunan proses system perkembangan telah berbetuk badan hokum. Pengujian siklus hidup adalah penyelesaian tanggungan dari penetapan sebelumnya yang mungkin disampaikan dalam pokok yang lebih spesifik diperkembangan siklus hidup. Apabila pelayanan informasi pribadi mempunyai kebujakan untuk menetapkan urutan dimana yang mungkinj disampaikan perkembangannya, proses uji sikus hidup menjadi tidak berguna. Ini adalah hak untuk mengubah dalam suatu proses, dimana biaya normal meningkat.Konsep pengujian siklus hidup dapat menjadi yang terbaik tergantung dari formasi tim penguji. Sebuah tim terdiri dari anggota-anggota dalam suatu proyek dimana mungkin baik sedang dilaksanakan dan sedan diuji di system. Bagaimanapun, ketika anggota-anggota dari suatu tim sedang menguji system mereka harus menggunakan metodologi ujian yang sudah ditetapkan untuk membedakan dengan jelas tata cara pelaksanaan dari tata cara ujian dan mereka juga harus mengikuti sturktur metodologinya ketika melakukan pendekatan perkembangan system. Tanpa struktur metodologi ujian yang spesifik, konsep tim penguji akan tidak berguna karena anggota-anggota tim akan mengikuti metodologi yang sama untuk menguji sama seperti mereka menggunakan untuk melakukan pengembangan system. Pengalaman memberitahu kepada orang-orang yang buta pada kesalahannya mereka sendiri, jadi keefektifan dari sebuah tim penguji adalah tanggungan dari pengembangan system di bawah satu metodologi dan ujina dengan yang lain.Konsep siklus hidup adalah seperti yang diilustrasikan di kotak 3.6. Ilustrasi ini memberitahu bahwa ketika proyek itu berjalan, baik proses pengembangan system dan awal proses system ujian. Tim ini yang mengembangkan awal proses pengembangan system dan tim ini adalah mengembangkan rencana system ujian awal, proses system ujian. Baik tim-tim mengawali di poin-poin yang sama menggunakan informasi yang sama. Tim pengembangan system mempunyai tanggungjawab untuk menetapkan dan mendokumentasikan syarat-syarat yang bertujuan untuk mengembangkan. Demikian juga tim penguji akan menggunakan syarat yang sama, tetapi untuk bertujuan untuk menguji system itu. Poin-poin yang tepat selama proses pengembangan, tim penguji akan menguji proses pengembangan dalam usaha untuk menemukan kerusakan. Tim penguji sebaiknya menggunakan garis besar struktur teknik ujian di dalam buku ini seperti dasar evaluasi proses system pengembangan yang mungkin disampaikan.Selama proses system ujian ada bagian yang tepat dari transaksi sebaiknya dikembangkan agar lengkap disaat yang sama untuk penyelesaian dari system aplikasi ketika aplikasi bertemu dengan criteria penerimaan dimana dapat digabungkan ke dalam lingkungan operasi. Selama proses ini, tim pengembang system dan penguji system bekerja dengan teliti bersama-sama untuk memastikan bahwa aplikasi ini dapat digabungkan dengan tepat ke dalam lingkungan produksi. Dalam poin itu, tim-tim tersebut memecah lagi untuk memastikan bahwa cara yang benar dari pembuatan perubahan selama fase pemeliharaan. Bagaimanapun, tim pemeliharaan akan membuat perubahan dan peningkatan yang penting dari system aplikasi dan tim penguji akan melakukan proses tes yang berlanjut untuk mengambil cara-cara yang tepat agar mengalami peningkatan sebagaimana mestinya yang telah diimplemntasikan dan digabungkan ke dalam lingkungan produksi.

Komposisi Dari Tim Penguji Tim penguji adalah bagian yang melengkapi proses pengujian. Tanpa tim penguji yang bersifat resmi, sulit menjelaskan secara formal atau resmi konsep pengujian ke dalam pengembangan proses. Perluasan Perluasan bagian pengujian oleh individu yang dikembangkan dalam kerja yang telah diuji tidak menyamai metode efektiv dalam pengujian.

Pendekatan TimPengujiBagian AnggotaTim PengujiKeuntunganKerugian

Internal IS

Tim Proyek Biaya minimal Latihan Proyek pengetahuan Alokasi waktu Kekurangan kebebasan Kekurangan objektivitas

Eksternal IS

Jaminan Kualitas Penguji Profesional Pandangan sendiri IS profesionalis Pengalaman menguji banyak proyek

Biaya Overreliance Kompetisi

Non IS

Pengguna Akuntan Penasehat Pandangan sendiri Kebebasan dalam menafsir Kepastian untuk bertindak Biaya Kekurangan pengetahuan IS Kekurangan proyek pengetahuan

Kombinasi

Sebagian atau semua dari yang di atas Keahlian yang beragam Pendidikan Kekuasaan Biaya Jadwal untuk memandang sendiri Bermacam-macam latar belakang

Kotak 4.2 Komposisi Tim Penguji

Kerugian penguji laki-laki atau perempuan pekerjaan yang dimiliki menggunakan dokumentasi yang dimiliki oleh perempuan atau laki-laki adalah : Kesalahpahaman akan tidak terlihat, karena pengawas akan berpendapat lain bahwa setiap pendengaran individu yang dihasilkan dari laki-laki ataupun perempuan adalah benar. Kepatuhan yang digunakan pada pengembangan proses mungkin tidak terlihat karena individu tidak mengerti proses. Perseorangan mungkin buta dalam menerima spesifikasi system yang salah dan pengkodean pria atau wanita jatuh ke dalam perangkap yang sama selama ujian dimana petunjuk kerusakan dijelaskan pada bagian pertama. Orang pelayan informasi optimis dengan kemampuan mereka untuk mengurangi kerusakan kerja dan yang terkadang meremehkan apa yang dibutuhkan dalam pengujian yang lebih luas. Tanpa pembagian yang sudah ditetapkan antara perkembangan dan ujian setiap individu mungkin telah tergoda untuk memperbaiki struktur system dan dokumentasi daripada menyediakan waktu dan usaha untuk ujianTim penguji dapat terorganisasi menggunakan salah satu dari keempat yang melakukan pendekatan yang berbeda ( Lihat gambar 4.2 ) dimana digambarkan pada tiap tahap.

Pendekatan Tim Penguji Internal ISAnggota dari tim proyek menjadi anggota tim penguji. Pada banyak instansi, memimpin proyek pengembangan sitem adalah pemimpin tim penguji. Bagaimanapun, itu bukan kebutuhan untuk dimiliki semua anggota tim pengembang yang berpartisipasi pada pengujian tim, walaupun mereka tidak memiliki alas an mengapa mereka tidak berpartisipasi. Yang paling penting adalah salah satu dari tim penguji akan menjadi atau memiliki tanggung jawab yang paling besar untuk menguji pekerjaan anggota lain. Obyektivitas pada tim untuk membuat ujian proses sendiri pada setiap orang yang mengembangakan bagian keterangan dari sebuah proyek yang telah diuji.Keuntungan dari tim penguji IS adalah meminimalkan biaya dari tim penguji. Proyek siap bertanggungjawab untuk pengujian, jadi penggunaan anggota-anggota proyek pada penguji, hanyalah metode pengganti belaka. Pengujian menggunakan pendekatan tim penguji tidak hanya melatih proyek perorangan adalah metode pengujian yang bagus, tetapi pelatihan silang antar mereka adalah bagian lain dari proyek. Pendekatan tim penguji Internal IS adalah menjamin bahwa tiap proyek menyediakan waktu yang tepat untuk pengujian.Untuk tambahan, anggota team proyek akan kekurangan kebebasan dan obyektifitas dalam menuntun test. Disana terdapat kecenderungan untuk anggota team proyek untuk mempercayai bahwa solusi proyek tersebut benar dan dengan demikian menemukan bahwa itu cukup sulit untuk tantangan perkiraan proyek.External IS Test Team Approach(Pendekatan Tim Penguji external IS)

Tetsing dijalankan oleh pelayanan onformasi kebebasan personil dari proyek yang tidak meringankan tenggung jawab tiap personil untuk memastikan kebenaran dari system aplikasi. Pengujian luar didesain untuk melengkapi pengujian independen dalam permintaan untuk melengkapi jaminan tambahan dari kebenaran dari proses yang sedang dilakukan. Pengujian luar normalnya banyak terjadi setelah team proyek sudah menjalankan pengujian yang mereka anggap perlu. Frekuensi team pengembang system memeriksa apakah struktur system benar dan team penguji independen memeriksa apakah system sudah memenuhi kebutuhan pemakai.External IS testing normalnya dijalankan oleh salah satu pelayanan informasi jaminan kualitas atau grup penguji professional didalam departemen pelayanan informasi . Ketika team proyek sudah menyertakan seluruh aspek dari pengembangan, team penguji professional jaminan kualitas khususnya pada proses pengujian. Walaupun demikian banyak individu pada grup pengujian ini sudah memiliki desain system berpengalaman dalam pemrograman.Keuntungan dari pengujian pelayanan informasi luar yaitu kebebasan perspektif atau pengharapan mereka bawa pada proses test uji. Grup meliputi pelayanan informasi professional yang memiliki spesialisasi dalam area pengujian. Untuk tambahan, grup ini memilki pengalaman pengujuan dalam bermacam-macam proyek, dan demikian lebuh baik untuk merancang dan menjalankan test daripada individu lain yang hanya melakukan test pada jangka waktu tertentu.Kerugian dari external IS testing adalah tambahan biaya dimana dapat diwajibkan untuk menetapkan dan mengatur sebuah fungsi pengujian, dan juga team pengembang akan menggantikan terlalu banyak kepercayaan pada team penguji dan kesalahan demikian untuk pengujian kemampuan yang memadai oleh mereka sendiri, pengambilan hasil akhir dalam penguji professional yang berlimpah. Sebagai tambahan, persaingan diantara team uji dan team proyek akan menghasilkan merusakkan kerjasama, membuat semakin sulit utnuk tim uji untuk fungsi yang harus mereka jalankan.

Non-IS Test Team ApproachPengujian bisa dijalankan oleh grup diluar departemen pelayanan informasi. Tiga grup umum yang paling banyak melakukan uji system aplikasi adalah pengguna, auditor, dan konsultan. Grup ini menggambarkan keinginan dari organisasi dan pengujian untuk keperluan organisasi. Mereka yang bersangkutan dengan perlindungan ketertarikan dari organisasi yang ada. Keuntungan dari non-Information Service test team adalah mereka memberi pandangan dan dalam waktu yang sama bisa memberikan kebebasan dalam penilaian. Grup diluar pelayanan informasi tidak dibatasi kesetiaan atau orang yang menghanguskan untuk melaporkan hasil yang tidak baik hanya kepada departemen pelayanan informasi. Grup non-IS memiliki kemampuan terhebat untuk menciptakan dan menyebabkan tindakan untuk sekali masalah yang terjadi yang terdeteksi daripada grup departemen pelayanan informasi.Kerugian dari non-IS testing adalah biaya dari test. Biasanya, grup ini tidak familiar dengan aplilkasi dan harus mempelajari aplikasi terlebih dulu, dan kemudian belajar bagaimana untuk menguji dalam organisasi. Grup non-IS akan berjumpa dengan tingkat kesulitan yang paling sulit dalam pengujian harus diberikan untuk kekurangan pengetahuan pelayanan informasi dan kekurangan pengetahuan proyek.

Combination Test Team Approach Beberapa atau semua dari keseluruhan grup dapat berpartisipasi dalam sebuah team uji. Gabungan team ini bisa saja bersama-sama untuk bertemu keinginan pengujian yang spesifik. Contohnya, jika proyek memiliki gambaran financial yang signifikan , auditor harus dimasukkan ke dalam team uji. Jika memiliki badan komunikasi , konsultan komunikasi juga harus dimasukkan.Keuntungan dari penggambaran pada bermacam-macam kemampuan untuk team uji adalah untuk mengaktifkan sebuah pendekatan multidisplin untuk pengujian. Pada kalimat lain, kemampuan dan latar belakan dari beberapa individual dan perbedaan tingkat kedisiplinan bisa saja sama didalam proses uji. Untuk beberapa orang yang berpartisipasi dalam test, terutama pengguna, itu bisa saja menjadi pembelajaran yang berpengalaman untuk membuat mereka waspada dari keduanya pada system dan potensial perangkap pada system yang sudah otomatis. Tambahan, test gabungan memiliki clout terhebat pada salah satu persetujuan, ketidak setujuan , atau proses modifikasi system aplikasi utama diatas test.Kerugian dari team test gabungan adalah biaya gabungan dengan perakitan dan proses administrasi team test. Itu juga membuat sikap beberapa penetapan perencanaan masalah ketika test akan terjadi. Terakhir, berbagai latar belakang dari team uji bisa membuat penentuan mutu dari kesulitan mendekati test yang dapat diterima.

Testing Concern(perhatian utama pengujian)Proses test adalah proses 3 dimensi. Dimensi pertama yaitu garis batas factor pengujian , sementara dimensi kedua mencari jangka waktu dari pengujian . Dimensi ketiga menerangkan proses penetapan apakah proses tersebut sudah diberi alamat.Faktor test membicarakan luas obyektif dari pengujian. Sekali obyektif ini terpenuhi , proses test bisa dianggap sudah menarik kesimpulan. Contoh, control akses adalah salah satu dari factor atau luas obyektif dari pengujian. Sekali proses uji sudah ditentukan maka sisrtem bisa cukup memadai dan memerlukan control akses, control akses seharusnya dianggap terpenuhi.Itu adalah angka dari kepentingan bahwa team uji harus memiliki masing-masing dari factor test atau obyektif perhatian menggambarkan sebuah kondisi atau kegiatan yang mungkin terjadi yang bisa mencegah obyektif test dari adanya penyelesaian. Pada contoh control akses kita, disana adalah perhatian yang akses ke system tidak akan ditemukan. Perhatian untuk setiap factor test terdaftar pada matriks perhatian pengujian dan dibicarakan secara ringkas dibawah. Catatan disana adalah adalah salah satu perhatian untuk setiap tahap dari SDLC.

1. Faktor Test Reliabiliti Tingkat ketepatan dan kelengkapan yang diharapkan pada operasional lingkungan sekitarnya sudah ditetapkan. Pengendalian integritas data untuk penetapan toleransi pemrosesan sudah didesain. Pengendalian integritas data sudah diimplementasikan pada penyesuaian dengan desain. Manual, kemunduran, dan kegunaan test sudah dijalankan untuk menjamin kerja pengendalian integritas data. Ketepatan dan kelengkapandari instalasi system sudah dibuktikan. Ketepatan kebutuhan sudah dipelihara sebagai peng-update-an aplikasi. 2. Faktor Test Autorisasi Aturan untuk memerintah pemberian kuasa dari transaksi yang memungkinkan transaksi utnuk proses yang sudah ditentukan. Aplikasi sudah didesain untuk mengidentifikasi dan memegang teguh aturan untuk pemberian kuasa. Implementasi program aplikasi berdasar kepada desain aturan pemberian kuasa. Sistem teruji izinnya untuk menjamin bahwa aturan pemberian kuasa sudah terlaksana dengan sebagai mana mestinya. Perubahan pencabutan kuasa dilarang selama proses instalasi. Metode dan aturan pemberian kuasa terpelihara selama pemeliharaan.

3. Faktor Test Integritas File Kebutuhan untuk integritas file sudah ditentukan. Melengkapi desain untuk pengendalian sebagai jaminan integritas data file. Spesifikasi pengendalian integritas file sudah diimplementasikan. Fungsi-fungsi integritas file sudah teruji untuk jaminan mereka berjala dengan baik. Integritas dari pembuatan file sudah dibuktikan lebih dulu untuk pemberian tempat file-file tersebut ke dalam sebuah status pembuatan. Integritas dari file sudah terpelihara selama tahap pemeliharaan.

4. Faktor Test Bekas Pemeriksaan Kebutuhan untuk menyusun kembali sudah ditentukan. Bekas pemeriksaan dan informasi dalam bekas pemeliharaan diperlukan untuk proses penyusunan kembali sudah didesain. Kebutuhan bekas pemerikasaan digabungkan ke dalam system. Fungsi-fungsi bekas pemeriksaan sudah dites utnuk jaminan bahwa data sesuai untuk disimpan. Bekas pemeriksaan dari kegiatan selama proses instalasi sudah terekam. Kebutuhan bekas pemeriksaan sudah terupdate selam pemeliharaan system.

Faktor TesRequirementDesainProgramTestInstalasiMaintain

RealibilitasMenetapkan toleransiMerancang kontrol integritas dataMenerapkan kontrol integritas dataPengujian kemundu-ran manual dan fungsionalMemverifikasi/ membuktikan ketepatan dan kelengkapan instalasiMemperbaharui ketelitian kebutuhan

OtorisasiMenggambarkan otorisasi aturanMerancang otorisasi aturanMenerapkan otorisasi aturanPengujian pemenuhanLarang merubah data selama instalasiMemeli-hara otorisasi aturan

Integritas FileMendefinisikan/ menggambarkan requirement / kebutuhan integritas fileMerancang kontrol integritas fileMenerapkan kontrol integritas fileMenguji fungsionalVerifikasi integritas file produksiMemeli-hara integritas file

Jejak AuditMendefinisikan rekonstruksi kebutuhanMerancang jejak auditMenerapkan jejak auditMenguji fungsionalCatat jejak audit instalasiMemperbaharui jejak audit

Kesinambungan dari pemrosesanMendefinisikan dampak dari kegagalanMerancang rencana daruratMenuliskan rencana darurat dan prosedurMenguji rekoveriMeyakinkan integritas dari pengujian sebelumnyaMemperbaharui rencana darurat

Kualitas pelayananMendefinisikan / menggambarkan kualitas pelayanan yang diinginkanMerancang metode untuk mencapai kualitas pelayananDesain sistem untuk mencapai kualitas pelayananMenguji tekananMengimple-mentasikan rencana gagal ,amannya instalasiMemeli-hara kualitas pelayanan

Akses kontrolMenggambarkan aksesMerancang Prosedur aksesMenerapkan prosedur keamananMenguji pemenuhanAkses kontrol selama penginte-grasianMemeli-hara keamanan

MetodologiMematuhi kebutuhan / requirement dengan metodologiMenyusun desain dengan metodologiProgram mematuhi metodologiPengujian sesuai dengan metodologiIntegrasi sesuai dengan metodologiPemeliha-raan mematuhi metodologi

KetepatanMerancang spesifikasi fungsionalDesain sesuai dengan kebutuhanProgram sesuai dengan desainMenguji fungsionalProgram dan data yang sesuai ditempatkan dalam produksiMemper-baharui kebutuhan

Kemudahan penggunaanMenentukan usabilitas spesifikasiKemudahan penggunaan desainProgram sesuai dengan desainMenguji manual pendukung Menyebarkan instruksi usabilitasMemeli-hara kemudahan penggu-naan

Dapat dipeliharaMenentukan spesifikasi pemeliharaanDesain dapat dipeliharaProgram dapat dipeliharaPemerik-saan / inspeksiDokumentasi lengkapMemeli-hara maintain-bilitas

PotabelMenentuan kebutuhan portabilitasDesain portabelProgram sesuai dengan desainPengujian terhadap bencanaDokumentasi lengkapMemeli-hara portabilitas

PenggabunganMenggambarkan sistem antarmukaDesain antarmuka lengkapProgram sesuai dengan desainMenguji fungsional dan kemundu-ranMengkoor-dinasi antarmukaYakinkan antar muka sesuai

Kemampuan bekerja / performaMenetapkan kriteria kemampuan / performansiDesain mencapai kriteriaProgram mencapai kriteriaMenguji pemenuhanMemonitor kemampuan pengintegra-sianMemeli-hara tingkat kemam-puan

Kemudahan Pengopera-sianMenggambarkan kebutuhan operasionalHarus memberitahu-kan untuk pengoperasianPengembang mengoperasikan prosedurMenguji operasiMengimplementasikan prosedur operasiMemper-baharui prosedur operasi

Pengujian Tahap RequirementPengujian sistem sebaiknya mulai pada tahap requirement. Requirement adalah dasar untuk sistem desain yang kemudian dipergunakan untuk memprogram untuk menghasilkan aplikasi yang dilaksanakan terakhir.

Deliverables Tahap requirement dilakukan untuk memecahkan masalah perusahaan. Deliverables pada pengujian tahap ini meliputi : Proposal ke manajemen yang menggambarkan masalah, pilihan dan solusi yang diusulkan. Biaya studi/manfaat yang menggambarkan nilai ekonomi dari solusi yang dihasilkan. Deskripsi detail pemecahan yang dianjurkan. Daftar asumsi sistem, seperti lama proyek berlangsung, nilai uang, rata-rata keahlian dari user dan lain-lain.

Test Concerns (Perhatian)Orang yang melakukan pengujian harus mengerti tujuan tahap dan kemudian menilai tujuan itu melalui pengujian. Tahap requirement saja tidak cukup pada tahap pengujian, sebaiknya dilanjutkan sampai requirement benar-benar lengkap. Tanpa pengujian, kekurangan dalam tahap requirement mungkin tidak diketahui.

Faktor Pengujian MetodologiRequirement dihasilkan dari penerapan suatu metodologi. Faktor Pengujian KevalidanSpec fungsional dapat didefinisikan dan diukur secara kuantitatif, misalnya kenaikan pelayanan ke user adalah kualitatif. Sedangkan pemrosesan order user dalam 4 jam adalah kuantitatif.

Faktor Pengujian Kemudahan PenggunaanPenentuan spec penggunaan perangkat lunak apakah aplikasi cukup mudah dipakai.

Faktor Pengujian PemeliharaanTingkat harapan pemeliharaan ditentukan, seperti harga berubah setiap 24 jam operasional.

Faktor Pengujian PortabilitasKemampuan untuk menjalankan sistem tergantung pada perbedaan jenis perangkat keras, memindahkan pada suatu waktu ketipe lain suatu perangkat keras, atau requirement untuk memindahkan dari versi perangkat lunak sebaiknya dinyatakan sebagai bagian dari requirement. Keperluan untuk mengembangkan aplikasi seperti aplikasi portabel dapat secara signifikan mempengaruhi implementasi requirement.

Definisi Sistern Interface (Faktor Penguiian Rangkaian)Sebaiknya Informasi yang diharapkan didefinisikan sebagai masukan dari sistem komputer lain dan hasilnya diantarkan kesistem komputer lain. Faktor interface yang lain mungkin perlu ditanggapi termasuk kebebasan pribadi, keamanan, dan memori dari informasi.

Definisi Kebutuhan Operasional (Faktor Test Kemudahan Untuk Dioperasikan)Pertimbangan cara bekerja harus ditegaskan selama tahap requirement karena sangat penting untuk sistem aplikasi user. Proses yang harus diikuti di terminal untuk menjalankan sistem, dengan kata lain prosedur diperlukan untuk mendapatkan terminal kedalam status yang siap untuk proses transaksi.

Ketepatan Toleransi (Faktor Pengujian Kehandalan)Ketetapan yang diharapkan dari sistem kontrol sebaiknya ditegaskan. Misalnya, tahap requirement sebaiknya menentukan kontrol requirement untuk ketepatan, pengolahan jumlah pesanan yang diperlukan selama 24 jam dan yang lainnya.

Definisi Aturan Otorisasi (Faktor Pengujian Otorisasi)Otorisasi requirement menetapkan metode otorisasi untuk memastikan bahwa transaksi sebenarnya diolah sesuai persetujuan dari manajemen.

Faktor Pengujian Integrit File (faktor pengujian integrit file)Metode dalam menjamin integritas file komputer perlu ditetapkan. Ini biasanya termasuk semua kontrol yang akan dipelihara baik dalam file dan aplikasi otomatis yang baik. Sedangkan kontrol harus menjamin detail dari record yang seimbang dengan semua kontrol untuk masing-masing file.

Definisi Requirement Rekonstruksi (Faktor Pengujian Pelacakan Sistem Audit)Rekonstruksi melibatkan ketelitian proses maupun pemulihan setelah identifikasi. Kedua keperluan ini meliputi memori informasi untuk proses cadangan.

Pengaruh Dari Kegagalan (Faktor Pengujian Keberlangsungan Pemrosesan)Kebutuhan untuk menjamin kesinambungan pengolahan tergantung pada dampak kegagalan. Disisi lain kesinambungan pada pelaksanaan esensial mungkin perlu mendapatkan duplikat data utama agar bisa terus melanjutkan pemrosesan yang gagal.

Definisi Tahapan Pelayanan (Faktor Pengujian Tahap Layanan)Tahap layanan ini berfariasi sesuai pada requirement, setiap tahapan dari layanan ini butuh untuk ditetapkan. Sebagai contoh, tahap layanan untuk menjalankan transaksi yang spesifik, tahap layanan untuk memperbaiki program yang salah, tahap layanan untuk menginstal dan tahap layanan untuk menanggapi sebuah permintaan.

Penggambaran Akses (Faktor Pengujian Keamanan)Keamanan requirement sebaiknya dikembangkan dengan menghubungkan antara sistem dan orang, pengontrolan pada seluruh sistem obyek yang ada. Seperti contoh, akses untuk membaca tapi tidak untuk mengubah data yang ada.

Uji Responsibiliti Tahap requirement harus menjadi tahap yang dikuasai seorang user. Selama siklus hidup, peserta memainkan peran dan pada beberapa tahap user sangat dominan, sedangkan servis informasi yang lain juga dominan. Misalnya, meminta user untuk menverifikasi program yang dibuat akan menjadi tidak berguna.

Alat-alat Pengujian yang Dianjurkan.Alat bantu pengujian walk-through dan resiko matriks direkomendasikan sebagai dua atau lebih test tool yang efektif pada tahap requirement. Penggunaan alat ini akan membantu memutuskan apakah faktor pengujian sudah memadai selama tahap requirement.

Alat Uji Walk-ThroughTahap requirement meliputi kreatifitas, pengalaman dan pendapatan sama baiknya dengan metodologi berikut. Tujuannya adalah membuat situasi yang mana sebuah individu berkemampuan tim, dapat membantu tim proyek dalam pengembangan solusi proyek. Lima langkah proses walk-through yang akan diselesaikan pada daftar dibawah :1. Membuat aturan dasarKonsep walk-through memerlukan proyek seseorang untuk membuat keterangan persentasi dari fungsi sistem setelah berkembang pada saat persentasi. Persentasi atau membaca requirement adalah alat untuk menginisialisasi diskusi diantara tim proyek dan tim walk-through. Aturan dasar yang harus dimengerti oleh tim proyek maupun tim walk-through adalah : Ukuran dan tampilan tim walk-through Tanggung jawab tim walk-through Menjawab pertanyaan dan rekomendasi Memperkirakan seberapa lama waktu dan lokasi Merahasiakan informasi yang didiskusikan Aspek-aspek yang menyangkut sistem yang tidak dapat ditolak dan didiskusikan Siapa saja yang akan menerima hasil dari tim walk-through2. Pilih kelompok/pesertaPeraturan dasar menetapkan ukuran dan susunan sebuah kelompok dengan batas-batas kewajaran dan sesuai dengan yang akan dikerjakan. Peserta-peserta yang paling sesuai dalam group walk-through meliputi : Pelayanan informasi bagi manajer proyek/sistem analisis Manajemen senior yang bertanggung jawab penuh atas area komputer Manajeman operasi Manajemen user/pemakai Penasehat/konsultan3. Persentasi proyekPara personil harus mempresentasikan syarat-syarat presentasi kepada seluruh kelompok walk-through. Sebuah walk-through yang baik meliputi : Pemberitahuan sasaran dan tujuan dari proyek Informasi dasar seperti statistik baru dan ditujukan untuk area aplikasi yang tepat Daftar pengecualian dari pembuatan proyek Alternatif diskusi yang dipertimbangkan dan yang telah dipilih Persyaratan dari sebuah walk-through4. Pertanyaan/pujianDalam sebuah proyek persentasi harus ada pertanyaan, komentar dan pujian atas apa yang telah dipersentasikan oleh tim walk-through yang bertujuan untuk membangun sebuah diskusi dan bukan hanya mengaplikasikan requirement tersebut. 5. LaporanPeraturan dasar menentukan apakah laporan dapat dikeluarkan atau dibagikan, dan juga dperuntukkan untuk siapa. Laporan tersebut harus dibuat berdasarkan siapa yang akan diberi laporan. Untuk hasil yang memuaskan,laporan harus diajukan dalam 5 hari setelah kesimpulan ditentukan saat walk-through

Resiko Pengujian MatrixMatriks resiko adalah sebuah alat yang didesain untuk memulai ketercakupan kontrol didalam sistem komputer. Salah satu keuntungan utama matriks resiko adalah mengidentifiakasi resiko dan sistem harus mengidentifikasi untuk masing-masing resiko itu. Matriks resiko bisa dipakai pada 2 tahap yaitu tahap requirement dan tahap desain. Secara ideal matriks resiko dimulai pada tahap requirement diperluas dan diselesaikan pada tahap desain. Pelaksanaan matriks resiko berupa 4 langkah proses. Langkah sebaiknya dilakukan dengan urutan berikut : 1. Tim pengidentifikasi resikoKunci keberhasilan resiko matriks adalah kebenaran pendirian resiko tim, tanggung jawabnya untuk menyelesaikan matriks. Tujuan menyelesaikan matriks adalah untuk menentukan kecukupan kontrol requirement dan desain untuk mengurangi resiko sampai tingkatan yang dapat diterima.Tim sebaiknya terdiri dari 3 sampai 4 orang anggota dan setidaknya memiliki ketrampilan seperti : Aplikasi pengetahuan pemakai Konsep pengertian resiko Kemampuan untuk mengenali kontrol Mengenali dengan baik aplikasi dan layanan informasi resiko Mengerti konsep layanan informasi dan sistem desain Mengerti prosedur pelaksanaan komputerCalon yang dimasukan ditim resiko adalah : Internal auditor Resiko konsultan Data prosessor Petugas keamanan Manajer pengoperasian komputer2. Mengidentifikasi resikoObyektifitas dari tim resiko adalah untuk mengidentifikasi aplikasi yang berorientasi terlebih dahulu, bukan lingkungan dan resiko yang dihubungkan dengan sistem aplikasi. Misalnya, resiko menghubungkan kesemua aplikasi secara berimbang. Adapun metode untuk mengidentifikasi resiko adalah : Resiko menganalisa skenario Resiko pengecekan pada list3. Menetapkan tujuan kontrolSelama tahap requirement tujuan kontrol untuk masing-masing resiko sebaiknya ditetapkan. Adapun tujuannya adalah untuk menegaskan tingkatan yang dapat diterima untuk tiap-tiap identifikasi resiko.4. Mengenali masing-masing kontrol dibagian sistemSelama tahap desain, tim resiko akan mengenali kontrol dimasing-masing tahap sistem aplikasi untuk setiap identifikasi resiko. Bagian sistem umumnya adalah : Pengaturan : Ciptaan otorisasi plus dokumen sumber yang dihubungkan dengan transaksi pengaturan Data entry : Transfer informasi menggunakan mesin media yang dapat dibaca Komunikasi : Pergerakan data dari satu titik kesistem lainnya baik secara manual atau atomatis Pemrosesan : Aplikasi sistem logika untuk data Penyimpanan : Penyimpanan data baik temporari atau tidak Output : Menterjemahkan data dari media komputer kemedia yang dapat dimengerti dan dapat dipakai oleh user Use : kepuasan keperluan perusahaan dengan hasil pengolahan sistemKategoti : Salah atau memalsukan data input 1. Sumber nilai data yang tak layak atau tidak konsisten mungkin tidak terdeteksi2. Mencocokkan kesalahan selama transkripsi mungkin tidak terdeteksi3. Melengkapi atau merekord data yang diformat kurang baik4. Merekord disatu format mungkin diterjemahkan dengan format yang berbeda5. Kecurangan pegawai dengan menambahkan, menghilangkan atau mengubah data untuk mendapatkan keuntungan bagi dirinya6. Kurangnya penghitungan dokumen dan kontrol dibalik sumber data atau transaksi masukan mungkin membolehkan sebagian dari data/transaksi untuk dihilangkan tanpa pendeteksian7. Merekord masukan data pegawai8. Tidak adanya pengecekan data pada menit terakhir sebelum pengolahan9. Rekord yang mengandung kesalahan sudah terdeteksi dan diperbaiki tetapi tanpa memverifikasi secara utuh

Kategori : Penyalahgunaan oleh pemakai1. Seorang pegawai mungkin mengubah informasi sampai penggunaan yang tidak sah. Misalnya, menjual data yang mempunyai hak akses mengenai individu kecalon pekerja2. Seorang user yang pekerjaannya memerlukan akses sampai rekord perseorangan dalam suatu file mungkin mengatur untuk mengeksekusi listing yang lengkap dari file tersebut3. Perubahan informasi mungkin diselesaikan untuk beberapa pengguna terakhir yang tidak sah4. User yang sah mungkin menggunakan cara untuk keuntungan pribadi (layanan pencurian)5. Pengawas mungkin mengatur untuk menyetujui dan memasukan transaksi yang curang6. Pegawai yang tidak puas atau dipecat mungkin menghancurkan atau mengubah rekord7. Seorang user untuk mengubah atau mendapatkan informasi dengan sah mungkin melalui jalan suap.

Kategori : Sistem akses yang tidak terkontrol1. Pengambilan data mungkin dari ruang komputer atau tempat penyimpanan lainnya2. Fasilitas layanan informasi mungkin dihancurkan atau dirusakkan oleh para pengacau3. Setiap orang mungkin tidak cukup teridentifikasi sebelum mereka diizinkan untuk memasuki area pelayanan informasi4. Kurangnya pengawasan remote terminal dari pengguna yang tidak sah5. Pengguna yang tidak sah dapat mengakses sistem melalui dial in-line dan disahkan beserta passwordnya6. Penyimpanan password mungkin kurang hati-hati sehingga kelihatan sama pengguna yang tidak sah7. Seorang user mungkin meninggalkan aksesnya dan memperbolehkan orang yang tidak sah memakainya8. Belum dihapusnya hak akses layanan informasi bagi pegawai yang telah dipecat9. Pengguna yang tidak sah mungkin mendapat hak akses untuk dirinya dengan cara pencurian layanan komputer10. Tidak terdeteksinya pengguna yang tidak sah sehingga dapat mengakses sistem tersebut

Kategori : Aplikasi pelatihan kemanan yang tidak efektif1. Kurang baiknya penegasan pada kriteria untuk akses yang sah 2. Kelalaian petugas kemanan untuk membatasi akses bagi pemakai3. Kurang akuratnya pemeriksaan dana pembayaran dan pengunaan barang inventaris4. Tidak adanya peninjauan ulang untuk bayaran bagi kelompok yang sama5. Kecerobohan staf aplikasi, mail servis dan personalia dalam menyimpan data yang sensitif6. Tidak adanya pemerikasaan untuk mengetahui pelanggaran keamanan7. Modifikasi atau perusakan file mungkin tanpa sengaja terjadi saat user masih bekerja pada data8. Tindakan yang baik mungkin hanya tidak berkelanjutan kalau varian kemanan dilaporkan kesistem9. Menutupi kajadian terhadap petugas kemanan dan supervisor

Kategori : Kesalahan prosedur di fasilitas pelayanan informasi1. File mungkin dihancurkan selama database direorganisasi atau selama pembebasan ruang disk2. Operator mungkin mengabaikan prosedur kerja3. Pekerjaan parameter bahasa kontrol mungkin keliru4. Manajer instalasi mungkin melepaskan kontrol untuk mendapatkan informasi5. Kesalahan melakukan restart sesudah shutdown mungkin menyebabkan bagian transaksi menjasi tak dikenal6. Seorang operator mungkin salah memasuki informasi di panel CPU 7. Pemeliharaan hardware mungkin dilakukan ketika data on-line8. Seorang operator mungkin melakukan perbuatan yang tidak sah untuk memperoleh keuntungan pribadi9. Staff operasi mungkin mensabotase komputer10. Sebuah program mungkin dihilangkan ketika melakukan transaksi yang sama11. Sebuah versi dari program yang salah mungkin dihilangkan12. Seorang operator mungkin melewati kontrol keamanan yang diperlukan13. Pengawasan dari personalia operasional mungkin tidak memadai selama tidak berpindah jam kerja14. Seorang operator mungkin sebelumnya merubah atau menghapus berkas utamanya15. Seorang operator panel mungkin mengesampingkan sebuah pengecekan label tanpa mencatat tindakannya dikunci keamanan

Kategori : Peralatan Media Pegangan1. File pita kritis mungkin diletakkan tanpa perlindungan2. Sebuah kesalahan yang menyebabkan media penyimpanan dapat terhapus3. Tidak adanya pemeriksaan yang akurat pada media penyimpanan4. File yang tanpa tanggal berlakunya mungkin dapat terhapus5. Pengolahan data yang tidak terkoreksi atau kesalahan ketika memperbaharui file6. Tidak dihapusnya pita yang telah digunakan untuk proses pekerjaan data yang sensitif7. File yang ditulis selama proses pekerjaan mungkin disebabkan oleh kesalahan pelepasan, kurang bisa memproteksi file dan pengakhiran yang tidak normal8. Media penyimpanan yang berisi informasi yang sensitif mungkin tidak mendapatkan perlindungan karena tidak ada pemberitahuan kepada staff9. Manajemen prosedur mungkin tidak menjelaskan status semua pita10. Belum dihilangkannya magnet pada media penyimpanan magnetik yang berisi informasi yang sensitif sebelum dilepas11. Hasil mungkin dikirim kepada individual atau terminal yang salah12. Unit pengolahan dijalankan secara tidak semestinya mungkin menghasilkan hasil yang salah13. Kelebihan hasil material mungkin tidak dibuang dengan semestinya14. Pita dan label program untuk didistribusikan mungkin tidak terproteksi dari kerusakan

Kategori : Kesalahan program1. Rekord mungkin dihilangkan dari file tanpa ada copyannya sehingga tidak dapat diperbaiki kembali2. Programmer mungkin memasukan ketetapan didalam program untuk memanipulasi data itu sendiri3. Data akan sulit dicari mungkin tidak disimpan secara terpisah dari hasil program modifikasi4. Perubahan program tidak cukup teruji sebelum menggunakan produk ini5. Pergantian kesebuah program mungkin menghasilkan kesalahan baru karena adanya interaksi yang tidak diharapkan antara modul program6. Test penerimaan program untuk kombinasi input mungkin gagal (contoh : program yang seharusnya menolak kesalahan tanpa pengecualian yang spesifik dari nilai penambahan)7. isi program sebaiknya dilindungi, karena mungkin tidak diidentifikasi dan diproteksi8. Kode, uji data dengan hubungan hasil dan dokumentasi untuk program sertifikasi mungkin tidak gagal dan dipertahankan untuk refe