# UAT Adalah: Pengertian, Jenis, Tahapan, dan Contohnya

> UAT adalah pengujian software oleh pengguna akhir sebelum rilis. Pahami arti, jenis, tahapan, beda SIT dan UAT, contoh skenario, dan isi dokumen UAT.

**URL:** https://www.ciptadusa.com/blog/uat-adalah  
**Type:** blog  
**Author:** PT Cipta Dua Saudara  
**Category:** Teknologi  
**Published:** 2026-10-19  
**Cover:** https://www.ciptadusa.com/media/uploads/blog/2026-10/1792376219376-uat-adalah-20261019.webp  

## Article

UAT adalah singkatan dari User Acceptance Testing, yaitu tahap pengujian software ketika pengguna akhir atau perwakilan bisnis mencoba aplikasi dalam skenario nyata untuk memastikan aplikasi itu memenuhi kebutuhan mereka sebelum dirilis. TechTarget menyebut UAT juga dikenal sebagai application testing atau end-user testing, dan menempatkannya di akhir proses pengujian, sebelum software dipakai di produksi ([sumber TechTarget](https://www.techtarget.com/it-infrastructure/definition/What-is-user-acceptance-testing-UAT)). Hasil akhirnya adalah keputusan: aplikasi diterima, atau masih perlu diperbaiki.

Artikel ini membahas pengertian UAT, tujuan dan pelaku UAT, posisinya dibanding SIT dan pengujian lain, jenis-jenis UAT, tahapan pelaksanaan, cara menulis kriteria penerimaan, contoh skenario dan dokumen UAT, serta tantangan yang perlu diantisipasi.

## Pengertian UAT (User Acceptance Testing)

Menurut TechTarget, UAT adalah fase pengembangan software saat software diuji di dunia nyata oleh audiens yang dituju. Tujuannya memastikan software sanggup menangani pekerjaan nyata dan bekerja sesuai spesifikasi pengembangan ([sumber](https://www.techtarget.com/it-infrastructure/definition/What-is-user-acceptance-testing-UAT)).

Silabus Acceptance Testing dari ISTQB, lembaga sertifikasi penguji software internasional, menyebut UAT sebagai salah satu bentuk acceptance testing, bersama contractual and regulatory acceptance testing serta alpha dan beta testing ([sumber ISTQB, PDF](https://istqb.org/wp-content/uploads/2024/11/ISTQB-CT-AcT_Syllabus_v1.0_2019.pdf)).

Perbedaan UAT dengan pengujian lain ada pada pertanyaan yang dijawab:

- **Pengujian teknis** (unit test, integration test, system test) menjawab apakah software dibangun dengan benar sesuai spesifikasi.
- **UAT** menjawab apakah software itu benar-benar bisa dipakai pengguna untuk menyelesaikan pekerjaannya.

TechTarget menjelaskan bahwa software bisa saja lolos semua fase pengujian dan berfungsi penuh, tetapi tetap tidak memenuhi kebutuhan jika tidak diterima oleh penggunanya. Penyebabnya antara lain kebutuhan yang tidak didefinisikan dengan jelas ke developer, perubahan cakupan selama pengembangan, atau software yang belum siap diuji di lingkungan nyata ([sumber](https://www.techtarget.com/it-infrastructure/definition/What-is-user-acceptance-testing-UAT)).

## Tujuan UAT

Berdasarkan uraian TechTarget, UAT punya beberapa tujuan ([sumber](https://www.techtarget.com/it-infrastructure/definition/What-is-user-acceptance-testing-UAT)):

- **Memvalidasi kebutuhan bisnis.** Jika berhasil, UAT membuktikan bahwa software memenuhi kebutuhan bisnis yang ditetapkan.
- **Menemukan masalah yang lolos dari pengujian sebelumnya.** Pengguna mencoba fitur dengan kasus dan data nyata, sehingga fitur yang terlewat atau bug yang belum terdeteksi bisa muncul.
- **Mencegah rilis software yang keliru, tidak efektif, atau belum selesai.** Tanpa UAT, software berisiko dirilis dengan bug atau tanpa tujuan yang jelas bagi pengguna akhir.
- **Meningkatkan transparansi dengan pengguna.** Pengguna melihat dan mencoba produk sebelum rilis resmi.

Untuk proyek software yang dibuat oleh vendor, UAT juga menjadi titik serah terima. TechTarget menulis bahwa setelah pengujian QA, organisasi pengembang menyerahkan produk ke klien, lalu penguji dari pihak klien menjalankan skenario nyata dan memberi sign-off ketika produk memenuhi kebutuhan mereka ([sumber](https://www.techtarget.com/it-infrastructure/answer/Quality-assurance-testing-vs-user-acceptance-testing)).

## Siapa yang Melakukan UAT?

UAT dilakukan oleh pengguna akhir, karena merekalah yang tahu persis bagaimana software akan dipakai sehari-hari dan perubahan apa yang dibutuhkan agar cocok untuk pemakaian harian. Ahli fungsional internal juga berperan membentuk siklus UAT, mengelola pengujian, dan menafsirkan hasilnya ([sumber TechTarget](https://www.techtarget.com/it-infrastructure/definition/What-is-user-acceptance-testing-UAT)).

Dalam praktik proyek, peran yang terlibat dapat dirinci seperti ini (gambaran pembagian peran, bukan standar baku):

- **Pengguna kunci dari tiap divisi**, misalnya admin penjualan, staf gudang, atau tim keuangan, yang menjalankan skenario uji.
- **Product owner atau pemilik proses bisnis** yang menetapkan kriteria penerimaan dan memberi keputusan akhir.
- **Business analyst atau QA** yang menyiapkan skenario, data uji, dan mencatat temuan.
- **Tim developer** yang memperbaiki temuan lalu menyiapkan versi untuk diuji ulang.

ISTQB menekankan bahwa merancang acceptance test dari kriteria penerimaan sebaiknya menjadi kerja kolaboratif antara business analyst dan tester, agar fase acceptance testing benar-benar bernilai bagi bisnis dan menekan risiko saat produk dirilis ([sumber ISTQB, PDF](https://istqb.org/wp-content/uploads/2024/11/ISTQB-CT-AcT_Syllabus_v1.0_2019.pdf)).

## Posisi UAT dalam Tahapan Pengujian Software

TechTarget menempatkan UAT setelah unit testing, quality assurance, system testing, dan integration testing ([sumber](https://www.techtarget.com/it-infrastructure/definition/What-is-user-acceptance-testing-UAT)). Dalam siklus pengembangan software, pengujian ini berada di tahap testing sebelum deployment. Gambaran lengkap tahapannya ada di artikel [SDLC adalah](https://www.ciptadusa.com/blog/sdlc-adalah).

### Perbedaan SIT dan UAT

SIT (System Integration Testing) dan UAT sama-sama berlangsung menjelang rilis, tetapi tujuan dan pelakunya berbeda. Menurut TechTarget, SIT menguji apakah seluruh komponen software dan hardware bekerja sesuai harapan sebagai satu sistem utuh, dan dijalankan oleh tim QA, bukan pengguna. Fase SIT berlangsung sebelum UAT ([sumber TechTarget](https://www.techtarget.com/it-infrastructure/answer/What-is-the-difference-between-SIT-and-UAT)).

| Aspek | SIT | UAT |
| --- | --- | --- |
| Pertanyaan utama | Apakah semua komponen terhubung dan berfungsi sebagai satu sistem? | Apakah sistem bisa dipakai untuk pekerjaan nyata pengguna? |
| Pelaku | Tim QA atau tester | Pengguna akhir dan perwakilan bisnis |
| Fokus | Alur data dan interaksi antarkomponen | Proses bisnis dan kebutuhan pengguna |
| Waktu | Sebelum UAT | Setelah SIT, menjelang rilis |
| Hasil | Daftar defect teknis | Temuan dan keputusan diterima atau belum |

Sumber tabel: diringkas dari [TechTarget](https://www.techtarget.com/it-infrastructure/answer/What-is-the-difference-between-SIT-and-UAT) dan [TechTarget](https://www.techtarget.com/it-infrastructure/definition/What-is-user-acceptance-testing-UAT).

TechTarget juga mencatat bahwa tidak ada standar industri yang baku untuk UAT maupun SIT, sehingga pelaksanaannya bervariasi antarproyek ([sumber](https://www.techtarget.com/it-infrastructure/answer/What-is-the-difference-between-SIT-and-UAT)). Karena itu, cakupan dan kriteria UAT perlu disepakati sejak awal proyek.

## Jenis-Jenis UAT

TechTarget menggolongkan beberapa jenis pengujian sebagai bagian dari UAT ([sumber](https://www.techtarget.com/it-infrastructure/definition/What-is-user-acceptance-testing-UAT), [sumber](https://www.techtarget.com/it-infrastructure/answer/What-is-the-difference-between-SIT-and-UAT)):

### 1. Alpha Testing dan Beta Testing

Alpha testing dilakukan pengguna atau kelompok pengguna di awal siklus untuk menemukan bug selama pengembangan. Beta testing dilakukan setelahnya, dengan merilis produk ke lingkungan pelanggan untuk mengumpulkan umpan balik lebih luas.

ISTQB mengaitkan beta testing dengan produk siap pakai (COTS) dan platform SaaS. Pengujian ini dijalankan oleh calon pengguna atau pengguna yang sudah ada di lokasi mereka sendiri. ISTQB juga mengingatkan bahwa acceptance testing sebaiknya tidak hanya mengandalkan beta testing, karena beta testing tidak sistematis, tidak terukur, dan tidak menjamin semua kebutuhan tercakup ([sumber ISTQB, PDF](https://istqb.org/wp-content/uploads/2024/11/ISTQB-CT-AcT_Syllabus_v1.0_2019.pdf)). Penjelasan soal model SaaS ada di artikel [SaaS adalah](https://www.ciptadusa.com/blog/saas-adalah).

### 2. Black Box Testing

Pengguna menguji fungsi tertentu tanpa melihat kode di dalamnya. Penilaian dibuat hanya dari interaksi dengan produk.

### 3. Contract Acceptance Testing

Software diuji berdasarkan kriteria dan spesifikasi yang tertulis di kontrak antara vendor dan klien. Jenis ini relevan untuk proyek [pengembangan software custom](https://www.ciptadusa.com/services/software) yang dikerjakan pihak ketiga.

### 4. Regulation Acceptance Testing

Disebut juga compliance acceptance testing. Pengujian ini memastikan software memenuhi aturan hukum atau kebutuhan kepatuhan pengguna.

### 5. Operational Acceptance Testing (OAT)

Fokusnya kesiapan operasional, seperti kompatibilitas, keandalan, dan stabilitas. Organisasi klien juga menilai kesiapannya memakai software, misalnya pelatihan karyawan, pemeliharaan software, dan cara menangani kegagalan. Topik pemeliharaan setelah rilis dibahas di artikel [biaya maintenance aplikasi](https://www.ciptadusa.com/blog/biaya-maintenance-aplikasi).

## Tahapan UAT

Jumlah langkah UAT bisa berbeda tergantung seberapa rinci tim mendefinisikannya. TechTarget merangkum tahapannya menjadi lima langkah ([sumber](https://www.techtarget.com/it-infrastructure/definition/What-is-user-acceptance-testing-UAT)):

1. **Perencanaan.** Tetapkan kebutuhan bisnis yang diuji, jadwal, dan strategi UAT.
2. **Menyusun skenario uji nyata.** Skenario dibuat untuk mencakup sebanyak mungkin kasus fungsional yang akan dihadapi pengguna.
3. **Memilih tim penguji.** Penguji perlu memahami bisnis dan tahu cara menemukan serta melaporkan masalah.
4. **Menguji dan mendokumentasikan.** Pengguna menjalankan pengujian dan mencatat bug di bug tracker, lengkap dengan cara mereproduksinya.
5. **Memperbaiki, menguji ulang, lalu sign-off.** Developer memperbaiki temuan, pengujian diulang, dan penguji memberi persetujuan ketika software memenuhi kriteria pengguna. Setelah itu software siap dirilis ke produksi.

Di proyek kontrak, persetujuan di langkah kelima dapat dituangkan dalam dokumen tertulis yang disepakati kedua pihak, sehingga jelas versi mana yang diterima dan temuan mana yang ditunda ke fase berikutnya.

## Cara Menulis Kriteria Penerimaan (Acceptance Criteria)

UAT yang baik berangkat dari kriteria penerimaan yang jelas. ISTQB mendefinisikan kriteria penerimaan sebagai pernyataan terukur yang bisa bernilai benar atau salah, dipakai untuk memeriksa apakah sebuah kebutuhan atau user story sudah diimplementasikan sesuai harapan. Kriteria ini menentukan apa yang diuji, sedangkan test case menjelaskan bagaimana pengujiannya dilakukan ([sumber ISTQB, PDF](https://istqb.org/wp-content/uploads/2024/11/ISTQB-CT-AcT_Syllabus_v1.0_2019.pdf)).

Ciri kriteria penerimaan yang baik menurut ISTQB:

- Tepat, terukur, dan ringkas, sehingga penguji bisa menilai lulus atau tidak.
- Tidak memuat detail solusi teknis, dan fokus pada apa yang harus dicapai.
- Mencakup kebutuhan fungsional maupun non-fungsional.

Atlassian menambahkan bahwa kriteria penerimaan sebaiknya ditetapkan sebelum pengembangan dimulai, dan disusun bersama product owner, tim developer, serta pemangku kepentingan lain ([sumber Atlassian](https://www.atlassian.com/work-management/project-management/acceptance-criteria)).

### Format Given-When-Then

ISTQB menjelaskan pola Given-When-Then untuk menulis test case dalam bahasa terstruktur yang bisa dipahami semua pihak ([sumber ISTQB, PDF](https://istqb.org/wp-content/uploads/2024/11/ISTQB-CT-AcT_Syllabus_v1.0_2019.pdf)):

- **Given:** kondisi awal sebelum pengujian.
- **When:** tindakan pengguna terhadap sistem.
- **Then:** hasil yang bisa diamati setelah tindakan itu.

Contoh penulisan (ilustrasi): Given seorang sales sudah login dan memiliki satu prospek berstatus "Baru", When ia mengubah status prospek menjadi "Negosiasi", Then status baru tampil di daftar prospek dan tercatat di riwayat aktivitas.

## Contoh UAT: Skenario untuk Aplikasi CRM

Berikut contoh skenario UAT untuk modul prospek di aplikasi CRM. Contoh ini ilustrasi untuk menunjukkan format, bukan hasil pengujian proyek nyata. Pengertian CRM dan modul-modulnya dibahas di artikel [CRM adalah](https://www.ciptadusa.com/blog/crm-adalah).

| ID | Skenario | Langkah | Hasil yang diharapkan | Status |
| --- | --- | --- | --- | --- |
| UAT-01 | Menambah prospek baru | Buka menu Prospek, isi nama, nomor telepon, sumber, lalu simpan | Prospek tersimpan dan tampil di daftar dengan status "Baru" | Lulus / Gagal |
| UAT-02 | Validasi data wajib | Simpan prospek tanpa nomor telepon | Sistem menolak dan menampilkan pesan bahwa nomor telepon wajib diisi | Lulus / Gagal |
| UAT-03 | Mengubah tahap prospek | Pindahkan prospek dari "Baru" ke "Negosiasi" | Tahap berubah dan tercatat di riwayat aktivitas | Lulus / Gagal |
| UAT-04 | Hak akses | Login sebagai sales A, cari prospek milik sales B | Sesuai aturan akses yang disepakati, misalnya prospek sales B tidak terlihat | Lulus / Gagal |
| UAT-05 | Laporan | Buka laporan pipeline bulan berjalan | Jumlah prospek per tahap sesuai data yang diinput selama pengujian | Lulus / Gagal |

Skenario seperti ini sebaiknya ditulis dengan bahasa proses bisnis, bukan bahasa teknis, karena yang menjalankannya adalah pengguna. Untuk sistem yang lebih luas seperti [ERP](https://www.ciptadusa.com/blog/erp-adalah), skenario dapat disusun per proses, misalnya dari pesanan penjualan sampai faktur.

## Isi Dokumen UAT

Tidak ada format tunggal untuk dokumen UAT. Berdasarkan tahapan dan praktik yang diuraikan TechTarget ([sumber](https://www.techtarget.com/it-infrastructure/definition/What-is-user-acceptance-testing-UAT)), dokumen UAT dapat memuat komponen berikut (contoh susunan, sesuaikan dengan proyek):

- **Rencana UAT:** tujuan, cakupan proses yang diuji, jadwal, peserta, dan lingkungan pengujian.
- **Kriteria penerimaan:** daftar syarat yang harus terpenuhi agar aplikasi diterima.
- **Skenario dan test case:** langkah, data uji, kondisi, dan hasil yang diharapkan.
- **Log temuan:** bug atau masukan, lengkap dengan langkah reproduksi, tingkat prioritas, dan status perbaikan.
- **Hasil uji ulang:** catatan bahwa temuan sudah diperbaiki dan diuji kembali.
- **Lembar persetujuan (sign-off):** pernyataan bahwa aplikasi memenuhi kebutuhan bisnis, ditandatangani pihak yang berwenang.

## Tantangan UAT dan Cara Mengantisipasinya

TechTarget mencatat empat tantangan dalam UAT ([sumber](https://www.techtarget.com/it-infrastructure/definition/What-is-user-acceptance-testing-UAT)):

- **Perencanaan pengujian yang lemah.** Karena UAT berada di akhir siklus, keterlambatan di tahap sebelumnya membuat waktu UAT tertekan. Alokasikan waktu UAT sejak menyusun jadwal proyek.
- **Penguji yang tidak tepat.** Penguji yang tidak dilatih bisa tidak tahu cara melaporkan bug, sehingga tim sulit mereproduksi masalah. Latih penguji sebelum UAT dimulai.
- **Lingkungan pengujian.** Memakai lingkungan yang sama dengan functional dan system testing bisa menyembunyikan ketergantungan pada lingkungan tersebut. Gunakan lingkungan terpisah untuk UAT.
- **Celah komunikasi.** Komunikasi yang buruk antara penguji UAT dan tim pengujian menyebabkan keterlambatan pelaporan. Sepakati kanal pelaporan dan jadwal review temuan.

Satu hal lagi yang perlu diperhatikan: temuan UAT bisa berupa permintaan fitur baru, bukan bug. Pisahkan keduanya di log temuan agar cakupan proyek dan biayanya tetap terkendali. Komponen biaya proyek aplikasi dibahas di artikel [biaya pembuatan aplikasi berbasis web](https://www.ciptadusa.com/blog/biaya-pembuatan-aplikasi-berbasis-web). Jika Anda sedang membangun versi awal produk, baca juga [MVP adalah](https://www.ciptadusa.com/blog/mvp-adalah).

## FAQ

### UAT adalah singkatan dari apa?

UAT adalah singkatan dari User Acceptance Testing, yaitu pengujian oleh pengguna akhir untuk memastikan software memenuhi kebutuhan nyata sebelum dirilis ([sumber](https://www.techtarget.com/it-infrastructure/definition/What-is-user-acceptance-testing-UAT)).

### Apa bedanya SIT dan UAT?

SIT dijalankan tim QA untuk memastikan semua komponen bekerja sebagai satu sistem, sedangkan UAT dijalankan pengguna untuk memastikan sistem cocok dengan kebutuhan bisnis. SIT berlangsung sebelum UAT ([sumber](https://www.techtarget.com/it-infrastructure/answer/What-is-the-difference-between-SIT-and-UAT)).

### Siapa yang melakukan UAT?

Pengguna akhir, dibantu ahli fungsional internal yang menyusun siklus UAT dan menafsirkan hasilnya ([sumber](https://www.techtarget.com/it-infrastructure/definition/What-is-user-acceptance-testing-UAT)).

### Apa saja jenis UAT?

Jenis yang disebut TechTarget antara lain alpha dan beta testing, black box testing, contract acceptance testing, regulation acceptance testing, dan operational acceptance testing ([sumber](https://www.techtarget.com/it-infrastructure/answer/What-is-the-difference-between-SIT-and-UAT)).

### Apa isi dokumen UAT?

Rencana UAT, kriteria penerimaan, skenario dan test case, log temuan, hasil uji ulang, dan lembar persetujuan. Susunannya dapat disesuaikan dengan kebutuhan proyek.

### Apa yang terjadi setelah UAT selesai?

Jika kriteria penerimaan terpenuhi dan temuan sudah diperbaiki, penguji memberi sign-off dan software siap dirilis ke produksi ([sumber](https://www.techtarget.com/it-infrastructure/definition/What-is-user-acceptance-testing-UAT)). Setelah rilis, aplikasi masuk fase pemeliharaan.

## Jalankan Proyek Software dengan UAT yang Terencana Bersama CDS

PT Cipta Dua Saudara membantu bisnis menyusun kebutuhan dan kriteria penerimaan lewat [konsultasi IT](https://www.ciptadusa.com/services/consulting), lalu membangun aplikasi web dan mobile lewat [pengembangan software custom](https://www.ciptadusa.com/services/software) dengan UAT sebagai bagian dari proses serah terima. Kami juga mengembangkan produk sendiri seperti [Zetta CRM](https://www.ciptadusa.com/incubating/zetta-crm). Lihat [portofolio kami](https://www.ciptadusa.com/works), atau baca [panduan memilih jasa pembuatan software di Jawa Barat](https://www.ciptadusa.com/blog/pilih-jasa-pembuatan-software-jawa-barat-20260907) dan [kapan bisnis butuh software custom](https://www.ciptadusa.com/blog/kapan-bisnis-butuh-software-custom-2026) sebelum memulai proyek.


---

*Markdown version of https://www.ciptadusa.com/blog/uat-adalah — generated for AI agents and LLM crawlers.*
