Menü

SRS Belgesi Nasıl Gözden Geçirilir ve Test Senaryoları Oluşturulur - Canlı Bir Projede Yazılım Test Eğitimi - 2. Gün

  • Ana
  • Yazılım Test Şablonları
  • SRS Belgesi Nasıl Gözden Geçirilir ve Test Senaryoları Oluşturulur - Canlı Bir Projede Yazılım Test Eğitimi - 2. Gün

how review srs document

Sorunları Ortadan Kaldırmak Için Enstrümanımızı Deneyin

Bu bizim programımızdaki ikinci öğreticidir. 'Canlı bir proje için ücretsiz çevrimiçi Yazılım Testi eğitimi' dizi. Burada yeniyseniz lütfen ilk giriş eğitimine bakın: Canlı Bir Projede Uçtan Uca Yazılım Test Eğitimi.

Şimdi bir SRS adım adım ilerlemesinin nasıl gerçekleştiğine, bu adımdan neyi tanımlamamız gerektiğine, başlamadan önce hangi ön adımları atmamız gerektiğine, karşılaşabileceğimiz zorlukların neler olduğuna vb. İlişkin ayrıntılı bir analize geçelim. detaylı bir şekilde.

SRS Belgesi Nasıl Gözden Geçirilir ve Test Senaryoları Oluşturulur_

SDLC’nin Tasarım Aşaması:

SDLC'nin bir sonraki aşaması 'Tasarım' dır - bu, işlevsel gereksinimlerin teknik ayrıntılara dönüştürüldüğü yerdir. Geliştirme, tasarım, ortam ve veri ekipleri bu adımda yer alır. Bu adımın sonucu tipik olarak bir Teknik Tasarım Belgesi - TDD'dir.

Girdi, hem TDD'nin oluşturulması hem de QA ekibinin projenin QA yönü üzerinde çalışmaya başlaması için - SRS'yi gözden geçirmek ve test hedefini belirlemek için - SRS belgesidir.

Ne öğreneceksin:

SRS İncelemesi Nedir?

SRS, geliştirme ekibi tarafından İş Analistleri ve çevre / veri ekipleri ile işbirliği içinde oluşturulan bir belgedir. Tipik olarak, bu belge tamamlandıktan sonra, ayrıntılı bir açıklamanın düzenlendiği bir toplantı aracılığıyla QA ekibiyle paylaşılacaktır.

Bazen, halihazırda var olan bir başvuru için resmi bir toplantıya ve bu belgede bize rehberlik edecek birine ihtiyacımız olmayabilir. Bunu kendi başımıza yapmak için gerekli bilgilere sahip olabiliriz.

SRS incelemesi, işlevsel gereksinimler spesifikasyon belgesini gözden geçirmek ve hedef uygulamanın nasıl olacağını anlamaya çalışmaktan başka bir şey değildir.

Resmi format ve bir örnek bir önceki makalede sizlerle paylaşıldı. Bu, tüm SRS'lerin tam olarak bu şekilde belgeleneceği anlamına gelmez. Daima form içeriğe göre ikincildir .

uyku () c ++

Bazı takımlar sadece madde işaretli bir liste yazmayı seçecek, bazı takımlar kullanım senaryoları içerecek, bazı takımlar örnek ekran görüntüleri (elimizdeki belge gibi) içerecek ve bazıları sadece paragraflardaki ayrıntıları açıklayacak.

Yazılım Gereksinimlerinin İncelenmesi için Ön Adımlar

Aşama 1) Belgeler birden çok revizyondan geçer, bu nedenle referans verilen SRS belgesinin doğru sürümüne sahip olduğumuzdan emin olun.

Adım 2) Gözden geçirmenin sonunda her ekip üyesinden ne beklendiğine ilişkin yönergeler oluşturun. Diğer bir deyişle, bu adımdan hangi çıktıların beklendiğine karar verin - tipik olarak, bu adımın çıktısı test senaryolarını belirlemektir. Test senaryoları, belirli işlevler için 'neyin test edileceğine' dair bir satır işaretten başka bir şey değildir.

Aşama 3) Ayrıca bu çıktının nasıl sunulacağına dair kılavuzlar oluşturun - yani şablon.

Adım 4) Ekibin her bir üyesinin tüm belge üzerinde çalışıp çalışmayacağına veya kendi aralarında bölüşüp bölmeyeceğine karar verin. Herkesin her şeyi okuması şiddetle tavsiye edilir çünkü bu, belirli ekip üyeleriyle bilgi yoğunlaşmasını önleyecektir.

