STLC - Hızlı Kılavuz

STLC, Yazılım Test Yaşam Döngüsü anlamına gelir. STLC, yazılımın veya ürünün kalitesini sağlamak için test ekibi tarafından gerçekleştirilen farklı etkinlikler dizisidir.

STLC, Yazılım Geliştirme Yaşam Döngüsünün (SDLC) ayrılmaz bir parçasıdır. Ancak, STLC yalnızca test aşamalarıyla ilgilenir.
STLC, gereksinimler tanımlanır veya SRD (Yazılım Gereksinim Belgesi) paydaşlar tarafından paylaşılır paylaşılmaz başlar.
STLC, kaliteli yazılım sağlamak için adım adım bir süreç sağlar.
STLC'nin erken aşamasında, yazılım veya ürün geliştirilirken, test cihazı test kapsamını, giriş ve çıkış kriterlerini ve ayrıca Test Durumlarını analiz edebilir ve tanımlayabilir. Daha iyi kaliteyle birlikte test döngüsü süresinin azaltılmasına yardımcı olur.
Geliştirme aşaması biter bitmez, test uzmanları test senaryolarına hazırdır ve yürütmeye başlar. Bu, ilk aşamada hataları bulmaya yardımcı olur.

STLC Aşamaları

STLC'nin aşağıdaki farklı aşamaları vardır ancak tüm aşamaları takip etmek zorunlu değildir. Aşamalar, yazılımın veya ürünün doğasına, test için ayrılan zamana ve kaynaklara ve izlenecek SDLC modeline bağlıdır.

STLC'nin 6 ana aşaması vardır -

Requirement Analysis - SRD hazır olduğunda ve paydaşlarla paylaşıldığında, test ekibi AUT (Test Altındaki Uygulama) ile ilgili üst düzey analize başlar.
Test Planning - Test Ekibi strateji ve yaklaşımı planlar.
Test Case Designing - Kapsam ve kriterlere göre test senaryoları geliştirin.
Test Environment Setup - Entegre ortam ürünü doğrulamaya hazır olduğunda.
Test Execution - Ürünün gerçek zamanlı doğrulaması ve hataları bulma.
Test Closure - Test tamamlandıktan sonra matris, raporlar, sonuçlar belgelenir.

Bu bölümde, STLC ve SDLC arasındaki karşılaştırma faktörlerini anlayacağız. Aşağıdaki noktaları ele alalım ve böylece STLC ile SDLC'yi karşılaştıralım.

STLC, SDLC'nin bir parçasıdır. STLC'nin, SDLC setinin bir alt kümesi olduğu söylenebilir.
STLC, yazılım veya ürün kalitesinin sağladığı test aşamasıyla sınırlıdır. SDLC, bir yazılım veya ürünün tam geliştirilmesinde büyük ve hayati bir role sahiptir.
Ancak STLC, SDLC'nin çok önemli bir aşamasıdır ve nihai ürün veya yazılım STLC sürecinden geçmeden yayınlanamaz.
STLC ayrıca, SDLC'nin bilinen kusurların giderildiği veya yazılıma yeni bir işlevsellik eklendiği, yayın sonrası / güncelleme döngüsünün, bakım aşamasının bir parçasıdır.

Aşağıdaki tablo, aşamalarına göre SDLC ve STLC arasındaki karşılaştırma faktörlerini listelemektedir -

Evre	SDLC	STLC
Şartlı toplantı	İş Analisti gereksinimleri toplar. Geliştirme ekibi gereksinimleri analiz eder. Üst seviyeden sonra, geliştirme ekibi mimari ve tasarım açısından analiz etmeye başlar.	Test ekibi SRD belgesini inceler ve analiz eder. Test gereksinimlerini tanımlar - Kapsam, Doğrulama ve Doğrulama temel noktaları. Çeşitli modüller arasındaki mantıksal ve işlevsel ilişki için gereksinimleri gözden geçirir. Bu, erken bir aşamada boşlukların belirlenmesine yardımcı olur.
Tasarım	SDLC'nin mimarisi, gereksinimlere göre yazılımın üst düzey ve alt düzey tasarımını geliştirmenize yardımcı olur. İş Analisti, UI tasarımının alaycısı üzerinde çalışır. Tasarım tamamlandıktan sonra paydaşlar tarafından imzalanır.	STLC'de, ya Test Mimarı ya da Test Lideri genellikle test stratejisini planlar. Test noktalarını tanımlar. Kaynak tahsisi ve zaman çizelgeleri burada sonlandırılır.
Geliştirme	Geliştirme ekibi yazılımı geliştirmeye başlar. Farklı sistemlerle entegre edin. Tüm entegrasyon tamamlandıktan sonra, teste hazır bir yazılım veya ürün sağlanır.	Test ekibi, ürünün kalitesini doğrulamak için test senaryolarını yazar. Beklenen davranışla birlikte tüm modüller için ayrıntılı test senaryoları yazılır. Bir test modülünün ön koşulları ve giriş ve çıkış kriterleri burada tanımlanır.
Ortam Kurulumu	Geliştirme ekibi, doğrulanması için geliştirilen ürünle bir test ortamı oluşturur.	Test ekibi, ön koşullara göre ortam kurulumunu onaylar. Test edilecek ürün için ortamın stabil olduğundan emin olmak için duman testi gerçekleştirir.
Test yapmak	Gerçek test bu aşamada gerçekleştirilir. Birim testi, entegrasyon testi, sistem testi, hata yeniden testi, regresyon testi vb. İçerir. Geliştirme ekibi, varsa rapor edilen hatayı düzeltir ve yeniden test edilmesi için test ediciye geri gönderir. UAT testi, SIT testinden çıktıktan sonra burada gerçekleştirilir.	Sistem Entegrasyon testi, test senaryolarına göre başlar. Varsa, rapor edilen kusurlar yeniden test edilir ve düzeltilir. Burada regresyon testi yapılır ve çıkış kriterlerini karşıladığında ürün imzalanır.
Dağıtım / Ürün Sürümü	Çeşitli test ekiplerinden onay alındıktan sonra, uygulama gerçek son kullanıcılar için üretim ortamında dağıtılır.	Üretim ortamında duman ve sağlık testi, ürün devreye girer girmez burada tamamlanır. Test raporları ve matris hazırlığı, ürünü analiz etmek için test ekibi tarafından yapılır.
Bakım	Varsa, dağıtım sonrası destekleri, geliştirmeleri ve güncellemeleri kapsar.	Bu aşamada, geliştirme ve güncellemelere göre test senaryolarının, regresyon takımlarının ve otomasyon komut dosyalarının bakımı gerçekleştirilir.

