Kualitas Perangkat Lunak & Pengujian

5.1 Ringkasan & Tujuan

Bab ini menetapkan kerangka Software Quality & Testing (SQT) yang mengatur bagaimana Provider memastikan kebenaran fungsional, integritas performa, dan keandalan data ProjectVIEW ERP sebelum setiap deployment ke lingkungan Production Customer.

Tidak ada Release, Update, atau Upgrade (sebagaimana didefinisikan dalam Chapter 1, §1.4) yang boleh dipromosikan ke Production tanpa berhasil menyelesaikan siklus pengujian yang dijelaskan di sini.

Provider menjalankan metodologi pengujian yang terdiferensiasi dan ditingkatkan AI yang memanfaatkan AI Testing Agents khusus yang dibangun di atas framework pengujian proprietari milik Provider untuk berinteraksi langsung dengan instance ProjectVIEW ERP milik masing-masing Customer. Pendekatan ini memungkinkan simulasi otomatis atas aliran data end-to-end, skenario interaksi pengguna yang realistis, dan validasi integritas data yang komprehensif, kapabilitas yang jauh melampaui QA manual atau berbasis skrip konvensional.

Selain pencegahan cacat, kerangka SQT juga mencakup layanan Process Optimisation Advisory yang proaktif, di mana output AI-agent dianalisis untuk mengidentifikasi inefisiensi workflow, anomali konfigurasi, dan peluang perbaikan model data dalam setiap deployment Customer. Wawasan ini disampaikan sebagai rekomendasi yang dapat ditindaklanjuti pada Quarterly Service Review (§3.9).

5.2 Ruang Lingkup

Kerangka SQT berlaku untuk seluruh artefak perangkat lunak yang di-deploy ke lingkungan Customer berdasarkan Framework ini, termasuk namun tidak terbatas pada:

• (a) Rilis/Pembaruan (v11.xx) — perubahan inkremental spesifik klien yang disampaikan melalui sprint Agile 3 hari (§4.7).
• (b) Upgrade (v11 → v12) — perubahan produk berskala besar di seluruh produk yang disampaikan kira-kira setiap tahun (§4.8).
• (c) Perubahan konfigurasi — aktivasi modul, kustomisasi alur kerja, template laporan, penyesuaian peran dan izin.
• (d) Artefak migrasi data — transformasi impor, skrip ETL, patch migrasi skema.
• (e) Antarmuka integrasi — endpoint API, handler webhook, adaptor konektor pihak ketiga.
• (f) Perubahan infrastruktur — pembaruan mesin basis data, upgrade versi middleware, rotasi sertifikat TLS.

Kerangka SQT mencakup pengujian internal Provider (§5.4–§5.7) yang dilakukan sebelum UAT Customer, serta Pengujian Penerimaan Pengguna Universal milik Customer (§5.8) yang berfungsi sebagai gerbang formal kesiapan produksi.

5.3 Kerangka Pengujian Berbantuan AI

5.3.1 Gambaran Arsitektur

Provider menggunakan platform pengujian berbasis AI yang dirancang khusus dan terdiri dari tiga lapisan inti:

5.3.2 Agen Pengujian AI

Setiap instance ProjectVIEW ERP milik Customer dipasangkan dengan satu atau lebih Agen Pengujian AI khusus, yang dikonfigurasi dengan pengetahuan spesifik domain tentang:

• Konfigurasi Modul: Modul yang diaktifkan (misalnya, Project-Management, Contract-Management, Quality-Management) dan saling ketergantungannya.
• Aturan Bisnis: Alur persetujuan, matriks eskalasi, aturan notifikasi, dan rumus perhitungan yang spesifik terhadap kebutuhan operasional Customer.
• Skema Data: Field kustom, tabel lookup, domain nilai berkode, dan batasan integritas relasional yang dikonfigurasi dalam instance Customer.
• Taksonomi Peran: Peran pengguna, set izin, dan aturan pemisahan tugas yang berlaku bagi organisasi Customer.
• Peta Integrasi: Sistem pihak ketiga yang terhubung (akuntansi, HR, manajemen dokumen, BI) dan kontrak pertukaran datanya.

