Kısa cevap: yazılım testi ve kalite güvencesi, teslimattan önceki son aşama değildir — sisteminizin yayına alındıktan sonra size neye mal olacağını belirler. Bütçeleri aynı olan iki sistem tek bir noktada ayrışır: Sistem, hataları müşterinizden önce yakalayan bir test kapsamıyla mı inşa edildi, yoksa test paketi müşterinizin kendisi mi? İlkinde kalitenin bedelini geliştirme sırasında bir kez ödersiniz. İkincisinde ise her ay kesintiler, acil düzeltmeler ve aşınan güvenle ödersiniz.

QA, "teslimattan önce birinin etrafa tıklaması" değildir

İşletme sahipleri arasındaki yaygın algı, kalitenin projenin son haftasında bir kişinin ekranları açıp düğmelere basması anlamına geldiğidir. Bu, işin çok küçük — ve en az etkili — bir parçasıdır. Gerçek kalite güvencesi ilk günden itibaren işleyen bir sistemdir: test edilebilecek kadar net yazılmış gereksinimler, her değişiklikte çalışan otomatik testlerle kapsanmış kod, canlı ortamı yansıtan bir hazırlık (staging) ortamı ve hiçbir değişikliğin bu kapılardan geçmeden canlıya ulaşmasına izin vermeyen bir dağıtım yolu.

Pratik fark basittir: ilk düzende bir hata, yazıldıktan dakikalar sonra ortaya çıkar; ikincisinde ise müşteriniz onu bir ay sonra bulur ve o zamana kadar aynı hatanın üzerine başka özellikler inşa etmiş olursunuz.

Karar verici olarak sizin için önemli olan test katmanları

Teknik ayrıntıları bilmeniz beklenmez, ancak neye para ödediğinizi bilmeniz beklenir. Ciddi her teknik teklifin adını açıkça koyması gereken katmanlar şunlardır:

  • Birim testleri: en küçük mantık parçalarını yalıtılmış olarak doğrular. En hızlı ve en ucuz testlerdir; küçük bir değişikliğin bir fatura toplamını, bir indirimi veya bir vergi hesaplamasını bozmasını engelleyen de onlardır.
  • Entegrasyon testleri: parçaların birbirleriyle ve harici sistemlerle — ödeme altyapısı, kargo, faturalama platformları, mesajlaşma — doğru şekilde iletişim kurduğunu doğrular. Gerçek dünyadaki arızaların çoğu kodun içinde değil, burada yaşanır.
  • Uçtan uca testler: sayfanın açılmasından siparişin onaylanmasına ve bildirimin alınmasına kadar, baştan sona eksiksiz bir kullanıcı yolculuğunu simüle eder.
  • Performans ve yük testleri: başka hiçbir testin yanıtlamadığı bir soruyu yanıtlar — aynı dakikada on yerine bin kullanıcı geldiğinde ne olur? Ekiplerin atladığı katman budur ve sonra sistem en büyük kampanyanızın olduğu gün çöker.
  • Güvenlik testleri: yaygın güvenlik açıklarını başkası bulmadan önce taramak. Pratik referans, kritik web uygulaması risklerini listeleyen OWASP Top 10 listesidir; bir test planında adının geçtiğini görmek açık bir olgunluk işaretidir.
  • Kullanıcı kabul testi: siz ve ekibiniz sistemi, geliştiricinin hazırladığı ideal bir senaryoya göre değil, gerçek iş senaryolarınıza göre çalıştırırsınız. Bu aşama sizin sorumluluğunuzdadır ve ondan önce hiçbir onay verilmemelidir.

Bir hata neden ne kadar geç bulunursa o kadar pahalıya mal olur

