developen

Çeşitli yerlerde, birçok kişi ile bir araya gelip sohbetler ediyoruz. Bu sohbetler sırasında, genelde yazılım kalitesi sohbetlerimizin odağını oluşturuyor. Çoğu arkadaşım, kendi yazılım üretim biçimlerine, kalite ile ilgili çözümleri ne şekilde eklemeleri gerektiğini soruyorlar. Zira özellikle test aktiviteleri, diğer yazılım süreçlerine sıkı sıkıya bağlı aktivitelerdir.

Bu tip sorulara genelde yanıt olarak, deneyip gördüğüm ve fikren sayın Spolsky’den aşırdığım bir yanıtı tekrarlıyorum. “İş planı yapın ve güncel tutun. Lakin her koşulda, takvimizdeki işlerin sürelerini saat cinsinden verin. Eğer bir işin alacağı süreyi saat cinsinden veremiyorsanız, daha küçük parçalara bölün.”

Yanıtın bu kadar absürd olmasının sebebi, aslında testin kendi iç dinamiklerinden kaynaklanmakta. Yazılım hataları “Yazılımın tanımlananın dışındaki davranışlarının tümü” olarak tanımlanır. Eğer uygulamanın ne şekilde davranacağını belirlememiş iseniz yada bir şekilde belirlenmemişse, hata bulmanız biraz güçtür. Burada bir şekilde belirlenmiş davranışlardan kastımız, sektör gelenekleri ve hayatın gerçekleri tarafından (bkz: psikoloji) belirlenen “beklenen” davranışlardır.  Örneğin kullanılabilirlik ile ilgili birçok hata bu “genel” pratiklere dayandırılır. Bir formun “Gönder” butonunu formun tepesine koyuyorsanız, bu açıkça tanımlanmasa dahi, bir kullanılabilirlik hatasıdır.

Detaylı bir iş takvimi yapılması ve sürekli olarak bu takvimin güncel tutulması, ekibi uygulamayı tasarlamak konusunda zorlayacaktır. İçeriğini ve detaylarını bilmediğiniz bir yazılım için “saatler ile süreleri belirtilmiş görevler” belirleyemezsiniz. Evet dokümante edilmiş bir tasarımınız olmayacaktır ama en azından üzerinde düşünülmüş bir yazılımı üretiyor olursunuz.

Kaliteli yazılım için işte ilk adım budur.