Agen AI dikendalikan versinya bersama codebase aplikasi menggunakan strategi branching Git milik Provider (Master → Client → Working branches, §4.7.2) sehingga konfigurasi pengujian berkembang seiring dengan perangkat lunak yang divalidasinya.

5.3.3 Integrasi API Aman

Lapisan integrasi API aman menyediakan lapisan komunikasi terstruktur antara Agen Pengujian AI dan ProjectVIEW ERP, yang memungkinkan:

• (a) Pemanggilan API: Agen memanggil API REST/GraphQL ProjectVIEW untuk membuat, membaca, memperbarui, dan menghapus record, meniru transaksi pengguna nyata tanpa ketergantungan pada UI.
• (b) Inspeksi Basis Data: Akses baca-saja ke basis data Dev/Sandbox Customer untuk memvalidasi batasan integritas data, konsistensi referensial, dan field terhitung setelah transaksi.
• (c) UI Automation Hooks: Ketika logika bisnis terikat erat dengan front-end (misalnya, visibilitas field kondisional, validasi formulir dinamis), lapisan integrasi mengarahkan instruksi agen melalui antarmuka browser headless yang merender UI ProjectVIEW secara akurat.
• (d) Perekaman Peristiwa: Semua interaksi agen-ERP dicatat ke jejak audit yang tidak dapat diubah, termasuk payload permintaan, kode respons, metrik waktu, dan hasil asersi.

Koneksi API diautentikasi menggunakan token API berumur pendek dan terbatas cakupan yang hanya memberikan izin yang diperlukan untuk rangkaian pengujian saat itu. Token diputar secara otomatis per sesi pengujian dan tidak dapat digunakan terhadap lingkungan Production.

5.4 Metodologi Pengujian

5.4.1 Tingkat Pengujian

Siklus pengujian Provider mencakup lima tingkat progresif, masing-masing dengan kriteria masuk, kriteria keluar, dan akuntabilitas yang ditetapkan:

5.4.2 Lingkungan Pengujian

Seluruh pengujian sisi Provider (L1–L4) dijalankan secara eksklusif di lingkungan Dev/Sandbox khusus milik Customer (§2.5.1). Lingkungan ini:

• Identik secara arsitektural dengan Production — versi mesin basis data, stack middleware, dan build aplikasi yang sama.
• Diisi dengan data setara produksi yang dianonimkan — volume dan variasi cukup untuk menguji kasus tepi yang realistis tanpa mengekspos data pribadi.
• Terisolasi — tidak ada konektivitas jaringan ke Production; namespace DNS dan realm autentikasi terpisah.
• Dapat di-reset — kemampuan snapshot/restore memungkinkan pengulangan run pengujian dari baseline yang diketahui baik.

Setelah Go-Live, lingkungan Dev/Sandbox beralih menjadi peran Staging (§2.5.1), mempertahankan seluruh properti di atas sekaligus juga berfungsi sebagai lingkungan UAT bagi Customer.

5.5 Simulasi Aliran Data End-to-End

5.5.1 Tujuan Simulasi

Agen AI mensimulasikan aliran data realistis end-to-end yang melintasi seluruh siklus hidup transaksi bisnis di ProjectVIEW ERP. Tujuannya adalah:

• (a) Memvalidasi bahwa data yang dibuat dalam satu modul dipropagasikan, ditransformasikan, dan tersedia dengan benar di semua modul hilir.
• (b) Mengonfirmasi bahwa aturan bisnis (rantai persetujuan, notifikasi, perhitungan) berjalan dengan benar di setiap tahap.
• (c) Memverifikasi bahwa tindakan pengguna serentak tidak menyebabkan race condition, deadlock, atau kerusakan data.
• (d) Mengukur latensi dan throughput transaksi terhadap ambang SLO yang ditetapkan (§3.3).

