Yazılım test günlüğü yazı serimin bu haftaki yazımızın konusun yazılım geliştirme modelleri. Test tek başına ayakta kalamaz, testin var olabilmesi için bir geliştirmenin yapılıyor olması gerekir. Bundan dolayıdır ki test adımları yazılım geliştirme adımları ile iç içe girmiş durumdadır. Bir proje için kabul edilen geliştirme süreci, proje amaç ve hedeflerine bağlıdır. Farklı hedefleri gerçekleştirmek için geliştirilen sayısız geliştirme yaşam döngüsü vardır.

Bu yaşam döngüleri, piyasaya arzın vazgeçilmez olduğu hafif ve hızlı metodolojilerden, kalite ve güvenilirliğin anahtar konumunda olduğu tamamen denetlenmiş ve belgelenmiş metodolojilere kadar uzanır. Bu metodolojilerin her biri modern yazılım geliştirme süreçleri olup en uygun geliştirme süreci seçilerek projeye mutlaka uygulanmalıdır. Modeller, yazılım geliştirme sürecinin çeşitli aşamalarını ve gerçekleştirildikleri sırayı belirtir. Bir proje için kabul edilen yaşam döngüsü modeli gerçekleştirilecek testleri etkiler; planlanan testlerimizin ne, nerede ve ne zaman yapıldığını tanımlar, regresyon testini ve hangi test tekniklerinin kullanılacağını büyük oranda belirler.

Testin düzenlenmesi, yazılım geliştirme yaşam döngüsüne uymalıdır. Her yazılım geliştirme yaşam döngüsünde, testlerin bir kısmı onaylama (validation) testine odaklanırken bir kısmı doğrulama (verification) testine odaklanır. Doğrulama, bir çalışma ürününün, bileşeninin veya sistemin, belirlenen gereklilikleri karşılayıp karşılamadığını belirlemek için yapılır. Onaylama ise bir çalışma ürününün, bileşeninin veya sistemin, kullanıcı ihtiyaçlarını ve gereksinimlerini karşıladığını belirlemek için yapılır.

V Modeli ( Sıralı Yazılım Geliştirme Modeli):

V modelinin farklı çeşitleri olsa da en yaygın kullanılan çeşidi, dört geliştirme seviyesine karşılık gelen dört test seviyesinin kullanımıdır. Waterfall modelin geliştirilmesiyle ortaya çıkmıştır.

Bu ders programında ele alınan dört test seviyesi şöyledir:

• Bileşen (birim) testi: Ayrı test edilebilen yazılım bileşenlerinin (örn. modüller, programlar, nesneler, sınıflar vb.) işleyişinde kusurlar arar ve doğrular.
• Entegrasyon testi: Bileşenler arasındaki arabirimleri test eder, bir işletim sisteminin, dosya sistemi ve donanım gibi bir sistemin farklı bölümlerine veya sistemler arasındaki arabirimler arasındaki etkileşimleri kapsar.
• Sistem testi: Bir geliştirme projesinin veya ürünün kapsamına göre tanımlandığı şekliyle tüm sistem / ürünün davranışı ile ilgilenir. Sistem testinin odak noktası, belirtilen gereksinimlere karşı doğrulama yapılmasıdır.
• Kabul testi: Kullanıcı ihtiyaçlarına, gereksinimlere ve sistemin kabul edilip edilmemesi konusunda karar verilen iş süreçlerine göre yapılan doğrulama testidir.

Uygulamada, projeye ve yazılıma bağlı olarak V modelinin daha fazla, daha az veya farklı geliştirme ve test seviyeleri olabilir. Örneğin, bileşen testinden sonra bileşen entegrasyon testi, sistem testinden sonra sistem entegrasyon testi olabilir.

Yazılım geliştirme sırasında üretilen ürünler (iş senaryoları veya kullanım senaryoları, gereksinimler, tasarım belgeleri ve kod vb.) genellikle bir veya daha fazla test seviyesinde test esasını oluşturur. Ürünlerin tanımlanmasına yönelik verilebilecek referanslar arasında Entegre Yetenek Olgunluk Modelini (CMMI) veya “Yazılım yaşam döngüsü süreçlerini” (IEEE/IEC 12207) sayabiliriz. Doğrulama ve sağlama (ve erken test tasarımı), yazılım ürünlerinin geliştirilmesi sırasında da gerçekleştirilebilir.