Test etmenin ortak amacı, hataları olabildiğince erken bulmaktır. Ve hatalar giderildikten sonra, beklendiği gibi çalıştığından ve diğer işlevleri bozmadığından emin olun.

Bu hedeflere ulaşmak için, yazılım testi için yedi temel ilke verilmiştir -

Test ne gösterir?

Testler, kusurların mevcut olduğunu gösterebilir ancak üründe herhangi bir kusur olmadığını kanıtlamanın bir yolu yoktur. Test aşamaları, test edilen uygulamanın verilen gereksinime göre çalıştığından emin olur ve uygulamada keşfedilmemiş kusur olasılığını azaltmaya yardımcı olur. Ancak herhangi bir kusur bulunmasa bile, kesinlikle doğru olduğu anlamına gelmez. AUT'nin çıkış kriterlerimizle eşleştiğini ve SRD'ye göre gereksinimleri koruduğunu varsayabiliriz.

Kapsamlı Test mümkün mü?

Tüm girdi kombinasyonlarının ve olası kombinasyonların% 100 kapsama alınması veya test edilmesi, önemsiz durumlar dışında mümkün değildir. Kapsamlı testler yerine, risk analizi ve öncelikler testin kapsamını tanımlamak için kullanılır. Burada, gerçek zamanlı senaryoların çoğu, en olası olumsuz senaryoyu da dahil etmeyi düşünebilir. Bu, başarısızlığı izlememize yardımcı olacaktır.

Erken Test

Test faaliyetleri mümkün olan en kısa sürede başlamalı ve Test Stratejisinde tanımlanan hedeflere ve beklenen sonuçlara odaklanmalıdır. Testin erken aşaması, Gereksinim Kusurunu veya tasarım seviyesi tutarsızlıklarını belirlemeye yardımcı olur. Bu tür hatalar ilk aşamada tespit edilirse, zamandan tasarruf etmemize yardımcı olur ve aynı zamanda uygun maliyetli olur. Testin neden erken bir aşamada başlaması gerektiğinin cevabı çok basittir - SRD alınır alınmaz, test uzmanları gereksinimi test perspektifinden analiz edebilir ve bir gereksinim tutarsızlığını görebilir.

Kusur Kümeleme

Önceki ürün hata analizine dayanarak, kusurların çoğunun uygulama için kritik olan küçük modüllerden tanımlandığı söylenebilir. Bu modüller, karmaşıklığa, farklı sistem etkileşimlerine veya farklı diğer modüllere bağımlılığa göre tanımlanabilir. Test uzmanları bu önemli modülleri belirleyebilirlerse, olası tüm hataları belirlemek için bu modüllere daha fazla odaklanabilirler. Bir çalışmada, 10 kusurdan 8'inin AUT'nin% 20 işlevselliğinden tanımlandığı bulunmuştur.

Böcek öldürücü paradoksu

Pestisit paradoksu nedir - eğer pestisitler mahsullerde sıklıkla kullanılıyorsa, böcekler belirli bir direnç geliştirdiğinde ve bu şekilde püskürtülen pestisitlerin böcekler üzerinde etkisiz göründüğü zaman ortaya çıkar.

Aynı kavram test için de geçerlidir. Burada böcekler böcek, pestisitler tekrar tekrar koşmak için kullanılan test durumlarıdır. Aynı test senaryoları tekrar tekrar yürütülürse, bu test senaryoları belirli bir zaman diliminden sonra etkisiz hale gelir ve test uzmanları herhangi bir yeni kusur belirleyemez.

Bu koşulların üstesinden gelmek için, test senaryoları zaman zaman gözden geçirilmeli ve gözden geçirilmeli ve yeni ve farklı test senaryoları eklenebilir. Bu, yeni kusurların belirlenmesine yardımcı olacaktır.

Test Bağlama Bağlıdır

Bu ilke, iki farklı uygulama türünün, her iki uygulama aynı yapıya sahip olana kadar aynı yaklaşım kullanılarak test edilemeyeceğini belirtir. Örneğin, bir test uzmanı Web Tabanlı Uygulama ve Mobil Uygulama için aynı yaklaşımı kullanırsa, bu tamamen yanlıştır ve düşük kaliteli ürün piyasaya sürülme riski yüksektir. Test uzmanları, farklı uygulama türleri ve doğası için farklı yaklaşımlar, metodolojiler, teknikler ve kapsamlar kullanmalıdır.

Hata Yokluğu - Yanılgı

Bu ilke, uygulama veya sistem kararlı hale gelene kadar kusurları bulmayı ve bunları düzeltmeyi ifade eder, zaman alır ve ayrıca kaynakları tüketir. Kusurların% 99'unu düzelttikten sonra bile, kararsız uygulama riski yüksektir. İlk önemli şey, uygulamanın kararlılığını ve ortamın ön koşullarını doğrulamaktır. Bu iki koşul yerine gelirse, ancak o zaman ayrıntılı testlerle başlayabiliriz.

Gereksinim Analizi, STLC'nin ilk aşamasıdır ve SRD / SRS test ekibiyle paylaşılır paylaşılmaz başlar. STLC'deki Gereksinim Analizini anlamak için aşağıdaki noktaları ele alalım.

