Varsayalım ki, geliştirdiğiniz uygulamanın bir sayfasında telefon defteri var. Zaman geçtikçe uygulamadaki istekler artıyor ve bir gün gelip diyorlar ki: “Rus pazarına giriyoruz, telefon defterindeki kayıtlar artık Rusça da olacak”. Siz Rusça desteği veriyorsunuz (ya da zaten UTF-8’di, bir bug vardı ve düzelttiniz). Ardından Rusça destekli telefon defterini test ortamına deploy ettiniz ve şikayetler gelmeye başladı: “Telefon defterimiz gözükmüyor”. Siz hatayı buldunuz ve sorunu çözdünüz; artık hem telefon defteri doğru bir şekilde gözüküyor hem de Rusça kayıtlar eklenebiliyor. Artık teyit edildiğine göre bu özellik canlı sisteme geçebilir.
Aradan 3 ay geçti, bu sefer şöyle bir istek geldi: “Müşterilerimiz telefon defterine aynı anda toplu bir şekilde 10.000 kayıt atabiliyor, bu sayının 500.000’e çıkması gerekiyor”. İhtiyaçlar değişti, siz de kodu gözden geçirdiniz; belki de kullandığınız kütüphaneleri değiştirdiniz ve artık bir kerede aktarılabilen kayıt sayısı 500.000 oldu. Yine test edilmesi için test ortamına koydunuz, yine bir şekilde bir hata oluştu ve telefon defterleri gözükmemeye başladı. Test ekibinden size iletilen mesaj şu: “3 ay önce çözülen telefon defterinin gelmemesi problemi tekrar meydana geliyor, neden önceden çözülmüş olan bu problem sürekli karşımıza çıkıyor”. Siz biliyorsunuz ki, ortaya çıkan hata 3 ay önceki ile aynı değil. Sorunu çözüyorsunuz, tekrar test ediliyor, onaylanıyor ve canlı sisteme aktarılıyor.
Biz de yazılım geliştirme süreçlerimizin test aşamasında buna benzer şikayetler alıyoruz: “Bu sorun çözülmüştü, neden tekrar geldi”. Ben biliyorum ki, bu sorun 3 ay önceki ile aynı değil, tamamen farklı bir sebepten kaynaklanıyor. Ama sonuçta test ekibinin Adres Defteri ile ilgili yeni özellikleri görebilecekleri tek ekran, Adres Defteri ekranı. Bu ekranın ana işlevi, Adres Defteri'ndeki kişileri göstermek olduğu için istenen herhangi bir özelliğin %90 ihtimalle adres defterini etkileyeceği malum.
Ben konuyu anlatmak için basit bir ifade yöntemi arıyordum ki buldum. Artık bu şekilde şikayetlerle gelenlere konuyu daha iyi anlamaları için şunu söylüyorum: “Sen uygulamının ateşi olduğunu söylüyorsun; ‘geçen sefer ateşini gidermiştiniz, neden tekrar ateşi çıktı’ diye soruyorsun. Oysa ateş, hastalığın sebebi değil, bir göstergesi. Geçen sefer geliştirdiğimiz uygulama grip olmuştu, onu iyileştirdik ve haliyle ateşi düştü. Şimdi ise idrar yolu enfeksiyonu olmuş ve biz de şu anda idrar yolu enfeksiyonunu gidermeye çalışıyoruz”.
Kaynak: Necati Demir
Yazı için teşekkürler. Elinize sağlık.
Behavior Driven Development tarzında uygulama geliştiriise, eski özellikler de otomatik olarak test edileceği için bu tür ateşi olan noktalar müşteri tarafından değil yazılım ekibi tarafından önceden bulunacaktır. Bu tür hatalar kök sebebi moduler kod yazılmaması olabilir. Yani Ali yazar Veli bozar sendromundan kurtulamak için encapsulation gibi temel prensipleri kod içerisinde uygulamamız gerektiğini düşünüyorum.
Teşekkürler.