Neredeydim, ne oldu?

2018 Mayıs ayında, uzun yıllardır arkadaşım olan ve her yıl gösterime giren yeni nesil Star Wars filmlerinin geceleri yapılan ilk gösterimini beraber izlediğim sevgili Barış Sarıalioğlu ile birlikte bir hayali gerçekleştirmek için adım attık. Bu oldu. Emekliliğimi alacağımı düşündüğüm ve bu yola da baş koyduğum TesterYou isimli firmanın bir neferiyim ben artık. Tüm gecem ve gündüzüm sadece burada. Genelde tüm yazılım yaşam döngüsündeki süreçlere, özelde ise yazılım test süreçlerine danışmanlık ve eğitmenlik yaptığımız bir oluşum kurduk. Çok güzel oldu. Daha da güzel olacak.

Hem bu işin getirdiği yeni öğrenmeler, hem de alışkanlığımdan dolayı yaptığım okumalar ve araştırmalarda, karşılaştığım şey tekrar şu oldu. Yazılım dünyasının kalite anlamında çok fazla eksiği var ve bu eksikliklerin ana unsuru da, bu geliştirmeyi yapan bizler ve bizlerin sahip olduğu rasyonel olmayan tutum ve tavırlarımız. Evrimimiz bizleri bu güne kadar getirdi ve en azından dünyaya hükmeden “en zeki” canlı türü olarak sağ kalabildik. Gelişen teknolojiyi yarattık, kullanır hale geldik ve geliştirmeye de devam ediyoruz. Bakılan açılara göre “çok şanslı bir çağda” ya da “tamamen şanssız bir çağda” yaşıyoruz. Yazılım yaşam döngüsündeki kişiler olarak (analistinden son kullanıcısına, geliştiricisinden proje yöneticisine, ‘creative ajans görevlisinden’ CTO’suna kadar herkes bu döngüde diye düşünelim), bu geliştirmelere ayak uydurmaya çalışıyor, işimizi ‘en iyi şekilde’ yapmaya çalışıyoruz. Ama hala bir şeyler tam da olması gerektiği gibi olmuyor. Bunun sebebi sadece süreçte kurallar olmaması, kurallara uymamak, araç eksikliği olamaz diye düşünüyorum. Yazılım geliştirme işinde her ne kadar “sayısal” iş yapılsa da,  insan dediğimiz canlı türü, savanada canlı kalmak için 200.000 yıldır geliştirdiği beyinsel becerilerin etkisi altında hala. Bu etkilerin izlerinin yazılım dünyasında ne kadar etkili olduğunu merak ettiğimden, altta yatan “insan faktörü” konusunda daha fazla araştırma yapmaya karar verdim. Bazı bulgularımı İngilizce olarak şirketimizin sitesinde bir blog post olarak yayınladım. Bu yazı da, hem onun Türkçeleştirilmiş hem de daha kişiselleştirilmiş hali olacak. Başlayalım bakalım…

Yazılım Kalitesi

Yıllar içinde, yazılımın kalitesinin ve doğru çalışmasının onaylanması sayılan testler, sadece son dakikada “bug” bulup bunları raporlamaktan, “hata meydana gelmeden önce önleme”ye doğru evrilmiş durumda. Bunda, yoğunlukla kullanılan “Waterfall” proje yönetim metodolojisinden “Agile” yönetim süreçlerine geçişin de etkisi çok büyük. Hala tersini yapan bir çok yazılım evi/birimi de var ama, gelişme gözle görülür bir şekilde iyi yönde.  Yazılım geliştirme yaşam döngüsünün (SDLC¹) analiz gibi ilk safhalarında başlayan testler, hem kalitenin artmasını sağlamakta, hem de ürünün piyasa başarısızlığını engelleyecek adımları atmaya yardımcı olmakta. Yazılım yaşam döngüsü içindeki hemen herkes (analistler, geliştiriciler, proje yöneticilerileri, test uzmanları ve üst düzey yöneticiler), testlerin, henüz geliştirme bile başlamadan önceki zamanlarda başlaması konusunda hemfikir.

