ÇEVİK YAZILIM GELİŞTİRME YÖNTEMLERİNDE ETKİLİ TEST ARAÇLARI EFFECTIVE TEST TOOLS IN THE AGILE SOFTWARE DEVELOPMENT METHODS

Transkript

1 ÇEVİK YAZILIM GELİŞTİRME YÖNTEMLERİNDE ETKİLİ TEST ARAÇLARI Ahmet BARAN, Funda AKAR, Fulya ASLAY Erzincan Üniversitesi, Mühendisik Fakültesi ÖZET : Çevik yazılım geliştirme yöntemleri, son zamanlarda kullanılan ana akım yazılım geliştirme yöntemleridir. Bu yöntemler, tek bir çevrim ile ürünü müşteriye sunmayı hedefleyen geleneksel yazılım geliştirme yöntemlerinin aksine, birçok iterasyon ve artırımlarla ürünü müşteriye, sürekli olarak sunar. Daha hızlı, daha fonksiyonel ve daha kaliteli ürün teslimi amacıyla tercih edilen bu yöntemlerde çeşitli test pratikleri oluşmuştur. Bu çalışmada, önce geleneksel yazılım geliştirme yöntemlerindeki test sorunları özetlenerek, çevik yazılım geliştirme yöntemlerinde kullanılan en iyi test pratikleri araştırması sunulmuş ve yazarların tecrübeleri ile birleştirilerek etkili test pratikleri önerilmiştir. Önerilen test pratiklerinin kullanımı ile daha kaliteli yazılım geliştirme süreçlerinin gerçekleştirileceği öngörülmektedir. Anahtar Kelimeler: Çevik yazılım geliştirme yöntemleri, Çevik yazılım geliştirme yöntemlerinde test EFFECTIVE TEST TOOLS IN THE AGILE SOFTWARE DEVELOPMENT METHODS ABSTRACT: Agile software development methods are mainstream software development methods recently used. These methods, unlike traditional software development methods that offer products to customers with a single cycle, provide a lot of iteration and increment of the product to the customer continuously. In this methods that preferred in order to deliver faster, more functional and better higher quality products, various testing practices are. In this study, initially testing issues in traditional software development methods are summarized next, research of the best testing practices used in agile software development methods in the literature have been presented. Afterwards, effective test practices that have been combined with the best practices and experience of the authors have been proposed. It is predicted that high quality software development process can be carried out using these agile test practices. Keywords: Agile software development methods, Test on agile software development methods GİRİŞ 2001 yılında çevik yazılım geliştirme manifestosunun yayınlanmasından sonra; Microsoft, SAP ve Adobe gibi büyük yazılım şirketlerinin de çevik yazılıma adapte olmalarıyla birlikte, çevik yazılım geliştirme, ana akım yazılım geliştirme yöntemi haline gelmiştir (Schmidt, 2016; West ve Grant, 2010) ve 2015 yılı itibarı ile geliştiricilerin %95 i çevik yazılım geliştirme pratiklerini kullanmaktadır (Version One Inc, 2016). Geliştiricilerin çevik yazılım yöntemlerini tercih etmelerinin birçok nedeni bulunmakla birlikte, yazılım kalitesini artırmak en önemli nedenler arasındadır (Version One Inc, 2016). Geleneksel yazılım geliştirme yöntemlerindeki yazılımın bir kez geliştirilip teslim edilmesine karşın, çevik yazılım geliştirme yöntemlerinde yazılım kısa aralıklarla sürekli geliştirilir ve müşteriye teslim edilir. Bu şekilde çevik yöntemlerde üretilen her artırımsal yazılım paketinin, müşterinin kalite beklentilerini karşılaması ve buna bağlı olarak da sürekli bir yazılım kalite güvencesi sağlanır (Schmidt, 2016).

