Yazılım Test Süreci ve QA: Ürün Sahipleri İçin Temel Bilgiler

Yazılım test süreci, bir yazılımın beklendiği gibi çalıştığını ve yapılan değişikliklerin mevcut özellikleri bozmadığını doğrulamak için yürütülen planlı kontroller bütünüdür. Sağlıklı bir süreçte otomatik testler (birim, entegrasyon ve uçtan uca testler) ile insan eliyle yapılan testler (keşif testleri ve kabul testi) birlikte kullanılır. Bu yazıda test türlerini ürün sahibinin bakış açısından açıklıyor, kabul testinde senin rolünü ve iyi bir hata raporunun nasıl yazılacağını anlatıyoruz.

Test neden yalnızca "son aşama" değildir?

Testi geliştirmenin sonuna bırakılan bir kontrol olarak düşünmek yaygın bir hatadır. Hatalar ne kadar geç bulunursa düzeltmesi o kadar pahalıya mal olur: Bir iş kuralındaki yanlış anlama gereksinim aşamasında bir konuşmayla düzelir, yayından sonra bulunduğunda ise veri düzeltme, kullanıcı iletişimi ve acil yayın gerektirebilir.

Bu nedenle kalite güvence (QA), projenin başından itibaren süren bir yaklaşımdır:

• Gereksinimler yazılırken test edilebilir kabul kriterleri tanımlanır,
• Geliştirme sırasında otomatik testler yazılır,
• Her iterasyon sonunda önizleme ortamında kontroller yapılır,
• Yayın öncesinde kabul testi ve son kontroller yürütülür,
• Yayından sonra hata izleme ile canlı ortam takip edilir.

Yazılım test sürecinde kullanılan test türleri

Birim testleri

Kodun en küçük parçalarını, örneğin bir indirim hesaplama fonksiyonunu, tek başına test eder. Hızlı çalışırlar ve iş kurallarındaki hataları erken yakalarlar. Ürün sahibi olarak bunları doğrudan görmezsin, ama karmaşık iş kurallarının birim testleriyle korunduğunu sormak yerinde bir sorudur.

Entegrasyon testleri

Birden fazla parçanın birlikte doğru çalıştığını kontrol eder: uygulamanın veritabanıyla, ödeme sağlayıcısıyla veya muhasebe sistemiyle doğru konuşması gibi. Dış sistemlere bağlı projelerde özellikle önemlidir.

Uçtan uca testler

Gerçek bir kullanıcı gibi tarayıcıyı otomatik olarak kullanarak ana akışları baştan sona dener: kayıt olma, giriş yapma, sipariş verme gibi. Yavaş ve bakımı daha zahmetli oldukları için genellikle yalnızca en kritik akışlar için yazılırlar.

Regresyon testleri

Yeni bir değişikliğin daha önce çalışan bir özelliği bozmadığını doğrular. Otomatik testlerin en büyük faydası buradadır: Her değişiklikte tüm kritik akışlar yeniden kontrol edilir.

Keşif testleri

Bir test uzmanının ya da geliştiricinin senaryoya bağlı kalmadan, uygulamayı zorlayarak hata araması. Beklenmedik girişler, yarıda bırakılan işlemler, geri tuşu, çift tıklama gibi durumlar burada ortaya çıkar.

Kabul testi (UAT)

Yazılımın iş ihtiyacını karşılayıp karşılamadığını, gerçek senaryolarla senin ve ekibinin doğrulamasıdır. Bu, projede senin doğrudan sorumlu olduğun test aşamasıdır.

Ne kadar test yeterlidir?

Her projede her şeyi otomatik test etmek ne mümkün ne de gereklidir. Yaygın ve pratik yaklaşım şöyledir:

• İş kuralları ve hesaplamalar için çok sayıda hızlı birim testi,
• Dış sistem bağlantıları için entegrasyon testleri,
• Para, veri kaybı veya erişim gibi kritik akışlar için az sayıda uçtan uca test,
• Arayüz ve kullanılabilirlik için insan eliyle yapılan kontroller.

Test kapsamını belirlerken şu soruyu sor: "Bu kısım bozulursa ne olur?" Cevap "müşteri yanlış ücretlendirilir" veya "veri kaybolur" ise o kısım güçlü bir şekilde test edilmelidir. Cevap "bir başlığın hizası kayar" ise insan gözüyle yapılan kontrol yeterli olabilir.

Test ortamları

Testlerin anlamlı olması için doğru ortamlarda yapılması gerekir. Tipik bir projede şu ortamlar bulunur:

• Yerel geliştirme ortamı: Geliştiricinin kendi bilgisayarı. Birim testleri burada sürekli çalışır.
• Önizleme ortamı: Her değişiklik veya iterasyon için oluşturulan, senin de erişebildiğin geçici bir bağlantı. Kabul testinin büyük kısmı burada yapılır.
• Hazırlık (staging) ortamı: Canlı ortamın ayarlarına mümkün olduğunca benzeyen, yayından önceki son kontrollerin yapıldığı ortam.
• Canlı ortam: Gerçek kullanıcıların kullandığı sistem.

Test ortamlarında gerçek kişisel verilerin kullanılmaması gerekir. Gerçekçi ama sahte ya da anonimleştirilmiş veriler, hem KVKK açısından daha güvenlidir hem de test senaryolarının tekrarlanabilir olmasını sağlar. Ödeme gibi dış servislerin de test modları kullanılmalı; test sırasında gerçek para hareketi oluşmamalıdır.

Kabul testinde senin rolün

Kabul testi, yazılımı en iyi bilen kişilerin, yani senin ve ekibinin katkısını gerektirir. Verimli bir kabul testi için:

1. Senaryoları önceden hazırla. Günlük işinde en sık yaptığın on işi listele ve her birini yazılımda dene.
2. Gerçekçi veri kullan. Uzun isimler, Türkçe karakterler, sıfır tutarlı siparişler, çok sayıda kayıt gibi gerçek hayattaki durumları dene.
3. Farklı rollerle dene. Her kullanıcı rolüyle giriş yapıp yalnızca görmesi gerekenleri gördüğünü kontrol et.
4. Farklı cihazlarda dene. Ekibinin gerçekten kullandığı telefon ve bilgisayarlarda test et.
5. Bulguları tek bir yerde topla. E-posta, mesajlaşma ve telefon arasında dağılan geri bildirimler kaybolur.

İyi bir hata raporu şablonu

Hata raporunun kalitesi, düzeltme süresini doğrudan etkiler. Aşağıdaki şablonu kullanabilirsin:

• Başlık: Kısa ve açıklayıcı. Örnek: "Stokta olmayan ürün sepete eklenebiliyor."
• Ortam: Hangi bağlantı (önizleme veya canlı), hangi tarayıcı ve cihaz.
• Kullanıcı rolü: Hangi hesapla giriş yapıldı.
• Adımlar: Hatayı yeniden oluşturmak için izlenen adımlar, numaralı olarak.
• Beklenen sonuç: Ne olmasını bekliyordun?
• Gerçekleşen sonuç: Ne oldu?
• Ekran görüntüsü veya kayıt: Mümkünse ekran kaydı.
• Önem derecesi: Engelleyici, önemli veya küçük.

"Çalışmıyor" gibi tek kelimelik bildirimler yerine bu yapıyı kullanmak, ekibin hatayı ilk denemede yeniden üretmesini sağlar.

Yayın sonrası kalite

Test süreci yayınla bitmez. Canlı ortamda:

• Hata izleme araçları, kullanıcıların karşılaştığı hataları otomatik olarak bildirir,
• Performans izleme, yavaşlayan sayfaları gösterir,
• Kullanıcı geri bildirim kanalı, test senaryolarının kaçırdığı durumları ortaya çıkarır.

Bulunan her önemli hata için bir regresyon testi eklemek, aynı hatanın tekrar etmesini önler.

Ayrıca test sürecinin kendisini de zaman zaman gözden geçirmek gerekir. Canlı ortamda bulunan hatalar hangi test türünün eksik olduğunu gösterir: Hesaplama hataları birim testlerinin, dış sistem kaynaklı sorunlar entegrasyon testlerinin, kullanıcıların takıldığı akışlar ise kabul testi senaryolarının güçlendirilmesi gerektiğine işaret eder.

Ürün sahibi olarak sorabileceğin sorular

Test süreci hakkında fikir edinmek için geliştirme ekibine şu soruları sorabilirsin:

• Hangi iş kuralları otomatik testlerle korunuyor?
• Her değişiklikte testler otomatik olarak çalışıyor mu?
• Kabul testi için hangi ortamı ve hangi test hesaplarını kullanacağız?
• Bulunan hatalar nerede takip edilecek ve bize nasıl raporlanacak?
• Yayından sonra hataları nasıl fark edeceğiz?

Bu sorulara verilen somut cevaplar, ekibin kaliteyi bir süreç olarak ele alıp almadığını gösterir.

Sonuç

Yazılım test süreci, hataları kullanıcılarından önce bulmanın sistemli yoludur. Otomatik testler kritik iş kurallarını ve akışları korur; kabul testi ise yazılımın gerçekten işine yarayıp yaramadığını doğrular. Weras Labs'te her iterasyon bir önizleme bağlantısıyla paylaşıldığı için kabul testini projenin sonuna değil, geliştirme boyunca dağıtıyoruz; sürecimizi hizmetler sayfamızda görebilirsin.