Rabu, 17 Agustus 2016

UAT ( User Acceptance Test )

Apakah yang dimaksud dengan UAT?
Pengujian Penerimaan Pengguna seringkali merupakan langkah terakhir sebelum meluncurkan aplikasi.
Biasanya pengguna akhir yang akan menggunakan aplikasi menguji aplikasi sebelum ‘menerima’ aplikasi.
Jenis pengujian ini memberikan pengguna akhir keyakinan bahwa aplikasi yang disampaikan kepada mereka memenuhi persyaratan mereka.
Tes ini juga membantu kuku bug yang berhubungan dengan kegunaan dari aplikasi.

Prasyarat UAT:
Sebelum Penerimaan Pengguna dapat dilakukan pengujian aplikasi sepenuhnya dikembangkan.
Berbagai tingkat pengujian (Unit, Integrasi dan System) sudah selesai sebelum Penerimaan Pengguna Pengujian dilakukan. Seperti berbagai tingkat pengujian telah selesai sebagian besar bug teknis sudah diperbaiki sebelum UAT.
Untuk apa UAT?

Untuk memastikan yang efektif Test UAT kasus diciptakan.
Tes ini kasus dapat dibuat menggunakan berbagai kasus menggunakan Persyaratan yang diidentifikasi selama tahap definisi.
Test kasus memastikan cakupan semua skenario selama pengujian.
Uji kasus yang ditulis menggunakan skenario dunia nyata untuk aplikasi 
Selama jenis pengujian fokus spesifik dunia nyata persis penggunaan aplikasi. Pengujian dilakukan di lingkungan yang mensimulasikan lingkungan produksi.


Bagaimana melakukan UAT ?

UAT biasanya merupakan kotak hitam jenis pengujian. Dengan kata lain, fokusnya adalah pada fungsi dan kegunaan aplikasi daripada aspek teknis. Secara umum diasumsikan bahwa aplikasi akan sudah mengalami Unit, Integrasi dan Pengujian Sistem Tingkat. Namun, ini berguna jika UAT dilakukan di lingkungan yang mirip dengan dunia nyata atau lingkungan produksi.
Langkah-langkah yang diambil untuk UAT biasanya melibatkan satu atau lebih dari berikut ini:

  1. User Acceptance Test (UAT) Perencanaan
  2. Merancang UA Uji Kasus
  3. Memilih Tim yang akan melaksanakan (UAT) Test Cases
  4. Pelaksana Uji Kasus
  5. Pengadministrasian yang Cacat ditemukan selama UAT
  6. Menyelesaikan masalah / Bug Fixing
  7. Sign Off
User Acceptance Test (UAT) Perencanaan
Seperti biasa Proses Perencanaan adalah yang paling penting dari semua langkah. Hal ini mempengaruhi efektivitas Proses Pengujian. Proses Perencanaan menguraikan Strategi Pengujian Penerimaan Pengguna. Ini juga menggambarkan bidang fokus utama, masuk dan keluar kriteria.

Merancang UA Uji Kasus
Uji Penerimaan Pengguna Kasus membantu Tim Pelaksanaan Tes untuk menguji aplikasi secara menyeluruh. Hal ini juga akan membantu memastikan bahwa UA Pengujian menyediakan cakupan yang cukup dari semua skenario.
Kasus Gunakan diciptakan selama fase definisi Persyaratan dapat digunakan sebagai masukan untuk membuat Test Kasus. Masukan dari Bisnis Analis dan Subject Matter Experts juga digunakan untuk membuat.


Setiap Kasus Uji Penerimaan Pengguna menggambarkan dalam bahasa yang sederhana langkah-langkah yang tepat yang akan diambil untuk menguji sesuatu.
Memilih Tim yang akan melaksanakan (UAT) Test Cases
Memilih Tim yang akan melaksanakan Test UAT Kasus ini merupakan langkah penting.
Tim yang UAT umumnya merupakan representasi yang baik dari dunia nyata pengguna akhir.
Dengan demikian Tim terdiri dari pengguna akhir yang sebenarnya yang akan menggunakan aplikasi ini.

