Risk Bazlı Test için Nihai Kılavuz: Yazılım Testinde Risk Yönetimi

ultimate guide risk based testing

Örneklerle Risk Temelli Test, Risk Yönetimi ve Yaklaşımı İçin Nihai Kılavuz:

Risk Temelli Test Nedir?

Risk temelli test, müşteri tarafından belirlenen işletme üzerinde olumsuz etki yaratacak en önemli iş risklerinin yaşam döngüsünün başlarında ürünlerinde veya özelliklerinde ortaya çıkarılacağı ve senaryoların test edilmesi veya tasarlanması ve yürütülmesidir. hafifletme önlemleri uygulayarak hafifletilir.

=> Tam Test Planı Eğitim Dizisi İçin Buraya Tıklayın

Olumsuz etki, maliyet etkisi, memnuniyetsiz müşteri, kötü kullanıcı deneyimi ve hatta müşterileri kaybetme derecesini içerebilir.

Başka bir deyişle, RBT yaklaşımı, testin bir kullanıcı olsa bile yapılmasını sağlamaktır. bir hata bulur üretimde, yazılımı kullanmasını engellemeyen veya işi ciddi şekilde etkilemeyen.

RBT, ürün risklerine göre gerçekleştirilen testlerdir. RBT, test senaryoları için bir önceliklendirme tekniği kullanarak, üretimdeki belirli bir özelliğin veya işlevin başarısız olma riski ve bunun işletme üzerindeki etkisinin maliyet ve diğer zararlar açısından ne olduğunu önceden tespit etmektir.

Bu nedenle, Risk Temelli test etme ilkesini kullanır testleri önceliklendirmek bir ürün veya yazılımın özellikleri, modülleri ve işlevleri. Önceliklendirme, o özelliğin veya işlevin üretimde başarısız olma olasılığı ve bunun müşteriler üzerindeki etkisine dayanır.

Ne öğreneceksin:

• Risk Temelli Testler ve Çevik ve DevOps ile İlişkisi
  • Risk Temelli Test Yaklaşımı
    • RBT Yaklaşımını Ne Zaman Kullanıyoruz?
    • RBT Yaklaşım Örneği
  • Risk Analizi Yapmanın Yolları
  • Risk Analizi Prosedürü
  • Risk Analizi Metodolojisi
    • Adım # 1) 3X3 ızgara kullanma
    • Adım # 2) Başarısızlığın Olasılık ve Etkisi
    • Adım 3) Öncelik Tablosunu Test Etme
    • Adım # 4) Testin Ayrıntıları
  • RBT, Agile ve DevOps ile Nasıl Alakalı?
  • Risk Temelli Test yaklaşımının faydaları
• Test Planlama Sırasında Risk Yönetimi
  • Risk Yönetimi Süreci
    • # 1) Risk Tanımlama
    • # 2) Risk Değerlendirmesi / Risk Etki Analizi
    • # 3) Risk Azaltma
  • Sonuç
• Test Yürütme Aşamasında Risk Yönetimi (Örneklerle)
  • Risk Yönetimi - AUT Odaklı
  • Risk Bazları Testi Nasıl Gerçekleşir?
  • Sonuç
  • Önerilen Kaynaklar

Risk Temelli Testler ve Çevik ve DevOps ile İlişkisi

Yazılım geliştirmek için harcanan 300 saat, üretimde tespit edilen tek bir kusurla yalnızca 30 saniyede işe yaramaz hale getirilebilir.

Bu da başka bir seçenek olmaksızın tüm ürünün amacını mahvedebilir, sadece onu piyasadan çekebilir. 'Kalite testi' nin önemi ve ihtiyacı da budur.

Teknolojideki hızlı büyümeyle birlikte yazılım, çoklu işletim sistemini, çoklu platformları, karmaşık BT altyapılarını vb. Destekleyen bulutta barındırılıyor, son kullanıcılar özellikler, seçenekler konusunda gittikçe daha titiz oluyor ve müşteri memnuniyeti için asla ödün vermiyorlar. .

Günümüzde, 'Kalite', müşterileri mutlu etmek için kaliteyi iyileştirmek için sürekli iyileştirmelerin yapıldığı yazılım dağıtımında çok önemli bir faktör haline geliyor.

Hemen hemen tüm Test Uzmanlarının, test pencerelerinin daraltılmasının ve tipik olarak yapının son dakikada test edilmek üzere kendilerine teslim edilmesinin çok büyük bir baskı altında olmasının yaygın bir sorun olduğunu sıklıkla fark ederiz. Tasarladıkları tüm testleri yapmaları için yeterli zaman ve kaynak yoktur ve otomasyon kapsamı her zaman% 100 değildir ve kendi zorlukları vardır.

Teslimat zaman çizelgesi kaçırılamaz ve aynı zamanda kaliteden de ödün verilemez. B planı ne olursa olsun, diğer takımlardan çekilerek ek test kaynakları eklemek, çalışmıyor, Plan C, diğer tüm aktiviteleri yapmayı bırak ve çabayı tek başına buna yönelt, gerçekten yardımcı olmuyor. Ancak sonuçta test kaynaklarının çok fazla eklenmesi işe yaramıyor.

Mevcut zaman ve kaynaklar dahilinde sınırlı ve önemli testler yapmaktan başka seçenek yoktur.

Peki bu aşamada hangi testin önemli olduğuna nasıl karar vereceğiz? Bir Test Cihazının önemli olduğunu düşündüğü şey, müşteriler için gerçekten önemli olmayabilir. Özelliğin veya bir işlevin önemi kimin bakış açısından belirleniyor? Önemli testlerin hangileri olduğuna kim karar verecek? Ve birçok başka soru ortaya çıkmaya devam ediyor.