Bu aşamanın giriş kriterleri, SRS'nin (Yazılım Gereksinim Belirtimi) sağlanmasıdır; ayrıca uygulama mimarisinin kullanışlı olması tavsiye edilir.
Bu aşamada, QA ekibi neyin test edileceğini ve nasıl test edileceğini daha yüksek bir düzeyde analiz eder.
QA ekibi, gereksinimi anlamak için herhangi bir sorgu veya açıklama gerekmesi durumunda İş Analisti, Sistem Mimarisi, Müşteri, Test Yöneticisi / Lider gibi çeşitli paydaşları takip eder.
Gereksinimler işlevsel veya performans, güvenlik, kullanılabilirlik vb. Gibi işlevsel olmayabilir veya hem işlevsel hem de işlevsel olmayabilir.
Bu aşamanın çıkış kriterleri, RTM belgesini, otomasyon fizibilite raporunu ve gerektiğinde daha spesifik olması için bir soru listesini tamamlamaktır.

İhtiyaç Analizi İçin Gerçekleştirilen Faaliyetler

Bu aşamada QA ekibi tarafından gerçekleştirilen üç ana faaliyet vardır. Faaliyetler aşağıda açıklanmıştır.

Kapsamın Tanımlanması

QA ekibi, yüksek seviyelerde test kapsamını belirler ve çeşitli fonksiyonel modüllere ayrılır. Ekip ayrıca, gerçekleştirilmesi gereken test türlerini de belirler - duman testi, akıl sağlığı testi, işlevsel test, regresyon testi, vb. QA ekibi, testin gerçekleştirilmesi gereken ön koşulları ve ortam ayrıntılarını analiz eder. Ekip, test öncelikleri hakkında ayrıntıları toplar ve doğrulanacak modüllerin sırasına odaklanır. Ayrıca, modüller çelişiyorsa ve işlevsellik diğer modüllerle birlikte taşınmıyorsa, gereksinim kusurlarını belirler.

RTM hazırlayın

Gereksinim izleme, gereksinimler ile bu gereksinimleri uygulamak ve doğrulamak için geliştirilen çalışma ürünleri arasındaki bağlantıların belgelenmesi sürecidir. RTM, Gereksinim Analizindeki tüm gereksinimleri izlenebilirliklerinin yanı sıra tek bir belgede toplar. Tüm bunlar yaşam döngüsünün sonunda teslim edilir.

Matris, projenin kapsamı ve üretilecek çıktıların temelini oluşturduğu için bir projenin en başında oluşturulur.

Matris, ürünün belirli bir özelliği için belirlenen iş gereksinimine bakarak teslim edileceklerin çıktılarını inceleyerek ve geriye dönük olarak gereksinimi ileriye doğru izlediği için çift yönlüdür.

Otomasyon Analizi

Gereksinim aşamasında, QA ekibi regresyon testi için otomasyon kapsamını analiz eder. Otomasyon kapsama eklenirse, ekip hangi aracın kullanılacağına, hangi işlevlerin otomasyon olarak ele alınacağına, zaman çerçevesine ve otomasyon geliştirme için dahil olan kaynak tahsisine karar verir. Bu analiz tamamlandığında, QA ekibi, farklı paydaşlara onay sağlamak için Otomasyon Fizibilite Raporunu sunar.

Bu bölümde, STLC'de farklı seviyelerde Giriş ve Çıkış Kriterlerini göreceğiz. Kriterleri anlamak için aşağıdaki noktaların dikkate alınması gerekir.

İdeal olarak, QA ekibi mevcut aşamanın çıkış kriterleri karşılanana kadar bir sonraki aşamaya geçmez. Giriş kriterleri, önceki aşamanın çıkış kriterlerinin tamamlanmasını içermelidir.

Gerçek zamanlı olarak, çıkış kriterleri karşılanana kadar bir sonraki aşama için beklemek mümkün değildir. Şimdi, önceki aşamanın kritik çıktıları tamamlanmışsa bir sonraki aşama başlatılabilir.

STLC'nin her aşamasında, giriş ve çıkış kriterleri tanımlanmalıdır.

Giriş kriterleri

STLC aşamaları için Giriş Kriterleri, özel koşullar olarak tanımlanabilir; veya belirli bir STLC aşamasını başlatmak için gerekli olan tüm belgeler, STLC aşamasından herhangi birine girmeden önce mevcut olmalıdır.

Giriş kriterleri, bir görevin gerçekleştirilmesine izin veren bir koşullar kümesidir veya bu koşullardan herhangi birinin olmaması durumunda görev gerçekleştirilemez.

Giriş kriterlerini belirlerken, süreci başlatmak için giriş kriterleri öğesinin mevcut olduğu zaman çerçevesinin tanımlanması da önemlidir.

Örnek için, Test Senaryoları geliştirme aşamasına başlamak için aşağıdaki koşullar karşılanmalıdır -

Gereksinim belgesi mevcut olmalıdır.
Başvuru akışının tam olarak anlaşılması gerekir.
Test Planı Belgesi hazır olmalıdır.

Çıkış kriteri

STLC aşamaları için Çıkış Kriterleri, mevcut aşama tamamlanmadan ve bir sonraki aşamaya geçmeden önce tamamlanması gereken öğeler / belgeler / eylemler / görevler olarak tanımlanabilir.

Çıkış kriterleri bir dizi beklentidir; STLC aşamasını tamamlamadan önce bunun karşılanması gerekir.

Örnek için, Test Senaryosu geliştirme aşamasını tamamlamak için aşağıdaki beklentilerin karşılanması gerekir -

Test Vakaları yazılmalı ve gözden geçirilmelidir.
Test Verileri tanımlanmalı ve hazır olmalıdır.
Test otomasyon komut dosyası, mümkünse hazır olmalıdır.

