Yazılım Test Metrikleri

Direk ölçülebilen veya yapılan ölçümlere göre hesaplanan değerlere metrik denir.
Testler için alınan metrikler, testi yapılan yazılım, müşteriye gönderebilmek için yeterli kaliteye ulaştı mı? Test ne kadar verimli olduğu gibi sorulara cevap verir.

Yazılım projelerinde özellikle kod satır sayısı ve hata sayısı en önemli metrikleri oluşturuyor.

Yazılım test mühendisliğinde tutulan 3 tip metrik vardır:

• Süreç Öncesi Metrikler
• Süreç Sırası Metrikler
• Süreç Sonrası Metrikler

Süreç Öncesi Metrikler: Test eforunu tahmin etmede kullanılır. Süreç öncesi metrikler genelde test sürecinin en başında, test takvimi belirlenirken test eforunu tahmin etmede kullaılırlar. Testi yapılan yazılımın büyüklüğü örneğin gereksinimlerin sayısı, kod satır sayısı, function points, complexity gibi faktörler göz önünde bulundurulur. Testi yapılan yazılımın kalitesinden kasıt gereksinim gözden geçirmelerinde bulunan hata sayısı, kod gözden geçirmede bulunan hata sayısı olabilir.

Faktörler:
- Testi yapılan yazılımın büyüklüğü
- Testi yapılan yazılımın kalitesi
- Bir önceki projelerde edinilen deneyim

Süreç Sırasında Tutulan Metrikler: Gidişatı izlemeye ve yazılımın kalitesini anlamaya yardımcı olur. Test sürecinin planlandığı şekilde gidip gitmediğine bakılır. Planlanan, koşan, geçen, kalan test prosedür sayıları gözönüne alınır. Hata sayılarına baklılırken, önem seviyeleri de dikkate alınır. Bunlar:

• Seviye 1: Tüm sistem ya da önemli bir fonksiyonalite çalışmıyor ve geçici bir çözüm yok
• Seviye 2: önemli bir fonksiyonalite çalışmıyor ve geçici bir çözüm var ya da önemsiz bir fonksiyonalite çalışmıyor ve geçici bir çözüm yok.
• Seviye 3: önemsiz bir fonksiyonalite çalışmıyor ve geçici bir çözüm var
• Seviye 4: Yazım hatası gibi kozmetik hatalar var ya da gereksinimlerde açık olarak belirtilmeyen iyileştirmeler yapılmamış.

Bu seviyelerin test planında müşteri ile görüşüp onay alınarak belirtilmesi gerekir.

Faktörler:
-Test prosedür sayısı
-Önem seviyelerine göre bulunan hata sayısı
-Testleri koşturmak için harcanan zaman

Süreç Bitiminde Tutulan Metrikler: Yazılımın kalitesini anlamaya ve süreçlerimizi iyileştirmeye yardımcı olur. Yapılan öngörülerle ne kadar örtüştük ona bakılır. Burada hata giderme oranının ne kadar 1’e yakın olduğu, yapılan testin kalite için bir göstergedir. Sistemde bulunan hataların çoğunun, en azından kritik olanların tamamının sistem testlerinde bulunmuş olması gerekir.

Faktörler:
-Süreç öncesi alınan metrikler
-Çözülmemiş, açık olan hata sayısı ve önem seviyeleri
-Test prosedürlerinde bulunan hata sayıları
-Hata Giderme Oranı (HGO)

HGO = Hs / (Hs + Hm)
Hs: Sistem testlerinde bulunan hata sayısıHm: Müşteri tarafından bulunan hata sayısı

Yazılım Test Otomasyonu

Test otomasyonu test ile ilgili olsa da, aslında bir yazılım geliştirme işidir. Genellikle istenir fakat kendi içinde bir takım riskler taşır. Hazır da alınabilir, geliştirilmesi de gerekebilir. Yazılım geliştirmenin erken safhalarında otomasyon çalışmalarına başlamak gerekir. Başarılı test otomasyonu kararlılık, testçiler ve geliştiriciler arasında takım çalışması gerektirir.

Hem zaman kazandırır hem de insan faktörlerinden doğabilecek bir takım problemlerin önüne geçer. Örneğin bir otomasyon aracı hiç bir zaman koşturulması gereken bir test prosedürünü unuttuğu için size eksik sonuç vermez. Test sonuçlarını doğru bir şekilde kayıt altında tutar. Özellikle çok fazla regression test koşturulması gerekliyse yani aynı testler kod değiştikçe birden fazla kere koşturulacaksa otomasyon mutlaka yapılmalıdır.