Tüm bu soruları cevaplamak ve yukarıdaki durumu etkin bir şekilde ele almak için, denilen bir test yaklaşımı 'Risk Temelli Test' kısaca aradı 'RBT' , ekibin test senaryolarını 'Proje Riski' kriterlerine göre açıkça planladığı ve tanımladığı yerde ortaya çıktı.

Kalite Güvence ekibi önemli testlerin net bir resmine sahip olsa da, RBT, müşteri ve işletme perspektifinden önemli ve önemli testleri bir test aracılığıyla tanımlamanın kanıtlanmış bir yöntemidir. 'Risk analizi' prosedür .

Dolayısıyla, artık yazılımdaki hataları basitçe tanımlamanın geleneksel yoluna karşı, kalite güvencesi yaklaşımı ve hedefi, teknolojideki değişim, piyasadaki rekabetin artması, kaliteli bir yazılımın piyasaya sürülmesi nedeniyle zamanla değişmiştir. 'Her Şeyi Otomatikleştirin' ve Agile ve DevOps uygulamalarının bir bütün olarak birkaç saatlik bir süre içinde yazılım teslim etme uygulaması.

Dolayısıyla, mevcut 'Test İlkesi' eğilimi yalnızca 'kusurları tanımlamak' değil, aynı zamanda,

# 1) Üretimdeki başarısızlık veya yüksek başarısızlık olasılığı nedeniyle iş üzerinde yüksek bir etkinin olduğu ürün alanına odaklanın.

#iki) Odaklanmak kusurları belirlemek erkenden ve bir ekibin bunu olabildiğince erken düzeltmesine ve dolayısıyla yazılımın / ürünün veya özelliğin 'Hızlı Başarısız'.

# 3) QA ekibinin şu anda Hizmetinin en önemli yönü, odak noktasını artırarak müşteriye değer katmak için müşteriye odaklanmaktır. 'Uçtan uca müşteri deneyimi'.

Risk Temelli Test Yaklaşımı

Her zaman bir sınava hazırlanmak gibidir, çok sayıda test tasarlayıp yürütseler bile, testin yeterli olduğunu ve yazılımda artık kusur olmadığını söyleyemezsiniz.

Yalnızca test senaryolarının sayısını artırarak yazılım kararlılığının iki katına çıkmayacağı bir nokta vardır. Zamanın bu noktasında, sadece test sayısına odaklanmak değil, müşterinin gerçekte sürümden ne beklediğine odaklanmaktır.

Bu nedenle, makul test çabasıyla maksimum faydayı elde etmek için testi optimize etmede bir denge kurmak çok önemlidir. Ve test zaman çizelgeleri çok sıkı olduğunda ve yeterli testi gerçekleştirmek için yeterli kaynak bulunmadığında bu daha önemlidir.

Bu nedenle, bu durumda, RBT yaklaşımı, QA çabasını optimize etmede ve minimum iş riski ile test avantajını en üst düzeye çıkarmada önemli bir rol oynar.

Dolayısıyla, yukarıdaki yöne odaklanırsak, o zaman bir kalite güvencesinin çalışması çok rahatlayacaktır. Hafta sonlarını ofiste yakmaları, yazılımı sürekli olarak test etmeleri ve testten çıkan her S4 (Önem Derecesi 4) ve P4 (Öncelik 4) kusurları için endişelenmeleri gerekmez.

4, testteki kusurların en düşük önceliği ve ciddiyeti olarak kabul edilir. Zamanlarını projenin diğer yararlı yönlerine daha iyi harcayabilirler.

'Risk temelli test' yaklaşımının temel itici güçlerini özetlemek için:

• İş açısından 'müşterilerin ne istediğini' test etmeyi etkinleştirmek için.
• Zaman çizelgesini beklenen kalitede karşılamak için.
• QA çalışmasını optimize etmek için.

RBT Yaklaşımını Ne Zaman Kullanıyoruz?

Bu, aşağıdaki senaryolarda kullanılır:

• RBT yaklaşımı, bir projenin Zaman, maliyet ve kaynakları üzerinde bir sınırlama veya kısıtlama olduğunda ve kaynakları optimize etme ihtiyacı olduğunda kullanılabilir.
• RBT yaklaşımı, program daha karmaşık olduğunda ve yeni teknolojiyi uyarladığında ve bu nedenle çok sayıda zorluk içerdiğinde kullanılır.
• Program bir Ar-Ge projesi olduğunda ve birinci türden olduğunda ve projede bir takım bilinmeyenler ve riskler olduğunda.

RBT Yaklaşım Örneği

BT endüstrisinde üretimin karşılaştığı risklerin ve etkisinin üstesinden gelmek için çeşitli Risk Tabanlı analiz yaklaşımları kullanılmaktadır.

Aşağıda verilen bu tür bir yaklaşımdır:

Bu RBT yaklaşımı, ürünün 'Hayati İşlevselliklerini veya Temel Özelliklerini' tanımlamayı ve bu işlevlerin her birinin üretim sırasında maruz kaldığı riskleri değerlendirmeyi ve riski azaltmak veya hafifletmek için uygun hafifletme önlemlerinin uygulanmasını içerir.

Dolayısıyla, RBT yaklaşımı, başarısızlık olasılığına ve iş üzerinde en yüksek etkiye sahip olan işlevlerin test edilmesini içerir. Arıza türleri operasyonel veya ticari, teknik, harici vb. Olabilir.

Risk Analizi Yapmanın Yolları

Bir ürünün her bir özelliği için Yazılım testinde risk analizini gerçekleştirmek için bu şekilde tanımlanan standart bir süreç veya şablon yoktur. Çeşitli kuruluşlar, risk analizi yöntemlerinde kendi yaklaşımlarını kullanır.