Ancak 1000 sayfaya yakın SRS belgelerinin çalıştığı büyük bir proje durumunda, belge modülünü akıllıca ayırma ve ekip üyelerine ayrı ayrı atama yaklaşımı en pratiktir.

Adım 5) SRS incelemesi, yazılımın test edilmesi için gerekli herhangi bir özel ön koşul olup olmadığını daha iyi anlamaya da yardımcı olur.

Adım 6) Bir yan ürün olarak, bazı işlevlerin anlaşılmasının zor olduğu veya işlevsel gereksinimlere daha fazla bilginin dahil edilmesi gerektiğinde veya SRS'de hata yapıldığında sorgular listesi belirlenir.

Başlamak için neye ihtiyacımız var?

  • SRS belgesinin doğru sürümü
  • Kimin ne üzerinde çalışacağına ve ne kadar zamanları olduğuna dair açık talimatlar.
  • Test Senaryoları oluşturmak için bir şablon.
  • Diğer bilgiler - bir soru durumunda kiminle iletişime geçileceği veya bir dokümantasyon tutarsızlığı durumunda kime bildirileceği hakkında diğer bilgiler

Bu bilgiyi kim sağlayacak?

Ekip liderleri genellikle yukarıdaki bölümde listelenen tüm öğeleri sağlamaktan sorumludur. Ancak, ekip üyelerinin girdileri tüm bu çabanın başarısı için her zaman önemlidir.

Takım liderleri sık sık soruyor: Ne tür girdiler? İlgilenmeyen bir ekip üyesine belirli bir modülü atamak daha iyi olmaz mıydı? Hedef tarihe takımın görüşüne göre karar vermek, onlara bir karar vermek daha güzel olmaz mıydı? Ayrıca, bir projenin başarısı için şablonlar önemlidir.

Windows 10 için en iyi bilgisayar temizleme yazılımı

Genel bir kural olarak, şablonlar, belirli ekibin rahatlığı ve rahatlığına göre uyarlandıklarında daha yüksek bir verimlilik oranına sahiptir. Bu nedenle, ekip liderlerinin ekip üyeleri olduğundan daha çok lider olduğu unutulmamalıdır. Ekibinizi günlük kararlara dahil etmek, projenin sorunsuz çalışması için çok önemlidir.

Test Senaryoları İçin Şablon Gerekli mi?

Neden test senaryoları için bir şablon - sadece bir liste yaparsak bu yeterli değil mi?

Kesinlikle öyle. Ancak, yazılım projeleri 'tek kişilik' gösteriler değildir. İçerirler takım çalışması .

Her biri yazılım gereksinimleri spesifikasyonunun bir modülünü gözden geçirmeye karar verirse, 4 kişilik bir ekip düşünün. Takım üyesi A, bir kağıt üzerine bir liste yaptı. Takım üyesi 2 bir excel sayfası kullandı. Takım üyesi 3 bir not defteri kullandı. Takım üyesi 4 bir kelime doc kullandı. Günün sonunda proje için yapılan tüm çalışmaları nasıl birleştiririz?

Ayrıca, hangisinin standart olduğuna nasıl karar verebiliriz ve başlangıçta kuralları biz oluşturmadıysak neyin doğru neyin doğru olmadığını nasıl söyleyebiliriz?

Şablon budur: Tüm ekip için tekdüzelik ve uyuşma için bir dizi kılavuz ve üzerinde anlaşılan bir format.

QA Test Senaryoları için bir şablon nasıl oluşturulur?

Şablonlar karmaşık veya esnek olmamasına gerek yok.

Tek ihtiyaç duydukları şey, yararlı bir test yapısı oluşturmak için etkili bir mekanizma. Aşağıda gördüğümüz gibi basit bir şey:

test senaryoları şablonu

Bu şablonun başlığı proje, mevcut belge ve referans alınan belge hakkında temel bilgileri yakalamak için gereken alanı içerir.

Aşağıdaki tablo Test Senaryoları oluşturmamıza izin verecektir. Dahil edilen sütunlar şunlardır:

1. Sütun) Test Senaryosu Kimliği
Test sürecimizdeki her varlığın benzersiz bir şekilde tanımlanabilir olması gerekir. Bu nedenle, her test senaryosuna bir kimlik atanmalıdır. Bu ID atanırken uyulması gereken kurallar tanımlanmalıdır.