2 Müşterilerin kalite beklentilerini sağlayacak kaliteli bir yazılım ürünü için, yazılımın olabildiğince sorunsuz olması gerekmektedir. Buradaki sorun çok geniş bir kavram olup; hatalı ihtiyaç tanımlanması sorunları, müşterigeliştirici iletişiminden kaynaklı sorunlar, ihtiyaçlardan bilinçli bir biçimde sapma sorunları, mantıksal tasarım sorunları, kodlama sorunları, kodlama yönergelerine ve dökümantasyon ile uyuşmama sorunları, test sürecinin hızlı geçilmesinden kaynaklanan sorunlar, prosedür sorunları ve dökümantasyon sorunları başlıkları altında özetlenebilir (Galin, 2004). Bu sorunların çoğunun hafifletilmesi için yazılım testi hususu öne çıkmaktadır. Yazılım testi, ürün kalitesini kontrol etmek için uygulanan temel kalite güvence aracıdır (Galin, 2004) ve önemi son zamanlarda giderek artmaktadır. Bilişim endüstrisinin 2012 yılında kalite güvence ve test çalışmalarına ortalama %18 bütçe ayırdığı, 2013 te %23, 2014 de %26 ve 2015 de %35 bütçe ayırdığı raporlanmıştır ve bu oranın 2018 de %40 olacağı tahmin edilmektedir (Capgemini vd., 2015). Test işlemlerini etkili bir şekilde yaparak yukarıdaki sorunların bir çoğu önemli derecede hafifletilebilir; ürün kalitesi, kullanım kalitesi ve veri kalitesi yükseltilebilir; yazılımın fonksiyonelliği, performans etkinliği, uyumluluğu, kullanılabilirliği, güvenilirliği, bakımının sürdürülebilirliği, taşınabilirliği iyileştirilebilir. Bununla birlikte yazılım testleri için oldukça fazla yöntem ve araç bulunmaktadır (Hariprasath, 2015; Spillner vd., 2014). Her teknik, test nesnesinin özel bir yönünü test etmeye odaklanır. Yine her testin, çeşitli hataları bulmakta güçlü ve zayıf yönleri bulunmaktadır. Tüm hususlara çözüm olabilecek tek bir test tekniği bulunmamaktadır. Bu nedenle değişik nedenlerden kaynaklanabilecek hataları bulabilmek için farklı test tekniklerinin kombinasyonlarının kullanılması gereklidir. Birim testi, entegrasyon testi, sistem testi ve kabul testi standart testler olarak yapılırken, fonksiyonel test ve fonksiyonel olmayan test başlıkları altında onlarca farklı testler yapılabilmektedir. Yine statik test ve dinamik test farklı amaçlarla ve farklı hususlara odaklanan değişik teknikleri uygulayan test yöntemleridir (Spillner vd., 2014). Her projede tüm bu testlerin uygulanması zorunlu değildir. Fakat her projenin ihtiyaçlarına göre, bahsedilen sorunları minimize edecek, etkili test tekniklerinin sistematik bir stratejiye göre uygulanması gereklidir. Bu çalışmada; çevik yazılım geliştirme yöntemlerinde kullanılan literatürdeki en iyi test pratikleri yazarların tecrübeleri ile birleştirilerek, çevik yazılım süreçlerinde uygulanabilecek etkili bir test stratejisi önerilmiştir. Bu çalışma dört bölümden oluşmaktadır. İkinci bölümde, geleneksel yazılım geliştirme yöntemlerinin test hususlarındaki problemleri, üçüncü bölümde günümüzde en çok kullanılan çevik yazılım geliştirme yöntemleri tanıtılarak literatürdeki en iyi test pratikleri sunulmuştur. Çalışma, dördüncü bölümdeki sonuç ve öneriler ile sonlanmaktadır. GELENEKSEL YAZILIM GELİŞTİRME VE TEST Bu bölümde geleneksel yazılım geliştirme yöntemleri olan Şelale, V-Model, Helezonik Model ve W-Model kısaca tanıtılarak test hususları değerlendirilecektir. Şelale modelinde (Royce, 1970) ihtiyaçların tanımlanması ve test aşamaları arasında uzun bir geri besleme olması nedeniyle model; değişen iş süreçlerini, değişen fikirleri, unutulan ihtiyaçları ve yanlış anlaşılan ihtiyaçları yönetemez. Bu sorunlar test aşamasında fark edildiğinde uzun zaman ve işgücü kaybına neden olur (Balaji ve Murugaiyan, 2012). Test için gerekli hazırlıklar yapılmadan geliştirme yapılması, sistematik bir testin yapılmasını zorlaştırır (Spillner, 2002). Bir aşamadaki problemler, o aşama boyunca tamamen çözümlenemez. Gerçekte, bir aşamaya ait problemler ancak o aşamadan sonraki aşama/aşamalarda görünür ve bu durum sistemin sorunlu geliştirilmesine neden olur (Balaji ve Murugaiyan, 2012; Christie, 2008). Test personeli tüm geliştirme aşamalarından sonra sürece dâhil olur. Kabul testine kadar olan testlerde müşteri bulunmamaktadır. Süreç içerisinde beklenmeyen bir durum ortaya çıktığında sürecin nasıl cevap vereceği tanımlı değildir (Spillner vd., 2014). V-Modelinde (Boehm, 1979) testin plansız yapılması sorunu haricinde, şelale modelindeki tüm sorunlar geçerlidir (Spillner, 2002). Bununla birlikte; test planı ve stratejisi, ihtiyaçların tanımlanmasının hemen sonrasında tanımlandığı için, süreç boyunca olabilecek değişimlere adapte olamamaktadır. Testlerin, geliştirme aşamaları ile bire bir ilişkili olduğu varsayılmaktadır. Fakat gerçek hayat uygulamalarında çoğa çok ilişkilerin kurulması gerektiği ile oldukça sık karşılaşılmaktadır. V sembolünün sol bacağı ile sağ bacağı arasında kurulmuş olan test bağlantıları belirsizdir (Christie, 2008).

