Yazılım Test Mülakat Soruları: Test Senaryosu, Hata Raporu ve Risk Önceliği

Yazılım test mülakat soruları için güçlü bir cevap, önce beklenen davranışı netleştirir, sonra bu davranışı çürütebilecek testleri seçer. “Pozitif ve negatif senaryolar yazarım” demek yerine başlangıç durumunu, işlemi, gözlenebilir sonucu ve en önemli riski açıklayın. Hata raporu da başka bir kişinin aynı sorunu yeniden oluşturmasını sağlamalıdır.

Bu yazıda bir rezervasyonun saatini değiştirme özelliği üzerinden çalışacağız. Çelişkili iki gereksinimi ayıracak, karar tablosu hazırlayacak ve yinelenen onay e-postasını kanıtlarıyla raporlayacaksınız. İlk pratik için Testing a New Feature: Planning Test Cases and Handling Flaky Tests sorusunda hangi ürün riskini önce kontrol edeceğinizi yazın.

Kanıt sınırı: Test tasarımı kavramları için resmi ISTQB dokümanı, nesne yetkisi için OWASP ve HTTP davranışı için RFC kullanılıyor. Rezervasyon kuralları, kayıtlar, hata raporu ve çalıştırılan küçük model özgün PracHub alıştırmalarıdır. Gerçek bir işverenin soruları, aday raporları veya evrensel mülakat aşamaları olarak sunulmaz. Öncelik sırası, bu örneğin etkilerine dayalı bir hazırlık önerisidir.

Gereksinimi netleştirme, senaryo oluşturma ve kanıtlı hata raporu hazırlama süreci

Çelişkili gereksinimi test sonucu sanmayın

Görüşmeci iki not verir: “Rezervasyon, başlangıcından en az 24 saat önce değiştirilebilir” ve “Başlangıca 24 saat veya daha az kaldığında değişiklik engellenir.” Tam 24 saatte biri izin verirken diğeri engeller. Beklenen davranışı koddan çıkarmadan ürün sahibine sınırı sorun.

Sorunuz somut olsun: “Tam 24 saat sınırında hangi davranış kabul ediliyor? Kalan süreyi sunucu mu hesaplıyor? Eski rezervasyonun başlangıcı mı, seçilen yeni saat mi temel alınıyor?” Bu ayrımlar hangi saatle test yapacağınızı ve sınırdaki beklentiyi belirler.

Özgün vaka için ürün kararı şu şekilde netleştirilmiştir: Eski başlangıç saatine en az 24 saat varsa değişiklik yapılabilir; tam 24 saat dahildir. Saat hesabı sunucunun UTC zamanına göre yapılır. Bu, gerçek rezervasyon ürünleri için genel bir kural değil, aşağıdaki testlerin varsayımıdır.

Karar henüz verilmediyse iki olası beklentiyi kaydedin ve sınır testini açık gereksinim olarak işaretleyin. Diğer bağımsız kontrolleri yapabilirsiniz. Belirsizlik yüzünden tüm çalışmayı durdurmak gerekmez; ancak belirsiz sınır için güvenilir geçti-kaldı sonucu üretilemez.

Özelliğin durum ve yan etkilerini tanımlayın

Başlangıç kaydı R17, sahibi U1, durumu confirmed, sürümü 1 olsun. Eski başlangıç 10 Ekim 2026 saat 12.00 UTC, istenen yeni başlangıç 11 Ekim 14.00 UTC’dir. Hedef zamanın uygun olup olmadığı sunucuda doğrulanır. Bu örnekte ödeme, fiyat farkı ve iptal ücreti kapsam dışıdır.

Başarılı değişiklik aynı rezervasyon kimliğini korur, yeni saati yazar, sürümü 2 yapar ve bir mantıksal onay olayı üretir. Reddedilen istek rezervasyonu veya onay olaylarını değiştirmez. Aynı işlemin tekrar gönderilmesi ayrı bir değişiklik sayılmaz.

İstemci aynı işlem için aynı operation_id değerini kullanır. Aynı sahip, aynı işlem kimliği ve aynı içerikle tekrar geldiğinde önceki sonuç döner; yeniden sürüm artışı veya yeni onay olayı olmaz. Aynı işlem kimliği farklı içerikle gelirse çakışma sonucu beklenir. Bu davranış uygulamanın sözleşmesidir.

Resmi teknik bilgi: RFC 9110, idempotent işlemi tekrarlamanın amaçlanan etkisini tanımlar. Bir POST isteğine işlem kimliği eklemek tek başına bu güvenceyi sağlamaz. Sunucunun kayıt, karşılaştırma ve yan etki davranışını ayrıca test etmeniz gerekir.