Bu makalenin iyiliği için adlandırma kuralını şu şekilde izleyeceğiz: TS (Test Senaryosu anlamına gelen önek) ve ardından '_', modül adı BEN Mİ (Orange HRM projesinin My Info modülü), ardından '_' ve ardından alt bölüm ( Örneğin, BEN Mİ Bilgilerim Modülü için, P fotoğraf vb. için) ve ardından bir seri numarası. Bir örnek şöyle olabilir: 'TS_MI_MIM_01'.

Sütun # 2) Gereklilik
Bir test senaryosu oluşturduğumuzda, onu aldığımız SRS belgesinin bölümüne geri eşleştirebilmemize yardımcı olur. Gereksinimlerin kimlikleri varsa, bunu kullanabiliriz. SRS belgesinin bölüm numaraları veya çift sayfa numaraları değilse, test edilebilir bir gereksinim belirlediğimiz yerde işe yarayacaktır.

Sütun 3) Test Senaryosu açıklaması
'Neyin test edileceğini' belirten tek satırlık bir kılavuz. Buna test hedefi olarak da değineceğiz.

Sütun # 4) Önem
Bu, AUT için belirli işlevlerin ne kadar önemli olduğu hakkında bir fikir vermek içindir. Bu alana yüksek, orta ve düşük gibi değerler atanabilir. Ayrıca 1-5 gibi bir puan sistemi de seçebilirsiniz, 5 en önemli, 1 daha az önemli. Bu alanın alabileceği değer ne olursa olsun, önceden karar verilmesi gerekir.

Sütun # 5) Test durumlarının sayısı
Tek bir test senaryosunu yazarak sonuçta kaç tane test senaryosu oluşturabileceğimize dair kabaca bir tahmin. Örneğin, Girişi test etmek için şu durumları dahil ediyoruz: Kullanıcı adını ve şifreyi düzeltin. Kullanıcı adı ve yanlış şifreyi düzeltin. Doğru şifre ve yanlış kullanıcı adı. Dolayısıyla, oturum açma işlevinin doğrulanması 3 test durumu ile sonuçlanacaktır.

Not: Bu şablonu genişletebilir veya uygun gördüğünüz alanları kaldırabilirsiniz.

Örneğin , başlığa 'İnceleyen' ekleyebilir veya oluşturma tarihini kaldırabilirsiniz, vb. Ayrıca tabloya, belirli bir test senaryosundan sorumlu test ediciyi belirlemek için bir 'Oluşturan' alanı ekleyebilir veya 'No. Test durumları ”sütunu. Seçim senin. Tüm ekip için en iyi olanı seçin.

Şimdi Orange HRM SRS Belgemizi inceleyelim ve Test Senaryolarını oluşturalım

Profesyonel İpucu: Herhangi bir belgenin nasıl akacağı ve ne kadar çalışma içerebileceği konusunda iyi bir fikir edinmek için 1. öğreticilerde sunduğumuz SRS örneğindeki içindekiler tablosuna bakın.

Bölüm 1 belgenin amacıdır. Orada test edilebilir gereksinim yok.

Bölüm 2.1 : Projeye Genel Bakış - Kitle - orada da test edilebilir gereksinim yok.

Bölüm 2.2 : Donanım ve Barındırma - Bu bölüm Orange HRM sitesinin nasıl barındırılacağından bahsediyor. Şimdi, bu bilgi biz testçiler için önemli mi? Cevap Evet ve Hayır. Evet, çünkü test ettiğimizde gerçek zamanlı ortama benzer bir ortama ihtiyacımız var.

Bu bize nasıl olması gerektiğine dair bir fikir verir. Hayır, çünkü bu test edilebilir bir gereklilik değil - testin gerçekleşmesi için bir tür ön koşul.

test senaryosu ve test senaryosu arasındaki fark

Bölüm 3: Burada bir giriş ekranı ve siteye girmemiz gereken hesap türünün detayları var. Bu test edilebilir bir gerekliliktir. Bu yüzden Test senaryolarımızın bir parçası olması gerekiyor.

Lütfen SRS'nin birkaç bölümü için test senaryolarının eklendiği test senaryoları belgesine bakın. Uygulama için, lütfen senaryoların geri kalanını benzer şekilde ekleyin. Ancak, belgenin 4. bölümüne doğru gidiyorum.