Riskleri belirlemek ve analiz için bir RBT yaklaşımı uygulamak için çeşitli proje öğeleri üzerinde risk analizi yapılabilir. Bu öğeler şunları içerir:

• Özellikleri
• İşlevsellikler
• Kullanıcı hikayeleri
• Gereksinimler
• Kullanım Durumları
• Test Durumları

Bu durumda, Risk Temelli Test yaklaşımı uygulamasını anlamak için yalnızca Test senaryolarına odaklanalım.

Risk Analizi Prosedürü

Risk analizi, programın ilgili paydaşlarının hem ' Teknik Ekip ve İş Ekibi ’ , Ürün Sahibi, Ürün Yöneticileri, İş Analistleri, Mimarlar, Test Uzmanları ve Müşteri Temsilcileri içerir.

Bu paydaşları içeren beyin fırtınası oturumları, bir ürünün her bir özelliğinin önemini belirlemek ve bunları üretimdeki son kullanıcılar üzerindeki başarısızlık riski ve etkisine göre önceliklendirmek için tartışmayı yürütmek üzere organize edilecektir.

Gereksinimler Dokümanı, Teknik Şartname Dokümanları, Mimari ve Tasarım Dokümanları, İş Süreci Dokümanı, Kullanım Örneği Dokümanı gibi çeşitli 'Proje Dokümanları' beyin fırtınası oturumunun girdisi olacaktır.

Paydaşların ürün ve pazardaki mevcut ürün hakkındaki bilgisi de tartışma için bir girdi faktörü olacaktır.

Birkaç başka girdi kaynağı da şunları içerebilir:

• En çok kullanılan işlevsellik hakkında girdi toplamak için.
• Bir alan uzmanına danışmanın girdileri.
• Piyasadaki ürünün veya benzer ürünün önceki sürümüne ait veriler.

Sırasında beyin fırtınası oturumda, bu özelliklerin her birine ait riskler belirlenir. Risk türleri bir operasyon, teknik veya işle ilgili olabilir. Bunlarla ilgili testler ve senaryolar ağırlıklandırılır ve riskin oluşma olasılığı ve riskin etkisine göre risk değerleri değerlendirilir.

'Risk oluşma olasılığı' şunlardan kaynaklanabilir:

• Ürün geliştirme ekibi tarafından özelliğin yeterince anlaşılmaması.
• Uygun olmayan mimari ve tasarım.
• Tasarlamak için yetersiz zaman.
• Takımın yetersizliği.
• Yetersiz kaynaklar - insanlar, araçlar ve teknoloji.

'Riskin Etkisi', başarısızlığın kullanıcılar ve gerçekleşmesi durumunda iş üzerindeki etkisidir. Etki olabilir,

• Maliyet etkisi, kayıpla sonuçlanır.
• İş kaybetmeye veya pazar payını kaybetmeye neden olan ticari etki, Hukuk davaları, Lisans kaybı.
• Kalite etkisi, standartların altında veya yetersiz ürün sürümüyle sonuçlanır.
• Kötü kullanıcı deneyimi, memnuniyetsizliğe ve müşteri kaybına neden olur.

Bir özelliğin veya ürünün riskinin değerlendirilmesinin odak alanı şunlar olabilir:

• İş Alanının işlevselliğinin kritikliği.
• En çok kullanılan özellikler ve önemli işlevler.
• Kusurlu alanlar
• Güvenlik ve güvenlik etkisini taşıyan işlevsellik.
• Karmaşık Tasarım ve Mimari Alanı.
• Önceki sürümlerden yapılan değişiklikler.

Risk Analizi Metodolojisi

Şimdi 'Risk Temelli test metodolojisini' ayrıntılı olarak anlayalım.

Risk Temelli test yaklaşımı, test döngüsünün tüm test aşamalarında kriter olarak RISK'i kullanır, yani, test planlaması , test tasarımı, test uygulaması, Test uygulaması ve test raporlaması. İdeal olarak, çok sayıda olası test senaryosu kombinasyonu tasarlanabilir.

Bu nedenle, RBT yaklaşımı, işletme üzerinde yüksek bir etkiye neden olan en kusurlu veya riskli başarısızlık alanını bulmak için risklerin ciddiyetine göre testlerin bir sıralamasını içerir.

Risk analizinin temel amacı, 'Yüksek değer' ürün özellikleri, işlevleri, gereksinimleri gibi öğeler, Kullanıcı hikayeleri ve test senaryoları ve ‘ Düşük değer' ve dolayısıyla daha sonra, 'Düşük değerli' Test Durumlarına daha az odaklanarak 'Yüksek Değerli' Test Durumlarına daha fazla odaklanır. Bu, Risk Bazlı teste başlamadan önce Risk analizinin ilk adımıdır.

Test Durumlarının Yüksek Değer ve Düşük Değer olarak Sınıflandırılması veya gruplandırılması ve bu test senaryolarının her birine öncelik değerinin atanması ana görevi aşağıdaki adımları içerir:

Adım # 1) 3X3 ızgara kullanma

Risk analizi, her bir işlevsellik, işlevselliksizlik ve ilgili Test durumlarının bir paydaşlar ekibi tarafından 'OlasılıkBaşarısızlık 've' Başarısızlığın Etkisi '.

Üretimdeki her bir işlevin başarısız olma olasılığına genellikle bir grup 'Teknik Uzman' tarafından erişilir ve ızgaranın dikey ekseni boyunca 'Başarısız olma olasılığı oldukça yüksek ve olası değil' olarak kategorize edilir.

deneyimli kişiler için yazılım testi mülakat soruları

Benzer şekilde, bu özelliklerin ve işlevlerin üretimdeki 'başarısızlığının etkisi' son müşteri tarafından deneyimlenir, test edilmezse bir grup tarafından değerlendirilir. ' İş Uzmanları ”ve ızgaranın yatay ekseni boyunca' Küçük, Görünür ve Kesinti 'kategorileri altında kategorize edilir.

