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.

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>

Ö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.

• Doğruluk

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

1. 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 performansı

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.

• Hassasiyet

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.

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

iki kişilk referans hakkım var..

ilgilenenler info (ad) testroot (dot) com adresine cv leri ile başvuru yapabilir.

Bu anlamda serena hem ücretsiz oluşuyla hemde yapısıyla oldukça işe yarar bir araç.

Ürünün oldukça iyi hazırlanmış help’i var, help den destek alarak bir kaç tutorial yaptığınızda ürünü rahatlıkla kullanmaya başlıyabiliyorsunuz.

Link‘e tıklayarak ürünün indirebileceğiniz adrese ulaşabilirsiniz.

Test Test gözlemcisi ve onun  seçtiği bir kullanıcı test grubu üzerinden gerçekleştirilir. Test edeceğiniz ürünün özelliklerine göre aşağıdaki başlıkları ölcümleyebileceğiniz taskları şecebilirsiniz.

Örnek üzerinden gidersek , bir kredi kartı sistemi oldukça büyük ve içinde tek bir transaction’ı gerçekleştirebilmek için oldukca farklı platformlarda alt sistemler içeren bir yapıdadır, basitçe bölersek pos cihazı, işlemlerin kontrolünün yapıldığı bir host , gelen işlemlerin muhasebesini gerçekleştiren bir mainframe ve raporla işlemlerini gerçekleştiren başka bir yazılım(crm sisteminden tutunda, fraud, kampanya vs.. gibi oldukca komplike bir yapısı var ama biz daha önce verdiğim basit örnekten gidelim).

Tüm bu parçaların ayrı ayrı tetsleri gerçekleştirildikten sonra ( pos uzerindeki yazılımın testi , kontrol mekanizmasının testi , vs..), tüm sistemin bir arada çalışabilirliğini test etmeniz gerekir. Küçük bir uygulama çok sorun yaratmaya bilir ama sistemin kapsamı büyüdükçe ent to ent testin gerekliliği ve maliyetide bir o kadar artar.

Bu test türü için oldukça detaylı bir test planı ve test tasarımı hazırlanması gerekli, Testler sırasında senaryodaki veya test verilerindeki en ufak bir yanlışlık oldukça büyük bir maliyete neden olur.  Tekrar verdiğimiz örnek üzerinden gidersek pos üzerinde hangi kartların kullanılacağı ,hangi işlemlerin hangi tutarlarda ne zaman gerçeleştirileceği ,bunların hangi sırayla kontollere ulaştığı ,butun kontrollerin validasyonlarının sağlandığı vb… case ler en ufak detayına kadar hesaplanmalı ve planlanmalı. Yapılan her hata tüm alt sistemlerede işlemlerin silinip baştan başlanmasına neden olacaktır.

Şahsi tecribeme göre hazırlanması ve gerçekeştirmesi en zor test çeşitlerinden birisi,sistemin kapsamı  ve executionın büyük bir ekip tarafından yapılması bunun en önemli nedenlerinden .

Yazılımda çıkan her hangi bir hata tüm emeğinizi çöpe atmanıza neden olabilir, tavsiyem bu teste başlamadan önce alt sistemlerin testinin oldukça iyi yapılmış olmasını sağlayın.

Bu durumda uygulamanızın diğer ürünlere göre zayıf ve güçlü yanlarınızı belirlemek ve istenilen seviyeye ulaştırmak için ( bu da bir gereksinim olarak karşınıza çıkabilir ) comparasion testi yapmanız gerekecektir.

Comprarison testi , temel anlamda belirlenen özeliklere karşılaştırma amaçlı test senaryoları hazırlamak ve senaryoları execute etmek anlamına geliyor. Bu çeşitli test sevilerinde yapılabilecek bir test, genel olarak bir nevi banchmark mantığı içeriyor. Seçilen özellikler 2 ürü içinde test ediliyor ve sonuclar rakip ürünün daha iyi olduğunu gösteriyorsa deffect açılıyor.

Örneğin; X bankasında internet şubesi projesinde görevlisiniz ve gereksinim olarak uygulamanın y bankasının internet subesinden daha hızlı olması olarak geldi, bu aşamada yapacağınız testler şu şekilde gelişebilir.

2 uygulamada hemen hemen aynı özelliklere sahip uygulamalardır. Bu özellikleri çıkarıp her biri için senaryo çıkartmanız gerekecektir. Bu senaryolar “a özelliğini x uygulamasında gerçekleştir, a özelliğini y uygulamasında gerçekleştir, ilk sonucun 2 ci sonuctan % 10 daha az olduğunu gör ” gibi olacaktır.

Bu örnekte sadece performans gereksinimine değinilmiştir, gereksinimler kullanım kolaylığı , iş akışı olarakda karşınıza çıkabilir.