En son yazılımcı maskemi çıkarıp yönetici olmak konusunda ahkam kesiyordum. Ne oldu da bu kadar ara verdim, sonra da araya böyle “ağır ve ciddi görünümlü bir konu olan bilişsel önyargıyı öne aldım” konusunda kısa iki paragraf ekleyeyim, devamında asıl konumuza döneriz.
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 (SDLC1) 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(UAT2) 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
- 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ü.
- 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.
- 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
- Yalansavar Web Sitesi (http://www.yalansavar.org)
- Ş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)
- 18 Cognitive Biases You Can Use for Conversion Optimization. Shanelle Mullin, October 15, 2015. (https://conversionxl.com/blog/cognitive-biases-in-cro/)
- Wikipedia, List of cognitive biases yazısı, (https://en.wikipedia.org/wiki/List_of_cognitive_biases)
- 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)
- 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.
- Kullanılan fotoğraf: Leonard von Bibra on Unsplash