Çoğu ekipte gereksinimler değiştiğinde test senaryolarına hiçbir şey olmaz. Gereksinimler değişir. Ürün değişir. Test senaryoları ise yazıldıkları dokümanda öylece durur ve artık var olmayan bir ürünü anlatır.
Bu bir disiplin sorunu değil. Yapısal bir sorun. Test senaryoları, değişimi tetikleyen şeylerden yalıtılmış biçimde oluşturulur. Spesifikasyonlar güncellendiğinde test senaryoları kendiliğinden peşlerinden gelmez. Test paketinizin söylediği ile ürününüzün yaptığı arasındaki fark, sprint sprint sessizce büyür.
Eskimiş Test Senaryosu Tam Olarak Ne Demek?
Eskimiş bir test senaryosu, ürünün artık sahip olmadığı, anlatıldığı şekliyle hiç sahip olmadığı ya da test yazıldıktan sonra önemli ölçüde değişmiş bir davranışı anlatan senaryodur.
Eskimiş test senaryoları iki şekilde yanıltır. Ya geçmeleri gerekirken başarısız olurlar, çünkü implementasyon değişmiş ve test yeni doğru davranışa göre güncellenmemiştir. Ya da başarısız olmaları gerekirken geçerler, çünkü test artık önemi kalmayan bir şeyi kontrol ederken bozulan şeyi kaçırır.
İkinci tür daha tehlikelidir. Bir QA uzmanı bunu çok iyi anlatmıştı: test senaryolarının bir yarı ömrü vardır. Her sprintte belli bir yüzdesi güncelliğini yitirir. Bunlar çoğunlukla yine de geçer, çünkü test uzmanları farkı zihinlerinde düzeltir. Ama dokümantasyon yalan söyler. Test uzmanları zihinlerinde düzeltme yaptığında test paketi tek doğru kaynak olmaktan çıkar. Tek doğru kaynak test uzmanının hafızası olur. O bilgi sistemde değil, tek bir kişinin kafasında yaşar.
Eskimiş Test Dokümantasyonu Gerçekte Ne Kadar Zamana Mal Oluyor?
Araştırmalar, çoğu ekibin beklediğinden daha net rakamlar veriyor.
Sektör analizleri, manuel test prosedürlerini güncel tutmanın tipik bir startup QA ekibinde haftada 8 ila 12 saat gerektirdiğini gösteriyor. Bu, her hafta bir ila bir buçuk günlük mühendislik zamanı demek. Test etmeye harcanmayan, yeni kapsam yazmaya harcanmayan, en başta kaymaması gereken dokümantasyonu güncellemeye harcanan zaman.
MoldStud'ın araştırması, düzgün test dokümantasyonunun bakım eforunu %40'a kadar azalttığını gösteriyor. Yani yapılandırılmış dokümantasyon sistemleri olmayan ekipler, bu taban değerden çok daha fazla zaman kaybediyor.
TestRail'in agile ekipler üzerine analizi, test senaryolarının %5 ila %15'inin her sprintte ya da sürüm döngüsünde güncelleme gerektirdiğini ortaya koydu. Daha yüksek yüzdeler istikrarsız gereksinimlere işaret eder. Hızlı ilerleyen bir üründe sprint başına %15'lik güncelleme oranı, on sprintte tüm test paketinize en az bir kez dokunulmuş olması gerekebileceği anlamına gelir. Çoğu ekip bunun yanına bile yaklaşamaz.
Otomatik test senaryosu onarımını inceleyen 2024 tarihli bir IEEE makalesi, 59 açık kaynak projede 45.373 bozuk test onarımını kapsadı ve test senaryosu eskimesinin bir uç durum olmadığını doğruladı. Bu, aktif olarak bakımı yapılmayan her test paketinin varsayılan halidir.
Gereksinimler Değiştiğinde Ekipler Test Senaryolarını Neden Güncellemiyor
Dürüst yanıt şu: test senaryolarını güncellemek görünmez bir iştir. Bir özellik yayınlamaz. Bir hatayı düzeltmez. Bir ticket'ı tamamlandıya taşımaz. Sprint odaklı bir ortamda görünmez iş yapılmaz.
QA ekiplerine yönelik sektör analizleri, test senaryolarını farklı sürümler boyunca güncellemenin ve versiyon geçmişlerini takip etmenin ciddi zaman aldığını, bunun da hatalara ya da güncellenmesi gerekirken atlanan testlere yol açabildiğini ortaya koyuyor. Ekipler çoğu zaman geçici çözüm olarak test senaryolarını klonlamaya ya da çoğaltmaya başvuruyor. Bu da verimsizliğe yol açıyor, ekipler arasında sürtünme yaratıyor ve yayın döngüsünü geciktiriyor.
Farklı test senaryosu versiyonlarını yönetmenin yapılandırılmış bir yolu olmadığında, test uzmanları bir test senaryosunun hangi versiyonunu çalıştıracaklarını belirlemekte sık sık zorlanır. Güncelliğini yitirmiş testler çalıştırılır, bu da yanıltıcı bulgulara ve kritik sorunların gözden kaçmasına yol açabilir.
Sonuç, hacmi büyürken güvenilirliği küçülen bir test paketidir. Daha fazla test senaryosu, daha az sinyal.
İzlenebilirlik Boşluğu
Test senaryolarındaki kaymanın altında yatan neden kopukluktur. Test senaryoları bir yerde yazılır. Gereksinimler başka bir yerde yaşar. Tasarım kararları üçüncü bir yerde alınır. Bunlardan herhangi biri değiştiğinde diğerlerinin haberi olmaz.
Test senaryosu izlenebilirliği olmadan QA, kontrollü bir süreç olmaktan çıkıp tahmin yürütmeye dönüşür. Test senaryolarını izlenebilirlik olmadan yönetmek çoğu zaman kapsam boşluklarına, tekrarlanan emeğe ve kaybolan bağlama yol açar.
İzlenebilirlik, bir test senaryosu ile doğruladığı gereksinim arasındaki bağdır. Bu bağ var olduğunda ve korunduğunda, bir gereksinim değişikliği güncellenmesi gereken test senaryolarını kendiliğinden ortaya çıkarır. Bu bağ olmadığında eskimiş test senaryolarını bulmanın tek yolu, her birini tek tek okuyup güncel spesifikasyonlarla karşılaştırmaktır. Bunu kimse düzenli olarak yapmaz.
Yapısal sorun budur. Çözüm, ekiplerden daha disiplinli olmalarını istemek değildir. Çözüm, test senaryolarını tek doğru kaynaklarına bağlamak ve böylece kaymayı sessiz değil görünür hale getirmektir.
Testleri Tek Doğru Kaynağınızdan Ürettiğinizde Ne Olur
Test senaryoları, ürününüze yön veren gerçek gereksinimlerden, tasarımlardan ya da spesifikasyonlardan üretildiğinde iki şey değişir.
Birincisi, test senaryoları doğru başlar. Ürünün ne yapması gerektiğini yansıtırlar, çünkü ürünün ne yapması gerektiğini tanımlayan dokümandan türetilmişlerdir. Bir standup toplantısının hatırasından değil. Altı haftalık bir Confluence sayfasından değil. Güncel spesifikasyondan.
İkincisi, spesifikasyon değiştiğinde spesifikasyon ile test senaryosu arasındaki bağlantı görünür olur. Hangi test senaryosunun hangi gereksinimden üretildiğini bilirsiniz. O gereksinim güncellendiğinde etkilenen test senaryoları belirlenebilir. Bakım sorunu ortadan kalkmaz ama yönetilebilir hale gelir.
Aynı şey çalıştırma için de geçerli. Text2Test'teki otomatik test scripti üretimi ile test adımlarını düz metin olarak yazarsınız ve adımlar doğrudan çalışır. Böylece test senaryolarınızla senkronu kaybeden ayrı bir script kod tabanı olmaz.
Tek Doğru Kaynaktan Yapay Zeka ile Test Senaryosu Üretimi: Nasıl Çalışır, Neden Önemli yazımızda ele aldığımız gibi, ürününüzü anlatan bir test paketi ile ürününüzü altı hafta önce anlatmış olan bir test paketi arasındaki fark budur.
Dürüst Olmayan Testlerin Gizli Maliyeti yazımızda da belirttiğimiz gibi, artık gerçeği yansıtmayan bir test paketinin maliyeti yalnızca boşa giden dokümantasyon zamanı değildir. Sahte güvendir. Yanlış şeyi kontrol ettiği için geçen testler. Doğrulama eskidiği için gerçek bir doğrulama olmadan yayına çıkan sürümler.
Bir LLM'e metin parçası yapıştırıp test senaryosu ürettirdiyseniz, LLM Yalnızca Yapıştırdığınızı Görür yazımız bunun eskime sorununu daha ilk günden nasıl ağırlaştırdığını tam olarak açıklıyor.
Öne Çıkanlar
- Test senaryolarının bir yarı ömrü vardır. Her sprintte belli bir yüzdesi güncelliğini yitirir. Çoğu ekip kaç tanesinin yitirdiğini takip etmez.
- Test dokümantasyonunu güncel tutmak, tipik bir startup QA ekibinde haftada 8 ila 12 saate mal olur. Bu, test etmeye ya da kapsam oluşturmaya harcanmayan zamandır.
- Agile ortamlarda test senaryolarının %5 ila %15'i her sprintte güncelleme gerektirir. Çoğu ekip bundan çok daha azını günceller.
- 59 projede 45.373 bozuk test onarımını kapsayan 2024 tarihli bir IEEE çalışması, test senaryosu eskimesinin bakımı yapılmayan paketlerin varsayılan hali olduğunu doğruluyor.
- Yapısal çözüm izlenebilirliktir: test senaryolarını doğruladıkları gereksinimlere bağlamak ve kaymayı sessiz değil görünür kılmak.
- Test senaryolarını gerçek tek doğru kaynağınızdan üretmek, doğru başlamaları ve değişimi tetikleyen şeye bağlı kalmaları demektir.
Sıkça Sorulan Sorular
Test senaryoları ne sıklıkla güncellenmeli?
Agile ortamlarda sektör kıyaslamaları, test senaryolarının %5 ila %15'inin her sprintte güncelleme gerektirdiğini gösteriyor. Pratik yanıt şu: bir gereksinim değişir değişmez ona bağlı test senaryoları gözden geçirilmelidir. Bunu hemen yapmak, sonraya bırakmaktan her zaman daha ucuzdur.
Eskimiş test senaryoları başarısız olmaları gerekirken neden geçer?
Çünkü test, artık doğru davranış olmayan bir şeyi kontrol ediyordur. Bir alan yeniden adlandırıldıysa, bir akış yeniden yapılandırıldıysa ya da bir uç durum farklı biçimde ele alındıysa, test gerçek regresyonu tamamen kaçırırken yine de hatasız çalışabilir. Eskimiş test senaryolarının bozuk olanlardan daha tehlikeli olmasının nedeni budur.
Test senaryosu izlenebilirliği nedir ve neden önemlidir?
Test senaryosu izlenebilirliği, bir test senaryosu ile doğruladığı gereksinim ya da kullanıcı hikayesi arasındaki bağdır. İzlenebilirlik olduğunda bir gereksinim değişikliği etkilenen test senaryolarını otomatik olarak ortaya çıkarır. Olmadığında eskimiş test senaryoları ancak tüm paketin elle gözden geçirilmesiyle bulunabilir.
Test senaryolarını gereksinimlere bağlamak bakımı nasıl azaltır?
MoldStud'ın araştırması, yapılandırılmış gereksinimlere bağlı düzgün test dokümantasyonunun bakım eforunu %40'a kadar azalttığını gösteriyor. Test senaryoları hangi gereksinimden geldiklerini bildiğinde, bir gereksinim değişikliğinden sonra onları güncellemek tüm paketin denetimi yerine hedefli bir iş olur.
Eskimiş test senaryosu ile kararsız (flaky) test senaryosu arasındaki fark nedir?
Kararsız (flaky) bir test senaryosu zamanlama, ortam ya da altyapı sorunları nedeniyle aralıklı olarak başarısız olur. Eskimiş bir test senaryosu ise ürünün artık sahip olmadığı bir davranışı anlattığı için başarısız olur ya da yanlış biçimde geçer. İkisi de test paketinin dürüst olmamasının birer biçimidir, ama nedenleri ve çözümleri farklıdır.
Kaynaklar: QATestLab / Bug0 analizi (2026), MoldStud test dokümantasyonu araştırması, otomatik test senaryosu onarımı üzerine IEEE makalesi (Yaraghi ve ark., 2024), TestRail agile test senaryosu kıyaslamaları (2026), sektörel QA ekibi versiyonlama analizi (2025).