PROSES TESTING

PROSES TESTING

oleh: Tumar

Proses testing proyek pengembangan piranti lunak adalah siap untuk dilaksanakan. Termasuk kegiatan rencana tes dan tes implementasi program. Maksud dari rencana aktivitas tes adalah untuk menentukan cara yang resmi didemonstrasikannya piranti lunak komputer sampai memuaskan hasilnya berdasarkan perjanjian dan menurut kinerjanya Persyaratan Spesifikasi Piranti Lunak telah disetujui. Aktivitas ini adalah bagian dari rancangan, tapi dilakukan bersamaan dengan aktivitas rancangan pendahuluan dan sangat bergantung pada rancangannya. Elemen yang esensial pada rencana tes adalah difinisi pada awal tes itu harus sukses dilaksanakan untuk penerimaan produk piranti lunak – produk diterima pada tes akhir. Tes ini dan persyaratan penerimaan yang lain akan didifinisikan dan yang telah disetujui sampai dengan awal pelanggan ( prioritas untuk PDR jika mungkin, tentu saja prioritas untuk CDR).
Perencanaan dan prosedur untuk testing / uji coba adalah pada awal tulisan dalam siklus pengembangan dan dibawa selama implementasi. Suatu tes / uji coba mempunyai tiga tujuan utama yaitu :
1. Verifikasi produk kinerja piranti lunak seperti yang ditentukan dalam dokumentasi rancangan.
2. Verifikasi produk kinerja piranti lunak yang memuaskan seluruh persyaratan yang ditentukan dalam Spesifikasi Persyaratan Piranti Lunak, dan
3. Asalkan Manajemen Proyek dengan status laporan proyek kecermatan implementasi piranti lunak.

Proses tes konsisten pada dua tahap tes dan empat tingkatan tes yaitu :

1. Tes / uji coba Pengembangan
   a. Program Unit Tes
   b. Modul Tes Integrasi,
2. Tes Validasi
   a. Verifikasi Tes,
   b. Tes diterima,

Tes Pengembangan pada program komputer adalah didifinisikan yang prosesnya interaktiv ditentukan apakah setiap langkah pada suatu Jenis Konfigurasi Program Komputer (a Computer Program Cunfiguration Item / CPCI) penyelesaian proses pengembangan seluruhnya pada persyaratan menurut langkah sebelumnya. Kinerja piranti lunak didemonstrasikan seperti yang ditetapkan dalam dokumentasi rancangan dan kinerjanya proses implementasi adalah cermat. Aktivitas tes pengembangan terutama adalah kontrol oleh organisasi pengembangan piranti lunak.

Definisi validasi adalah evaluasi, intergrasi dan aktivitas tes mengangkat keluar tingkat sub sistem piranti lunak hingga memastikan pengembangan piranti lunak itu memuaskan persyaratan kinerjanya dan kriteria rancangannya memuaskan dalam Persyaratan Spesifikasi Piranti Lunak. Validasi piranti lunak terutama adalah kontrolnya oleh organisasi penjamin kualitas. Catatan tes itu dukungan organisasi tersendiri, di bawah pengawasan proyek, utilitas boleh untuk validasi tes yang telah didiskusikan dalam modul 4. Pada modul ini, bagaimanapun, fungsinya kami terima adalah kinerjanya leh organisasi penjamin kualitas.
Hasil tes/uji coba adalah dgunakan sebagai laporan selama kejadian penting pada implementasi piranti lunak. Kejadian penting adalah mudah didifinisikan oleh kesuksesan yang lengkap sebuah definisi tes dan secara lengkap didokumentasikan dalam laporan hasil tes / uji coba.
Proses tes / uji coba, kumpulan dokumentasi, dan tinjauan program formal adalah digambarkan dalam bagian yang berturut-turut.


8.1 PROSES TES

Proses tes / uji coba adalah kinerja menjelaskan tahap pengembangan piranti lunak dan konsisten terhadap tiga (3) dasar aktivitas antara lain :

1. generasi rencana tes secara rinci dan prosedurnya,
2. kinerja pada aktivitas tes/uji coba, termasuk resolusinya dan tes ulang pada kekurangan piranti lunak, dan
3. dokumentasi hasil tes / uji coba untuk mengikuti jejak laporan.

Gambar 8.1 diilustrasikan waktu yang relativ pada tiga aktivitas ini dalam tahap proyek, produk dokumentasi, dan tinjauan persyaratan sampai pada verifikasi hasilnya proses tes / uji coba.
Rencana Tes / Uji Coba digambarkan lengkap program tes / uji coba piranti lunak dan basis dalam Persyaratan Spesifikasi Piranti Lunak. Ini adalah disampaikan dalam format pendahuluan dan tinjauan pada PDR . Selama Tahap Rancangan Rinci, komentar dari PDR dalam rencana

Tes Pendahuluan adalah yang tergabung kedalam Rencana Tes / Uji Coba, dan tambahan rinci mengenai konfigurasi tes uji coba, piranti lunak tes / uji coba dan tes/uji coba khusus adalah pengembangan dan tergabung kedalam dokumen. Rencana Tes / Uji Coba disampaikan dalam format akhir pada CDR. Setelah CDR Rencana Tes / Uji Coba di bawah konfigurasi formal kontrol dirubah. Pada basis Rencana Tes dan Dokumen Rancangan Rinci, Prosedur Tes Pendahuluan adalah tertulis dan ditinjau pada Tinjauan Prosedur Tes ( The Test Prosedure Review/ TPR). Prosedur Tes / Uji Coba adalah diperbarui dalam basis TPR dan disampaikan dalam format akhir lebih dulu sampai tes/ uji coba formal. Selama proses tes / uji coba, Prosedur Tes / Uji Coba adalah di bawah kontrol konfigurasi, tapi dapat dimodifikasi jika berdasarkan ketidak tepatan. Laporan Tes / Uji Coba adalah turunan selama proses tes / uji coba dan tinjauan pada Penyerahan Tinjauan Piranti Lunak (Software Acceptance Review/ SAR).
Multi organisasi adalah termasuk di dalam proses tes/ uji coba, keduanya dalam grup yang memproduksi piranti lunak yang dihasilkan dan digunakannya. Yang berikutnya dalam diskusi, organisasi pemakai bertanggung jawab untuk diterimanya produk akhir piranti lunak akan sebagai referensi pemakai. Organisasi ini biasanya konsisten pada keduanya personil penjaminan kualitas dan aktual sistem mudah digunakan.

Sebagaian besar berpengaruh pada organisasi dalam proses tes/uji coba adalah organisasi penjamin kualitas untuk grup produksi piranti lunak. Sejumlah metoda verifikasi dikerjakan itu untuk menguji organisasi. Pilihan di mana metoda verifikasi pada penggunaannya akan tergantung pada kebutuhan itu yang dibuktikan dan tingkatan pengujian dilakukan. Uji organisasi, dengan metoda verifikasi, dan bagian tingkatan test yang diuraikan sebagai berikut :

8.1.1 Jaminan Kualitas (Quality Assurance-QA)
Dalam rangka memaksimalkan efektivitas penjaminan kualitas (QA) program, personil QA harus tidak terikat pada organisasi yang bertanggung jawab untuk pengembangan produk. Ini dapat terpenuhi dengan penetapan organisasi QA itu yang secara langsung di bawah pengendalian manajemen perusahaan, bukannya di bawah manajemen proyek piranti lunak. Bagian yang berikut menguraikan suatu program jaminan mutu dan suatu alternatif ke QA formal.

Tanggung Jawab Penjamin Kualitas dan Otoritas (Quality Assurance Responsibility and Authority)
Mutu Tanggung jawab Penjaminan Dan Otoritas. Organisasi QA dilibatkan dalam semua tahap pengembangan program, dari persiapan proposal sampai penyerahan dan penerimaan akhir. Otoritas Dan Tanggung jawab yang spesifiknya diringkas gambar 8.2. Kemerdekaan QA yang organisatoris meyakinkan bahwa pengecekkan dan keseimbangan yang penting bagi suatu QA program sukses yang tidak bisa dipisahkan di dalam struktur manajemen. Karena tanggung jawab yang terakhir untuk produk yang disampaikan pada umumnya terletak di tangan organisasi pengembangan itu, QA yang mandiri menyediakan suatu saluran laporan terpisah untuk monitoring kemajuan pengembangan. Organisasi QA mempunyai otoritas untuk menerima atau menolak semua produk bisa disampaikan, seperti halnya untuk melakukan audit yang sedang dikerjakan dan tinjauan ulang. Dalam hal konflik antara QA dan organisasi pengembang, resolusi harus terpenuhi di tingkatan manajemen perusahaan.

