Risk Faktörüne Genel Bakış

Risk, bir olayın olumsuz ya da istenmeyen bir şekilde sonuçlanma olasılığıdır. ISTQB’de ise risk faktöründen gelecekte olumsuz sonuçlanabilecek bir etki ya da olasılık olarak bahsedilir. Riskler bir problem oluştuğu zaman müşterinin, kullanıcının, ortakların ya da paydaşların ürün kalitesiyle ya da proje başarısıyla ilgili beklentilerini düşürmelerine sebep olur. Risk genelde duruma ya da bakış açısına göre çeşitlenebilen kişisel bir değer olarak algılanabilir. Risk, olması gereken durumun etkilerinin aksine istenmeyen bir durum olma olasılığını dengelemek için hesaplanır. Bunun karşılığında işin ne kadarının şansa bırakılabileceği görülmüş olur.

Özünde risk zamandan kaynaklanan belirsizlikler ile ilgili bir sorundur. Bir aktivitenin başlamasıyla bitişi arasında geçen zamanın etkisi, aktivitenin geliştirme sürecindeki çıktılar ile ilgili belirsizlik gösterir. Tüm riskler her zaman endişeye sebep olmamalıdır. Risk seviyesi iki özellik ile belirlenir.

Problemin oluşma olasılığı ve problem oluştuktan sonra beklenen ile planlanan sonuç arasındaki negatif değer sapması olarak tanımlanabilir.

Zaman ve teste ayrılan bütçe ne kadar fazlaysa o kadar test yazılabilir. Daha fazla test ile riskler direkt olarak ya da dolaylı olarak azaltılmış olur ve test aşamasında bulunan ürünün durumu hakkında paydaşlara daha kesin ve güvenilir bilgiler sağlanabilir.Bir ürünün ya da altsistemin risk seviyesini ölçebilmek için sırasıyla ürünün kendisinin ve çevresinin analizi ve durumu gereklidir. Ne kadar risk içerdiği belirlendikten sonra risklerin bir kısmının ya da hepsinin azaltılması ya da yokedilmesi için ölçütler alınır.Bu risklerin statik olmadığı akılda tutulmalıdır,riskler ürünün kendisi kadar dinamiktir.Riskler ortaya çıkarılır, silinir ya da değiştirilir.

77

Genel olarak riskler iki farklı kategoriye ayrılır.Ürün riskleri ve Proje riskleri:

a) Ürün riskleri

Ürün kalitesindeki potansiyel problemlerin belli olduğu yerlerde potansiyel problemler “ürün riskleri” ya da “kalite riskleri” olarak adlandırılır. Örnek vermek gerekirse güvenlik eksikliği canlı ortamda ürünün başarısızlığına sebep olabilir.Test disiplini bu tip risk gruplarına odaklanır. Test, ürüne fonksiyonel ya da fonksiyonel olmayan gereksinimler, ürünün karmaşıklığı ve güvenilirliği, dokümantasyon kalitesi ve yazılım kodunun kalitesi şeklinde bakar. Test etmek tüm bu ürün risklerinin uygun testlerle kapsanmasını amaçlar.

b) Proje riskleri

Yüksek kalitede olan gereksinim anlaşmaları, katı proje yönetim planları ürünün başarısını garantilemez. Bu iyi bir başlangıçtır ancak projeyi destekleyen yeterli kaynak yoksa başarı şansı azalır.Projenin başarılı olması için bir kaç önemli konu vardır.

 Personelin gerekli bilgi, yetenek ve beceriye sahip olması,  Doğru test araçlarının kullanılabilirliliği,

 Test ürünü için uygun ortamın bulunması,

 Konfigürasyon yönetimi gibi aktivite desteğinin verilmesi,  Tedarikçinin verimi.