Resmi güvenlik ilkesi: OWASP nesne düzeyinde yetkilendirme rehberi, nesneye erişen işlemlerde yetki kontrolünün önemini açıklar. R17 kimliğini bilmek sahip olma yetkisi değildir. Daha önce tamamlanmış bir işlemin sonucunu tekrar döndürürken de özel rezervasyon bilgileri yetkisiz kullanıcıya verilmemelidir.

Karar tablosuyla davranışı görünür yapın

Resmi test kavramı: ISTQB CTFL v4.0.1, karar tablolarını koşul birleşimleri ile sonuçları inceleyen bir teknik olarak ele alır. Aşağıdaki tablo özgün sözleşmenin seçilmiş kurallarını gösterir; tüm olası birleşimlerin eksiksiz kapsandığı iddiası değildir.

Durum	Sahip mi?	Rezervasyon aktif mi?	Kalan süre	Hedef uygun mu?	Beklenti
Normal değişiklik	Evet	Evet	25 saat	Evet	Başarılı; sürüm 2, bir onay olayı
Sınır	Evet	Evet	Tam 24 saat	Evet	Başarılı; sürüm 2, bir onay olayı
Sınırın altı	Evet	Evet	23 saat 59 dakika 59 saniye	Evet	Red; kayıt ve olay sayısı aynı
Başkasının kaydı	Hayır	Evet	25 saat	Evet	Yetki reddi; özel sonuç yok
İptal edilmiş kayıt	Evet	Hayır	25 saat	Evet	Red; durum korunur
Dolu hedef	Evet	Evet	25 saat	Hayır	Çakışma; eski saat korunur

Her satırın başlangıç verisini yeniden kurun. İlk başarılı test sürümü 2’ye çıkardıktan sonra ikinci testi aynı kirli kayıtla çalıştırmak sınır davranışını yanlış yorumlatabilir. Test bağımsızlığı, yalnızca test sırasını değiştirebilmek değil, başlangıç koşulunun gerçekten biliniyor olmasıdır.

Tablodaki bir koşul diğerlerini etkileyebilir. Yetkisiz kullanıcı için hedef uygunluk veya mevcut rezervasyon saati açıklanmamalıdır. Reddetme sırası ürünün bilgi sızdırma ve hata sözleşmesine göre belirlenir. Birden fazla koşul yanlışken yalnızca birini doğru yapıp sonucun nasıl değiştiğini inceleyen ek testler faydalıdır.

Senaryoyu ölçülebilir bir test kaydına dönüştürün

“24 saat sınırını test et” bir test fikridir. Uygulanabilir kayıt ise şunu belirtir: test saati 9 Ekim 12.00 UTC’ye sabitlenir; R17 ilk durumda bulunur; sahibi U1, uygun yeni saat için değişiklik gönderir; sonuç başarılıdır; okuma ile yeni saat ve sürüm 2 görülür; test olay kaydında bir onay vardır.

Test saati 9 Ekim 12.00.01 UTC olduğunda, aynı ilk rezervasyon verisiyle ayrı test red bekler. Yanıtın yanında eski saat, sürüm 1 ve sıfır yeni onay olayı korunmalıdır. Yalnızca hata mesajını kontrol etmek, reddedilmiş isteğin arka planda değişiklik yapmasını kaçırabilir.

Saatin duvardaki gerçek zamana bağlı olması testi kararsızlaştırır. Saat sağlayıcısı veya izin verilen test kontrolü kullanın; üretim sisteminin saatini değiştirmeyin. Tarayıcı saatini değiştirmek de sunucudaki sınırı kontrol ettiğinizi kanıtlamaz. Hangi saatin kullanıldığını söyleyin.

Kara kutu testinde yalnızca ekran ve okuma API’si varsa veritabanının iç durumunu gördüğünüzü iddia etmeyin. Ekranda yeni saati ve sürümü gözlemek bir kanıttır; kalıcı kayıt, olay kuyruğu ve e-posta sağlayıcısı için ayrı gözlem noktaları gerekebilir. Test raporunda erişilemeyen katmanı açık bırakın.

İki onayı, iki değişiklikten ayırın

Özgün hata senaryosunda ilk değişiklik sunucuda tamamlanır, fakat istemci yanıtı alamaz. İstemci aynı işlem kimliğiyle tekrar gönderir. Kullanıcı iki e-posta görür. Bu gözlem, rezervasyonun iki kez değiştiğini tek başına göstermez.

İki onay e-postasının ardından rezervasyon sürümü, işlem kimliği ve olay kimliğini kontrol etme

Üç ayrı kanıtı toplayın: rezervasyonun son sürümü ve saati, değişiklik işleminin kayıtları, mantıksal onay olayı ve teslim denemeleri. Sürüm yalnızca 1’den 2’ye çıktıysa iki yazma iddiası desteklenmez. Aynı olay iki kez teslim edilmiş olabilir; farklı iki olay üretilmişse araştırılacak katman değişir.