İlk zamanlarda daha çok manuel olarak yapılan testler, gelişen teknoloji ile birlikte onlarca araç tarafından desteklenir hale gelmiş, otomasyon araçları ile iş yükünden tasarruf edilmiş, süreç iyileştirmeleri ile daha güvenilir düzeye getirilmeye çalışılmıştır. Artık geliştiriciler, “test” konusunda daha eğitimli ve bilinçli, ürün yöneticileri (ve proje yöneticileri) test etmenin önemini önceye göre daha iyi kavramış durumda. Tüm bu gelişmeler karşısında ise hala bir gerçek var: Ürün, kullanıcı kabul testine(UAT²) geldiğinde ya da daha da kötüsü piyasa çıktıktan sonra onlarca bug barındırmakta ve ürün ve üretici şirket imajı da bu durumdan çok kötü etkilenmekte. İki soru hala aktif olarak şirketin koridorlarında dolaşmakta: Neden böyle oldu ve bu kimin suçu?

Akıllı olan ekipler, böyle bir durumda kendi test süreçlerini kontrol eder, hangi noktada ne tür eksiklikleri olduğunu anlamaya çalışır, performans ya da otomasyona yönelik test araçlarını kullanılıyorlarsa da, o araçları kalibre eder, tüm bunlara bağlı olarak da belki ekip üyelerine daha fazla eğitim verme yönünde seçim yapar. Daha da akıllı hareket eden ekip üyeleri ise bunların tümünün üstüne bir de kendi içlerine, o bizi onbinlerce yıl hayatta tutmuş olan beyinsel işleyişlerimize bakar: Bilişsel önyargılarımız!

Bilişsel Önyargı

Vikipedi Türkçe sayfası (evet, 2019 yılında sadece VPN ile girilebiliyor hala), bilişsel önyargıyı, “diğer insanlar ve durumlar hakkında mantıksız olabilecek çıkarım sapmaları için kullanılan bir kalıptır. Bireyler ellerindeki mevcut girdiler neticesinde kendi nesnel sosyal gerçekliklerini yaratırlar. Öznel girdi yerine, bir bireyin kendi yarattığı sosyal gerçeklik inşası sosyal dünyadaki davranışlarını da dikte edebilir. Böylece, bilişsel eğilimler bazen algısal bozulma, yanlış yargı, mantıksız yorumlama ya da geniş anlamıyla mantıksızlığa (irrasyonalite) yol açabilir.” olarak tanımlamakta. Uzun lafın kısası: “kendi bilinciniz ile oluşturduğunuz önyargılar, sizlerin mantıklı davranışlarınızı kısıtlayabiliyor ve yanlış eğilimlerde bulunabiliyorsunuz“. Ya da bu süslü cümleleri “anneye anlatır gibi” anlatmak istersek; “her birimiz, insan beyninin işleyişi yüzünden, mantıksız ve farkında olmadığımız davranışlar içinde bulunabiliyoruz“.

Eğer bu son cümleye karşı çıkıyorsanız size bir sürprizim var. Buna karşı çıkıyor olmanızın sebebi, “yanılgı kör noktası” (bias blind spot) denilen bilişsel önyargınızdan kaynaklanıyor olabilir. Başkalarının önyargılı davranışlarını, kendi davranışlarımıza göre çok daha hızlı görebilme kusurudur belki de.

Yazılımın testi benim gözümde hem bir sanat hem de bilim olan bir meslektir; temel olarak yazılım özellikleriyle ilgili seçimleri yapma, seçimleri gözden geçirme, değerlendirme ve sonuç çıkarma üzerine oluşan bir meslek. Yazılım testi mesleği ayrıca testleri oluşturma, uygulama ve test sonuçlarının analizi aşamaları boyunca bilişsel önyargıya çok fazla maruz kalmaktadır.

Yazılım test süreçlerini, testleri ve kalite ekiplerini etkileyebilecek birçok bilişsel önyargı türü olduğunu düşünüyorum. Bu konuda yapılacak araştırmaların hem yazılım hem de yazılımcıların kalitesini olumlu ölçüde değiştireceğine inanıyorum. Ben küçük bir katkı olarak, yeni işimizdeki danışmanlık hizmetlerimiz sırasında karşılaştığımız ikisini yazının devamında özetlemeye çalıştım.

