İş değeri ölçülerek ve deneysel yönetim kullanılarak iş sonuçları sürekli nasıl iyileştirilir.

GENEL BAKIŞ

Çevik ürün teslim etme pratiklerini benimseyen organizasyonlar, aktiviteleri ve iş sonuçları yerine çıktıları iyileştirerek gerçek hedefleri olan teslim edilen değeri iyileştirmeyi kolayca gözden kaybedebilirler.

Çeviklik bir amaç için araçtır, kendisi bir amaç değildir; çevik pratikleri benimsenin amacı iş performansını iyileştirmektir. Organizasyonlar bu bakış açısını kaybettiklerinde yöneticiler mantıklı gibi görünen fakat istenmeyen sonuçlara neden olan sorular sorabilirler. Böyle sorulara örnekler…

Kanıta Dayalı Yönetim Kılavuzu’nu indirebileceğiniz bağlantı:

Kanıta Dayalı Yönetim Kılavuzu

1 file(s) 988.12 KB

Download

Test Odaklı Geliştirme şu anda sektördeki pek çok moda sözcükten yalnızca biri. Bu yüzden insanların bu konuda kafalarının karışık olması son derece normal.

• Test Odaklı Geliştirme (TDD → Test Driven Development)
• Davranış Odaklı Geliştirme (BDD → Behavior Driven Development)
• Kabul Testi Odaklı Geliştirme (ATTD → Acceptance Test Driven Development) 
• DevOps
• DevSecOps
• Sürekli Test
• Model Tabanlı Test

Liste böyle uzayıp gidiyor.

Ancak hata yapmayın. Tüm bu uygulamalar ve metodolojiler aslında tek bir soruya cevap arar. “Daha iyi” bir yazılımı nasıl geliştirebiliriz?

Bu yazımda, Test Odaklı Geliştirme, Davranış Odaklı Geliştirme ve Kabul Testi Odaklı Geliştirme ile ilgili kafanızdaki tüm soru işaretlerini gidermeye çalışacağım. Nedir? Nasıl çalışır? Ayrıca geliştirme/test süreci üzerindeki etkileri nelerdir?

Test Odaklı Geliştirme (TOG): “Kod Doğru Mu?”

Test Odaklı Geliştirme, iç-dış perspektifine odaklanır; yani testleri geliştiricinin bakış açısından oluştururuz. “Bu kod doğru mu?” sorusu Test Odaklı Geliştirme’nin ardındaki ana sorudur.
Metodoloji özellikle “birim testlerine” odaklanır. Geliştirici bir gereksinimi alır ve onu belirli bir test case’ine dönüştürür. Daha sonra da geliştirici yalnızca bu belirli testleri geçebilecek kodu yazar. Bu pratikle gereksinimleri karşılamayan lüzumsuz güncellemeleri önlemek amaçlanmaktadır. Test Odaklı Geliştirme, geliştiricilerin kodu yazdıktan sonra Birim Testleri yazdıkları geleneksel programlamadan farklı olarak, geliştiricileri kodu yazmadan önce ürün gereksinimlerine odaklanmaları için zorlar.

TOG, Kent Beck’in, “Test Driven Development: By Example” kitabında bahsettiği gibi 6 adımdan oluşan basit bir işlemdir. Şimdi gelin, Spotify kataloğundan belirli bir albümü yayınlama örneğini hep birlikte inceleyelim.