Skip to main content
search

Risk nedir?

Aslında risk hayatımızın her alanında karşımıza çıkan , aldığımız kararlar neticesinde olumsuz olarak sonuçlanabilecek olayların gerçekleşme olasılığıdır. Bu olumsuz sonuçları önceden planlamamız gerekir, böylece riskin etkileri azaltabiliriz. Riski sınıflandırmamız gerekirse 2 risk boyutu ile karşılaşırız. Bunlar olasılık ve etkidir.

1- Olasılık

Risk her zaman bir olasılıktır. Risk olasılığı her zaman % 0 ile % 100 arasındadır. Olasılık asla % 0 olamaz; aksi takdirde risk asla oluşmaz. Asla% 100 olamaz; aksi takdirde, bu bir risk değildir; bu bir kesinliktir. Örneğin,% 99 doğru hesaplama yapan bir programımız olsun. Programın yanlışlık olasılığı nedir? Doğru tahmin ettin! Yüzde 1.

2- Etki

Risk doğası gereği olumsuz bir etkiye sahiptir. Bununla birlikte, etkinin boyutu bir riskten diğerine göre değişir. Risk oluşursa proje üzerindeki etkiyi belirlememiz gerekiyor. Aynı örnekle devam edersek hesaplama yanlış olursa bunun etkisi nedir? Yapılan yanlış hesaplama ile belki hayati bir önem barındıracak sonuç doğacaktır ve bu yüzden etkisi çok yüksektir!

 

Ürün riski nedir?

Bir çalışma ürününün kullanıcılarının ve/veya paydaşlarının belirli kalite ve gerekli ihtiyaçlarını karşılamaması ihtimalini içerir. Ürün risklerine örnek verirsek:

• Yazılım, gereksinime göre amaçlanan fonksiyonları yerine getiremeyebilir.

• Yazılım; kullanıcı, müşteri ve/veya paydaş ihtiyacına göre amaçlanan fonksiyonları yerine getiremeyebilir.

• Sistem mimarisi, fonksiyonel olmayan bazı gereksinimleri uygun şekilde desteklemeyebilir.

• Yüksek performanslı olması beklenen bir işlemin yanıt süreleri yetersiz olabilir.

 

Proje riski nedir?

Projenin hedeflerine ulaşma imkânı üzerinde olumsuz etkiye sahip olabilecek durumları içerir. Proje risk çeşitlerini farklı başlıklarda örnekler verelim:

 

Proje sorunları:

• Teslimatta, görevi tamamlamada , çıkış kriterlerinin veya tamamlandı tanımının karşılanmasında gecikmeler yaşanabilir.

• Yanlış tahminler, maddi kaynakların daha yüksek öncelikli projelere yeniden tahsis edilmesi veya kurum genelinde genel harcama kısıntıları, parasal kaynak yetersizliğine neden olabilir.

• Geç yapılan değişiklikler projede önemli ölçüde yeniden yapılması gereken işlere neden olur.

 

Kurumsal sorunlar:

• Yetkinlik, eğitim ve personel yeterli olmayabilir.

• Personel sorunları çatışma ve problemlere neden olabilir .

• Çakışan işletme öncelikleri nedeniyle kullanıcılara, işletme personeline veya konunun uzmanlarına ulaşılamayabilir.

 

Politik sorunlar:

•İletişim her şeydir! Geliştiriciler ve test ediciler birbirleriyle konuşmazsa ne olur? Yanlış ilerleyen etkileşim ekibe de iner ve böyle bir ortamda etkili test yürütülmesini engellenir.

• Test uzmanları ihtiyaçlarını ve/veya test sonuçlarını uygun şekilde iletmeyebilir

• Yazılımcılar ve/veya test uzmanları testlerde ve gözden geçirmelerde bulunan bilgilerin takibini yapmayabilir.

• Testlere ilişkin yanlış bir tutum veya yanlış beklentiler olabilir ( Örneğin tüm zor işi yaparsanız, ancak ekip toplantılarında yalnızca geliştirme çabaları takdir alırsa.)

 

Teknik sorunlar:

• Gereksinimler eksik tanımlanmış olabilir.

• Mevcut kısıtlamalar göz önüne alındığında gereksinimler yerine getirilememiş olabilir.

• Test ortamı zamanında hazır olmayabilir.

• Veri dönüşümü, taşıma planlaması ve bunların araç desteği geç kalmış olabilir.

• Yazılım geliştirme sürecindeki zayıflıklar; tasarım, kod, yapılandırma, test verileri ve test senaryoları gibi proje çalışma ürünlerinin tutarlılığını veya kalitesini etkileyebilir

• Yetersiz hata yönetimi ve benzer problemler, hata birikimi ve diğer teknik borçlarla sonuçlanabilir.

 

Tedarikçi sorunları:

Hizmet veya altyapı sağlaması gereken üçüncü bir taraf zamanında teslimat yapamaz. Gecikmelere ve kalite sorunlarına yol açabilir.

• Sözleşmeden kaynaklanan sorunlar projede aksaklıklara neden olabilir

 

Risklerle nasıl başa çıkacağız ?

Test Uzmanı risk faktörünün yazılımın kalitesi üzerindeki etkisini en aza indirebilmesi için bu risklerin farkında olması gerekir. Testlere yönelik risk bazlı bir yaklaşım, ürün riski düzeylerini azaltmak için proaktif fırsatlar sağlar.

Peki Test uzmanının projenin karşılaşabileceği her riski ele alması mümkün müdür?

Tüm pratiklikler, her riski planlamak için asla zamana ve kaynağa sahip olunmayacağının da farkında olmalıyız. Peki en aza indirmek için ne yapmalıyız?

• Kullanılacak test tekniklerini önceden belirleyebiliriz.

• Koşulacak testlerin seviyelerinin ve çeşitlerinin belirleyebiliriz.(ör. güvenlik testleri, erişilebilirlik testleri)

• Koşulacak testlerin kapsamının belirleyebiliriz.

• Kritik hataların mümkün olduğunca erken belirlenmesi için testlerin önceliklendirebiliriz.

• Riski azaltmak için testlere ek olarak yapılabilecek potansiyel aktivitelerin belirlenmesini ve uygulanmasını isteyebiliriz. (ör. deneyimsiz olan takım elemanlarına eğitim verilmesi)

• Neyin yanlış gidebileceğinin (riskler) analizi (ve düzenli olarak yeniden değerlendirilmesi)

• Hangi risklerin önlenmesinin önemli olduğunun belirleyebiliriz.

• Riskleri azaltmak için aksiyon alınmasında etkili iletişimde bulunabiliriz.

• Gerçekleşmeleri halinde risklerle başa çıkmak için acil durum planlarının yapabiliriz.

Ve son olarak Murphy yasasının belirttiği gibi “Onlara bir şans verirseniz, herhangi bir durumda işler ters gidecektir.”

 

Hazırlayan

Aydan Torun

Software Test Engineer  @Keytorc

Close Menu