3 Helezonik (Spiral) modelinde (Boehm, 1988) test planının sistem tasarımından sonra yapılması V-modelindeki erken planlama problemini bir miktar hafifletmektedir (Spillner, 2002). Bununla birlikte, aşamalar ve aşama süreçleri hâlâ lineerdir (Christie, 2008). Son çevrimde Şelale basamaklarının kullanılması nedeniyle, test hâlâ kodlamadan sonra yapılmaktadır (Schwaber, 1997) ve bu durum plansızlık hariç, Şelale modelinin tüm sorunlarını beraber getirmektedir. W-Modelinde (Herzlich, 1993) analiz ve tasarım aşamaları ile test planlama aşamalarının birlikte yürütülmesine rağmen; hangi süreçlere ne kadar kaynak (zaman, personel)ayrılacağı belirlenmemiştir (Spillner, 2002). Sol bacaktaki test işlemlerinin farklı personel ile gerçekleştirilmek istenirse; ekstra personel çalıştırılmasına ihtiyaç doğurmaktadır. Aynı personel ile gerçekleştirilmek istenirse; kodlamada gecikmelere ya da test dokümanının kısa sürede gözden geçirilmesine neden olabilmektedir (Christie, 2008). Bu kısıtlar, geleneksel yöntemlerle geliştirilen yazılımların sadece fonksiyonelliğinde sıkıntılara neden olmakla kalmayıp, yazılımların kalitesinde, performansında, uyumluluğunda, kullanılabilirliğinde, güvenilirliğinde, bakımının sürdürülmesinde ve taşınabilmesinde de çeşitli kısıtlara neden olabilmektedir (Balaji ve Murugaiyan, 2012; Jorgensen, 2013; Spillner vd., 2014). ÇEVİK YAZILIM GELİŞTİRME VE TEST Yazılım endüstrisinin, bugünün hızlı değişen bilişim dünyasına ayak uydurabilmesini sağlayan yazılım geliştirme yöntemi olan çevik yazılım geliştirme, 2001 yılında 17 yazılım geliştirici tarafından bir manifesto halinde ilkesel olarak yayınlanmıştır. Bu manifestoda Süreçler ve araçlardan ziyade bireyler ve etkileşimlere, Kapsamlı dökümantasyondan ziyade çalışan yazılıma, Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine, Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye değer vermeye kanaat getirildiği ifade edilmiştir (Beck vd., 2001). Daha önceden bilinen fakat bu manifestoda özetlenen bakış açısının yayınlanmasından itibaren; Uç Programlama (Extreme Programming [XP]), Scrum, Yalın Yazılım Geliştirme (Lean Software Development [LSD]), Kanban, Özellik Güdümlü Programlama (Feature Driven Development [FDD]), Dinamik Sistemler Geliştirme Yöntemi (Dynamic Systems Development Methodology [DSDM]) ve Adaptif Yazılım Geliştirme (Adaptive Software Development [ASD]) ana akım çevik yazılım yöntemleri olarak görülmeye başlanmıştır (Campanelli ve Parreiras, 2015). Bunlarla birlikte, Çevik Modelleme (Agile Modelling [AM]), Crystal ve Çevik Birleşik Süreç (Agile Unified Process [AUP]) yöntemleri tercih edilen diğer çevik yazılım geliştirme yöntemleri olup, bu son grup daha çok proje ve insan gücü yönetimine odaklanmıştır. Bu yüzden bu çalışmada ilk gruptaki 7 çevik yöntem kısaca tanıtılacak ve test pratikleri vurgulanacaktır. Çevik yazılım geliştirme yöntemleri artırım ve iterasyon temelli yöntemlerdir. Artırım ve iterasyon temelli yöntemler, Şelale geliştirme yöntemini parçalara böler, her bir parça için aynı süreci gerçekleştirir ve geliştirme döngüsünde tekrarlar (Cohen vd., 2004). Artırımsal geliştirme, geliştirme süresini azaltmak amacıyla projeyi eşzamanlı artırımlara böler. Şelale da olduğu gibi geliştirme başlamadan tüm ihtiyaçlar analiz edilir. Bununla birlikte, ihtiyaçlar fonksiyonel artımlar olacak şekilde parçalara bölünür. Artırımların geliştirilmesi eşzamanlı olduğunda, çok görevlilik mantığı ile proje geliştirme süresi azalır. İteratif geliştirme ise, projeyi çeşitli uzunluklarda iterasyonlara böler. Bu iterasyonların her biri, kullanılabilir ve dökümante edilmiş ürünler üretir. İlk iterasyon en temel ürünü üretmekle başlar ve ardışık her iterasyon ürüne yeni özellikler ekler. Her iterasyonda, o iterasyona ait analiz, tasarım, gerçekleştirme ve test etme işlemleri kendi Şelale süreci içerisinde sürdürülür. İteratif geliştirme, sadece bulunulan iterasyondaki ihtiyaçları karşılayacak değişimler ile ilgilenir. Sonraki iterasyon(lar)da gerekli olacak/olabilecek ihtiyaçlar, iterasyon sırası gelmeden değerlendirmeye alınmaz. Böylece, teknolojinin gelişimi ve/veya müşterinin fikir/istek değişimleri, projenin momentumuna minimum etki eder (Cohen vd., 2004). Çevik yöntemler olarak adlandırılan bu yöntemler, manifestodan önce de kullanılan yöntemlerdir fakat manifesto ile daha çok kullanılmaya başlanmıştır. (Abrahamsson vd., 2003) bu yöntemlerin manifestoya kadar evrimleşmesini ve (Dingsøyr vd., 2012) ise arası 10 yılda çevik yöntemlerin gelişimini şematik olarak göstermektedir.

