Bir hata üretime ulaştığında bunun nedeni genellikle birisinin test yapmayı unutması değildir. Bu, bir gerekliliğin hiçbir zaman sorgulanmadığı, test verilerinin yanlış olduğu veya hiç kimsenin “yapılan”ın ne anlama geldiği konusunda fikir birliğine varmadığı bir durumdur. Yazılım testi yaşam döngüsü, testlere ilk gereksinimden nihai rapora kadar net bir yapı vererek bu sorunları giderir.

Bu kılavuz her aşamayı açıklıyor ve ardından tüm aşamaların açıklayıcı bir özelliğini takip ediyor: Beş başarısız denemeden sonra hesabı kilitleyen bir oturum açma sayfası. Kaynaklar aşamaların sayısı konusunda tam olarak hemfikir değil. Yedili, sekizli modeller göreceksiniz ama çoğunlukla aynı işi farklı şekilde bölüyorlar. Yaygın olarak öğretilen altı aşamalı versiyonu kullanıyoruz.

STLC nedir?

STLC, yazılımın gereksinimlerini karşıladığını doğrulamak için gerçekleştirilen tanımlanmış bir dizi test faaliyetidir. Her aşamanın bir hedefi, girdileri ve çıktıları vardır; böylece test, sonunda doğaçlama yapmak yerine planlanır ve izlenebilir.

Faydaları pratiktir. Kusurların düzeltilmesi daha ucuz olduğunda, test uzmanları erken müdahale eder. Çaba en yüksek risklere gider. Ve bir yönetici “serbest bırakmaya hazır mıyız?” diye sorduğunda ekip kanıtlarla cevap verebilir.

Bir bakışta altı STLC aşaması

Giriş kriterleri, bir aşama başlamadan önce doğru olması gereken koşullardır. Çıkış kriterleri sona ermeden önce doğru olması gereken koşullardır. Örneğin, bir ekibin bozuk bir yapı üzerinde testler yapmasını ve gününü boşa harcamasını engellerler.

Aşama 1: Gereksinim analizi

Test uzmanları neyin test edilebileceğini ve neyin belirsiz olduğunu öğrenmek için gereksinimleri inceler. Bir sorunun üretim düzeltmesinden çok daha az maliyetli olması nedeniyle burası genellikle bir hatayı önlemek için en ucuz yerdir.

• Giriş: gereksinim belgeleri veya kullanıcı hikayeleri mevcuttur.
• Faaliyetler: işlevsel ve işlevsel olmayan ihtiyaçları belirleyin, sorular sorun, riski değerlendirin ve nelerin otomatikleştirilebileceğine karar verin.
• Çıkış: açık sorular yanıtlanır ve gereksinim izlenebilirlik matrisi (RTM) başlatılır.
• Teslim edilecekler: test edilebilir gereksinimlerin bir listesi ve RTM.

Giriş örneği. Hikayede “beş başarısız denemeden sonra hesabı kilitle” yazıyor. İyi bir testçi şunu sorar: Hangi dönemde beş? Kilidi nasıl açılır? Başarılı bir giriş, sayımı sıfırlar mı? Hangi mesaj gösteriliyor? Her cevap test edilebilir bir şey haline gelir.

Aşama 2: Test planlaması

Ekip kapsam, yaklaşım, kişiler, araçlar, program ve risklere karar verir. Test lideri genellikle bu aşamanın sahibidir.

• Giriş: analiz edilen gereksinimler ve ilk risk değerlendirmesi.
• Faaliyetler: kapsamı tanımlayın, işgücünü tahmin edin, araçları seçin, rolleri atayın ve sonraki aşamalar için çıkış kriterlerini ayarlayın.
• Çıkış: test planı incelenir ve onaylanır.
• Sonuçlar: test planı ve çaba tahminleri.