Kritik iş süreçlerinde, karmaşık uygulamalarda ve bunları tehlikeye atan kullanım durumlarında otomasyon çabalarına odaklanmak anlamlıdır. Ama bir kurumun günde birçok saat çalışan birden çok yazılım testçisi varsa ve hala kalite ve işlevsel sorunlar bulunuyorsa, otomatik teste geçmek yararlı olabilir.

Otomasyon işine erken safhada başlamak gerekir. Çünki geç aşamalarda başlandığı zaman tüm test tasarımlarını, test stratejilerini, test sonuç formatını ve benzeriyi değiştirmek gerekebilir. Bu da maliyet ve aynı zamanda personelin demotivasyonu demektir. Bu etkileri en aza indirebilmek için, otomasyon mimarisini çok iyi yapmak gerekir.

Yazılım otomasyon işinde turnover yani devretme işinin yüksek olmaması gerekir çünki otomasyon işi deneyim isteyen bir iştir. Yoksa başarı şansı azalır.

Bu iş için özel personel ve zaman ayırmak gerekir.

Yazılım otomasyonu da bir yazılım geliştirme projesi olarak ele alınmalı, bu iş için de özel olarak asssign edilmiş testçiler bulunmalı, otomasyon fazının da normalde işleyen yazılım projelerinde olduğu gibi gereksinimlerinin çıkarılması, tasarımının yapılması, hata yönetimi yapılması ve testlerinin yapılması gerekmektedir.

Yazılımda Otomasyonun Avantajlarını şöyle sıralayabiliriz:

• İnsan kaynaklı hataları minimize eder
• Daha fazla hatayı daha erken teşhis eder
• Testlerin yeniden kullanımını kolaylaştırır
• Testlerle kapsanan kod yüzdesini artırır (Code Coverage)
• Testler 7x24 çalışabilir

Ne zaman otomasyon yapmalıyız?

Aşağdıaki sorulardan en az bir tanesine "EVET" cevabı vermişseniz otomasyon yapmak projenin faydasına olacaktır fakat şunu da belirtmekte fayda var ki otomasyon manuel testlerin yerine konan bir yöntem değildir. İşleri kolaylaştırmak için yapılır, bazen en önemli hatalar Ad Hoc testler ile bulunur, yani testçi kendisini müşterinin yerine koyar ve çeşitli senaryolar dener ve genelde de önemli hatalar bu şekilde bulunur.

• Test aktiviteleri ardışık olarak tanımlanabiliyor mu?
• Ardışık aktiviteleri tekrarlamak gerekiyor mu?
• Ardışık aktiviteler için otomasyon yapılabiliyor mu?
• Testler, yarı-otomatik hale getirilebiliyor mu?
• Testi yapılan yazılımın davranışları otomasyon olunca değişmiyor?
• Programın kullanıcı arayüzü olmayan özellikleri mi test ediliyor?
• Aynı testleri farklı donanım konfigürasyonlarında koşturmak gerekiyor mu?

Açık Kutu Test Teknikleri

Bu tip testlerde kaynak kod test mühendisi tarafından görülebilir. Hatta bu yöntemlerden bazıları kaynak kodun değiştirilmesini bile gerektirir. Örneğin mutasyon testi gibi.

Aşağıda listelenen teknikler, açık kutu test tekniklerine birer örnektir:


Reference models for code-based testing (flow graph, call graph)
Kontrol Akışı Tabanlı Test
Veri Akışı Tabanlı Test
Mutasyon Testi

Kapalı Kutu Test Teknikleri

Yazılım test edilirken sadece girdi ve çıktı değerleri bilinir. Yazılımın içinde ne tür algoritmalar çalıştığı, nasıl kodlandığı, tasarım detayları ve kod bilinmez.
Yazılım bir sistem olarak ele alınır ve hangi girdilere sistemin ne cevap verdiği test edilir.

Aşağıdaki teknikler kapalı kutu test teknikleridir:

Equivalence partitioning
Boundary-value analysis
Decision table (Karar Tablosu)
Finite-state machine-based
Formal Spesifikasyonlardan Test
Error guessing
Random testing
Operational profile
SRET

Yazılım Test Teknikleri

Test teknikleri geliştirilmesindeki amaç, sistematik olarak test senaryolarının seçilebilmesini sağlamaktır. Hangi tekniğin ne zaman kullanılacağı test mühendisinin deneyimi, kaynak kodun yapısı, gereksinimlerin yapısı, bulunan gerçek hatalar, alan kullanımı ve uygulamanın doğasıyla ilgili olabilir. Test teknikleri genelde birbirlerine alternatif değil, birbirlerini tamamlayıcı rol oynarlar. Bu teknikler, testin amacına hizmet etmesi için kullanılan araçlardır.