4 Uç Programlama XP ihtiyaçların belirsiz ve sıkça değiştiği şartlarda, küçük yazılım takımlarının başarılı bir yazılım geliştirmesine yardımcı olan yazılım mühendisliği pratiklerini ifade eder. Kısa iterasyonlarla (en fazla birkaç ay), küçük sürümler yayınlayarak hızlı geri besleme almak, müşterinin yakın katılımı, sürekli iletişim ve koordinasyon, çift halinde programlama, sürekli geliştirme, sürekli entegrasyon ve sürekli test bu yöntemin temel karakteristikleridir (Abrahamsson vd., 2003; Beck, 1999; Campanelli ve Parreiras, 2015) XP de bileşen (component) testleri programcılar tarafından anlık olarak yapılır. Bu testler bir araya getirilir ve bileşen testlerin tümünden geçmelidir. Test güdümlü geliştirme (Test Driven Development [TDD]) söz konusudur. Bu geliştirme tipinde hangi testlerin geçileceği bilinmeden kod yazılmaya geçilmez. Önce testler hazırlanır, kodlar yazılır ve düzenleme (refactoring) yapılır. Akademik ve endüstriyel çalışmalarda TDD nin yazılım geliştirme sürecinde yazılım iç kalitesi (internal quality), dış kalitesi (external quality) ve üretkenliğe (productivity) etkileri incelendmiş ve iç kalitede %76 ve dış kalitede %88 avantaj sağladığı rapor edilmiştir (Bissi vd., 2016). Diğer taraftan müşteriler her bir iterasyon için iş odaklı, test edilebilir ve sonucu kestirilebilir fonksiyonel testler hazırlar ve bileşenler bu testlerin tümünden geçmelidir. Bazı durumlarda müşteri geçilemeyen testi çözümlemenin zaman gecikmesi ve maliyete etkisini birlikte değerlendirerek problemin çözümünden bilerek vazgeçebilir. Müşteri tam zamanlı olarak takımla birlikte çalışır. İterasyon sonuç ürünü yeni kod, aktif sisteme saatler geçmeden entegre edilir. Entegrasyon sırasında sistem sıfırdan inşaa edilir ve tüm testler geçilmelidir. Aksi durumda değişikliklerin entegrasyonu iptal edilir ve aktif iterasyona geri dönülerek sorun çözülmeye çalışılır (Beck, 1999). Her entegrasyon testinde tekrar test edilecek hususlar için test otomasyonu yazılması tavsiye edilir. Scrum Scrum (Schwaber, 1995), hızla değişen, gereksinimlerin açıkça tanımlanamadığı ve kaotik şartlarda yazılım geliştirme sürecini yönetmek için en çok kullanılan yöntemlerden biridir (Version One Inc, 2016). Esneklik, adaptiflik ve üretkenlik temelli deneysel bir yaklaşım olup, geliştiricileri kendi yöntemlerini kullanmaları konusunda serbest bırakır. Scrum da karmaşık bir proje, küçük iş parçalarına bölünerek backlog denilen havuza atılır. Bir iş parçası yeterince küçükse itemin açık, test edilebilir ve mümkün olup olmadığı anlaşılabilir felsefesine göre değişik büyüklükte parçalar ayrılır. Backlog havuzundaki işler müşteri tarafından öncelik sırasına konulur ve gerektiğinde ekleme, çıkarma ve yeni sıralama yapılabilir. Her bir alt iş sprint adı verilen iterasyon içerisinde yapılır. Sprint süresi, katî olarak sınırlı bir çalışma süresidir. Bir iterasyon için, sprint öncesi planlama toplantısı, sprint ve sprint sonrası değerlendirme toplantısı (toplantılarda da saat sınırı vardır) yapılmakla birlikte, her gün 15 dakikayı geçmeyecek ayaküstü scrum-toplantıları yapılır. Takımlar küçük sayıdadır ve iterasyonlar kısa sürelidir (1-6 hafta). Sprint ler lineer değildir. Varsa açık (explicit) bilgiler kullanılır, geri kalanı için örtük (tacit) bilgi ve deneme yanılma yöntemi kullanılır. Bu şekilde sprintlerin ilerlemesi ile nihai ürüne ulaşılır. Scrum yönteminde kısa aralıklı sürüm yayınlanması, düzenli olarak küçük parçaların sisteme eklenmesi anlamına gelmektedir. Bu durum bakımı, testi ve hataların yakalanmasını kolaylaştırmaktadır (Cohen vd., 2004). Sürekli dökümantasyon yapılması, gerek bakımı gerekse testleri kolaylaştırmaktadır. Sürekli test pratiği; big-bang tekniğinin tam tersi şekilde, testi geliştirmenin ana unsurlarından biri haline getirir. Geliştiricilerin hatalarını kodlama aşamasında yakalamasını ve yöneticilerin herhangi bir zamanda demo yapımı veya ürün satmasını mümkün kılar. Müşteri sürekli olarak geliştirme odasında takım ile birlikte çalışır. Test sorumlusu bilgisayar başında demo yu tanıtır. Müşteri Tamam dediğinde, yani yazılım kullanıcı hikayelerinden oluşmuş tüm kabul kriterlerini geçince, kabul söz konusudur. Bitmemiş veya hatalı bileşenler asla kabul edilmez. Bu hususlar, sıfır noktası olmak üzere backlog havuzuna geri konulur (Pichler, 2010). Yalın Yazılım Geliştirme Yalın yazılım geliştirmenin en öncelikli felsefesi üretim sürecindeki atıkları (waste) atmaktır. Atık; kısmi yapılmış işler, ekstra yapılan işlemler (bürokrasi gibi), program kusurları, ekstra özellikler, görev değişiklikleri (kişiye verilen iş süresince aradan çıkarılmak üzere başka bir iş verilmesi), beklemeler (özellikle biten bir bileşenin entegrasyon için diğer bir bileşeni beklemesi), hareketlilik (geliştiricinin konsantrasyonunu bozacak durumlar) ve program kusurları gibi müşteri açısından ürünün değerine katkısı olmayan herşeydir (Poppendieck ve Poppendieck, 2003). Bu şekilde sadece müşterinin istediğini karşılayacak ürünü elde etme süreci yürütülmüş olur. Süreç boyunca tüm varsayımlar tekrar tekrar doğrulanır. Bir metrik veya pratik artık geçerli değilse çöpe atılır. Kısa iterasyonlar sonunca geri beslemeler alarak ürün doğrulama (validation) gerçekleştirilir. Kararlar, mümkün olduğunca ertelenir ve alınması gereken son zamanda alınır. Bu şekilde kesinleşmemiş kararlara uygun atık işlemlerle gereksiz yere uğraşılmamış olunur.

