Tüm dünyada gündemde olan Agile süreçler test çalışmalarını da etkilemiş, yeni olmasa da bazı kavramlar daha fazla gündemimizde olmaya başlamıştır. Bu bağlamda Agile Testing’de özellikle üç tamamlayıcı teknik ağırlıklı olarak kullanılmaktadır.
- Test-Driven Development
- Behavior-Driven Development
- Acceptance Driven Development
Test seviyelerinden başlayıp, testle ilgili genel kavramlara ilişkin bilgilerden sonra bu üç kavrama kısaca değinerek agile test süreçlerini inceleyebiliriz.
Test sevileri değerlendirilirken üç ana katman olarak bakılmaktadır
- Bu seviyelerin en altında Unit Test bulunmaktadır ve en güçlü olması gereken test katmanıdır.
- Orta katmanda servis/entegrasyon testi katmanı bulunmaktadır. Regresyon (değişken ilişkileri) ve etkileşim testleri de bu seviyede yapılmaktadır.
- En üst katmanda UI/UAT test katmanı yer alır. Pratikte testler genellikle sadece bu katmanda yapılmaktadır. Özellikle user story’ler uçtan uca bu katmanda test edilmektedir. Fakat bu katman yatırım getirisi (Return of Invesmet – ROI) en düşük katmandır. Bu katman yerine özellikle otomasyonda Unit ve servis katmanına yatırım yapmak daha fazla fayda geri dönüşü sağlamaktadır.
Test Düzlemi
Test yaklaşımı nihai kullanıcıdan teknolojiye kadar bir düzlem üzerinde ifade edilebilir. Bu düzlem “business facing to technology facing” şeklinde ifade edilir ve 4 bölümde gösterilir.
- Q1: Unit ve Component testlerini ifade etmektedir.
- Q2: Fonksiyonel testleri ifade eder. User story seviyesinde bir test yapılması anlamına gelir.
- Q3: Araştırma (Exploratory) testleridir ve hata arama testleri anlamına gelir. Kullanılabilirlik ve UAT testleri bu seviyede yapılan testlerdir.
- Q4: Güvenlik, performans ve yük testlerini ifade etmektedir.
Akış genellikle Q1’den Q4’e şeklinde yapılmakla birlikte özellikle Q3 ve Q4 seviyelerinin derinliği uygulama kritikliği ile ilişkilidir.
Agile Projelerinde Kalite Riski
Bildiğiniz gibi test süreci aslında yazılım kalitesini belirleme sürecidir. Risk ise belirlenen sonucu olumlu veya olumsuz etkileyebilecek belirsizlikler olarak tanımlanmaktadır. Bu bağlamda risk kavramı içerisinde fırsatları da tehditleri de barındırabilir. Negatif riskler; ürünü değerinden uzaklaştıran yani iş değerini azaltan etkiler olarak düşünülebilir.
Riskler genellikle Release/Iterasyon planlama aşamalarında belirlenmeye çalışılır. Örneğin scrum metodolojisinde Product owner yüksek seviyeli riskleri açıklarken; sprint planlama aşamasında tüm takım user story’lerin risklerini belirlemelidir. Belirlenen riskler, takım tarafından etki ve olasılıklarına göre değerlendirilip izlenmelidir.
Sık yaşanan olumsuz durumlara; test datasının hiç olmaması veya yanlış olması, yavaş sistemeler, ekranlarda sınır koşullarının veya iş mantığının olmaması gibi örnekler verilebilir.
Test Eforunun Ölçülmesi
Efor belirleme çalışmaları user story’lerin öncelik ve karmaşıklığı dikkate alınarak yapılmalıdır. Sürekli bir aktivitedir, test sürecindeki engeller ve planlanan takvimden önce bitirilen tasklar göz önüne alınarak değiştirilebilmektedir.
Unit test ve Test Driven Development süreçlerinde efor belirleme çalışmaları development odaklı yapılmaktadır. Planlama özelinde yapılan toplantı/görüşmelerde tüm ekip ile efor ölçümünün paylaşılması takımın efor ölçümünü geliştirmesi için her zaman önerilmektedir.
Temel Yapı
Öncelikle test stratejisi oluşturulmalıdır. Buradaki strateji; kritiklik seviyesine göre her şeyi test et (pratikte imkansız), sadece spesifik caseleri test et, sadece %90 ve üzeri gerçekleşme ihtimali olan caseleri test et gibi test derinlik seviyesini belirlemelidir.
Test analizine başlamadan önce gereksinimlerin, teknik özelliklerin, mimarinin belirlenmesi ve risk analizinin gerçekleştirilmiş olması gerekmektedir. Bu dört içerik belirlenmeden test analizi gerçekleştirilemez. Bu dört başlığın oluşması ile test koşulları belirlenebilir. Mümkün olduğunca fazla koşul belirlenmeye çalışılmalıdır.
Test caseleri oluşturmak için belirlenen koşullar içerisinden seçim/birleştirme yapılarak ilerlenmelidir. Bu koşullar test datası, giriş ve çıkış verileri için mutlaka tanımlanmalıdır. Her şeyi test etmek pratikte imkansızdır ve hata bulma olasılığı yüksek alanlara odaklanılır. Aslında bu durum testi 7 prensibinde ifade edilmektedir. (Exhaustive test is not possible)
Definition of Done
Hazırlanan uygulamanın proda alınmaya hazır hale gelmesi (potentially shippable) Definition of Done tanımı olarak verilmektedir. Gereksinimlerin kısa ve özet bir listesi oluşturularak dokümante edilebilir. Oluşturulan bu doküman yaşayan bir dokümandır ve periyodik olarak gözden geçirilmeli ve güncellenmelidir. Liste müşteri/ürün sahibi (scrum için product owner) tarafından mutlaka kabul edilmelidir. ISTQB jargonunda bu başlık “exit criteria” olarak da geçmektedir ve testi sonlandırmak/bitirmek için gerekli kriterler olarak ifade edilmektedir.
Farklı seviyelerde oluşturulabilir. Örneğin product backlog veya user story seviyesinde özellik listesi, bir sprintte geliştirilmiş özelliklerin listesi, projenin tamamlanıp proda geçişe hazır hale gelmesi gibi farklı seviyelerde oluşturulabilir.
Definition of done, dizayn, tahmin (estimation) gibi faaliyetlere rehberlik sağlarken, reworkü engelleyerek maliyetlerin belirlenen limitlerde tutulmasına yardımcı olur. Yanlış anlama ve takım içerisindeki fikir ayrılıklarını sınırlar. Kriter listesine çok fazla odaklanmak veya bağımsız özelliklere ağırlık vermek ise en sık karşılaşılan olumsuz yönler olarak karşımıza çıkabilir.
Test-Driven Development (TDD)
5 aşamalı bir aktivite zincirinden oluşan bir yaklaşımdır. Aslında “Kod yazmaya başlamadan önce gereksinimleri nasıl sağlarım” düşüncesi üzerine kuruludur.
- Tek bir Unit Test hazırla
- Testin işlevsel olduğunu doğrula
- Kodu yaz
- Testi Çalıştır
- Refactor et. (hazırlanan kod testi geçene kadar refactor et)
Bu döngünün uygulanmasında en çok karşılaşılan tuzaklar aşağıda listelenmiştir. Özellikle bu şekilde bir çalışma planlanıyorsa bu tuzaklara dikkat edilmelidir.
- Tek Seferde Çok Fazla Test Yazmaya Çalışmak
Zaten agile yaklaşımın temel prensiplerine ters olan bu durum, tüm projeyi tek seferde tamamlamaya, başlangıçta yapılan testlerin sürekli değişimine ve kapsam kaymalarına uzanan bir sorunlar silsilesini beraberinde getirmektedir. Döngü belirlenen periyotlarda ve bu periyot içerisinde belirlenen kapsamlarda gerçekleştirilmelidir.
- Çok Büyük Test Parçalarının Yazılması
Hem test yazım hem de development olarak periyot hedeflerinde sapmalara neden olmanın yanında, bu şekilde çalışma kontrolü de zorlaştırmaktadır.
- Gereksinimleri Karşılamayan Test Yazımı
Bu durum ise gereğinden fazla çalışmayı beraberinde getirecektir.
- Kısmi Adaptasyon (Dedike olamama)
Tüm agile yaklaşımların ortak sorunu olan dedike olarak tek projede çalışamama durumu en sık karşılaşılan ve çözmesi en zor sorunlardan biri olarak karşımıza çıkmaktadır.
- Zayıf Maintenance
Kodlama sürecinde bakımın ve refactor’ün yetersiz olması projenin zaman planına etki eden önemli etkilerden biridir. Proje süresince sürekli refactor gereksinimi dolayısıyla clean code yaklaşımı benimsenmelidir. Bir yazılımcının başka bir yazılımcının kodunu beğenmemesi hepimizin sorunuyken, yazılımcının kendi yazdığı kodu bile birkaç ay sonra beğenmeyebildiğini en azından kendimizden biliyoruz.
- Nadir Kullanılan Test Araçlarının Seçimi
Yazılan tüm testlerde sürekli optimizasyon yapılmalıdır. Özellikle otomatik test araçlarında yapmadığımız testlerin optimizasyon gereksinimi yeterince zordur. Bununla birlikte kullandığımız test aracının yetersiz kalması veya karşılaştığımız sorunlarda yeterince cevap bulunamaması da sık karşılaşılan sorunlardan biridir.
Behavior-Driven Development (BDD)
TDD uygulanırken kullanılan pratiklerin iyileştirilmesi odağında çalışmaktadır.
Uygulamada genellikle tıkanma noktalarının ve sorunların kök nedenlerini bulmaya ve çözmeye odaklanır. Kök neden analizi için ise “5 Whys” prensibini kullanır. Bu prensibin ana odağı adından da anlaşılacağı üzere üst üste 5 kez “Neden?” sorusunun sorularak kök nedenin bulunmasıdır. Kök neden eğer 3. soruda bulunmuşsa daha fazla derine inilmez, 5. soruda genellikle kök nedene ulaşılsa da bulunamamışsa daha derine inilirken ilgili sürecin/operasyonun güncellenmesi gerekliliği ortaya çıkar.
BDD uygulamalarında Outside-in Thinking yaklaşımı önemlidir. Bu yaklaşım yapılan işe müşterinin bakış açısından bakmak, ardından süreçleri, araçları ve ürünleri tasarlamak; karar verirken müşteri için neyin en iyi olduğuna ve müşterinin gereksinimlerinin karşılamaya dikkat etmek anlamına gelmektedir. Outside-in thinking’de müşteri en önemli odak iken tersi olan inside-out thinking’de iş için en iyisi belirlenmeye çalışılır.
İsrafı engellemek için gerekli çalışmalar yapılarken, davranışlar (behaviors) mümkün olduğunca açık ve herkes tarafından anlaşılabilir şekilde tanımlanmaya çalışılır. Uzmanlar, testçiler, developerlar, analistler veya proje yöneticisi gibi farklı roller tarafından anlaşılabilir ve ulaşılabilir bir davranış seti, proje iletişiminin efektif sağlanması için de faydalı olacaktır. Tüm davranışların tek bir notasyonda ifade edilmesi anlaşılırlığı arttırırken düzeni de sağlayacaktır.
BDD’nin Faydaları:
- Tüm paydaşların gereksinimleri anlamasına yardımcı olur.
- Yapılan işin sağlayacağı faydayı ve amacını anlayarak çalışmaya imkan verir. Sürekli aynı konu çevresinde çalışanlar bir süre sonra ürünlerini nasıl geliştireceklerine dair körlük yaşayabilmekte, yeni geliştirme isteklerinde “Ne gerek var?” gibi tepkiler verebilmektedir. Bu durumu aşamanın yollarından biri de BDD yaklaşımını kullanmaktır.
BDD Uygulanırken en çok karşılaşılan tuzaklar:
- Uygulamada sadece çözümü düşünerek kavramsal yaklaşmak en sık karşılaşılan sorun olarak karşımıza çıkmaktadır.
- BDD yaklaşımı çalışılan iş domaini konusunda aşinalık gerektirmektedir. User story, iş domaini dili gibi kısımlarda bilgi gerekebilir ancak alışıldığında büyük kolaylık sağlamaktadır.
Acceptance Test-Driven Development (ATDD)
Gereksinimlerin ve kabul kriterlerinin doğrulanması bu yaklaşımın ana odağıdır. İletişim, iş birliği ve berraklık esası ile hareket edilir. Tüm paydaşların (developerler, analistler, son kullanıcılar vs) katılımı ile kabul kriterleri tanımlanır. Kabul testleri, yazılım bitmiş sayılmadan önce mutlaka başarılı şekilde geçmesi gereken test seti olarak tanımlanır. Geleneksel olarak yazılım geliştirme sürecinin sonunda çalıştırılır.
Ortak olarak tanımlanan kabul testi, geliştirmeye başlamadan önce otomatize edilir. Tüm proje üyelerinin nelerin tamamlanması gerektiğini anlamasını sağlar. ATDD yaklaşımında otomatize edilmiş testler, geleneksel olarak sonra çalıştırılma yerine proje boyunca çalıştırılabilir.
Amaç, uygulanabilir testler yapmaktır. Kodda değişiklik yapıldığından otomatik olarak yürütülür. İlerlemenin nesnel olarak ölçülmesini sağlarken karmaşıklığın öncelikli olarak özellik ve user story bazında belirlenmesine yardımcı olur.
Çok farklı tool ve frameworklere sahiptir. Örneğin FitNess basit ve teknik olmayan bir araç olarak kullanılabilir iken, Concordion HTML sayfaları olarak ifade edilen bir framework’tür. Projeye uygun ve ekibin kullanabileceği aracın seçimi pratiklik açısından önemlidir.
Functional ve Nonfunctional Black Box Test Dizaynı
Black box testleri uygulamanın işlevini veya bir metodu inceler. Unit, Entegrasyon, sistem veya kabul testi gibi farklı seviyelerde uygulanabilir. Kullanıcı bakış açısında gerçekleştirilen ve tarafsız bir testtir. Üst seviyede kaldığından uygulamada farklı pathlerin denenmesi ve tasarlanmasının karmaşık olması gibi olumsuz özellikler ile karşılaşılabilir.
Fonksiyonel Testler:
- Uygulamanın işlevsel gereksinimleri ile ilgilidir.
- Yazılım testçileri tarafından gerçekleştirilir. (Unit test düzeyindeyse yazılımcılar tarafından da yapılır.)
- Sistem uyumluluğunu değerlendirir.
- Testçiler belirli eylem ve fonksiyonları doğrular.
- Manuel veya otomatik olarak yapılabilir.
Fonksiyonel Olmayan Testler:
- Spesifik bir işlev veya fonksiyonun testi ile ilgilenmez
- Test edilen sistemin hazır olup olmadığı ile ilgilenir. (Performans, Ölçeklendirme, Kullanılabilirlik, Güvenlik gibi)
- İdealde testçilerin kontrolünü sağlamak için fonksiyonel olmayan gereksinimlerin de belirlenmesi gerekir.
Keşif/Araştırma Testi
Test dizaynının ve uygulamasının aynı anda yapıldığı, programı daha iyi tanımaya olanak veren, hata arama testleridir. Prodda neler yaşanabileceği düşünülerek yapılır. Beceri ve yaratıcılığı ön plana çıkarır. Çıkan sonuçlar fix gerekir mi diye yorumlanır. Farklı test teknikleri uygulanabilir. Basit senaryolar ile başlanarak, iş akışları, değişkenler, grafikler, sessionlar ve raporlar mutlaka kontrol edilerek ilerlenebilir.
Aslında experience based test tekniklerindendir. Checklist kontrolü veya hata tahmini gibi de yapılabilir. Literatürde bu teknikler ayrı ayrı anlatılabilmektedir. Güvenlik tarafında atak testleri bu tekniklerdendir.
Testçisinin asıl emeği, test ettiği uygulamanın kalitesidir.