Çeşitli test teknikleri vardır. Bunlar aşağıdaki gibi özetlenebilir. Detaylar için önemli tekniklerle ilgili ayrıca yazılarım olacaktır.

1)Test Mühendisinin Deneyim ve Önsezilerine Dayalı Test Teknikleri:

Ad hoc Test: Herhangi bir dokumantasyonu olmayan, tamamen test mühendisinin bilgi düzeyi ve yaratıcılığıyla oulşturduğu test senaryolarıdır. Belki de en fazla kullanılan tekniklerde birisidir. Test yapan kişinin benzer programlarla olan deneyimine oldukça bağlıdır. Formal methodlarla çıkamayan test senaryoları yaratmak için kullanılan bir yöntemdir.

Exploratory Test: Araştırmacı test olarak da bilinir. Eşzamanlı, anında öğrenme, test tasarlama ve test koşmadır. Etkili olması testi yapan kişinin bilgisine, uzmanlığına, hataların tipne, test sırasında ürünün yaklaşımına, uygulama ile olan yatkınlığa, bunun gibi etkilere bağlıdır.

2)Spesifikasyonlara Dayalı Test Teknikleri:

Equivalence Partitioning

Boundary Value Analysis

Desicin Table (Karar tabloları)

Finite-State Machine Based Test

Formal Spesifikasyonlardan Test
Rastgele (Random) Test

3)Kod Tabanlı Test Teknikleri:

Control Flow Based Test

Data Flow Based Test

REference Models for Code-Based Testing

4)Hataya Dayalı Test Teknikleri:

Error Guessing

Mutation Testing

5)Kullanıma Dayalı Test Teknikleri:

Operational Profile

SRET (Software Reliablility Engineering Testing)

6)Uygulamanın Doğasına Dayalı Test Teknikleri:

Nesneye Yönelik Test (Object Oriented Testing)

Bileşen Tabanlı Test (Component-based Testing)
Web Tabanlı Test
Kullanıcı Arayüzü Testleri
Eşzamanlı Program Testleri
Protokol Uyum Testleri
Gerçek Zamanlı Sistem Testleri
Emniyet Kritik Sistem Testleri

Yazılım Test Başlama ve Bitirme Kriterleri

Test bazen “after-the-fact” aktivitesi olarak düşünülür yani ürünün kodlaması bittikten sonra uygulanacak bir aktivite gibi fakat bu yanlış bir düşünce tarzıdır. Yazılım testi, gereksinimlerin ortaya çıkmasıyla başlaması gereken bir prosestir. Bir çok standard, gereksinimler gözden geçirilirken test senaryolarının da paralel olarak yazılmasını önermektedir. Bu sayede gözden geçirmeler sırasında özellikle “testability”, “ambiguity”, “completeness” gibi sorulara cevap vermek kolaylaşır ve geri dönüşler azalır.

Benim şahsi fikrim test tasarımının gereksinimler aşamasında yapılması, test prosedürlerinin ise yazılımın tasarımı olgunlaştıktan sonra tamamlanmasıdır fakat projenin takvimine göre bu aşama geç de olabilir. Burada yapılabilecek şey, test prosedürlerinin yazılım tasarımından en çok etkilenecek olanlarının belirlenmesi ve belki sadece bu testlerin tasarım olgunlaştıktan sonraki bir aşamaya bırakılmasıdır. Testlerde özellikle de entegrasyon testlerinde kullanılacak olan araçların projenin en başında Test Değerlendirme ve Ana Planında zaten belirlenmiş olması gerekmektedir.

Bence birim testler bir “software development” aktivitesidir. Yani geliştirici tarafından yapılan dinamik gereksinim, tasarım ve kod gözden geçirmesi sayılabilir. Bu sebeple burada bahsettiğim yazılım testi ifadesindeki “test” genelde entegrasyon (yazılım-yazılım, yazılım-donanım) testlerine karşılık gelmektedir.

Testler ne zaman bitmeli gibi sorular ilk defa bir projeye test mühendisi ya da uzmanı olarak başlayan çoğu insanın sorduğu bir sorudur. Aslında bu sorunun tek bir cevabı da yoktur. Fakat bu test sonlandırma kriterleri mutlaka ve mutlaka Test Değerlendirme ve Ana Planında yer almalı ve müşteri tarafından onaylanmalıdır.