5 Kanban Kanban, üretim operasyonlarından ödünç alınmış adaptif, görsel ve maliyet odaklı bir tekniktir. Toyota tarafından 1950 lerden beri kullanılmasına rağmen, yazılım geliştirme alanında uygulaması ilk kez, 2004 yılında David J. Anderson tarafından, Microsoft firmasında küçük bir takımla çalışırken yaşanan problemlerin giderilmesi için gerçekleştirilmiştir (Ahmad vd., 2013). Kanban ın arkasındaki fikir yalın (lean) düşünceden gelmektedir. İş akışını görselleştirmek, üzerinde çalışılan işleri sınırlamak (limit Work In Progress [WIP]) ve döngü süresini ayarlamak Kanban yönteminin ana felsefesidir. Yöntemde yapılan ve yapılacak işler Kanban Board denilen bir tahtada görselleştirilir. Bu şekilde tüm takım ve müşteri; işlerin durumunu, önceliklerini ve darboğazları görerek hareket eder. Bu tahtada soldan sağa; yapılacak işler, yapılmakta olan işler ve testi geçen işler kağıtlara yazılmış şekilde bulunmaktadır. Süreç boyunca bu kağıtlar (yapılacak işlerin anlatıldığı hikayeler) soldan sağa doğru hareket ederler. Bununla birlikte amaçlardan biri WIP i mümkün olduğunca küçük tutmaktır. Böylece geliştiriciler verilen bir zaman aralığında sadece bir işe odaklanır ve müşteri de o zaman aralığı sonunda ne elde edeceğini bilir. Zaman baskısı konusunda Scrum dan farklıdır. Kısa geri besleme çevrimleri ile sürece hızlı adapte olmayı hedefler. Kanban kullanmanın anahtar güdüsü zorlayıcı iterasyonlara değil, akışa odaklanmaktır (Ahmad vd., 2013). Kanban yönteminde program kusurları atık olarak görüldüğünden bunun yok edilmesi (en azından minimum hale getirilmesi) hedeflenmektedir. Program kusurundan kaynaklanan atığın miktarı, kusurun ürüne etkisi ve farkedilememe süresi olarak görülür. Üç dakika içerisinde farkedilmiş bir kritik kusur büyük bir atık kaynağı olarak sayılmaz. Haftalarca farkedilememiş küçük bir kusur ise daha büyük bir atık olarak sayılır. Kusurların etkilerini azaltmanın yolu, oluşur oluşmaz onları bulmaktır. Böylece kusurlar yüzünden harcanan zamanı azaltmak için kod yazarken anında test, sık sık entegrasyon ve mümkün olduğunca çabuk sürüm yayınlanması yapılır (Poppendieck ve Poppendieck, 2003). Bununla birlikte son zamanlarda Scrum ve Kanban ın bazı özelliklerinin bir araya getirildiği Scrumban isimli hibrit bir çevik yöntem çalışmalarına rastlanmaktadır. Bu yöntemde Kanban yönteminde olduğu gibi işler yapılacaklar tahtasına alınır ama farklı olarak bazı işler için zaman sınırı olduğunu gösterir farklı renkte kâğıtlar kullanılır (Reddy, 2014). FDD FDD, yazılım geliştirme yaşam döngüsünde sadece tasarım ve geliştirme aşamalarını etkileyen çevik ve adaptif bir yazılım geliştirme yöntemidir. Beş adet sıralı ana aktivitesi vardır: tüm sistemi modelleme, özellik listesi hazırlama, özellikleri planlama, özelliğe göre tasarım ve özelliğe göre geliştirme. Sistemin modelleme aşamasında, takım üyeleri ve uzmanlar sistem için bir yol planı hazırlar. İkinci aşamada gerekli özellikler tüm tarafların anlayabileceği basitlikte parçalara bölünür. Üçüncü aşamada tasarım paketleri adı verilen bu parçalar önceliklendirilir ve her bir parça, bir kaç programcıdan sorumlu bir şef programcıya atanır. Özelliğe göre tasarım aşamasında sürecin iteratif kısmı başlar. Şef programcı kendisine atanmış tasarım paketinden 1-2 hafta içerisinde yapılabilecek bir alt iş seçer. Geliştirme aşamasında bu alt iş yeniden ayrıntılı olarak analiz edilir tasarlanır, kodlanır, test edilir ve entegre edilir (Palmer ve Felsing, 2001). Diğer çevik yöntemlere kıyasla çok büyük ve kritik projelerde kullanılabilmektedir. Tüm süreç boyunca kalite hususuna ağırlık verir. FDD yönteminde, kod yazıldıktan sonra birim testi ve kod inceleme alt süreçlerine geçilir. Hangisinin önce yapılacağına şef programcı karar verir. Birim testinin nasıl yapılacağına dair sınırlama yoktur. Manuel veya otomasyon aracılığı ile yapılabilir. Kod inceleme FDD için zorunlu bir uygulamadır ve bunun için kod yazma süresinin yaklaşık dörtte biri kadar süre ayrılır. Kod inceleme, iyi bir şekilde yapıldığında test etmekten daha fazla ve çeşitli yazılım kusurlarını bulabilmektedir (McConnell, 2004). Bu inceleme sadece geliştirici tarafından yapılmakla kalmayıp, takım içindeki tecrübeli programcılar tarafından da yapılır. Böylece yeni programcıların gelişmesine yardımcı olacak bir süreç olarak da görülebilir. Bununla birlikte, program kodlarının inceleceğini bilmek, programcıların daha dikkatli ve standartlara uygun kod yazmalarını sağlar. Kod incelemenin formalite seviyesi, iterasyonda geliştirilen özelliğin etki ve karmaşıklığına göre şef programcı tarafından tespit edilir. Önem ve karmaşıklık seviyesi düşük işler şef ve takım tarafından incelendiği halde, daha önemli ve karmaşık kod incelemelerinde diğer şef programcılar ve bazen diğer takımlardan programcılar da davet edilir. Bu şekilde XP programlamada yapılan çift (iki kişi) programlama pratiğinden daha iyi bir sonuç elde edilir. Burada programcıya koda bir süre sonra yeniden bakmasıyla kod optimizasyonu yapma şansı verilmekle birlikte, kodlara farklı gözlerin bakması ve fikir yürütmesi ile çok daha iyi, hızlı ve optimal kodların elde edilmesi mümkün olabilmektedir. Bu aşamalardan sonra eldeki kod, entegrasyona hazır hale gelir (Flora ve Chande, 2014; Palmer ve Felsing, 2001).