Penjamin Kualitas Piranti lunak (Software Quality Assurance)
Mutu hanya dapat dibangun ke dalam piranti lunak oleh para programmer dan para perancangnya, tetapi tinjauan ulang mandiri dapat berperan untuk mutu piranti lunak dengan menemukan dan melaporkan permasalahan, atau permasalahan potensial, dan dengan berikut yang berdasar pada resolusi. Seperti permasalahan. Dengan penggunaan teknik pemrograman yang modern dan mencakup personil QA di dalam tinjauan ulang teknis sering, kesalahan dapat terbongkar lebih awal dan yang dikoreksi sebelum efek air terjun kecil mereka sampai pada sistem. Sepert yang dibahas pada bab 9, manajemen konfigurasi piranti lunak di dalam memelihara melalui suatu Perpustakaan Program Komputer (CPL). Piranti lunak personil penjamin kualitas menggunakan CPL itu yang melaporkan prosedur permasalahan dokumen piranti lunak dan perubahan jejak untuk mengoreksi kesalahan. Piranti lunak Grup QA adalah bertanggung jawab untuk:

1. Melihara Pengendalian yang tegas atas spesifikasi, dokumentasi disain, kode piranti lunak, dan konfigurasi test untuk meyakinkan capaian dan persyaratan disain yang disatukan dan kemampuan jejak persyaratan itu ke spesifikasi tingkat yang lebih tinggi didokumentasikan.
2. Tinjauan ulang disain piranti lunak sebelum coding.
3. Ambil bagian audit dan tinjauan ulang teknis disain dan aktivitas pengembangan.
4. Melaksanakan tinjauan ulang untuk memastikan kesetiaan ke standard dan prosedur piranti lunak.
5. Melaporkan permasalahan piranti lunak dan pertentangan dan monitoring tindakan korektif.
6. Tinjauan ulang dan rencana test kecakapan yang disetujui dan memeriksa prosedur.
7. Melakukan monitoring test untuk memastikan bahwa prosedur diikuti dan semua ukuran-ukuran sukses dicukupi.

Piranti lunak QA Test Tinjauan ulang memeriksa prosedur untuk memastikan bahwa mereka adalah konsisten dengan rencana pengujian piranti lunak dan arus dokumentasi, yang mereka uji itu semua kebutuhan, dan bahwa mereka berisi ukuran-ukuran penerimaan dan cukup sukses. Kecakapan menguji piranti lunak mendorong ke arah penerimaan program yang dimonitor oleh piranti lunak QA untuk memastikan bahwa:

1. Uji prosedur disetujui sebelum start pengujian.
2. Uji perangkat keras dan lunak adalah dikendalikan dan bisa diterima.
3. Semua test yang diselenggarakan sesuai dengan prosedur pemeriksaan dan memenuhi test.
4. Semua piranti lunak dan definisi test yang ditemukan dalam pengujian direkam.
5. Semua koreksi piranti lunak ddikoreksi kembali.
6. Semua data test direkam dan yang mencerminkan penemuan nyata perjanjian
7. Semua dokumentasi test dirawat untuk mengijinkan pengulangan kemampuan test itu.
8. Status uji laporan dirawat dengan teliti.
9. Uji laporan yang mencerminkan persyaratan perjanjian
10. Semua dokumentasi disain diperbaharui untuk mencerminkan perubahan buat yang menguji.
11. Semua pengujian adalah lengkap, permasalahan dipecahkan, dan piranti lunak adalah bisa diterima untuk tahap yang berikutnya menguji atau untuk penyerahan.

Di dalam melakukan dari tiap test, pengukuran, pengamatan, dan keluaran untuk prosedur test yang direkam dan dibuktikan oleh QA. Laporan Test ditinjau dan bersertifikat oleh QA untuk memastikan korelasi antara sasaran hasil test dan hasil. Piranti lunak QA meninjau ulang dokumentasi piranti lunak yang berikut dengan konsistensi, kelengkapan, pemenuhan dengan standard, dan informasi perubahan perusahaan :

1. Merancang Rencana
2. Spesifikasi Kebutuhan piranti lunak.
3. Menghubungkan Spesifikasi
4. Dokumen Rancangan Fungsional
5. Pengujian rencana
6. Pengujian prosedur
7. Pengujianlaporan
8. Dokumen Rancangan Rinci
9. Dokumen Instruksi Operasi
10. Dokumen Uraian Versi

Semua program komputer bisa menyampaikan oleh perangkat lunak QA yang bersertifikat. Sertifikasi ini dibuat sebelum diedarkan kepada pemakai itu. Perangkat lunak CPCI secara formal bersertifikat ketika kondisi-kondisi yang berikut ini dicukupi:

1. Semua dokumen relevan dan pekerjaan yang digambarkan adalah lengkap, sekarang, dan di bawah pengendalian perubahan.
2. Tembusan arsip QA dikendalikan menurut format prosedur yang telah mapan.
3. Semua pengujian kecakapan diselesaikan, dokumentasi test diperbaharui dan dilepaskan ketika diperlukan.
4. Semua laporan masalah piranti lunak telah tertutup.

Alternatif ke QA formal

Proyek lebih kecil, dengan suatu staff piranti lunak kurang dari appromimately 20 orang-orang, dapat dengan sukses diatur tanpa jaminan mutu formal, seperti yang telah diuraikan di atas. Suatu penyelamatan biaya substansiil adalah mungkin dengan memodifikasi prosedur QA yang formal seperti yang diuraikan sebagai berikut:

1. Manager proyek, bukannya suatu QA organisasi QA yang mandiri, memberi hak penyerahan dokumen dan piranti lunak.
2. Tidak ada tinjauan ulang mandiri atau monitoring kemajuan teknis pekerjaan.
3. Tidak ada jejak audit QA yang diproduksi.
4. Tinjauan ulang material terpenuhi melalui pengamatan tinjauan ulang dan tinjauan ulang manajemen proyek.

8.1.2 Metoda Verifikasi (Verification Method)

Verifikasi harus dilakukan untuk semua kebutuhan subsistem perangkat lunak oleh penggunaan satu atau lebih metoda yang diperkenalkan di bawah:

1. Inspection. Metoda ini digunakan untuk memverifikasi bahwa piranti lunak menemukan kebutuhan yang tidak bisa dipertunjukkan melalui pengujian operasional. Itu meliputi pengujian hirarki piranti lunak dan diagram alir fungsional, program yang terdaftar, Bahasa Disain Program (Program Design Language (PDL)), dan berhubungan uraian naratif. Kebutuhan ini meliputi format perangkat keras dan piranti lunak dan kesetiaan bagi pemmrogram dan standard disain.
2. Comparison. Metoda ini membandingkan pelaksanaan unsur piranti lunak yang baru dengan suatu program baku yang dikenal, diikuti oleh hasil analisa.
3. Analysis. Metoda ini meliputi suatu analisa keluaran program untuk mengevaluasi capaian algoritma pada berbagai langkah-langkah proses. Itu digunakan untuk mengesahkan logika dan apa yang dihasilkan persamaan yang kompleks tidaklah secara langsung dihubungkan dengan masukan. Analisa terdiri dari perhitungan yang mandiri dari hasil yang diharapkan dan membandingkannya hasil ini dengan hasil program yang sebenarnya.
4. Prior Kecakapan. Metoda ini didasarkan pada suatu demonstrasi bahwa unsur-unsur CPCI sudah lulus lewat kecakapan di dalam sistem lain pemakai.
5. Demonstration. Metoda ini meliputi pengamatan atas capaian sistem di dalam suatu lingkungan yang dikendalikan. Itu menyediakan verifikasi dalam real-time dari fungsi yang terpisah, seperti memasang cahaya atau mulai, membunyikan alarm, warna display yang bervariasi, dan seterusnya.
6. Usage. Metoda ini melibatkan pelaksanaan yang diulangi bersama piranti lunak dengan satu atau lebih metoda uraikan di atas.
7. Test. Metoda ini terpenuhi dengan pelaksanaan satu rangkaian test dengan masukan yang dikenal perlu menghasilkan keluaran dikenal. Hasil percobaan harus mampu untuk menyelesaikan pengujian setelah test.

8.1.3 Menguji Tingkatan (Test Levels)

Pengujian Unit Program dilakukan oleh programmer dan adalah yang diharapkan untuk memverifikasi unit program yang dilaksanakan tunggal itu menurut rancanngan yang diharapkannya. Pengujian pengintegrasian modul dilakukan oleh pengembang organisasi dan dimaksudkan untuk memverifikasi unit program yang individu itu menghubungkan satu sama lain dengan tepat dan bahwa, sebagai kelompok, mereka melaksanakan fungsi yang menggambarkan dokumentasi disain. Pengujian Verifikasi dilakukan oleh organisasi penjamin kualitas dan yang diharapkannya untuk memverifikasi bahwa "as-built" sistem yang dibuat memuaskan kebutuhan seperti yang ditetapkan dalam dokumentasi kebutuhan, Tiga tingkatan ini dilakukan di lokasi pengembangan, yang sering berbeda dengan lokasi operasional itu.

