Devir değişti ,artık Türkiyedede ürün şeklinde çıkan yazılımlar görebiliyoruz , buda bizim test sürecimize yei bir test türü daha ekliyor install/uninstall testing .
Eğer teste gelen bir uygulama paket halinde satılacaksa , installer uygulamasıda artık ürünün içine dahil demekdir , ürün istediğiniz kadar hatasız olsada kurulamıyorsa ,yada kurulum sırasında yazılımın ihtiyarcı olan bazı konfigürasyonlar kurulum yapılan sistemde tanımlanmıyorsa buyuk bir sorun yaratır.
install/uninstall testing de burda devreye giriyor, paketlenen ürünün doğru kurulup kurulmadığı , set up sırasında doğru dizinlere doğru dosyaların yüklenip yüklenmediği, sistemde doğru izinlerin verilip verilmediği, uygulamanın kullanacağı userlar varsa bunların tanımlanmadığı gibi ürüne özel bir check listin testi yapılmalıdır.
naciizane önerim eğer testini yaptığınız uygulama bu tür bir paketleme yapılacaksa ürün testini her cycle ınıda installerla birlikde teste almanızdır.
Not: sistemdeki ürüne upgrade/update yapan set up larda başka bi konudur ayrı 
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.
ne yazık ki ie 8.0 ile QC uyumlu değil buda olmadık sorunlara yol açıyor.
Hp bunun için bir add in hazırlamış. indirip kurdukdan sonra start menüden direk olarak açabiliyorsunuz.
QC 9.2 için
QC 9ç0 için
kurdukdan sonra adres satırına aşağıdaki şekilde adresi girmeniz yeterli.
http://<Quality Center server name>/<virtual directory name>
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
Son Yorumlar