Bir yazılım projesi yönetmiş herkes kuralı bilir: gereksinimler yazılırken yakalanan bir hata, bir cümle düzeltilerek giderilir. Aynı hata yayına alındıktan sonra yakalanırsa teşhis, düzeltme, yeniden test ve yeniden dağıtım gerektirir — çoğu zaman buna yol boyunca bozulan verilerin onarımı ve etkilenen müşterilerden özür dilemek de eklenir. Sorun şu ki bu fark hiçbir teklifte görünmez; bu yüzden testi kapsamdan çıkaran tedarikçi daha ucuz görünür. Gerçekte ise faturayı yalnızca ertelemiş ve büyütmüştür.

Otomatik ve manuel test: hangisi ne zaman

Manuel test; kullanıcı deneyimini, uç durumları ve insan muhakemesi gerektiren her şeyi değerlendirmek için vazgeçilmezdir. Ancak kalıcı bir güvenlik ağı olarak işlev göremez, çünkü kimse her küçük değişiklikten sonra iki yüz ekranı elle yeniden kontrol etmeyecektir. Sürekli geliştirmeyi mümkün kılan otomatik testtir: testi bir kez yazarsınız, binlerce kez çalışır ve bugünkü değişikliğin ekibinizin bir yıl önce inşa ettiği bir şeyi bozup bozmadığını dakikalar içinde size söyler. Pratik kural: paraya veya veriye dokunan tekrarlı her şeyi otomatikleştirin; ürünün nasıl hissettirdiğine dokunan her şeyi ise insan muhakemesine bırakın.

Test verilerinize dikkat edin

Birçok ekibin gözünden incelenmeden kaçan bir konu var: geliştiriciler onunla test yapabilsin diye canlı veritabanını hazırlık ortamına kopyalamak. Bu, müşterilerinizin adlarının, telefon numaralarının ve adreslerinin artık daha geniş erişimli ve daha zayıf korunan bir ortamda durduğu anlamına gelir. Suudi Veri ve Yapay Zekâ Otoritesi (SDAIA) tarafından denetlenen Suudi Arabistan Kişisel Verilerin Korunması Kanunu, onları barındıran ortama ne ad verirseniz verin kişisel verilerin işlenmesini düzenler. Çözüm basit ve bilinir: sentetik olarak üretilmiş veriler veya kopyalanmadan önce hassas alanları maskelenmiş gerçek veriler.

İmzalamadan önce tedarikçinizden neler istemelisiniz

  • "Sistem test edilecek" şeklinde sözlü bir vaat değil, iş kapsamının içinde yazılı bir test planı.
  • Bir test başarısız olduğunda dağıtımın engellendiği, sürekli entegrasyon hattı üzerinden her değişiklikte otomatik olarak çalışan testler.
  • Müşteriye açık ortamdan ayrı, verilerinin nereden geldiği açıkça belirtilmiş bir hazırlık ortamı.
  • Hem yüzde hem de yön olarak okunan periyodik bir kapsam raporu: sistem büyüdükçe kapsam artıyor mu, yoksa düşüyor mu?
  • Neyin ücretsiz düzeltilecek bir hata, neyin yeni bir geliştirme talebi sayılacağını tanımlayan, yayın sonrası bir garanti süresi.

Projenizde kalitenin ihmal edildiğinin işaretleri

Bunları fark etmek için teknik bir geçmişe ihtiyacınız yok: her düzeltme başka bir şeyi bozar, her dağıtımdan önce ekipte gözle görülür bir gerginlik olur, kimse eski bir modüle "çalışıyor ve neyi etkileyeceğini bilmiyoruz" diye dokunmaya cesaret edemez ve kesintileri izleme sisteminiz değil müşterileriniz bildirir. Bunlar ayrı sorunlar değildir — ekibin değişiklikleri güvenle yapmasını sağlayacak bir test ağının eksikliğinin belirtileridir.

Origami'de test kapsamını bir destek kalemi olarak değil, ürünün bir parçası olarak ele alıyoruz: iki yıl sonra güvenle değiştirilemeyen bir sistem, teslim gününde ne kadar iyi görünmüş olursa olsun başarılı bir sistem değildir.

Kaynaklar