Pengujian Penerimaan dilakukan di lingkungan operasional pemakai, sebagai usaha yang dihubungkan antara organisasi penjamin kualitas dan pemakai, dan yang dimaksudkan untuk menyediakan jaminan yang akhir pemakai itu dengan yang sistemnya dilaksanakan seperti yang ditetapkan dalam lingkungan yang diharapkan. gambar 8.3 menguraikan yang empat tingkatan test piranti lunak yang dibahas pada paragraph yang berikut.

Unit Program Pengujian (Program Unit Testing)
Tujuan Pengujian Unit Program adalah untuk memverifikasi bahwa "as-built" unit program yang dilaksanakan seperti yang ditetapkan pada Dokumentasi Rancangan rinci. Suatu unit yang digambarkan sebagai program komputer tunggal yang dapat diuraikan dalam kaitannya dengan masukan, proses, dan keluaran. Sebagai contoh, di dalam unit Fortran akan sesuai dengan suatu program utama atau suatu subroutine. Test formal merencanakan, memeriksa prosedur, dan menghasilkan untuk Pengujian Unit Program yang tidak dihasilkan kecuali jika test unit memverifikasi bahwa piranti lunak tidak menemukan suatu kebutuhan yang kemudian membuktikan dalam program test.

Test informal merencanakan, memeriksa prosedur, dan hasil dihasilkan oleh programmer ketika perancangan dan coding unit program adalah yang didokumentasikan sesuaian dengan pola unit Pengembangan. Masukan yang utama kepada rencana test dan prosedur adalah Dokumen Rancangan Rinci. Pengujian Unit Program dilakukan secara terpisah dari uji coba unit lain dan terdiri dari dua tahap. Tahap yang pertama melibatkan penyusunan unit itu dan ia mengoreksi kesalahan yang ditandai oleh compiler itu.

Ini menggunakan yang meliputi penggunaan compiler lain yang membantu, seperti daftar referensi silang, untuk memverifikasi bahwa tidak ada definisi variabel kesalahan telah dibuat. Tahap yang kedua dimaksudkan untuk menemukan apapun kesalahan logika di dalam unit itu. Tujuannya adalah untuk memverifikasi bahwa masing-masing cabang program, masing-masing persamaan, dan arus logika dengan baik dieksekusi. Pengujian dilanjutkan sampai semua mengetahui kesalahan telah dihapus dan logika unit program yang disainnya kode matematika.Rancangan tak efisien mempengaruhi dokumentasi yang disampaikan harus ditangani sesuai standar jaminan kualitas yang digambarkan. Secara umum, rancangan yang tak efisien tidak mempengaruhi fungsi selain dari yang ada dalam sistem piranti lunak kodenya dikoreksi, dan perubahannya adalah " red-lined" di dalam suatu salinan Bagian Dokumen Rancangan Rinci yang sesuai, yang mana adalah Folder Pengembangan Unit terpelihara. Ketika kekurangan rancangan yang mempengaruhi antarmuka dengan lain organisasi atau memerlukan suatu spesifikasi perubahan, proses perubahan yang formal dimulai dengan seketika.

Walaupun pengujian adalah informal yaitu, diselenggarakan tanpa prosedur tertulis formal, ini merupakan suatu aktivitas yang direncanakan. Perencanaan adalah yang penting bagi penggunaan komputer yang efisien dan waktu programmer itu. Perencanaan yang diperlukan meliputi penjelasan apa yang programmer berniat untuk memenuhi test yang ditentukan, masukan apa yang diperlukan, keluaran apa yang diharapkan, dan bagaimana test akan jadi diselenggarakan. Program-mer perlu mempersiapkan daftar test untuk dilaksanakan untuk unit masing-masing dan memelihara daftar ini di dalam folder. Test Unit Program diselesaikan sebagai berikut:

1. ketika programmer telah menyelesaikan program test yang direncanakannya dan dicukupi kode yang memenuhi disain itu,
2. ketika semua mengetahui kesalahan telah dihapuskan, dan
3. ketika kode telah ditinjau oleh suatu tim tinjauan ulang melalui kode yang sedang berjalan.

Tinjauan ulang Tim dapat terdiri dari satu atau banyak penulis resensi buku, dengan beberapa di antara mereka terutama lebih disukai dari tim pengembangan. Terkecuali menemukan finding bug. Di dalam kode, tinjauan ulang mempunyai keuntungan tambahan yang menyediakan para programmer lain dengan pengetahuan cukup untuk mengambil alih lebih lanjut uji coba modul jika siapa programmer yang menulis program itu adalah memberikan beberapa alasan dari sesuatu yang tersedia. Suatu daftar nama untuk mengkonfirmasikan bahwa Pengujian Unit Program adalah lengkap meliputi yang berikut:

1. Masing-Masing persamaan telah diuji menggunakan semua parameter yang bisa diterapkan dengan nilai nominal, nilai di batas yang ditetapkan, dan nilai di luar batas itu di mana jika sesuai. Persamaan ini perlu meliputi persamaan pengulangan yang dikendalikan.
2. Tiap-Tiap program cabang telah dieksekusi.
3. Semua mengetahui persandian dan kesalahan disain telah dikoreksi.
4. Semua test yang sukses telah direkam di dalam folder Pengembangan Unit.
5. Hasil percobaan dari test sukses telah diselamatkan.
6. Semua pekerjaan tulis menulis untuk perubahan disain telah diaktipkan.

Sekali ketika Pengujian Unit Program diselesaikan, programmer mengisi suatu Format Pengiriman Perpustakaan Program Komputer (Computer Program Library Transmittal Form (CTF)) dan menyampaikan CTF itu dan kode kepada pustakawan program komputer (lihat bab 9). Unit kemudian adalah mengkombinasikan dengan Pengintegrasian Modul dan unit terkait yang mulai menguji.

Menguji Pengintegrasian Modul (Module Integration Testing)
Menguji Pengintegrasian Modul yang konsis diri dari membangun keseluruhan subsistem perangkat lunak dengan menambahkan pengulangan-pengulangan unit program, kemudian ketika unit program terintegrasi, pengujian untuk memastikan bahwa subsistem piranti lunak yang diterapkan memenuhi satu yang diuraikan dokumentasi disain. ( Pengintegrasian Modul Pengujian adalah juga dikenal sebagai Modul yang diuji, Menguji Pengintegrasian atau Kualifikasi Uji Pendahuluan). Jika perangkat lunak yang penggunaannya diterapkan adalah suatu pendekatan top-down, Menguji Pengintegrasian Modul yang terdiri dari mengintegrasikan unit program yang tertinggi yang pertama dan penggunaan modul yang diuji sebagai bingkai yang bekerja untuk menguji masing-masing unit program secara berurutan.
Menguji Pengintegrasian Modul yang digunakannya adalah suatu building-block yang mengintegrasikan mendekati dan membangun program komputer itu dan, jika bisa diterapkan, subsistem piranti lunak. Modul yang hirarkinya tertinggi yang dulu subsistem piranti lunaknya terintegrasi. Pengintegrasian maju langkah demi langkah menurut suatu jadual berdasarkan pada fungsi itu untuk dilakukan oleh modul, inter ketergantungan mereka, ketersediaan mereka, dan data antarmuka masukan. Potongan yang digantikan untuk rutin tingkat bawah untuk mengisolasikan fungsi itu di bawah Potongan perjanjian uang digantikan langkah demi langkah oleh modul yang nyata sampai subsistem perangkat lunak adalah lengkap. Suatu keuntungan yang utama top-down pengintegrasian dan menguji pendekatan adalah bahwa alat penghubung subsistem yang utama digambarkan pada suatu tingkat tinggi hirarki, dan kemudian dibuktikan pada awal proyek itu. Sekali ketika alat penghubung dibuktikan, implementasinya dan diuji coba subsistem yang berbeda bisa dilakukan dengan bebas. Tujuan Pengujian Pengintegrasian Modul adalah untuk memverifikasi bahwa:

1. Unit Program yang individu menghubungkan satu sama lain dengan tepat untuk membentuk modul itu yang diuraikan dalam Dokumen Disain Rinci.
2. Modul telah menjadi dengan baik coded, sedemikian sehingga semua persamaan berfungsi dengan baik dan semua alur logika beroperasi seperti yang dirancang.
3. Modul menghubungkan satu sama lain untuk membentuk subsistem perangkat lunak itu yang diuraikan dalam Dokumen Disain Rinci.
4. Ada suatu kemajuan rapi ke arah kemampuan piranti lunak yang akhirnya akan jadi dibuktikan menguji Verifikasi.

Prosedur Test formal disiapkan bersama-sama oleh pengembangan software dan perusahaan penjaminan kualitas piranti lunak dan didokumentasikan, ditinjau, dan disetujui. Perusahaan penjaminan kualitas piranti lunak perlu melaksanakan suatu tinjauan ulang prosedur sebelum penggunaan mereka oleh organisasi pengembangan software. QA piranti lunak perlu memastikan bahwa semua test yang diselenggarakan sesuai dengan prosedur yang terpenuhi didokumentasikan. Apapun penyimpangan harus didokumentasikan.

