Sebelumnya saya akan menjelaskan tujuan
dari tes penerimaan terhadap sistem yang dibuat, tes penerimaan bertujuan untuk
mendapatkan pernyataan tertulis dari user bahwa produk (dalam hal ini sistem)
yang dikirim sesuai dengan yang dijanjikan.
Sehingga dengan adanya tes terhadap sistem sangat penting karena dilihat dari
manfaat yang didapat, yaitu:
1.Dapat mendemonstrasikan semua fungsi yang dijanjikan.
2.Mengetahui tindakan yang menyebabkan masalah seperti, siapa yang mengetik
ketika masalah terjadi.
3.User tidak merasa takut tentang semuanya. Maka sangatlah penting untuk
melakukan tes penerimaan terhadap suatu sistem.
Yang perlu dicek pada kegiatan Rencana Penerimaan:
1.
PERIODE PERCOBAAN / 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.
2. 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.
3. 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.
4. MENGGUNAKAN DISAIN (USING THE DESIGN)
Disain membantu untuk menggelompokkan
tes ke dalam serangkaian tes yang mendemonstrasikan fungsi utama dari sistem.
5. MENULIS PERCOBAAN (WRITING TEST)
Anda sudah siap menentukan bagaimana
anda akan menguji item ketika pengisian pada metode percobaan.
6. DAFTAR RENCANA TES PENERIMAAN (THE ACCEPTANCE TEST PLAN CHECKLIST)
Daftar pengecekkan untuk semua kegiatan
yang diperlukan untuk rencana penerimaan:
-
Hasilkan Fungsi vs. Tabel Percobaan dan semua FS yang dijanjikan telah
dialamatkan.
-
Definiskan percobaan dan kumpulan percobaan.
-
Tetapkan tanggung jawab untuk menulis percobaan.
-
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.
-
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.
7. KESIMPULAN UNTUK RENCANA TES PENERIMAAN (CONCLUSION TO THE ACCEPTANCE
TEST PLAN)
Anda dapat melakukan tes penerimaan
secara berlebihan. Membandingkan biaya tes dengan biaya risiko itu adalah suatu
masalah. Anda dapat tidak melakukan semua percobaan, khususnya dalam sistem
multi-user yang interaktif.
8. KESIMPULAN UNTUK TAHAP DISAIN (CONCLUSION TO THE DESIGN PHASE)
Tahap disain menempuh beberapa kejadian
penting sebagai berikut :
-
Dokumen Spesifikasi Disain memuat disain akhir tingkat atas melalui disain
tingkat menengah.
-
Tanggung jawab ATP disahkan dan dimulai. Ini tidak perlu diselesaikan
sampai tahap penerimaan.
-
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%.
Jadi menurut saya dengan
adanya sistem ini kita dapat mendemonstrasikan semua fungsi yang di telah
janjikan sebelumnya, dan juga kita dapat mengetahui apakah user merasa puas
atau tidak dengan proyek yang telah kita buat. setelah melakukan hal tersebut
dan apabila user tidak user tidak lagi mengkomplain dengan hasil kinerja
kita, sehingga kita bisa mendapatkan tanda penerimaan dari user seperti
pembayaran yang telah disepakati sebelumnya atas hasil kinerja yang sudah
dikerjakan