Bu alanlardan birinde olan potansiyel problemler proje riski olarak adlandırılır.Bir sonraki bölümde incelenecek olan PRISMA yaklaşımı ürün riski için olan risk yönetimine ve riske yönelik teste odaklanır. Proje risk yönetimi ile ilgili tartışılan konular uygulanabilir. Yukarıda bahsedilen iki risk tipi bağımsız değildir.Ürün riskleri proje risklerine yönlenebilir. Yetersiz geliştirme yapılan üründe daha fazla hata bulunur ,daha fazla hata giderildiği için daha fazla tekrar testi yapmak gerekecektir bu yüzden projenin bitiş tarihi gecikir. Eğer yazılımcıların yeterli bilgi ve becerileri yoksa ürün hataya meyilli olarak ortaya çıkar.

78

Paydaşların, özellikle iş temsilcilerinin riskler üzerinde daha önce kazandıkları deneyimler vardır. Başarısızlıkla sonuçlanacak olan ürün risklerini görmek istemezler. Bir şekilde daha fazla ödeme yaparak bu risklerden kurtulmayı tercih ederler. Paydaşlar risk sorumluluğu alınmasında en önemli rolü üstlenirler ve bu yüzden risk tanımlama aşamasına, analizlere, önceliklendirmelere risk azaltma uygulamalarına dahil olmak zorundadırlar. Paydaşlar sistemin gerçek ortamdaki hareketlerinden de sorumludurlar.

Sistemin kurulması için son kararın verilmesi ve test ortamından canlı ortama taşınması kolay olmaz. Genelde bütçenin büyük bir kısmı pazarlamaya ve yeni ürünlerin geliştirilmesine ayrılır ya da mevcut ürünler şirketin önümüzdeki birkaç yıl içindeki pozisyonunu belirliyecektir. Sistem test ortamındayken hataların bulunup giderilmesi için fırsat vardır. Ancak sistem bir kere canlı ortama çıktığı zaman bu kararı veren kişi kendi üzerine dikkatleri çekmiş olur. Ürünün canlı ortama çıkma kararını testçi vermez. Testçi iş açısından paydaşlara bilgi sağlar. Testçiler kendi yönetimlerini sunar ve diğer paydaşları bağımsız bir şekilde bilgilendirirler.Bir ürünün yeteri kadar iyi olup olmadığı değerlendirileceğinde, testçi elde edilen bulguların faydalarının olduğunu ancak bazı ürün riskleri içerdiğini söylemelidir.Riskler izlenmeli gerekliyse tarih bilgisi tutulmalıdır.Testçiler paydaşların karar vermesine yardımcı olurlar ancak kendileri karar vermezler. Bazı ürün riskleri testçilerin bakış açısına göre sistemi kabul edilemez yapabilir eğer bu risklerin kritik olmasıyla ilgili paydaşlarla baştan anlaşmaya varıldıysa paydaşların bu risklerle ilgili algısı değişene kadar sistem kabul edilmemelidir.

Test için organizasyonun, riske olan bakış açısını algılamak önemlidir. Bazı organizasyonlar canlı ortama çıkarken kasıtlı olarak risk alırken bazıları tamamen riske karşıdır. Organizasyonlar belirli riskleri kabul etmek konusunda farklı davranışlar sergiler. Projenin ya da organizasyonun risk tutumunun anlaşılması, riske yönelik testle ilgili ya da risk yönetimiyle ilgili yaklaşımda etkili olana kadar önemlidir.

Özetle, test etmek, paydaşlara verilen bilgilerin doğruluğundan ve anlaşılabilirliliğinden emin olmamızı sağlar.

79 5.1.1 Test aktivitelerinin sınırlamaları

a) Ayrıntılı test