Test Pengintegrasian Modul diselenggarakan menggunakan data masukan dinamis dan yang statis diperlukan untuk melaksanakan inter modul dan eksekutip yang menghubungkan dan untuk berlatih fungsi operasional. Itu adalah yang diinginkan untuk mempunyai akses pada kenyataan atau pengolah target selama Pengujian Pengintegrasian Modul. Dalam posisi ini, sistem operasi harus secara penuh mampu untuk mendukung test ini. Di mana jika Sistem Pengintegrasian Modul yang diselenggarakan penggunaannya adalah suatu simulasi pengolah target, target pengolah harus dibuat bertahap ke dalam pengujian yang secepat itu menjadi tersedia. Test kembali cukup harus terpenuhi untuk memastikan kecocokan penuh.
Suatu komplemen matematika yang penuh dan rutin digunakan, mencakup test dan bantuan debugging, harus tersedia untuk Menguji Pengintegrasian Modul. Test Perangkat keras yang diperlukan meliputi semua sekeliling keperluan: terminal pemakai, pencetak garis, disk dan pengontrol tape dan pengarah, operator menghibur, dan seterusnya. Test ini lengkap di lingkungan yang tidak mungkin diperlukan sepanjang langkah-langkah awal pengujian, tetapi akan diperlukan ketika menguji kemajuan.

Masukan Test Data yang diperlukan datang dari perangkat keras/ piranti lunak yang nyata menghubungkan, jika tersedia. Cara lainnya, masukan data harus mewakil contoh antarmuka yang nyata itu. Pengarah Test dan lain program test yang memerlukan untuk memverifikasi dan Penerimaan Pengujian harus digunakan Pengujian Pengintegrasian Modul. Ini disahihkan untuk menggunakan Verifikasi formal yang menguji sebagai hasil operasi sukses selama Menguji Pengintegrasian Modul. Menguji Pengintegrasian Modul terdiri dari dua unsur-unsur: Menguji Pengintegrasian dan Menguji Verifikasi Fungsional.

Menguji Pengintegrasian yang memverifikasi ketepatan antarmuka program dengan pengujian bahwa masing-masing program dapat dipanggil dan dihubungi oleh program itu menghubungkan dengan, dan lewat parameter dengan baik. Tujuan Pengujian Pengintegrasian Modul yang utama adalah :

1. untuk menetapkan kecocokan antara modul dan program komputer saling berinteraksi, dan
2. untuk menetapkan kecocokan program dengan antar muka eksternal mereka.

Menguji Verifikasi Fungsional yang terdiri dari menguji koleksi unit program telah diterapkan dan pengujian untuk melihat bahwa mereka berfungsi sebagai suatu modul yang terintegrasi dan melaksanakan fungsi itu yang ditugaskan kepada mereka di dalam Dokumen Disain Rinci. Menguji Verifikasi Fungsional yang terdiri dari menguji koleksi unit program yang telah diterapkan dan pengujian untuk melihat bahwa mereka berfungsi sebagai suatu modul yang terintegrasi dan melaksanakan fungsi itu yang ditugaskan kepada mereka di dalam Dokumen Disain Rinci. Pengujian Verifikasi Fungsional pada umumnya dilakukan betapapun unit program yang berisikan suatu modul, suatu yang digambarkan pada dokumentasi disain, sudah lulus lewat Pengujian Pengintegrasian.

Penyelesaian Pengintegrasian Modul yang memuaskan pengujian yang menetapkan bahwa perangkat lunak yang diterapkan dengan baik melaksanakan fungsi itu menetapkan dokumentasi disain dan adalah menyisiapkannya untuk dibuktikan melawan terhadap kebutuhan yang ditetapkan Kebutuhan spesifikasi perangkat lunak.
Menguji Verifikasi (Verification Testing)
Menguji Verifikasi yang terdiri dari test, demonstrasi, dan melakukan analisa untuk mengkonfirmasikan bahwa piranti lunak membuat puas semua kebutuhan terasang permanen dan yang diperoleh dari Spesifikasi Persyaratan Piranti lunak. Spesifikasi Disain Rinci, yang digunakan pengujian lebih awal, hanya suatu permainan peran pelajaran pelengkap di dalam menguji verifikasi. Sebagai gantinya, awal dokumen yang menyatakan kebutuhan sistem atau perangkat lunak dan sasaran hasil produk atau misi itu adalah sumber yang utama dari kasus test yang diperoleh. Suatu korelasi antara Spesifikasi Persyaratan Piranti lunak dan Rencana Test Verifikasi disiapkan dalam bentuk Rencana Test. Prosedur Dan Rencana Test formal tertulis untuk Verifikasi pengujian. Analisa dilakukan untuk kebutuhan adalah terlalu mahal untuk memverifikasi dengan pengujian atau demonstrasi.
Test Verifikasi diselenggarakan di lingkungan test yang sama sebagai Test Pengintegrasian Modul, Penggunaan komplemen piranti lunak pendukungnya penuh, perangkat keras sekelilingnya, dan alat operator, lebih pengolah target, dengan kemampuan sistem operasi penuh dan perangkat keras nyata atau realistis menghubungkan data.
Sebelum dimulai Pengujian Verifikasi, program komputer daftar harus dilepaskan, kode program komputer harus di bawah pengendalian konfigurasi formal di dalam Program Komputer Perpustakaan , dan test prosedur harus disetujui semuanya. Semua Pengujian Verifikasi diselenggarakan di bawah pengawasan proyek yang digolongkan pejamin kualitas. Oleh karena pengujian yang luas mendahului test ini, itu diharapkan bahwa secara relatif sedikit kesalahan yang terjadi akan terbongkar dan terbuka pada Pengujian Verifikasi.
Pengulangan test dan pengujian yang berlebih-lebihan harus dengan bebas dihindarkan. Disimpulkan dari test ini, semua kebutuhan yang dapat dibuktikan pada tingkatan ini akan dibuktikan dan hasil percobaan dianalisa dan melepaskan. Test memverifikasi antarmuka eksternal, mempertunjukkan bahwa program komputer membuat kepuasan fungsional yang ditetapkan dan kebutuhan tercapai, dan mempertunjukkan capaian program komputer di bawah yang menirukan kondisi-kondisi operasional yang serupa bagi mereka yang mengharapkan operasi nyata. Ke tiga tingkatan test diuraikan di atas yang diterapkan serial berkenaan dengan unit program tertentu , tetapi dilakukan secara serempak pada seluruh tahap pengujian proyek itu. Suatu unit program masuk Pengujian Pengintegrasian Modul itu yang tahapannya secepat itu telah lulus lewat Pengujian Unit Program. Pada setiap waktu selama implementasi piranti lunak, suatu Verifikasi Test mungkin adalah dijumpai. Yang dipertunjukan bahwa tujuannya tercapai pada keseluruhan kebutuhan subsistem piranti lunak.

Pengujian Penerimaan
Banyak dari Test Verifikasi yang diulangi Pengujian Penerimaan untuk memverifikasi bahwa perangkat lunak yang dilaksanakan di lingkungan yang operasionalnya sebagai di dalam lingkungan test. Di dalam kejadiannya banyak orang, Pengujian Penerimaan adalah satu-satunya pengujian di mana perangkat lunak beroperasi dengan alat penghubung eksternal yang nyata, dibandingkannya dengan perangkat lunak test dan perangkat keras. Pada PDR persetujuan harus dicapai dengan pemakai bahwa pelaksanaan dari kasus test ini di dalam suatu cara menguraikan Test yang menggunakan rencana suatu data base yang disetujui dan memproduksi hasil percobaan yang mencukupi penerimaan yang digambarkan kriteia yang akan mengakibatkan penerimaan terhadap sistem perangkat lunak

Disimpulkan Menguji Penerimaan dan setelah Test Laporan telah tertulis, Tinjauan ulang Penerimaan perangkat lunak (Software Acceptance Review ( SAR)) dipegang. Pada tinjauan ulang ini produk perangkat lunak, kode, dokumen, dan hasil percobaan ditinjau. Jika semua materi adalah memuaskan dan sesuai penerimaan yang merencanakan tercakup di Test perencanaannya, perangkat lunak diterima. Kebutuhan SAR diuraikan bagian 8.3.3.
Dokumentasi akhir harus direncanakan untuk penyerahan setelah pelaksanaan sukses dari semua Test Penerimaan sedemikian rupa sehingga koreksi yang diharuskan oleh kesalahan yang terdeteksi akhirnya di dalam program test yang formal dapat dimasukkan.

