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)

This entry was posted on Tuesday, August 7th, 2007 at 1:19 am and is filed under QualiTest, Projeler, Techinox, Yazılım, Genel. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.