Test hataların bulunmasına, ürün risklerinin azaltılmasına, ürün riskleriyle ilgili bilgi edinilmesine ve ürün kalitesinin arttırılmasına yardımcı olur. Ne kadar testin yeterli olduğu ya da kesin sonuçlar için ne kadar bilginin gerekli olduğu tartışılabilir. Bu aşamada seçenekler ortaya çıkar. Sistemdeki herşeyin test edilmesi, hiçbirşeyin test edilmemesi ya da sistemin bir kısmının test edilmesi bu seçenekler arasındadır. Yöneticiler herşeyin test edilmesi konusunda hem fikirse bu, sistemin her yönünün tüm durumlarının uygulanması anlamına gelir. Ancak sistemi yüzde yüz kapsamayla test etmek imkansızdır. Ayrıca hiçbir şirket kaynakların büyük bir kısmını bu şekilde harcamak istemez.

Projede zaman ve parayla ilgili baskı, projenin gereksinimlerinin karşılanmasıyla ilgili baskı kadar fazladır.Kaynaklar herzaman limitlidir. Proje yöneticileri onlara yatırım olarak dönmesini sağlayacak şekilde bir test süreci isterler. Proje sürümü yayınlandıktan sonra önlenecek hatalar pahalıya mal olacaktır.

b) Test sürecinin sıkıştırılması

En çok bilinen test zaman aşımı, yazılımcıların testçilere olan teslimatı geciktirmesiyle son testlimatın tarihinin aynı kalması durumunda oluşur. Tamamlama kriterleri bir sonraki aşamada ne olacağını belirler ancak genelde bu kriterler zamanında karşılanmaz. Sürümün çıkmasıyla ilgili baskı kriterlerin sağlanması şartının yerine getirilememesini sağlar.

c) Tamamlama kriterleri

Özel ve genel durumlar için sürecin tamamen bitirilmesine izin verilmesi için paydaşların anlaşmaya varmış olması gerekir. Bitiş kriterlerinin amacı henüz tamamlanmamış olan işlerin tamamlanmış gibi kabul edilmesini önlemektir. Bitiş kriterleri testin ne zaman bitirileceğinin planlanmasını sağlar.

Bazı önemli hataların giderilemesi ya da ürün risklerinin azaltılması için girişimler yapılabilir.Bitiş kriterleri tanımlanan kalite hedefleri için hatırlatıcı niteliktedir ve projenin erken evrelerinde bununla ilgili anlaşmaya varılır. Test süreci sıkıştığı zaman, bazı ürün riskleri göze çarparken ,testçiler yeni ürün

80

riskleri ortaya çıkarabilirler bu durumda göze çarpan ürün risklerinin hepsi kapsanmalıdır. Eğer paydaşlar ürünün bu şekilde ortaya çıkmasına karar verirlerse daha sonra ortaya çıkacak olan ürün riskleri testçilerin problemi değildir.

5.1.2 Test sürecinin risk odaklı yürütülmesi

Herşeyi test etmek mümkün olmadığı ve testin sıkıştırılması gerekmediği zaman, ürünün ve projenin doğru kısmının test edilmesi için bir yaklaşıma ihtiyaç vardır. Bu testin odak noktalarının bulunmasıyla ve ürün riskleriyle ilgili testlere yönelinmesiyle olur. Ürün risklerinin değerlendirilmesi ve yönetilmesi her proje için en önemli, aynı zamanda en kritik aktivitelerdendir. Ne kadar testin yeterli olacağına karar vermek için ürün ve proje risk seviyelerine göre zaman ve para kısıtlamalarının ne kadar olacağı da hesaba katılmalıdır.

Ürün risk değerlendirmesi ne kadar testin gerektiğine karar vermek için gerçekleştirilir. Riskin seviyesine ve tipine göre tanımlama yapılır, test yaklaşımı, test eforu ve gerekli testlerin dağılımı çeşitlendirilir. Test süreci, sistemin bir sonraki geliştirmeye kadar test edilmiş olduğuna paydaşları ikna etmelidir. Bütçedeki, zamandaki ve test sürecindeki kısıtlamalar ürün riskine yönelik teste öncelik verilmesi gerektiğini göstermiştir.