Alternatif adalah untuk menyampaikan dokumen itu yang lebih awal dan mempunyai biaya dan tidak menyenangkan untuk mengeluarkan lembaran kesalahan yang tertulis atau halaman perubahan. Pendekatan yang belakangan tidaklah direkomendasikan. Oleh karena itu, pada waktu penerimaan, yang akhir itu "asbuilt" Dokumen Disain Rinci yang harus disiapkan dan Dokumen instruksi beroperasi harus diselesaikan. Dengan penyerahan masing-masing perangkat lunak, suatu Uraian Versi Dokumen adalah juga diperlukan.

8.1.4 Pengendalian Tes (Test Control)
Pengujian Unit Program dilakukan dan dikendalikan oleh programmer siapa yang menerapkan unit itu. Sebelum persandian unit, programmer perlu mepelajari Uraian Dokumen Disain Rinci unit program dan siapkan rencana test informal dan memeriksa prosedur. Ini disatukan pada Folder Pengembangan Unit. Sekali ketika unit lewat Menguji Unit Program, itu disampaikan kepada Perpustakaan Program Komputer. Unit kemudian adalah mengintegrasikan ke dalam sistem, dan Pengujian Pengintegrasian modul dilakukan oleh kelompok pengembangan, yang dibantu oleh QA organisasi. Bila ada permasalahan yang ditemukan, mereka didokumentasikan pada suatu Laporan Masalah Perangkat lunak (Software Problem Report ( SPR)) Format ( lihat bab 9) dan unit itu dikembalikan ke programmer untuk dimodifikasi dan unit program yang berikutnya diuji kembali.

Jika Pengujian Pengintegrasian Modul untuk suatu program yang membongkar suatu masalah di dalam program yang telah duji , program ini harus dipindahkan dari tempat alas test ( koleksi dari modul perangkat lunak yang diuji) dan dikembalikan ke programmer itu untuk dimodifikasi dan diuji. Masalahmya tergantung pada kesungguhan hati, semua dari bagian dari Pengujian Pengintegrasian Modul harus diulangi yang melibatkan program yang salah/cacat itu. Keputusan dari apa yang telah ditest perlu untuk pengulangan adalah dibuat oleh organisasi pengembangan software. Sekali melengkapi program;menyudahi Pengujian Pengintegrasian Modul itu yang menjadi bagian dari dasar test sistem yang dan digunakan sebagai bagian dari bingkai yang bekerja untuk menguji lain program.
Ketika keseluruhan sub system perangkat lunak telah lulus lewat Pengujian Pengintegrasian Modul, Pengujian Verifikasi dilakukan. Pemakai harus dilibatkan sedapat sebanyak mungkin di dalam Uji Verifikasi agar supaya menjadi terbiasa dengan operasi perangkat lunak. Organisasi Penjamin kualitas melaksanakan Pengujian Verifikasi. Bila ada permasalahan yang terbongkar / terbuka, mereka mendokumentasikan adalah suatu Laporan Masalah Perangkat lunak ( lihat bab 10), dan programnya salah/cacat terisolasi dan dikembalikan ke para programmer itu. Program harus ditetapkan;perbaiki dan diuji kembali menurut prosedur itu seperti yang ditetapkan di atas. Verifikasi yang gagal test kemudian adalah diulangi sampai masalahnya terpecahkan.
Itu adalah tanggung jawab penjamin kualitas yang perorangan untuk memutuskan penyelesaian Verifikasi Test yang perlu untuk diulangi untuk tidak memastikan bahwa apapun efek samping adalah disebabkan oleh perubahan perangkat lunak yang dibuat untuk memecahkan permasalahan yang dikenali itu. Perangkat lunak harus dirancang untuk yang memerlukan saling ketergantungan minimal antara modul, sedemikian rupa sehingga perubahan satu modul tidak akan mempengaruhi lain modul. Ini akan mengijinkan pengujian untuk dilanjutkan ke area yang tidak bertalian dengan perangkat lunak yang sedang ada permasalahan ditetapkan diperbaiki. Pengujian Penerimaan diselenggarakan oleh organisasi penjamin kualitas dan pemakai di dalam lingkungan yang operasional itu. Bila ada permasalahan yang ditemukan, pemakai mempunyai hak untuk meminta bahwa keseluruhan Prosedur Test Penerimaan dimulai kembali ( kecuali jika lain prosedur yang telah ditetapkan pada Rencana Test).
Pengendalian Proses Pengujian oleh dokumentasi test yang berikut:

1. Rencana Test Unit Program informal dan Meriksa prosedur Folder Pengembangan Unit dan
2. Rencana Test formal dan Prosedur untuk Pengujian Pengintegrasian Modul, Pengujian Verifikasi, dan Pengujian Penerimaan.

Itu adalah tanggung jawab organisasi penjamin kualitas untuk memastikan bahwa semua pengujian adalah sesuai dengan dokumen ini dan bahwa semua hasil didokumentasikan. Pengendalian konfigurasi yang menempatkan pada dokumen ini diuraikan bab 9.


8.2 PROSES TEST DOKUMENTASI (TEST PROCESS DOCUMENTATION)

Tujuan aktivitas perencanaan test adalah bermakna untuk menetapkan untuk secara formal yang mempertunjukkan bahwa perangkat lunak komputer untuk dikirimkan membuat kepuasan kebutuhan yang susuai kontrak dan kinerjanya menurut Spesifikasi Persyaratan Piranti lunak yang telah disetujui.
Produk aktivitas perencanaan test adalah dokumentasi test. Dokumentasi Test formal yang diperlukan terdiri dari suatu Rencana Test, Menguji Prosedur Documen, dan Menguji Laporan. gambar 9.4 menyediakan suatu ringkasan parameter yang berhubungan dengan dokumentasi test yang formal.
Tujuan Rencana Test adalah untuk menetapkan kebutuhan terperinci, ukuran-ukuran, metoda umum, tanggung-jawab, dan perencanaan menyeluruh untuk mengkonfirmasikan bahwa "sebab yang dibangun" sistem memenuhi kebutuhan yang ditetapkan Spesifikasi Persyaratan Piranti lunak. Itu menggambarkan aktivitas test itu untuk dilakukan oleh pengembang piranti lunak untuk mencapai penerimaan piranti lunak oleh pemakai. Tujuan Prosedur Test adalah untuk menggambarkan secara detil prosedur yang nyata untuk dipekerjakan untuk melaksanakan test itu yang menggambarkan Test itu direncanakan. Dokumen Laporan Test hasil proses pengujian dan digunakan untuk secara formal untuk meyakinkan pemakai bahwa sistem yang beroperasi seperti yang ditetapkan.
Muatan yang terperinci dari tiap dokumen ini adalah mungkin ditemukan Catatan tambahan B.

8.2.1 Rencana Tes (Test Plan).
Rencana Test menguraikan program test piranti lunak yang lengkap. Itu menggambarkan pengujian pengembangan apa yang akan dilakukan oleh programmer, Pengintegrasian Modul apa, Verifikasi, dan Test Penerimaan akan dieksekusi, dan kondisi-kondisi di bawah masing-masing unsur-unsur program test yang mana akan terpenuhi.

Rencana Test yang menggambarkan bentuk wujud test itu, menguji jadual, dan test mengukur, mengidentifikasi peralatan test diperlukan suatu test piranti lunak, menggambarkan peran berbagai organisasi di dalam memproses test, menggambarkan pengendalian konfigurasi itu untuk diterapkan pada tingkatan masing-masing pengujian, dan mengidentifikasi kasus test untuk dieksekusi pada tingkatan test masing-masing. Uraian yang terperinci kasus test disiapkan dalam bentuk Prosedur Test itu. Yang secara rinci, Rencana Test menguraikan:

1. Tanggung-Jawab yang organisatoris untuk berbagai tugas di dalam program test.
2. Metoda untuk dipekerjakan untuk meninjau ulang rencana test dan prosedur, monitor dan pengendalian pelaksanaan test, laporan dan mengoreksi pertentangan test, melaporkan hasil percobaan, dan menentukan kesiap-siagaan untuk penerimaan.
3. Tujuan Dan Konsep yang tertinggi untuk pengembangan dan Pengujian Penerimaan dan strategi untuk memenuhi tujuan ini, mencakup suatu uraian test mengukur dan filosofi pengembangan.
4. Generator Data, menguji pengarah, simulator lingkungan dan program analisa test memerlukan untuk masing-masing tingkatan yang diuji. (Catatan : Seluruh pengujian piranti lunak harus dibuktikan dan di bawah konfigurasi pengendalian sebelum penggunaannya untuk verifikasi formal.)
5. Konsep Dan Metoda menekankan piranti lunak ( e.g., dengan sibuk dan jika tidak ada data masukan tidak sempurna, atau dengan data puncak yang mengisi) selama tingkatan pengujian masing-masing.
6. Jadual Test, Yang menyediakan suatu uraian yang terperinci urutan dari semua aktivitas test. Jadual Test harus dibentuk mapan untuk memastikan bahwa pengujian yang diperlukan akan diselesaikan di dalam periode waktu yang dibagikan. Jadual Test harus kompatibel dengan:
   (a) Ketersediaan fasilitas komputer.
   (b) Ketersediaan piranti lunak untuk diuji
   (c) Ketersediaan pendukung piranti lunak test
   (d) Ketersediaan intefacing piranti lunak dan perangkat keras
   (e) Ketersediaan dari peralatan test khusus
   (f) Keseluruhan proyek menguji jadual
