Coverage %90 Olduğunda Neden Hala İçimiz Rahat Etmez?

Seri 1: Liderin Masası – Bölüm 1

Dashboard yeşil. Test koşumları sorunsuz tamamlanmış. Son rapora göre kod kapsama oranı yüzde doksanın üzerinde. Teorik olarak her şey yolunda görünür; hatta yöneticilere sunulan slaytlarda bu oran güven verici bir kalkan gibi durur.

Ama cuma akşamı prod ortamına yeni sürüm çıkarken bir test liderinin ya da kıdemli bir test mühendisinin içindeki o huzursuzluk kolay kolay geçmez.

Çünkü sahada biraz zaman geçirmiş herkes bilir: Kodun üzerinden geçmiş olmakla, o kodu gerçekten sınamış olmak aynı şey değildir.

Rakamların Yarattığı Güven Yanılsaması

Yazılım dünyasında ölçülebilen şeyleri çok seviyoruz. Bir metriği hedef yapıp arkasına sığınmak her zaman daha konforlu. Coverage oranı da bu konforun en büyük tuzaklarından biri.

Bir gün ekiple oturup bir servisin testlerine bakıyorduk. Testler kusursuz çalışıyor, satır kapsaması yüzde doksan beşi gösteriyor. Ancak kodun içine biraz indiğimizde gördüğümüz manzara şuydu: Fonksiyon çağrılmış, parametreler verilmiş, satırlar çalıştırılmış ama dönen değerin iş mantığına etkisi neredeyse hiç doğrulanmamış. Yani kod satırları “ziyaret edilmiş”, ama kimse o satırların ne amaçla orada olduğunu sorgulamamış.

Metriği tutturmak için yazılan test ile sistemin kırılganlığını anlamak için kurgulanan test arasındaki fark tam olarak burada başlar. Coverage, bir testin koddan geçip geçmediğini söyler; o testin anlamlı bir iddiada bulunup bulunmadığını değil.

Testçinin Zihni Kod Satırında Değil, Boşluklarda Gezer

İyi bir test mühendisinin asıl katma değeri, kodun yazıldığı yerlerde değil, yazılmadığı boşluklarda ortaya çıkar:

• Geliştiricinin "buraya zaten bu tip veri gelmez" dediği yerler,
• Ürün yöneticisinin kabul kriterine yazmayı unuttuğu sınır durumlar,
• İki servisin haberleşirken birbirine duyduğu kontrolsüz güven,
• Ve en önemlisi; kullanıcının arayüzde yapabileceği en mantıksız hareketler.

Coverage araçları bu boşlukları görmez. O araçlar sadece var olan kodu bilir; olması gerekip de unutulan mantıkları bilmez. Sistemin asıl canını yakan hatalar ise genellikle kodun içinde yanlış yazılmış bir satırdan değil, hiç yazılmamış bir koşuldan doğar.

Kalite Raporlarda Değil, Reflekste Yaşar

Bir test lideri olarak ekibimde coverage oranının yüzde seksenlerden doksanlara çıkmasından çok daha fazla önemsediğim bir şey var: Bir test mühendisinin yeni bir özelliği incelerken sorduğu ilk sorunun niteliği.

Ekip arkadaşım masaya oturduğunda “Bunu otomasyona nasıl bağlarız?” sorusundan önce, “Burada işler yolunda gitmezse kullanıcı ne yaşar?” diye sorabiliyorsa, kaliteyi asıl o an güvenceye almaya başlıyoruz demektir.

Otomasyon sadece ritmi tutar, tekrarlı yükü sırtlar. Ama güven duygusu, o otomasyonun arkasındaki merak ve şüphecilikten beslenir. Testi sadece yeşil yanan bir Jenkins/GitLab pipeline’ı olarak gören takımlar, metrikleri kusursuz olsa bile prod ortamında şaşırmaya mahkûmdur.

Masadaki Gerçek Soru

Rakamları bir kenara bıraktığımızda liderin masasında kalan soru aslında basittir:

Sisteme gerçekten güveniyor muyuz, yoksa sadece raporların yeşil yanmasıyla kendimizi mi teselli ediyoruz?

İçimizin rahat etmesi, hiçbir satırın test edilmeden geçmemesine değil; ekibin o sistemi bozabilecek kadar derin düşünüp düşünmediğine bağlı. Bazen yüzde yetmiş coverage oranına sahip ama sınırları gerçekten zorlanmış bir sistem, yüzde doksan beşlik mekanik bir test setinden çok daha huzurlu bir uyku uyutur.

Serinin devamında masadaki bir diğer sancılı konuya bakacağız: İyi bir test mühendisini burnout noktasına getiren ve "ben bu işi bırakıyorum" dedirten o sessiz kırılma anları.