Adım # 2) Başarısızlığın Olasılık ve Etkisi

Tüm Test senaryoları, aşağıdaki resimde noktalar olarak gösterilen arıza olasılığı ve arızanın etkisinin tanımlanmış değerlerine dayalı olarak 3 X 3 ızgaranın çeyreğinde konumlandırılmıştır.

Açıkça görüldüğü gibi yüksek arıza olasılığı ve yüksek arıza etkisi (kesinti), çok önemli olan ızgaranın sağ üst köşesinde gruplandırılmıştır ve bu nedenle 'Yüksek Değer' testlerinin ve 'Düşük Değer' testlerinin gruplandırıldığı tespit edilmiştir. Müşteri için en az önemli olan veya hiç önemi olmayan sol alt köşede, bu özelliklere veya test senaryolarına çok az odaklanılabilir.

Adım 3) Öncelik Tablosunu Test Etme

Şebekede yukarıdaki test senaryolarının konumlandırılmasına bağlı olarak, testler önceliklendirilir ve 1,2,3,4 ve 5 öncelikleri ile etiketlenir ve her birine göre işaretlenir. En önemli testler, 1^st1. önceliğe sahip ve benzer şekilde daha az önemli olan ızgara 2, 3, 4 ve 5 olarak sıralanır.

Son olarak, tüm test senaryoları öncelik numaralarına göre sıralanır ve öncelik sırasına göre yürütülmek üzere alınır. Yüksek öncelikli olanlar önce yürütme için alınır ve düşük öncelikli olanlar daha sonra yürütülür veya kapsamı kaldırılır.

Adım # 4) Testin Ayrıntıları

Bir sonraki adım, tanımlanan test kapsamı için testin ayrıntı düzeyine karar vermektir. Test kapsamının derinliği, aşağıdaki tabloya göre yukarıdaki sıralamaya göre belirlenebilir.

1. sıraya sahip yüksek öncelikli testler 'Daha Kapsamlı' test edilir ve buna göre uzmanlar, bu yüksek kritik özellikleri ve ilgili Test Durumlarını test etmek için görevlendirilir. Benzer şekilde, öncelik 2, 3 ve 4 olan durumları test edin. Öncelik 5 özelliklerinin kapsamını kaldırma kararı ve mevcut zaman ve kaynaklara dayalı testler alınabilir.

Bu nedenle, özellikleri ve test senaryolarını öncelik sırasına koyan Testin Ayrıntı Düzeyi yaklaşımı, Test Uzmanlarının yalnızca 'Yüksek Değerli Testleri' belirlemelerine yardımcı olmakla kalmaz, aynı zamanda bu öncelik sıralamalarına dayanarak 'test ayrıntı düzeylerine' karar vermelerine de rehberlik eder. daha iyi testler yapmalarına yardımcı olur ve optimizasyon süreciyle test maliyetlerini düşürür.

RBT, Agile ve DevOps ile Nasıl Alakalı?

Şimdi, belirli bir özelliğin 'Başarısızlık Riski' ne ve canlı olarak 'Müşteriye Etkisi' ne bağlı olarak testlerin önceliklendirilmesine dayalı testlerin gerçekleştirilmesine ilişkin Risk Temelli Test yaklaşımını anladıktan sonra, açıkça şu soruyu gündeme getirebiliriz: Çevik ve DevOps Uygulamalarında Risk Temelli Test yaklaşımının alaka düzeyi.

'Her Şeyi Otomatikleştir', 'Her Şeyi Test Et', 'Sürekli Test Et', 'Tekrar Tekrar Test Et' bu uygulamaların temel kavramlarıdır.

Her seferinde, kodda bir değişiklik olduğunda veya bir sürüm olduğunda, tasarlanan tüm testler otomatik olarak çalıştırılır. Sürekli Entegrasyon (CI) / Sürekli Teslimat (CD) öncelik sırasına bakılmaksızın hızlı ve tekrar tekrar boru hattı.

O halde RBT ve DevOps arasındaki ilişki nedir? RBT, Agile ve DevOps'ta nereye sığar ve alakalı hale gelir ???

# 1) Evet, daha önce de söylediğim gibi, her Sektörün ve her ürünün test uygulamaları için% 100 otomasyon kapsamı olduğu anlamına gelmez. Bu nedenle, ekip manuel test senaryolarının seçiminden test yürütme için önceliklendirme seçimi yapmak zorundaysa ve test kaynaklarının enerjisini ve çabasını diğer faaliyetlere ayırmak istiyorsa, RBT en iyi seçimdir.

Risk Temelli yaklaşım aynı zamanda yüksek öncelikli olan otomatik testleri çalıştırmak ve en erken test etmek için daha iyi bir bahistir.

#iki) Kalite Güvencesi ekibi, Gereksinim Analizi sırasında gereksinimleri analiz etmede ve ürünlerin ve özelliklerin olası risklerine ilişkin önceden bir rapor sunmada RBT yaklaşımını daha etkili bir şekilde benimseyebilir, böylece program ekibi bunu azaltmak için proaktif olarak uygun eylemler gerçekleştirebilir.

# 3) RBT yaklaşımı, Test Durumlarının ve Yüksek riske dayalı senaryoların tasarlanmasında etkili bir şekilde kullanılabilir, böylece yüksek riskli özellikler ve işlevlere daha fazla odaklanılabilir.

# 4) 'Yüksek Risk' alanlarının belirlenmesi, QA ekibinin 'Yüksek Yetenekli Test Uzmanlarını' kullanarak 'Daha kapsamlı' testler yapmak için Test çalışmalarını bu alanlara odaklamasına olanak tanır.