Kabul kriterleri, gereksinim belgelerinde listelendiği gibi bir işlevsellik, modül ve uygulamanın beklenen davranışı anlamına gelir. Yazılım sisteminin gereksinim özelliklerini karşılayıp karşılamadığını belirlemek için doğrulama aşamaları / kontrol noktalarıdır. Bu testin temel amacı, sistemin iş gereksinimlerine uygunluğunu değerlendirmek ve gerekli kriterleri karşılayıp karşılamadığını doğrulamaktır.

Kabul Kriterleri, beklenen başarılı / başarısız sonucundan açıkça bahseden bir dizi ifadedir. Kabul kriterleri hem işlevsel hem de işlevsel olmayan gereksinimleri belirtir. Bu gereksinimler "memnuniyet koşullarını veya beklenen davranışı" temsil eder. Kısmi kabul yoktur; ya bir kriter karşılanır ya da karşılanmaz.

Bu kriterler, bir işlevselliğin / modülün sınırlarını ve parametrelerini tanımlar ve işlevselliğin / modülün tamamlanıp tamamlanmadığını ve beklendiği gibi çalışıp çalışmadığını belirler.

Üst Düzey Kabul kriterleri, Test Planı Düzeyinde belirtilir. Kabul kriterleri, doğrulanacak noktalar listesine veya test senaryoları düzeyinde beklenen sonuçlara dönüştürülür.

Kabul kriterleri aşağıdaki özelliklere göre tanımlanır -

Fonksiyonel Doğruluk ve Tamlık
Veri bütünlüğü
Veri dönüşümü
Usability
Performance
Timeliness
Gizlilik ve Kullanılabilirlik
Yükleme ve Yükseltme yeteneği
Scalability
Documentation

Bir test planı, bir uygulamayı test etmek için kullanılacak stratejiyi, kullanılacak kaynakları, testin gerçekleştirileceği test ortamını ve testin sınırlamalarını ve test faaliyetlerinin programını ana hatlarıyla belirtir. Tipik olarak, Kalite Güvence Ekibi Lideri bir Test Planı yazmaktan sorumlu olacaktır.

Bir Test Planı Neleri İçerir?

Bir Test Planı aşağıdakileri içerir.

Test Planı belgesine giriş.
Uygulamayı test ederken varsayımlar.
Uygulamanın test edilmesine dahil edilen test senaryolarının listesi.
Test edilecek özelliklerin listesi.
Yazılım test edilirken kullanılacak yaklaşım türü.
Test edilmesi gereken çıktıların listesi.
Uygulamayı test etmek için ayrılan kaynaklar.
Test süreci sırasında ortaya çıkan riskler.
Ulaşılması gereken görevler ve kilometre taşları programı.

Test Planlaması için Önemli Noktalar

STLC'de Test Planlaması için aşağıdaki noktaların dikkate alınması gerekir.

İdeal olarak, Test Analisti (Lider) / Yönetici Test Stratejisi / Test Planı Dokümanını hazırlar.
Analiz daha çok uygulama ile ilgili verilere / bilgilere odaklanır.
Gerçek test görevlerinin ilk aşamasıdır.
Bu aşama "Neyin test edileceği" ve "Test etmek için HANGİ KAYNAKLAR gereklidir" yanıtlarını verir.
Bu aşamanın temel giriş kriterleri, Gereksinim İzlenebilirlik Matrisi ile birlikte Gereksinim Belgelerinin (açık olmayan / eksik / açıklığa kavuşturulmuş gereksinimlerin güncellenmiş versiyonu) sağlanmasıdır.
Otomasyon kapsam dahilinde ise bu aşamaya geçmeden önce Otomasyon Fizibilite Raporu hazırlanmalıdır.
Bu aşamadan çıkış kriteri Test Stratejisi / Test Planı Dokümanı ve Test eforu Tahmin dokümanının tamamlanmasıdır.

Test Planlama Aşamasının Yönleri

Bu aşamanın temel amacı, bir Test Planı / Test Stratejisi belgesi hazırlamaktır. Üç ana yönü içerir - Çıktıların Kapsamı, İş gücü tahmini ve Kaynak Planı.

Teslim Edileceklerin Kapsamı

Teslim edileceklerin kapsamına ilişkin sonuca varmak için aşağıdaki faaliyetlerin gerçekleştirilmesi gerekir -

Uygun görev ve teslimat modelini belirleyin.
Test hedeflerini, test kapsamını, test aşamalarını ve faaliyetleri tanımlayın.
Test uygulanabilirliğini belirlemek için iş gereksinimini ve sistem gereksinimini inceleyin.
Test sürecini, test türünü ve prosedürleri tanımlayın.
Hata yönetimi ve değişiklik yönetimi prosedürlerini tanımlayın.
Test araçlarını, tekniklerini ve en iyi uygulamaları belirleyin.
Risk Analizini tanımlayın.
Otomasyon çözümünü tanımlayın ve uygunsa otomasyon için uygun adayları belirleyin.

Gayret tahmini

Tahmin, girdi verileri eksik, belirsiz veya kararsız olsa bile bir amaç için kullanılabilen bir değer olan bir tahmin veya yaklaşıklık bulma sürecidir.

Tahmin, belirli bir sistem veya ürün oluşturmak için ne kadar para, çaba, kaynak ve zaman gerekeceğini belirler. Tahmin şuna dayanır -

Geçmiş Veriler / Geçmiş Deneyim
Mevcut Belgeler / Bilgi
Assumptions
Tanımlanmış Riskler

Test Tahminindeki dört temel adım şunlardır:

AUT (Test Altındaki Uygulama) boyutunun tahmini.
Eforun kişi-ay veya kişi-saat cinsinden tahmini.
Takvimin takvim aylarına göre tahmini.
Kararlaştırılan para birimi cinsinden proje maliyetinin tahmini.

Kaynak Planı

