A. Test Faaliyetlerine Ait Geleneksel Bakış Açısı
Geleneksel test faaliyetleri, tamamlanmış bir spesifikasyona göre doğrulanması gereken bitmiş bir yazılıma gerekesinim duyar. Bu yaklaşımın altında yatan temel varsayım şudur: Test faaliyetleri ancak kodlama bittikten sonra yapılabilir.(?)
Geleneksel yaklaşımın temel odak noktası "hataları" önlemekten ziyada "hataları" tespit etmektir.Test faaliyetleri bir bakıma, geliştirilen ürünün son anda geçmesi gereken "kalite kontrol kapıları" olarak görülür.Bu "kapılarda" geliştirme takımından ayrık olan bir test takımının üyeleri hizmet verir.Test, geliştirmeden ayrık bir "fazdır": Geliştirme ve sonrasında Test.Kalitesiz yazılımın, müşteriye gitmesinin önlenmesinin esas sorumlululuğu ayrık olan bu test grubuna aittir.
Neden geliştirmeden "ayrık" bir test grubu-takımı-bölümü oluşturulur? Cevaba ait temel varsayımlar şunlardır:
- Programlama "yapıcı" bir faalitken, test "yıkıcı" bir faaliyettir. Yani iki rol arasında "çıkar" çatışması vardır ve bir kişinin bu iki farklı şapkayı giymesi(rolü üstlenmesi) gerçekci değildir.Bu nedenle programcılar test yapamaz.
- Eğer programcılar kendi kodlarını test ederlerse, testleri kendi kodlamalarına göre değiştirebilirler: Yani testlere göre kodlarını düzenliyeceklerine, testleri kodlamalarına uydurma yoluna gidebilirler.
- Eğer test faaliyetleri, kodlamayı yapan aynı grup tarafından yapılırsa, bu grup projeyi bitim tarihine yetiştirebilmek için bazı testleri dikkate almıyacak, ihmal edecektir.
- Test uzmanlık gerektirir.İyi test becelerileri elde etmek yoğun pratik ve zaman gerektirir.Bu nedenle testçiler sadece test yapar.
B. Teste Bakıştaki Paradigma Değişimi
B1. Değişim : Test Artık Bildiğiniz "Test" Değil :- )
Çevik süreçlerde "Test" ve "Gereksimler" arasındaki fark-ayrışma muğlaklaşmaktadır.Sistemin davranışı, yazılan testlerlerle tanımlanmakta ve bu testlerin çalıştırılması ile doğrulanmaktadır. Artık testler bir gereksinim, gerkesinimlerde birer test.
Bu yönteme Acceptance Test-Driven Development (A-TDD) denmektedir.
Acceptance Test-Driven Development (A-TDD):
Gereksinimlerin tanımlanmasında "örnekleri" ve "otomatize edilebilen testleri" kullanan ve takım halinde workshop'lar şeklinde yapılan gereksinim keşfetme yöntemi. A-TDD yöntemi gereksinimleri otomatize edilebilen (automatable) testler olarak formüle eder.
A-TDD ( acceptance test-driven development ) TDD (test-driven development) ile karıştırılmamalıdır.TDD (Test-Driven Development), geliştiricilerin testi yaz-kodla-yeniden yapılandır (test–code–refactor) mikro-döngüsünde kullandığı kodlamaya ait bir teknik iken, A-TDD ( acceptance test-driven development ), ise tüm takım tarafından (whole-team technique) tartış-keşfet-teslim et (discuss–develop–deliver) döngüsünde gereksinimlerin keşfedilmesinde kullanılan bir teknik yöntemdir.Her ikisinde de testler önce yazılmaktadır, fakat amaçlar farklıdır.
Bu amaçla yapılan workshop'ların temel amacı ilgili iterasyona ait gereksimlerin netleştirilmesi, ve bunun tüm takım tarafından paylaşılmasıdır.Bu esnada "örnekler" gereksinimlerin olgunlaştırılması için kullanılır ve daha sonra bu gereksinimler testlere dönüştürülür. Yazılan testler elde edilen bu açıklığın bir göstergesidir-ifadesidir.
Bu yöntem "Test faaliyetleri ancak kodlama bittikten sonra yapılabilir" varsayımını çürütmektedir.
A-TDD 'yi destekleyen araçlar:
B2. Değişim : Tüm Takım Beraber Yaklaşımı (Whole Team Approach)
Çevik geliştirmede takımların yapısı cross-functional olarak tanımlanır: minumun geliştiştiriciler ve testcilerden oluşur.Bu nedenle testleri yapan ayrık bir test bölümü ve takımı oluşturulmasından kaçınılır.Testçiler ve programcılar aynı takımın bir parçasıdır ve ortak bir amaca yönelik olarak beraber çalışırlar.
Örneğin Scrum takımlarında testçiler "testçi" değil sadece takımın bir üyesidir.Daha net bir ifade ile "test konusunda uzmanlığı" olan bir takım üyesi.
Hatta bu üyeler, test işlemleri hazır oluncaya kadar bekleyen "part-time" üyeler olarak görülmez.Tam aksine bu üye bu zaman aralığında testle ilgisi olmayan işleri üstlenip, yeteneklerini arttırır. Takımın ortak bir amacı vardır ve takımın farklı ana uzmanlık alanına sahip her bir üyesi bu amaca ulaşılmasından sorumludur.
Bu yaklaşım, geleneksel yöntemlerin bağımsız-ayrık bir test grubu oluşturmasının arkasında yatan varsayımlarının hepsini çürütmemekte ama bu varsayımların bir kısmına farklı alternatif çözümler sunmaktadır. Temelde test ve geliştirme faaliyetlerinin bağımsız olması gerektiği kabul edilmekte ama bunun
testçilerin ve geliştiricilerin birbirinden ayrık olması gerektiği şeklinde yorumlamamaktadır.
Farklı bölümler-takımlar arasında oluşacak iletişim ek yükünü ortadan kaldırmak için, test ve kodlamayı birbirinden ayırmadan testi nasıl bağımsız kılabilirim?
Cevabınını ise şu şekilde vermektedir: Kodlama yapmadan önce testleri yazarak.Testler mevcut kodlamadan etkilenemez çünkü ortada henüz kod yok. Böylelikle test faaliyetleri bölümlerin ayrılmasına gerek kalmadan "bağımsız" olma ruhunu koruyabilmektedir.
Burda dikkat edilmesi gereken A-TDD faaliyetlerinin sadece "testciler" tarafından yapılan bir faaliyet olmadığıdır: tüm takım tarafından yapılır (testciler dahil). Bunun aksine TDD faaliyetlerinde, birim testler(unit test) geliştiriciler tarafından, sisteme ait işlevler kodlanırken yazılır.Kodlama ve birim test
faaliyetleri ayrık safhalar olmayıp testi yaz -kodla-yeniden yapılandır (test–code–refactor) mikro-döngüsünde aynı zamanda yapılır . Yine ilgili kodu kim
yazıyorsa, ona ait unit testleri aynı geliştirici işlevleri kodlarken yazar: başka bir kişi değil.
Böylelikle "test faaliyetleri" geliştirme faaliyetlernin içine "entegre" edilmiş olur.Odak noktası hataları yakalamaktan ziyade "önlemeye" kaymıştır.
C. Paradigmayı Destekleyen Takım Oluşumu: Özellik Takımı ( Feature Team )
Özellik takımı uzun ömürlü, çok işlevli(cross-functional: farklı uzmanlıklara sahip, farklı bilgi alanlardan gelen kişilerden oluşan) müşteriye ait her bir isteği-özelliği baştan-sona bir bütün olarak (tabiri caizse anahtar teslimi şeklinde) kendi başına gerçekleyebileyen bir takım çeşidir.Scrum kullanan projelerde bu takımların eleman sayısı genellikle 7 ± kişidir.
Özellik Takımı (Feature Team ) bir bütün olarak, müşteriye ait ilgili istediği-özelliği baştan sona gerçekleyecek bilgi ve donanıma sahiptir.Aksi durumda
takımdan ilgili beceri ve beceriyi öğrenmesi veya elde etmesi beklenir.
İlgili özelliğin gerçeklenmesi tüm takımın sorumluluğundadır.(ortak sorumluluk).Başarı ya da başarısızlık tüm takıma aittir. Takım elemanları takımın tam zamanlı (% 100) üyeleridir: elemanlar aynı zamanda başka farklı projelerin yarı-zamanlı(part-time) çalışanları değildir.
Not: Bir bütün olarak- baştan sona ne demek : İlgili özelliği gerçekleştirmek yapmak ne demek? Bu sizin "yaptım" tanımınıza göre değişir. (Definition of done)
D. Yeni Paradigmaya Ait Gözlemler
Çevik geliştirmede testle ilgili ilk göze çarpan şey, geleneksel literatürde olgunlaşmış test çeşitlerine çok fazla itibar etmemesi.Örneğin geleneksel test literatüründe onlarca test çeşidi görünürken, çevik geliştirmedeki sınıflandırmalar "yalın" ve "sınırlı" seviyede kalmakta.
Bu ayrıntılı sınıflandırmalardan uzak durulmasınının temel nedeni bu olgunlaşmış test çeşitlerinin sanki test uzmanlarından oluşan ayrık bölümlerin var olması gerektiği gibi bir düşünceye zemin hazırlamasıdır.
Bu tür bir test bakış açısının, ayrık test ve kalite takımları-bölümleri olan kurumlarda uygulanmasının büyük bir direnişle karşılanacağını söyleyebiliriz. Yeni paradigmada kendi rolünü anlamayan testcilerin kurumu belli bir süre sonra terk etme olasılığı da yüksektir. Dolayısıyla bu sürecin çok iyi ve dikkatli bir şekilde yürütülmesi gerekmektedir.
Her şeyden önce, herhangi bir şeyi çevikciler veya başka bir "etiket" altındaki grup (CMMI, ITIL, RUP vs) söyledi diye uygulamayınız. Problemleriniz ne? Bu problemlere çözüm getirebilcek pratikler neler olabilir? sorusundan sonra bu pratikleri DENEYİN ve sonucunu görün...İlgili koşulda işe yaramıyorsa onu terkedin ve yenilerine bakın veya bizzat kendiniz yenilerini oluşturun.
Tavsiye Edilen ve Yararlanılan Kaynaklar:
- Practices for scaling lean & agile development : large, multisite, and offshore product development with large-scale Scrum / Craig Larman, Bas Vodde. (Test Bölümü)
- Agile Testing: A Practical Guide for Testers and Agile Teams / Lisa Crispin, Janet Gregory
- Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum / Craig Larman, Bas Vodde ( Feature Team Bölümü) Not: Bu bölümü ücretsiz olarak burdan okuyabilirsiniz.