Döngüsel-Artımlı Geliştirme Modelleri:

Döngüsel-artımlı geliştirme, kısa geliştirme döngüleri boyunca gereksinimleri çıkarma, yazılımı tasarlama, geliştirme ve test etme sürecidir. Örnek olarak Hızlı Uygulama Geliştirme (RAD), Rational Unified Process (RUP) ve Çevik (Agile) geliştirme modelleri verilebilir. Bu modeller kullanılarak üretilen bir yazılım, her bir döngü sırasında çeşitli test seviyelerinde test edilebilir. Daha önce geliştirilen kısma eklenen bir aşama, büyüyen kısmi bir sistem oluşturur ve bu sistemin de test edilmesi gerekir. Regresyon testi, ilk döngüden başlayarak sonraki tüm döngülerde artan bir önem taşır. Doğrulama ve sağlama her bir aşamada gerçekleştirilebilir.

Hızlı Uygulama Geliştirme (RAD):

Hızlı Uygulama Geliştirme  resmi olarak işlevlerin paralel bir gelişimi ve sonraki entegrasyonudur. Bileşenler / işlevler, mini projeler gibi paralel olarak geliştirilir. Gelişmeler zaman kutusuna konulmuş, teslim edilmiş ve daha sonra çalışan bir prototip haline getirilmiştir.

Çevik (Agile) Geliştirme:

Aşırı Programlama (Extreme Programming, XP) halen en tanınmış çevik geliştirme yaşam döngüsü modellerinden biridir. Geleneksel gelişim yöntemlerinden daha insana dost olduğunu iddia ediyor. XP’nin bazı özellikleri şunlardır:

• İşlevselliği tanımlamak için iş hikayelerini üretmeyi teşvik eder.
• Sürekli geribildirim için bir yerinde müşteri talep eder ve fonksiyonel kabul testlerini tanımlar ve yerine getirir.
• Geliştiriciler arasında eşli programlamayı ( pair programming ve paylaşılan kod sahipliğini (shared code ownership) destekler.
• Bileşen test komut dosyalarının kodun yazılmasından önce yazılması ve bu testlerin otomatikleştirilmesi gerektiğini belirtir.
• Kodun entegrasyon ve testinin günde birkaç kez gerçekleşebileceğini belirtir.
• Bugünün sorunlarını karşılamak için her zaman en basit çözümü uygulamayı öngörür.

Kodda her değişiklik yapıldığında, bileşen test edilir ve varolan kod ile entegre edilir ve daha sonra bu test durumları kullanılarak tam entegrasyon testine tabi tutulur. Bu sayede sürekli entegrasyon sağlanır ve değişikliklerin yazılım yapısına sürekli olarak dahil edilmelidir.

Yaşam Döngüsü Modeli İçinde Test:

Tüm yaşam döngüsü modellerinde iyi test etme pratiğinin birtakım özellikleri vardır:

• Her geliştirme aktivitesi için buna karşılık gelen bir test etme aktivitesi vardır.
• Her bir test seviyesinde bu seviyeye özgü test hedefleri bulunur.
• Belirli bir test seviyesi için testlerin analizi ve tasarımı karşılık gelen geliştirme akivitesi sırasında başlamalıdır.
• Dokümanlar belli bir olgunluğa geldiği anda test uzmanları tarafından gözden geçirilmelidir

Projenin doğasına veya yazılım mimarisine bağlı olarak test seviyeleri birleştirilebilir veya yeniden düzenlenebilir. Örneğin, ticari bir paket yazılımın (COTS) bir sisteme entegre edilmesi için, sistem seviyesinde entegrasyon testi (örn. altyapıya veya diğer sistemlere entegrasyon ya da sistem dağıtımı) ve kabul testi (fonksiyonel ve/veya fonksiyonel olmayan ve kullanıcı ve/veya operasyonel test) gerçekleştirilebilir.

1. ISTQB Foundation Level Syllabus
2. FOUNDATIONS OF SOFTWARE TESTING ( Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black)