Software / Yazılım Testi Nedir?

Yazılım geliştirme yaşam döngüsü içerisinde testin önemi yazılımdaki kalitenin seviyesi ile doğru orantılıdır. Test bir bakış açısı ile yazılımın kalitesini arttırmak için önemli bir konudur. Yazılım geliştirme sürecinde bu konu önemsenmeli ve ciddi politikalar belirlenip benimsenmelidir.

Yazılım geliştirme yaşam döngüsü içerisinde bulunan test konusunun ne ve nasıl olması gerektiğine dair konuları aşağıdaki slaytlarda bulabilirsiniz.

SDLC – Software Development Life Cycle Nedir?

Yazılım geliştirmede, sadece çeşitli teknik ve tenkolojileri bilerek kod geliştirmek yeterli değildir. Başta bunun bir süreç olduğunu bilmek gerekmektedir. Yapılan iş bir problemi çözmeye yönelik çalışmalar yapmayı içeriyor ve bu işin nihayetinde bir hedef vardır. Bu hedefe nasıl gidilebileceğine dair çeşitli yöntemler ve pratikler vardır. Aşağıda bu sürecin nasıl olması gerektiğine dair çeşitli yaklaşımları bulabilirsiniz.

Nedir Docker?

dockerKısaca ifade etmek gerekirse sanallaştırma konusunda en temelde olan kaynak kullanımına optimizasyon sağlayan bir araç olarak nitelenebilir. Bunu nasıl yapıyor derseniz; VMWare,VirtualBox vb. gibi araçların çalışma mantığı şöyledir; fiziksel host makinenin kaynaklarını belirtilen ölçülerde kullanarak bir işletim sistemi çalıştırır. İşletim sisteminin de bir yazılım olduğundan belirli ölçülerde memory,cpu vb. kaynağına ihtiyaç duymaktadır. Bu da host makinenin kaynaklarını daha fazla tüketmeye sebep olmakta.

Docker ise şunu diyor; madem amaç ayrıştırılmış kaynaklar üzerinde bir/birkaç uygulamayı yalıtılmış olarak çalışırtırmak ise, bunu ayrıca bir işletim sistemi olmadan da yapabiliriz. Ve dedikleri gibi de yapıyorlar. Docker ile host makine üzerinde uygulamalar birbirlerinden yalıtılmış şekilde çalışabiliyor hale geliyor. Bu sayede uygulamaları yalıtmak, farklı adresler,portlar vermek için ekstra bir işletim sistemi çalıştırmaya gerek kalmıyor. Ve böylece işletim sistemi çalıştırmak için gerekli olan kaynağı amacınıza yönelik kullanabilir hale geliyorsunuz. Aslında buraya kadar olan kısmı daha öncede farklı araçlar ile yapılabiliyordu. Bildiğim Solaris üzerindeki Zone’lar bunu sağlıyordu. Docker’in farkı ise buradan sonra başlıyor. Bu aşamaya kadar yaptığı, bu tarz özellikleri kolay kullanılabilir hale getirmesi.

Docker aslında bir uygulama sanallaştırma aracıdır dersem yanlış olmaz sanırım. Unix/linux sistemler için tasarlanmış, fakat windows üzerinde de kullanabiliyorsunuz. Docker daha önce bu tarz işler için geliştirilen uygulamalar bir araya getirilerek oluşturulmuştur.

Tek yaptığı bu değil tabiki. Başka neler yapabiliyor; sanallaştırmak istediğiniz uygulamalar için configürasyonlar oluşturuyorsunuz(uygulamayı şuradan yükle, bu parametreleri kopyala, şu port ile çalıştır vb.). Bu konfigürasyon dosyalarının build edilmiş haline image deniyor. Image’lar üzerinde değişiklik yapıp değişiklikleri yönetebiliyorsunuz. Bu source versioning aracı olan git’e benziyor. Sonra bu image’ları dockerhub denilen bir repositorye yükleyip herkesin erişip kullanabileceği hale getirebiliyorsunuz. İsterseniz ücretli bir hesap ile dockerhub üzerinde private repolar oluşturabilirsiniz. Oluşturulan bu imajlar her sistemde çalışabilir nitelikte oluyor, bu paket eksik bunun versiyonu farklı gibi sorunları bertaraf ediyor. Geliştirme ortamında çalışan uygulamanın test ve production ortamında da çalışacağını garanti ediyor.

Sonrasında oluşturulan bu imajları container denilen, uygulamaları yalıtabilen sanal ortamlar üzerinde çalıştırıyor. Dockerhub’a yüklediğiniz imajı çalıştırmak için yapmanız gereken docker ortamına pull etmek ve çalıştırmaktır.

