RENCANA TES PENERIMAAN SUATU SISTEM

1.       Menurut Anda seberapa penting dilakukan tes penerimaan terhadap sistem yang dibuat?

Jawab :

Sangat penting karena ketika suatu system baru yang telah di kerjakan selesai dan akan di serahkan kepada user ( pemesannya ) apakah sesuai dengan perjanjian yang telah disepakati. Karena kalau sudah di terima kepada user ( pemesannya ) dan terjadi kesalahan atau tidak sesuai permintaan yang akan terjadi akan hilang kepercayaan kepada selaku pembuat. Maka harus di lakukan tes penerimaan dengan demikian akan mengetahui apakah system yang telah di buat sesuai dengan permintaan atau tidak ada lagi kesalahan dan jika ada kesalahan atau tidak sesuai permintaan dapat di perbaiki.

2.       Apa saja yang perlu dicek pada kegiatan 'Rencana Penerimaan'?

Jawab :

 Tujuan dari penerimaan adalah mendapatkan pernyataan tertulis dari user bahwa produk (dalam hal ini sistem) yang dikirim sesuai dengan yang dijanjikan. Berikut langkah-langkah “Rencana Test Penerimaan” :

·         PERIODE PERCOBAAN ATAU PARALLEL RUN

(THE TRIAL PERIOD OR PARALLEL RUN)

 Periode percobaan atau parallel run adalah pendekatan yang paling umum untuk penerimaan. Menggunakan pendekatan „Periode Percobaan‟ tim proyek mudah memasang sistem baru untuk dicoba oleh user. Pendekatan ‘Parallel Run’ menambahkan dimensi untuk peralihan sistem lama yang sudah berjalan dengan baik sebagai perbandingan dan cadangan. Dalam kedua kasus ini klien menggunakan sistem baru selama „X‟ hari. Jika tidak ada masalah maka user menerimanya, jika ada masalah maka tim proyek berusaha memperbaikinya dan melakukan kembali percobaan selama „X‟ hari.

·        PENERIMAAN YANG LENGKAP SEDIKIT DEMI SEDIKIT

(SOLUTION : A THOROUGH BUT PIECEMEAL ACCEPTANCE)

Pendekatan yang lebih baik adalah menemukan serangkaian tes yang mendemonstrasikan semua fungsi yang dijanjikan. Penerimaan akan dilakukan secara resmi melalui seluruh tes ini kepada pelanggan. Keberhasilan tes diakhiri satu per satu. Jika sebuah tes gagal, Tim proyek dengan penuh harapan memperbaiki masalah langsung di tempat pengujian. Jika itu masalah utama maka tes ditunda sampai masalah dapat diperbaiki. Dalam teori hanya tes yang gagal yang diulang, walaupun user memiliki hak untuk menjalankan kembali tes yang diterimanya sesudah perbaikan.

Serangkaian tes dan perintah yang dijalankan sistem disebut Rencana Tes Penerimaan (Acceptance Test Plan / ATP).

·        MEMASTIKAN BAHWA SEMUA YANG DIJANJIKAN AKAN DIUJI

(ENSURING THAT ALL THE PROMISES ARE TESTED)

Untuk memastikan semua yang dijanjikan akan dites langsung melalui Spesifikasi Fungsi halaman demi halaman, paragraf demi paragraf, dan buat daftar semua fungsi yang dapat dites.

·         MENGGUNAKAN DESAIN (USING THE DESIGN)

Anda mungkin berfikir mengapa saya menyarankan mengerjakan ATP setelah disain dikerjakan. Sesungguhnya anda hanya memerlukan Spesifikasi Fungsi untuk menghasilkan ATP. Tetapi, disain membantu untuk menggelompokkan tes ke dalam serangkaian tes yang mendemonstrasikan fungsi utama dari sistem. Anda dapat menjalankan tes pada perintah atas bawah yang sama seperti TLD, yang dapat dimengerti dengan baik oleh user anda. Pendekatan sistem ABC seperti dalam TLD (gambar 7.1), anda dapat mendemonstrasikan semua menu, kemudian seluruh keterangan yang diminta, diikuti dengan semua update, dsb. Cara lain untuk mengelompokkan kumpulan tes adalah dengan fungsi. Melalui semua fungsi Registrasi, diikuti oleh fungsi Administrator, dsb

·         MENULIS PERCOBAAN (WRITING TEST)

Anda sudah siap menentukan bagaimana anda akan menguji item ketika pengisian pada METODE PERCOBAAN

·         DAFTAR RENCANA TES PENERIMAAN

(THE ACCEPTANCE TEST PLAN CHECKLIST)

Gunakan hal berikut sebagai daftar pengecekkan untuk semua kegiatan yang diperlukan untuk rencana penerimaan :

1.      Hasilkan Fungsi vs. Tabel Percobaan dan semua FS yang dijanjikan telah dialamatkan.

2.      Definiskan percobaan dan kumpulan percobaan.

3.      Tetapkan tanggung jawab untuk menulis percobaan.

4.      Klien dan Tim proyek mengetahui bahwa ATP akan ditinjau kembali, direvisi jika perlu, dan ditandatangani oleh user. Klien mengetahui bahwa keberhasilan penyelesaian dari percobaan akan mempengaruhi penerimaan sistem. Lihat bentuk contoh ATP pada bagian 10 di Appendix A.

5.      Tanggung jawab untuk percobaan data telah ditetapkan. Data untuk percobaan seharusnya disediakan oleh tim proyek dan juga user. Jika user dapat menyediakan data yang sesuai dengan keadaan yang sebenarnya, percobaan terhadap sistem akan berjalan dengan baik, ditambah user akan merasa nyaman dengan keakuratan percobaannya.

·        KESIMPULAN UNTUK RENCANA TES PENERIMAAN

(CONCLUSION TO THE ACCEPTANCE TEST PLAN)

Menganjurkan user untuk menulis ATP jika dia mampu. Hal ini akan memberikan dia perasaan mengawasi – tim proyek harus membangun sistem melalui percobaan.

·        KESIMPULAN UNTUK TAHAP DISAIN

(CONCLUSION TO THE DESIGN PHASE)

Pada akhir tahap disain kita menempuh beberapa kejadian penting sebagai berikut :

1. Dokumen Spesifikasi Disain memuat disain akhir tingkat atas melalui disain tingkat menengah.

2. Tanggung jawab ATP disahkan dan dimulai. Ini tidak perlu diselesaikan sampai tahap penerimaan.

3. Rencana proyek, khususnya perkiraan perlu ditinjau kembali. Walaupun anda sedang memperkirakan hanya 4 tahap yang telah disebutkan, tahap pemrograman mungkin akan menjadi tahap yang sangat mahal dan membutuhkan waktu yang sangat banyak dalam keseluruhan kerja proyek. Disain memberikan anda perkiraan perhitungan jumlah modul-modul dan kerumitannya. Sekarang anda mungkin tahu siapa programmer-programmer yang dapat diandalkan, sehingga anda dapat mempertimbangkan faktor produktivitas mereka. Dengan informasi ini waktu pemrograman yang diperlukan dapat dengan mudah diperkirakan (lihat BAB 13). Statistik menunjukkan bahwa pada akhir tahap disain diperkirakan seharusnya tidak lebih dari 10%.

Sumber : rudity.staff.gunadarma.ac.id/Downloads/.../bab+8.doc