Home›Test›Yazılım Testlerinde Hedef Neden Önemlidir ? Nasıl Belirlenir ?
Test İçeriğinin Test Stratejisinin Belirlenmesine Etkileri
Hiç kimse çok farkında olmamasına rağmen, günümüzde içerik aslında pek çok projenin bağlayıcı konularından biridir. Uzmanlığını yaptığınız konuyu düşünün; yaklaştığınız pek çok teknik, çok değişik türlerde yaklaşım ve belki özellikle kullanmadığınız teknolojiler bile vardır. Yeni başlayacak projelerin toplantılarında, dikkat edecek olursanız, sürekli olarak “Nasıl?” sorusunu soruyorsunuz. Bu sorunun sorulma sebebi ise; optimum çözümü bulma isteğinizdir. Kafanızda projeyi şekillendirmeniz, size bu soruları sorup, projeyi yönlendirme ve yönetme imkanı yakalamanızı sağlar.
Bu noktadan hareketle, test süreçlerinde de biz testçiler de tam olarak aynısını yaparız. Testler sırasında ne kadar detaya inilecek, takip sırasında ne yapacağız? Projenin raporlaması için neler kullanılacak? Projenin ne kadarı servis katmanında, ne kadarı birim katmanında, ne kadarı ön yüzde test edilecek? Test sırasında ne gibi araçlara ihtiyacımız olacak gibi soruları cevaplamaya uğraşırız. Bu sorunun cevabı da tabi ki bir uçak yazılımı için farklı, bir bankacılık projesi için farklı, bir e-ticaret projesi için farklı olur. Tıpkı sizin vereceğiniz cevapların farklı olacağı gibi, test safhasında da farklılıklar olur. Bu farklılıklar da bizim yaklaşım ve stratejilerimizde farklılıklar doğurur.
Peki bu stratejinin önemi nedir ?
Bu soruyu cevaplamak için her şeyden evvel iki konunun üzerine vurgu yapmak gerekiyor. Bu konulardan ilki %100 testin, kısıtlı kaynaklar ve zaman hesaba katıldığında, mümkün olmadığıdır. Her şeyin testinin neden mümkün olmadığını başka bir yazıda açıklamaya çalışacağım. Ancak basit olarak bahsetmem gerekirse; özellikle mobil ortamda 2015 yılında pazara 13.000 farklı konfigürasyona sahip cihaz çıktığını hesaba katarsak sanırım sorumuz cevap bulmuş oluyor. İkinci konu ise; yazılarımda sürekli vurgu yaptığım, testlerin risk azaltmak üzerine odaklanmış olması gerekliliğidir. Bu noktada, testlerin asıl amacının müşterilerin önüne en az riskle çıkmak olduğunu düşünmek gerekiyor. Bunu sağlamak için de testleri kurgularken; yazılım ve ürün sahibi insanlarla paralel çalışmalar yapmanın zorunlu olduğu ortaya çıkıyor.
Yukarıdaki konuları değerlendirdiğimizde, ortaya verimli ve hedefine ulaşacak bir test çalışması çıkarmak için, çok ciddi bir planlama gerekliliğini herkes fark edecektir. Kısacası, yöneticileri ve ürün sahiplerini her şeyi test edelim mantığından uzaklaştırarak; teknik anlamda eksiği olmayan ve kapsamı müşteri odaklı testler ile tasarlanmış bir plan doğrultusunda test yapma gerekliliğinin önemini anlatmak görevi test mühendislerine düşüyor.
Her şey güzel, bu strateji nasıl oluşturulmalı ?
“ Testler projenin en erken evresinde başlamalıdır.” Strateji her zaman klişe bir sözle başlar. Bu klişe doğru olmakla beraber, bu klişenin doğru olmasının temelinde bulguların ucuza çözümü vardır. Bulgular ne kadar erken bulunurlarsa o kadar ucuza mal olurlar. Bu durumu sağlamak için ekipler genelde analiz safhasında testlere başlarlar ancak daha sonra önyüzler oluşana kadar test yapmazlar. İşte bu durum aslında iyi niyetle başlanıp doğru tasarlanmamış bir süreçte maalesef yanlış ilerletilmiştir. Burada felsefe olarak doğru başlayan konunun, pratikte de doğru olarak ilerlemesi için projenin her safhasına karşılık bir test uygulanması gerekmektedir. Kısacası, analizden sonra önyüze kadar yapılması gereken bir çok test vardır.
Analiz seviyesinde başlayan test, yazılım yaşam döngüsü ile devam etmelidir. Kısaca, önce birim testler yazılmalıdır. Sonrasında yazılımın bağlı olduğu iç ve dış servislerin testleri yazılmalı ve sonrasında da en az test ön yüz tarafında yapılmalıdır. Bu şekilde sistemli gidecek bir test mimari anlamında uygundur. Bu durumda sürüm çıkışları, sürekli entegrasyon gibi konular; projenin yazılım mimari ile konuşularak izlenecek test yönetimine yön verilebilir. Burada yoğurt yiyiş biçimi mutlaka değişecektir. Önemli olan nokta totalde bu mantalitenin uygulanmasıdır.
Önceki soru başlığını dikkatli okuyan okurları duyar gibiyim, e peki test kapsamı ne oldu? Test kapsamında da ürün yönetiminin destek ve çalışmalarına ihtiyaç duyuyoruz. Burada projenin içeriği çok d
aha etkili hale geliyor. Testin doğasını düşündüğümüzde, görebiliriz ki biz testçiler aslında müşterileri taklit etmeye çabalıyoruz. Onların rolüne büründüğümüz bu süreçte onları çok iyi tanımalıyız ve ürün yönetiminin önceliklerini bu taklitte başarılı olmak adına iyi analiz etmeliyiz. Projenin mobil kanadı var mı? Hangi platformda neler öncelikli? Müşterilerin olası davranış desenleri nelerdir sorularına çok iyi analizler yapmamız gerekecektir. Bu cevaplar doğrultusunda manuel ve otomatik testleri nerelerde ne kadar kullanacağız, nasıl raporlayacağız? Hangi durumların çözümlerine öncelik vereceğiz sorularının cevabını proje paydaşlarına başarıyla bildirmemiz gerekmektedir.
Biraz satır aralarına bakacak olursak, yapmaya çabaladığım şey şu; teknik anlamda testlerin çoğunu birim ve servis testleri seviyesine indirmek. Burada tasarlanmış fonksiyonların hatalarını çok daha hızlı yakalama şansını elde etmiş oluyoruz. Buna ek olarak, ön yüzde kullanıcıların yapacağı hatalı davranışlara ve sistem açıklarına ayıracak daha konsantre bir manuel test süreci elde etmiş oluyoruz. Kısacası, sistemli bir ekip çalışması ile müşterinin davranışlarına odaklanmış bir test süreci üretmiş oluyoruz. Bu test süreci de bizlere müşterilerin çok daha az hata ile karşılaşma durumunu yaratmamızda yardımcı olacaktır.
Sürekli Entegrasyonda Test Otomasyonu Nerede Yer Alır ...
Projelerinizde başarılı bir UX yaratmak için neleri ...