5.5.2 Skenario Simulasi

Provider memelihara pustaka skenario simulasi yang diparameterkan, masing-masing dipetakan ke proses bisnis inti ProjectVIEW. Tabel berikut mengilustrasikan skenario representatif — seluruh pustaka disesuaikan per Customer berdasarkan modul yang diaktifkan dan konfigurasinya:

5.5.3 Penanaman Data & Eksekusi Skenario

Sebelum setiap run simulasi, agen AI secara otonom:

• (a) Menanam data prasyarat: Membuat record master (proyek, vendor, pengguna, kode biaya) yang diperlukan sebagai input untuk skenario yang diuji.
• (b) Menjalankan rantai transaksi: Memanggil API ProjectVIEW melalui lapisan integrasi API aman untuk melakukan setiap langkah proses bisnis dalam urutan yang benar, dengan nilai data dan interval waktu yang realistis.
• (c) Melakukan asersi pada setiap checkpoint: Setelah setiap langkah, agen mengkueri basis data dan/atau API untuk memastikan bahwa perubahan status yang diharapkan telah terjadi (record dibuat/diperbarui, alur kerja maju, notifikasi dikirim).
• (d) Menangkap bukti: Setiap panggilan API, kueri basis data, hasil asersi, dan pengukuran waktu dicatat ke repositori bukti pengujian yang tidak dapat diubah dan tertaut ke tiket deployment.
• (e) Membersihkan: Setelah selesai, agen mengembalikan lingkungan ke baseline menggunakan kemampuan snapshot/restore, memastikan tidak ada artefak pengujian yang mencemari run berikutnya.

5.6 Simulasi Interaksi Pengguna

5.6.1 Tujuan

Sementara pengujian di tingkat API (§5.5) memvalidasi logika backend, Simulasi Interaksi Pengguna memvalidasi bahwa antarmuka pengguna ProjectVIEW berperilaku dengan benar saat dioperasikan oleh pengguna manusia. Agen AI mereplikasi interaksi pengguna yang realistis termasuk:

• Pengisian formulir dengan data valid, tidak valid, dan nilai batas.
  • Navigasi melalui alur kerja multi-langkah (wizard, rantai persetujuan, urutan unggah dokumen).
  • Penegakan akses berbasis peran — agen menyamar sebagai pengguna dengan set peran/izin yang berbeda untuk memastikan elemen UI ditampilkan/disembunyikan dan diaktifkan/dinonaktifkan dengan benar.
  • Perilaku responsif — pengujian pada ukuran viewport desktop dan tablet untuk memastikan integritas tata letak.
  • Kepatuhan aksesibilitas — memverifikasi bahwa navigasi keyboard, atribut ARIA, dan rasio kontras memenuhi persyaratan WCAG 2.1 AA.

5.6.2 Skenario Interaksi

Simulasi interaksi pengguna disusun berdasarkan skrip pengujian berbasis persona:

5.6.3 Klasifikasi Defect

Defect yang diidentifikasi selama simulasi interaksi pengguna diklasifikasikan menggunakan taksonomi tingkat keparahan yang sama seperti insiden operasional (§4.3):

5.7 Validasi Integritas Data

5.7.1 Ruang Lingkup

Integritas data divalidasi pada tiga level setelah setiap run pengujian dan sebelum promosi deployment apa pun:

5.7.2 Asersi Integritas

Agen AI menjalankan asersi integritas berikut pada akhir setiap skenario simulasi:

(a) Zero Orphans: Kueri SELECT di semua tabel junction dan child memastikan tidak ada record yang mereferensikan parent record yang tidak ada. (b) Balance Verification: Untuk modul keuangan — total debit sama dengan total kredit pada setiap cost centre; budget committed + actual + remaining sama dengan total budget. (c) Sequence Integrity: Urutan bernomor otomatis (nomor dokumen, ID transaksi) tidak memiliki gap dan tidak ada duplikasi. (d) Concurrency Safety: Thread agen paralel yang menjalankan pembaruan yang saling bertentangan menghasilkan outcome yang deterministik dan benar dengan respons optimistic-locking yang sesuai. (e) Encryption at Rest: Field sensitif (PII, data keuangan) disimpan terenkripsi di basis data; plaintext hanya tersedia melalui lapisan dekripsi aplikasi.

5.7.3 Laporan Integritas Data

Setiap siklus pengujian menghasilkan Laporan Integritas Data otomatis yang berisi:

• Total assertasi yang dijalankan dan jumlah lulus/gagal.
  • Catatan kegagalan terperinci dengan tabel, kolom, ID record, nilai yang diharapkan, dan nilai aktual.
  • Analisis tren yang membandingkan skor integritas selama sepuluh siklus pengujian terakhir untuk mengidentifikasi pola penurunan.
  • Tindakan remediasi yang dilakukan (diperbaiki otomatis vs. diekskalasi ke pengembangan).

Laporan Integritas Data dilampirkan pada tiket deployment dan disertakan dalam paket bukti UAT yang diberikan kepada Customer.

5.8 Pengujian Penerimaan Pengguna Universal (UAT)

5.8.1 Prasyarat UAT

Provider tidak boleh mengundang Customer untuk memulai UAT sampai prasyarat berikut terpenuhi:

• (a) Semua tingkat pengujian L1–L4 telah diselesaikan tanpa defect P1/P2 yang masih terbuka.
• (b) Laporan Integritas Data (§5.7.3) menunjukkan tingkat keberhasilan asersi 100%.
• (c) Lingkungan Staging Customer telah diperbarui dengan candidate build.
• (d) Template kasus uji, data uji, dan kredensial pengguna telah disiapkan dan dikomunikasikan kepada lead UAT yang ditunjuk Customer.

5.8.2 Pelaksanaan UAT

UAT dilaksanakan oleh perwakilan yang ditunjuk Customer menggunakan lingkungan Staging. Provider harus:

• Sediakan template kasus uji terstruktur yang selaras dengan proses bisnis Customer.
  • Menyiapkan data uji realistis yang mencerminkan skenario produksi tanpa mengekspos data pribadi.
  • Menyediakan Service Desk untuk pencatatan defect, triase, dan penyelesaian selama jendela UAT.
  • Menetapkan sumber daya QA Provider khusus sebagai liaison UAT, tersedia untuk dukungan real-time melalui grup WhatsApp Business bersama (§4.4) dan Embedded Ticketing System (§4.1).

5.8.3 Persetujuan UAT

Tidak ada deployment ke Production yang boleh dilanjutkan tanpa persetujuan UAT tertulis dari perwakilan Customer yang berwenang. Dokumen persetujuan harus menegaskan bahwa Customer telah memvalidasi rilis terhadap kriteria penerimaannya dan mengesahkan promosi ke Production.

Jika Customer tidak memberikan persetujuan atau penolakan dalam sepuluh (10) Hari Kerja sejak tanggal mulai UAT, Provider harus menerbitkan pengingat tertulis. Jika tidak ada respons dalam lima (5) Hari Kerja tambahan, rilis tersebut dianggap diterima oleh Customer.

5.8.4 Penanganan Defect UAT

Defect yang diidentifikasi selama UAT dikelola melalui Embedded Ticketing System (§4.1) dan diklasifikasikan sesuai taksonomi tingkat keparahan pada §5.6.3. Aturan berikut berlaku:

• Defect P1/P2: Blokir persetujuan UAT. Provider harus memperbaiki dan mempresentasikan kembali fungsi yang terdampak dalam siklus sprint saat ini.
  • Defect P3: Tidak menghalangi persetujuan. Provider harus melakukan remediasi pada sprint berikutnya dan mengonfirmasi penyelesaiannya kepada Customer.
  • Defect P4: Dicatat ke backlog. Remediasi dijadwalkan berdasarkan kapasitas dan masukan prioritas Customer.