7. Lingkungan Test, mencakup bentuk wujud perangkat keras, menguji konfigurasi piranti lunak, dan memerlukan pembuktian unsur-unsur piranti lunak baru. Lingkungan Test harus dibentuk mapan sebagai bagian dari proses perencanaan test di depan kasus test dapat digambarkan. Diagram blok, mempertunjukkan kemajuan pengujian konfigurasi, yang harus disiapkan untuk masing-masing tingkatan pengujian.
8. Test yang individu untuk dilakukan untuk mempertunjukkan pemenuhan dengan kebutuhan. Uraian dari tiap kasus test meliputi kebutuhan itu untuk dibuktikan,konfigurasi test untuk digunakan, dan piranti lunak test yang diperlukan. Prosedur Test akan disiapkan yang kemudiannya untuk masing-masing mengenali kasus test.
9. Suatu subset kasus test yang menggambarkan Test direncanakan. Test ini harus dikenali seperti Kasus Test Penerimaan untuk menyediakan tujuan penerimaan piranti lunak. Kasus ini harus disetujui dengan pelanggan ketika Rencana Test Penerimaan.

Sebagai contoh table untuk Perencanaan Pengujian/Test adalah disediakan pada gambar 8.5.

8.2.2 Prosedur Pengujian (Test Procedures)

Test Dokumen Prosedur dikembangkan untuk menguraikan Pengintegrasian Modul itu, Verifikasi, dan Prosedur Test Penerimaan. Prosedur ini mungkin adalah dikombinasikan ke dalam satu dokumen untuk program komputer kecil, satu dokumen untuk prosedur pada masing-masing menguji tingkatan, atau, karena sistem besar, volume tambahan terpisah.
Karena masing-masing kasus test mengenali Test yang direncanakan, Prosedur Test menggambarkan bentuk wujud test itu, test yang dilakukan, dan hasil percobaan. Bentuk wujud Test menetapkan material test yang spesifik, masukan data, test rutin, dan konfigurasi perangkat keras. Test yang dilakukan itu menguraikan secara bertahap berurutan diikuti untuk melakukan penyelenggaraan test, bagaimana dan kapan menguji data yang diharapkan untuk masuk, dan mengharapkan hasil. Hasil yang diharapkan meliputi toleransi yang bisa diterima dan suatu pendukung diskusi bagaimana hasil ini menunjukkan bahwa sasaran test telah dicukupi. Di mana jika informasi tambahan bisa dilaksanakan pada pilihan program dan yang diperkirakan waktu dijalankan harus dikenali. Suatu tabel contoh isi Dokumen Prosedur Test ditunjukkan pada gambar 8.6.

Di mana seperti Rencana Test yang memberi suatu ikhtisar program test, Dokumen Prosedur Test memberinya secara bertahap prosedur yang terperinci yang diperlukan untuk menguji perangkat lunak itu. Karena sejak Rencana Test dikirimkan format akhir pada CDR, itu tidak bisa meliputi suatu uraian yang terperinci dari semua pemakai yang memerlukan hubungan. Prosedur Test berisi acuan kepada Test yang direncanakan, di mana jika sesuai, untuk menghindari duplikasi informasi. Mereka mempunyai banyak dari bagian yang sama sebagai Rencana Test, tetapi berisi yang lebih detil tentang kenyataan perancangan test itu.
Karena merampas perkerjaan mengikuti jalan dan dokumen itu menguji proses, masing-masing tingkatan test dapat dipecah ke dalam tahap test. Di dalam Pengujian Pengintegrasian Modul, tahap test ini menghadirkan peristiwal fungsional yang utama di dalam proses pengembangan. Di dalam Verifikasi Dan Pengujian Penerimaan, tahap ini menghadirkan peristiwa yang utama utama di dalam menguji proses itu. Tahap yang dapat digambarkan oleh modul yang diselesaikan atau oleh peristiwa fungsional di dalam satu subsistem ketika suatu kemampuan yang bisa menguji baru ditambahkan kepada subsistem itu. Test bertahap harus yang cukup kecil untuk pengujian terpenuhi dua sampai empat jam.


ISI : DOKUMEN RENCANA PENGUJIAN

Bagian 1 Pengenalan
1.1 Lingkup
1.2 Maksud
1.3 Ringkasan

Bagian 2 Dokumen Keterkaitan
1.1 Referensi yang dapat diterapkan
1.2 Dokumen Pengembangan

Bagian 3 Konsep Pengujian
1.1 Filosofi Pengujian
1.2 Verifikasi Metode
1.3 Tingkatan Pengujian
1.3.1 Unit Pengujian Program
1.3.2 Pengujian Integrasi Modul
1.3.3 Verifikasi Pengujian
1.3.4 Penerimaan Pengujian

1.4 Peraturan Organisasi
1.4.1 Pengembangan Piranti Lunak
1.4.2 Penjamin Produk
1.4.3 Pengendalian Produk
1.4.4 Verifikasi dan Sertifikasi
1.4.5 Integrasi dan Pengujian
1.4.6 Human Engineering

1.5 Pengendalian Pengujian
1.5.1 Penjamin Kualitas
1.5.2 Memonitor Pengujian
1.5.3 Pengendalian Konfigurasi Pengujian

Bagian 4 Verifikasi Persyaratan dan Kriteria
4.1 Pengujian ke I
1.1.1 Deskripsi Pengujian
1.1.2 Pelaksanaan Pengujian
1.1.3 Hasil yang diharapkan
…….
4.n Pengujian n
4.n.1 Deskripsi Pengujian
4.n.2 Pengujian Masukan
4.n.3 Pelaksanaan Pengujian
4.n.4 Hasil yang diharapkan

Bagian 5 Persyaratan dan Ringkasan Tahap Pengujian

Bagian 6 Pengujian Integrasi Modul
1.1 Pengenalan
1.2 Lokasi dan Jadual
1.3 Pembatasan dan Komentar Umum
1.4 Persipan Masukan
1.5 Pengujian Dilakukan
1.6 Hasil Analisis
1.7 Pengujian Lingkungan
1.8 Persyaratan Personil

Bagian 7 Verifikasi Pengujian
1.1 Pengenalan
1.2 Lokasi dan Jadual
1.3 Pembatasan dan Komentar Umum
1.4 Persipan Masukan
1.5 Pengujian Dilakukan
1.6 Hasil Analisis
1.7 Pengujian Lingkungan
1.8 Persyaratan Personil

Bagian 8 Penerimaan Pengujian
8.1 Pengenalan
8.2 Lokasi dan Jadual
8.3 Pembatasan dan Komentar Umum
8.4 Persipan Masukan
8.5 Pengujian Dilakukan
8.6 Hasil Analisis
8.7 Pengujian Lingkungan
8.8 Persyaratan Personil

Bagian 9 Pengendalian dan Prosedur Pelaporan
9.1 Pengendalian Pengujian Program
9.2 Dokumentasi Prosedur PengujianDokumentasi Laporan Pengujian

8.2.3 Laporan Pengujian (Test Reports)
Dokumen Laporan Test hasil untuk masing-masing tahap pengujian kasus yang menggambarkan Rencana Test dan yang diuraikan secara detil di dalam Prosedur Test. Hasil percobaan untuk masing-masing kasus test diuraikan dengan suatu ringkasan permasalahan yang ditemukan, SPRs menulis lagi test, yang disposisi SPRs, dan disposisi keluaran test yang berhasil pada pelaksanaan yang terakhir. Juga dimasukkan adalah yang manapun direkomendasikan perubahan pada dokumentasi yang sebelumnya, yang mencakup halaman perubahan dan permintaan surat pelepasan tuntutan. Suatu daftar isi contoh untuk Dokumen Laporan Test disiapkan dalam bentuk gambar 8.7.


8.3 TEST TINJAUAN ULANG (TEST REVIEWS)

Tiga jenis tinjauan ulang diadakan untuk pendukung pengujian:

1. Rancangan Kritis Dan persiapan tinjauan ulang untuk meninjau ulang rancangan dan Perencanaan Test,
2. Menguji Tinjauan ulang (Prosedur Test Procedures Review (TPR)), yang sebelum ditangani pengujian formal (mungkin adalah dtangani kenaikannya), dan
3. Tinjauan ulang Penerimaan Piranti lunak (SAR)

ISI : DOKUMEN PROSEDUR PENGUJIAN

Bagian 1 Pengenalan
1.1 Maksud
1.2 Lingkup
1.3 Ringkasan