Kaynak planları, test aşamalarının kilit unsurudur. Bu planlar, test ekibinin belirli bir görevi tamamlamak için harcadığı süre ile ters orantılıdır. Kaynak sayısının artırılması, belirli bir sınır için tamamlanma günlerinin sayısını azaltacak, daha sonra doyurulacak ve kaynağı artırmanın çok fazla etkisi olmayacak ve tamamlanma günlerinde azalmaya yol açmayabilecektir.

Genellikle bir proje yöneticisi olan bir Kaynak İsteği, kaynak istemek, çabaları ve maliyetleri izlemek için kaynak planları oluşturur. Bir Kaynak yöneticisi, planlar kullanılmadan önce kaynak planlarını değiştirebilir ve onaylayabilir.

Bir kaynak planı için normal iş akışı şudur:

Proje Yöneticisine Göre Planlama
Proje Yöneticisi tarafından talep edildi
Kaynak Yöneticisi Tarafından Onayla / Değiştir / Reddet
Tamamlandı - İsteğin Kaynak Yöneticisi tarafından imzalandıktan sonra kapatılması

Test Planı hazır olduğunda, QA Ekibi test senaryolarının geliştirilmesini başlatır. Bu aşamanın temel amacı, tek bir birim için test senaryoları hazırlamaktır. Bu işlevsel ve yapısal test senaryoları, Test Planında belirtilen işlevselliği, doğrulama ve doğrulama noktalarını kapsar.

STLC'de Test Vaka Geliştirme için aşağıdaki noktaların dikkate alınması gerekir.

Bu aşamada, QA ekibi test senaryosunu aşamalı bir yaklaşımla yazar. Test Senaryosu, daha sonra değişikliklerin gerekli olması durumunda test senaryoları üzerinde inceleme veya yeniden çalışma yapıldıktan sonra bir İş Analisti tarafından imzalanır.
Test senaryoları hazır olduğunda, QA ekibi ön koşullara göre Test Verilerini hazırlar.
Bu aşamanın giriş kriterleri, test planlamasındaki faaliyetlerin bitirilmesi ve test planının hazır olmasıdır.
Bu aşamanın çıkış kriteri, test senaryolarının imzalanması, test verilerinin hazır olması ve otomasyon kapsamda ise test komut dosyalarının hazırlanmasıdır.
Herhangi bir şeyin gözden kaçması durumunda gereksinimlerin kapsamını takip etmek için test senaryoları Gereksinim İzlenebilirlik Matrisi ile eşleştirilmelidir.

Test Vaka Geliştirme Aşamasındaki Faaliyetler

Aşağıda, Test Senaryosu Geliştirme aşamasında gerçekleştirilen üç etkinlik yer almaktadır:

Test Senaryoları Tanımlama

Senaryolar, karmaşık bir sistemin test edilmesini ve değerlendirilmesini kolaylaştırır. Aşağıdaki stratejiler, iyi senaryolar oluşturmaya yardımcı olur -

Olası kullanıcıları, eylemlerini ve hedeflerini sıralayın.
Kullanıcıları bilgisayar korsanının zihniyetiyle değerlendirin ve olası sistem kötüye kullanım senaryolarını listeleyin.
Sistem olaylarını ve sistemin bu tür talepleri nasıl ele aldığını listeleyin.
Faydaları listeleyin ve kontrol etmek için uçtan uca görevler oluşturun.
Benzer sistemler ve davranışları hakkında bilgi edinin.
Rakiplerin ürünleri ve önceki ürünleri hakkındaki şikayetleri incelemek.

Test Vakaları Yazma

Bir test senaryosu, belirli bir gerekliliğe uygunluğu doğrulamak için belirli bir test senaryosu için geliştirilmiş test verilerini, ön koşulları, beklenen sonuçları ve son koşulları içeren bir belgedir.

Test Durumu, test yürütme için başlangıç noktası görevi görür. Bir dizi girdi değeri uygulandıktan sonra; Uygulamanın kesin bir sonucu vardır ve sistemi yürütme sonrası koşulu olarak da bilinen bir son noktada bırakır.

Test Verilerinin Hazırlanması

Test Verileri, test yazılımları üzerinde testleri yürütmek için kullanılır. Kusurları ortaya çıkarmak için test verilerinin kesin ve ayrıntılı olması gerekir. Bu üç hedefi gerçekleştirmek için, aşağıda belirtildiği gibi aşamalı bir yaklaşım izlenir -

Test kaynaklarını veya gereksinimlerini belirleyin
Test edilecek koşulları / işlevselliği tanımlayın
Öncelikli test koşullarını ayarlayın
Test için koşulları seçin
Test senaryolarının işlenmesinin beklenen sonucunu belirleyin
Test senaryoları oluşturun
Belge testi koşulları
Yürütme testi
Değişikliklere göre test senaryolarını doğrulayın ve düzeltin

Etkinlik Blok Şeması

Aşağıdaki diyagram, Test Senaryosu Geliştirmenin bir parçasını oluşturan farklı etkinlikleri göstermektedir.

Test Ortamı, yapılandırılan yazılım, donanım ve ağ ile test yürütmeyi destekleyen öğelerden oluşur. Ortam / yapılandırmayla ilgili sorunları ortaya çıkarmak için test ortamı yapılandırması üretim ortamını taklit etmelidir.

Bir Test Ortamı Kurulumunda aşağıdaki noktaların dikkate alınması gerekir.