5.9 Advisory Optimisasi Proses

5.9.1 Ikhtisar

Kemampuan unik yang dihadirkan oleh kerangka pengujian berbantuan AI milik Provider adalah kemampuan menghasilkan wawasan optimisasi proses yang dapat ditindaklanjuti dari analisis data eksekusi pengujian. Layanan ini mengubah pengujian dari sekadar gerbang mutu defensif menjadi aktivitas penciptaan nilai yang proaktif bagi Customer.

5.9.2 Generasi Wawasan

Selama eksekusi pengujian, agen AI secara terus-menerus menangkap dan menganalisis:

• (a) Pola Latensi Transaksi: Mengidentifikasi langkah alur kerja yang secara konsisten menghabiskan waktu pemrosesan tidak proporsional, yang menunjukkan potensi bottleneck pada aturan bisnis atau pola akses data.
• (b) Frekuensi Pengecualian: Mengatalogkan kegagalan validasi, penolakan aturan bisnis, dan penolakan persetujuan untuk menampilkan titik friksi proses yang dapat mengindikasikan aturan yang salah konfigurasi atau panduan pengguna yang kurang jelas.
• (c) Anomali Kualitas Data: Mendeteksi pola record yang tidak lengkap, penggunaan nilai default secara berlebihan, atau kesalahan input data yang sistematis yang mengindikasikan perlunya redesain formulir atau penyesuaian field wajib.
• (d) Konflik Izin: Mengidentifikasi kombinasi peran/izin yang menciptakan bottleneck persetujuan yang tidak perlu atau, sebaliknya, celah pemisahan tugas.
• (e) Fitur yang Kurang Dimanfaatkan: Menandai modul atau fitur yang diaktifkan tetapi tidak digunakan dalam skenario pengujian realistis, yang mengindikasikan potensi kesenjangan pelatihan atau biaya lisensi yang tidak perlu.

5.9.3 Penyampaian Rekomendasi

Rekomendasi optimisasi proses adalah:

• Dikompilasi: Ke dalam Laporan Optimasi Proses terstruktur setelah setiap siklus pengujian utama (Rilis Sprint atau Upgrade).
  • Diklasifikasikan: Berdasarkan dampak (Tinggi/Sedang/Rendah), upaya (perubahan konfigurasi, pengembangan minor, pengembangan besar), dan risiko (tanpa risiko, risiko rendah, memerlukan UAT).
  • Disampaikan: Kepada Customer selama Quarterly Service Review (§3.9) oleh Service Delivery Manager.
  • Dilacak: Sebagai item tindakan dalam Continuous Service Improvement (CSI) register (§4.10) dengan jadwal waktu dan penanggung jawab yang disepakati.

5.9.4 Batasan Ruang Lingkup

Advisory Optimisasi Proses diberikan sebagai informasi. Implementasi rekomendasi apa pun merupakan perubahan konfigurasi atau permintaan pengembangan yang diatur oleh proses manajemen perubahan dan perencanaan sprint yang berlaku (§4.6, §4.7). Provider tidak boleh menerapkan perubahan optimisasi tanpa persetujuan Customer dan, jika berlaku, Formal Scope Change Request (§2.7).

5.10 Tata Kelola & Pelaporan Pengujian

5.10.1 Repositori Bukti Pengujian

Provider harus memelihara repositori bukti pengujian terpusat dan tidak dapat diubah untuk setiap Customer, yang berisi:

• Rencana pengujian dan spesifikasi kasus uji untuk setiap deployment.
• Log eksekusi agen AI (trace interaksi API lengkap, timestamp, hasil asersi).
• Laporan integritas data (§5.7.3).
• Laporan optimisasi proses (§5.9.3).
• Paket bukti UAT (hasil kasus uji, log defect, dokumen persetujuan).
• Riwayat evolusi rangkaian regresi (kasus uji yang ditambahkan/dimodifikasi/didepresiasi).