Bagian 2 Dokumen Keterkaitan
1.1 Referensi yang dapat diterapkan
1.2 Dokumen Pengembangan

Bagian 3 Pengujian Obyektiv

Bagian 4 Orang yan Bertanggung Jawab

Bagian 5 Perlengkapan dan Persyaratan program Komputer

Bagian 6 Prosedur Operasi Pengujian
6.1 Inisiatif Sistem Operasi
6.2 Pemeliharaan Sistem Operasi
6.3 Mengakhiri dan Mengulang Sistem Operasi

Bagian 7 Prosedur Rinci Pengujian : Pengujian Integrasi Modul
3. Pengujian ke I
4. Deskripsi Modul
5. Pengujian Masukan
6. Pengujian Dilakukan
7. Hasil yang diharapkan
…..
7.n Pengujian ke n
7.n.1 Deskripsi Modul
7.n.2 Pengujian Masukan
7.n.3 Pengujian Dilakukan
7.n.4 Hasil yang diharapkan

Bagian 8 Penerimaan Pengujian
8.1 Pengujian ke I
8.2 Deskripsi Modul
8.3 Pengujian Masukan
8.4 Pengujian Dilakukan
8.5 Hasil yang diharapkan
…..
8.n Pengujian ke n
8.n.1 Deskripsi Modul
8.n.2 Pengujian Masukan
8.n.3 Pengujian Dilakukan
8.n.4 Hasil yang diharapkan

Bagian 9 Pengendalian dan Prosedur Pelaporan
9.1 Pengujian ke I
9.2 Deskripsi Modul
9.3 Pengujian Masukan
9.4 Pengujian Dilakukan
9.5 Hasil yang diharapkan
…..
9.n Pengujian ke n
9.n.1 Deskripsi Modul
9.n.2 Pengujian Masukan
9.n.3 Pengujian Dilakukan
9.n.4 Hasil yang diharapkan

Bagian 10 Analisis dan Reduksi Data
10.1 Mencatat dan Persyaratan Reduksi
10.2 Reduksi Data dan Prosedur Analisis

Appendix A Akronim dan Singkatan
Appendix B Definisi dan Nomenklatur

Gambar 8.6 Contoh table isi untuk Dokumen Prosedur Pengujian


ISI : DOKUMEN PELAPORAN

Bagian 1 Pengenalan
1.1 Maksud
1.2 Lingkup
1.3 Ringkasan

Bagian 2 Dokumen Keterkaitan
2.1 Referensi yang dapat diterapkan
2.2 Dokumen Pengembangan

Bagian 3 Pengujian Obyektiv dan Hasil

Bagian 4 Laporan Pengujian : Pengujian Integrasi Modul
1.1 Pengujian ke I
……
4.n Pengujian ke n

Bagian 5 Perlengkapan dan Persyaratan program Komputer
5.1 Pengujian ke I
…..
5.n Pengujian ke n

Bagian 6 Prosedur Operasi Pengujian
6.1 Pengujian ke I
…..
6.n Pengujian ke n

Bagian 7 Prosedur Rinci Pengujian : Pengujian Integrasi Modul
7.1 Revisi Dokumen
7.2 Pengujian Tambahan
7.3 Permintaan Surat Pelepasan tuntutan

Bagian 8 Attachment untuk Laporan Pengujian

Appendix A Akronim dan Singkatan
Appendix B Definisi dan Nomenklatur
Appendix C Data Pendukung

Gambar 8.7 Contoh table isi untuk Dokumen Prosedur Pengujian

Yang ditangani Setelah Pengujian Penerimaan dengan sukses diselesaikan dan semua diperlukan dokumentasi yang telah disiapkan atau diperbaharui kepada" as-built" bentuk wujud. Organisasi penjamin kualitas menghadiri semua tinjauan ulang untuk memastikan bahwa program penjamin kualitas diterapkan. Isi, Format, dan yang diharapkan hasil dari tinjauan ulang ini dibahas pada subseksi yang berikut ini.

8.3.1 Disain Kritis Dan Persiapan Tinjauan Ulang (Preliminary and Critical Design Reviews)

Format rencana test ditinjau dalam persiapan Disain Kritis dan persiapan tinjauan ulang (Preliminary Design Review ( PDR)) dan di dalam format terakhir Tinjauan ulang Disain Kritis (Critical Design Reviews (CDR)). Tujuan Tinjauan ulang Rencana Test adalah untuk memastikan bahwa semua corak disain penting akan diuji dan bahwa semua kebutuhan spesifikasi akan dibuktikan. Filosofi Program Test memperkenalkan Rencana Test yang telah dipersiapkan ditinjau secara detil di PDR itu. Detil test yang nyata adalah di dalam Rencana Test yang akhirnya peninjauan pada CDR.

8.3.2 Menguji Tinjauan ulang Prosedur (Test Procedures Review)
Prosedur Test Perangkat lunak ditinjau pada Tinjauan ulang Prosedur Test untuk memastikan bahwa pengujian cukup akan dilakukan pada komponen masing-masing. Tinjauan ulang ini menyediakan persetujuan formal untuk prosedur untuk digunakan di dalam menguji dan memastikan bahwa mereka menyelesaikan tujuan Test yang telah direncanakan.
Dua rangkaian Tinjauan ulang Prosedur Test diselenggarakan: Prosedur Test Pengembangan Tinjauan ulang. Ini harus diselenggarakan secara terpisah. Tinjauan ulang Prosedur Test Pengembangan diselenggarakan sebelum Pengujian Pengintegrasian Modul dan tinjauan ulang prosedur itu untuk diikuti Sistem Pengintegrasian Modul. Tinjauan ulang Prosedur Test Pengesahan diselenggarakan sebelum Pengujian Verifikasi untuk meninjau ulang prosedur untuk diikuti Verifikasi Dan Pengujian Penerimaan. Test Pengembangan diselenggarakan untuk memastikan bahwa program komputer yang diselesaikan yang membuat kepuasan kebutuhan tercapai yang dinyatakan nya. Seperti itu, test pengembangan mengevaluasi program komputer itu lagi kebutuhan di dalam Spesifikasi Kebutuhan Perangkat lunak. Materi untuk diuji mengevaluasi prosedur test ini seperti daftar di bawah ini:

1. Uji Procedures/Plan Kecocokan. Prosedur harus konsisten dengan Test Rencanakan dan meliput semua area test diperlukan.
2. Menguji Masukan. Test Masukan harus digambarkan; masukan menggambarkan untuk test melakukan harus mampu untuk menguji disain pada batas nya.
3. Menguji Kelengkapan. Test yang didokumentasikan [perlu] mencukupi semua sasaran hasil test. Semua aspek/pengarah [yang] penting perangkat lunak disain harus dicoba-coba pengujian dan harus didokumentasikan.
4. Meriksa prosedur Kejelasan. Operator Instruksi harus dinyatakan dengan jelas, dengan singkat, dan secara terang.
5. Kofigurasi Piranti lunak. Bentuk wujud piranti lunak untuk diuji harus dengan teliti dan secara menyeluruh uraikan.
6. Ukuran-Ukuran Sukses. Sukses Ukuran-Ukuran harus digambarkan untuk masing-masing langkah pada setiap prosedur test; mereka harus konsisten dengan sasaran hasil ia perjanjian
7. Konfigurasi Perangkat keras. Perangkat keras Test Bentuk wujud harus cukup untuk melakukan test dan menggambarkan dalam detail yang jelas untuk mengevaluasi ketercukupan nya.
8. Menguji Konfigurasi Piranti lunak. Piranti lunak Test yang diperlukan konfigurasi harus cukup digambarkan. Pemenuhan perlu meliputi susunan test, masukan data, sekeliling, display, ukuran-ukuran sampling data, tingkat data rate, dan seterusnya.

8.3.3 Penerimaan Tinjauan Ulang Piranti lunak (Software Acceptance Review)

Tinjauan ulang Penerimaan Piranti lunak adalah suatu pertemuan formal diadakan untuk audit produk piranti lunak sebelum diterima pemakai. Penyelesaian dari audit ini menandakan bahwa perangkat lunak adalah siap untuk dioperasikan dan tahap pengembangan itu adalah lengkap. Tinjauan ulang yang secara normal terdiri dari dua audit: suatu Audit Konfigurasi Fungsional (Functional Configuration Audit (FCA)) dan suatu Audit Konfigurasi Phisik (Physical Configuration Audit (PCA)). Audit ini mungkin adalah diselenggarakan incrementally sebagai informasi yang perlu menjadi tersedia. Jika mereka diselenggarakan incrementally, kebanyakan materi tinjauan ulang akan merupakan suatu perihal merekam pada ketika pertemuan yang formal itu. SAR akan kemudian berisi sebagian besar menguji arsip untuk memastikan bahwa semua audit materi telah diselesaikan.