Testlerin yürütüleceği donanım ve yazılım ortamının bir kombinasyonudur.
Testin gerçekleştirilmesi için donanım yapılandırması, işletim sistemi ayarları, yazılım yapılandırması, test terminalleri ve diğer destekleri içerir.
Test sürecinin en önemli yönü budur. Kullanılamazlık veya hatalı ortam kurulumu tüm test çabalarını mahvedebilir.
Pratik olarak, QA ekibi test etmek için doğru ortama sahip olmadan fiili çalışmaya başlayamaz.
Bağımsız bir faaliyettir ve test senaryosu geliştirmeyle birlikte başlatılabilir.
Çoğu genel olarak, bu aktivite geliştiriciler tarafından teknik yönden gerçekleştirilirken, gereksinim koşulları Müşteriler / İş Analistleri tarafından yapılabilir.
Test ortamının hazır olup olmadığı duman testi ile doğrulanabilir ve QA ekibi tarafından gerçekleştirilebilir.
İdeal olarak, bu aşamanın Giriş Kriterlerinin Test Planının sağlanması, Duman Testi durumlarının hazırlığı ve test verilerinin hazırlanması olduğunu söyleyebiliriz.
Bu aşamadan çıkış kriteri, test ortamının hazır olması ve duman testinin beklenen sonuçlarla başarılı bir şekilde yapılmasıdır.

Test Ortamı Kurulumu için Gerçekleştirilen Etkinlikler

Bu aşamada aşağıdaki faaliyetler gerçekleştirilir.

Tasarım Test Ortamı

Aşağıdaki faktörler, bir test ortamının tasarlanmasında önemli bir rol oynar.

Yedekleri almak için test ortamının arşivlenmesi gerekip gerekmediğini belirleyin.
Ağ yapılandırmasını doğrulayın.
Gerekli sunucu işletim sistemini, veritabanlarını ve diğer bileşenleri tanımlayın.
Test ekibi tarafından gerekli görülen lisans sayısını belirleyin.

Ortamın Kurulumu

Ortam kurulum gereksinimlerini analiz edin ve kurulum için bir yazılım ve donanım gereksinimleri listesi hazırlayın. Test ortamının kurulumu için resmi onayı alın ve test ortamına erişmek için yapılandırın.

Duman Testi

Ortam kurulduktan ve kalite güvence ekibi buna erişime sahip olduktan sonra, test ortamı oluşturma kararlılığının doğrulanması için hızlı bir duman testi turu yapılmalıdır. Sonuçlar beklendiği gibiyse, QA ekibi bir sonraki aşamaya geçebilir, aksi takdirde tutarsızlıklara işaret edebilir ve düzeltmelerden sonra dağıtımı bekleyebilir.

Test yürütme, kodu yürütme ve beklenen ve gerçek sonuçları karşılaştırma sürecidir. Bir test yürütme süreci için aşağıdaki faktörlerin dikkate alınması gerekir -

Bir riske bağlı olarak, bu döngü için yürütülecek bir test paketi alt kümesi seçin.
Her test paketindeki test senaryolarını yürütme için test uzmanlarına atayın.
Testleri yürütün, hataları bildirin ve test durumunu sürekli olarak yakalayın.
Engelleme sorunlarını ortaya çıktıkça çözün.
Durumu rapor edin, atamaları ayarlayın ve planları ve öncelikleri günlük olarak yeniden değerlendirin.
Test döngüsü bulgularını ve durumunu bildirin.

Test Yürütme için aşağıdaki noktaların dikkate alınması gerekir.

Bu aşamada, QA ekibi hazırlanan test senaryolarına dayalı olarak AUT'nin gerçek doğrulamasını gerçekleştirir ve aşamalı sonucu beklenen sonuçla karşılaştırır.
Bu aşamanın giriş kriterleri Test Planının ve Test Örnekleri Geliştirme aşamasının tamamlanmasıdır, test verileri de hazır olmalıdır.
Test Ortamı kurulumunun doğrulanması, test yürütmesine resmi olarak girmeden önce her zaman duman testi yoluyla önerilir.
Çıkış kriterleri, tüm Test Durumlarının başarılı bir şekilde doğrulanmasını gerektirir; Kusurlar kapatılmalı veya ertelenmelidir; test senaryosu yürütme ve kusur özet raporu hazır olmalıdır.

Test Yürütme Faaliyetleri

Bu aşamanın amacı, üretime / piyasaya sürülmeye geçmeden önce AUT'nin gerçek zamanlı doğrulanmasıdır. Bu aşamadan çıkmak için QA ekibi, ürünün kalitesinden emin olmak için farklı test türleri gerçekleştirir. Bu kusurun raporlanması ve yeniden test edilmesinin yanı sıra, bu aşamada çok önemli bir faaliyettir. Bu aşamanın önemli faaliyetleri şunlardır -

Sistem Entegrasyon Testi

Ürünün / AUT'nin gerçek doğrulaması burada başlar. Sistem Entegrasyon Testi (SIT), sistemin belirlenen gereksinimlere / hazırlanan test senaryolarına uygunluğunu değerlendiren bir kara kutu test tekniğidir.

Sistem Entegrasyon Testi genellikle sistemin alt kümesinde gerçekleştirilir. SIT, test araçlarının minimum kullanımı ile gerçekleştirilebilir, alışverişi yapılan etkileşimler için doğrulanabilir ve her bir veri alanının bireysel katman içindeki davranışı da araştırılır. Entegrasyondan sonra, veri akışının üç ana durumu vardır:

Entegrasyon katmanındaki veri durumu
Veritabanı katmanındaki veri durumu
Uygulama katmanındaki veri durumu

Note- SIT testinde, QA ekibi kaliteyi sağlamak için olabildiğince çok kusur bulmaya çalışır. Buradaki ana amaç, olabildiğince çok böcek bulmaktır.

Kusur Raporlama

Beklenen sonuç gerçek sonuçla eşleşmediğinde bir yazılım hatası ortaya çıkar. Bir bilgisayar programındaki bir hata, kusur, başarısızlık veya arıza olabilir. Hataların çoğu, geliştiriciler veya mimarlar tarafından yapılan hatalardan ve hatalardan kaynaklanır.

SIT testi gerçekleştirirken, QA ekibi bu tür kusurları bulur ve bunların ilgili ekip üyelerine bildirilmesi gerekir. Üyeler daha fazla önlem alır ve kusurları düzeltir. Raporlamanın bir diğer avantajı da kusurların durumunun izlenmesini kolaylaştırmasıdır. Hata raporlama ve izlemeyi destekleyen ALM, QC, JIRA, Version One, Bugzilla gibi birçok popüler araç vardır.

