Örnek sorular
Qa Test StrategyZorluk 1
Test piramidi modelinde, şeklin (geniş taban, dar tepe) temsil ettiği şey nedir?
- aBir sprint sırasında testlerin yazılması gereken sıra
- bRelease sürecinin her katmanına atanan test uzmanı sayısı
- cHer seviyede kaç test olduğu, tabanda çok✓
- dHer katmanda test yazmak için gereken kıdem
Açıklama:Test piramidi, her seviyedeki testlerin göreli oranı için bir kılavuzdur: tabanda çok sayıda hızlı, ucuz unit test; ortada daha az integration test; tepede az sayıda yavaş, pahalı uçtan uca test. Yazma sırasıyla, kadroyla ya da kıdemle ilgili değildir.
Qa Test StrategyZorluk 2
Unit testler neden genellikle test piramidinin en büyük katmanını oluşturur?
- aBağımlılıklardan izole olmaları hızlı ve ucuz kılar✓
- bMantık hatalarını tespit edebilen tek test türüdür
- cÇoğu organizasyonda yasal olarak zorunludur
- dHer türlü manuel test ihtiyacını ortadan kaldırır
Açıklama:Unit testler küçük bir kod birimini bağımlılıklarından izole eder, bu da onları hızlı ve ucuz bakımlı kılar, böylece ekipler çoğunu yazabilir. Integration ve uçtan uca testler de mantık hatalarını yakalar ama daha yavaş ve pahalı; unit testler yasal zorunluluk değildir ve hiçbir seviye manuel testin değerini ortadan kaldırmaz.
Qa Test StrategyZorluk 2
Bir ekibin test paketinde 800 unit test, 150 integration test ve 20 uçtan uca test var. Bu dağılım piramidin önerdiği şekle uyuyor mu?
- aHayır, toplam sayı production için çok düşük
- bEvet, sayı her seviyede yukarı çıktıkça küçülüyor✓
- cHayır, integration testler unit testlerden fazla olmalı
- dEvet, ama yalnızca uçtan uca testler en değerli olduğu için
Açıklama:Piramit şekli oranla ilgilidir: sayılar unit'ten (800) integration'a (150), oradan uçtan uca'ya (20) keskin küçülüyor, bu önerilen şekille örtüşüyor. Sabit bir toplam-sayı eşiği yoktur, integration testlerin unit testlerden fazla olması beklenmez, ve uçtan uca testlerin az olması maliyetlerinden kaynaklanır, değerinden değil.
Qa Test StrategyZorluk 1
Risk-bazlı test planlama nedir?
- aYalnızca bir bug production'a ulaştıktan sonra test yazmak
- bTest görevlerini en az deneyimli mühendise atamak
- cTüm riski ortadan kaldırmak için her senaryoyu çalıştırmak
- dÇabayı en riskli alanlara öncelik vererek yönlendirmek✓
Açıklama:Risk-bazlı test planlama, sınırlı test kaynağını başarısızlığın daha olası ya da daha zararlı olduğu alanlara yönlendirir; her parçayı eşit önemde saymaz. Yalnızca production hatasına tepki vermekle, deneyimsizliğe göre kadrolamayla ya da her yerde eksiksiz test denemekle ilgili değildir.
Qa Test StrategyZorluk 2
Bir üründe nadiren kullanılan bir ayarlar sayfası ve her müşteri için ödeme işleyen bir checkout akışı var, kod boyutları benzer. Risk-bazlı planlamada daha fazla test çabası nereye gitmeli?
- aCheckout'a, çünkü oradaki hatanın etkisi ve kapsamı yüksek✓
- bAyarlara, çünkü az kullanılan özellikler daha çok bug barındırır
- cİkisine eşit, çünkü önemli olan kod boyutudur
- dÖzel olarak hiçbirine; kullanım fark etmeksizin eşit dağıt
Açıklama:Risk-bazlı planlama hem olasılığı hem etkiyi tartar. Checkout'un etkisi yüksektir (finansal, her müşteriyi etkiler), bu da onu daha yüksek riskli alan yapar, bug olasılığı diğer özelliklerle benzer olsa bile. Kod boyutu tek başına riski belirlemez ve çabayı eşit bölmek gerçek sonuçları göz ardı eder.
Qa Test StrategyZorluk 1
Kod kapsamı (code coverage) neyi ölçer?
- aUygulanan gereksinimlerin yüzdesini
- bTest paketinin çalıştırdığı kod miktarını✓
- cTest senaryosu başına bulunan bug sayısını
- dİlk çalıştırmada geçen testlerin yüzdesini
Açıklama:Kod kapsamı, test paketi çalıştırılırken kaynak kodun ne kadarının çalıştırıldığını ölçer. Gereksinimlerin karşılanması, bug sayısı ya da geçme oranı hakkında doğrudan bir şey söylemez — bir test bir satırı çalıştırabilir ama doğruluğunu doğrulamayabilir.