Günümüzde, teknolojinin sürekli gelişmesiyle yazılım sektörü de kendi içinde yeni dallar oluşturmaya başladı.
Yazılım sektöründe rekabetin bu kadar yüksek olduğu bir ortamda şirketlerin ayakta kalabilmek için ürün kalitelerini koruyup memnuniyet oranlarını sürekli yüksek tutmaları gerekiyor. Ürün kalitesi olarak bahsettiğimiz konu, ürünün hatadan arındırılmış olması olarak karşımıza çıkıyor.
Bu aşamada yazılım test mühendislerine büyük işler düşüyor. Bir şirketin ürünü güncel ve kaliteli tutabilmesi onu sürekli profesyonel bir şekilde test etmesinden geçiyor.
Yazılım testi, bir yazılımın çalışma alanından, sınırlı sayıda ve uygun şekilde seçilmiş testler ile belirlenmiş gereksinimleri karşıladığının doğrulanması veya beklenen ile gözlenen sonuçlar arasındaki farkların belirlenmesini amaçlar.
????Yazılım süreçlerinde “test” nedir?
Test, proje geliştirme sırasında projenin başarılı bir şekilde tamamlanması için oldukça önemlidir. Yazılım geliştiricilere ayrılan birim test süresi genellikle yeterli olmamaktadır.
Yazılım test süreci aşamaları aşağıdaki gibidir:
1- Testin planlanması
2- Test tasarımı yapılması
3- Testin gerçekleştirilmesi
4- Hata raporlama yapılması
5- Test sonuç raporları oluşturulması ve paylaşılması
Test süreçleri mantıksal olarak ardışıkdır ancak belirli bir projede çakışması durumunda eş zamanlı olarak gerçekleşebilir ve tekrarlanabilir.
????Testin 7 Prensibi
Testler, hataların varlığını gösterir: Testler hataların bulunduğunu gösterebilir fakat hatanın olmadığını ispatlayamaz.
%100 test mümkün değildir: Her şeyi tamamen test etmek imkansızdır.
Erken test etmek gerekir: Yazılım geliştirme yaşam döngüsünün başlangıcında test etmek, maliyeti azaltacaktır.
Arıza kümülenmesi: Yazılımda hatalar birbirine yakın bölgelerde yoğunlaşır. Hataların %80’i, tüm yazılımın %20’sini kapsar.
Pesticide pradoksu: (Antibiyotik direnci) Test senaryolarının belirli aralıklarla güncellenmesi ve revize edilmesi gerekmektedir.
Test içeriğe göre değişir: Test farklı bağlamlarda farklı yapılabilir.
Hatasızlık algısı: Testte tespit edilen hataların düzeltilmiş olması kullanıcının ihtiyaçlarını tam karşılıyor olduğu anlamını taşımamaktadır.
????Test Driven Development Nedir?
Test Driven Development (TDD), kodun ne yapacağını belirlemek ve doğrulamak için test senaryolarının geliştirildiği bir yazılım geliştirme yaklaşımıdır.
TDD yaklaşımının avantajları arasında daha hızlı geri bildirim, yüksek kabul oranı, daha düşük proje kapsamı ve gereğinden fazla mühendislik, müşteri odaklı ve yinelenen süreçler, modüler, esnek ve sürdürülebilir kodlar yer alır.
Test odaklı geliştirme, kodlama, test ve tasarımın birlikte çalıştığı bir programlama tarzını ifade eder.
Basit bir ifadeyle, önce her işlev için test senaryoları oluşturulur ve test edilir. Bu aşamada test başarısız olursa, testi geçmek ve kodu basit ve hatasız hale getirmek için yeniden kod yazılır.
????Test Driven Development Testi Nasıl Yapılır?
Test driven development sadece birkaç adımdan oluşmaktadır:
1. Bir test yazılır.
2.Tüm testleri çalıştırın ve yeni bir testin başarısız olup olmadığına bakın.
3. Test başarılı hale getirilir.
4. Mevcut bütün testlerin başarılı olması sağlanır.
5. Refactor kodunu çalıştırın.
????TDD vs Geleneksel Test
Test driven development yaklaşımı, kaynak kodunuzun doğrulayıcı düzeyde test edilmesini sağlar. Geleneksel testlerde ise başarılı bir test, bir veya daha fazla kusur bulur.
Test driven development, sisteminizin kendisi için tanımlanan gereksinimleri karşılamasını sağlayarak sisteminiz hakkında güveninizi geliştirmenize yardımcı olur.
Geleneksel testler, test senaryosu tasarımına daha fazla odaklanılır.
TDD’de geleneksel testlerden farklı olarak her kod satırı test edilme sürecinden geçer.
Hem geleneksel test hem de TDD, sistemin test edilmesinin önemine yol açar.
????TDD Avantajları
TDD, programcının “belki ilerde kullanılır, bu metodu eklemekte fayda var” düşünce tarzını engeller. Bu sayede TDD, proje maliyetini düşürür.
TDD ile test kapsama alanı oldukça geniştir.
Testler koda olan güveni artırır.
Testler sistemin nasıl çalıştığını gösteren dokümantasyon olarak düşünülebilir.
Design first mentalitesi kazandırır ve over-engineeringten kaçınmamızı sağlar.
????TDD ile Geliştirme Yaparken Dikkat Edilmesi Gerekenler
Test kodlarımız normal kodlar gibi ele alınmalı gelişime açık kodlar tasarlanmalıdır.
Testler yazılırken negatif caseler’e de önem verilmeli.
Testler bir işin nasıl yapıldığından çok ne yapılmaya çalışıldığıyla ilgilenmelidir.
Testlerin çalışma sırası birbirini etkilememelidir.
????Görsel stil için TDD kullanmalı mısınız?
Görseller anlık görüntü sürecinizi geliştirebilir ancak TDD’nin yerini alamaz.
Bunun yerine, görsel regresyon ve anlık görüntü araçları görsel stili test etmenize yardımcı olabilir. Görsel tasarımlar sıklıkla değişme eğilimindedir ve genellikle nesnel olmaktan çok özneldir. Bir şeyin nasıl görünmesi gerektiğine ve bu görünümün biçimlendirme ve stillerle nasıl elde edilebileceğine dair bilimsel bir tahmin bulmak zordur.
????Kodumuzu yeniden düzenlediğimizde, birçok test başarısız olmaya başlayacaktır. Testleri yeniden düzenlemeli miyiz yoksa yenilerini mi yazmalıyız?
Aklınıza bu soru geliyorsa, refactor kötüye kullanılıyor demektir.
Refactor, “herhangi bir kod değişikliği” anlamına gelmez. Bunun yerine, yeniden düzenleme, test edilen birimin iç yapısını, dış davranışını değiştirmeden değiştirdiğimiz anlamına gelir.
Test edilen birimi yeniden yapılandırdığınızda testler başarısız olmamalıdır. Birim testleri, yalnızca birimin davranış gereksinimleri değiştiğinde kırılmalıdır.
Test etmeniz gereken tüm geçerli gereksinimleri not alın ve ardından ihtiyacınız olmayan testleri bir kenara bırakın.
????Agile Model Driven Development (AMDD) aracılığıyla TDD ölçeklendirme
AMDD yaşam döngüsü
Yineleme 0: Düşünme Aşaması
İki ana alt aktivasyon vardır.
Öngörülen ilk gereksinimler: Ana odak noktası, kullanım modelini, ilk etki alanı modelini ve kullanıcı arabirimi modelini (UI) keşfetmektir.
İlk Mimari tasavvur: Ana odak noktası, teknoloji diyagramlarını, kullanıcı arayüzü (UI) akışını, etki alanı modellerini ve değişiklik durumlarını keşfetmektir.
Yineleme modellemesi: Burada ekip, her yineleme için yapılacak işi planlamalıdır.
Model fırtınası: Tam zamanında modelleme olarak da bilinir.
Test Güdümlü Geliştirme (TDD):
Uygulama kodunuzun doğrulayıcı testini ve ayrıntılı spesifikasyonu teşvik eder.
Hem kabul testi (ayrıntılı gereksinimler) hem de geliştirici testleri (birim testi) TDD için girdilerdir.
TDD, kodu daha basit ve anlaşılır hale getirir. Geliştiricinin daha az belge tutmasına izin verir.
Yorumlar:
Bu isteğe bağlıdır. Kod incelemelerini ve model incelemelerini içerir.
Bu, her bir yineleme için veya tüm proje için yapılabilir.
Bu, proje için geri bildirim vermek için iyi bir seçenektir.
AMDD, Model Odaklı Geliştirme’nin (MDD) çevik sürümüdür. MDD, kaynak kodu yazılmadan önce kapsamlı modellerin oluşturulduğu yazılım geliştirme yaklaşımıdır.
AMDD, TDD’nin yapmadığı Çevik ölçeklendirme sorunlarını ele alır.
Geliştirme sırasında, modelinizi uygulamak için belirli bir süre boyunca Test-First Design (TFD) ve refactoring gibi yaygın Agile metodlarını uygulamak oldukça yaygındır. TDD ile tipik olarak bir seferde tek bir varlıkla ilgili çok odaklı konular üzerinde düşünürken yeniden düzenleme ile, çalışmalarınızın yüksek kalitede kalmasını sağlamak için tasarımınızı küçük adımlarla geliştirirsiniz.
TDD, uygulama kodunuzun doğrulama testini ve bu kodun ayrıntılı özelliklerini destekler. Agile kabul testleri olarak da adlandırılan müşteri testleri, ayrıntılı gereksinimlerin bir biçimi olarak düşünülebilir. AMDD’yi dikkate almak için TDD’nin ötesine geçmemiz gerekiyor.