Kusur Raporlama, müşterilerin geri bildirimlerini test ederek veya kaydederek ve müşterinin geri bildirimlerine göre kusurları gideren ürünün yeni sürümlerini oluşturarak test edilen uygulamada veya üründeki kusurları bulma sürecidir.

Hata izleme aynı zamanda yazılım mühendisliğinde önemli bir süreçtir çünkü karmaşık ve kritik iş sistemleri yüzlerce kusura sahiptir. En zorlayıcı faktörlerden biri, bu kusurları yönetmek, değerlendirmek ve önceliklendirmektir. Belirli bir süre içinde kusurların sayısı katlanarak bunları etkin bir şekilde yönetmek için, işi kolaylaştırmak için hata takip sistemi kullanılmaktadır.

Hata Haritalama

Kusur rapor edildikten ve günlüğe kaydedildikten sonra, ilgili başarısız / engellenen test durumları ve Gereksinim İzlenebilirlik Matrisindeki ilgili gereksinimlerle eşleştirilmelidir. Bu haritalama Defect Reporter tarafından yapılır. Doğru bir kusur raporu yapılmasına ve üründeki kötülüğün analiz edilmesine yardımcı olur. Test senaryoları ve gereksinimleri kusurla eşleştirildikten sonra, paydaşlar, önceliğe ve ciddiyete göre kusurun düzeltilmesi / ertelenmesi konusunda analiz yapabilir ve karar alabilir.

Yeniden test

Yeniden test, sorunun çözülüp çözülmediğini kontrol etmek için AUT'ye karşı daha önce başarısız olan bir testi yürütmektir. Bir kusur giderildikten sonra, aynı çevresel koşullar altında senaryoyu kontrol etmek için yeniden test yapılır.

Yeniden test sırasında, test uzmanları değişen işlevsellik alanında ayrıntılı ayrıntılar arar, regresyon testi ise bu değişiklik nedeniyle hiçbir işlevin bozulmamasını sağlamak için tüm ana işlevleri kapsar.

Gerileme testi

Tüm kusurlar kapalı, ertelenmiş veya reddedilmiş durumdayken ve test durumlarından hiçbiri devam etmiyor / başarısız oluyor / çalıştırılmıyorsa, sistem entegrasyon testinin tamamen test durumlarına ve gereksinimlere dayandığı söylenebilir. Ancak, kod değişiklikleri / kusur düzeltmeleri nedeniyle hiçbir işlevselliğin bozulmadığından emin olmak için bir tur hızlı test gereklidir.

Regresyon testi, kod değişiklikleri nedeniyle etkisi olan testlerin yeniden yürütülmesinden oluşan bir kara kutu test tekniğidir. Bu testler, yazılım geliştirme yaşam döngüsü boyunca mümkün olduğunca sık yapılmalıdır.

Regresyon Testlerinin Türleri

Final Regression Tests- Belirli bir süre boyunca bir değişikliğe uğramamış olan yapıyı doğrulamak için bir "son regresyon testi" gerçekleştirilir. Bu yapı dağıtılır veya müşterilere gönderilir.
Regression Tests - Derlemenin, uygulamanın diğer bölümlerinden herhangi birini hataların düzeltilmesi veya iyileştirilmesi için yapılan son kod değişiklikleriyle bozmadığını doğrulamak için normal bir regresyon testi gerçekleştirilir.

Etkinlik Blok Şeması

Aşağıdaki blok diyagram, bu aşamada gerçekleştirilen önemli faaliyetleri göstermektedir; aynı zamanda önceki aşamalardaki bağımlılığı da gösterir -

Hata Yaşam Döngüsü olarak da bilinen Kusur Yaşam Döngüsü, bir kusurun ömrü boyunca geçirdiği döngü olan bir kusurun yolculuğudur. Yazılım test süreci tarafından yönetildiği ve ayrıca kullanılan araçlara bağlı olduğu için organizasyondan kuruma ve ayrıca projeden projeye değişir.

Kusur Yaşam Döngüsü - İş Akışı

Aşağıdaki şema, Kusur Yaşam Döngüsünün iş akışını göstermektedir.

Kusurlu Yaşam Döngüsünün Durumları

Bir Kusur Yaşam Döngüsünün farklı durumları aşağıdadır.

New - Ortaya çıkan ve henüz doğrulanacak potansiyel kusur.
Assigned - Ele alınacak bir geliştirme ekibine atandı.
Active- Kusur, geliştirici tarafından ele alınıyor ve soruşturma devam ediyor. Bu aşamada, iki olası sonuç vardır - Ertelendi veya Reddedildi.
Test / Fixed / Ready for Retest - Kusur düzeltildi ve test edilmeye hazır.
Verified - Tekrar test edilen ve test QA tarafından doğrulanan Kusur.
Closed - Kusurun, KG'nin yeniden test edilmesinden sonra kapatılabilen veya kusur yinelenmesi veya kusur DEĞİLDİR olarak kabul edilmesi durumunda kapatılabilen son durumu.
Reopened - Kusur DÜZELTİLMEDİĞİNDE, QA arızayı yeniden açar / yeniden etkinleştirir.
Deferred - Söz konusu döngüde bir kusur ele alınamadığında, gelecekteki sürüme ertelenir.
Rejected - Bir kusur, üç nedenden herhangi biri nedeniyle reddedilebilir - yinelenen kusur, Kusur DEĞİL, Tekrarlanamaz.

Kusurlar, QA ekibi perspektifinden şu şekilde sınıflandırılır: Priority ve geliştirme perspektifinden bakıldığında Severity(düzeltmek için kod karmaşıklığı). Bunlar, zaman diliminde önemli bir rol oynayan iki ana sınıflandırmadır ve kusurları düzeltmek için harcanan çalışma miktarıdır.