Bukti pengujian disimpan selama Framework berlaku ditambah dua belas (12) bulan, atau selama diwajibkan oleh regulasi perlindungan data yang berlaku (GDPR Art. 5(1)(e); UAE PDPL Art. 5), mana yang lebih lama.

5.10.2 Metrik Kualitas

Provider harus melacak dan melaporkan metrik kualitas berikut, yang disertakan dalam Quarterly Service Review (§3.9):

5.10.3 Perbaikan Berkelanjutan

Kerangka SQT tunduk pada perbaikan berkelanjutan sejalan dengan Siklus Deming (Plan-Do-Check-Act):

• (a) Plan: Strategi pengujian dan konfigurasi AI-agent ditinjau dan diperbarui pada awal setiap kuartal berdasarkan tren metrik kualitas dan masukan Customer.
• (b) Do: Rangkaian pengujian yang diperbarui dan konfigurasi agent diterapkan ke lingkungan Staging Customer.
• (c) Check: Metrik kualitas (§5.10.2) dievaluasi terhadap target; analisis akar masalah dilakukan atas setiap target yang tidak tercapai.
• (d) Act: Tindakan korektif dan preventif dicatat dalam register CSI (§4.10) dan dilaksanakan pada siklus sprint berikutnya.

5.11 Keamanan & Kepatuhan

5.11.1 Perlindungan Data Pengujian

Semua data pengujian yang digunakan dalam proses SQT tunduk pada kewajiban perlindungan data dalam Kerangka ini (Bab [Perlindungan Data — referensi bab mendatang]). Secara khusus:

• Data produksi harus dianonimkan atau dipseudonimkan sebelum digunakan di lingkungan nonproduksi, sesuai dengan GDPR Pasal 89(1) dan UAE PDPL Pasal 5.
• AI agents tidak menyimpan data Customer setelah sesi pengujian. Semua data yang diproses oleh AI Testing Agents bersifat sementara dan dihapus setelah sesi berakhir.
• Token API dibatasi pada izin minimum yang diperlukan, dibatasi waktunya, dan dicabut secara otomatis pada akhir sesi.
• Log bukti pengujian dienkripsi saat tersimpan (AES-256) dan saat dikirim (TLS 1.3).

5.11.2 Tata Kelola Agent

Penggunaan AI agents oleh Provider dalam kerangka SQT diatur oleh:

• Kepatuhan EU AI Act: AI agents yang digunakan untuk pengujian perangkat lunak diklasifikasikan sebagai berisiko minimal di bawah EU AI Act (Regulation (EU) 2024/1689), karena beroperasi pada data nonproduksi dalam lingkungan terkendali dan tidak membuat keputusan otonom yang berdampak pada orang perseorangan.
• NIST AI RMF: Metodologi pengujian AI milik Provider selaras dengan prinsip validity, reliability, dan accountability dalam NIST AI Risk Management Framework (AI RMF 1.0).
• Pengawasan Manusia: AI agents beroperasi di bawah pengawasan manusia. Semua hasil pengujian, rekomendasi optimasi, dan keputusan penerapan memerlukan peninjauan dan persetujuan manusia sebelum tindakan diambil.
• Transparansi: Atas permintaan Customer, Provider harus menyediakan dokumentasi konfigurasi AI-agent, logika pengambilan keputusan, dan log interaksi untuk setiap siklus pengujian.

EU AI Act — Regulation (EU) 2024/1689 NIST AI Risk Management Framework 1.0

5.12 Register Proses

5.12.1 Registri Proses

5.12.2 Matriks RACI

R = Responsible | A = Accountable | C = Consulted | I = Informed

5.12.3 Alur Proses — Siklus Hidup Kualitas & Pengujian Perangkat Lunak