Menü

Yazılım Testinde Test Kapsamı (Test Kapsamını En Üst Düzeye Çıkarma İpuçları)

test coverage software testing

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

Yazılım Testi Test Kapsamı Tam Kılavuzu: Nasıl Daha Fazla Test Yapılır, Zamandan Tasarruf Edilir ve Daha İyi Test Sonuçları Elde Edilir:

Yazılım testi, yazılım geliştirme ve bakım yaşam döngülerinde önemli bir faaliyettir. Yazılım kalitesine karar vermek ve iyileştirmek için sıklıkla kullanılan bir uygulamadır.

Günümüzde geliştirme daha sistematiktir ve kuruluşlar, testi tamamlama kriterlerini göstermek için test tamlığı ve etkinliği ölçütleri aramaktadır. Hepsinden kapsama alanı özellikle değerli kabul edilir.

Ne öğreneceksin:

Test Kapsamı nedir?

Basitçe ifade etmek gerekirse, kapsam 'Neyi test ediyoruz ve Ne kadarını test ediyoruz?'

Test kapsamı, test kalitesinin izlenmesine yardımcı olur ve test uzmanlarının eksik veya doğrulanmamış alanları kapsayan testler oluşturmasına yardımcı olur.

test kapsamı

Çoğu ekip, kapsam hesaplamalarını yalnızca işlevsel gereksinimlere dayandırır. Aynı zamanda adil çünkü bir uygulama her şeyden önce yapması gerekeni yapmalıdır. Değilse, hızı veya güvenliği veya kullanım kolaylığı - bunların hiçbiri önemli değil.

Ancak, adanmış ve bağımsızsa fonksiyonel olmayan test ekipler performans, güvenlik, kullanılabilirlik testi vb. üzerinde çalışıyorlar, ardından test kapsamı analitiği yoluyla gereksinimlerini yürütmeye kadar takip etmeleri gerekecek.

Test Kapsamı ve Kod Kapsamı

Test kapsamı genellikle Kod Kapsamı ile karıştırılır. Temel ilkeler aynı olsa da, iki farklı şeydir.

Kod kapsamı kodun tüm alanlarını en az bir kez hedeflemesi gereken ve geliştiriciler tarafından yapılan birim test uygulamalarından gerçekten bahsediyor.

Öte yandan, Test Kapsamı her gereksinimi test etmek en az bir kez ve açıkça bir QA ekip aktivitesidir.

Kapsanan bir gereksinim olmaya gerçekten neyin uygun olduğu, her ekibin yorumuna bağlıdır.