6 DSDM 1994 yılında çok sayıda proje uzmanı tarafından Hızlı Uygulama Geliştirme (Rapid Application Development [RAD]) için kaliteyi hedeflemek amacıyla geliştirilen ve 1995 de (Millington ve Stapleton, 1995) tarafından tanımlanan bir iskelettir (framework) (Flora ve Chande, 2014). İlk çevik yöntem olan bu framework, proje ürün yönetimi yaşam döngüsünün en iyi süreçlerini birleştiren iteratif ve artırımlı bir metodolojidir. Sonuçlara hızlı ve efektif olarak ulaşmayı sağlayarak, zaman, maliyet, risk ve kaliteyi kontrol altında tutup iş faydalarını artırımsal olarak ulaştırmayı sağlamak, stratejik amaçtır. Kullanıcının aktif katılması, takımların güçlendirilmesi (empowering), kaliteyi en iyilemekten ziyade sürümlerin hızlı ulaştırışlması, geliştirme sırasında herhangi bir değişikliğin geri alınabilmesi, en üst seviye ihtiyaçların değişmemesi, tüm paydaşların birlikteliği ve iyi haberleşmesi ile tüm proje boyunca testin yapılması bu yöntemin prensipleridir. Zaman kutuları (Time boxing), MoSCoW, Prototipleme, Test, İmalat ve Modelleme, bu yöntemde kullanılan temel tekniklerdir. Framework dâhilinde ön-proje, fizibilite çalışması, iş çalışması, fonksiyonel model iterasyonu, tasarım ve geliştirme iterasyonu, uygulama ve proje sonu aşamaları gerçekleştirilir (Cohen vd., 2004; Millington ve Stapleton, 1995). Fonksiyonel model iterasyonunda, dökümanlar gözden geçirilip, prototip sergilenerek ve yazılım parçasının başarılı bir şekilde test edildiği kanıtlanarak, işin doğru yapıldığı (verification) ispat edilir. Burada ürünün fonksiyonelliğe katkısı üzerinde odaklanılır. Fonksiyonel olmayan hususlar, tasarım ve gerçekleştirme aşamalarında test edilir. Kullanıcının aktif katılması, kabul testinin hızlıca geçilmesini sağlar. DSDM test araçlarının kullanımını savunmaktadır. Yakalama ve yeniden oynama (capture and replay) araçları ile testlerin yapılması, kanıtlama için iyi bir yol olmakla birlikte, kağıda geçirilmesinden daha az zahmetli bir işlem olarak görülür. Kod inceleme DSDM de de önerilen bir pratiktir. Dinamik analiz araçları, demo sırasında dizi boyutları, hafıza kullanımı gibi hususları test etmek için kullanılabilmektedir (Millington ve Stapleton, 1995). ASD ASD, yüksek hızlı ve çok değişen internet ekonomisi için geliştirilmiş bir yazılım geliştirme yöntemidir. Yüksek hızlı ve çok değişimli projeler, tahmin edilemez ve geleneksel yöntemlerle işlenemeyecek kadar karmaşıktır. Bu nedenle geliştirme organizasyonunun adaptif olması, yeni değişimlere hızlı cevap vermesi gerekir. Sürekli prototip geliştirerek iteratif ve artırımsal geliştirmeyi teşvik eder. Yöntemde kaosun sınırında dengeleme mantığı ile, yeterli klavuzluk ile projelerin kaosa düşmesi engellenebilir düşüncesi temeldir. Bu yöntemde proje üç fazda değerlendirilir: tahmin etmek (speculate), işbirliği yapmak (collaborate) ve öğrenmek (learn). Belirsizliğin az olduğu durumlarda yapılan plan yerine, bu yöntemde tahmin yapılır. Birlikte çalışma hızla değişen sistem geliştirmede oldukça önemlidir. Hatalardan bilgi üretme ve geliştirme sırasındaki ihtiyaç değişimlerini sağlamak öğrenme fazıdır. Proje başlama, adaptif çevrim planlama, eşzamanlı özellik geliştirme, kalite gözden geçirme ve final kalite güvence-sürüm yayınlama olmak üzere beş genel adımdan oluşur. Kalite gözden geçirme ile çevrim planlama arasında öğrenme geri beslemesi bulunmaktadır (Highsmith, 2000). Müşterinin geliştirme aşamasında bulunması ile Ortak Uygulama Geliştirme (Joint Application Development [JAD]) temeldir. Bu durum kabul testini kolayca geçmeyi sağlar. İlk kez tecrübe edilen işler ve araştırma geliştirme faaliyetleri için bu yöntemdeki öğrenme geri beslemesi oldukça önem arz etmektedir. Bu geri besleme ile birlikte ürün testi gerçekleştirilmiş olup, müşterinin bakış açısından ve teknik bakış açısından incelemeler yapılır. Bu incelemeler ile birlikte takım, performansını değerlendirme imkanı bulur. Ayrıca JAD oturumlarında tüm paydaşların projenin anlık durumunu gözden geçirme fırsatı olur (Abrahamsson vd., 2002; Highsmith, 2000). SONUÇ VE ÖNERİLER Bu bölümde, çevik yazılım geliştirme yöntemleri ile gerçekleştirilen yazılım geliştirme projelerinde başarı şansını artırabilmek için, literatürdeki ve yazarların tecrübeleri ile elde edilen test pratikleri verilmektedir. Bu kapsamda: Projenin tamamı için bir test master test planı ve her entegrasyon seviyesi için bir seviye test planı hazırlanıp, süreçler bu planlara uygun sürdürülmelidir, Test bir faz olarak değil, tüm süreç boyunca yürütülecek; planlama, uygulama ve kontrol aşamalarını içeren bir süreç olarak görülmelidir, Test özel olarak hazırlanmış test ortamlarında gerçekleştirilmelidir, İterasyonlarda test güdümlü hareket edilmelidir, Geliştirilen yazılım, hata oluşma durumlarını günlük dosyalarına kaydetmelidir, Hem el ile (manuel) hemde otomatik test araçları kullanılmalıdır. Hangi aşamalarda hangisinin kullanılacağını takım lideri ve programcılar birlikte kararlaştırmalıdır, Entegrasyonda eksik parçaların fonksiyonunu sağlamak için koçan (stub) yazılım bileşenleri hazırlanmalıdır,