Pelaksana Uji Kasus
Tim Pengujian mengeksekusi Uji Kasus dan mungkin tambahan acak melakukan Tes relevan untuk mereka

Pengadministrasian yang Cacat ditemukan selama UAT
Team log komentar mereka dan setiap cacat atau masalah yang ditemukan selama pengujian.

Menyelesaikan masalah / Bug Fixing
Masalah-masalah / cacat yang ditemukan selama Pengujian dibahas dengan Tim Proyek, Subject Matter Ahli dan Bisnis Analis. Masalah-masalah diselesaikan sesuai konsensus bersama dan untuk kepuasan pengguna akhir.

Sign Off
Setelah berhasil menyelesaikan Penerimaan Pengguna Pengujian dan penyelesaian masalah tim secara umum menunjukkan penerimaan aplikasi. Langkah ini penting dalam penjualan perangkat lunak komersial. Begitu Pengguna “Terima” Perangkat Lunak disampaikan mereka menunjukkan bahwa perangkat lunak memenuhi persyaratan mereka.
Sekarang yakin para pengguna perangkat lunak dan solusi yang disampaikan vendor akan dibayar untuk sama.
Macam-macam teknik dalam pengujian sistem.
Acceptance Test
Test yang dilakukan oleh user-user / pengguna terhadap sistem yang baru atau sistem yang telah diubah dengan tujuan memperoleh persetujuan terhadap sistem yang sedang di testing dan go live (siap dipakai). Dikenal juga sebagai UAT (User Acceptance Test)..


Active Test

Melakukan test data dan menganalisa hasilnya. Kebalikan dari "Passive Test" (liat dibawah).


Ad Hoc Test

Test non-formal tanpa Test Case (lihat bawah). 


Age Test (aging)

Mengevaluasi kemampuan sistem dalam melaksanakan tugas2nya di masa yang akan datang. Untuk melakukan test ini, hardware dan/atau data uji coba dimodifikasi ke tanggal yang akan datang


Alpha Test

Tahapan testing paling awal di sebuah laboratorium. Setelah itu, baru release Beta Testing.


Automated Test

Menggunakan software untuk menguji coba software (A Software Testing a Software).Walaupun begitu, testing ini masih memerlukan intervensi manusia untuk memonitor tahapan2/langkah2 dari analasis atau error yang ada. 


Beta Test

Test yang dilakukan oleh end users (pengguna akhir). Tahap testing yang dilakukan setelah Alpha Testing.


Black Box Test

Test terhadap software yang didasarkan atas hasil keluarannya saja (output) tanpa pengetahuan mendalam tentang kode-kode atau logika yang terdapat didalam software tersebut. Kebalikan dari "white box test" dan "gray box test."


Environment Test

Test sebuah software baru yang menentukan apakah semua transaksi antara input, output dan media penyimpanan berjalan sebagaimana mestinya.


Functional Test

Uji coba terhadap kebutuhan fungsional software, seperti menu dan kunci perintah (key commands).


Fuzz Test

Test terhadap software bugs dengan memberikan data yang dihasilkan secara acak.



Gray Box Test  

Uji coba software dengan adanya pengetahuan di kode / logika internal softwaretersebut. Kebalikan dari "white box test" dan "black box test."


Negative Test / Dirty Test

Menggunakan inputan yang salah/tidak sesuai untuk mengetes kemampuan error handling program.


Passive Test

Memonitor hasil dari sistem yang sedang berjalan tanpa melakukan tes data yang unik terhadap sistem. Kebalikan dari "active test" (diatas).


Recovery Test

Menguji kemampuan sistem untuk recover/pulih dari hardware atau software failure. Misalnya, gagal booting, overheat, overload data processing, transaksi putus karena koneksi down, dll. Apa yang akan terjadi?


Regression Test

Menguji coba software yang telah direvisi untuk melihat apakah fungsi-fungsi sebelumnya dapat berjalan dengan baik atau mengalami pengaruh.


Smoke Test

Menyalakannya dan melihat apa yang terjadi. (Testing untuk harware)

System Test

Testing keseluruhan di laboratorium dan di lingkungan pengguna (user environment).


Test Case

