SÖZLÜK
Raporlarımızda ve kapsam belgelerimizde geçen terimler. Her tanım tek başına okunur; birini anlamak için diğerini okumanız gerekmez.
API sözleşme testi, bir servisin belgelenmiş davranışına gerçekten uyup uymadığını denetler: hangi alanlar dönüyor, hangi tiplerde, hangi hata kodlarıyla.
Arayüz doğru göründüğü hâlde arkadaki servis sessizce değişmiş olabilir; bir alan opsiyonel olmuş, bir hata kodu 400'den 422'ye kaymış olabilir. Sözleşme testi bunu istemci fark etmeden önce yakalar. Geçerli isteklerin yanı sıra sınır değerleri, eksik alanları ve yetkisiz çağrıları da kapsar.
Bulgu, testte tespit edilen ve bağımsız olarak tekrar üretilebilen tek bir sorundur; tekrar üretilemeyen bir gözlem rapora bulgu olarak girmez.
"Hata" yerine "bulgu" diyoruz çünkü listenin bir kısmı kodda bir hata değildir: eksik bir kabul kriteri, tutarsız bir davranış ya da kullanıcıyı yoran bir akış olabilir. Her bulgu tekrar üretim adımları, beklenen ve gerçekleşen davranış, ortam bilgisi ve kanıtla birlikte gelir.
Doğrulama turu, siz düzeltmeleri yayınladıktan sonra ilgili bulguların yeniden test edilmesidir; kapanan, kapanmayan ve düzeltme sırasında bozulan maddeler ayrı ayrı listelenir.
Üçüncü liste çoğu süreçte yoktur ve en pahalı olanıdır: bir düzeltmenin başka bir yeri bozması yaygındır. Doğrulama turu tüm paketlerimize dahildir, ayrıca faturalandırılmaz.
Fonksiyonel test, ürünün yapacağını söylediği şeyi gerçekten yapıp yapmadığını, tanımlı senaryoları deneyerek doğrular.
Kapsam, kritik iş akışlarıdır: kayıt, giriş, arama, sepet, ödeme, veri girişi ve yetkilendirme. Yalnızca mutlu yol değil; geçersiz girdi, yarıda kalan işlem, geri tuşu ve eşzamanlı oturum gibi gerçek hayatta olan durumlar da denenir.
Kabul kriteri, bir özelliğin "bitti" sayılabilmesi için sağlaması gereken, önceden yazılmış ve tek tek doğrulanabilir koşullardır.
İyi yazılmış bir kabul kriteri tartışmayı bitirir: ya sağlanmıştır ya sağlanmamıştır. "Hızlı açılmalı" bir kriter değildir; "3G bağlantıda ilk içerik 2,5 saniyede görünmeli" kriterdir. Test senaryolarımızı bu kriterlerden türetiyoruz; kriter yoksa ürünün mevcut davranışını değil, kullanıcının makul beklentisini esas alıyoruz.
Kapsam matrisi, testte koşulan her senaryoyu bir hücre olarak gösterir; işaretli hücreler bulgu çıkan senaryolardır.
Tek bir bakışta iki soruyu yanıtlar: kaç senaryo denendi ve bulgular nerede yoğunlaştı. Bulguların bir bölgede kümelenmesi genellikle o modülün tekil bir hatası değil, yapısal bir sorunu olduğunun işaretidir. Her raporun başında bu matris yer alır.
Kara kutu testi, ürünü kaynak koduna bakmadan, yalnızca dışarıdan görünen davranışı üzerinden test etmektir.
Testi yapan kişi, ürünü kullanıcının gördüğü kadarıyla görür. Bunun avantajı, kodun nasıl yazıldığına dair varsayımların testi yönlendirmemesidir; kullanıcı da o varsayımlara sahip değildir. Fonksiyonel, uyumluluk ve kullanılabilirlik testlerini kara kutu olarak yürütüyoruz. Performans darboğazı analizi ve güvenlik denetiminde koda erişim sonucu iyileştirir ama zorunlu değildir.
Kararsız test, aynı kod üzerinde bazen geçen bazen kalan testtir; sonucu ürünün davranışını değil, test ortamının rastgeleliğini yansıtır.
En yaygın nedenleri, sabit bekleme süreleri, testler arasında paylaşılan veri ve zamana bağlı varsayımlardır. Kararsız testler zamanla güveni yok eder: ekip kırmızıyı görmeye alışır ve gerçek bir kırılmayı da görmezden gelir. Otomasyon yazdığımızda kararsızlık, düzeltilene kadar açık bir bulgu olarak takip edilir.
Keşif testi, önceden yazılmış senaryo listesi olmadan, testerin ürünü kullanırken fark ettiği şeylerin peşinden gittiği zaman sınırlı bir oturumdur.
Senaryo testi bilinen riskleri kapsar; keşif testi kimsenin aklına gelmemiş olanı bulur. Oturum başı süre ve odak baştan belirlenir, sonunda ne denendiği yazılır — yani "rastgele tıklamak" değildir. Bulguların önemli bir kısmı bu oturumlardan çıkar.
Lokalizasyon testi, çevirinin doğru olmasının yetmediği yerleri arar: kırpılan metin, o ülkede yanlış okunan biçimler ve yerele oturmayan akışlar.
Çeviri kusursuz olabilir ve ürün yine de yanlış görünebilir. Almanca bir etiket düğmeyi taşırır, virgülle ayrılan kuruş İngilizce arayüzde binlik ayracı sanılır, sağdan sola bir dilde ikonlar aynalanmadan kalır, o ülkede kimsenin kullanmadığı bir ödeme yöntemi tek seçenek olarak durur. Bunları görmek için hedef ülkede, o dili ana dili olarak konuşan birinin ekrana bakması gerekir.
OWASP Top 10, web uygulamalarında en yaygın ve en yüksek etkili on güvenlik zafiyeti kategorisini listeleyen, düzenli olarak güncellenen açık bir referanstır.
Bozuk erişim kontrolü, kriptografik hatalar, enjeksiyon, güvensiz tasarım ve hatalı yapılandırma gibi başlıkları kapsar. Güvenlik denetimimizin temel çerçevesidir. Bir sızma testinin yerini tutmaz; sertifikasyon gerektiren durumlarda bunu baştan söylüyoruz.
Ödeme akışı testi, bir siparişin parasının tam olarak bir kez, doğru tutarda ve doğru kayıtla hareket ettiğini gerçek kartla doğrular.
Sandbox mutlu yolu doğru gösterir; sorunlar para gerçekten hareket ettiğinde çıkar. Çift gönderim iki tahsilat üretebilir, 3D Secure ekranından geri dönmek siparişi ödenmiş gösterip tahsilatı hiç yapmayabilir, kısmi iade faturaya yansımayabilir. Test bunları gerçek kart ve gerçek banka yanıtlarıyla, sağlayıcı panelinden karşılaştırarak arar.
Öncelik, bir bulgunun ne zaman düzeltilmesi gerektiğini söyler; önem derecesi ise ne kadar zarar verdiğini söyler. İkisi aynı şey değildir.
Düşük önem dereceli bir yazım hatası, ana sayfanın ortasında duruyorsa yüksek öncelikli olabilir. Yüksek önem dereceli bir çökme, yalnızca kimsenin kullanmadığı bir yönetim ekranında oluyorsa bekleyebilir. Biz önem derecesini veriyoruz; önceliği ürün sahibi belirler.
Önem derecesi, bir bulgunun kullanıcı ve iş üzerindeki etkisini gösteren sıralamadır; bizde dört seviyeden oluşur: kritik, yüksek, orta ve düşük.
Kritik, veri kaybı ya da iş akışının tamamen durması demektir. Yüksek, kullanıcının işi bir yol bulmadan tamamlayamaması. Orta, işin tamamlanabildiği ama yanlış ya da zahmetli olduğu durumlar. Düşük, tutarsızlık ve cila. Seviye etki ve olasılığın birlikte değerlendirilmesiyle verilir, tek başına "ne kadar bozuk göründüğüyle" değil.
Regresyon testi, yeni bir değişikliğin daha önce çalışan bir davranışı bozup bozmadığını, her sürümde aynı senaryo paketini koşarak kontrol eder.
Değer, tekrarında ve paketin bakımında yatar: değişmeyen bir paket zamanla ürünün gerçek hâlini test etmeyi bırakır. Paketi her sürümde gözden geçiriyor, kapanan bulguları kalıcı senaryoya çeviriyoruz. Sonuçlar sürümden sürüme karşılaştırılabilir olarak raporlanır.
Smoke test, bir sürümün daha ayrıntılı teste değip değmeyeceğini anlamak için koşulan, kısa ve yüzeysel bir kontrol setidir.
Uygulama açılıyor mu, giriş yapılabiliyor mu, ana akış baştan sona yürüyor mu — birkaç dakika sürer. Amacı hata bulmak değil, temel bir şeyin kırık olduğu bir sürümde saatlerce test yapmayı önlemektir. Her test turuna bununla başlıyoruz.
Stres testi, sistemi kapasitesinin ötesine iterek nerede ve nasıl çöktüğünü, yükün geçmesinden sonra kendini toparlayıp toparlamadığını ölçer.
Yük testinden farkı amacıdır: yük testi normal günü ölçer, stres testi sınırı arar. Kritik olan ikinci kısımdır — yük düştükten sonra sistemin kendiliğinden normale dönmesi. Dönmüyorsa, yoğunluk biten bir kampanya bile hizmeti saatlerce kapalı bırakabilir.
Test ortamı, canlı sistemden ayrı çalışan ama onunla aynı şekilde yapılandırılmış bir kopyadır; testler burada gerçek veriye ve gerçek kullanıcıya dokunmadan yürütülür.
Test ortamı olmadan da çalışırız, ancak veri oluşturan senaryoları kapsam dışında bırakmak zorunda kalırız — bu da kapsamı ciddi şekilde daraltır. Ortamın canlıdan farklı yapılandırılması, canlıda çıkan ama testte çıkmayan bulguların en yaygın nedenidir.
Uçtan uca test, bir işi kullanıcının başladığı yerden bitirdiği yere kadar, aradaki tüm sistemlerden geçerek dener.
Parçalar tek tek çalışırken birleşimlerinin çalışmaması yaygındır: ödeme sağlayıcısı doğru yanıt verir, sipariş servisi doğru kaydeder, ama ikisi arasındaki zaman aşımı sepeti boşaltır. Uçtan uca test bu boşlukları hedefler. Bizim senaryolarımızın çoğu bu türdendir.
Uyumluluk matrisi, bir ürünün hangi cihaz, işletim sistemi ve tarayıcı sürümlerinde test edildiğini ve her birinde ne sonuç verdiğini gösteren tablodur.
Matris iki şeyi aynı anda söyler: neyin test edildiği ve neyin test edilmediği. İkincisi çoğu raporda eksiktir. Emülatör tek başına yeterli değildir; dokunma hedefi, klavye davranışı, bellek sınırı ve ağ değişimi gerçek cihazda başka türlü davranır.
WCAG 2.2 AA, web içeriğinin engelli kullanıcılar için erişilebilir olmasını tanımlayan uluslararası standardın yaygın olarak talep edilen uyum seviyesidir.
Renk kontrastı, klavyeyle tam kullanım, odak görünürlüğü, form etiketleri, hata bildirimi ve ekran okuyucu uyumluluğu gibi ölçütleri kapsar. Otomatik tarama ihlallerin yaklaşık üçte birini yakalar; kalanı gerçek ekran okuyucu oturumu gerektirir. Denetimimiz ikisini birlikte yürütür.
Yük testi, beklenen kullanıcı yoğunluğu altında sistemin yanıt süresinin ve hata oranının nasıl değiştiğini ölçer.
Amacı sistemi kırmak değil, normal ve yoğun günün nasıl göründüğünü sayıyla göstermektir. Çıktı genellikle bir eşiktir: "400 eşzamanlı kullanıcıya kadar yanıt süresi 800 ms altında kalıyor, sonrasında veritabanı bağlantı havuzu doluyor."
Panelden kayıt olun, test ettirmek istediğiniz kriterleri seçin, ödemeyi yapın. İlk bulgular birkaç saat içinde aynı panele düşmeye başlar.
SendTheCanary, web, mobil ve API ürünleri için bağımsız yazılım testi sunar. Fonksiyonel testten ödemeye ve lokalizasyona kadar on ayrı hizmeti 4.700 testerlık ağıyla yürütür, bulguları önem derecesine göre sıralanmış tek bir raporla teslim eder.
Hizmetler:Fonksiyonel testRegresyon testiUyumluluk matrisiPerformans ve yükGüvenlik denetimiAPI testiÖdeme testiErişilebilirlikKullanılabilirlik incelemesiLokalizasyon testi