Giriş örneği. Kapsam dahilinde: web ve mobil cihazlarda kilitleme kuralları, sıfırlama ve hata mesajları. Kapsam dışı: Tek oturum açma, başka bir ekip tarafından gerçekleştirilir. En büyük risk, gerçek kullanıcıları kilitlemektir, böylece en fazla dikkati çeker. Bir planın bir stratejiden ne kadar farklı olduğundan emin değilseniz, test planı ve test stratejisi konusunu okuyun.

Aşama 3: Test senaryosu geliştirme

Test uzmanlarının ayrıntılı test senaryolarını, otomasyon komut dosyalarını ve test verilerini yazdığı yer burasıdır.

• Giriş: onaylanmış bir test planı ve kararlı gereksinimler.
• Etkinlikler: test senaryoları yazın ve inceleyin, verileri hazırlayın, otomatik kontrollerin komut dosyalarını yazın ve RTM’yi güncelleyin.
• Çıkış: test senaryoları ve veriler incelenir ve hazır olur.
• Sonuçlar: test senaryoları, komut dosyaları ve test verileri.

TC-01 ve TC-02’nin, doğrudan sınır değer analizinden gelen sınırın her iki tarafını da test ettiğine dikkat edin. Bunları iyi yazma konusunda daha fazla bilgi için test senaryolarının nasıl yazılacağına bakın.

Aşama 4: Test ortamı kurulumu

Testlerin gerçekleştirilebilmesi için gerçekçi bir yere ihtiyaç vardır: doğru sunucular, veriler, hesaplar, tarayıcılar ve ağ erişimi. Bu aşama genellikle aşama 3 ile paralel olarak yürütülür ve geliştiriciler veya DevOps ekibi tarafından yönetilebilir.

• Giriş: bir test planı, mimariye genel bakış ve ortam gereksinimleri.
• Etkinlikler: donanım veya kapsayıcıları kurun, verileri yükleyin, erişimi yapılandırın ve yapıyı yükleyin.
• Çıkış: ortam hazırdır ve duman testi geçilmiştir.
• Sonuçlar: bir çalışma ortamı ve duman testi sonucu.

Giriş örneği. Aşamalandırma, bilinen durumlardaki test hesaplarını kısaltılmış bir kilitleme zamanlayıcısıyla birlikte alır, böylece test kullanıcılarının beklemek zorunda kalmaz. Hızlı bir duman testi, oturum açma işleminin tam çalıştırma başlamadan önce yüklendiğini doğrular. Konteynerler, Docker Compose eğitimimizde gösterildiği gibi ortamların tutarlı kalmasına yardımcı olur.

Aşama 5: Testin yürütülmesi

Test uzmanları planlanan testleri yürütür, gerçek ve beklenen sonuçları karşılaştırır ve kusurları bildirir. Düzeltilen hatalar yeniden test edilir ve ilgili alanlara regresyon testi uygulanır.

• Giriş: test senaryoları hazır, ortam çalışıyor ve bir yapı teslim edildi.
• Etkinlikler: testleri çalıştırın, sonuçları kaydedin, hataları günlüğe kaydedin, düzeltmeleri yeniden test edin ve RTM’yi güncelleyin.
• Çıkış: planlı testler gerçekleştirilir ve kusurlar düzeltilir veya resmi olarak kabul edilir.
• Sonuçlar: test sonuçları ve kusur raporları.

Giriş örneği. TC-04 başarısız oluyor: iki tarayıcıyla sayaç yalnızca dörde ulaşıyor. Testi gerçekleştiren kişi, hata raporu nasıl yazılır bölümünde açıklandığı gibi, açık adımlarla ve kanıtlarla hatayı günlüğe kaydeder. Düzeltildikten sonra TC-04 yeniden çalıştırılır ve ilgili giriş kontrolleri regresyon kontrol listesinden geçer.

Aşama 6: Test kapanışı

Bu aşama genellikle atlanır ve bu çok yazıktır, çünkü bir takım bu şekilde gelişir. Ekip döngüyü değerlendirir, çalışmalarını arşivler ve öğrendiklerini kaydeder.