Öncelik nedir?

Öncelik, kusurların çözülmesi gereken sıra olarak tanımlanır. Öncelik durumu genellikle QA ekibi tarafından, kusurun düzeltilmesi için zaman diliminden bahseden geliştirici ekibine karşı kusur ortaya çıkarılırken belirlenir. Öncelik durumu, son kullanıcıların gereksinimlerine göre belirlenir.

Örneğin, şirket logosu şirketin web sayfasına yanlış yerleştirilmişse, öncelik yüksek, ancak düşük önemdedir.

Öncelikli Listeleme

Bir Öncelik, aşağıdaki şekillerde sınıflandırılabilir:

Low - Bu kusur, kritik olanlar giderildikten sonra düzeltilebilir.
Medium - Kusur, sonraki yapılarda çözülmelidir.
High - Kusur, uygulamayı önemli ölçüde etkilediğinden ve ilgili modüller düzeltilene kadar kullanılamayacağından derhal çözülmelidir.
Urgent - Kusur, uygulamayı veya ürünü ciddi şekilde etkilediği ve ürün giderilene kadar kullanılamayacağı için derhal çözülmelidir.

Önem nedir?

Önem derecesi, uygulama üzerindeki kusurun yetersizliği ve kodun geliştirme açısından düzeltmek için karmaşıklığı olarak tanımlanır. Itürünün geliştirme yönü ile ilgilidir. Önem derecesi, sistem için kusurun ne kadar kötü / önemli olduğuna göre belirlenebilir. Önem durumu, kusur nedeniyle işlevsellikteki sapma hakkında fikir verebilir.

Example - Uçuş işletme web sitesi için, rezervasyona karşı bilet numarasının oluşturulmasındaki kusur, yüksek ciddiyet ve aynı zamanda yüksek önceliktir.

Önem Listesi

Önem derecesi aşağıdaki şekillerde kategorize edilebilir -

Critical /Severity 1- Kusur, Uygulamanın en önemli işlevlerini etkiler ve QA ekibi, düzeltilmeden test edilen uygulamanın doğrulanmasına devam edemez. Örneğin, Uygulama / Ürün sık sık çöküyor.
Major / Severity 2- Kusur, işlevsel bir modülü etkiler; QA ekibi söz konusu modülü test edemez ancak diğer modüllerin doğrulanmasına devam eder. Örneğin, uçuş rezervasyonu çalışmıyor.
Medium / Severity 3- Kusurun tek ekranda sorunu var veya tek bir işlevle ilgili, ancak sistem hala çalışıyor. Buradaki kusur herhangi bir işlevi engellemez. Örneğin, Bilet #, ilk beş karakter gibi uygun alfa sayısal karakterleri ve sayısal olarak son beşi takip etmeyen bir temsildir.
Low / Severity 4- İşlevselliği etkilemez. Kozmetik bir kusur, bir alan için kullanıcı arayüzü tutarsızlığı veya kullanıcı arayüzünden son kullanıcı deneyimini iyileştirmek için bir öneri olabilir. Örneğin, Gönder düğmesinin arka plan rengi Kaydet düğmesinin rengiyle eşleşmiyor.

Testin artık tamamlandığını iddia etmek için test çıkış kriterlerine göre bir kontrol çok önemlidir. Test sürecine son verilmeden önce ürün kalitesi testi tamamlama kriterlerine göre ölçülür.

Bu aşamanın giriş kriterleri, test senaryosunun yürütülmesinin tamamlanmış olması, test sonuçlarının mevcut olması ve kusur raporunun hazır olmasıdır.

Testi tamamlama kriterleri aşağıdakileri içerir -

Belirtilen kapsam sağlandı.
Hayır showstoppers veya kritik kusurlar
Bilinen çok az orta veya düşük öncelikli kusur vardır. Bunlar ürünün kullanımını etkilemez.

Bu aşamanın çıkış kriteri, test kapanış raporlarının sağlanması ve daha sonra müşteri tarafından imzalanan matrislerin hazırlanmasıdır.

Şimdi tartışalım activities involved in the closure of Test Cycle.

Test Tamamlama Raporu

Test tamamlama raporlaması, paydaşları güncellemek için test ölçümlerinin özetlenmiş biçimde raporlandığı bir süreçtir. Bu onların bilinçli bir karar almalarını sağlar.

Test Tamamlama Raporu aşağıdaki bilgileri içerir.

Test Özeti Rapor Tanımlayıcısı
Summary
Variances
Özet Sonuçlar
Evaluation
Planlanan ve Gerçek Çabalar
Oturumu Kapat

İyi bir Test Tamamlama Raporu kaliteyi gösterir, olağanüstü riskleri ölçer ve test edilen bir yazılımın seviyesini tanımlar.

Test Tamamlama Matrisi

Testin tamamlanmasının ardından, test raporlarını hazırlamak için çeşitli matrisler toplanır. Raporları hazırlama kriterleri aşağıdakileri içerir:

Yürütülen Test Sayısı
Geçen Test Sayısı
Başarısız Test Sayısı
Her modüle göre Başarısız Test Sayısı
Yürütme döngüsü sırasında ortaya çıkan Test Kusurlarının Sayısı
Kabul Edilen Test Kusurlarının Sayısı
Reddedilen Test Kusurlarının Sayısı
Ertelenen Test Kusurlarının Sayısı
Aktif kusurların durumu
Yapının Kalite İndeksinin Hesaplanması

Test sonuçları

Bir test senaryosu yürütürken, hataları yeniden test ederken ve regresyon testi senaryosu gerçekleştirirken, Test results articulate kaydedilmelidir ve test yürütmesinin tamamlanmasını desteklemek için test döngüsü kapanış belgeleriyle birlikte üretilebilir.

Açıklamalar ekran görüntüleri, veritabanı sorgu sonuçları, kayıt, günlük dosyaları vb. Olabilir.