Benim yaptığımı eleştirme!

Yaşamın her alanında olduğu gibi, yazılım geliştirme dünyasında da kişisel olarak çoğu kişi tarafından sevilmeyen bir şey varsa, o da üretimini yaptığınız ya da üretilmesine katkıda bulunduğunuz bir şeyin negatif olarak eleştirilmesi, işlemeyecek ya da hatalı yönlerinin gösterilmesidir. Bu da ne yazık ki, yaklaşık 150 – 200 bin yıl kadar önce, evrimleşerek konuşmaya geçişimiz ile başlayan1 ve o zamanların öncesinden bu yana gelişmekte olan “sürüngen beynimizin” köşelerine kadar işlenmiş bir korunma güdüsü sanırım. Genelde, yapmak istediklerimizin, bu isteklerimizi gerçekleştirirken seçtiğimiz yolların ya da sonuca ulaşıp da yaptıklarımızın eleştirilmesine ya da yanlışlanmasına pek katlanabilir ve bunları olgunlukla karşılayabilir bir tür değiliz düşüncesindeyim. Bunu yapabilen ve mantıklı argümanlar ile desteklenen negatif eleştirileri olgunlukla karşılayabilen kişilerin hem profesyonel hem de kişisel yaşamlarında daha başarılı olduklarına inanıyorum.

Toplum ya da ekibimizdeki bir kişi, yaptığımız bir şeyi yanlış, istenildiği gibi olmayan ya da -daha da ağır tabiri ile- kötü yaptığımızı söylediğinde ilk tepkimiz, istemsiz de olsa, bu kişiye karşı savunma duvarını örmemiz oluyor genelde. Bu savunma duvarını örmeyen kişiler ise, negatif eleştiriye ve kendisini geliştirmeye açık olan insanlar olarak, içinde bulunduğu toplum ya da ekipten sıyrılabiliyor. Bir üretimin ya da yapılan işi “kötü” olarak nitelendirilmenin “yıkıcı”, “yok edici”, “haksızlık”, “mutsuzluk yaratan” bir şeymiş gibi görülmesinin haksızlık olduğunu, negatif eleştiride bulunan kişinin de her zaman “kötücül” olarak adlandırılmasının ise, modern insana hakaret olduğunu düşünüyorum.

Tanımlar ve Taraflar

Dört yazıdan oluşan bir seri şeklinde yazmayı düşündüğüm “Yazılımın Karanlık Tarafı” yazılarında, yazının başlığını da esinlendiğim Star Wars evrenindeki “karanlık taraf / aydınlık taraf” kavramlarına gönderme yapacağım. Yazı(lar)daki görüşler, deney veya verilere bağlı rasyonel yöntemlerin çıkarımları yerine daha çok benim kişisel gözlemlerimi ve görüşlerimi kapsayacak şekilde olacak. Yazı(lar)da bahsi geçecek olan negatif eleştiri tanımının, bir veriye dayalı ve mantıklı açıklamaları olan eleştiriler olduğunu da varsayacağım. Oluşturulan herhangi bir üretim için, sırf laf olsun diye yapılan “olmamış ki bu” ya da “x daha iyisini yaptı zaten” tarzı tüm eleştirileri sadece “kötüleme” olarak görüyorum.

Aydınlık olarak görülen taraf, yazılımın üretilmesi, projenin ya da uygulamanın ‘ne olursa olsun’ ilerlemesi için çaba gösteren taraf; “karanlık” olarak görülen taraf ise, projedeki ya da uygulamadaki eksikliklere, aksiliklere veya hatalara dikkat çeken ve pek de sevilmeyen taraf olacak. Anlayacağımız teknik dilde yazarsak, “aydınlık taraf” yazılım geliştirici, proje yöneticisi ve yönetim kadrosunu temsil ederken, “karanlık taraf” ise yazılımları test eden ve hataları engellemeye / bulmaya çalışan test mühendislerini ve test uzmanlarını temsil edecek.

Bir ürünün kaliteli bir şekilde üretilebilmesinin en iyi yolunun, optimum derecede test edilmesinden ve test sonuçlarının ciddiye alınıp düzeltmelerin de buna uygun şekilde yapılmasından geçtiğini bilecek kadar deneyim sahibiyim. Yazılım dünyasının “karanlık tarafı” ve kötü çocukları olarak görülen test uzmanlığı konusunda yerim kesinlikle belli.

Aydınlık taraf ne istiyor?

Bir yazılım projesini yürüten ekip ya da şirket içinde test konusunda yeterli bir olgunluk olup olmadığını, aşağıdaki durumları gözlemleyerek anlayabiliriz:

  1. Ürünün ya da uygulamanın test edilmesi, proje teslimine çok yakın bir süre kalmışken başlıyor,
  2. Proje yöneticisi ve / veya üst yönetim, test sürelerini de düşünerek bir proje takvimi oluşturmuyor,
  3. Tüm testlerin geliştirici tarafından yapılmış olması bekleniyor,
  4. Ekip dahilinde, test işine ayrılmış uzman bir test mühendisi bulunmuyor,
  5. Yazılım testi denildiğinde sadece “birim testi” ya da “son kullanıcı testi” anlaşılıyor
  6. Ekipte varsa, test uzmanı tarafından bulunan her “bug”, kayıt altına alınmak yerine, direkt geliştiriciye bildiriliyor,
  7. Test edilecek uygulamanın istekleri net olarak anlaşılabilmiş değil,
  8. Geliştirme, test ve canlı ortam ayrımı bulunmuyor,
  9. Test için kullanılacak veriler ve veri setleri ayrıştırılmış değil,
  10. Geliştiricilerin maaşlarını belirleyen performans kriterlerinde, yazdıkları modül ya da uygulamalarda bulunan “bug” sayıları da var,
  11. Ürün ya da uygulama piyasaya çıktıktan sonra müşteriden ya da kullanıcıdan gelen ilk hata bildiriminde, suçlu kişi ya da birim “testçiler” olarak seçiliyor.