Burada bilgi amaçlı örnek olsun diye bazı test sonlandırma kriterlerini de vermek istiyorum:

• Test prosedürlerinin %100’ü koşturulduğunda
• Test prosedürlerinin %95’i “PASS” olduğunda
• Yüksek öncelikli olan tüm testler “PASS” olduğunda
• 1.Öncelikli hatalar = 0
• 2.Öncelikli hatalar ≤ 2
• 3.Öncelikli hatalar ≤ 5
• 4.Öncelikli hatalar ≤ 10
• İstenilen kod kapsamı (code coverage) sağlandığında

Yazılım Testi Nedir?

Yazılım testi için SWEBOK,2004 tarafından verilen tanımı kullanmak istiyorum:

“Software testing consists of the dynamic verification of the behavior of a program on a finite set of test cases, suitably selected from the usually infinite executions domain, against the expected(“specified and implied”) behavior”.

Burada anlatılmak istenen yazılım testinin; yazılımın sınırlı sayıda ve seçilmiş test senaryoları kullanılarak beklenilen davranışı gösterdiğinin dinamik olarak yani kodun çalıştırılarak doğrulanması aktivitesidir.

Test, bir doğrulama aktivitesidir. Yazılımın dinamik olarak geçerlemesidir aslında. Gereksinim, Tasarım, Kodlama gibi aktivitelerde yapılan statik geçerleme analizlerinin tamamlayıcısı sayılabilir. Test aşamasında bulunan bir hatanın düzeltme maliyeti, bakım aşamasında ortaya çıkan bir hatanın düzeltme maliyeti yanında oldukça düşük kalır. Bunun yanında, müşterinin bulduğu hataların size sadece maliyet olarak değil, güvensizlik ve pazardaki rekabeti düşüren bir faktör olarak geri dönmesi de kaçınılmazdır.

Elbette ki müşteriye teslim edilen versiyonda hiç hata olmaması mümkün değildir fakat kritik hataların müşteri tarafından bulunması projenin ne kadar başarısız olduğunun da bir göstergesidir.

Bir çok proje, test sürecinin belirsizliği ve test yönetiminin eksikliğinden dolayı olumsuz sonuçlanmaktadır.Test süreci, proje yaşam döngüsü içinde kurum ve yüklenici arasındaki güçlük derecesi en yüksek olan aşamadır.Projenin en son aşaması olarak yer alan "test süreci”, test planlaması ve yönetimi altında, projenin başından itibaren devreye alınarak, ürün kalitesini ve projede beklenen sonuçların elde edilmesini güvence altına almaktadır. Bence yazılımda iyi bir test sürecinin olması, yazılımın kalitesini etkileyen en önemli faktörleden birisidir.

Yazılım test süreçlerinde özellikle gereksinimlerin ve tasarımın anlaşılması çok önemlidir. Gereksinim bazlı testlerde, gereksinimlerin yanlış yorumlanması hatalı teste, bu da çalışmayan ya da hata vermesi beklenen bir sistemin onaylanmasına sebep olabilir. Test planı oluşturulurken de gereksinimlerin ve de projenin doğası, yapısı girdi olacaktır. Planda belirtilen yaklaşımlarla test tasarımları, durumları ve prosedürleri hazırlanır. Daha sonra hazırlanan bu dokümanlar gözden geçirilir. En sonda yapılıyor gibi görünmesine rağmen, test dokümanlarının hazırlanması aşamasına paralel olarak test ortam ve araçları, kullanılacak veriler hazırlanır. Hatta kullanılacak test ortamı test tasarımlarını ciddi anlamda etkiler, bu tip durumlar için test ortamı ne kadar erken hazırlanırsa o kadar iyi olur.

Günümüzde pek çok yazılım firmasında “Yazılım Test Mühendisliği” kavramı oturmamıştır. Birim testler, modül testleri ve entegrasyon testleri, en nihayetinde de müşteri kabul testleri halen projeyi geliştiren yazılım mühendisleri tarafından yapılmaktadır. Testlerin bağımsız kişiler tarafından yapılmasına gerek görülmemektedir.

Fakat son zamanlarda ülkemizdeki bazı firmaların emniyet kritik askeri projelerde yer alması ve bu projelerin de bir takım standardlara uyma zorunluluğu beraberinde bağımsız yazılım doğrulama aktivitelerinin gerçekleştirilemsine ve bu vesileyle yazılım geliştirme ekibinden bağımsız yazılım doğrulama ve geçerleme grupları oluşturulmasına ön ayak olmuştur.