# 5) Hepimizin bildiği gibi 'Hızlı Başarısız', RBT yaklaşımının yazılımdaki 'yüksek riskli' alanların tanımlanmasına yardımcı olduğu, kusurları erken belirlediği ve hızlı ve başarısız olmalarına izin veren 'Çevik' ve 'DevOps' kavramıdır. önce ve bırakın takım düzeltsin.

# 6) Çevik / DevOps'un nihai hedefi 'Müşteri odaklılıktır' ve dolayısıyla RBT yaklaşımı, Kalite Güvencesinin sadece Kusurları bulmaktan çok müşteri deneyimine odaklanmasını sağlar.

Risk Temelli Test yaklaşımının faydaları

Gereksinimleri analiz etmek, test senaryolarını tasarlamak ve yürütmek için RBT yaklaşımının amacını ve kullanımını zaten anladık. RBT'nin çeşitli faydaları vardır.

Risk Temelli Testin faydalarını şu şekilde birleştirebilir ve listeleyebiliriz:

• Test Kaynaklarının daha verimli ve optimize edilmiş kullanımına yardımcı olur.
• Önceliklendirerek QA çalışmasını, Test, Test Tasarım ve Geliştirme ve Test Hazırlama faaliyetlerini kolaylaştırmaya yardımcı olur.
• Temel kaynakları yüksek odak alanlarına tahsis ederek QA kaynaklarının daha iyi yönetilmesine yardımcı olur.
• Kaynakların etkin kullanımına yardımcı olur ve zamanlarını ve enerjilerini projede daha iyi şeylere yönlendirir.
• QA ekibinin, değişken ve yüksek riskli alanların risk değerlendirmesine ve tanımlanmasına dayalı olarak test çabalarını planlamasına yardımcı olur.
• Ekibe, önemine bağlı olarak yapılacak testleri optimize etmesine ve dolayısıyla paydaşlarla mutabık kalınarak düşük değerli testlerin kapsamını kaldırmasına yardımcı olur.
• Genel olarak optimize edilmiş ve azaltılmış test faaliyetleri yoluyla Maliyetin düşürülmesine yardımcı olur.
• RBT yaklaşımı, QA ekibinin önce yüksek riskli alanları test etmesine ve ürünün 'Hızlı bir şekilde başarısız olmasına' ve hızlı bir şekilde düzeltmesine olanak tanır.
• RBT yaklaşımı, ' Test kapsamı' ve tüm Paydaşlar grubuna 'Test Kapsamı'.
• Ekip, Yüksek riskli alanlara odaklanmayı artırabilir ve düşük riskli alana daha az odaklanmaya devam edebilir.
• RBT, Ekibin ürün riskleri için en etkili azaltma yönteminin uygulanmasına önceden karar vermesine olanak tanır.
• RBT, uygun olmayan azaltma uygulamalarının etkisinden kaçınmaya yardımcı olur.
• Risk Temelli Test, ekibin ya acil durumu hafifletmek ya da planlamak için uygun eylemi gerçekleştirmesine ya da hatanın üstesinden gelmek için herhangi bir geçici çözüm konumlandırmasına ya da risk Live'da meydana gelirse etkisini azaltmasına olanak tanır.
• RBT, sürümdeki artık riski en aza indirmeye yardımcı olur.
• Üretimde daha az maliyetli kusurlar yoluyla 'İyileştirilmiş Kalite' ye ulaşılmasına yardımcı olur.
• Nihayetinde 'Gelişmiş müşteri deneyimi' ve 'Memnun Müşteri' ye yardımcı olur.

Daha sonra, Yazılım Test Yaşam Döngüsünün Test Planlama ve Test Yürütme aşamalarında riskleri nasıl yöneteceğimizi öğreneceğiz.

Test Planlama Sırasında Risk Yönetimi

Test Planlama Aşamasında Riskler Nasıl Yönetilir:

Hayat risklerle doludur, bir yazılım projesi de öyle. Her an her şey ters gidebilir. Her şeyi düzeltmek için her zaman ayak parmaklarımızdayız - peki ya hiçbir şeyin ters gitmemesini sağlamaya ne dersiniz? Risk yönetimine girin - bu, bizi riskleri önlemeye, anlamaya, bulmaya ve üstesinden gelmeye hazırlayan bir yazılım test projesinin bir bölümüdür.

Risk, basitçe ortaya çıkması muhtemel bir sorundur ve gerçekleştiğinde bir kayba neden olur.

Kayıp herhangi bir şey olabilir - para, zaman, çaba veya kaliteden ödün verme. Kayıp asla iyi değildir. Ne kadar döndürürsek verelim, olumlu değil ve asla olmayacak. Bu nedenle Risk yönetimi riskleri ele aldığımızdan ve kayıpları önlediğimizden / azalttığımızdan emin olmak için yazılım projelerinin ayrılmaz bir parçasıdır.

Risk Temelli Test : Bir QA topluluğu olduğumuz için, yalnızca QA dünyamızda risklere ve bununla ilgili sürece özel kalmamıza izin verin. Riskler, kabaca 2 aşamada değerlendirilir ve yönetilir. Yazılım Testi yaşam döngüsü . STLC, 3 aşamaya ayrılabilir - Test Planlama, Test Tasarımı ve Test Yürütme.

Risk Yönetimi süreci şu durumlarda iki kez gerçekleşir:

1. Test Planlama
2. Test Senaryosu Tasarımı (son) veya bazen Test Yürütme aşamasında

1. durumda zorunludur, ancak 2. durumda daha çok 'ihtiyaç temelli' bir durumdur.

İki bölümden oluşan makale dizisi:

Altta yatan süreç aynı olsa da, Risk türleri her iki alanda da ele alınan tamamen farklıdır. Onlara ayrı ayrı adalet sağlamak için iki bölümlük bir dizi olarak farklı şekilde ele alacağız.