Bölüm 4: Estetik / HTML Gereksinimleri ve Yönergeleri - Bu bölüm, SRS incelemesi sırasında bazı gereksinimlerin test ekibine ne kadar anlamlı gelmeyebileceğini en iyi şekilde açıklar, ancak ekip bunları aynı şekilde test edilebilir gereksinimler olarak not etmelidir.

Bunları nasıl test edeceğimiz ve belirli bir kuruluma / herhangi bir ekibin doğrulama için yardımına ihtiyacımız olursa, bu noktada şu anda bilmeyebileceğimiz ayrıntılardır. Ancak bunları test kapsamımızın bir parçası yapmak, onları gözden kaçırmamamızı sağlamak için ilk adımdır.

OrangeHRM Uygulaması için Örnek Test Senaryoları: (resmi büyütmek için tıklayın)

test senaryoları şablonu

=> Lütfen bakın ve Test Senaryoları belgesini indirin daha fazla bilgi için.

SRS İncelemesine İlişkin Bazı Önemli Gözlemler

# 1) Hiçbir bilgi açıkta bırakılmamalıdır.
#iki) Belirli bir gereksinimin doğru olup olmadığı ve ayrıca test edilip edilemeyeceği konusunda fizibilite analizi yapın.
# 3) Ayrı bir performans / güvenlik veya başka herhangi bir test ekibi olmadığı sürece, tüm işlevsel olmayan gereksinimlerin dikkate alınması gerektiğinden emin olmak bizim işimizdir.
# 4) Tüm bilgiler test uzmanlarına yönelik değildir, bu nedenle neye dikkat edip nelerin not edilmeyeceğini anlamak önemlidir.
# 5) Önemi ve hayır. Bir test senaryosu için test senaryolarının% 'si doğru olmak zorunda değildir ve yaklaşık bir değerle doldurulabilir veya boş bırakılabilir.

Özetlemek gerekirse, SRS incelemesi şunlarla sonuçlanır:

  • Test Senaryoları listesi
  • Sonuçları Gözden Geçirme - SRS belgesini statik olarak geçerek / doğrulayarak bulunan belge / Gereksinim hataları
  • Daha iyi anlamak için bir Soru listesi - herhangi bir durumda
  • Test ortamının nasıl olması gerektiğine dair ön fikir
  • Test kapsamı tanımlaması ve kaç test senaryosuna sahip olabileceğimize dair kabaca bir fikir - yani dokümantasyon ve nihayetinde yürütme için ne kadar zamana ihtiyacımız var.

Dikkat edilmesi gereken önemli noktalar:

# 1) Test senaryoları harici çıktılar değildir (İş Analistleri veya Geliştirme ekipleri ile paylaşılmaz) ancak dahili QA tüketimi için önemlidir. Bunlar,% 100 test kapsamı hedefine doğru ilk adımımızdır. Test senaryoları tamamlandıktan sonra bir meslektaş incelemesine tabi tutulur ve bu yapıldıktan sonra hepsi birleştirilir.

QA belgelerinin nasıl gözden geçirildiği hakkında daha fazla ayrıntı için şu makaleye göz atın: 6 Basit Adımda Test Dokümantasyonu İncelemeleri Nasıl Gerçekleştirilir.

#iki) Gibi bir test yönetimi aracı kullanabiliriz HP ALM veya qTest test senaryoları oluşturmak için. Ancak, Test senaryolarının gerçek zamanlı olarak oluşturulması manuel bir faaliyettir. Bence manuel olarak daha uygun. 1. adım olduğu için henüz büyük silahları ortaya çıkarmamıza gerek yok. Basit excel sayfaları, bunu yapmanın en iyi yoludur.

Bu dizinin bir sonraki adımı şudur: - test senaryoları oluşturmaya çalışacağız ve test tasarımı aşamasına geçeceğiz. Ondan önce, biz de gireceğiz - Test planlaması nedir?Tüm QA projesine nerede uyuyor? Her zaman olduğu gibi, en iyi sonuçlar için bizimle çalışın.

QA Eğitimi 3. Gün: Sıfırdan bir SRS belgesi nasıl yazılır.

Lütfen sorularınızı ve yorumlarınızı saklayın. Okurunuz için çok teşekkür ederiz!

Önerilen Kaynaklar

^