Test Uzmanı Derken
Herkese Merhabalar, yazılım test alanında başlattığım bu yazı serimin ilkinde iyi bir test uzmanının sahip olması gereken özellikleri tecrübelerim doğrultusunda sizlere aktarmaya çalışacağım. Yazılım test alanında iyi bir noktaya gelmek için neler yapılmalıdır, hangi özelliklere sahip olunmalıdır? Kariyerime yazılım test alanında devam etmeye karar verdiğimden beri bu soruyu kendime çok soruyorum. Sürekli gelişen yenilikler ile kapsamı değişen ve genişleyen bir meslek grubu içinde olduğumuzu kabullenmeliyiz, bu kötü bir şey mi? Asla. Değişimin olduğu yerde heyecan vardır. Yeter ki biz hevesimizi kaybetmeyelim.
#1 Öncelikleri Anlamak Ve Belirlemek
Biz testçilerin üzerinde uzmanlaşmamız gereken ilk yetenek: Zaman yönetimi. Bu özelliğe sahip değilseniz bile fark etmeden zamanı ustaca kullanmaya başlayıp bu yeteneğe sahip oluyorsunuz. Çünkü mecburuz :) Agile yönetimi olsun, kanban olsun ve hatta isterse waterfall yöntemi ile çalışsın takımınız, teste ayrılan süre her zaman kısıtlı olacaktır. O kısıtlı süreyi test edeceğiniz modül/fonksiyon vs bunlar için öncelikleri doğru belirleyip bir an önce teste başlamanız gerekmektedir.
Hangi senaryoların öncelikli olacağı, hangi kısımların otomatize edilmesinin gerektiği veya manuel olarak kontrol edilmesi gereken tarafları çok hızlı bir şekilde karar vermelisiniz. Mesela gelen işler hangi sıralama ile test edilecektir. Bunların önceliklendirmesini doğru ve hızlı şekilde yaparak teste başlamak elde edeceğimiz sonuç için güzel bir başlangıç noktası olacaktır.
#2 Erken test proje kurtarır
Yeni başlayan projelerde analizler, dökümanlar, incelemeler derken sanki projenin çok vakti olduğu izlemine kapılabiliriz ama ne yazık ki öyle değildir. Projenin en başında gereksinim dökümanları incelenerek testler için bir yol haritası çıkarılmalıdır. Önümüze bir arayüz gelmeden test edebileceğimiz bir çok alan vardır. Bunlara örnek olarak; uygulamanın servis testlerine arayüz kodlaması yapılmadan dahi bakılabilir. Proje bitimine yakın testlerin uzaması gibi bir durum söz konusu olmadığı gibi testin zamanından çalan faktörler olacaktır. Kısaca ne kadar erken test o kadar ruh-beden-proje sağlığı
#3 Doğru Kişiye Doğru Soru
Önünüze test edilmesi gereken bir iş geldiğinde yeterli bir bilgiye veya kapsama sahip olmayabilirsiniz. Gözünüze, aklınıza takılan o ufak pürüzleri sormaktan çekinmeyin. Sizin aklınıza takılan o sorular ürün ortaya çıkınca müşterinin ayağına takılabilir :)
İşin gereksinimlerini, değişikliğin kapsamını, gereksinimlerin nasıl entegre edildiği, ürünün hangi kısımlarını etkilediğini vs. Bu soruları iş analistine veya yazılımcıya sormamız öncelikle işin kapsamını anlamamıza ve dolayısıyla testin kapsamını doğru şekilde belirlememize olanak sağlayacaktır.
İlk zamanlarımda yeni bir modül(özellik) denediğimiz iş vardı, işin kapsamı analist tarafından detaylı şekilde yazılmamıştı, yazılımcı o eksik alanları kendi mantığına göre doldurmuştu, iş teste geldiğinde kullanıcı gözünde bazı alanların eksik olduğunu düşünerek raporlayıp göndermiştim ve yazılımcı o alanları da eklemişti. Ürün demo tanıtımı için müşteri ile toplantı yaptığımızda müşterinin, analistin, yazılımcının ve testçinin(ben) hepimizin farklı şeyler anladığını görmüştük. Kapsam doğru belirlenmemişti ve hiç kimse aklına takılan pürüzler için yardım istememişti.
#4 Verileri Analiz Etme
Test uzmanı olmak demek sadece test yapmak değil, verileri doğru şekilde analiz etmek ve işlemek ile de alakalıdır. Ürün ve yazılım davranışının testi esnasında oluşan yapay ve doğal dataları doğru şekilde değerlendirmemiz gerekmektedir. Ortaya çıkmış bir bug için tekrar edilemez demek doğru değil, bugın ortaya çıkış ortamı için gerekli datalar ve ortam hazırlanmalıdır. Bu süreçte yazılımın performansını araçlar ile dikkatli izlemek yine bu araçların sağlamış olduğu çıktılar ile verileri doğru okuyup hatanın peşine düşmeliyiz
#5 Kötü haberi Güzel Vermek
Kötü haber derken tabi ki ufak buglarımızdan bahsediyorum. İşe ilk başladığım zamanlar bulduğum hataları söylemekten çok çekinirdim, sanki yazılımda ki hatayı değil de yazılımcının karakterinde ki hatayı söylüyor gibi hissederdim. Bu hissi ürün piyasaya çıktıktan hemen sonra en ufak bug için ortalığın alev almasını yaşadıktan sonra aştım. Zamanında raporlanmayan ve müdahale edilmeyen her bug ürün maliyetine çok büyük yükler getiriyordu. Zamanında raporladığım buglar sadece benim işimi iyi yapmam demek değil, yazılımcının gözünden kaçmış tüm noktaları (kapsam yanlış anlaşılmış olabilir, dikkat dağınıklığı anına denk gelmiştir, yanlış modüle entegre edilmiş olabilir) erkenden belirlenip müdahale etmek demekti. Bulunan hatanın yazılımcının karakteriyle hiçbir ilgisi yoktu. Ama yine de rapor sonucunun aktarırken üslup önemliydi.
Test sonucunu aktarırken iyi niyet çerçevesi içinde düzgün bir üslupla söylemek bizlerin görevi olmalıdır. Takım çalışması içindeyiz, birbirimizin morali ve motivasyonu da tüm ekip için çok değerlidir. Yazdığı kodun %0,05lik hatası için herkesin içinde çok büyük bir olay gibi lanse etmek yerine, hatanın detaylı raporunu ve hatayı tekrar oluşturup incelemesi için gereken desteği göstermeliyiz. Bu şekilde dikkat edersek yazılımcıların sevmediği kişi değil, bizden alacağı destek ile güvenle korkmadan kod yazabileceği bir nefes alanı açmış oluruz.
#6 Raporlama Önemli
Tüm gün süren testler sonucunda sayısız koşturduğumuz senaryoların bir çıktısı oldu.(Pass/Fail) Bunun için bir test-case yönetim aracı kullanmış olabilirsiniz. Bu senaryoların ayrıntılı detayını ve statüsünü herkes incelemek istemeyebilir, onun yerine daha kısa ve özet şeklinde bir raporlama sunmanızı beklerler. Gözü yormayan, okuması kolay ve öz cümlelerle gerçekleştirilmiş bir rapor, hepsi bu.
#7 Son Kullanıcı Gözünden Test
Yeni bir özelliği, fonksiyonu test ederken ister istemez göz alışkanlığı oluşmaya başlıyor. İlk gördüğünüzde size yabancı gelen, dikkatli şekilde incelediğiniz arayüz tasarımını test ederken bir süre sonra beyniniz yeşil butona bas, kırmızı uyarı çıkacak biraz bekle işlem tamam gibi bir döngüye alıyor. El-göz alışkanlığı kazandığımız modül için bir süre sonra değişen ayrıntıları fark edemiyoruz. Son kullanıcı ise kıyıda köşede yazılı textleri bile dikkatlice okuyabiliyor. Alfa/Beta testlerinin önemi çok farklı, buna daha sonra değineceğiz fakat bizlerin test sonunda bir nefes alıp, son kullanıcının ayakkabılarını giyip onun gözünden bakmaya çalışmak için kendimizi zorlamamız gerekmektedir. Müşterinin ihtiyaçlarını karşılayamadığımız bir platformda yazılımın fonksiyonalitesi, kullanılabilirliği gibi terimler önemsiz kalıyor.
#8 Sonsuz Öğren – Uygula Döngüsü
Teknoloji sektörünün içindeyiz, bir sabah uyandığınızda yeni bir araç, yeni bir test yöntemi çıkmamış olsun. Dinamiği hiç bitmeyen, sürekli gelişime ve değişime açık olan bir alan yazılım test sektörü. Bunun farkında olup kendimize bu gelişmeleri takip etmek ve uygulamak için bir alan oluşturmalıyız. Takip etmemiz gereken bloglar (https://www.swtestacademy.com/ , http://www.satisfice.com/blog/ ) sunumlarını ve seminerlerini kaçırmamız gereken insanlar (Onur Başkirt, Barış Sarıalioğlu, Alper Mermer, Canberk Akduygu, Ömürden Cengiz…), uyguladıkları yeni teknolojilerle gözümüzden kaçmaması gereken firmalar olmalıdır. Bunların takibini sıkı şekilde yapmak demek yaptığımızın işin kalitesini her gün daha iyi yerlere taşımak demektir. Otomasyona almamız gereken modüller test senaryolarıdır, kendimizi almamalıyız.
#9 Kutunun Dışında Düşün
Test yaparken en çok karşılaştığımız problemlerden biri de yalın düşünce tarzımızın test senaryolarını etkilemesi. Happy Path (olumlu senaryo) için bir senaryo oluşturmak çok kolay olurken, olumsuz olanlar için senaryo yazmak kolay olmuyor. Kullanıcı ne yapabilir, nasıl bir ortamda ürüne erişecek, uygulamayı kullanma alışkanlıkları nelerdir? Düşünce tarzımızın esnek olması ve alışılagelmiş tarzın içinde değil kutunun dışına çıkmamız bize bir çok fayda olarak geri dönüyor. Biz o kutunun içinden çıktığımızda kapsamda belirtilmeyen veya öngörülmeyen bir alanı keşfetmiş oluruz. Kimsenin öngöremediği bu yeni alan için önlemler alınmaya başlanılıyor, hızlı şekilde çözüm üretiliyor ve ürün maliyeti düşürülmüş oluyor.
#10 Mobil test başka bir dünya mı yoksa?
Aplikasyonlara acaba alışık olduğumuz web testinde kullandığımız yaklaşımlar ile düşünebilir miyiz? Donanım değişiyor, ortam, kullanıcı alışkanlıkları derken başka bir dünyaya giriyoruz. Mobilde test yaklaşımı gerektirdiği özellikler ile bizi web testi gibi düşünmemeye en başta itiyor. Mobilin artan kullanımından veya teknolojinin o yönde yoğunlaşmasını hepimiz biliyoruz, kabullendik fakat mobilde test ihtiyaçları Web ortamına göre daha hızlı ve acil olarak artıyor. Mobil ortamdan erişim gösteren son kullanıcı sayısı günden güne artıyor. Mobil test gelişmelerini ve yeniliklerini bırakmamanız gerekiyor.
#11 Takım içinde takım
Eğer bir test takımının bir parçası iseniz çok şanslınız demektir. Yenilikleri denemek, test altyapısı kurmak, data havuzu oluşturmak gibi görevler tek bir test uzmanı için fazla mesai demektir. Çalıştığınız kurum için doğru test altyapısını oluşturmak ve üzerine diğer teknolojileri inşa etmek için yardımlaşabilir, birlikte emek harcayabilirsiniz. Eğer yetkin bir takıma sahip değilseniz dışarıdan destek alabilirsiniz. Temelleri kötü atılmış bir test altyapısında ilerlemenin ne kadar sancılı olduğunu tahmin bile edemezsiniz. Unutmayın destek almak, yardımlaşmak, paylaşmak yetersizlik değildir.
#12 -Kalite, herkesin sorumluluğundadır
En iyisini en sona sakladım – Kalite, herkesin sorumluluğundadır :) Çünkü organizasyonda ki herkes son kullanıcının ve müşterinin isteklerini gözeterek ortaya çıkan ürünün, problemlerini ve ihtiyaçlarını şık ve zahmetsiz bir şekilde çözüme kavuşturmasına yardımcı olmalıdır.
Kendi enerjinize odaklanarak üretmeye çalıştığınız yüksek kalitede ürün için sadece müşterinin memnuniyeti değil aynı zamanda şirketinizin memnuniyetine katkı sağlarsınız. Kalitenin yüksek standartlara sahip olmasının görevini tek kişiye yüklemek doğru değildir, takım içinde yer alan her birey bu sorumluluğa sahip çıkmalı ve kalite odaklı bir efor ile çalışmalıdır. Kalite, sürdürülen bir sürecin sonucu olmalıdır, kazanılmış bir alışkanlık haline gelmelidir.