Bu bölüm 'Test Planlama Sırasında Risk Yönetimi”.

Risk Yönetimi Süreci

Risk Yönetimi için genel süreç 3 önemli aşamadan oluşur:

1. Risk tanımlaması
2. Risk Etki Analizi
3. Risk azaltma

Test Riskleri ve Etki Azaltma Örnekleri:

# 1) Risk Tanımlama

Söylendiği gibi, bir problemi çözmenin ilk adımı onu tanımlamaktır. Bu aşama, potansiyel olarak ortaya çıkabilecek ve olayların normal akışını bozabilecek her şeyin bir listesini yapmayı içerir.

Bu adımın ana sonucu bir riskler listesidir.

Bu risk temelli test adımı genellikle QA sorumlusu / Yöneticisi / temsilcisi tarafından yönetilir. Bununla birlikte, lider tek başına listenin tamamını ortaya çıkaramayacaktır; tüm QA ekibinin girdisi büyük bir etki yaratır. Bunun, QA liderinin önderlik ettiği kolektif bir faaliyet olduğunu söyleyebiliriz.

Ayrıca, Test planlama aşamasında belirlenen riskler oryantasyonda daha 'yönetimseldir' yani QA projesinin programını, çabasını, bütçesini, altyapı değişikliklerini vb. Etkileyebilecek herhangi bir şeye bakacağız. Buradaki odak noktası şudur: AUT değil, QA aşamasının devam etme şekli.

Test Planlama Sırasındaki Riskler: Risk Temelli Test Örnekleri

Aşağıda, Test Planlama aşamasında listelenebilecek risklerin örnek bir listesi verilmiştir. Lütfen AUT ve işlevselliğinin burada odak noktası olmadığını unutmayın.

1. Test programı sıkı. Testin başlaması tasarım görevleri nedeniyle gecikirse, test UAT tarafından planlanan başlangıç ​​tarihinin ötesine uzatılamaz.
2. Yeterli kaynak yok, kaynaklar çok geç devreye giriyor (süreç yaklaşık 15 gün sürer.)
3. Kusurlar, döngünün geç bir aşamasında veya bir geç döngüde bulunur; Geç keşfedilen kusurlar büyük olasılıkla belirsiz özelliklerden kaynaklanmaktadır ve çözülmesi zaman alıcıdır.
4. Kapsam tam olarak tanımlanmadı
5. Doğal afetler
6. Bağımsız'ın bulunmaması Test ortamı ve erişilebilirlik
7. Yeni Sorunlar Nedeniyle Gecikmiş Test

Bu noktada, mevcut süreye bağlı olarak istediğiniz kadar kapsamlı olmayı seçebilirsiniz.

Tüm riskler listelendiğinde, Risk değerlendirme / Risk etki analizine geçiyoruz.

# 2) Risk Değerlendirmesi / Risk Etki Analizi

Risk Analiziniz buna benzer bir şey mi? :)

Yazılım Testinde Risk Analizi : Bu adımda tüm riskler ölçülür ve önceliklendirilir. Her riskin olasılığı (gerçekleşme şansı) ve etkisi (bu risk gerçekleştiğinde neden olacağı zarar miktarı) sistematik olarak belirlenir.

Yüksek - orta-düşük değerler, her bir riskin hem olasılığına hem de etkisine atanır. Önce “yüksek” olasılığa ve “Yüksek” etkiye sahip riskler ilgilenilir ve ardından sıra takip edilir.

Risk etki analizi tablosu:

Bu adımların ardından, yukarıda listelenen riskler için risk etki analizi tablosu şuna benzer görünecektir (tüm değerler varsayımsaldır ve yalnızca anlama amaçlıdır):

# 3) Risk Azaltma

Bu Risk Temelli Test (RBT) sürecindeki son adım, bu durumların her birinin nasıl ele alınacağını planlamak için çözümler bulmaktır. Bu planlar firmadan firmaya, projeden projeye ve hatta kişiden kişiye farklılık gösterebilir.

Risk Azaltma Teknikleri:

İşte bu aşama tamamlandığında Risk tablosunun neye dönüştüğüne dair bir örnek:

Dikkat edilmesi gereken birkaç nokta:

1. Bir QA proje planlama aşamasında risk yönetimi ne kadar erken başlarsa o kadar iyidir.
2. Tüm 3 adımdan Risk Tanımlama en önemli şeydir . Herhangi bir şey listelenmemişse ve sonraki adımlar için düşünülmemişse, risk ele alınmaz.
3. Bu aktivite için ideal bir zaman çerçevesi bulmaya çalışın. Unutmayın, çok fazla planlama yapmak için çok az zaman kalır.
4. Ayrıca, risk yönetimi sürecinden sonra yeni bir durum ortaya çıkarsa, risk yönetim planı en güncel durumu yansıtacak şekilde değiştirilebilir veya güncellenebilir.
5. Tarihsel veri bu sürecin başarısı için çok faydalı olabilir.

Sonuç

Bu bizi Test planlama aşamasında Risk yönetiminin sonuna getiriyor. Altta yatan adımlar ve ilkeler benzer olsa da, risk yönetimi süreci, test tasarımı / yürütme aşamasında gerçekleştiğinde daha çok AUT'ye odaklanır.

Bir sonraki bölümde ele alacağız - Test Yürütme aşamasında Risk Yönetimi.

Test Yürütme Aşamasında Risk Yönetimi (Örneklerle)

Risk yönetimi sürecini anlama yolculuğumuzda, bunun sadece Risk bazlı testin test planlama aşaması . Ayrıca içeren genel süreci de anladık - Risk tanımlama, Risk Değerlendirmesi ve Risk Azaltma Planı.

Test tasarımı veya Test yürütme aşamasında Risk Nasıl Yönetilir:

