Örnek sorular
Qa Automation FundamentalsZorluk 1
Klasik test otomasyon piramidinde, en fazla test hangi katmanda olmalıdır?
- aUnit testler — hızlı, ucuz ve hatayı kesin işaret eder✓
- bUçtan uca UI testler; gerçek kullanıcı davranışını en iyi onlar yansıtır
- cManuel keşifsel testler; insan muhakemesi otomatikleştirilemez
- dEntegrasyon testleri; test başına en fazla iş mantığını onlar kapsar
Açıklama:Piramit şekli maliyet ve hızı yansıtır: unit testler milisaniyeler içinde çalışır ve hatayı kesin olarak işaret eder, bu yüzden geniş taban onlardır. b ve d, piramidin tam olarak kaçındığı şeyi yapıp kapsamın büyük kısmını yavaş/pahalı katmanlara koyuyor. c ise piramidi katman oranı meselesi yerine otomasyona karşı bir argüman gibi yanlış okuyor.
Qa Automation FundamentalsZorluk 2
Bir test senaryosu, tek seferlik bir veri migrasyonunu doğrulamak için tam olarak bir kez çalıştırılacak ve bir daha hiç çalıştırılmayacak. Otomasyon ROI açısından en makul yaklaşım hangisidir?
- aTamamen otomatikleştir; otomasyon manuel teste her zaman üstündür
- bManuel test et; tek çalıştırma bir script'in maliyetini geri ödemez✓
- cSadece son assertion'ı otomatikleştir, gerisini elle yap
- dDoğrulamayı atla; tek seferlik migrasyonlar nadiren kontrol gerektirir
Açıklama:Otomasyon ROI'si, tekrarlanan çalıştırmaların baştaki maliyeti amorti etmesinden gelir; tam olarak bir kez çalışan bir senaryo bu maliyeti asla geri kazanamaz, bu yüzden manuel doğrulama akılcı seçimdir. a otomasyonu maliyetten bağımsız olarak evrensel şekilde üstün sayıyor. c ve d ise ya sorunu yarım çözüyor ya da riskli bir işlemin doğrulamasını tamamen atlıyor.
Qa Automation FundamentalsZorluk 2
Aşağıdaki senaryolardan hangisi otomatik test suite'ine en güçlü yatırım getirisini (ROI) sağlar?
- aNeredeyse her sprint değişen bir ekranın UI düzen kontrolü
- bTek seferlik bir ad-hoc rapor için yapılan manuel veri kontrolü
- cCheckout gibi stabil bir çekirdek akışın her release'de doğrulanması✓
- dHâlâ aktif tasarım değişikliği geçiren yepyeni deneysel bir özellik
Açıklama:ROI, stabilite ve tekrar ile artar: stabil bir akışın her release'de test edilmesi, otomasyon maliyetini az yeniden-yazımla birçok çalıştırmaya yayar. a ve d hâlâ değişiyor, yani otomatik kontroller sürekli yeniden yazılmalı; b ise tek seferlik çalıştığı için maliyetin amorti edileceği bir tekrar yok.
Qa Automation FundamentalsZorluk 1
"Flaky" (kararsız) test nedir?
- aKoddaki gerçek bir bug yüzünden her zaman başarısız olan test
- bCI pipeline'a dahil edilemeyecek kadar yavaş olan test
- cKullanımdan kaldırılmış ama henüz silinmemiş test
- dKod değişmediği halde bazen geçen bazen kalan test✓
Açıklama:Flaky, değişmeyen bir sistemde deterministik olmayan sonuç anlamına gelir ve suite'e güveni aşındırır. a, sürekli (deterministik) başarısız olan bir testi tanımlar; bu flaky değil gerçek bir bug'dır. b ve c, tutarsız sonuçla ilgisiz, farklı bakım sorunlarını anlatır.
Qa Automation FundamentalsZorluk 2
Bir otomatik test, asenkron bir güncellemeyi tetikleyen bir butona tıklıyor, sonra sonucu hemen kontrol ediyor ve özellik doğru çalışsa da ara sıra başarısız oluyor. En olası kök neden nedir?
- aTest, güncelleme bitmeden sonucu kontrol ediyor✓
- bTest ortamının veritabanı bozulmuş durumda
- cButon elementinde bir erişilebilirlik etiketleme sorunu var
- dTest, uygulamanın eski bir build'ine karşı çalışıyor
Açıklama:Bir asenkron işlemi tetikledikten hemen sonra kontrol etmek, değişken tamamlanma süresine karşı yarışa girer; bu klasik bir zamanlama-kaynaklı flakiness kalıbıdır. b, c ve d, anlatılan ara sıra 'bazen geçme' kalıbı yerine tutarlı, tekrar edilebilir başarısızlıklara yol açardı.
Qa Automation FundamentalsZorluk 2
İki test tek başına çalıştırıldığında güvenilir şekilde geçiyor, ama ikincisi birinciden hemen sonra çalıştırıldığında ara sıra başarısız oluyor; çünkü birinci test, ikincinin kontrol ettiği sayıyı değiştiren bir kayıt bırakıyor. Bu durumu en iyi ne açıklar?
- aAsenkron çağrılar arasında bir zamanlama/yarış durumu
- bBirinci testten kalan state, ikincinin başlangıcını değiştiriyor✓
- cRunner ile sunucu arasında kararsız bir ağ bağlantısı
- dCI aracı testlerin çalışma sırasını rastgeleleştirdi
Açıklama:Bir testten kalan verinin diğer testin başlangıç koşullarını değiştirmesi, testler arası state sızıntısının tam tanımıdır. a ilgisiz, çünkü burada asenkron bir zamanlama yok; c'ye dair bir belirti yok; d ise gerçek başarısızlık mekanizması olan paylaşılan değişebilir state yerine sıranın rastgeleleştirildiğini anlatıyor.