1. Doğrulama Yanlılığı (Confirmation Bias)

Tanım: Doğrulama yanlılığı ya da teyit yanlılığı, kişilerin kendi inançlarını, düşüncelerini ve varsayımlarını destekleyen ya da teyit eden bilgileri kayırma, dikkate alma ve öne çıkarma eğilimidir. Bu yanlılığa sahip kişiler inançlarına, düşüncelerine ve varsayımlarına ters düşen, karşı duran, onlarla çelişen bilgileri ihmal etme, yok sayma eğilimi gösterir.

Genelde oluşturulan test senaryolarının “Pozitif Testler” üzerinden gitmesine yol açtığını görüyoruz. Yazılan test senaryoları çoğunlukla, yazılmış olan “analiz” ya da “gereksinim” dokümanlarına bağlı olduğu ve analiz dokümanları da çoğunlukla pozitif ifadeler içerdiği için -doğal olarak- sistemin “ne yapması gerektiğine” daha çok odaklanıyoruz. Pozitif test bizim aklımızdaki senaryoyu da doğrular nitelikte olacağı için, test için kullandığımız verileri bile “doğru sonuç vermesi” için değiştirebiliyoruz.

Bir konuda geçmiş deneyimlerimiz doğrultusunda fikrimizin ve belirli bir örgüdeki “bakış açımızın” olmaması neredeyse imkansız. Bunu yazılım testleri sırasında kendi dünya görüşümüze ve bakış açımıza uygun arayışlar ile yapıyoruz. Hesap makinesi yazılımını düşünün. Gereksinim dokümanında, ekrandaki iki alana girilen rakamların toplanılarak bir “label”‘da sonucun gösterilmesi gerektiği yazıyor diyelim. İki tane textbox var ve biz doğal olarak gidip oraya “nümerik değer” yazıyoruz. Çünkü zihnimiz yıllarca, hesaplamanın rakamlar üzerinden yapıldığını öğrenmiş durumda. Rakamları girip de sonuca baktığımızda ve doğru toplama yapıldığını görünce de testten geçmiş olduğunu varsayıyoruz.

Benzer şekilde, gereksinim dokümanındaki “şifrenin en az 8 karakter olmalıdır” isteği için, test senaryosuna “şifrenin en az 8 karakterli olması gerektiğini” test edecek adımı koyuyoruz ve “olması gerekeni doğruluyoruz. Peki ya en fazla kaç karakter koyabiliyoruz? Veri tabanı oraya 1024 karakter eklesek de izin verecek mi?

2. Sürü Psikolojisi (Bandwagon Effect)

Tanım: Bir yığın kurallar ve koşullar dizisiyle temellenmiş belirli inançların, bir grup, topluluk, ülke vs.’nin (siz bunu IT ekibi ya da agile ekip olarak da düşünün) insanları arasında yayılmasına verilen addır.

Ortak tutuma başvurma safsatası ile de ilişkili olan bu kolaycılık görüşümüz, genelde ekiplerin içindeki otoriter ve yetkin kişilerin fikirlerinin ekip içinde kabul görmesi ve yaygınlaşması ile kendini ortaya çıkardığını gözlemledim. Sprint planlama toplantılarınızdaki “Story Point”‘lerin belirlenmesini düşünebilirsiniz. Ekip içinde yeniyseniz, ne kadar bilgili ve tecrübeli olduğumuza bakmaksızın baskın görüşe doğru yönleniyoruz. “Büyük çoğunluk bu şekilde düşünüyorsa, büyük ihtimalle ben yanılıyorumdur” gibi davranıyor beynimiz. Bu da yanlış bile olsa bazı kararlara katılımımızı sağlıyor.

Benzer şekilde, ekip içinde bir modülün / fonksiyonun hata çıkarmayacağına dair yaygın bir inanış varsa bu modül üzerinde yazılan ya da koşulan test sayısı da düşmekte. Bulunan hatalar bile, baskın inanış bunun aksini söylediği için, kimi zaman göz ardı edilebilmekte (yine, “büyük ihtimalle ben yanlış bir şey yaptım” görüşü baskın geliyor test eden kişiye).