Sentetik iz	İlk istek	Aynı işlemin tekrarı	Yorum
Rezervasyon	Sürüm 1 → 2	Sürüm 2 olarak kalır	Tek değişiklik gözleniyor
İşlem	`op-41` tamamlandı	`op-41` önceki sonucu döndürdü	İşlem tekrarı tanındı
Hatalı olay üretimi	`evt-81`	Yeni `evt-82`	Aynı değişiklik için iki mantıksal olay oluştu
Kullanıcının gözlemi	Bir onay	İkinci onay	Tek başına kök neden değil

Bu iz, gerçek sistemden alınmış bir log değildir; hatayı ayırmak için hazırlanmış örnektir. Başka bir sistemde aynı olayın iki teslim denemesi iki e-posta yaratabilir. Sadece e-posta sayısından “idempotency bozuk” veya “veritabanı iki kez yazdı” sonucuna atlamayın.

Özgün yerel modelin hatalı tekrar yolu, sürümü 2’de tutarken olay sayısını ikiye çıkardı. Düzeltilmiş model aynı tekrar için bir olayda kaldı. Bu, gösterilen modelin kanıtıdır; gerçek dağıtık kuyruğun eşzamanlılık, çökme veya teslim güvencelerini doğrulamaz.

Yeniden üretilebilir hata raporunu yazın

İyi bir başlık, gözlenen belirtiyi ve oluştuğu koşulu söyler: “Tamamlanmış saat değişikliği aynı işlem kimliğiyle tekrarlandığında ikinci onay olayı üretiliyor.” “Rezervasyon sistemi çalışmıyor” hem fazla geniş hem de araştırma için yetersizdir.

Rapor alanı	Özgün örnek
Ortam	Yerel test modeli; sabit UTC saati; başlangıç `R17`, sürüm 1
Önkoşul	`U1` kayıt sahibi, 25 saat kalmış, hedef uygun, işlem `op-41`
Adımlar	Değişikliği gönder; ilk yanıtı alınamamış kabul et; aynı kimlik ve içerikle tekrar gönder
Beklenen	Sürüm 2, yeni saat, aynı tamamlanmış sonuç ve bir mantıksal onay olayı
Gerçek	Sürüm 2 olarak kaldı; `evt-81` ve `evt-82` oluştu
Etki	Kullanıcı çelişkili veya yinelenen onay alabilir; destek başvuruları artabilir
Kanıt	İki işlem denemesi, sürüm kontrolü ve iki ayrı olay kimliği
Sınır	Gerçek e-posta teslimi ve üretim sıklığı bu modelde ölçülmedi

Sıralı adımların aynı kaydı gerçekten hedeflediğini ve tekrarın aynı içeriği taşıdığını gösterin. Yeniden denemede yeni işlem kimliği üretildiğinde farklı bir sözleşmeyi test ediyor olabilirsiniz. İlk işlemi tamamlamadan atılan tekrar da tamamlanmış sonucu yeniden okuma senaryosuyla aynı değildir.

Gerçek bir projede raporu ekibin kullandığı araçta kaydedin. GitHub’ın issue oluşturma belgesi, başlık, açıklama ve ilgili kayıtlarla bağlantı kurmayı destekler. Buradaki rapor alanları ise bu vakaya ait hazırlık şablonudur; GitHub’ın zorunlu alanları gibi sunulmaz.

Ekran görüntüsü ve log eklerken gerçek müşteri adı, e-posta, oturum anahtarı veya başka özel verileri paylaşmayın. Güvenli test kimlikleri yeterlidir. Görüşmeciye “loglara bakarım” demek yerine hangi kimliğin hangi iki kaydı ilişkilendirdiğini açıklayın.

Önceliği kullanıcı etkisiyle savunun

Görüşmeci üç hata verir: başkasının rezervasyonunu değiştirme, aynı işlemde iki onay, tarih başlığında küçük hizalama sorunu. Bu örnekte yetkisiz değişiklik önce gelir; veri ve kullanıcı güveni etkisi büyüktür. İki onay sonraki sıradadır; kullanıcıyı yanıltabilir. Görsel sorun, temel akış okunabilir ve kullanılabilir kaldığı varsayımıyla daha düşük sıradadır.

Bu öncelik sırası, örnekteki kullanıcı etkisi ve varsayımlarla sınırlıdır. Tarih alanı ekran okuyucuyla kullanılamıyorsa veya yanlış saat seçimine yol açıyorsa “görsel” etiketi etkisini küçültür. Üretimdeki sıklık, etkilenen kullanıcı sayısı, geri dönüş olanağı ve geçici çözüm önceliği değiştirebilir. Bilmediğiniz sıklığı tahmin edilmiş gerçek gibi söylemeyin.