Docker için edindiğim izlenimleri yalın bir şekilde paylaşmak istedim 😉 Teknik olarak bu anlattıklarımın nasıl yapıldığına dair ayrıntıları paylaşmaya çalışacağım.

Test Driven Analysis

İş süreçlerimizde analizin çok önemli olduğunu düşünenlerdenim. Maalesef öyle zamanlar geliyor ki işle uğraşmaktan çok, işi verenlerle uğraşmak zorunda kalıyorsunuz. Bu konunun literatürde detaylarını hiç araştırmadım. Ama yaşananlar insana “ya kesinlikle test yönelimli analiz yapılmalı” cümlesini kurdurtuyor.

Neden Böyle? diye sorduğumda…

Analiz eksikliklerinin bence en önemli sebebi yönetimdeki anlayıştır. Birçok yerde kurallar vardır ama büyük oranda bu kurallara uyulmaz. Konulan kurallar da zamanla verimsiz hale gelir. Bir zaman sonra artık bu kurallar sadece denetimlerde gündeme gelir ve sonraki denetime kadar raflarda kalır.

Yukarıda neden en önemli sebep yönetimdeki anlayış dediğimi biraz daha açıklayacak olursam; kimse durup dururken birşeyleri standartlaştırmanın peşine düşmez. Neden kendi kendine kurallar koyup kalıba girsin. Tabiki standartlaşmanın asıl amacı ölçümleyebilmektir. Standart olmayan birşeyi belirli kriterlere göre ölçmek çok zor olsa gerek.

İş süreçlerinizi ölçümleyemezsiniz nerede problem olduğunu göremezsiniz. Bunu göremezseniz işinizi iyileştirip, konforunuzu arttıramazsınız vb…

Tabi böyle bir iyileşmenin ihtiyaç olduğunu anlayabilmek en önemli mesele 🙂 Eğer dünyada/dünyanızda neler olup bittiğini görmüyorsanız, farkında değilseniz, nasıl olsa işler yürüyor öylese sorun yok diyorsanız ilerleme kaydetmek neredeyse imkansız oluyor.

Bunlar iş süreçlerinin daralıp maalesef e-mail ile yürüyen bir akışa kadar inmesine sebep oluyor. Yönetici açısından bakınca; kimse süreci denetlemiyor, işi yapanlarda bir şekilde e-mail içerisindeki söylenenleri yapıyorlar. İşin detayında yirmi kez de değişiklik yapılsa, komple de değişse problem olarak görülmüyor.

Ben bir analist değilim, bu işin eğitimini de almadım. Sadece yaşadıklarıma dayanarak temel düzeyde yorumlar yapıyorum. Bir konuyu analiz etmek, konuyu bütün detayları ile ortaya koyabilmek olmalı. Tüm detayları ortaya koymak demekse konuya kafa yormak, anlaşılmayan noktaları tartışmak, netleştirmek olmalı.

Eğer bu kafa yorma süreci işlemiyorsa iş delik deşik oluyor. Ortaya karmaşık, bakım maliyeti yüksek bir iş çıkıyor. Çünkü iş anlaşılmadan yapılmaya başlanıyor, sonra müşterinin karşısına çıkıyor, müşterinin beklentisini karşılamammış oluyor. Sonra tekrar müşterinin taleplerine göre değişiklikler yapılıyor vb. Bu değişiklikler çok köklü de olabiliyor.

Bu kadar sorunu yaratmak ve yönetmek yerine dikkatli bir analiz süreci ile herkesin memnun olacağı bir iş yürütmek daha mantıklı ve kolay değil mi?

Analizin bir de test driven olduğunu düşünsenizya ne kadar muhteşem olur 🙂 İşi yapanlar sadece kendi işlerini yaparlar, analistlerin işlerini değil.

Adaptive Object Model

Dinamiklik gerektiren ve hızlı değişime ihtiyaç duyan uygulamaların domain modellerini yönetmek için AOM design patterni kullanılabilir. AOM classları,attributeleri,ilişkileri ve classların operasyonlarını metadata olarak saklayıp dinamik olarak kullanmayı sağlar. Kullanıcılar doğrudan metadatayı değiştirerek domain modeli değiştirebilirler. Object modeli ister XML dosyalarında ister databasede saklayabilir ve yönetebilirsiniz.

Bu tasarıma baktığımızda aslında NoSQL databaselerin temel aldığı mantığı yansıtmaktadır. Yani MongoDB gibi NoSql databaselerin temelindeki pattern AOM diyebiliriz.

AOM’u anlatan güzel bir blog girdisi gördüm. Paylaşmak istedim;

Buradan erişebilirsiniz.

Kaynak