how create requirements traceability matrix
Yazılım Testinde Gereksinimler İzlenebilirlik Matrisi (RTM) nedir: Örnekler ve örnek şablonla İzlenebilirlik Matrisi oluşturmak için adım adım kılavuz
Bugünün öğreticisi, ya fazla basitleştirilmiş (gözden kaçan) ya da fazla vurgulanmış - yani, önemli bir kalite kontrol aracı hakkındadır. İzlenebilirlik Matrisi (TM).
Çoğu zaman, bir İzlenebilirlik Matrisinin oluşturulması, gözden geçirilmesi veya paylaşılması, birincil kalite güvence süreci çıktılarından biri değildir - bu nedenle büyük ölçüde üzerinde yoğunlaşmaz, dolayısıyla az vurguya neden olur. Aksine, bazı müşteriler bir TM'nin ürünleri hakkında dünyayı sarsan yönleri ortaya çıkarmasını bekler (test aşamasındadır) ve hayal kırıklığına uğrarlar.
'Doğru kullanıldığında, bir İzlenebilirlik Matrisi, QA yolculuğunuz için GPS'niz olabilir'.
Genel bir uygulama olduğu gibi bir şey , bu makalede bir ÇB'nin 'Ne' ve 'Nasıl' yönlerini göreceğiz.
Ne öğreneceksin:
- Gereksinim İzlenebilirlik Matrisi Nedir?
- Test Kapsamı ve Gereksinim İzlenebilirliği
- Gereksinimler İzlenebilirlik Matrisi Nasıl Oluşturulur
Gereksinim İzlenebilirlik Matrisi Nedir?
Gereksinim İzlenebilirlik Matrisi veya RTM'de, müşteri tarafından önerilen kullanıcı gereksinimleri ile inşa edilmekte olan sistem arasındaki bağlantıları belgelemek için bir süreç kurarız. Kısacası, kullanıcı gereksinimlerini test senaryolarıyla haritalamak ve izlemek için üst düzey bir belgedir ve her gereksinim için yeterli düzeyde test yapılmasını sağlar.
Herhangi bir gereksinim için tanımlanan tüm test senaryolarını gözden geçirme sürecine İzlenebilirlik adı verilir. İzlenebilirlik, test süreci sırasında hangi gereksinimlerin en fazla sayıda kusuru ortaya çıkardığını belirlememizi sağlar.
Herhangi bir test görevinin odak noktası, maksimum test kapsamıdır ve bu olmalıdır. Kapsam dendiğinde, test edilecek her şeyi test etmemiz gerektiği anlamına gelir. Herhangi bir test projesinin amacı% 100 test kapsamı olmalıdır.
Gereksinimler İzlenebilirlik Matrisi, kapsam yönüyle ilgili kontroller yaptığımızdan emin olmanın bir yolunu belirler. Kapsama boşluklarını belirlemek için bir anlık görüntü oluşturmaya yardımcı olur. Kısacası, her gereksinim için Çalıştırılan, Başarılı, Başarısız veya Engellenen Test senaryolarının sayısını belirleyen metrikler olarak da adlandırılabilir.
Gereksinim İzlenebilirliği Neden Gereklidir?
Gereksinim İzlenebilirlik Matrisi, gereksinimleri ilişkilendirmeye yardımcı olur, Test durumları ve kusurları doğru. Uygulamanın tamamı Gereksinim İzlenebilirliğine ( Uçtan uca test bir uygulamanın elde edilmesi).
java'da nesne dizisini kullanarak bir yöntem nasıl çağırılır
Gereksinim İzlenebilirlik, tüm özellikler test edilirken uygulamanın iyi bir 'Kalitesini' garanti eder. Kalite kontrol Yazılım, öngörülemeyen senaryolar için minimum kusurla test edildiğinde ve tüm İşlevsel ve işlevsel olmayan gereksinimlerin karşılanmasıyla elde edilebilir.
Gereksinim İzlenebilirlik Matrisi, öngörülen sürede test edilen yazılım uygulamasına yardımcı olur, projenin kapsamı iyi belirlenir ve müşteri istek ve ihtiyaçlarına göre uygulanması sağlanır ve projenin maliyeti iyi kontrol edilir.
Kusur Sızıntıları, uygulamanın tamamı gereksinimleri için test edilerek önlenir.
İzlenebilirlik Matrisi Türleri
İleri İzlenebilirlik
Test senaryolarına yönelik 'İleri İzlenebilirlik' Gerekliliklerinde. Projenin istenilen yönde ilerlemesini ve her ihtiyacın kapsamlı bir şekilde test edilmesini sağlar.
Geriye Doğru İzlenebilirlik
Test Örnekleri 'Geriye Dönük İzlenebilirlik' deki Gereksinimlerle eşleştirilmiştir. Temel amacı, geliştirilmekte olan mevcut ürünün doğru yolda olmasını sağlamaktır. Ayrıca, belirtilmemiş ekstra işlevlerin eklenmediğini ve dolayısıyla projenin kapsamının etkilendiğini belirlemeye yardımcı olur.
Çift Yönlü İzlenebilirlik
(İleri + Geri): İyi bir İzlenebilirlik matrisi, test senaryolarından gereksinimlere ve tam tersine (gereksinimlerden test senaryolarına) referanslara sahiptir. Bu, 'Çift Yönlü' İzlenebilirlik olarak adlandırılır. Tüm Test senaryolarının gereksinimlere göre izlenmesini ve belirtilen her gereksinimin onlar için doğru ve geçerli Test senaryolarına sahip olmasını sağlar.
RTM Örnekleri
# 1) İşletme Gereksinimi
BR1 : E-posta yazma seçeneği mevcut olmalıdır.
BR1 için Test Senaryosu (teknik özellik)
TS1 : Posta oluştur seçeneği sağlanır.
Test Durumları:
Test Senaryosu 1 (TS1.TC1) : Posta oluştur seçeneği etkinleştirildi ve başarıyla çalışıyor.
Test Senaryosu 2 (TS1.TC2) : Posta oluştur seçeneği devre dışı bırakılır.
# 2) Kusurlar
Test senaryoları gerçekleştirildikten sonra, iş gereksinimleri, test senaryoları ve test senaryoları ile listelenebilecek ve eşleştirilebilecek herhangi bir kusur bulunursa.
Örneğin, TS1.TC1 başarısız olursa, yani E-posta oluştur seçeneği etkinleştirilmesine rağmen düzgün çalışmıyorsa, bir hata günlüğe kaydedilebilir. Otomatik oluşturulan veya manuel olarak atanan kusur kimliğinin D01 olduğunu varsayalım, bu durumda bu BR1, TS1 ve TS1.TC1 numaraları ile eşleştirilebilir.
Böylece tüm Gereksinimler bir tablo formatında gösterilebilir.
| İş gereksinimi # | Test Senaryosu # | Test durumu # | Kusurlar # |
|---|---|---|---|
| BR1 | TS1 | TS1.TC1 TS1.TC2 | D01 |
| BR2 | TS2 | TS2.TC1 TS2, TC2 TS2.TC3 | D02 D03 |
| BR3 | TS3 | TS1.TC1 TS2.TC1 TS3.TC1 TS3.TC2 | NIL |
Test Kapsamı ve Gereksinim İzlenebilirliği
Test Kapsamı Nedir?
Test Kapsamı, test aşaması başladığında müşterilerin hangi gereksinimlerinin doğrulanacağını belirtir. Test Kapsamı, yazılım uygulamasının tamamen test edilmesini sağlamak için test senaryolarının yazılıp yürütüldüğünü belirleyen bir terimdir, böylelikle minimum veya NIL kusurları rapor edilir.
Test Kapsamı nasıl elde edilir?
Maksimum Test Kapsamı, iyi bir 'Gereksinim İzlenebilirliği' oluşturularak elde edilebilir.
- Tüm dahili kusurların tasarlanan test senaryolarıyla eşleştirilmesi
- Müşteri Tarafından Bildirilen Kusurların (CRD) gelecekteki regresyon testi paketi için ayrı test senaryolarıyla eşleştirilmesi
Gereksinim Özellikleri Türleri
# 1) İşletme Gereksinimleri
Gerçek müşterilerin gereksinimleri şu şekilde bilinen bir belgede listelenmiştir: İşletme Gereksinimleri Belgesi (BRS) . Bu BRS, müşteri ile kısa bir etkileşimden sonra, en ince ayrıntısına kadar yüksek seviyeli gereksinim listesinden türetilmiştir.
Genellikle 'İş Analistleri' veya 'Mimar' tarafından hazırlanır (organizasyon veya proje yapısına bağlı olarak). 'Yazılım Gereksinim Özellikleri' (SRS) belgesi, BRS'den alınmıştır.
# 2) Yazılım Gereksinimleri Spesifikasyon Dokümanı (SRS)
İşlevsel ve işlevsel olmayan tüm gereksinimlerin tüm titiz ayrıntılarını içeren ayrıntılı bir belgedir. Bu SRS, yazılım uygulamalarının tasarlanması ve geliştirilmesi için temeldir.
# 3) Proje Gereksinim Belgeleri (PRD)
PRD, bir projedeki tüm ekip üyeleri için bir ürünün tam olarak ne yapması gerektiğini anlatan bir referans belgedir. Ürünün Amacı, Ürün Özellikleri, Yayın Kriterleri ve Projenin Bütçelendirme ve Çizelgesi gibi bölümlere ayrılabilir.
# 4) Kullanım Durumu Belgesi
Yazılımın iş ihtiyaçlarına göre tasarlanmasına ve uygulanmasına yardımcı olan belgedir. Bir aktör ile olay arasındaki etkileşimleri, bir hedefe ulaşmak için gerçekleştirilmesi gereken bir rolle eşler. Bir görevin nasıl yapılması gerektiğine dair ayrıntılı bir adım adım açıklamadır.
Örneğin,
Aktör: Müşteri
Rol: Oyun indir
Oyun indirme işlemi başarılı.
Kullanım Örnekleri, kuruluşun çalışma sürecine göre SRS belgesine dahil edilen bir parça da olabilir.
# 5) Kusur Doğrulama Belgesi
Kusurlarla ilgili tüm detayları içerecek şekilde belgelenmiştir. Ekip, kusurların düzeltilmesi ve yeniden test edilmesi için bir 'Kusur Doğrulama' belgesi tutabilir. Test uzmanları, kusurların giderilip giderilmediğini doğrulamak istediklerinde, farklı işletim sistemlerinde, cihazlarda, farklı sistem konfigürasyonlarında vb. Kusurları yeniden test edebilirler.
'Kusur Doğrulama' belgesi, özel bir kusur giderme ve doğrulama aşaması olduğunda kullanışlı ve önemlidir.
# 6) Kullanıcı Hikayeleri
Kullanıcı hikayesi, öncelikle bir yazılım özelliğini son kullanıcı perspektifinden tanımlamak için 'Çevik' geliştirmede kullanılır. Kullanıcı hikayeleri, kullanıcı türlerini ve belirli bir özelliği ne şekilde ve neden istediklerini tanımlar. Gereksinim, kullanıcı hikayeleri oluşturarak basitleştirilmiştir.
Şu anda, tüm yazılım endüstrileri, Kullanıcı Hikayeleri ve Çevik Geliştirme ve gereksinimleri kaydetmek için ilgili yazılım araçlarının kullanımına doğru hareket ediyor.
İhtiyaç Toplama Zorlukları
# 1) Toplanan Gereksinimler ayrıntılı, açık, doğru ve iyi belirtilmiş olmalıdır. Ama orada HAYIR Gereksinim toplama için gerekli olan bu ayrıntıları, belirsizliği, doğruluğu ve iyi tanımlanmış özellikleri hesaplamak için uygun ölçü.
#iki) Gereksinim bilgilerini sağlayan 'İş Analisti' veya 'Ürün Sahibi' nin yorumu çok önemlidir. Benzer şekilde, bilgiyi alan ekibin de paydaşların beklentilerini anlamak için uygun açıklamaları yapması gerekir.
Anlayış, hem iş ihtiyaçları hem de uygulama uygulaması için gereken fiili çabalarla uyumlu olmalıdır.
# 3) Bilgi ayrıca son kullanıcının bakış açısından da türetilmelidir.
# 4) Paydaşların farklı zamanlarda çelişen veya çelişen gereksinimleri belirtir.
# 5) Son kullanıcı bakış açısı, birden fazla nedenden dolayı dikkate alınmaz ve diğer paydaşlar, bir ürün için neyin gerekli olduğunu 'tamamen' anladıklarını düşünürler, ki bu genellikle böyle değildir.
# 6) Kaynaklar, geliştirilen uygulama için beceri eksikliği.
# 7) Uygulamada sık sık 'Kapsam' değişiklikleri veya modüller için öncelik değişikliği.
# 8) Eksik, örtük veya belgelenmemiş gereksinimler.
# 9) Müşteriler tarafından belirlenen tutarsız veya belirsiz gereksinimler.
# 10) Yukarıda belirtilen tüm faktörlerin sonucu, bir projenin 'Başarısı' veya 'Başarısızlığı' nın büyük ölçüde bir gereksinime bağlı olduğudur.
Gereksinim İzlenebilirliği Nasıl Yardımcı Olabilir
# 1) Gereksinim nerede uygulanır?
Örneğin,
Gereksinim: Bir posta uygulamasında 'Posta Oluştur' İşlevini uygulayın.
Uygulama: Ana sayfada 'E-posta oluştur' düğmesinin nereye yerleştirilmesi ve erişilmesi gerekir.
# 2) Bir gereklilik gerekli mi?
Örneğin,
Gereksinim: Bir posta uygulamasında yalnızca belirli kullanıcılara 'Posta Oluştur' İşlevini uygulayın.
Uygulama: Kullanıcı erişim haklarına göre, e-posta gelen kutusu 'Salt okunur' ise, bu durumda 'E-posta oluştur' düğmesi gerekli olmayacaktır.
# 3) Bir Gereksinimi nasıl yorumlarım?
Örneğin,
Gereksinim: Yazı tipleri ve eklerle bir posta uygulamasında 'Posta Oluştur' İşlevselliği.
Uygulama: 'E-posta oluştur' tıklandığında, hangi tüm özellikler sağlanmalıdır?
- Farklı yazı tiplerinde e-postalar yazmak ve düzenlemek için Metin Gövdesi ve ayrıca kalın, italik, altını çizin
- Ek türleri (Resimler, belgeler, diğer e-postalar vb.)
- Eklerin boyutu (İzin verilen maksimum boyut)
Böylece Gereksinimler alt gereksinimlere bölünür.
# 4) Bir Gereksinimin uygulanmasını hangi tasarım kararları etkiler?
Örneğin,
Gereksinim: 'Gelen Kutusu', 'Gönderilmiş postalar', 'Taslaklar', 'Spam', 'Çöp Kutusu' vb. Tüm öğeler açıkça görünür olmalıdır.
Uygulama: Görünür olacak öğeler 'Ağaç' biçiminde veya 'Sekme' biçiminde görüntülenmelidir.
# 5) Tüm Gereksinimler tahsis edildi mi?
Örneğin,
Gereksinim: 'Çöp Kutusu' posta seçeneği sağlanır.
Uygulama: 'Çöp Kutusu' posta seçeneği sağlandıysa, postaları 'Sil' seçeneği (gereklilik) başlangıçta uygulanmalı ve doğru şekilde çalışmalıdır. Postayı 'Sil' seçeneği düzgün çalışıyorsa, yalnızca silinen e-postalar 'Çöp Kutusu' nda toplanacak ve 'Çöp Kutusu' posta seçeneğinin (gereksinim) uygulanması mantıklı olacaktır (faydalı olacaktır).
RTM ve Test Kapsamının Avantajları
# 1) Geliştirilen ve test edilen yapı, 'Müşteriler' / 'Kullanıcılar' ihtiyaçlarını ve beklentilerini karşılayan gerekli işlevselliğe sahiptir. Müşteri istediğini almalıdır. Müşteriyi yapması bekleneni yapmayan bir uygulama ile şaşırtmak hiç kimse için tatmin edici bir deneyim değildir.
#iki) Müşteriye geliştirilen ve teslim edilen son ürün (Yazılım Uygulaması) yalnızca ihtiyaç duyulan ve beklenen işlevleri kapsamalıdır. Yazılım uygulamasında sağlanan ekstra özellikler, onu geliştirmek için ek bir zaman, para ve çaba harcanıncaya kadar başlangıçta çekici görünebilir.
Ekstra özellik ayrıca, kurulumdan sonra müşteri için sorunlara neden olabilecek bir Kusur kaynağı olabilir.
# 3) Geliştiricinin ilk görevi, müşteri gereksinimlerine göre yüksek öncelikli gereksinimleri uygulamaya ilk önce çalışırken açıkça tanımlanır. Müşterinin yüksek öncelikli gereksinimleri açıkça belirtilmişse, bu kod bileşenleri birinci öncelikte geliştirilebilir ve uygulanabilir.
Böylelikle son ürünün müşteriye sevk edilme şansının en üst gereksinimlere göre ve programa uygun olması sağlanır.
# 4) Test uzmanları ilk olarak geliştiriciler tarafından gerçekleştirilen en önemli işlevselliği doğrular. Öncelikli yazılım bileşeninin doğrulanması (Test) ilk olarak yapıldığından, sistemin ilk sürümlerinin ne zaman ve ilk sürümlerinin piyasaya sürülmeye hazır olup olmadığını belirlemeye yardımcı olur.
# 5) Doğru Test planları, Test senaryoları yazılır ve yürütülür, bu da tüm uygulama gereksinimlerinin doğru şekilde uygulandığını doğrular. Gereksinimlerle eşleştirilen test senaryoları, büyük kusurların gözden kaçmamasını sağlamaya yardımcı olur. Müşteri beklentilerine göre kaliteli bir ürünün uygulanmasına da yardımcı olur.
# 6) İstemciden 'Değişiklik İsteği' gelmesi durumunda, değişiklik talebinden etkilenen tüm uygulama bileşenleri değiştirilir ve hiçbir şey göz ardı edilmez. Bu, bir değişiklik talebinin yazılım uygulamasına yaptığı etkiyi değerlendirmeyi daha da geliştirir.
# 7) Görünüşte basit olan bir değişiklik isteği, uygulamanın birkaç bölümünde yapılması gereken değişiklikleri içerebilir. Değişikliği yapmayı kabul etmeden önce ne kadar çaba sarf etmeniz gerektiğine dair bir sonuç çıkarmak daha iyidir.
Test Kapsamındaki Zorluklar
# 1) İyi İletişim Kanalı
Tarafından önerilen herhangi bir değişiklik varsa Paydaşlar aynı şeyin, geliştirmenin önceki aşamalarında Geliştirme ve Test ekiplerine iletilmesi gerekir. Bu olmadan zamanında Uygulama geliştirme, test etme ve kusurların yakalanması / düzeltilmesi garanti edilemez.
# 2) Test Senaryolarına öncelik vermek önemlidir
Hangilerinin yüksek öncelikli, karmaşık ve önemli test senaryoları olduğunu belirlemek zor bir iştir. Hepsini test etmeye çalışıyorum Test senaryoları neredeyse ulaşılamaz bir görev. Senaryoları test etmenin amacı, işletme ve son kullanıcı açısından çok açık olmalıdır.
# 3) Süreç Uygulama
Test süreci, teknik altyapı ve uygulamalar, ekip becerileri, geçmiş deneyimler, takip edilen organizasyon yapıları ve süreçler, maliyet, zaman ve kaynaklar ile ilgili proje tahminleri ve zaman dilimlerine göre ekibin konumu gibi faktörler dikkate alınarak açıkça tanımlanmalıdır.
Belirtilen faktörleri dikkate alan tek tip bir süreç uygulaması, projeyle ilgili her bireyin aynı sayfada olmasını sağlar. Bu, uygulama geliştirmeyle ilgili tüm süreçlerin sorunsuz akışına yardımcı olur.
# 4) Kaynakların Kullanılabilirliği
Kaynaklar iki türdendir; uzmanlık alanına özgü test uzmanları ve test uzmanları tarafından kullanılan test araçları. Test uzmanları alan hakkında yeterli bilgiye sahiplerse, etkili test senaryoları ve komut dosyaları yazıp uygulayabilirler. Bu senaryoları ve komut dosyalarını uygulamak için test uzmanları uygun 'Test Araçları' ile iyi bir şekilde donatılmış olmalıdır.
Windows 7 için en iyi kötü amaçlı yazılım temizleme
Uygulamanın iyi bir şekilde uygulanması ve müşteriye zamanında teslim edilmesi, tek yetenekli test cihazı ve uygun test araçlarıyla sağlanabilir.
# 5) Etkili Test Stratejisi uygulaması
' Test Stratejisi'nin kendisi büyük ve ayrı bir tartışma konusudur. Ancak burada 'Test Kapsamı' için etkili bir test stratejisi uygulaması, ' Kalite' uygulamanın iyi ve budur korunmuş her yerde zaman içinde.
Etkili bir 'Test Stratejisi', her tür kritik zorluğun önceden planlanmasında önemli bir rol oynar ve bu da daha iyi bir uygulama geliştirmeye yardımcı olur.
Gereksinimler İzlenebilirlik Matrisi Nasıl Oluşturulur
Birlikte olmak için tam olarak neyin izlenmesi veya izlenmesi gerektiğini bilmemiz gerekir.
Test uzmanları test senaryolarını / hedeflerini yazmaya başlar ve sonunda bazı girdi belgelerine dayalı olarak test senaryoları - İş gereksinimleri belgesi, İşlevsel Özellikler belgesi ve Teknik Tasarım belgesi (isteğe bağlı).
Diyelim ki, İş Gereksinimleri Belgemiz (BRD): ( Bu örnek BRD'yi excel biçiminde indirin )
(Büyütmek için herhangi bir resme tıklayın)
Aşağıda, İş Gereksinimleri Belgesinin (BRD) yorumlanmasına ve bilgisayar uygulamalarına uyarlanmasına dayanan İşlevsel Özellikler Belgemiz (FSD) bulunmaktadır. İdeal olarak, FSD'nin tüm yönlerinin BRD'de ele alınması gerekir. Ancak basitlik uğruna, sadece 1. ve 2. maddeleri kullandım.
BRD'nin Üzerinden Örnek FSD: ( Bu örnek FSD'yi excel biçiminde indirin )
Not : BRD ve FSD, QA ekipleri tarafından belgelenmez. Biz sadece, diğer proje ekipleriyle birlikte belgelerin tüketicisiyiz.
Yukarıdaki iki girdi belgesine dayanarak, QA ekibi olarak test etmemiz için aşağıdaki üst düzey senaryolar listesini oluşturduk.
Yukarıdaki BRD ve FSD'den Örnek Test Senaryoları: ( Bu Örnek Test Senaryoları dosyasını indirin )
Buraya vardığımızda, Gereksinim İzlenebilirlik Matrisini oluşturmaya başlamak için şimdi iyi bir zaman olacaktır.
Şahsen izlemek istediğimiz her belge için sütun içeren çok basit bir excel sayfasını tercih ediyorum. İş gereksinimleri ve işlevsel gereksinimler benzersiz bir şekilde numaralandırılmadığından, takip etmek için belgedeki bölüm numaralarını kullanacağız.
(Özellikle sizin durumunuz için en mantıklı olana bağlı olarak satır numaralarına veya madde işaretli nokta numaralarına vb. Göre izlemeyi seçebilirsiniz.)
Örneğimiz için basit bir İzlenebilirlik Matrisi şöyle görünür:
Yukarıdaki belge, BRD'den FSD'ye ve nihayetinde test senaryoları arasında bir iz oluşturur. Bunun gibi bir belge oluşturarak, ilk gereksinimlerin her yönünün test takımları tarafından test takımlarını oluştururken dikkate alınmasını sağlayabiliriz.
Bu şekilde bırakabilirsiniz. Ancak daha okunaklı olması için bölüm isimlerini eklemeyi tercih ediyorum. Bu, bu belge müşteri veya başka bir ekiple paylaşıldığında anlayışı geliştirecektir.
Sonuç aşağıdaki gibidir:
Yine, eski formatı veya sonrasını kullanma seçimi size aittir.
Bu, TM'nizin ön sürümüdür ancak genellikle burada durduğunuzda amacına hizmet etmez. Kusurlara kadar tahminde bulunduğunuzda maksimum fayda elde edilebilir.
Nasıl olduğunu görelim.
Bulduğunuz her test senaryosu için en az 1 veya daha fazla test senaryosuna sahip olacaksınız. Bu nedenle, oraya vardığınızda başka bir sütun ekleyin ve test senaryosu kimliklerini aşağıda gösterildiği gibi yazın:
Bu aşamada İzlenebilirlik Matrisi boşlukları bulmak için kullanılabilir. Örneğin, Yukarıdaki İzlenebilirlik Matrisinde, FSD bölüm 1.2 için yazılmış hiçbir test senaryosu olmadığını görüyorsunuz.
Genel bir kural olarak, İzlenebilirlik Matrisindeki herhangi bir boş alan, araştırma için potansiyel alanlardır. Dolayısıyla, böyle bir boşluk iki şeyden biri anlamına gelebilir:
- Test ekibi 'Mevcut kullanıcı' işlevini bir şekilde gözden kaçırdı.
- 'Mevcut Kullanıcı' işlevi, daha sonrasına ertelendi veya uygulamanın işlevsellik gereksinimlerinden çıkarıldı. Bu durumda, TM, FSD veya BRD'de bir tutarsızlık gösterir - bu, FSD ve / veya BRD belgelerinde bir güncelleme yapılması gerektiği anlamına gelir.
Senaryo 1 ise,% 100 kapsama sağlamak için test ekibinin biraz daha çalışması gereken yerleri gösterecektir.
Senaryo 2'de, TM sadece boşlukları göstermez, anında düzeltilmesi gereken yanlış belgelere işaret eder.
Şimdi ÇB'yi test senaryosu yürütme durumunu ve kusurları içerecek şekilde genişletelim.
İzlenebilirlik Matrisinin aşağıdaki versiyonu genellikle Testin yürütülmesi sırasında veya sonrasında hazırlanır:
Gereksinimler İzlenebilirlik Matrisi şablonunu indirin:
=> Excel Formatında İzlenebilirlik Matrisi Şablonu
Dikkat Edilmesi Gereken Önemli Noktalar
İzlenebilirlik Matrisinin bu sürümü hakkında dikkat edilmesi gereken önemli noktalar şunlardır:
# 1) Yürütme durumu da görüntülenir. Yürütme sırasında, işin nasıl ilerlediğine dair konsolide bir anlık görüntü verir.
# 2) Kusurlar: Geriye dönük İzlenebilirliği oluşturmak için bu sütun kullanıldığında, 'Yeni kullanıcı' işlevselliğinin en kusurlu olduğunu söyleyebiliriz. Test vakalarının başarısız olduğunu bildirmek yerine, TM, en çok kusuru olan iş gereksinimine şeffaflık sağlar ve böylece Kaliteyi müşterinin istediği şekilde gösterir.
# 3) Bir sonraki adım olarak, kusur kimliğini durumlarını temsil edecek şekilde renklendirebilirsiniz. Örneğin, Kırmızı kusur kimliği, hala açık olduğu anlamına gelebilir, yeşil renkte ise kapalı olduğu anlamına gelebilir. Bu yapıldığında, TM, belirli bir BRD veya FSD işlevselliğine karşılık gelen kusurların durumunu açık veya kapalı olarak görüntüleyen bir sağlık kontrolü raporu olarak çalışır.
# 4) Bir teknik tasarım belgesi veya kullanım senaryoları veya izlemek istediğiniz başka yapılar varsa, yukarıda oluşturulan belgeyi ek sütunlar ekleyerek ihtiyaçlarınıza uyacak şekilde her zaman genişletebilirsiniz.
Özetlemek gerekirse, RTM şu konularda yardımcı olur:
- % 100 test kapsamının sağlanması
- Gereksinim / Belge tutarsızlıklarını gösterme
- İş Gereksinimlerine odaklanarak genel Kusur / Yürütme durumunu görüntüleme.
- Belirli bir iş ve / veya işlevsel gereksinim değişecekse, bir TM, test senaryolarını yeniden gözden geçirme / yeniden çalışma açısından QA ekibinin çalışması üzerindeki etkiyi tahmin etmeye veya analiz etmeye yardımcı olur.
Bunlara ek olarak,
- İzlenebilirlik Matrisi, Manuel Teste özel bir araç değildir, Otomasyon projeleri için de kullanılabilir. Bir Otomasyon projesi için test senaryosu kimliği, Otomasyon Testi komut dosyası adını gösterebilir.
- Aynı zamanda sadece QA'lar tarafından kullanılabilecek bir araç değildir. Geliştirme ekibi, BRD / FSD gereksinimlerini, tüm gereksinimlerin geliştirildiğinden emin olmak için oluşturulan kod blokları / birimleri / koşullarıyla eşlemek için aynısını kullanabilir.
- Test Yönetimi araçları gibi HP ALM dahili izlenebilirlik özelliği ile birlikte gelir.
Dikkat edilmesi gereken önemli bir nokta şudur:İzlenebilirlik Matrisinizi koruma ve güncelleme şekliniz, kullanımının etkinliğini belirler. Sık sık güncellenmezse veya yanlış güncellenmezse, araç bir yardımcı olmak yerine bir yüktür ve aletin tek başına kullanılmaya değer olmadığı izlenimini yaratır.
java dizisinden elemanlar nasıl kaldırılır
Sonuç
Gereksinim İzlenebilirlik Matrisi, harita ve izleme Müşterinin test senaryoları ve keşfedilen kusurlarla ilgili tüm gereksinimleri. Bu bir tek belge Bu, hiçbir test senaryosunun kaçırılmaması ve dolayısıyla uygulamanın her işlevinin kapsanması ve test edilmesi temel amacına hizmet eder.
Önceden planlanan İyi 'Test Kapsamı', test aşamalarında tekrar eden görevleri ve Kusur sızıntılarını önler. Kusur sayısının yüksek olması, testin iyi yapıldığını ve dolayısıyla uygulamanın 'Kalitesinin' arttığını gösterir. Benzer şekilde, çok düşük bir kusur sayısı testin işarete kadar yapılmadığını gösterir ve bu, uygulamanın 'Kalitesini' olumsuz bir şekilde engeller.
Test Kapsamı kapsamlı bir şekilde yapılırsa, düşük bir hata sayımı haklı gösterilebilir ve bu hata sayısı, birincil değil, destekleyici istatistikler olarak kabul edilebilir. Bir uygulamanın kalitesi, Test Kapsamı en üst düzeye çıkarıldığında ve kusur sayısı en aza indirildiğinde 'İyi' veya 'Tatmin Edici' olarak adlandırılır.
Yazar hakkında: STH ekip üyesi Urmila P., deneyimli bir QA Uzmanıdır. yüksek kalite test etme ve sorun izleme becerileri.
Projelerinizde Gereksinim İzlenebilirlik Matrisi oluşturdunuz mu? Bu makalede oluşturduklarımıza ne kadar benzer veya farklı? Lütfen bu makale ile ilgili deneyimlerinizi, yorumlarınızı, düşüncelerinizi ve geri bildirimlerinizi yorumlarınızla paylaşın.
Önerilen Kaynaklar
- Format ve İçerikli Örnek Yazılım Test Planı Şablonu
- Etkili Bir Test Özeti Raporu Nasıl Yazılır (Örnek Rapor İndir)
- Test Senaryosu Örneklerini içeren Örnek Test Durumu Şablonu (İndir)
- Örneklerle Kabul Testi Raporu için Örnek Şablon
- Test Stratejisi Belgesi Nasıl Yazılır (Örnek Test Stratejisi Şablonuyla)
- Yazılım Gereksinimleri Spesifikasyonu (SRS) Nasıl Test Edilir?
- İlk 20'den Fazla En İyi Gereksinim Yönetim Aracı (Tam Liste)
- QA Yazılım Test Kontrol Listeleri (Örnek Kontrol Listeleri Dahildir)