Test uzmanı bir arkadaşta gördüğüm bir davranış biçimi de şu şekilde oldu. Bir ekipte yeni olan test uzmanı, grup içinde kabul edilebilirliliğini arttırmak için, kendisine “bunu bug olarak raporlama, ben hallederim” şeklindeki telkinlere uymaya başlayıp, aslında yazılımın kalitesinden ve ekip içindeki test olgunluğunun yükselmesinden taviz verdi. Ekibin performans ölçüm kriterlerinden birisini “bulunan bug sayısı” olarak koymak, bu türden yanlışlıklara da yol açabiliyor.

Özet

Bilim insanlarına, araştırmacılara ve psikologlara göre karar verme sürecini kendimiz için kolaylaştıran, bizlerin günlük yaşamını etkileyen düzinelerce önyargı var. Bu önyargıların çoğu inanç oluşumunu, ticari ve ekonomik kararları ve genel olarak insan davranışını etkilemekte. Test uzmanları ve kalite ekibi üyeleri olarak, bu önyargıların üstesinden gelmenin kolay bir yolu da yok. Ne de olsa hepimiz insanız, robot değil. Yapabileceğimiz şey, bu önyargıları bilmek ve kabul etmek, irrasyonel davranışların sonuçları hakkında açık fikirli olmak ve şartların gerektirdiği şekilde değişiklik yapmaya istekli olmaktır.

Kısaltmalar, tanımlar

1. SDLC: Software Development Life Cycle, Yazılım Geliştirme Yaşam Döngüsü. Yazılımın, istek oluşma anından başlayıp, analiz, geliştirme, test ve piyasaya sürülmesi süreçlerinin tamamını kapsayan döngü.
2. UAT: User Acceptance Test, Kullanıcı Kabul Testi. Özne olarak yazılımdaki gereksinimleri ve istekleri belirleyen kişilerin geliştirici ekip ile birlikte yaptığı testler.
3. Test senaryosu: Uygulama parçasının doğru çalışması ve istenilenleri doğru yaptığının görülmesi için yazılan adımların ve her adım için beklenen çıktıların tutulduğu şablon.

Yararlanılan Kaynaklar

