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. 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”.

(Bu yazı ayrıca yazarın kendi blog sitesinde de yayınlanmaktadır)