Adı Türkiye’de sosyal medya kullanıcıları tarafından malum olan, çokça ziyaretçi çeken bir içerik derleme ve başkalarından kopyalayıp yayma sitesinin yaptığı kişilik testleri gibi olacak belki ama, yukarıda ilk anda aklıma gelen on bir maddenin en azından ikisine “evet” cevabı verdiyseniz, ekibinizde ya da şirketinizde test ve yazılım kalitesine gerekli önem verilmiyor demektir.

Aydınlık olarak görülen taraf (yani yazılımcılar, geliştiriciler, proje yöneticileri ve üst yönetim) sırf geçmişten bu yana gelen alışkanlıklarından ve genelde de rahatlarının bozulmasından duydukları endişe yüzünden, bu maddelerdeki önerilerin tümünün aynı anda uygulanamaz ve piyasa gerçekleri ile uyumsuz olduklarından şikayet etmekte. Proje yöneticileri “zaman” konusunda şikayetçiyken, şirket yönetimi “bütçe” konusuna dikkat çekmekte, geliştiriciler ise ilk girişte belirtmeye çalıştığım “eleştirilemezlik” veya sonrasında bahsi geçen “performans hedefi” konularında direnç göstermekteler.

Star Wars evrenindeki “aydınlık tarafı” tekrar düşünün. Master Yoda’yı, Obi-Wan Kenobi’yi ve Jedi konseyini hatırlayın. Bağnazlığa kaçan tutuculukları yüzünden ilerlemeleri olduğu gibi göremeyip, kendilerinin söylemlerini sorgulayan her fikri susturma amacı ile uzun süre hüküm kurmuşlardı. Aydınlık taraf, eleştirilmekten ve rahatlarının bozulmasından çekinir ve korkar. Test edilmek, teste tabi tutulmak da rahat kaçıran acımasız bir süreçtir. Bu yüzden karanlık olarak görülür. İnsan, bilmediği şeylerin gizlendiğini düşündüğü karanlıktan korkar ve uzak durmaya çalışır.

Karanlık taraf ne istiyor?

Yazılım dünyasında uzun süre karanlık taraf olarak görülen test mühendisleri, uygulamanın ana hedefini “kalite” olarak belirlemişlerdir. İşini iyi yapan yazılım test mühendisleri, yapıcı, geliştirici, binaya tuğla koyan kişi olmak yerine, konulan her tuğlanın standartlara ve ev sahibinin isteğine ne kadar uyduğunu milimetre ölçüsünde kontrol etmek ve sorunlu kısımları bildirip, bu sorun giderilinceye kadar işin peşinden koşmak ile sorumludurlar. Yazılım konusu geçen her yerde hırsla ve öncelikle kaliteyi savunan kişilerdir. Aşağıdaki özelliklere sahip bir test mühendisi ekibinizde varsa, bahsi geçen ve devamlı kötülenen karanlık tarafın en iyi neferlerinden birisidir:

  1. Karşılaştığı hataları ya da eksiklikleri müşteri ihtiyaçları ve uygulama içi dengelere uygun olarak önem derecelerine ayırabilen,
  2. Farkına vardığı hataları nesnel verilere dayandırıp gerekçelendirebilen,
  3. Taahhütte bulunup, bu sözlerini yerine getirebilen,
  4. İnsan ilişkilerinde çok iyi olan ve derdini anlatabilip, karşı tarafı objektif olarak dinleyebilen,
  5. Testlerini yapabilmek için gerekli kaynak ve zaman planlamasını iyi yapabilen,
  6. Her bulduğu hatayı detaylı olarak raporlayabilen,
  7. Bir yazılımın üretim sürecine en başından itibaren katılmak için ısrarcı olan,
  8. Yazılım kalitesi anlamında bir ürünün “iç kalite” ve “dış kalitesinin” ayrımının farkında olup, yapacağı testleri buna göre planlayabilen,
  9. Yazılım kalitesinde literatürü iyi takip edip, standartları içselleştirmiş ve uygulayabilen,
  10. Yazılım ürünü kalite modelini2 çok iyi bilen ve ekibine de bu standartlar çerçevesinde bir test süreci uygulanması yönünde baskı kurabilen,
  11. Negatif ya da pozitif, veriye dayalı nesnel eleştiriye tamamen açık, duygularını işe karıştırmayan.

Yazı dizisinin bundan sonraki bölümlerinde, korktuğumuz ve kötü bildiğimiz karanlık tarafa hizmet eden kişilerin, neden o görevler için çok uygun olduklarını yazmaya çalışacağım. Umarım verdiğim sözü tutabilir ve önümüzdeki zamanlarda tamamlayabilirim.

Kaynaklar:

1: Mcneill, David. (2010). How Language Began: Gesture and Speech in Human Evolution. 81-82. 10.1017/CBO9781139108669.

2: ISO/IEC 25010:2011 / Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models

3: Kullanılan fotoğraf: Tommy van Kessel 🤙 / Unsplash

aydınlık taraf darkside kalite karanlık taraf lightside quality starwars testing