Bir dosyanın değişmesi, kullanıcının gördüğü sorunun çözüldüğünü tek başına kanıtlamaz. CSS doğru yazılmış olabilir fakat eski dosya önbellekten geliyor olabilir. Bir kayıt ekleme fonksiyonu çalışabilir fakat gerçek arayüz yanlış kategoriye kaydedebilir. Codex ile iş tesliminde kanıt toplamak, “yapıldı” cümlesinin hangi gözleme dayandığını açık hale getirir. OpenAI'nin iyi uygulamalar rehberi de tamamlanma ölçütünün görevde belirtilmesini önerir.
Başarıyı işlemden önce tarif edin
“Menüyü düzelt” yerine görülecek davranışı yazın: alt menü masaüstünde açılmalı, klavyeyle erişilebilmeli ve mobilde ekran dışına taşmamalıdır. Böylece doğrulama yalnızca derlemenin bitmesine indirgenmez. Başarı ölçüsü kullanıcı ihtiyacından çıkar; kullanılan teknolojiye göre kanıtın biçimi değişir. Bir API hatası için ekran görüntüsü tek başına yeterli olmayabilir.
Örnek görev: “Kategori alt menüsündeki çerçeveyi kaldır. Hover durumunda yalnızca soldaki sarı çizgi görünsün. Değişikliği canlıya uygula, gerçek sayfada açılan menüyü kontrol et ve sonucu kısa raporla.” Bu istek için kaynak farkı, yayın işlemi ve tarayıcı gözlemi birbirini tamamlar. Her biri farklı bir iddiayı destekler.
Doğrulama katmanlarını ayırın
Kaynak kontrolü, neyin değiştiğini gösterir. Birim testi, belirli mantığın beklenen girdide nasıl davrandığını sınar. Tarayıcı kontrolü, kullanıcının karşılaşacağı arayüzü gösterir. Canlı kontrol ise yayımlanan sürümün gerçekten erişildiğini doğrular. Bir katmanın başarısı diğerlerinin otomatik olarak geçildiği anlamına gelmez; rapor bu sınırı korumalıdır.
Örneğin yerel testlerin geçmesi, canlı veritabanındaki izinleri doğrulamaz. Tarayıcıda sayfanın açılması da arka plandaki bütün eşzamanlı işlemlerin doğru olduğunu kanıtlamaz. Bu nedenle kanıtı dar ve doğru cümleyle anlatın: “Dar ekranda menü taşması görülmedi” ifadesi, “her cihazda kusursuz” iddiasından daha değerlendirilebilirdir.
Kanıtı değişikliğe uygun seçin
Küçük bir başlık düzeltmesinde geniş test paketini tekrar tekrar çalıştırmak gerekmeyebilir. Gerçek metnin doğru sayfada görülmesi yeterli odak kontrolü sağlayabilir. Ödeme hesaplaması gibi davranış değişikliğinde ise sınır değerleri ve hata yolları önem kazanır. Kontrol kapsamını risk, değişen mantık ve mevcut proje gerekleri belirlemelidir.
Görsel düzenlemede ekran görüntüsü alırken doğru durumu yakaladığınızdan emin olun. Alt menü kapalıysa hover çizgisini göstermez. Açık tema kontrolü koyu temayı kanıtlamaz. Görüntüye ek olarak ilgili alanın gerçekten etkileşim kurabildiğini gözlemek gerekir. Statik bir resim görünümü anlatır, bütün davranışı kapsamaz.
Eksik kontrolü doğru adlandırın
Bir test çalışmadıysa nedenini kaydedin. Eksik bağımlılık, ağ engeli veya erişim sınırı nedeniyle yürütülemeyen kontrolü “başarısız test” diye etiketlemeyin. Fakat bunu yapılmış gibi de sunmayın. Kullanıcı neyin doğrulandığını ve hangi belirsizliğin kaldığını kısa bir açıklamadan anlayabilmelidir. Dürüst sınır, uzun bir güvence paragrafından daha faydalıdır.
Son teslimi üç soruyla gözden geçirin: İstenen davranış değişti mi, ilgili ortamda gözlendi mi, rapor yalnızca eldeki kanıtı mı söylüyor? Gerekli kontroller geçtiyse sırf daha çok çıktı üretmek için aynı doğrulamayı tekrarlamayın. Yeni değişiklik veya açık bir endişe varsa ek kontrol yapın. Kanıt toplama, işi uzatan bir tören yerine tamamlanmanın ne anlama geldiğini görünür kılan son adımdır.
Örneğin yayın sonrası kontrol kaydına açılan adresi ve gözlenen sonucu ekleyebilirsiniz. Bu kayıt, sonraki küçük düzenlemenin hangi sürümden başladığını anlamaya yardım eder. Ekran görüntüsünün tarihi ile kontrol edilen sayfanın aynı çalışmaya ait olduğunu da koruyun.
Resmî kaynak: OpenAI Docs — Best practices.
