Çevik Test (Agile Testing)

Çevik Yazılım Geliştirme Metodolojilerinin bir parçası olarak Test nerede konumlanmalı? Bu konudaki uzman görüşü nedir? Çevik metodlar ile yazılı test süreçlerimizi nasıl iyileştirebiliriz?

Embed

  1. Çevik Yaklaşım ! 

    İhtiyaçlar üzerine gelişen bir yönetim tekniği

    Yazılım Geliştirme yaklaşımı olarak belirlenen Çevik Süreçler (Agile) günümüzde bir yönetim prensibi olarak kabul görmüş durumda. 

    Uzmanlar, Yazılım Geliştirme Yaşam Döngüsünün tüm süreçlerini ayrı ayrı çevik olarak tanımlıyorlar. 

    Uluslararası PMI (Project Management Institute) örgütü Proje Yönetim disiplininde çevik yaklaşımın bir ihtiyaç olduğunu kabul edip, 2011 in ilk aylarında Çevik Proje Yönetim sertifikasyonunun duyurusunu yaptı. 

    Çevik süreçlerin geliştirilmesinin altında yatan felsefe en kolay olarak, "Agile Manifesto" ile ifade edilebilir. 
  2. Sexier Skunkworks- Cyborg Management 101
    Sexier Skunkworks- Cyborg Management 101
  3. Geleneksel yazılım geliştirme süreçlerinin parçası olarak Yazılım Test Ekibi nelerden sorumludur?  

    * Üründeki hataların tespit edilmesi, 
    * Sistemin gereksinimlere uygun olduğunun ispatlanması,
    * Test edilen sistemin limitlerinin keşfedilmesi.

    Bu modelde bir test mühendisinin başına gelebilecek en kötü şey, test edilen sistemin gereksinimlere tamamen uygun olması ancak gereksinimlerin doğru toplanmamış olmasından ötürü kullanıcının istediğinden farklı bir sistem geliştirilmiş olmasıdır. Çünkü test profesyonellerinin bu tür uymazlıkları iş işten geçmeden tespit etmeleri neredeyse olanaksızdır. 

    Peki bunlardan farklı olarak çevik süreçlerle yönetilen bir yazılım projesinde test ekibi nasıl rol alabilir? 

    Geleneksel yaklaşımın tersine, test profesyonelleri, yazılım geliştirme yaşam döngüsünün en başından itibaren sürece dahil oluyorlar. Kullanıcının geliştirici (ve test sorumlusu) ile aynı ortamı paylaşması prensibi ise geliştirilen ürünün kullanıcının gerçekten istediği bir biçimde geliştirilmesi ve gerçekçi kullanım durumlarına göre test edilmesini sağlar. 

    Brett Pettichord çevik projelerde testin rolünü şu şekilde açıklamış:

    * Test projenin farlarıdır - Proje şu anda nerede, nereye ilerliyor? 
    * Test takıma bilgi sağlar - Takımın daha bilinçli kararlar almasını sağlar 
    * Hata (bug) kullanıcıyı rahatsız eden herhangi bir şeydir. 
    * Test kaliteyi garanti etmez - Tüm takım kaliteden sorumludur  
    * Test başkalarının açığını bulma oyunu değildir - Hatalar üzerine odaklanmaktansa hedefler belirlenmesini sağlamalıdır. 

    Çevik projelerde test profesyonellerini bekleyen en büyük engeller nelerdir? 

    * Alışılagelmiş iş gereksimleri ve fonksiyonel belirteç dokümanları yoktur. Sadece tek özelliğe odaklanan kullanıcı öykü kartları (story cards) vardır. Geri kalan özellikler kullanıcı ile birlikte çalışarak sözlü olarak yakalanır.   
    * Test yazılım geliştirme yaşam döngüsünün en başından itibaren başlar ve sürekli devam eder. Bu sebeple kod testler sürerken üretilmeye devam ediyor olacaktır.  
    * Kabul test senaryoları gereksinim analiz sürecinin bir parçası olacaktır, ve daha program yazılmaya başlamadan bu senaryoların yazılması beklenir.  
    * Her kod parçası kod havuzuna gönderildiğinde otomatik olarak birim testler yürütülür. Bir iterasyonun içinde birden fazla gerçekleştirilecek olan kod teslimatında regresyon testi gereksinimleri ciddi biçinde artacaktır.  
  4. Çevik test profesyonelleri, yazılım geliştiricilere hizmet verir. Kod modül bazında test edilebildiği ilk anda sık, seri ve sürekli testler yürüterek kaliteyi sağlar, kullanıcının isteğini gerçekçi kullanım durumları oluşturarak göz önünde bulundurur. 

    Çevik yazılım geliştirme yaklaşımında çalışır kod parçaları sık sık yayınlanır. Sık yayınlanan kodun testlerinin de sık yapılması gerekir. Bunun el ile yapılması çok büyük bir emek gerektirir ve hataya açıktır. Testlerin otomatik hale getirilmesi bu sebeple önemlidir. 
  5. Son yıllarda pek çok çevik geliştirme süreç modeli öne sürüldü. Adlarından en çok söz ettirenler XP, Lean, SCRUM, ... 

    Temelde bunların hepsi belli prensipler üzerine kurulu: 
    * İletişim
    * Cesaret
    * Basitlik
    * Geribildirim

    Lisa Crispin makalesinde XP Test metodolojisinden bahsetmiş. Lisa, XP Test metodolojisinin geleneksel test yaklaşımından farklarını anlatırken kalitenin sadece test ekibinin değil, tüm geliştirme ekibinin sorumluluğunda olduğuna dikkat çekmiş.  

    Makalede test ekibinin XP süreçleri dahilinde nasıl rol aldığı da anlatılmış. Test ekibinin görevleri arasında kullanıcı öykülerinin netleştirilmesi, gizli varsayımların ve risklerin bulunması, kabul testlerinin kullanıcıların istekleri doğrultusunda yazılması, testlerin mümkün olduğunca otomatize edilmesi listelenmiş. 

    Ne var ki Lisa, çevik tekniklerin anlatılması örgütler tarafından kabul edilmelerini ve kullanılmalarını sağladığından yakınmış. Bunun yerine takım ile birlikte varolan süreçte sorunların neler olduğu üzerinde konuşulması ve çevik süreçlerin hangi prensip ve pratiklerinin yardımcı olacağına karar verilmesinin daha anlamlı olacağını belirtmiş. 
  6. Lisa, makalesinin ikinci bölümünde çevik süreç kullanımına geçmek isteyen takımlara önerilmek üzere bazı çevik pratikleri açıklamış.  

    Ayrıca çevik test yaklaşımında otomasyonun önemi bir daha vurgulanmış ve bazı otomatik test araçları listelenmiş: 

  7. Lisa'nın makalesinin üçüncü ve son bölümü, testlerin yürütülmesi, risk yönetiminin uygulanması ve retrospektif pratiklerinden bahsetmiş. 

    Belki de bu makale dizisinden çıkarılması gereken en önemli sonuç testçiler ile geliştiricilerin ayrı takımlar olmadığı, ürün kalitesinden tam sorumlu tek bir ekip olarak görülmeleri gerektiğidir.
  8. Çevik Süreçler ile İlgili Diğer Kaynaklar
Like
Share

Share

Facebook
Google+