Bir başka şekli daha var Risk yönetimi (bazen şu şekilde de anılır, Risk bazlı test ) duruma bağlı olarak Test tasarımı veya Test yürütme aşamasında meydana gelen. Şimdi, hangi durumdan bahsediyoruz? Önce bunu anlamaya çalışalım.

Hepimiz test çalışmalarımızın reaktif olduğunu biliyoruz. Hiçbir gereksinim (veya kapsam tanımlanmamış), fizibilite analizi gerçekleştiremiyoruz ve test senaryoları yazamıyoruz veya test faaliyetleri için plan yapamıyoruz.

Benzer şekilde, kod hazır olmadığında, test senaryoları, test verileri vb. Açısından ne kadar hazırlık çalışması olursa olsun test edecek hiçbir şeyimiz yok. Ayrıca, test, ürün gitmeden önce kalan tek adımdır. canlı.

Risk Yönetimi - AUT Odaklı

Bunu bir örnekle daha iyi anlayalım:

Test, 1 Ocak'ta başlayacaksa^stve 14 Ocak'a kadar devam etmek zorunda kaldı^inci- Test tamamlandığında, ürünün Yayına Başlama tarihi genellikle hemen sabitlenir. Diyelim ki, 15 Ocak^incibasitlik uğruna. Şimdi, mükemmel dünyada işler tam olarak planlandığı gibi gider. Ama hepimiz gerçeği biliyoruz.

Bu durumda, herhangi bir nedenle testin 7 Ocak'a kadar başlamadığını varsayalım.^inciBu, test süremizin yarısını kaybettiğimiz anlamına geliyor. Ancak ürünü iyice test etmek için 14 güne ihtiyacımız var. Yayınlanma tarihini 7 gün daha uzağa taşıyabiliriz - ancak; bu genellikle bir seçenek değildir. Çünkü ürünün belirli bir tarihte piyasaya çıkacağı sözü veriliyor ve herhangi bir gecikme iş için iyi değil.

Bu nedenle, genellikle, test ekiplerinin gecikmeleri özümsemesi, bir şekilde telafi etmesi, mevcut zamanla çalışması ve ürünün iyi test edildiğinden emin olması gerekir. Zor iş, değil mi?

Bu, Risk Yönetimi sürecinin yeniden kullanıldığı yerdir.

• Şimdi eğer vaktinden önce gecikmeler bekleniyor daha test başlamadan önce - süreç Test tasarımı aşamasında gerçekleşir.
• Eğer gecikmeler meydana gelir Test Yürütme aşaması normal olarak başlayan - süreç, test yürütme aşamasında izlenir.
• Adımlar ve yöntem, hangi aşamada olursa olsun aynıdır.

Süreç nedir?

AUT'nin (Test Altındaki Uygulama) hangi alanlarının maksimum odaklanmaya ihtiyaç duyduğunu belirlemek için risk yönetimi gerçekleştirilir. Bunlar, tipik olarak, nihai ürünün başarısı için kritik olan ve başarısızlığa en yatkın olan işlevsel alanlardır (modüller veya bileşenler).

Ayrıca oku=> Arıza Modu ve Etkileri Analizi (FMEA) bir Risk Yönetimi tekniğidir

Kim yapıyor?

AUT ile ilgili olduğu için, bu konudaki bilgi sadece QA ile değil, diğer tüm ekiplerle - Dev, BA, Müşteri, Proje yönetimi ekipleri, vb. Bu nedenle, test ekibi tarafından yönlendirilen toplu bir çabadır.

Risk Bazları Testi Nasıl Gerçekleşir?

Aşama 1) Risk tanımlaması

AUT'nin tüm işlevsel alanlarını tanımlayın. Bu sadece bir liste yapmayı içerecektir.

Adım 2) Risk değerlendirmesi

Bu adımda tüm riskler ölçülür ve önceliklendirilir. Niceleme, basitçe, listedeki her riske, ele alınması gereken önceliğin bir göstergesini verecek bir numara atamaktır.

Her riskin olasılığı (gerçekleşme şansı) ve etkisi (bu risk gerçekleştiğinde neden olacağı zarar miktarı) kararlaştırılır.

Tipik yöntem, derecelendirmeleri atamaktır. Örneğin, Olasılık, meydana gelme olasılığının düşük olması (hiç olması muhtemel değildir) ve 5'in yüksek olması (büyük olasılıkla gerçekleşecektir) olarak 1'den 5'e kadar değerleri alabilir.

Benzer şekilde, Impact'e 1-5 arası bir derecelendirme de atanabilir. 1 düşük etki (bu risk gerçekleşse bile, kayıp minimumdur) ve 5 yüksek etki (gerçekleştiğinde büyük kayıplar).

Aşama 3)

Bir tablo formatı oluşturun ve tüm ekip temsilcilerine - Geliştirme, İş İdaresi, Müşteri, PM, QA ve ilgili diğer kişilere dağıtın.

Adım 4)

Her takıma, olasılık ve etki puanlarına göre değerleri doldurmalarını söyleyin.

Olasılık ve etki değerleri sayısal olduğundan “Risk Faktörü” değerinin hesaplanmasını kolaylaştıracaktır.

Risk faktörü = Olasılık X Etkisi. Risk faktörü ne kadar yüksekse, sorun o kadar ciddidir.

Bir örnek:

Lütfen bu noktada, bunun sadece bir takımın reytinginin sonucu olduğunu unutmayın. 5 farklı ekibin dahil olduğu bir proje için QA ekibi 5 farklı masa ile sonuçlanacaktır.

Adım 5)

Risk faktörü değerlerinin ortalamasını alın. Örneğin, 5 takım varsa, her modül için tüm risk faktörü değerlerini toplayın ve 5'e bölün. Bu, ele alacağımız nihai değerler. Diyelim ki, bunlar ortalama risk faktörleri:

Java'da bir dizge dizisi döndürmek

Risk faktörü ne kadar fazlaysa, o modülün o kadar fazla test edilmesi gerekir.

Bu nedenle, Modül 5 ve 2, işletmenin başarısı için çok önemlidir. Sonuçları tüm ekiplerle paylaşın.

6. Adım)

Risk Azaltma Planı : Şimdi, Proje'den Proje'ye değişen adım budur. Modül 5 ve 2'nin en çok odaklanması gerekenler olduğunu belirledik.

Örneklerplanın şunlar olabilir:

1. Modül 5 ve 2, kendileriyle ilgili tüm test durumlarının test edildiğinden emin olarak kapsamlı bir şekilde test edilecektir. Diğer modüller, keşif amaçlı olarak test edilecektir.
2. Modül 5 ve 2 önce test edilecek ve sonra mevcut süreye bağlı olarak diğerleriyle ilgilenilecektir.

Bir plan yapıldığında, tüm ekipler bir anlaşmaya varır ve ürünü risk faktörünü hesaba katarak test etmek için onu takip eder.

Bu kadar!

Dikkat edilmesi gereken birkaç önemli nokta:

• Bu, toplu bir etkinlik olduğu için herkesin görüşü dikkate alınır ; doğru ve etkili olma şansı daha yüksektir.
• Bu resmi bir yöntem değil ve her QA projesinin bir parçası olmak zorunda değildir.
• Bazen, takım tablo çizmemeyi ve değerler atamamayı seçse bile basit beyin fırtınası oturumu herkesin hazır bulunması, QA ekibine nasıl ilerleyeceği konusunda iyi bir yön verebilir.
• geliştirme ekibinin girdisi bu çok önemlidir çünkü ürünü yaratanlar onlardır, bu yüzden neyin işe yarayacağını ve neyin ek kontrol gerektirebileceğini bilirler. Bunun için tetikte olduğunuzdan emin olun.
• Süreçte birden fazla adım olsa da, bunları gerçekleştirmek çok fazla zaman almaz . Özellikle, tüm ekipler birlikte oturabilir ve aynı anda çalışabilirse.
• Bu süreci hatırlayın ve sonucu sadece alternatif . Test için planlandığı kadar zaman kazanmak, QA etkinliğini gerçekleştirmenin en iyi yoludur.

Sonuç

Risk Temelli Test yaklaşımı, test uzmanının odak noktasının, ciddiyet ve önceliğe bakılmaksızın sadece kusurları keşfetmeye devam etmek olmadığını açıkça göstermektedir. Artık işler değişti ve Test Uzmanlarının akıllıca çalışması gerekiyor ve 'Müşterinin İhtiyacı ve Kullanıcının İstediği' ni net bir şekilde anlamaları gerekiyor.

Ürünü derinlemesine inceleyerek, üretimde en sık kullanılan özellik olan, gelir elde etmek için en kritik yol olan ve müşterileri üretim sorunları ve iş tehditlerinden nasıl koruyacaklarını anlamaları gerekir.

Bu nedenle, RBT yaklaşımı, 3 test uzmanına, yalnızca her şeyi test etmenin veya kapsamlı bir şekilde test etmenin, testin tamamlandığı veya üründe kusur olmadığı anlamına gelmediği konusunda açıkça eğitir. Öngörülen bir sürede etkili bir şekilde test etmek ve kritik ve büyük ticari etkilerin geçersiz kılınmasını sağlamak ve bu, test uzmanı için oldukça önemlidir.

Bu nedenle Risk Bazlı test, QA ekibinin proje risklerine dayalı olarak proje paydaşlarına rehberlik etmesi için en etkili araçtır. RBT yaklaşımı, QA ekibine, genel proje hedeflerine ve hedeflerine ulaşılmasını tehlikeye atabilecek riskin ve çözümünün sürekli olarak belirlenmesine yardımcı olur ve QA Grubunun nihai amacına ulaşılmasına yardımcı olur.

Not: Belge boyunca QA ve Testing sözcükleri birbirinin yerine kullanılmıştır.

Yazar hakkında: Bu makale birden çok STH ekip üyesi tarafından yazılmıştır - Gayathri Subrahmanyam ve Swati S.

Gayathri, Yazılım Testinde 2 yıldan fazla deneyime sahip bir Yazılım Test KOBİ'sidir ve çeşitli görevlerde Test Endüstrileşmesinin bir parçası olarak 'Risk Tabanlı Test' yaklaşımını kapsamlı bir şekilde benimsemiştir ve Test kaynak optimizasyonu ve kalite testinin faydalarını fark etmiştir.

Risk Tabanlı test sizin için zor bir test miydi? Eğitimimize eklemek için ilginç gerçekleriniz var mı? Aşağıdaki yorumlar bölümünde düşüncelerinizi ifade etmekten çekinmeyin !!

=> Tam Test Planı Eğitim Dizisi İçin Burayı Ziyaret Edin

Önerilen Kaynaklar

• Sürekli Entegrasyon Süreci: Yazılım Kalitesini İyileştirme ve Riski Azaltma
• Hata Modu ve Etkileri Analizi (FMEA) - Daha İyi Yazılım Kalitesi ve Memnun Müşteriler İçin Riskler Nasıl Analiz Edilir!
• Risk Bazlı Test için Nihai Kılavuz: Yazılım Testinde Risk Yönetimi
• En İyi 10 Risk Değerlendirme ve Yönetim Araç ve Teknikleri
• Yazılım Projelerinde Risk Türleri
• Bazı İlginç Yazılım Testi Görüşme Soruları
• Kariyeriniz olarak Yazılım Testini Seçme
• Yazılım Test Kursu Geri Bildirimleri ve İncelemeleri