1. Yalansavar Web Sitesi (http://www.yalansavar.org)
2. Şebnem Özdemir, Buster Benson’un “Cognitive Bias Cheat Sheet” çevirisi (https://medium.com/@behavioralist/buster-bensonun-cognitive-bias-cheat-sheet-t%C3%BCrk%C3%A7e-versiyonu-22baf8e0a5)
3. 18 Cognitive Biases You Can Use for Conversion Optimization. Shanelle Mullin, October 15, 2015. (https://conversionxl.com/blog/cognitive-biases-in-cro/)
4. Wikipedia, List of cognitive biases yazısı, (https://en.wikipedia.org/wiki/List_of_cognitive_biases)
5. Fuqun Huang (June 21st, 2017). Human Error Analysis in Software Engineering, Theory and Application on Cognitive Factors and Risk Management, Fabio De Felice and Antonella Petrillo, IntechOpen, DOI: 10.5772/intechopen.68392. (https://www.intechopen.com/books/theory-and-application-on-cognitive-factors-and-risk-management-new-trends-and-procedures/human-error-analysis-in-software-engineering)
6. Oswald, Margit E.; Grosjean, Stefan (2004). “Confirmation Bias”. In Pohl, Rüdiger F. Cognitive Illusions: A Handbook on Fallacies and Biases in Thinking, Judgement and Memory. Hove, UK: Psychology Press. pp. 79–96. ISBN 978-1-84169-351-4. OCLC 55124398.
7. Kullanılan fotoğraf: Leonard von Bibra on Unsplash

The post Yazılım testlerinde bilişsel önyargılar appeared first on mirmirik.net.

Kovboy tarzı yazılımcı olmanın ve bu şekilde yazılım geliştirmenin kötü taraflarından üzerine sıklıkla bastırdıklarım özetle şunlar:

• Tek kişi kalmak, yalnız olmak
• Ekibe güvenmemek
• Test ya da dokümantasyona zaman ayırmamak
• Bilginin tek elde toplanması
• İşlerin gün geçtikçe yığılması
• Yığılmadan dolayı işlerde gecikmeler ve bug çıkması
• Bug-fix yapacak ya da işleri yetiştirecek kişinin aynı kişi olması
• [infinite loop]

Tüm bunları bir kovboy yazılımcı ile konuşursanız, size, kendisine zamansız ve eksik dokümante edilmiş istekler geldiğinden, isteklerin bilgisizce hazırlandığından, zaten sistemin ayakta kalmasının tek sorumlusunun kendisi olduğundan, ekipteki daha junior seviyedekilere işin nasıl yapılacağını anlatmaktansa kendisinin yapmasının çok daha hızlı olduğundan bahsedecektir. Kendisinin çevik metodolojiler için yanıp tutuştuğundan, yazılım geliştirme döngüsünde herhangi bir çevik yazılım geliştirme metodolojisi uygulanıyor olsa herşeyin güllük gülistanlık olacağından, ancak süregiden şirket politikası ve işlerin kritikliği sebebiyle bunun uygulanamayacağından da söz edecektir.

Bu durumda kendisine çevik metodolojilerin prensiplerini tekrar hatırlatmakta fayda var:

• En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.
• Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir. Çevik süreçler değişimi müşterinin rekabet avantajı için kullanır.
• Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunulmalıdır.
• İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.
• Projelerin temelinde motive olmuş bireyler yer almalıdır. Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi başaracakları konusunda güven duyulmalıdır.
• Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüzyüze iletişimdir.
• Çalışan yazılım ilerlemenin birincil öçüsüdür.
• Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir. Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.
• Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.
• Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.
• En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.
• Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.

Prensiplerde önemle tekrarlanan bir nokta var. Takım / ekip / birlikte çalışmak / takım oyuncusu olmak. Takım oyuncusu olmanın şartlarından birisi de aslında bilgi paylaşımının ve şeffaflığın arttırılması. Bilgi paylaşımında bulunmak ve şeffaflığı arttırmak için ise asıl yapılması gerekenin -kişisel deneyimlerden yola çıkarak- “profesyonel ego”dan kurtulmak olduğuna inanıyorum.

Egosunu yenebilmiş teknik bir kişinin, ekip ile birlikte daha çok büyüyeceğine ve hep hayalindeki rahat çalışma ortamına kavuşacağına dair inancım yüksek. Ego nasıl yok edilir konusu ise daha çok psikoloji ve sosyoloji alanlarının konusu. Hala kişisel hayatımda yüksek olduğuna inansam da, benim iş konusundaki egomu zayıflatmam şunları sağladı:

• Şirket içi bilgi paylaşımıma daha fazla zaman ayırdım,
• Ekibe yeni katılmış ya da daha önceden ekip içinde varolan arkadaşların teknik bilgilerini yükseltmek için çabalar oldum,
• Ekipteki arkadaşlarımın kendilerine güvenleri yükseldi,
• Üzerimdeki işleri dağıtabilmeyi başardım,
• Üretime aldığımız kodlarda çok daha az hata çıkmaya başladı,
• Müşterilerimizde şirketimize ve ekibimize karşı güven yükseldi ve zaman zaman yaptığımız hataların tolere edilmesi kolaylaştı
• Mesai sonrası boş zamanım oldu,
• Sosyal hayata daha çok zaman ayırabildim,
• Geceleri, aklımda o günkü ya da yarınki proje ile ilgili daha az endişe duydum ve daha rahat uyuyabildim.

Uzun lafın kısası, kovboy yazılımcı olmanın o iç daraltıcı dünyasından, ilk etapta egonuzu arkanızda bırakarak ve bu sayede takım oyuncusu olma yoluna adım atarak sıyrılabilirsiniz. Emin olun her şeyin en iyisini siz bilmiyorsunuz ve aslında vazgeçilmez değilsiniz.

Not: Yazıdaki fotoğraf, bir zamanlar kovboy filmlerinde oynayan ancak daha sonra ABD başkanlığına soyunan Ronald Reagan‘a ait.

The post Kovboyluktan vazgeçip takım oyuncusu olmak appeared first on mirmirik.net.