Ekiple Neden Uyuşmuyoruz? Test ve Psikoloji.
Merhaba,
Bazı mülakatlarda belki denk gelmişsinizdir “ x’in sahip olması gereken özellikler ne? ” sorusuna. Bizi ilgilendiren ve bu yazıda bahsedeceğim kısım, tabi ki bir QA’in sahip olması gereken özellikler.
Herkesin aklından ben bu role uygun muyum, bugün doğru tepki verebildim mi, kriz anını qa olarak nasıl daha iyi yönetebilirdim gibi sorular sıkça planlı olmasa da istem dışı muhakkak geçiyordur.
Geçenlerde ISTQB (International Software Testing Qualifications Board) Foundation Level dökümanında bir başlık dikkatimi çekti ve bundan bahsetmek istedim:
The Psychology of Testing
Test etme psikolojisinin, en az test teknikleri kadar önemli olmasına karşın sektörde dökümantasyon konusunda test teknikleri kadar önem verilmeyen bir konu olduğunu fark ettim. Bugün “ How To … ” ile başlayan sorulara binbir çeşit sonuç bulabiliyor ve test otomasyonlarımızı rahatça geliştirebiliyoruz aslında. Fakat ben bir qa olarak ekibe nasıl yaklaşım sergilemeliyim, problemlerle nasıl başa çıkmalıyım, ekibi ve iş süreçlerini nasıl iyileştirebilirim, bu role uygun muyum sorularıma net cevaplar bulamıyorum. Açıkçası ISTQB Foundation Level dökümanında bu konudan bahsedilmiş olması beni çok mutlu etti ve dikkatimi çekti. Bu bağlamda öğrendiklerim ve uyguladıklarımdan, doğru-yanlış davranışlardan biraz bahsetmek istedim.
İlk olarak İnsan Psikolojisi Ve Test diyor dökümanda, ve bahsedilenler ufkumu genişletiyor. Psikolojide “doğrulama sapması” diye bir tezden bahsediyor, mevcut görüş ve inançlara uymayan bilgilerin kabul edilmesi kolay değildir diyor. Yani yazılımcılar işi geliştirirken aslında hatasız olmasını bekledikleri için kodun hatalı olduğunu kabul etmelerini zorlaştıran bir doğrulama sapmasına sahiplermiş (vaov). Buna ek olarak, kötü haber veren insanlar genelde suçlanır bilirsiniz, qa’den de genelde hata döndüğü için developerlar hataları kabul etmekte bir miktar daha zorlanabilirmiş.
Bu sebeple, biz qa’lere dikkat ve düzgün iletişim kurma sorumluluğu yükleniyor. Bir qa engineer:
- İş birlikçi olmalı :) developer’a suçlayıcı şekilde değil de, developer’la aynı amaca hizmet etmek adına birlikte çalıştıklarını hissettirebilmeli. Sonuçta hepimizin amacı ilgili işi en iyi şekliyle canlı ortama çıkmak.
- Testin ve yaptığı işin, ürettiği otomasyonun, çıkardığı caselerin faydalarını vurgulamalı. En basitinden manuel işleyen bir test sürecini otomatize etmiş olmak, tüm ekip için zaman tasarrufu sağlar. Erken dönemde bulunan bir hata, developer’a belki de arap saçına dönebilecek kodunu fark ettirip hemen düzenlemesi için olanak sağlar.
- Güzel bir dil kullanmalı ve eleştiriden olabildiğince uzak durmalı. Bir hata bulduğumuzda “yuh, bu da nasıl hata” şeklinde yaklaşımlar sergilemek bu minvalde çok kırıcı ve yanlış bir davranış olur.
- Developer’ı anlamaya çalışmalı, ve anladığını hissettirebilmeli, empati yapabilmeli. Kendini anlaşılmış hisseden developer da artık qa’in dediklerini anlamak için hazır olur.
İkinci olarak da Test Uzmanlarının Ve Yazılımcıların Düşünme Tarzı diyor dökümanda. Developer ve qa farklı düşünür diyor. Yani developer iş geliştirmekten ve üretmekten sorumludur. QA ise hata bulmaktan, kullanıcıya gereksinimleri karşılayan bir ürün sunabiliyor muyuz sağlamasını yapmaktan sorumludur. Farklı işler ve sorumluluklar, beraberinde farklı düşünce tarzlarını getiriyor. Bu düşünce tarzlarını bir araya getirdiğimizde ise, ürünümüzün kalitesi oldukça artıyor.
Bir QA’in düşünce tarzı:
Merak
Profesyonel karamsarlık :)
Eleştirel bir bakış açısı
Ayrıntılara dikkat
İyi ve pozitif iletişim
İlişkiler için motivasyon
içermelidir. Bunun yanında bir developer ise genellikle çözümler tasarlamak ve oluşturmakla ilgilenir. Neyin yanlış olabileceğini düşünmez ve yukarda bahsettiğimiz doğrulama sapması da hata bulmasını zorlaştırır. Burada aslında developer yazdığı kodun anasıdır, babasıdır diyebiliriz; kimse kendi bebeğinde kolay kolay hata bulmaz :)
Eğer doğru düşünce tarzına evrilirse, yazılımcı kendi kodunu test edebilir. Burda da unit(birim) test yazması, hatta işleri TDD prensibine göre geliştirmesi bir developer’ın düşünce tarzının test için ne kadar olgunlaştığını, ve doğrulama sapmasını ne kadar törpüleyebildiğini gösterir :)
Özetlemek gerekirse; test rolleri bence kesinlikle severek yapılabilecek, sevmeyen birinin rahatça yapamayacağı, mutlu olmayacağı roller. Gerçekten meraklı, hata bulma bakış açısına sahip ve bunların yanında da iyi iletişim kurabilen, motivasyonu yüksek kişiler test rolleri için en uygun kişiler. İyi iletişim kuramayan qa’ler genel gözlemim developer’dan da saygı duymuyor ve bu sorun çığ gibi büyüyor. Genelde ekibin dinamiğini belirleyen, ekibi çekip çeviren de qa’in bu özellikleri oluyor. Bu yüzden yukardaki maddeleri sindirip, iş yapış şeklimizde uygulamaya başlamalıyız diye düşünüyorum :)
Umarım hoşunuza giden bir yazı olmuştur. Yorumlarınızı bekliyorum. Bu arada yazıyı beğendiyseniz alkış ile beni haberdar edebilirsiniz.