• Giriş: yürütme tamamlandı ve kusur durumu biliniyor.
• Etkinlikler: çıkış kriterlerini kontrol edin, kusur eğilimlerini analiz edin, test varlıklarını arşivleyin ve geriye dönük bir inceleme düzenleyin.
• Çıkış: kapatma raporu imzalanır.
• Sonuçlar: kapanış raporu ve öğrenilen dersler.

Giriş örneği. Rapor, beş vakanın tamamının tek bir düzeltmeden sonra geçtiğini gösteriyor. Çıkarılan ders, eşzamanlılığın yalnızca geç test edildiğidir, bu nedenle sayaçlarla birlikte gelecekteki özellikler, bu senaryonun tasarım sırasında eklenmesini sağlar.

STLC ve SDLC

SDLC veya yazılım geliştirme yaşam döngüsü, tüm ürünün oluşturulmasını kapsar. STLC, test etmeye odaklanan kısımdır ve onunla birlikte çalışır.

SDLC’deki gereksinim analizi, STLC’deki gereksinim analizini besler ve geliştirme, derlemelerin test yürütmesine sunulmasını sağlar. Testin kodlama bitene kadar beklemesine gerek yoktur. İnsanların “sola kaydırma” derken kastettiği erken başlamaktır.

Çevik ve DevOps’ta STLC

Aşamalar uzun, tek yönlü bir süreç gibi görünebilir ancak öyle olmak zorunda değildir. Agile’da aynı aktiviteler her sprintte küçülür ve tekrarlanır, genellikle haftalar yerine saatler içinde:

• Gereksinim analizi, kullanıcı hikayesine ilişkin sorular aracılığıyla birikmiş işlerin ayrıntılandırılmasında gerçekleşir.
• Planlama, uzun belgeler yerine hafif notlar kullanılarak sprint planlamada gerçekleşir.
• Test tasarımı genellikle kabul kriterleri ve otomatik testler olarak kodlamanın yanında gerçekleşir.
• Ortam kurulumu, kod olarak kapsayıcılar ve altyapı aracılığıyla otomatikleştirilir.
• Yürütme, bir CI/CD hattında sürekli olarak çalışır.
• Kapanış, sprint incelemesinin ve geriye dönük değerlendirmenin bir parçası haline gelir.

Yararlı olanı saklayın ve evrak işlerini riske göre ölçeklendirin. Küçük bir dahili araç kısa bir kontrol listesine ihtiyaç duyabilirken, bir bankacılık sistemi düzenleyici nedenlerden dolayı resmi onaylara ihtiyaç duyabilir.

Yaygın hatalar

• Test kullanıcılarının geç getirilmesi. Gereksinimlerde bulunan hatalar, sürümden sonra bulunanlardan çok daha ucuzdur.
• Belirsiz çıkış kriterleri. Bunlar olmadan, son tarihler sizin yerinize karar verir.
• Kötü bir ortamda test yapmak. Kötü veri veya yapılandırmanın neden olduğu hatalar zaman kaybına neden olur ve güveni zedeler.
• Kapanışın atlanması. Ekip daha sonra bir sonraki döngüde aynı hataları tekrarlar.
• Çok katı bir şekilde takip ediyorum. STLC bir rehberdir. Ağır belgeler otomatik olarak daha iyi kalite anlamına gelmez.

Son sözler

Yazılım testi yaşam döngüsü altı soruya verilen disiplinli bir cevaptır: Neyi, nasıl, hangi durumlarda, nerede, ne oldu ve ne öğrendik? Bir sonraki özelliğinize bakın ve ekibinizin bu sorulardan hangilerini genellikle atladığını kontrol edin. Bu boşluğu düzeltmek muhtemelen size en büyük kazancı sağlayacaktır.

Sık sorulan sorular

Öğrenmeye devam et