Sekumpulan data percobaan, program percobaan dan hasil tes yang diharapkan.


Test Scenario

Sekumpulan dari Test Case.


Test Suite

Kumpulan dari Test Case dan Tes Scenario yang telah dirangkum dengan detail.



Metode Pengembangan Perangkat Lunak Fourth Generation Techniques (4GT)

Istilahnya metode pengembangan perangkat lunak generasi keempat, mengarah ke perangkat lunak yang umum yaitu tiap pengembang perangkat lunak menentukan beberapa karakteristikperangkat lunak pada level tinggi.  Saat ini pengembangan perangkat lunak yang mendukung 4GT, berisi tool-tool berikut:

  1. Bahasa non prosedural untuk query basis data;
  2. Report generation;
  3. Data manipulation ;
  4. Interaksi layar ;
  5. Kemampuan grafik level tinggi 
  6. Kemampuan spreadsheet .
Tiap tool ini ada tapi hanya untuk sauatu aplikasi khusus. Metode pengembangan perangkat lunak 4GT menggunakan perangkat bantu (tools) yang akan membuat kode sumber secara otomatis berdasarkan spesifikasi dari pengembang perangkat lunak. Hanya digunakan untuk menggunakan perangkat lunak yang menggunakan bahasa khusus atau notasi grafik yang diselesaikan dengan syarat yang dimengerti pemakai. Cakupan aktivitas 4GT meliputi:


  1. Pengumpulan kebutuhan, idealnya pelanggan akan menjelaskan kebutuhan yang akan ditranslasikan ke prototype operasional.
  2. Translasi kebutuhan menjadi prototype operasional, atau langsung melakukan implementasi secara langsung dengan menggunakan bahasa generasi keempat (4GL) jika aplikasi relatif kecil.
  3. Untuk aplikasi yang cukup besar, dibutuhkan strategi perancangan sistem walaupun 4GL akan digunakan.
  4. Pengujian.
  5. Membuat dokumentasi
  6. Melaksanakan seluruh aktivitas untuk mengintegrasikan solusi-solusi yang membutuhkan paradigma rekayasa perangkat lunak lainnya.



Kelebihan dari metode pengembangan perangkat lunak ini diantaranya :

  1. Pengurangan waktu dan peningkatan produktivitas secara besar
  2. Karena 4GT menggunakan 4GL yang merupakan bahasa pemrograman yang  khusus dirancang dengan tujuan tertentu (spesifik), maka untuk permasalahan yang tertentu dengan 4GL tertentu pula sangat tepat menggunakan 4GT.
  3. Tool yang menggunakan metode pengembangan perangkat lunak 4GL bisa meng-generate sistem dari output yang dihasilkan oleh CASE tools.


Untuk aplikasi yang kecil, adalah mungkin untuk langsung berpindah dari pengumpulan kebutuhan ke implementasi dengan menggunakan metode 4GL. Tapi untuk aplikasi yang besar, dibutuhkan pengembangan strategi desain untuk sistem, walau digunakan 4GL. Penggunaan 4GL tanpa perencanaan yang matang (untuk proyek skala besar) akan meyebabkan kesulitan yang sama (kualitas dan pemeliharaan yang jelek, ketidakpuasan pelanggan) seperti dengan metode pengembangan perangkat lunak model konvensional.

Kekurangan metode pengembangan perangkat lunak ini:


  1. Penggunaan perangkat bantu (tools) dibandingkan dengan bahasa pemrograman, dan juga kode sumber yang dihasilkannya tidak efisien.
  2. Untuk usaha yang besar, dibutuhkan pengembangan strategi desain untuk sistem, walau digunakan bahasa 4GL.
  3. Penggunaan 4GT tanpa perencanaan matang (untuk proyek besar) akan menyebabkan kesulitan yang sama (kualitas dan pemeliharaan yang jelek, ketidakpuasan pelanggan) seperti dengan metode konvensional.
  4. 4GL tidak selalu berhasil menghasilkan sistem yang diinginkan.
Sekian dan terima kasih semoga bermanfaat bagi yang membaca..

    Tidak ada komentar:

    Posting Komentar