7 Test gereksiz bir işlem, vakit kaybı veya sıkıcı bir bürokrasi olarak görülmemeli, projenin gelişimi için bir araç olarak görülmelidir, Mümkün olduğunca geliştirme sürecinde takımın aynı fiziksel ortamda bulunması sağlanmalıdır, Test sadece test edicilerin (tester) görevi değildir. Tüm ekibin bunun bilincinde olması sağlanmalıdır, Testin sadece hatalardan arınmayı ifade etmediği, bakım ve onarımı da kolaylaştırdığı bilinmelidir, Dökümantasyon gereğinden ne az, ne de çok olmalıdır. Kağıt kullanımı yanında kayıt ve oynatma araçları kullanımı ihmal edilmemelidir, Sık sürüm yayınlama ve müşteri testleri ile geri besleme sağlanması, gereksiz zaman kayıplarını azaltacaktır. Test işlemleri sadece hataları düzeltmeyi değil, öğrenmeyi de sağlar, Test personeli kritik süreçlere dahil edilmelidir, Test sonucu görülebilecek her hata iterasyonu başa döndürmez, durumun kullanıcıların önceliklerine sunulması gerekir, Test sonuçlarına göre hata seviyeleri yüksek ise, takımın motivasyonu ve çalışma saatları gibi yönetimsel hususların yeniden gözden geçirilmesi gerekir. KAYNAKLAR Abrahamsson, P., Salo, O., Ronkainen, J. ve Warsta, J. (2002). Agile software development methods review and analysis. VTT Publications, (478), Abrahamsson, P., Warsta, J., Siponen, M. T. M. T., Ronkainen, J. ve Ronkanen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. Software Engineering, Proceedings. 25 International, 6, Ahmad, M. O., Markkula, J. ve Ovio, M. (2013). Kanban in Software Development: A Systematic Literature Review. Software Engineering and Advanced Applications (SEAA), th EUROMICRO Conference on, (September 2013), Beck, K. (1999). Embracing change with extreme programming. IEEE Computer, 32(10), Beck, K., Cockburn, A., Jeffries, R. ve Highsmith, J. (2001). Agile Manifesto. Agile Manifesto. Bissi, W., Serra Seca Neto, A. G. ve Emer, M. C. F. P. (2016). The effects of test driven development on internal quality, external quality and productivity: A systematic review. Information and Software Technology, 74, Campanelli, A. S. ve Parreiras, F. S. (2015). Agile methods tailoring A systematic literature review. Journal of Systems and Software, 110, Capgemini, HP ve Sogeti. (2015). World Quality Report Cohen, D., Lindvall, M. ve Costa, P. (2004). An Introduction to Agile Methods. Advances in Comp., 62, Dingsøyr, T., Nerur, S., Balijepally, V. ve Moe, N. B. (2012). A decade of agile methodologies: Towards explaining agile software development. Journal of Systems and Software, 85(6), Flora, H. K. ve Chande, S. V. (2014). A Systematic Study on Agile Software Development Methodologies and Practices. International Journal of Computer Science and Information Technologies (IJCSIT), 5(3), Galin, D. (2004). Software quality assurance: from theory to implementation. Pearson. Hariprasath, P. (2015). Software Testing: 100+ Testing Approaches. HARIPRASATH P. Highsmith, J. (2000). Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Journal of Evolutionary Biology (C. 12). McConnell, S. C. (2004). Code Complete 2nd Edition. Programming. Millington, D. ve Stapleton, J. (1995). Developing a RAD standard. IEEE Software, 12(5), Palmer, S. R. ve Felsing, M. (2001). A Practical Guide to Feature-Driven Development. Pichler, R. (2010). Agile Product Management with Scrum: Creating Products that Customers Love. AddisonWesley Professional. Poppendieck, M. ve Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Thinking. Reddy, A. (2014). The Scrumban Revolution. Igarss Schmidt, C. (2016). Agile Software Development Teams. Schwaber, K. (1995). Scrum development process. Proceedings of the Workshop on Business, Spillner, A., Linz, T. ve Schaefer, H. (2014). Software Testing Foundations. Heidelberg, Germany. Version One Inc. (2016). The 10th Annual State of Agile Report. West, D. ve Grant, T. (2010). Agile Development: Mainstream Adoption Has Changed Agility. Forrester Research, Inc., 1 20.