Audit Konfigurasi Fungsional (Functional Configuration Audit (FCA))
Sasaran FCA adalah untuk memverifikasi bahwa capaian piranti lunak mematuhi persyaratan capaian spesifikasi perangkat lunak itu. Ini adalah terpenuhi dengan tinjauan ulang data test itu yang mengumpulkan pengujian piranti lunak. Masing-Masing konfigurasi piranti lunak untuk disampaikan mungkin adalah tunduk kepada suatu FCA. Audit perlu menentukan yang berikut:

1. Kelengkapan Verifikasi. FCA perlu meliputi suatu audit test merencanakan, memeriksa prosedur, dan menghasilkan untuk mengkonfirmasikan bahwa data test dan hasilnya mematuhi rencana test itu dan memeriksa prosedur. Jika defisiensi dicatat, mengulangi test atau pengujian tambahan harus direkomendasikan. Di mana jika ada penyelesaian kebutuhan verifikasi parsial, status harus dibentuk mapan dan rencana untuk penyelesaian harus diperkenalkan
2. Kebenaran Simulasi. FCA perlu mengkonfirmasikan simulasi antarmuka perangkat keras dan piranti lunak itu menggunakan melakukan test telah disahihkan.
3. Kebenaran Penelitian. Di mana jika analisa telah digunakan sebagai suatu pengganti untuk menguji, metoda analisa dan hasilnya harus disahihkan.
4. Kebenaran Konfigurasi. fungsional Dan Memerinci Dokumen Disain dan Uraian dokumen Versi akan ditinjau untuk memastikan bahwa konfigurasi piranti lunak yang mengaudit adalah sama ketika itu dibuktikan.
5. Status Disain Perubahan. Semua perubahan, seperti ketika didokumentasikan oleh Laporan Masalah Piranti lunak, harus ditinjau untuk memastikan bahwa mereka telah disatukan dan dibuktikan.

Audit Konfigurasi Phisik (Physical Configuration Audit (PCA))
PCA diselenggarakan sebelum penyerahan item. Itu terdiri dari dari suatu pengujian dokumentasi disain yang terperinci melawan terhadap "as-built" konfigurasi perangkat lunak. Itu diselenggarakan untuk memastikan ketercukupan, kelengkapan, dan ketelitian dokumentasi disain yang teknis. Tinjauan ulang juga meliputi suatu audit status perubahan yang sekarang, perubahan arsip, dan arsip uraian versi untuk memastikan bahwa "as-built" konfigurasi adalah kompatibel dengan dokumen yang dilepaskan. Tim PCA perlu meninjau ulang itemnya seperti yang diuraikan di bawah. Dan Dokumen yang perlu Arsip harus disajikan oleh organisasi pengembangan piranti lunak.

1. Dokumentasi Rancangan. Suatu audit disain dokumentasi harus dilakukan untuk memastikan bahwa mereka persisnya itu menghadirkan untuk dikirimkan konfigurasi. Dokumentasi Disain terdiri dari Disain Yang fungsional, Menghubungkan pengendalian, dan Dokumen Disain Rinci. Pengujian dokumen perlu memastikan yang berikut: korelasi modul mengalir ke tingkat yang tertinggi, masukan sesuai ke aliran, dan korelasi data alat penghubung ke ICDs. Pengujian perlu juga memastikan definisi data base yang cukup karakteritiknya, ketentuan alokasi penyimpanan, pemilihan waktu dan karakteristik peruntukan, dan yang perlu cross-checking mengalir ke listing program computer.
2. Dokumentasi Test. Dokumentasi Test untuk ditinjau terdiri dari Perencanaan Test, Prosedur Test. Dan Laporan perubahan Test. untuk Menguji Prosedur yang membuat pengujian harus ditinjau untuk menentukan kebenaran test yang dilakukan menggunakan prosedur yang berkembang itu. Test Data harus diuji untuk meyakinkan bahwa semua data yang di test diperlukan hadir dan yang bersertifikat oleh organisasi penjamin kualitas. Perencanaan Test ditinjau untuk memastikan bahwa semua perubahan disetujui untuk Test Perencana telah dicerminkan Prosedur Test.
3. Uraian Dokumen Versi. Uraian Dokumen Versi harus teraudit untuk memastikan kelengkapan uraian versi yang dikirimkan itu. Suatu daftar lengkap dokumen, angka-angka versi, dan subroutine identifiers memerlukan untuk membangun versi program komputer itu harus dimasukkan
4. Dokumen Instruksi Operasi. Dokumen Instruksi operasi harus bersertifikat untuk penggunaan operasional.
5. Pendukung Dokumentasi. Semua pendukung bisa menyampaikan/kirim dokumentasi harus ditinjau untuk memastikan kelengkapan mereka.
6. Perubahan Status. Daftar semua perubahan disain yang menyatukan dengan program komputer itu karena sejak start menguji harus ditinjau untuk memastikan kelengkapannya.
7. Konfigurasi Materi. Konfigurasi Paket Item harus ditinjau untuk menjamin bahwa semua tape, kartu, dokumen, daftar, dan seterusnya hadir dan memberi label dengan identifikasi dan tanda-tanda yang diperlukan.

8.4 PENGUJIAN PROSES DAFTAR (TESTING PROCESS CHECKLIST)
Daftar nama yang berikut menyediakan suatu ringkasan mengenai pokok-pokok informasi yang harus tersedia dokumentasi test. Informasi ini memastikan bahwa perangkat lunak yang terakhir ditemukan kebutuhan itu yang menyatakan Spesifikasi Persyaratan Piranti lunak dan disain yang diuraikan Dokumen Persyaratan Disain Rinci.

1. Uji filosofi dan metodologi pekerja dan mengubah test methode yang dipertimbangkan untuk mencapai penerimaan terhadap perangkat lunak itu.
2. Memerlukan Personil untuk mendukung program test itu, yang mencakup banyaknya orang-orang dan kecakapan mereka dalam kaitannya dengan pelatihan, keanggotaan organisatoris, dan pengalaman.
3. Fasilitas Komputer yang diperlukan, mencakup suatu blok diagram sebagai tempat test yang di atasnya perangkat lunak akan jadi diuji.
4. Uji perangkat lunak yang diperlukan untuk mendukung program test itu.
5. Uji jadual, mencakup penempatan, menguji konfigurasi, dan diagram arus test.
6. Korelasi dari semua perangkat lunak dan kebutuhan disain ke test individu.
7. Capaian, Alat penghubung, dan kebutuhan test atas mana rencana test didasarkan.
8. Uji rencana untuk gerbang keluar dari tiap modul perangkat lunak menulis, seperti halnya suatu test merencanakan untuk memverifikasi bahwa sistem menemukan kebutuhan sistem itu.
9. Uraian dari semua pengujian untuk dilakukan mencakup masukan, melakukan test, dan mengharapkan hasil. Hasil yang diharapkan diperlukan meliputi ukuran-ukuran penerimaan dan toleransi pengukuran itu.
10. Hasil percobaan diperoleh pada setiap perjanjian

Dokumentasi Pengujian ditinjau pada sebagian pada PDR, CDR, TPR dan SAR. Ketika meninjau ulang dokumentasi ini, tim tinjauan ulang perlu memastikan bahwa:

1. Perencana Test meliputi suatu test terintegrasi beredar dari sistem meratakan kepada test yang paling rendah mengukur.
2. Masing-Masing test memverifikasi sedikitnya satu kebutuhan dan masing-masing kebutuhan dibuktikan dalam suatu perjanjian
3. Semua test dapat terpenuhi dengan perangkat lunak test dan peralatan mengenali.
4. Test yang dilakukan adalah suatu urutan yang logis, sedemikian rupa sehingga penggunaan yang maksimum hasil awal percobaan dapat direalisir test kemudiannya.
5. Test memverifikasi kecocokan alat penghubung.
6. Tidak ada area di atas pengujian atau di bawah pengujian.
7. Semua sumber daya pendukung dikenali.
8. Tanggung-Jawab peserta test dikenali.
9. Uraian dari tiap test adalah cukup untuk test yang benar-benar dilakukan.
10. Ukuran-Ukuran untuk sukses atau kegagalan dari tiap test secara jelas dikenali.
11. Masukan Test Dan Keluaran dikenali dan terdaftar.
12. Pertimbangan cukup diberikan kepada penyimpanan data dan pengurangan data.
13. Jadual Test adalah kompatibel dengan disain yangberedar.
14. Hasil yang nyata dari tiap test didaftarkan dan dibandingkan dengan hasil yang diramalkan itu. Hasil percobaan menemukan ukuran-ukuran penerimaan itu.

Referensi

Bob Hughes and Mike Cotterell, 2002, Software Project Management, McGraw Hill, London.
Philip Bruce, Sam M. Pederson, 1982 The Software Development Project, John Wiley and Sons, New York.
Steve McConnell, 1996, Rapid Development Taming Wild Software Schedule, Microsoft Press, Washington.
Tumar, 2002, Information System Strategic, Universitas Bina Nusantara, Jakarta.