Özet. Günümüzde, farklı sektörlerdeki ihtiyaçlar için farklı yazılım ürünleri geliĢtirilmektedir. Yazılım geliĢtirme sürecinin önemli bir aĢaması da yazılım test sürecidir. Yazılım testleri ürün kalitesinin yükseltilmesi ve müĢteri memnuniyetinin artırılması için kritik öneme sahiptir. Test sürecinin baĢarısı doğrudan projenin baĢarısını etkilemektedir. Yazılımlardaki çok küçük hatalar dahi can, mal kayıplarına neden olabilecek kritik sonuçlara sebebiyet verebilir. Bu sebeplerden dolayı yazılım test sürecinin etkili ve verimli geçmesi projenin istenen hedeflere ulaĢmasında büyük öneme sahiptir. Bu çalıĢmada test süreçlerinde karĢılaĢılan problemler belirli gruplarda toplanarak, bu problemlere neden olan sebepler ve bu problemler için önerilen çözüm önerileri anlatılmıĢtır. KarĢılaĢılan problemler; planlama ile ilgili problemler, yönetimsel problemler, gereksinimler ile ilgili problemler, düĢünsel problemler, paydaĢlar arasındaki problemler ve genel test problemleri olarak gruplandırılabilir. Bu gruplar altında toplanan problemlerin sebepleri belirtilerek, çözüm yolları önerilmiĢtir.
Doğrulama sürecinin temel amacı, kalitesi yüksek ürün üretebilmektedir.
Doğrulama geçerleme sürecinin mümkün oldukça projelerin erken evrelerinde baĢlatılması
olası problemlerin önünü kesme veya çözümünün daha erkene alınmasına yardımcı
olacaktır [
Geçerleme süreci, yazılımın tam olduğunu ve kendi içinde tutarlı olduğunu gösteren bir süreçtir. Proje sırasında iĢ adımları ve ara çıktılar gözden geçirilip bunların kabul edilebilir olduğundan emin olunur.
Yazılımın tutarlılığını, bütünlüğünü ve doğruluğunu göstermek için yazılım
geliĢtirme yaĢam döngüsü aĢamasında ve aĢamaların her birinin arasında geçerleme süreci
uygulanır. Ayrıca geçerleme süreci yazılım geliĢtirme esnasında eğitimler, standartlar,
gözden geçirme ve yorumlar, geri bildirimler, kontrol listelerine göre denetimlerin
yapılması gibi aĢamalarla gerçekleĢtirilir [
Yazılım test faaliyetleri doğrulama ve geçerleme süreci içerisindeki alt aktiviteler arasında önemli aktivitelerdir.
Yazılım test sürecinin olmadığı ya da eksik olduğu durumlarda yaĢanabilecek negatif durumlar; proje yönetimi ile ilgili problemler, test yönetimi ile ilgili problemler, düĢünsel problemler ile ilgili problemler olarak genel baĢlıklarla toplanabilir. Bu çalıĢma kapsamında belirtilen genel durumlar detaylı bir Ģekilde ele alınacaktır. 2 2.1
Yazılım projelerinde proje özelliklerine, ihtiyaçlarına, hedeflerine uygun olarak belirlenen yazılım geliĢtirme yaĢam döngüsü seçimi ve bu yaĢam döngüsü aĢamalarının amaçlarının belirlenmesi, bu aĢamalarda yapılması gereken faaliyetlerin ve bu faaliyetlerin çıktılarının belirlenmesi gerekmektedir.
Proje süreçleri içerisinde bir aĢama tamamlandıktan, hedeflerine ulaĢarak faaliyetler kapandıktan sonra ilerleyen dönemlerde bu aĢamalara geri dönmenin, projenin planlarından sapmasına, aynı iĢlerin tekrar yapılmasına, zaman, iĢ gücü kaybedilmesine sebebiyet vermektedir. Örneğin, projenin sistem testleri gerçekleĢtirilir iken, müĢteri kurumdan yeni bir özellik talebi gelmesi, isterlerin tekrar düzenlenmesi, geliĢtirme sürecine geri dönülmesi ve test sürecinin (yineleme ve sistem testleri) yeni duruma göre tekrar değerlendirilmesini gerektirecektir. Bu problemin önüne geçilebilmesi için proje analiz ve planlama süreçlerinin paydaĢlar ile birlikte belirlenmesi, onaylarının alınması ve bu planlara bağlı kalınması gerekmektedir. 2.2
Proje planlama aĢamasında gerekli kaynaklar belirlenirken, planlanan test faaliyetleri, iĢ yüküne, yapılacak çalıĢmaların teknik gerekliliklerine göre belirlenir. Test faaliyetlerini yürütecek test mühendisi sayısı ve testler sırasında kullanılacak araçların belirlenmesi gerekmektedir. Test mühendisi sayısının gerekenden az belirlenmesi iĢ yükünün artmasına, yeterli detayda test yapılamamasına ve test sürecinin hedeflerine ulaĢamamasına sebebiyet vermektedir. Aynı durum test faaliyetlerinde kullanılacak araçlarının belirlenmesinde de geçerlidir. Gereken araçların tedarik edilememesi veya geç tedarik edilmesi test sürecinin verimliliğini ve etkinliğini düĢürecektir. 2.3
Yazılım geliĢme yaĢam döngüsünün diğer aĢamalarında olduğu Ģekilde test çalıĢmalarının verimli olması ve istenen çıktılar elde edilmesi için zaman planlamasına uyulması gerekmektedir. Yazılım testlerindeki faaliyetler, planlama, test tasarımı, testlerin koĢturulması, bulunan hataların düzeltilmesi, yineleme testleri, değiĢikliklerin olması ve bunların dokümante edilmesidir. Projelerde farklı sebeplerden dolayı zamansal dar boğazlara girilmesi ihtimali vardır. Proje teslim zamanının yaklaĢması geliĢtirme sürecinin henüz tamamlanmaması sonucunda zaman kazanmak için test süreci için ayrılan zaman ötelenmekte ve test faaliyetleri planlanandan daha az bir zamana sıkıĢtırılmaktadır. Böylece oluĢan zaman baskısı istenen detayda test yapılmasının engelleyeceği için test faaliyetlerinin kalitesini düĢürmektedir. 2.4
Projelerde planlamalar yapılırken önemli noktalardan biri de görev tanımlamaların yapılmıĢ olmasıdır. Yazılım testlerinde farklı bağımsızlık seviyelerine göre farklı pozisyondaki kiĢilere farklı görevler verilebilmektedir. Test faaliyetlerinin sağlıklı ilerleyebilmesi için proje içerisinde görevlerin ve bu görevleri gerçekleĢtirecek insanların belirli olmaması nedeniyle, bazı iĢlemlerin takibi yapılamamakta ve bu iĢlemler tamamlanamamaktadır. 2.5
Proje baĢlangıç aĢamalarında test faaliyetleri için yapılan kestirimler iki temel dayanağa sahiptir, bunlar tecrübeye dayalı kestirimler ve istatistiksel verilere dayalı kestirimlerdir. Proje planlarının temel aldığı öngörüler takvimsel öngörüler, iĢ gücüne dayalı öngörüler, bütçe öngörüleri ve proje risk öngörüleri Ģeklinde sıralanabilir. Bu öngörülerin isabetli olup olmaması, test faaliyetlerinin istenen amaçlara ulaĢmasında etkili olmaktadır. 2.6
Yazılım test faaliyetlerinin sağlıklı olarak devam edebilmesi için önemli noktalardan birisi de yazılım geliĢtirme ortamından ayrı bir test ortamının olmasıdır. Bu ortam yazılım geliĢtirme müdahalelerinden uzak tutulmalıdır. Burada amaç test edilen yazılım ürününün durağan bir yapıda tutulmak istenmesi, yazılımda alınan çıktıların aynı iĢlemler karĢısında aynı kalmasını sağlamaktır.
Test edilen yazılım ürününün bahsedilen durağan tepkiler vermesini sağlamak için diğer bir zorunluluk ta ürün ile ilgili düzenli sürüm tanımlama ve sürüm kontrolünün yapılmasıdır. Bu düzen sağlanmadığı durumda yazılım sürüme ait hatalar, hata düzeltmeleri (bug fix), geliĢtirmeden kaynaklı eklemeler sürümler arasında net olamayacak ve sağlıklı bir test süreci iĢletilemeyecektir. 2.7
Yazılım test faaliyetleri, yazılım yaĢam döngüsü içerisindeki diğer yazılım faaliyetleri gibi girdileri ve çıktıları için dokümantasyona ihtiyaç duymaktadır. Test sürecine girdi sağlayacak dokümanların (Gereksinimler, Plan dokümanları, ġartname vb.) yeterli detayda olmaması, süreç için gerekli verileri sağlayamadığı için süreci olumsuz etkilemesi beklenebilir.
Test faaliyetleri sonucunda çıktı olan, diğer test faaliyetlerine ve diğer yazılım geliĢtirme evrelerine girdi olacak dokümanların miktarı iyi belirlenmelidir. Eğer gerektiğinden fazla olur ise test faaliyetlerinin hızını düĢürme riski oluĢmaktadır.
Test dokümantasyonu miktarını belirlemek için IEEE 829 Standardı
kullanılmalıdır. Burada Önem Derecesi kavramı (Integrity Level) öne çıkmaktadır [
Test çalıĢmalarının oluĢturduğu doğal pozisyonlardan dolayı, yazılım geliĢtirme ekibi yazılım test ekibine direnç gösterebilir. Bu direnç yapılan çalıĢmaların verimliliğini düĢürecek boyutta olabilir. Test ekibinin bu duruma gelmemesi için proje yönetiminin test ekibini desteklemesi, yaptığı çalıĢmaların önemine inandığını geliĢtirici ekip içerisinde hissettirmesi gerekmektedir. Bu desteğin sağlanamadığı durumlarda test ekibi etkinliğini kaybedebilir. 2.9
Yazılım projelerinde baĢarısızlıkların nedenleri incelendiğinde, gereksinimler ile ilgili
sorunların en baĢta olduğu görülmektedir [
Test stratejisi, test teknikleri, önceliklendirme gibi noktaların belirlenmesinde fonksiyonel ve fonksiyonel olmayan gereksinimler incelenmektedir. Bu açıdan sistemde yer alan bir özelliğin, bir fonksiyonun gereksiniminin olmaması test sürecine negatif yansıyacağı öngörülebilir. Gereksinimler tanımlanırken sadece fonksiyonel isterlerin tanımlanması yeterli olmayacaktır. Fonksiyonel olmayan güvenlik (security), güvenilirlik (reliability), kullanılabilirlik, gibi özelliklerin de sistem içerisinde tanımlanması gerekmektedir. Ġsterler tanımlanırken uyulması gereken kurallar bulunduğu gibi isterleri değerlendirirken isterlerin taĢıması gereken özellikler de bulunmaktadır. Ġsterler doğru, doğrulanabilir, tam, net, sade, tutarlı, gerçekleĢtirilebilir, izlenebilir olmalıdır. Gereksinimlerin proje baĢlangıç aĢamasından itibaren tasarım, gerçekleĢtirme, test faaliyetleri aĢamaları için izlenebilirliğinin kurulmuĢ olması gerekmektedir. Proje yaĢam döngüsü süreçlerinde gözden geçirme (review) faaliyetleri önemli yer tuttuğu gibi isterler için de gözden geçirme çalıĢmaları yapılmalıdır. Yukarıda belirtilen özelliklere uygunluk durumu, izlenebilirliği de gözden geçirilmelidir. Ġsterlerin yazımı tamamlandıktan sonraki evrelerde müĢteri talepleri, tasarımsal değiĢiklikler gibi sebepler ile isterlerin değiĢtirilmesi söz konusu olabilir. Bu değiĢikliklerin etkilerinin değerlendirilmesi ve proje ilerleyiĢinde hesaba katılması gerekmektedir. Bahsedildiği gibi, gereksinimler üzerine inĢa edilmiĢ bir projede gereksinim değiĢiklik oranlarının yüksek olmaması dikkat edilmesi, incelenmesi, gerekli tedbirlerin alınması gereken bir durumdur. Bu durumların sonuçlarında test planlama, test özelliklerinin belirlenmesi faaliyetlerinin tekrar yapılacak olması test sürecini uzatacağı öngörülebilir. Birçok kiĢiden oluĢan ve farklı fiziki ortamlarda çalıĢanların olduğu projelerde gereksinimlerde yapılan değiĢikliklerin tüm ekip tarafında takip edilebileceği ve gerekli uyarılaarın yapılabileceği bir alt yapı kurulması diğer bir gerekliliktir. 2.10
Yazılım projelerinde test faaliyetlerini gerçekleĢtiren kiĢi veya kiĢilerin farklı bağımsızlık seviyelerinde oldukları durumlar görülmektedir. Her bağımsızlık seviyesinin pozitif ve negatif yanları bulunmaktadır. Bağımsızlık seviyesi arttıkça test mühendisinin önyargı ve ĢartlanmıĢlık seviyesi azalmaktadır. Dolayısı ile baĢkalarının göremediği hataları görebilirler. Bağımsız Test ekibi sistemin gereksinim ve tasarım aĢamalarında etkili olarak, testlerin baĢarılı bir Ģekilde gerçekleĢtirilmesini sağlamaktadır. Bağımsızlık seviyesi düĢükten yükseğe doğru Ģu Ģekilde sıralanabilir: ─ GeliĢtirmeyi yapan yazılımcı kendi kodunu test edebilir, ─ GeliĢtirme ekibinin içerisinde, ürünü kodlayan kiĢiden baĢka bir kiĢi test edebilir, ─ Aynı firma içerisinde, test için uzmanlaĢmıĢ ayrı bir ekip tarafından testler gerçekleĢtirilebilir, ─ BaĢka bir firmadan test iĢlerini yapacak ayrı bir ekip proje test faaliyetlerini gerçekleĢtirebilir.
Bağımsız test ekibi ile çalıĢmanın avantajları olduğu gibi, dezavantajları da sözkonusu olabilir. Tamamen bağımsız olma durumunda geliĢtirme ekibinden izole olunma ihtimali bulunmaktadır. Bağımsız test ekibi yazılım ekibi ile farklı fiziksel ortamlarda çalıĢtıklarından dolayı çalıĢanlar birbirlerini görmemektedir. Bu durum beraberinde, yazılım geliĢtirme ekibi için kalite duygusunun yitirilmesini getirebilir. 3 3.1
Test stratejisi ve yaklaĢımı projeye özgü bir Ģekilde belirlenmektedir. Test planlaması sırasında test yaklaĢımına karar verilir, detaylandırılır ve bu yaklaĢımdan yola çıkılarak test durumları, test aktiviteleri belirlenir. Test planlamasının ilk adımı test stratejisinin belirlenmesidir. YanlıĢ test yaklaĢımının belirlenmesi test sürecinde istenen hedeflere ulaĢılamamasına, tekrarlı iĢlerin yapılmasına, sürenin uzamasına neden olabilir. Kurumsal firmalarda daha çok görülen hatalardan biri de her projeye benzer test stratejisinin uygulanmak istenmesidir. Bir uygulamada baĢarılı olmuĢ bir test stratejisi, diğer bir projenin kendisine özgü durumundan dolayı istenen baĢarı seviyesinde olmayabilir.
Her projeye aynı test yöntemlerini uygulamama yaklaĢımını sistematik hale getirmek için önem derecesi kavramı kullanılabilir. Burada proje bir proje özelliğine göre (risk, sonuç vb.) seviyelendirilir. Daha sonra bu özelliğe göre projenin tamamı veya modüllerine bir önem derecesi tanımlanır. Bu önem derecesi kavramı temel alınarak, test sürecindeki dokümantasyon ve faaliyetlerin derinliği miktarı belirlenir. Böylece her projenin hatta her modülün özelliklerine göre test yaklaĢımı belirlenebilir.
Test yaklaĢımında yapılan diğer bir hata da test edilecek noktaların doğru belirlenememesidir. Genelde kolay test edilen kısımlar tekrar tekrar test edilirken, test edilmesi zor ama önemli alanlara yeterli önem gösterilmemektedir. Diğer bir durum ise test sürecinde tüm test durumları birden koĢturularak, diğerlerine göre daha önemli kısımlara aynı özen gösterilmektedir. Bu durum zamanın ve test eforunun etkin ve etkili kullanılmaması sonucuna çıkmaktadır. Bu durumda önceliklendirme yapılması gerekir. Sistemdeki karĢılıklarının önemlerine dayanarak test durumlarının önceliklendirilmesi gerekmektedir. 3.2
Proje planlaması yapılırken test süreçlerinin de planlaması gerekmektedir. Test
planları tüm test süreçlerini, test aktivitelerini, test giriĢ ve çıkıĢ kriterlerini, test
yaklaĢımlarını, takvimi, kabulleri ve varsayımları, test sürecinde kullanılacak araçları
tanımlamalıdır. Test dokümantasyonu IEEE Std. 829 standardında belirtilmiĢtir
[
Test Ana Planında (Master Test Plan) ve seviye test planlarında testlerin hangi kriterler sağlandığında tamamlanacağı bilgisi de yukarında belirtilen sebeplerden dolayı yer almalıdır.
Test süreçlerinde, nelerin test edileceğinin belirlenmesi yanında, nelerin test edilmeyeceğinin de belirlenmesi ve bu konuda paydaĢlar arasında anlaĢmaya varılmalıdır. Bu durum da taraflar arasında problemlere sebebiyet verebilir. 3.3
Test faaliyetlerinin gerçekleĢtirilmesi sırasında yaĢanabilecek tehlikelerden birisi de yeterli seviyede test edilememesidir. Yazılımın test edilmesi sadece bir yol takip edilerek doğru çalıĢtığının gösterilmesi değildir. Eğer sadece ana akıĢ (Happy Path) test edilirse sistemin çalıĢmayan yanlarının gösterilmesi için gösterilmesi gereken çaba gerçekleĢtirilmemiĢ ve amaca ulaĢılamaz. Bu durumu kontrol etmek ve test faaliyetlerinin hangi seviyede yapıldığının izlenmesi için etkili yöntemlerden birisi Test Kapsam Aracı (Test Coverage Tool) kullanmaktır. Bu araçlar yazılıma ait kodları izlemektedirler. Yazılım testleri yapılırken çalıĢtırılan kod parçalarını belirlemekte, iĢlem sonucunda da test faaliyetleri sonucunda çalıĢtırılan kodların, tüm kodlara oranını vererek bir kapsam yüzdesi vermektedir. 3.4
Yazılım geliĢtirme yaĢam döngüsü sırasında tüm evrelerde olduğu gibi test süreçlerinin de izlenmesi ve bu evreler hakkında bilgi sahibi olunması, çıkarımlar yapılması ve bu çıkarımlara göre gerektiği durumlarda sürece müdahale edilmesi gerekmektedir. Ölçüm iĢlemi doğru metriklerin alınması ile yani doğru soruların sorulması ile baĢlamaktadır. Yetersiz metrikleri olan bir test süreci yeterli ölçümleri yapamayacak, dolayısı ile doğru verilere ve çıkarımlara ulaĢamayacaktır. Bir projede en yaygın kullanılan test metrikleri aĢağıdaki gibidir: ─ Test durumları hazırlama aĢamasında, test durumlarının tamamlanma yüzdesi, ─ Test ortamı hazırlanmasında yapılması gereken iĢlerin yüzde kaçının tamamlandığı, ─ Testlerin koĢturulması safhasında test durumlarının ne kadarının koĢturulduğu, ─ Hata verileri, (hata sayısı, hata yoğunluğu, hata oranı, düzeltilen hata sayısı, düzeltilme iĢleminden sonra tekrarlanan testlerde baĢarı oranı), ─ Test kapsam yüzdesi (kod üzerinde), ─ Test mühendislerinin sisteme güveni, ─ Takvimsel kilometre taĢları, ─ Test maliyeti Örnekleri yukarıda verilen metriklerden veriler geldiğinde verileri değerlendirmek, riskler belirlemek ve bu riskler doğrultusunda kararlar almak gerekmektedir. Eğer riskleri belirleyecek, değerlendirecek ve gerekli tedbirleri alacak bir mekanizma kurulamaz ise proje takibi takip edilemez, plandan sapmalar tespit edilemez, projenin baĢarısını etkileyecek risklere karĢı gerekli müdahaleler yapılamaz. 3.5
Test faaliyetleri farklı alanlarda farklı stratejiler gerektirmektedir, örneğin güvenlikkritik bir sistemin testleri ile bir banka uygulamasının testleri farklı bilgiler, farklı alt yapı gerektirmektedir. Test mühendisinin projenin ilgili konusunda bilgiye sahip olması gerekmektedir. Test mühendisi yeterli bilgiye sahip değilse yapacağı testlerin istenen hedeflere ulaĢmasından Ģüphe edilebilir. 3.6
Test süreci sırasında bulunan hataların test ekibi tarafından raporlanarak yazılım geliĢtirme ekibine iletilmesi, yazılım geliĢtirme ekibi tarafından bu hataların analiz edilerek düzeltilmesi gerekmektedir. Bu iĢlemlerin yapılabilmesi için bulunan hataların geliĢtirme ekibine doğru ve tam olarak iletilmesi kritik öneme sahiptir. 3.7
Test araçları doğru kullanıldığında test faaliyetlerine yüksek katkıları olmaktadırlar. Bununla beraber, araçların yanlıĢ kullanılması test araçlarından alınan verimi düĢürmektedir.
Test araçları ile ilgili yapılan genel hatalar: ─ Gerçekçi olmayan beklentiler, ─ Gerekli sürelerin azımsanması, ─ Gerekli eforun azımsanması, ─ Araca gerekenden fazla güvenilmesi, ─ Araç için destek alınan firmanın desteği kesmesi, Ģeklinde sıralanabilinir. 3.8
Yazılım test sürecinde hatalardan dolayı yapılan düzeltmeler ve yeni geliĢtirme faaliyetler sonucunda kodda değiĢiklikler yapılmaktadır. Bu değiĢikliklerin sistemin ilgili alanlarında beklenmedik bir hataya sebebiyet verip vermediğinin kontrolü yineleme testleri (regresyon) ile yapılmaktadır. Bu testlerin yetersiz olması durumunda sistem içerisinde beklenmedik hataların çıkması ihtimali artmaktadır. 4
Yazılım ürününün baĢarısı, gereksinimleri karĢılaması ve müĢterilerin memnuniyeti ile ölçülebilir. Bu tanımlanan baĢarıya ulaĢmak için ürünün doğru süreçler iĢletilerek, gereksinimlerde tanımlanan Ģekilde sonuçlandırılması gerekmektedir. Bu amaç ile doğrulama ve geçerleme süreci yazılım projelerinin hedeflenen baĢarıya ulaĢmasında kritik bir yere sahiptir. Yazılımın doğrulama ve geçerleme faaliyetleri içinde değerlendirilebilecek test faaliyetleri geliĢtirilen ürünün istenen özelliklere uygunluğunun kontrol edilmesi açısından oldukça önemlidir. Bu faaliyetlerin etkinliği ve etkililiği çok farklı sebeplerden dolayı düĢebilir. Bu sebepler öngörülebilir ve önlem alınabilir sebeplerdir.
Teşekkür - Yazarlar, bu çalıĢmanın gerçekleĢtirilmesi için destek sağlayan TÜBĠTAK BĠLGEM Yazılım Test ve Kalite Değerlendirme Merkezi'ne teĢekkür eder.