Ciddiyet ile planlanan çözüm sırasını ayırın. Ciddiyet hatanın etkisini anlatır; öncelik ürün ve teslim koşullarıyla birlikte kararlaştırılır. Test uzmanı somut etki ve kanıt sunar. Tek başına iş önceliklerinin sahibi olduğunu iddia etmesi gerekmez.

Zaman azsa ilk olarak yetki reddinde hiç değişiklik olmadığını, tek başarılı değişikliği, tam 24 saat sınırını ve tamamlanmış işlemin tekrarını kontrol etmeyi önerin. Daha sonra iptal edilmiş kayıt, dolu hedef ve farklı içerikle tekrar gibi kuralları genişletin. Hangi risklerin henüz test edilmediğini görünür tutun.

Düzeltmeden sonra neyi yeniden kontrol edersiniz?

Hata doğrulaması, aynı başlangıç ve tekrar adımlarıyla ikinci olayın artık oluşmadığını göstermelidir. Regresyon ise ilgili diğer davranışları koruduğunuzu kontrol eder: ilk başarılı değişiklik hâlâ bir olay üretmeli, farklı içerik aynı kimlikle kabul edilmemeli, yetkisiz tekrar özel sonucu döndürmemelidir.

Tekrarı engellemek için bütün bildirimleri kapatan bir düzeltme ilk hatayı saklar ama başarı yolunu bozar. Sadece “iki olay yok” kontrolü bu kusuru kaçırabilir. Hem doğru sayıyı hem olayın hangi başarılı değişikliğe ait olduğunu kontrol edin.

Yerel referans modelinde sekiz bağımsız kural satırı ve dört tekrar davranışı kontrolü kullanıldı. Toplam on iki kontrol geçti; ayrıca hatalı model iki olay üreterek rapordaki belirtiyi yeniden oluşturdu. Bu sonuçlar küçük sözleşme modeline aittir, bütün ürünün hatasız olduğunu göstermez.

Gerçek sisteme geçildiğinde aynı anda gelen iki istek, süreç yeniden başlatma, kalıcı işlem kaydı ve bildirim teslimi ayrı entegrasyon kontrolleri ister. Yerel modelin tek süreçte çalışması bunları doğrulamaz. Bir çıkış notu, geçti denilen kontrollerin yanında kalan riskleri ve gözlenemeyen katmanları da belirtmelidir.

Mülakatta cevabınızı kanıt üzerinden anlatın

Şöyle bir kısa anlatım hazırlayın: “Önce tam 24 saat sınırındaki gereksinim çelişkisini netleştirdim. Sahiplik, durum, süre ve hedef uygunluğundan karar tablosu çıkardım. Her testte yanıtın yanında rezervasyonun saati, sürümü ve onay olaylarını kontrol ettim. Tekrar senaryosunda iki bildirimi iki yazma olarak yorumlamadım; olay kimlikleriyle hatayı daralttım.”

Kendi projenizden örnek istenirse bu uydurma vakayı yaşanmış deneyiminiz gibi anlatmayın. Gerçek katkınızı, kullandığınız kontrolleri ve gözlediğiniz sonucu söyleyin. Ölçmediğiniz kullanıcı etkisi veya üretim iyileşmesi için sayı eklemeyin.

Beş PracHub sorusuyla devam edin

Bu başlıklar ilgili çalışma kayıtlarıdır, belirli bir mülakatın soru listesi değildir. Her sorunun sözleşmesi farklıdır; rezervasyon örneğinin varsayımlarını otomatik olarak taşımayın.

PracHub sorusu	Çalışılacak beceri
Testing a New Feature: Planning Test Cases and Handling Flaky Tests	Ürün riski, başlangıç verisi ve kanıtı ayırın.
Design Test Cases for UI Change: Ensuring Quality and Functionality	Ekran değişikliğinin gözlenebilir beklentilerini yazın.
Explain work-simulation approach under ambiguity	Açık soruyu, varsayımı ve onaylanmış kararı ayırın.
Debug and Harden a Ticketing Backend API	Tekrar ve durum kanıtlarıyla bir API hatasını daraltın.
Walk Through Your Hardest Debugging Investigation	Araştırmayı gözlem, hipotez ve doğrulamayla anlatın.

Testing a New Feature: Planning Test Cases and Handling Flaky Tests sorusu için önce üç risk seçin. Ardından en önemli riskin test kaydını ve başarısız olursa açacağınız raporu yazın; raporu okuyan ikinci kişinin aynı başlangıç ve adımlarla sonucu yeniden oluşturabildiğini kontrol edin.