Sebuah tim pernah memberikan sistem pengeluaran yang lulus setiap tes teknis. Pada hari pertama, tim keuangan menemukan bahwa mereka tidak dapat menangani klaim multi-mata uang, yang merupakan bagian besar dari pekerjaan mereka. Tidak ada yang “rusak”, tapi tidak bisa digunakan. Uji penerimaan pengguna ada untuk menangkap kesenjangan semacam itu sebelum peluncuran.

Panduan ini mencakup perbedaan UAT dari pengujian lainnya, cara menjalankannya langkah demi langkah, dan cara memutuskan kapan Anda siap untuk merilisnya. Skenario di atas dan contoh di bawah hanya bersifat ilustratif, dan prosesnya harus disesuaikan dengan proyek Anda.

Apa itu UAT?

UAT biasanya merupakan tahap pengujian akhir sebelum rilis, di mana pengguna yang dituju mengonfirmasi bahwa perangkat lunak dapat melakukan tugasnya dalam kondisi realistis. Ini juga disebut pengujian pengguna akhir atau pengujian penerimaan. Itu terjadi setelah pengembangan dan pengujian sistem, ketika produk diharapkan stabil.

Tujuannya bukan untuk menemukan setiap bug. Pada tahap ini, sebagian besar sudah hilang. Tujuannya adalah validasi: apakah kita membangun hal yang benar? Penguji memverifikasi bahwa produk sesuai dengan spesifikasi. UAT memvalidasi bahwa spesifikasi dan produk benar-benar memenuhi kebutuhan.

pengujian UAT vs QA

UAT tidak menggantikan pengujian lainnya. Jika pengguna terus menemukan bug dasar, berarti build belum siap, dan Anda membuang-buang waktu mereka yang terbatas. Masalah tersebut termasuk dalam level pengujian sebelumnya dan pengujian regresi.

Siapa yang menjalankan UAT?

Pilih penguji yang benar-benar melakukan pekerjaannya hari ini. Penangan klaim yang berpengalaman akan menemukan masalah yang tidak akan pernah ditemukan oleh manajer atau kuasanya. Sertakan berbagai pengalaman, karena karyawan baru sering kali mengungkapkan langkah-langkah membingungkan yang dilakukan oleh seorang ahli tanpa menyadarinya. Dan pastikan manajer mereka meluangkan waktu untuk hal ini, karena UAT tidak dapat berhasil jika beban kerjanya penuh.

Jenis UAT

Proses UAT tujuh langkah

1. Tentukan ruang lingkup dan tujuan

Putuskan apa yang diterima, apa yang di luar cakupan, dan hasil bisnis apa yang penting. Misalnya: “Staf keuangan dapat mengajukan, menyetujui, dan membayar klaim pengeluaran, dalam mata uang apa pun yang didukung.”

2. Menyepakati kriteria penerimaan

Tuliskan dalam bahasa yang sederhana seperti apa kesuksesan itu, idealnya pada awal proyek, bukan pada minggu sebelum peluncuran. Kriteria yang tidak jelas akan menimbulkan perdebatan di kemudian hari.

3. Pilih dan beri pengarahan singkat pada penguji

Pilih pengguna sebenarnya, jelaskan tujuannya, tunjukkan kepada mereka cara mencatat umpan balik, dan jelaskan bahwa mereka sedang menguji perangkat lunak, bukan menguji diri mereka sendiri. Banyak orang khawatir akan terjadi kesalahan.

4. Mempersiapkan lingkungan dan data

Lingkungan UAT harus menyerupai produksi semaksimal mungkin. Gunakan data yang realistis, atur peran pengguna yang benar, dan periksa integrasi seperti email. Jika Anda menyalin data produksi, tutupi informasi pribadi terlebih dahulu. Jalankan tes asap dengan cepat, sehingga penguji tidak datang dan menemukan build yang rusak.

5. Tulis skenario

Dasarkan ini pada alur kerja nyata, bukan tombol individual. Mereka harus membaca seperti pekerjaannya, bukan seperti perangkat lunaknya. Panduan kami untuk kasus uji vs skenario pengujian menjelaskan seberapa banyak detail yang Anda perlukan.

6. Jalankan tes dan kumpulkan umpan balik

Jalankan sesi dengan seseorang yang siap membantu. Kumpulkan masalah di satu tempat, dengan tangkapan layar. Berikan juga waktu untuk eksplorasi gratis, karena orang-orang mencoba hal-hal yang tidak pernah diantisipasi oleh skrip. Pengujian eksplorasi menawarkan teknik yang berguna untuk ini.

7. Perbaiki, uji ulang, dan keluar

Lakukan triase terhadap masukan, perbaiki hal yang penting, dan mintalah pengguna yang sama untuk mengonfirmasi perbaikan tersebut. Kemudian catat keputusan formal.

Kasus uji UAT

Kasus uji UAT harus mudah diikuti oleh orang non-teknis. Berikut ini contoh sistem pengeluaran:

ID:        UAT-012
Scenario:  Submit a foreign currency expense claim
User role: Sales employee
Before:    Logged in, with a USD receipt ready

Steps:
  1. Create a new expense claim
  2. Enter a client dinner of 80 USD and attach the receipt
  3. Submit the claim for approval

Expected:  The amount is converted to INR at the current rate
           The manager receives an approval request
           The claim shows as "Awaiting approval"

Result:    Pass / Fail
Comments:
Tester / Date:

Perhatikan bahwa ini menggambarkan tugas nyata, bukan rincian teknis, dan memberikan ruang untuk komentar. Komentar tersebut seringkali menjadi bagian yang paling berharga, seperti “ini berfungsi, tetapi saya tidak akan pernah menemukan tombol itu”.

Kriteria masuk dan keluar

Hal ini sesuai dengan siklus hidup pengujian perangkat lunak yang lebih luas. Tetapkan angkanya dengan pemangku kepentingan Anda terlebih dahulu. “Kami akan memutuskan pada saat yang tepat” cenderung mengarah pada jawaban ya yang terburu-buru, didorong oleh tenggat waktu.

Menangani umpan balik

Umpan balik UAT adalah campuran dari berbagai hal, dan tidak semuanya merupakan bug. Urutkan ke dalam kategori:

Gunakan aturan yang jelas mengenai apa yang memblokir rilis, seperti yang dijelaskan dalam keparahan vs prioritas. Dan tanggapi setiap item, termasuk item yang Anda tolak. Orang-orang berhenti memberikan umpan balik jika umpan balik itu tampaknya hilang. Panduan kami tentang cara menulis laporan bug dapat membantu penguji menjelaskan masalah dengan jelas.

Daftar periksa UAT

Sebelum UAT

• Ruang lingkup dan kriteria penerimaan disetujui secara tertulis
• Pengujian sistem dan regresi telah selesai
• Penguji dipilih, diberi pengarahan dan diberi waktu
• Lingkungan, akun, dan data realistis sudah siap
• Data pribadi dalam salinan telah disamarkan
• Skenario ditinjau oleh bisnis
• Satu tempat untuk mencatat masalah telah disiapkan
• Pemilik sign-off disebutkan namanya

Selama UAT

• Kontak dukungan tersedia
• Masalah diprioritaskan setiap hari
• Kemajuan dibagikan kepada para pemangku kepentingan
• Perbaikan diterapkan dan diuji ulang dengan cara yang terkendali

Setelah UAT

• Kriteria keluar telah diperiksa
• Masalah yang diketahui didokumentasikan, dengan pemiliknya
• Penandatanganan formal dicatat
• Catatan pelatihan dan rilis diperbarui
• Retrospeksi singkat telah diadakan

UAT di tim Agile

UAT tradisional hadir sebagai satu fase besar di akhir, dimana kejutan itu mahal. Tim yang tangkas memperpendek putaran itu. Pemilik produk meninjau setiap cerita berdasarkan kriteria penerimaannya selama sprint, dan pengguna melihat perangkat lunak yang berfungsi pada tinjauan sprint. Banyak tim masih menjalankan UAT terfokus sebelum rilis besar, terutama ketika beberapa fitur digabungkan menjadi satu alur kerja.

Dengan seringnya rilis, teknik seperti penanda fitur dan penerapan canary memungkinkan pengguna sebenarnya mencoba pekerjaan baru secara bertahap. Perhatikan bahwa pengujian ini melengkapi pengujian penerimaan, namun tidak secara otomatis menggantikannya, terutama di industri yang diatur dan memerlukan catatan formal.

Kesalahan umum

• Memperlakukannya sebagai formalitas. Penandatanganan tanpa kegunaan nyata tidak akan melindungi siapa pun.
• Menggunakan penguji yang salah. Pengembang dan QA memiliki terlalu banyak pengetahuan tentang sistem untuk mewakili pengguna.
• Memulai dengan build yang tidak stabil. Penguji kehilangan kepercayaan dan minat dengan cepat.
• Membiarkannya hingga menit terakhir. Maka tidak ada waktu untuk memperbaiki apa yang Anda pelajari.
• Menggunakan data yang tidak realistis. Data pengujian jarang memiliki kasus berantakan seperti yang terjadi pada pekerjaan nyata.
• Membiarkan ruang lingkup berkembang. Perlakukan ide-ide baru sebagai permintaan perubahan, kecuali jika ide-ide tersebut benar-benar menghalangi.

Penutup

UAT adalah kesempatan terakhir Anda untuk mengetahui, sebelum dirilis, apakah perangkat lunak tersebut benar-benar membantu orang yang akan menggunakannya. Rencanakan dari awal proyek, rekrut pengguna sebenarnya, dan sepakati seperti apa kesuksesannya. Untuk rilis Anda berikutnya, cobalah satu perubahan sederhana: duduklah bersama satu pengguna selama skenario sebenarnya, dan jangan katakan apa pun saat mereka bekerja.

Pertanyaan yang sering diajukan

Teruslah belajar