Örneğin , Bazı takımlar, karşı en az bir test davası varsa karşılanan bir şartı çağırır. Bazen, en az bir ekip üyesi atanmışsa kapsanır. Veya onunla ilişkili tüm test senaryoları yürütülürse.

  • Oluşturulan 10 gereksinim ve 100 test varsa - bu 100 test 10 gereksinimin tamamını hedeflediğinde ve hiçbirini atlamadığında - buna tasarım düzeyinde yeterli test kapsamı diyoruz.
  • Oluşturulan testlerin yalnızca 80'i yürütüldüğünde ve gereksinimlerin yalnızca 6'sını hedeflediğinde. Testlerin% 80'i yapılmasına rağmen 4 gereksinimin karşılanmadığını söylüyoruz. Bu, yürütme düzeyindeki kapsam istatistikleridir.
  • 8 gereksinimle ilgili yalnızca 90 test, test görevlileri atadığında ve geri kalanı olmadığında, test görevi kapsamının% 80 olduğunu söylüyoruz (10 gereksinimden 8'i).

Kapsamın ne zaman hesaplanacağı da önemlidir.

Bunu süreçte çok erken yaparsanız, birçok boşluk göreceksiniz çünkü işler hala eksiktir. Bu nedenle genellikle tavsiye edilir Son Yapıya kadar bekle ör. Son Regresyon Oluşturma. Bu, verilen Gereksinimler için gerçekleştirilen Testler için doğru bir kapsama sağlayacaktır.

Ayrıca => okuyun Sürüm ve Dağıtım Yönetimi Süreci

Benim deneyimim

8 yıl önce sahne: Yazılım testi endüstrisinde 2 yıllık deneyime sahip olduğumda, yazılım testiyle ilgili bazı temel bilgileri, deneyimle öğrenilebilecek bir şey olarak bilmiyorsam ve benim de yapacağım şeyin sorun olmayacağını düşünüyordum.

Ben haklıydım - hem de yanılmışım.

Doğru çünkü deneyimle daha büyük bir resim görmeyi öğrenirsiniz, “Kritik Durum” un gerçek anlamını anlarsınız ve son kullanıcıyı daha iyi anlarsınız.

Yanlış çünkü bahsedilen şeylerin hiçbiri tecrübe gerektiriyor, ama çok geç anladığım erken öğrenme. Bu yazıyı yazmak için cesaret verici faktör budur.

Daha Kısa Sürede Test Kapsamını En Üst Düzeye Çıkarın

İşte o zamanki röportajlardan birinde yaşadığım deneyim:

Test kapsamının eksiksiz veya maksimum olduğundan nasıl emin olursunuz? Sormuştum.

Ummmm …… Her işlevi test ettiğimden emin oluyorum , Dedim.

S o tüm işlevleri test ettikten sonra, test açısından maksimum uygulama / ürün kapsadığınızı düşündüğünüzü söylüyorsunuz , görüşmeci geri tepti.

Ummm… iyi… .ummm…. Evet, çünkü tüm işlevleri test ettiğinizde, uygulamanın / ürünün davranışından emin olursunuz, Cevabımı destekledim .

Katılıyorum, ancak sorum şu - test kapsamınızın maksimum veya eksiksiz olduğu konusunda size güven verecek mi? görüşmeci gitmeme izin verecek havada değildi.

Şimdi, sabırsızlanıyordum, yazılım testleriyle ilgili en önemli konulardan birini öğreneceğim gerçeği hakkında bilmiyordum - ' Test kapsamı' .

Röportajın alıntılarını çoğaltmaktansa, o gün Test Kapsamı hakkında öğrendiklerimi burada özetliyorum. Ancak ondan önce bir noktayı netleştirelim - test kapsamı hiçbir zaman yeterince test edip etmediğinizi bilmek anlamına gelmez, ne de mükemmel test ettiğiniz anlamına gelmez.

avast cleanup premium'a ücretsiz alternatifler

Test kapsamı anlamı

Test kapsamının farklı bağlamlarda farklı bir anlamı olabilir. Şimdi bu bağlamları tek tek keşfedelim:

Ürün kapsamı - Ürünün hangi yönlerine baktınız?

Evet, test kapsamı ürün açısından ölçülürken odaklanılması gereken ana alan - ürünün hangi alanlarını test ettiğiniz ve hangileri test edilmemiş olarak kaldığıdır?

Örnek 1:

'Bıçak' bir ürünse, test ediyorsunuz; sadece sebzeleri / meyveleri doğru şekilde kesip kesmediğini kontrol etmeye odaklanmayın. Aranacak başka hususlar da vardır, örneğin - kullanıcı bunu rahatça idare edebilmelidir.

Örnek 2:

Eğer 'not defteri' bir uygulama ise, test ediyorsanız, ilgili özellikleri kontrol etmeniz şarttır.

Ancak dikkat edilmesi gereken diğer hususlar şunlardır - uygulama, diğer uygulamaları aynı anda kullanırken düzgün yanıt verir, uygulama çökmez kullanıcı alışılmadık bir şey yapmaya çalıştığında kullanıcıya uygun uyarı / hata mesajları verilir, kullanıcı uygulamayı kolayca anlayabilir ve kullanabilir, gerektiğinde yardım içeriği mevcuttur.

Bahsedilen senaryolara bakmazsanız, uygulama için test kapsamının tamamlandığını iddia edemezsiniz.

Risk kapsamı - Hangi riskleri test ettiniz?

Risk kapsamı, eksiksiz test kapsamına sahip başka bir husustur. İlişkili riskleri de test edene kadar ürünü veya uygulamayı 'test edilmiş' olarak etiketleyemezsiniz. İlişkili risklerin kapsamı, genel test kapsamındaki önemli bir faktördür.

Örnek 1:

Bir uçağı test ederken, bir test uzmanı size uçağın iç sistemini tam olarak test ettiğini ve iyi çalıştığını söylerse, ancak uçağın yalnızca uçma kabiliyeti test sırasında kapsanmamışsa - tepkiniz ne olur?

Risk kapsamının anlamı budur. Riski uygulama / ürüne göre belirlemek ve iyice test etmek her zaman iyi bir uygulamadır.

Örnek 2:

Bir e-ticaret sitesini test ederken, test cihazı her etkili faktörü göz önünde bulundurdu, ancak web sitesine aynı anda ve Süper TEKLİF gününde erişen kullanıcı sayısının riskini dikkate almadı, dikkate alınmayan riskin büyük bir hata olduğu kanıtlandı.

Önerilen Kaynaklar =>

Gereksinimlerin kapsamı - Hangi gereksinimleri test ettiniz?

Bir ürün veya uygulama çok iyi geliştirilmişse, ancak müşterinin gereksinimlerine uymuyorsa, o zaman hiçbir faydası yoktur. Test sırasındaki gereksinim kapsamı, ürün kapsamı kadar önemlidir.

Örnek 1:

Aile işlevi için heyecanla, terziden elbisenizi dikmesini ve yakasındaki tavuskuşu mavisi gösteri düğmelerini takmasını istediniz.

Terzi elbiseyi dikerken bu düğmeleri yakaya koymanın iyi görünmeyeceğini düşündüğü için altın rengi bir bordür dikti. Kesinlikle deneme gününde mutsuz müşteri terziye ihtiyaçlara bağlı kalmadığı için bağırdı.

Örnek 2:

Bir sohbet uygulamasını test ederken, test uzmanı bir grupta birden fazla kullanıcının sohbet etmesi, iki kullanıcının birbirinden bağımsız sohbet etmesi, her türden ifadenin mevcut olması, kullanıcıya anında gönderilen güncellemeler vb. Gibi tüm önemli noktalara dikkat etti, ancak ihtiyaç belgesine bakmayı unuttu ki bu açıkça iki kullanıcı birbirinden bağımsız sohbet ettiğinde, video görüşmesi seçeneğinin etkinleştirilmesi gerektiğinden bahsetti.

Müşteri, iki kullanıcı bağımsız olarak sohbet ederken aramaya izin vereceğini iddia ederek sohbet uygulamasını pazarladı. Sohbet uygulamasına ne olacağını tahmin edebilirsiniz.

Ayrıca okumak => Gereksinim İzlenebilirlik Matrisi Nasıl Oluşturulur

Uygun bir Test Kapsamı yöntemi nasıl benimsenir?

Farkındalık her şeydir:

Öncelikle, QA ekibinin ne kadar işin dahil olduğunu ve tasarım görevlerinin nerede olduğunu bilmesi gerekir. Bu şekilde, daha fazla test eklenip eklenmeyeceğinin farkında olacaklar. Bunu yapmak için, tipik bir uygulama olduğu gibi bir RTM kullanabilirsiniz.

=> Hakkında daha fazla bilgi edinmek ve nasıl kullanılacağını öğrenmek için bu makaleye göz atın: Gereksinimler İzlenebilirlik Matrisi Nasıl Oluşturulur - Örnek Şablonla Tam Süreç

İkinci olarak, kaynak atamasını kontrol edin ve test yürütme süreci her şeyin daha etkili bir şekilde test edilip edilmediğini görmek için.

Aşağıdaki gibi bir tablo yardımcı olabilir:

Test TürüToplam VakalarYürütülen DavalarDurumYorumlar
İşlevsel1008050 geçiş, 30 başarısız
Uyumluluk100elli45 geçiş, 5 başarısız
Kullanılabilirlik10010098 geçiş, 2 başarısız
Son Regresyon10010099 geçiş, 1 başarısız

Her şeyin test edildiğinden nasıl emin olunur?

  • Her test uzmanı, gereksinimlerin ve test yöntemlerinin farkında olmalıdır
  • Gereksinimlerinize öncelik verin ve enerjinizi en çok ihtiyaç duyulan yere odaklayın
  • Belirli bir sürümün öncekinden ne kadar farklı olduğu hakkında bilgi sahibi olun, böylece kritik gereksinimleri daha doğru bir şekilde belirleyebilir ve maksimum pozitif kapsama odaklanabilirsiniz.
  • Test Otomasyonunu Uyarlayın
  • Test Yönetimi araçlarını kullanın her zaman bilgide kalmak
  • Akıllı iş ataması - En iyi kaynaklarınızı kritik görevlere yönlendirin ve yeni test uzmanlarının yeni bir bakış açısı için daha fazlasını keşfetmesine izin verin
  • Bir bakım tüm görevler için kontrol listesi ve çeşitli faaliyetler
  • Uygulama davranışına ilişkin içgörüler elde etmek için Geliştirme / Scrum / BA ekiplerinizle daha fazla etkileşim kurun
  • Tüm derleme döngülerinizi ve düzeltmelerinizi takip edin
  • İlk yapılarda (mümkün olduğunda) en çok etkileyen sorunları tespit edin, böylece daha sonraki olanlar daha iyi istikrar için çalışabilir ve önceki sorunların engellediği alanlara ulaşabilir.

Etkili test için kritik alanlar ve yöntemler

etkili test

# 1)Kaynak kargaşası: Ekip üyeleriniz arasında görev değişimi yapın. Bu, katılımı iyileştirmeye ve bilgi konsantrasyonunu önlemeye yardımcı olur.

#iki)Uyumluluk kapsamı: Bildiğinizden ve dahil ettiğinizden emin olun. farklı tarayıcılar ve platformlar uygulamanızı test etmek için.

ağ oluşturma mülakat soruları ve cevapları pdf

# 3)Mülkiyet: Test uzmanlarını sorumlu hale getirin ve üzerinde çalıştıkları modül / görev için onlara ücretsiz bir dizgin (tabii ki izleme ve destekle) verin. Bu, sorumluluk oluşturmaya yardımcı olur ve yol boyunca dayak yerine yaratıcı yollar denemelerini sağlar.

# 4)Son tarihler: Test aşamasının başlamasından önce son teslim tarihlerini bilmek, etkili planlamaya yardımcı olur

# 5)İletişim : Geliştirici ve diğer ekiplerle iletişimde kalın ne olduğunu bilmek için yayın döngüleri arasında.

# 6)Bir RTM koruyun: İyi bir türev görevi görür. Paydaşlar veya Müşteriler , hangi sürüm planının onaylanabileceğine bağlı olarak

Test Uzmanı için Test Kapsamı farkındalığının avantajları:

  • Öncelikle test görevi önceliklendirmeye yardımcı olur
  • % 100 ihtiyaç teminatına ulaşılmasına yardımcı olur veya başka bir deyişle ihtiyaç kaçağını önler
  • Etki Analizi kolaylaşır
  • Belirlenmesinde faydalıdır Çıkış kriteri
  • Bir test ucunun temiz bir test kapanış raporu

Sonuç

Test kapsamı, belirtilen bağlamlarla bitmez. Test kapsamı söz konusu olduğunda dikkate alınması gereken başka birçok nokta vardır.

Daha fazlasını test ettiğinizde sonuçların daha iyi olduğu her zaman doğru değildir. Aslında, görünürde bir strateji olmadan daha fazlasını test ettiğinizde, muhtemelen çok fazla zaman harcayacaksınız.

Daha yapılandırılmış bir yaklaşım,% 100 ihtiyaç kapsamı hedefi ve etkili test yöntemleri ile kaliteden ödün vermezsiniz.

Bu makalede özetlenen tekniklerin size bazı ipuçları vereceğini umuyoruz.

Gönderi hakkındaki yorumlarınızı ve görüşlerinizi yazın. Her zamanki gibi sizden haber almayı çok seviyoruz.

Önerilen Kaynaklar

^