developen

Yazılım geliştirme süreçlerinde, her bir iş ekibi, çoğunlukla benzer altyapılara sahip kişilerden meydana gelirler. Örneğin sistem analizi konusunda gelişmiş insanlar bir araya gelerek sistem analizi ekiplerini oluştururlar. Benzer altyapılara sahip de olsalar, bu insanların beraberce çalışmaları, ancak yönetim biliminin incelikli detayları yardımıyla birçok sorunun çözülmesiyle sağlanabilir.

Yazılımları ise, bu ekipleri bir araya getirerek üretiriz. Yazılım üretimi ekipler arası bir ekip çalışması olarak adlandırılabilir. Bu yapılanma içerisinde her alt birim kendisi ile ilişkili diğer ekipler ile ortak çalışmak ile yükümlüdür. Tasarımcılar, analistlerin çıktılarını kullanırlar ve ürettikleri ürünler geliştiriciler için çok önemlidir. Geliştirdikleri ürünler test ekiplerince test edilir. Bunun dışında yazılım tasarım ekibi, proje takvimine de uymak konusunda –diğer tüm ekip üyeleri gibi- proje yöneticisine karşı da sorumludurlar.

Test ekipleri ise, müşterilerin, geliştiricilerin, analistlerin, tasarımcıların, proje yöneticilerinin, satış-pazarlama ekibinin, dokümantasyon ekibinin ve belki de muhtemelen ürünün GUI’sinin ne kadar anlaşılır olduğu ile ilgili soru sorduğunuz babanızın da katılımıyla daha da kaotik bir yapılanma içinde çalışırlar.

İşte günümüz dünyasında, yazılım böyle ekiplerle ve bu şartlar altında üretilmektedir. Kullandığınız işletim sistemi, mesajlaşma programı, hata yönetim sistemi ve evinizde kullandığınız tost makinası böyle bir yapılanma ile düşünülmüş, tasarlanmış, geliştirilmiş ve test edilmiştir.

Bunca insanın bir araya gelip “tek” bir şey üretebilmesi için, belirli kabullere ihtiyacımız olacaktır. Bu kabuller uygulama özellikleri, geliştirme yöntemleri, kullanılacak teknolojiler yada toplantı frekansları ile ilgili olabilir. Yazılım geliştirmenin başlaması ile, sistem analist müşterinin ihtiyaçları ile ilgili, satış-pazarlama personeli pazar ile ilgili, tasarımcılar doğru mimari ile ilgili kabullerde bulunurlar. Yazılımın sahip olması gereken kalite seviyesi ile ilgili de kabuller yapılır. Bu kabuller konusunda, tüm ekip içerisinde mutabakata varıldıktan sonra, ürün geliştirilmeye başlanır.

Kurt Gödel’in de dediği gibi her karmaşık sistem kendisi ile çelişmek zorundadır(1). Bu yazılım geliştirme ekipleri içerisinde de yaşanır ne yazık ki. Bir alt ekip için olan doğrular, diğer bir alt ekip için olan doğrular ile çeliştiği anda, kabullerimizi esnetmeye ve kendi şartlarımıza uydurmaya çalışırız. Böylece aynı kabul, ekip içerisineki farklı kişilerde farklı beklentiler yaratmaya başlamıştır.

Sonunda, ürün toplantılarından birinde, yazılımdaki bir anomali ile ilgili ekip arkadaşlarınız ile sesinizi yükselterek tartışırken, ortamda artan testesteron miktarı neticesinde, arada flört etmeyi ihmal etmediğiniz –hangi test mühendisi flört etmeyi sevmez ki?- , güzel pazarlama sorumlunuzun kapıyı çarparak toplantı odasını terk ettiğinde durumun farkına varırsınız.

Lanet olsun!

Durun ve derin bir nefes alın. Eminim anomali konusunda geliştirici ekipten arkadaşınız ile bir orta nokta bulacaksınız. Önceliğimizi böyle durumların tekrar ederek enerjinizi çalmasına izin vermemek yönünde kullanalım.

Şimdi doğru soruları soralım:

İddia ettiğimiz gibi anomali bir hata mıdır?

G.E. Moore, kendi adıyla anılan paradoksunda der ki,

• Bir P olayı olmuş olabilir. Ben bunu biliyor da olabilirim. Ama buna inanabilirim yada inanmayabilirim.
• Bir anda bu iki inanıştan herhangi birini seçebilirim.
• Sadece ve sadece bu inanışın her ikisini birden benimsemek, konu içerisinde beni absürd kılar.

