#table driven testing

Sadece yazılım testleri değil genel olarak tüm test süreçleri aslında birbiri ile entegre çalışması gereken (ya da beklenen) kapsamının tanımlanması, test planlarının oluşturulması, testlerin çalıştırılması, ortaya çıkan hataların raporlanması ve takibi gibi bir çok alt aşamadan oluşur.  Çoğu zaman süreci oluşturan bu adımların sürekli olarak tekrar edilmesi zor, sıkıcı ve yorucu bir iştir. Bu anlamda test otomasyon araçlarının kullanılması önemli faydalar sağlayabilir.  Otomasyon araçlarını sunan firmaların söylediklerinin aksine test otomasyonu yapısının oluşturulması pahalı ve zor bir süreçtir. Hatta bilinenin aksine manuel test adımlarından vazgeçmenizi yâda test ekibinizi küçültmek gibi (sakın yapmayın) faydalar sağlayamaz.  

İster manuel ister test otomasyonu tercih edilsin, Keyword driven testing çatısı (yada Table Driven Testing) test adımlarının veya otomasyon scriptlerinin geliştirilmesini, test senaryolarından veya ilgili iş akışından ayırmayı sağlayan dolayısı ile karmaşıklığı azaltan ve modülerliği artıran bir yaklaşımdır. Hazırlanan Keywordler (Kelimeler) farklı parametreler ile birden fazla test senaryosunda kullanılabilir hale gelir. Bir anlamda programlama dillerinde yazılan kodların tekrar kullanılabilmesini sağlayan fonksiyon veya metotlara benzer. Kelime temelli test yapısı, data driven test yapısına çok benzer. Fakat bu yaklaşımda test sistemi veriler yerine oluşturulan kelimeler ve ilgili parametreleri ile beslenir.

Çok basit bir örnek ile anlatmaya çalışalım: Elektronik bir sisteme de oturum açmayı test etmek için gereken adımları ( Browserın başlatılması, adres alanına ilgili adresin yazılması, kullanıcı adı kutusuna tıkanılması, kullancı adının girilmesi vb.) gibi tüm adımları parametrik hale getirdiğimizde ve adına “Login” dediğimizde ilk keyword’ müzü oluşturmuş oluyoruz. Bu kelimeyi besleyecek olan adres, kullanıcı adı vb. gibi veriler ise parametrelerimizi oluşturmuş oluyor.  Yani

Login (www.tumblr.com, kullaniciadi, sifre) kullanımında Login kelimemiz ve diğerleri parametrelerimizi oluşturuyor. Bu yaklaşımın nasıl bir faydası olabilir? Test tasarımı ile testin teknik detaylarını ve uygulamayı birbirinden ayırmayı en önemli faydası olarak gösterebiliriz. Böylelikle iş analistleri ve test mühendislerinin birlikte daha efektik çalışması mümkün olabilir.

5 kişiden oluşan bir ekibiniz olduğunu ve bu ekipte test geliştirme veya test otomasyonu ile ilgili bilgisi ve tecrübesi olan sadece bir kişi olduğunu varsayalım. Ekipteki test tasarımı ve geliştirilmesi konusundaki deneyimsiz fakat süreç konusundaki bilgili üyeler (örneğin iş analistleri) sadece kelimeleri (keyword) kullanarak sürece ait senaryoyu geliştirirken, test uzmanı bu kelimeler kullanılarak uygulanması gereken adımları (manuel yada otomatize) oluşturabilir. Örneğin ilgili kelimedeki aksiyonları gerçekleştirecek test otomasyon scriptlerini hazırlayabilir. Böylelikle tekrar kullanılabilecek bu keywordler sayesinde analistlerin yeni süreçler üretmesi mümkün olabilir. Hatta daha ürün geliştirilmeden bu kelimeler ve parametreleri belirlemek ve test süreçlerinde daha erken başlamakta mümkündür.

Son not yukarıda listelediğimiz avantajların yanında süreçlerin (fonksiyonlara benzer biçimde) gerekecek modüler kelimelere dönüştürülmesi ve eğer test otomasyonu uygulanacak ise ilgili araç ile deneyimli bir test mühendisinin bulundurulması ve bazı durumlarda konvansiyonel test yöntemlerine nazaran daha fazla vakit alması sebebi ile bu yöntem tercih etmeyebilirsiniz.