Birazda düşünce tekniği olarak bahsetmek istiyorum…
Genel olarak yapılmaya çalışan uygulamalar verilerin birbiri üzerine ilişkilenmesi üzerine kuruludur. Örneğin bu blogda herhangi bir yazı yayınamak için öncelikle kullanıcı kaydı yapılması gerekmektedir. Bu veri tanımlandıkdan sonra yazı yayımlanabilir.
Burda dikkat çekmek istediğim nokta bu temel akış uzerindeki silme ve güncelleme işlemleridir. Genede “Türk Yazılım Yönteminde” genel olarak silme fonksiyonu ilk kez gerçekleştirildiğinde ilişkili diğer veri yapıları gözetilmez. Sildim gitti usuludur. Test açısından temel akışın işlerliğindense silme/güncelleme fonksiyonlarının uyumlu işlemesi daha önemlidir . Örneğin kullanıcı silindiğinde yazdığı yazılar , yaptığı yorumlara ne olacak ?
Hiyerarşik bir veri sisteminde yapılan değişiklilerin üst seviyedeki ilişkili verilere etkileri bence en çok başımıza iş çıkartan durumlardır. Kendi gözlemim olarak hataların %30 bu gibi nedenlerden kaynaklanmakta. tabi Development kısmınada pek suç atamak lazım genellikle bu durumların detayları analizde atlanır.
Yine oldukca baş ağrıtan konulardan biri, bir uygulamanın search /arama özelliğinin testi.
Öncelikle neleri test edebileceğimizi tanımlamamız gerekiyor. Öncelikle uygulamaya özel bir arama özelliğiyse( örneğin bir fiyat aralığı arama özeliği) bu konuların belirlenmesi gerekiyor. Daha sonra aşağıdaki başlıkları göz önünde bulundurulması gerekli.
Arama otorunun doğrululuğu belirlenen kritere göre ürün database’indeki eşleşen kayıtları tam ve doğru olarak getirmesidir.
Bunu için 2 yöntem kullanılabilir
- Karşılaştırma
User interfacede yapılan sorguyu direk olarak databse de yapılan sorgu sonuclarıyla karşılaştırma.
2. Tutarlılık
Eklenen kayıtlarla sorgu sonuclarınızında artması gerekiyor. bir data seti oluşturup , databade verileri ekleyerek sorgu sonuclarınında arttığını görmeniz gerekmekte.
Arama sonuclarını kabul edilebilir zaman aralıklarında döndürülmesi gereklidir. Bu zaman gereksinime göre değişebilir. Performans testi yaparak bu zamanın uygun değerlere çekilmesi gereklidir.
Bu oldukca göz ardı edilen bir konudur.Arama özelliğinin hassasiyeti yapılan sorgulama soncunda sadece istenilen sonuçları getirmesindeki başarısıdır. Örneğin İpod touch aradığınızda sadece beklediğiniz ürünleri getirmesi , “ipod kılıfı , araba şarjı vs… ” sonucların getirilmemesi yada arka sıralara atılmasıdır. Tabiki bu user ın girdiği keyword lerin detayı, searc edilecek database deki verilerin temizliği, uygulamanın kendine has özelliklerine göre değişir. Dolayısıyla test konusunda biraz kafa yormanız gerekecekdir.
Farkındasınızdırki agile test kavramı bilinen waterfall modelinden oldukça farklılık gösterir.Testleri daha sık ve daha çabuk yapılması gerekir. Buda test sürecinizin değişmesi anlamına gelir. Yazılımdaki gibi testlerde özellik bazlı ve iteratif olmalıdır.
Dolayısıyla testci anlayışıda tamamen değişiyor, testci tam bir dokuman setiyle işe başlıyamıyacağı için projeye işin başından yani gereksinimlerin toplanması aşamasından katılıp , dokuman olmasada neyin doğru neyin yanlış olduğuna fikir sahibi olabilecek kadar konuyu ve işleyisşi bilmelidir. Bu da ekibe katılacak testcinin kalifikasyonunun oldukca iyi olması gerektiği anlamına geliyor
Jacabson amcamın bu amacla bir webinar düzenlemiş,
temel başlıklar;
• Avoiding unnecessary pre-requisites for testing activities
• Reducing test preparation to just-good-enough
• Not using test plans / test strategies to educate the team
• Automating, but only when the RIO stacks up
• Making testing a team responsibility
olayın ne olup ne olmadığını bilen , bu konuda çalışmak isteyen, aklı başında kişiler aranıyor
iki kişilk referans hakkım var..
ilgilenenler info (ad) testroot (dot) com adresine cv leri ile başvuru yapabilir.
Bu tabir , ful otomatik arayüz test tooları için kullanılır. Bu toollar uygulamanın nasıl kullanılacağını bilmezler, bu yüzden temel işlevi rastlantısal olarak ekran üzerinde mouse click yapmak yada yine rastlantısal olarak klavyeden input yapmak. Conduct stochastic test adı ile black box test tipinin altında sayılabilir.Bu sayade bir insanın düşünemeyeceği olasılıklarda test edilmiş oluyor 
.
Bu toollarında 2 çeşidi bulunmakda ;
Dumb monkeys: Düşük bir IQ seviyesiyle, testin ne durumda olduğunu bilmeden , inputların legal yada illlegal olduğu farketmeksizin girer. Bug la karşılaştığı zaman tanımlayamaz yada tekrarlıyamaz.
Smart Monkeys:Bu toollar öncekine göre biraz daha aklı başındadır, verilen state table yada modeline göre inputlar generate edip kullanır. Test altındaki uygulamanın akışına göre davranır.
Test Seviyesi
Düşünüldüğü gibi teste giren bir uygulama prod’a hatasız çıkıcak diye bir kural yoktur, test başlamadan bir seviye belirlenmeli ve bunu sağlıycak kadar teste maliyet harcanmalıdır, kısacası bu test yaparkende suyu çıkarılmamalı.
Örnek üzerinden anlatmak gerekirse , bir blog sayfasının testiyle , uzaya roket gönderdiğin bir projenin testi aynı algılanmamalı, hata durumunda oluşabilecek etkiler belirlenmeli, test de bu etkiler kabul edilebilir dereceye çekilene kadar devam etmeli. bu yüzden bi ürünü test etmeniz istendiğinde önce sorulması gerek ken şey test seviyesi ne olmalı sorusunun cevabıdır. Bu cevabı proje yöneticisinden isteyebilirsiniz ki, proje yöneticisi klanında bütün projeler çok önemli statusune girer, dolyısıyla doğru cevabı alamzsınız genelde , o zaman yapılması gereken şey proje yöneticisini kenara çekip , işi yapmak için bu cevaba ihtiyarç duyulduğunu belirtip, nasıl cevap verilebileceğine dair yönlendirmeler yapabilirsiniz. Cavaba ulaşmak için gereken bilgiler; zaman, kaynak planlaması, proje sponsorunun görüşü, müşterinin görüşü vb.. bilgiler incelenerek bir karara bağlanabilir.
Son Yorumlar