Yani geliştirici arkadaşınız, söz konusu anomali ile ilgili kendi içerisinde tutarlı ama sadece sizinle farklı bir inanışa sahip olabilir. Evet, ekip arkadaşımız saçmalamıyor. Siz ve ekip arkadaşınız kendi içerisinde tutarlısınız.

Peki, arkadaşımız tutarlı olsun. Öyleyse hangi inanış ürettiğimiz yazılıma hizmet eder? Yazılım hatası nasıl tanımlanabilir?

Şimdi doğru yolda olduğumuzu hissediyorum.

“Yazılımın beklenenin dışındaki her türlü davranışı bir hatadır”

Evet, sizin beklentiniz dışında gerçekleşen bu davranış bir anomalidir. Lakin, acaba tüm ekip sizinle aynı kabulu paylaşıyor mu? Eğer bir ortak beklenti mevcut değilse, herkesçe kabul gören hataların mevcudiyetinden söz edilebilir mi?

Test Mühendisi olarak, proje ekibi içerisinde varlığınızın yegane sebebi yazılımın muhtemel hatalar ile çıkma riski ise, “hataların varlığı” sizin için önemli olmalıdır. Başarımınızın anahtar belirleyicisi, herkes tarafından hata olarak kabul görmüş anomalileri saptamak ve düzeltilmeleri için çaba sarfetmek ise, nelerin hata olarak kabul göreceği de sizler için önemli olmalıdır.

Bu sebeple test süreçleri ile ilgili çalışırken, sisteme dair beklentiler noktasındaki kabullerin net, amacına ve proje hedeflerine uygun olduğundan ve tüm ekip tarafından paylaşıldığından emin olun.

Bunun için aşağıdaki kontrol listesini masanızın yanına asmanızı tavsiye ederim.

• Müşterinin ihtiyaçlarını ve beklentilerini, bilmenin ötesinde, hissedebiliyor musunuz? Eğer empati kurabileceğiniz kadar bilgiye sahip değilseniz, muhtemelen projeye başlamak için daha fazla bilgiye sahip olmalısınız.
• Yazılımın ulaşması gereken minimum kalite seviyesi nedir? Bu konuda kantitatif saptama yapabiliyor musunuz? Eğer yanıtınız hayır ise, muhtemelen projeye başlamak için daha fazla bilgiye sahip olmalısınız.
• Söz konusu kalite seviyesi hangi bileşenlerden oluşur? (Ne kadar fonksiyonel başarım? Ne kadar performans? Ne kadar güvenilirlik? …) Eğer bu yanıtı bilmiyorsanız, muhtemelen yazılımın ulaşması gereken minimum kalite seviyesi konusunda net değilsiniz demektir.
• Proje için harcanan ilk 100 adam-saat içerisinde sistemde oluşabilecek hatalar için bir sınıflandırma yaptınız mı? Hangi tip hataların sizin için kritik olduğunu biliyor musunuz? Bu bilgiyi tüm ekip ile paylaştınız mı? Yanıtınız hayır ise, muhtemelen farklı kabuller ile uygulamanın temellerini atmış bulunuyorsunuz ve yazılımın mutlaka bir bölümü ile ilgili yeniden geliştirme yapılacaktır.
• Proje hangi yönde evrimleşiyor farkında mısınız? Müşteri ile en son ne zaman bir araya geldiniz? Söz konusu evrimleşmeden müşteriniz haberdar mı? Yanıtınız hayır ise müşterinizin beklentilerini ve ihtiyaçlarını karşılayamama riskini aldınız, yani “Kalite riskinizi arttırdınız”.
• Acaba ekip içerisinde esnetilen kabuller mevcut mu? Kalite ile ilgili kabuller ve değişen gereksinimlerin etkilerini, ekip ile ürün toplantılarında konuşuyor musunuz? Eğer yanıtınız hayır ise, bu durumda yazılım hataları ile ilgili yakın zamanda “konuşmaya” başlayacaksınız.

Lütfen parçası olduğunuz operasyonun ne kadar karmaşık olduğunu ve ne kadar zor bir aktivite gerçekleştirdiğinizi unutmayın. Yoksa parçası olduğunuz bu kaotik yapı, sizi hiç acımadan içinde öğütecektir. Başarı tekrarlanabildiği sürece başarıdır, diğer durumlarda başarınız iyi şanstan öte değildir ve dolayısıyla denilebilir ki sadece “başarılı” insanlar, her koşul altında “başarırlar”.