Bir önceki yazımda “yazılım kalitesi” başlığıyla kaliteli yazılım geliştirme üzerine bir giriş yapmıştım. Şimdiyse kaliteli yazılımın “test” boyutunu çok genel olarak inceleyelim diyorum.
Yazılım testinin amacı; ortaya çıkartılan ürünün, proje başında belirlenen gereksinimleri karşılayıp karşılamadığının belirlenmesidir. Bunun için uygulama denetlenebilir/izlenebilir bir ortamda çalıştırılır ve olması gerekenlerin olduğu, olmaması gerekenlerin olmadığı ve gerekli güvenlik, performans, kullanım koşullarına uygun olup olmadığına bakılır.
Peki, bu “test” dediğimiz şey nasıl yapılır?
Günümüzde yazılım kalitesi gittikçe önem kazanmaya başladı ve önem kazandıkça test alanındaki başlıklar gittikçe arttı. Bugün artık kurumların yazılım geliştirme süreçlerini ölçen CMMI (Capability Maturity Model Integration - Yetenek Olgunluk Model Entegrasyonu) gibi, sadece test süreçleri için belge veren TMMI (Test Maturity Model Integrated – Entegre Test Olgunluk Modeli) ‘dan bahsetmeye başladık.
TMMI, kurumun test konusundaki olgunluğunu 3 seviyeyle değerlendirir. Birinci seviye “işler bir şekilde yapılıyor” seviyesidir. Test yapan yapmayan herkes bu seviyede kabul edilir. Asıl amaç 2 ya da 3. Seviyeyi almaktır. İkinci seviye “yönetilen” olarak tabir edilir. Bu kurumda testler yönetiliyor anlamına gelmektedir. Bu seviyeye ulaşmak için tamamı belgelerle desteklenmiş olan ve işletilen aşağıdaki başlıkları tanımlamış ve uyguluyor olmalısınız.
- Test Politikaları ve Stratejileri
- Test Planları
- Test İzleme ve Kontrol Süreçleri
- Test Tasarımı ve İşletilmesi
- Test Ortamı
Bunları gerçekleştirdikten sonra bir üst seviye olan “tanımlı” aşamasına çıkmak içinse aşağıdaki başlıkların hayata geçirilmesi gerekir.
- Test Organizasyonu
- Test Eğitim Programı
- Test Yaşam Döngüsü ve Entegrasyonuna
- İşlevsel Olmayan Test Yönetimi
- Eşler arası Gözden Geçirme
Bu konuda daha fazla bilgi almak için http://www.tmmifoundation.org sitesini ziyaret edebilirsiniz.
Günümüzde yazılım kalitesi gittikçe önem kazanmaya başladı ve önem kazandıkça test alanındaki başlıklar gittikçe arttı. Bugün artık kurumların yazılım geliştirme süreçlerini ölçen CMMI (Capability Maturity Model Integration - Yetenek Olgunluk Model Entegrasyonu) gibi, sadece test süreçleri için belge veren TMMI (Test Maturity Model Integrated – Entegre Test Olgunluk Modeli) ‘dan bahsetmeye başladık.
TMMI, kurumun test konusundaki olgunluğunu 3 seviyeyle değerlendirir. Birinci seviye “işler bir şekilde yapılıyor” seviyesidir. Test yapan yapmayan herkes bu seviyede kabul edilir. Asıl amaç 2 ya da 3. Seviyeyi almaktır. İkinci seviye “yönetilen” olarak tabir edilir. Bu kurumda testler yönetiliyor anlamına gelmektedir. Bu seviyeye ulaşmak için tamamı belgelerle desteklenmiş olan ve işletilen aşağıdaki başlıkları tanımlamış ve uyguluyor olmalısınız.
- Test Politikaları ve Stratejileri
- Test Planları
- Test İzleme ve Kontrol Süreçleri
- Test Tasarımı ve İşletilmesi
- Test Ortamı
Bunları gerçekleştirdikten sonra bir üst seviye olan “tanımlı” aşamasına çıkmak içinse aşağıdaki başlıkların hayata geçirilmesi gerekir.
- Test Organizasyonu
- Test Eğitim Programı
- Test Yaşam Döngüsü ve Entegrasyonuna
- İşlevsel Olmayan Test Yönetimi
- Eşler arası Gözden Geçirme
Bu konuda daha fazla bilgi almak için http://www.tmmifoundation.org sitesini ziyaret edebilirsiniz.
Test Türleri Nelerdir?
Testle ilgili genel bir kavrayış sağlamak için bir de “test türleri”ne bakmak lazım. Bu başlık altında testlere teker teker değinmektense, genel olarak testlerin sınıflandırılması ve test yaklaşımları konularına değineceğim. (En yaygın kullanılan testlerle ilgili bir başka yazıyı ilerleyen günlerde yazmayı planlıyorum.)
Testle ilgili genel bir kavrayış sağlamak için bir de “test türleri”ne bakmak lazım. Bu başlık altında testlere teker teker değinmektense, genel olarak testlerin sınıflandırılması ve test yaklaşımları konularına değineceğim. (En yaygın kullanılan testlerle ilgili bir başka yazıyı ilerleyen günlerde yazmayı planlıyorum.)
Kutu Yaklaşımı
Kutu yaklaşımı, test mühendislerinin testi geliştirirken ve test gerçekleştirilirken hangi açıdan baktıklarıyla ilgilidir. Bu bakış açısı kodun, algoritmanın, içsel bileşenlerin (değişken, yapılar, veriler, vb.) mi yoksa sadece girdi ve çıktıların mı göz önünde tutularak testin yapılacağıyla ilgilidir. Temel olarak “kara kutu” ve “beyaz kutu” yaklaşımlarından bahsedilir. Ancak son günlerde bir de “gri kutu” yaklaşımından bahsedilmeye başlanmıştır.
Kara kutu yaklaşımı; adı üzerinde işlevi kapalı bir yapı olarak kabul eder ve içsel olarak neye sahip olduğu veya ne yaptığıyla ilgilenmez. Sadece verilen girdiler için doğru çıktılar üretiliyor mu? Diye bakar.
Beyaz kutu yaklaşımı; işlevin doğru çalışmasının yanında, içsel değişkenlerini ve algoritmasının da doğru/uygun olup olmadığını denetler.
Gri kutu yaklaşımı; testin tasarımıyla ilgilidir. Gri kutu testleri aynı kara kutu gibi uygulanır. Ancak test tasarlanırken işlevin içsel veri ve algoritma yapısı da göz önünde bulundurulmaktadır.
Kutu yaklaşımı, test mühendislerinin testi geliştirirken ve test gerçekleştirilirken hangi açıdan baktıklarıyla ilgilidir. Bu bakış açısı kodun, algoritmanın, içsel bileşenlerin (değişken, yapılar, veriler, vb.) mi yoksa sadece girdi ve çıktıların mı göz önünde tutularak testin yapılacağıyla ilgilidir. Temel olarak “kara kutu” ve “beyaz kutu” yaklaşımlarından bahsedilir. Ancak son günlerde bir de “gri kutu” yaklaşımından bahsedilmeye başlanmıştır.
Kara kutu yaklaşımı; adı üzerinde işlevi kapalı bir yapı olarak kabul eder ve içsel olarak neye sahip olduğu veya ne yaptığıyla ilgilenmez. Sadece verilen girdiler için doğru çıktılar üretiliyor mu? Diye bakar.
Beyaz kutu yaklaşımı; işlevin doğru çalışmasının yanında, içsel değişkenlerini ve algoritmasının da doğru/uygun olup olmadığını denetler.
Gri kutu yaklaşımı; testin tasarımıyla ilgilidir. Gri kutu testleri aynı kara kutu gibi uygulanır. Ancak test tasarlanırken işlevin içsel veri ve algoritma yapısı da göz önünde bulundurulmaktadır.
Düzeylerine Göre Testler
Testleri gruplandırmak için kullanılabilecek başka bir bakış açısı da testin yazılım geliştirme sürecine dahil olduğu aşamadır. Bu bakışa göre yazılım testleri aşağıdaki gibi sınıflandırılabilir:
- Unit Test – Birim Testi
- Integration Test – Tümleştirme Testi
- System Test – Sistem Testi
- System Integration Test – Sistem Tümleştirme Testi
- Regression Test – Regresyon Testi
- Acceptance Test – Kabul Testi
- Alpha Test – Alfa Test
- Beta Test
Testleri gruplandırmak için kullanılabilecek başka bir bakış açısı da testin yazılım geliştirme sürecine dahil olduğu aşamadır. Bu bakışa göre yazılım testleri aşağıdaki gibi sınıflandırılabilir:
- Unit Test – Birim Testi
- Integration Test – Tümleştirme Testi
- System Test – Sistem Testi
- System Integration Test – Sistem Tümleştirme Testi
- Regression Test – Regresyon Testi
- Acceptance Test – Kabul Testi
- Alpha Test – Alfa Test
- Beta Test
İşlevsel / İşlevsel Olmayan Testler
Testler işlevselliği mi yoksa performans, güvenlik, kullanım kolaylığı gibi direkt işlevsel olmayan ama yazılım kalitesini etkileyecek unsurları mı test edip etmediğine bağlı olarak da işlevsel ve işlevsel olmayan testler olarak ikiye ayrılabilirler. İşlevsel olmayan testlerden bazıları şöyledir:
- Performance Test – Başarım Testi
- Load Test – Yük Testi
- Stability Test – Kararlılık Testi
- Usabilitiy Test – Kullanışlılık Testi
- Security Test – Güvenlik Testi
- Internationalization and Localization Test – Uluslar arası ve Yerel Kullanıma Uygunluk Testi
Testler işlevselliği mi yoksa performans, güvenlik, kullanım kolaylığı gibi direkt işlevsel olmayan ama yazılım kalitesini etkileyecek unsurları mı test edip etmediğine bağlı olarak da işlevsel ve işlevsel olmayan testler olarak ikiye ayrılabilirler. İşlevsel olmayan testlerden bazıları şöyledir:
- Performance Test – Başarım Testi
- Load Test – Yük Testi
- Stability Test – Kararlılık Testi
- Usabilitiy Test – Kullanışlılık Testi
- Security Test – Güvenlik Testi
- Internationalization and Localization Test – Uluslar arası ve Yerel Kullanıma Uygunluk Testi
Statik/Dinamik Testler
Testlerle ilgili son olarak “statik test” kavramına değinmek istiyorum. Şu ana kadar konuştuğumuz testlerin hepsi, kodun çalışır hali üzerinden yapılırken, kodu çalıştırmadan okuyarak, inceleyerek ya da adım adım nasıl çalışacağını takip ederek yapılan testler de vardır. Bunlar genelde statik kod analizi diye bilinirler. Statik test türlerinden bazıları da şöyledir:
- Software inspection
- Code walk-through
- Code review
Testlerle ilgili son olarak “statik test” kavramına değinmek istiyorum. Şu ana kadar konuştuğumuz testlerin hepsi, kodun çalışır hali üzerinden yapılırken, kodu çalıştırmadan okuyarak, inceleyerek ya da adım adım nasıl çalışacağını takip ederek yapılan testler de vardır. Bunlar genelde statik kod analizi diye bilinirler. Statik test türlerinden bazıları da şöyledir:
- Software inspection
- Code walk-through
- Code review
Sonuç:
Kaliteli yazılımlar üretebilmek için yazılım geliştirme sürecimizin tanımlı olması hatta bununla birlikte test sürecimizin de tanımlı olması temel koşuldur. Bundan sonrasında da ürün bazında kalite için o ürünün testinin en uygun şekilde yapılması gerekir. Test konusunda çalışmalar arttıkça, test uzmanlarımızın sayısı arttıkça ve testin maliyetinin ötesinde yazılıma kattığı değer fark edildikçe daha kaliteli yazılımlar üreteceğimiz açıktır.
Kaliteli yazılımlar üretebilmek için yazılım geliştirme sürecimizin tanımlı olması hatta bununla birlikte test sürecimizin de tanımlı olması temel koşuldur. Bundan sonrasında da ürün bazında kalite için o ürünün testinin en uygun şekilde yapılması gerekir. Test konusunda çalışmalar arttıkça, test uzmanlarımızın sayısı arttıkça ve testin maliyetinin ötesinde yazılıma kattığı değer fark edildikçe daha kaliteli yazılımlar üreteceğimiz açıktır.
Hiç yorum yok:
Yorum Gönder