Bil 390 - Yazılım Kalite Yönetimi (#4) - Başkent Üniversitesi - PDF
Document Details
Uploaded by IntimateYew1075
Başkent Üniversitesi
2024
Dr. Attila Aşçıoğlu
Tags
Summary
This document from Başkent Üniversitesi details software quality management and the various software testing techniques. It also discusses the costs of software defects.
Full Transcript
BAŞKENT ÜNİVERSİTESİ MÜHENDİSLİK FAKÜLTESİ BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜMÜ BİL 390 - YAZILIM KALİTE YÖNETİMİ (#4) DR. ATİLA AŞÇIOĞLU eyec.baskent.edu.tr...
BAŞKENT ÜNİVERSİTESİ MÜHENDİSLİK FAKÜLTESİ BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜMÜ BİL 390 - YAZILIM KALİTE YÖNETİMİ (#4) DR. ATİLA AŞÇIOĞLU eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ eyec.baskent.edu.tr Genele Açık YAZILIM HATA NEDENLERİ ve MALİYETLERİ Hataların Nedeni İster Belirleme & Analiz ~55% Tasarım ~25% Kodlama ~15% Diğer ~ 5% Hataların Maliyeti "Süreç ne kadar ilerlemişse bulunan hataların düzeltilmesi daha pahalıya mal olur" Bir hatayı düzeltme maliyeti katlanarak artar (10x) Örnek: Gereksinim belirtim sırasında bulunan bir hatayı düzeltme maliyeti 1 USD Tasarımda bulunan hatanın maliyeti 10 USD Kodlama sürecinde bulunan hatanın maliyeti 100 USD Canlıda/Piyasaya sürülen yazılımdaki hatanın maliyeti 1000 USD eyec.baskent.edu.tr Genele Açık YAZILIM TESTİ ve AMACI Projemizde geliştirmiş olduğumuz yazılım veya modülün, doğru bir şekilde çalıştığını veya farklı modüllerin eklenmesi durumda da doğru çalıştığını anlamamızı sağlayan yapılara test veya test süreci adı verilir. Amaç: Müşteriye sunmadan önce ürün kalitesinden emin olmak, Yeniden çalışma ve geliştirme için masrafları azaltmak, Geliştirme yaşam döngüsünün erken aşamalarında hataları saptayarak ileri aşamalara yayılmasını önlemek, böylece zaman ve maliyet tasarrufu sağlamak, Müşteri memnuniyetini arttırmak eyec.baskent.edu.tr Genele Açık YAZILIM TEST SÜRECİ eyec.baskent.edu.tr Genele Açık TEST PLANI Test planlaması genellikle gereksinimler aşamasında başlar. Yazılım projelerinin iş planı dökümanı olarak ele alınabilir. Test projesinin nasıl ilerleyeceği, hangi fazlarda nelerin yapılacağından bahseder. Test planında ana unsurlar: 1. Test kaynaklarının belirtilmesi 2. Test ortamının ve erişim yönteminin belirtilmesi 3. Her test aşaması için hedefler 4. Her test aktivitesi için programlar ve sorumluluklar 5. Araçların ve test kütüphanelerinin mevcudiyeti. 6. Test tamamlama kriterlerinin belirlenmesi eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ Test Senaryosu (Test case) Belirli bir program akışını çalıştırmak ya da bir gereksinim ile uyumluluğunu doğrulamak gibi belirli bir amaç veya test koşulu için geliştirilen, bir dizi girdi değeri, test öncesi yürütülmesi gereken önkoşullar, test sonrası oluşması beklenen sonuçlar ve koşullar bütünü. Test Aracı (Testing Tool) Test yönetimi, test tasarımı, testin yürütülmesi ve sonuçlarının değerlendirilmesi gibi test aktivitelerine yardımcı olmak için kullanılan yazılım. Test Verisi (Test Data) Test edilen yazılımın etkilediği veya yazılım tarafından etkilenen veri. eyec.baskent.edu.tr Genele Açık DOĞRULAMA & GEÇERLEME Özellik Açıklama Doğrulama Ürünü doğru mu oluşturuyoruz? Verification Bir yazılımın hatasız olarak hedefine ulaştığını kontrol etmektir. Geliştirilen ürünün istenen gereksinimleri karşılayıp karşılamadığını doğrular. Doğrulama statik testtir. Yazılımcı veya QA ekibi tarafından gerçekleştirilir. Doğrulama aşamasında bulunan hataların maliyeti daha azdır. (Örnek: Yazılımın iyi bir tasarıma sahip olup olmaması kontrolü) Geçerleme Doğru ürünü mü oluşturuyoruz? Validation Yazılımın standartlara ve gereksinimlere uygun olup olmadığının kontrol edilmesidir. Gerçek ve beklenen ürünün doğrulanmasıdır. Geçerleme dinamik testtir. Test ekibi tarafından gerçekleştirilir. Geçerleme aşamasında bulunan hataların maliyeti daha fazladır. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ Prensipler (i) Tüm testler müşteri gereksinimlerini karşılamalıdır. (ii) Testlerin üçüncü bir taraf/ekip tarafından gerçekleştirilmesi daha sağlıklıdır. (iii) Her süreci kapsayan test mümkün değildir. Uygulamanın risk değerlendirmesine dayalı olarak en uygun test kapsamı belirlenir. (iv) Yapılacak testler, uygulama yazılmadan önce planlanmalıdır. (v) Hataların %80'i program bileşenlerinin %20'sinden gelir. (Pareto 80/20 kuralı) (vi) Teste küçük parçalarla başlanması ve büyük parçalara genişletilmesi önerilir. Başarılılık/Başarısızlık Kriteri (Pass/Fail Criteria) Bir test öğesinin veya özelliğin başarılı veya başarısız olup olmadığını belirlemek için kullanılan karar verme kuralları. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİNİN TÜRLERİ Başlıca Test Türleri: Ayrıca; 1. Birim Testi 12. Gerçek Zamanlı Test 2. Entegrasyon Testi 13. Sınır Değer Analizi 3. Regresyon Testi 14. Taşınabilirlik Testi 4. Smoke Testi 15. Risk Bazlı Test 5. Alfa Testi 16. Maymun Testi 6. Beta Testi 17. Diğer türler… 7. Sistem Testi 8. Stres Testi 9. Performans Testi Yazılım mühendisleri ve test uzmanları tarafından 10. Nesneye Yönelik Test kullanılan çeşitli test türleri vardır. Yüksek verimlilikle 11. Kullanıcı Kabul Testi çalışabilmek, maliyet ve efor tasarrufu yapılabilmek için doğru test türünün kullanılması önemlidir. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİNİN TÜRLERİ 1. Birim Testi (Unit Test) Yazılım tasarımının en küçük birimine odaklanır. Bu test ile, tekil bir birim veya birbiriyle ilişkili birimler grubu test edilir. Genellikle programcı tarafından örnek girdi kullanılarak ve karşılık gelen çıktılarını gözlemleyerek yapılır. Örnek: a) Bir programda döngü (loop), metot veya fonksiyonun doğru çalışıp çalışmadığını kontrol ederiz. b) Yanlış anlaşılmış veya hatalı aritmetik öncelik c) Yanlış değer atama eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ 2. Entegrasyon Testi Bileşenler veya sistemler arasında gerçekleşen etkileşimlerde oluşabilecek hataları açığa çıkarmak için yapılan testtir. 4 türü vardır: 1. Yukarıdan aşağıya (Top-down) 2. Aşağıdan yukarıya (Bottom-up) 3. Sandviç (Sandwich) 4. Büyük Patlama (Big-Bang) Ayrıca: ▪ Kara Kutu testi: Geçerleme için kullanılır. Yazılım iç çalışma mantığını dikkate almaz, çıktının ne olduğuna odaklanılır. ▪ Beyaz kutu testi: Doğrulama için kullanılır. İç mekanizmalara, yani çıktının nasıl elde edildiğine odaklanılır. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ 2. Entegrasyon Testi I. Yukarıdan aşağıya (Top-down) Önce kontrol programı test edilir. Modüller birer birer entegre edilmiştir. Arayüz testi vurgulanır. Avantajlar: Erken bir prototip elde etme imkanı Arayüz hataları erken keşfedilir Modüler özellikler hata ayıklamaya yardımcı olur Dezavantajları: Test taslakları gereklidir Alt seviyelerdeki kritik modüllerin hataları geç bulunur. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ 2. Entegrasyon Testi II. Aşağıdan yukarıya (Bottom-up) Erken testlere izin verilir. Modül işlevselliği ve performans vurgulanır. Avantajlar: Test taslaklarına gerek yoktur Kritik modüllerdeki hatalar erken bulunur Dezavantajları: Test sürücülerine(*) ihtiyaç vardır Arayüz hataları geç keşfedilir Erken bir prototip mümkün değildir (*) Sürücü: hazır olmayan modül/birimlerin yerine testin başarıyla yürütülebilmesi için kullanılan öğedir. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ 2. Entegrasyon Testi III. Sandviç/Hibrit (Sandwich) Modüllerin bir kısmı Top-Down, bir diğer kısmı ise Bottom-Up tiplerini kullanılarak gerçekleştirilen test tipidir. Karma tipteki bu testin amacı bazı modülleri gruplara ayırabilirken diğer modülleri ayrı bir şekilde test edebilmektir. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ 2. Entegrasyon Testi IV. Büyük Patlama (Big-Bang) En yaygın kullanılan entegrasyon test tipidir. Geliştirilmiş tüm modüller bir araya getirilerek yapılan testtir. Hızlı ve kolay bir şekilde birbirleri ile beraber çalıştıklarında anlam ifade eden modüllerin doğruluğunu sağlar fakat birim başı metot doğruluğunun gözden kaçırılması olasıdır. Avantajlar: Küçük sistemler için uygun. Dezavantajları: Hata Lokalizasyonu zordur. Test edilmesi gereken çok sayıda arayüz olduğundan bazı arayüz bağlantıları gözden kaçabilir. Entegrasyon testi ancak "tüm" modüller tasarlandıktan sonra başlayabileceğinden, testin yürütülmesi için daha az zaman kalır. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ 3. Regresyon Testi Yazılım üzerinde yapılan her değişiklik istenmeyen yan etkiler doğurabilir. Yazılımda yapılan geliştirmelerin veya hata düzeltmelerinin düzgün çalıştığından, yazılıma yeni bir hata eklenmediğinden ve mevcut işlevselliği etkilemediğinden emin olmak için regresyon testi yapılır. Genellikle SDLC'nin bakım aşamasında yapılır. Her değişiklik ve hata düzeltmesinin ardından regresyon testleri yapılarak, sistemin bütünlüğü test edilir. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ 4 tip regresyon testi vardır. I. Düzeltici Regresyon testi – Gereksinimler değiştirilmediğinde kullanılır ve testte tüm test senaryoları yeniden kullanılabilir. Arızaları veya hataları bulmak için daha az zaman gerektirir. Rahat ve tekrarlayan kullanımı ile çok tercih edilir. Yeni kodun, mevcut kod üzerindeki etkisini analiz eder. II. Aşamalı Regresyon testi – Gereksinimler değiştirildiğinde ve tüm test senaryolarının yeniden oluşturulması gerektiğinde kullanılır. Test, modelde yapılacak yalnızca birkaç değişiklik olduğunda veya yeni test senaryoları oluştururken de iyi çalışır. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ III. Tümünü Yeniden Test Et Regresyon testi – Tüm testler yeniden yapılır. Ancak bu test yöntemi, testlerin gereksiz yere yürütülmesine neden olduğundan daha fazla zaman ve maliyet gerektirebilir. Bu nedenle, test sürecine başlamadan önce test uzmanlarının aktiviteyi bilmeleri ve anlamaları önerilir. Bir sistemde değişiklik küçük olduğunda, bu test yöntemi önerilmez. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ IV. Seçici Regresyon testi – Testin süre ve maliyetini azaltmak için mevcut test senaryolarının bir alt kümesi kullanılır. Test senaryosu ile kapsadığı program varlıkları arasındaki bağımlılıkları bulmayı amaçlar. 6 adımda ele alınır: 1. Program değiştirildikten sonra yazılımın etkilenen bileşenleri belirlenir. 2. Değişikliklerden etkilenen yazılım bileşenlerini kapsayan mevcut test senaryoları setinden bir senaryo alt kümesi seçilir. 3. Programın doğruluğunu görmek için değiştirilen program test edilir. 4. Yazılım arızasını belirlemek için test sonuçları incelenir. 5. Herhangi bir hata bulunursa, hatayı oluşturan nedenler düzeltilir. 6. Programın test senaryoları ve test kayıtları güncellenir. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ 4. Duman (Smoke) Testi Bir yazılımın en önemli fonksiyonlarının çalışıp çalışmadığını anlamak amacıyla detaylara girmeden yapılan test tekniğidir. Yazılımın daha fazla test için hazır veya kararlı olduğundan emin olmak için yapılır. İlk çalıştırmada yangını/dumanı yakalayıp yakalamadığını kontrol etmek için duman testi denir. Örnek: 2 modülü olan bir projede; 2. modüle geçmeden önce 1. modülün düzgün çalıştığından emin olmak için yapılan test eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ 5. Alfa Testi Bir tür doğrulama testidir. Ürün müşterilere sunulmadan önce yapılan kabul testidir. Potansiyel kullanıcı veya bağımsız test ekibi tarafından yazılımı geliştiren ekibin kontrolündeki ortamda onların yönlendirmesi olmadan yapılan kullanıcı senaryolarını içeren testtir. 6. Beta Testi Teste yapılan sürümü gerçek zamanlı bir ortamda test edilmek üzere sınırlı sayıda kullanıcı için yayımlanır ve yazılımın son kullanıcısı tarafından bir veya daha fazla müşteri ortamında/ lokasyonunda gerçekleştirilir. Potansiyel kullanıcı tarafından yazılımı geliştiren ekibin kontrolü dışındaki ortamda yapılan testtir. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ 7. Sistem Testi Tüm entegrasyonlar tamamlandıktan sonra, gereksinimlerin karşılanıp karşılanmadığı kontrol edilir. Bu nedenle; fonksiyonel olmayan testlerin (performans, stres, yük, güvenlik testleri) dahil olduğu, kapsamlı testler gerekir. Bu aşama, ürünün teslimine çok yakın olduğu için canlıya yakın ortamda test edilir. Bu testleri, ürün gereksinimlerine hakim olan test ekibi yapar. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ 8. Stres Testi Bir yazılımın öngörülen veya belirlenmiş çalışma yükünün sınırlarında ya da ötesinde, ya da bellek veya sunucuya erişimi gibi kaynakların azalması durumundaki çalışma kapasitesini değerlendirmek için yürütülen bir çeşit performans testi. Bu testte sistemin olumsuz koşullarda nasıl performans gösterdiği kontrol edilir. Örnek: (a) Maksimum bellek veya diğer kaynaklar gerektiren test senaryoları yürütülür (b) Sanal işletim sisteminde bozulmaya neden olabilecek test senaryoları (c) Aşırı disk gereksinimine neden olabilecek test durumları eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ 9. Performans Testi Entegre bir sistem bağlamında yazılımın çalışma zamanı performansını test etmek için tasarlanmıştır. Programın hızını ve etkinliğini test etmek için kullanılır. Aynı zamanda yük testi olarak da adlandırılır. İçinde sistemin verilen yükteki performansının ne olduğunu kontrol ediyoruz. Bir yazılımın performansını belirlemek için yürütülen fonksiyonel olmayan test çeşidi. Örnek: İşlem süresi, cevap süresi, verim oranı vb. Yük Testi (Load Testing): Bir çeşit performans testidir. Bir yazılımın artan yük (eşzamanlı kullanıcı sayısı, işlem sayısı) karşısındaki davranışlarını değerlendirmek için kullanılır. Yazılımın yükü ne kadar kaldırabileceği tespit edilir. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ 10. Nesneye Yönelik Test (Object-Oriented Testing) Bu test, nesne yönelimli yazılımın doğrulanmasına ve doğrulanmasına yardımcı olan çeşitli test tekniklerinin bir birleşimidir. Test şu şekilde yapılır: 1. Gereksinimlerin Test Edilmesi, 2. Testlerin Tasarımı ve Analizi, 3. Kodun Test Edilmesi, 4. Entegrasyon testi, 5. Sistem testi, 6. Kullanıcı Testi. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ 11. Kullanıcı Kabul Testi (User Acceptance Test- UAT) Yazılımın kabul edilmesine karar vermek için yapılan; kullanıcı ihtiyaçları, gereksinimleri ve iş sürecine göre yürütülen, yazılımın kabul kriterine uygunluğunu, kullanıcıyı, müşteriyi veya yetkili birimi etkin kılarak denetleyen resmi test aktivitesidir. Taraflar, ürün son kullanıcı gereksinimleri karşısında yeterli mi, taraflar arası sözleşmenin maddelerini sağlıyor mu, uçtan uca testte sistemin fonksiyonel olan/olmayan herhangi bir noktasında hata var mı, sorularına yanıt ararlar. Kabul testlerini, müşteri/son kullanıcı ve kalite/test ekibi yapar. Bu aşamadaki kabul kriterleri bellidir ve senaryolar önceden yazılmıştır. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ Gerçek Zamanlı Test Canlı sistemin geliştirme sisteminden daha karmaşık olduğu durumlarda Gerçek Zamanlı test gereklidir. Gerçek zamanlı sistemi test etmek için gereken kurallar: Özel zamanlama koşulları oluşturarak olası kilitlenmeleri (deadlocks) değerlendirilir. Donanım hatalarını simüle etmek için testler kullanılır. Yazılım tasarımını zorlamak için donanım simülasyonu kullanın. Geliştirme sisteminde eksik olan modülleri simüle etmenin yolları tasarlanır. Emülatör: Test edilecek yazılım gibi davranan ve onunla aynı girdileri kabul edip aynı çıktıları üreten bir cihaz, yazılım veya sistem. eyec.baskent.edu.tr Genele Açık YAZILIM TESTLERİ Sınır Değer Analizi (Boundary Value Analysis): Test senaryolarının, sınır değerlerine göre tasarlandığı kara kutu test tekniği. (bir sayı aralığının min veya max değeri) Taşınabilirlik Testi (Portability Testing): Yazılımın bir ortamdan başka bir ortama ne kadar kolay taşınabildiğinin test edilmesi. Risk Bazlı Test (Risk-Based Testing): Yazılım risklerinin seviyelerini düşürmek ve projenin ilk aşamasından başlayarak paydaşları durumdan haberdar etmek amaçlı bir test yaklaşımıdır. Test sürecine rehberlik etmesi için ürün risklerinin belirlenmesini ve risk seviyelerinin kullanımını içerir. Maymun Testi (Monkey Testing): Geniş bir giriş veri seti içerisinden rastgele seçilerek yapılan ve yazılımın nasıl kullanıldığının hiç önemi olmadan rastgele tuşlara basılarak yapılan test. eyec.baskent.edu.tr Genele Açık FARKLI TEST BAKIŞI eyec.baskent.edu.tr Genele Açık CANLI SİSTEMDE TEST RİSKİ Chernobyl felaketi neden oldu? eyec.baskent.edu.tr Genele Açık CANLI SİSTEMDE TEST RİSKİ Acil bir durumda ek güç kaynağı olan türbin jeneratörün test edilmesi planlandı. Test’in 700 MW güçle yapılması planlanmıştı. Ancak güç durdurma ayarı 700 MW'ya ayarlanmadığından görevli operatör testi planlananın altında güçte (200 MW) başlattı. Saat 01.23’de kumanda tablosunda acil durdurma sinyali yanınca, operatör reaktörü durdurma düğmesine bastı ve güç seviyesi saniyeler içinde normal değerin 100 katına ulaştı. Durum kontrolden çıktı ve birkaç saniye arayla iki büyük patlama meydana geldi. Chernobyl Nükleer Santrali test yaparken patladı eyec.baskent.edu.tr Genele Açık DİKKAT EDİLMESİ GEREKEN KONULAR 1. İnternet uygulamalarının test edilmesi 2. Mobil uygulamaların test edilmesi 3. Kurumsal uygulamaların test edilmesi 4. Test sonuçları yönetimi 5. Test kapsamı 6. Test sürecinde zaman 7. Test senaryolarının güncellenmesi 8. Farklı duruma göre farklı test aktiviteleri 9. Farklı yazılım geliştirme modellerinde test süreci 10. Standardizasyon ve test sürecine etkisi 11. Test yönetim aracının önemi 12. Fonksiyonel olmayan gereksinimlerin test edilmesi 13. Test Uzmanın ve Senaryoların geliştirme sürecinin başında projeye dahil edilmesi 14. SDLC ile uyumlu test sürecinin olması ve yönetim tarafından desteklenmesi 15. Gereksinimlerin kalitesinin doğrulanması 16. Test verisi eyec.baskent.edu.tr Genele Açık DİKKAT EDİLMESİ GEREKEN KONULAR 1. İnternet uygulamalarının test edilmesi İnternete açık uygulamalarda hız testi önemlidir. Kullanıcılar yavaş gelen/çalışan sayfalara zorunlu olmadıkça kullanmak istemezler. İnternete açık uygulamalarda çok fazla kullanıcının bağlanmasından dolayı yük testi önemlidir. Uygulamanın, normal ve çok yoğun olacağı dönemler dikkate alınmalıdır. Sistemin önyüzü ve seçilen renkler sayfanın tercih edilmesinde önemlidir. Sayfanın kullanımı kolay olmalıdır. Sistem 24 saat ayakta olmalıdır. Kullanıcıların farklı web tarayıcılarda ve farklı versiyonları kullanma ihtimalinden dolayı farklı ortamlarda test edilmesi önemlidir. Uygulama üzerinde yer alan tüm bağlantıların test edilmesi gereklidir. eyec.baskent.edu.tr Genele Açık DİKKAT EDİLMESİ GEREKEN KONULAR 2. Mobil uygulamaların test edilmesi Mobil uygulamaları işletme içinde veya işletme dışındaki kullanıcılar kullanır. Mobil cihaz ile bu cihazın kullandığı ağ altyapısının çok iyi bir şekilde test edilmesi gerekir. Düşük seviyeli hızlarda bile yazılımın çalışması önem arz etmektedir. Güvenlik testleri çok kritiktir. Mobil cihaz üzerinde çalışan işletim sistemi ve mobil cihazın ekranının büyüklüğü ve performansı da test edilmelidir. Kullanım amacı ve yerine göre mobil cihazın fiziksel dayanıklılık testleri yapılabilir. eyec.baskent.edu.tr Genele Açık DİKKAT EDİLMESİ GEREKEN KONULAR 3. Kurumsal uygulamaların test edilmesi Kurumsal uygulamalar kurum içinde iç müşteriler için geliştirilmiş uygulamalardır. Test senaryolarının tam ve tüm gereksinimleri kapsayacak şekilde yazılması ve bunların test edilerek olumsuz sonuçlarının tamamlanması önemlidir. 4. Test sonuçları yönetimi Her bir test bulgusunun hangi gereksinim ile ilişkili olduğu net bir şekilde geriye doğru ve ileriye doğru izlenebilirlik sağlanmalıdır. Test sonuçları formal bir şekilde tutulmalıdır. Testlerin sonuçlarının kritiklik seviyesine göre sınıflandıracak bir yapı kurulmalı, sistemi durduracak veya yanlış veri oluşmasına neden olacak hatalar çözülmeden sistem canlıya alınmamalıdır. eyec.baskent.edu.tr Genele Açık DİKKAT EDİLMESİ GEREKEN KONULAR 5. Test kapsamı Test süreci yazılımlardaki hata oranını azaltır ancak sıfıra indirmez. Hata oranlarını azaltmak için test senaryolarında en kritik gereksinimlerden başlamak önemlidir. Bunun için bir öncelik matrisi yapılmalıdır. 6. Test sürecinde zaman Proje planında test süreci de yer alır. Ancak gereksinim belirleme, tasarım ve kodlama aşamaları genelde planlanandan fazla zaman alır, test aşamasına çok az zaman kalır. Bu durumda test yapan personelin üzerinde zaman ve yönetim baskısı oluşur. Zaman baskısı testleri olumsuz etkiler, yazılımda sorunlar artar ve müşteri mutsuz olur. Bunun için zaman iyi yönetilmeli ve test süreci planlandığı sürede yapılmalıdır. Test süreci için yazılım geliştirmenin sonu beklenmemeli, test senaryoları daha önce hazırlanmalıdır. eyec.baskent.edu.tr Genele Açık DİKKAT EDİLMESİ GEREKEN KONULAR 7. Test senaryolarının güncellenmesi Test senaryolarının yenilenmediği ve yazılımdaki hataların senaryo koşumu ile bulunamadığı durumları önlemek için test senaryoları yazılıma eklenen modül veya yetenekler nedeniyle belirli aralıklar ile güncellenmelidir. 8. Farklı duruma göre farklı test aktiviteleri Yazılım çeşidine, yazılımın çalışacağı ortama(Mobil, web, vb) , yazılımı kullanacak müşterinin durumuna, yazılım geliştirme yöntemlerine göre test aktiviteleri ve tipleri farklılık gösterir. Tek bir test çeşidi ve yöntemi bu farklılıkları ele alması beklenmemelidir. Bu nedenle ihtiyaca göre farklı testler yapır. Daha önce yapılmış olan projelerden elde edilen test ile ilgili deneyimler sonraki projelere yansıtılmalıdır. eyec.baskent.edu.tr Genele Açık DİKKAT EDİLMESİ GEREKEN KONULAR 9. Farklı yazılım geliştirme modellerinde test süreci Çevik yazılım geliştirmelerde amaç kullanıcıya küçük fonksiyonlar şeklinde yazılımları geliştirerek hem geliştirme hatalarını azaltmak hem de kullanıcıya bir an önce yazılımın ilk kısımlarını kullanmasını sağlamaktır. V model veya şelale yönteminde ise yazılımlar belirli fonksiyonlar üzerine eklenerek geliştirilir ve aralarda bazı fonksiyonlar bitince test yapan personel test çalışmalarına başlar. Bu durum özellikle yeni fonksiyon/özellik eklenince yazılımın altyapısı düzgün bir şekilde kurulmadıysa veya deneyimsiz yazılımcılar ile çalışılması durumunda daha önce test edilen veya kullanıcıya açılmış olan kısımlarda bile sorunlar çıkabilmektedir. Eğer test uzmanı bu kısımları tekrar test etmezse, önceden test edilmiş ve doğrulanmış olan kısımlarda da sorunlar çıkmaya başlayacaktır. Bu durumda regresyon testleri yapılmalıdır. eyec.baskent.edu.tr Genele Açık DİKKAT EDİLMESİ GEREKEN KONULAR 10. Standardizasyon ve test sürecine etkisi Her yazılımcı kendi bilgi birikimi ve çalışma şekline göre kodlama yapması durumunda ortaya çıkan ürünün hem testi hem de inceleme ve değerlendirmesi zor olacaktır. Dolayısı ile kodlama, gereksinim belirleme, sistem tasarımı, test süreçlerinden standartlaşma yazılım geliştirme projelerinde büyük öneme sahiptir. 11. Test yönetim aracının önemi Test aktivitelerinin SDLC’deki diğer aşamalarla ilişkili bir şekilde takip edilmesini sağlayacak bir aracın kullanılması projenin başarısı için önemlidir. Test aktivitelerinin yönetimi ayrı bir yerde manuel veya ilişkili bir şekilde tutulmaması durumunda karışıklıklar yaşanabilir, yapılmayan ve unutulan testlere bağlı olarak hataları düzeltilmeyen yazılımın canlıya alınma riski vardır. eyec.baskent.edu.tr Genele Açık DİKKAT EDİLMESİ GEREKEN KONULAR 12. Fonksiyonel olmayan gereksinimlerin test edilmesi Fonksiyonel olmayan gereksinim testleri projenin içeriğine göre planlanmalı ve yapılmalıdır. Yazılım webe açık ise sistem performansı son kullanıcı için çok önemlidir. Yazılım, askeri veya gizli içeriğe sahipse güvenlik anlamında fonksiyonel olmayan testler kritik hale gelecektir. Kullanıcılarınız çok farklı seviyede ise sistemin anlaşılabilir ve kolay kullanılabilirliği önemli olacaktır. 13. Test Uzmanın ve Senaryoların geliştirme sürecinin başında projeye dahil edilmesi Testi personelinin projenin başından itibaren iş analisti ile beraber çalışması, gereksinimler belirlenirken test uzmanın da test senaryoları üzerinde çalışması yazılımın hatasız bir şekilde üretilmesi için çok önemlidir. Test uzmanı yazılımı bozmaya veya hataya düşürmeye; iş analisti yazılımın temelini sağlam atmaya, yazılımcı ise yazılımı en doğru bir şekilde inşa etmeye odaklanır. eyec.baskent.edu.tr Genele Açık DİKKAT EDİLMESİ GEREKEN KONULAR 14. SDLC ile uyumlu test sürecinin olması ve yönetim tarafından desteklenmesi Test süreci tanımlı değilse, testleri sadece yazılımcılar yapıyorsa, testler çok basit bir şekilde yapılıyorsa canlı ortamda sorunlar yaşanacaktır. İşletmedeki test süreci, olgunluk seviyesine göre incelenmeli ve bununla ilgili iyileştirme çalışmaları başlatılarak en iyi duruma nasıl getirileceği üzerinde bir proje çalışması başlatılmalıdır. 15. Gereksinimlerin kalitesinin doğrulanması Yazılımın temelini oluşturan gereksinimlerin kaliteli bir şekilde belirlenip belirlenmediği doğrulama aşamasında ele alınmalıdır. Gereksinimler doğru, tam, uyumlu, test edilebilir, gerekli, uygulanabilir, net, izlenebilir ve önceliklendirilmiş olmalıdır. Gereksinimlerin bu kriterler ışığında ele alındığı doğrulanır ise test aşamasında daha düzgün ve daha iyi test senaryoları ele alınabilir ve testler yapılır. eyec.baskent.edu.tr Genele Açık DİKKAT EDİLMESİ GEREKEN KONULAR 16. Test verisi Test edilecek olan yazılımdaki tüm fonksiyonları kapsayacak şekilde test verisi oluşturmak gereklidir ve test verisi hazırlamak uzmanlık gerektirir. Test verisi oluşturma sürecinde test verisi oluşturma yazılımları kullanılabilir. Test yapmaya başlamadan önce, test verisinin test esnasında bozulması durumuna karşı verinin yedeği alınmalıdır. Bazı durumlarda canlı sistemdeki veriden yararlanılabilir. Bu durumda KVKK dikkate alınarak gerekli önlemler alınmalıdır. eyec.baskent.edu.tr Genele Açık YAZILIM TESTİNİN 7 İLKESİ 1. Test verisi Testing shows the presence of defects, not their absence. (Testler, hataların yokluğunu değil varlığını gösterir) Yani, test aktivitesi ile uygulamalardaki hatalar bulunur. Böylece ürünün kullanımı sırasında olası zaman/para ve itibar kaybı azalır. Ancak unutulmaması gereken nokta, ne kadar çok test yapılırsa yapılsın, hala bir yerlerde hatalar olmaya devam edecektir. O an uygulamada hiç hata bulunmaması, uygulamanın noksansız olduğu anlamına GELMİYOR. 2. Detaylı ve %100 test etmek imkansızdır Yani, bir uygulamadaki tüm kombinasyon ve olasılıkları test edemezsiniz (Bazı aşırı-kritik uygulama istisnaları haricinde). Bu makul bir durum değildir. Ancak teorik olarak sınırsız zaman ve bütçe olması durumunda (Ve psikoloji sağlam test ekibi de dahil) bu seçenek gerçekleşebilir. O yüzden gerçek hayatta, belli parametreleri dikkate alıp(Risk, öncelik vs) ona göre “makul yeterlilikte” test yapılır. Fizibilitesi doğru yapılmış bir test aktivitesi ile bu sınırsız seçeneği test etmeye yakın sonuçlar alınabilir. eyec.baskent.edu.tr Genele Açık YAZILIM TESTİNİN 7 İLKESİ 3. Erken aşamada test yapmak zaman ve paradan tasarruf etmeyi sağlar En kritik ilkelerden biridir. Testler, her ne kadar klasik waterfall sürecinde projenin sonlarında bir aktivite gibi görünse de, projenin her aşamasında yer almalıdır. Agile metodolojileri güzel bir örnektir. Metodoloji ne olursa olsun, testler tüm aşamalarda yer almalıdır. Erken aşamada farkedilen hatalar daha az zaman/para kaybına yol açar. Süreç ilerledikçe bu masraf artar. 4. Uygulamadaki hataların çoğunluğu sadece belli yerlerde kümelenir Yapılan araştırmalarda hataların homojen dağılmadığı, genelde belli modüllerde/kısımlarda oluştuğu veya belli kişiler (Development ekibinde) tarafından geliştirilen kısımlarda olduğu görülmüştür. Hataların %80'i belli modül veya kişilerden gelmektedir eyec.baskent.edu.tr Genele Açık YAZILIM TESTİNİN 7 İLKESİ 5) Zehirlenme (veya antibiyotik) paradoksu Aynı test case, aynı data ile (aynı kişi olursa, paradoks daha güçlenir) defalarca test edildiğinde, artık orada bir hata bulunması zor olur. Test doğası gereği üçüncü/bağımsız bir göz olması ve farklı girdilerle sonuç alması dolayısıyla, aynı şeyi yapmak, artık orada da bir direnç gösterir (sinek ve böceklerin aynı zehirden etkilenmemeleri gibi. Terminolojide hatalar için kullanılan Bug-böcek- kavramı ile ilişkilendirilir bu durum). O yüzden, belli sürelerde data değiştirilmeli ve mümkünse o testler başka bir ekip üyesi tarafından çalıştırılmalıdır. Otomasyon testlerinde ise durum tersidir. Yani, aynı test aynı data ve state ile test edilmelidir ki, çıkan hata ona göre tekrar edilebilir olsun. Unutulmaması gereken nokta: kullanılan her farklı data, teknik olarak yeni bir test durumudur. eyec.baskent.edu.tr Genele Açık YAZILIM TESTİNİN 7 İLKESİ 6) Test içeriğe göre değişkenlik gösterir Her ne kadar ana konsept aynı olsa da, test yaklaşımı içeriğe/projeye göre değişkenlik gösterir. Farklı sektörlerin, farklı alanların ihtiyaçları farklıdır. Örnek: Enerji sektörü, Telekom sektörü, Bankacılık sektörü öncelikleri ve riskleri ayrıdır. Bu nedenle, test stratejisi ve yaklaşımı oluştururken sektörün dinamikleri de göz önünde bulundurulmalıdır. 7) Hatasızlık bir yanılgıdır Deneyim, bilgi ve pozisyon ne olursa olsun herkes hata yapabilir. O yüzden “ben asla hata yapmam” veya “o hatayı yapmam imkansız” demeyin. Bu durum, özellikle test ekibini çok ilgilendirir. Projenin tüm “hata” bulma beklentisi test ekibine yüklenir ve test ekibindeki insanların “noksansız” olması beklenir. eyec.baskent.edu.tr Genele Açık YAZILIM TEST UZMANI Test Uzmanının amacı yazılım geliştirme süreçlerinde olabildiğince erken zamanda, hataları bulmak ve düzeltildiklerinden emin olmaktır. Yazılım test uzmanının özellikleri Meraklı Sorun giderici Toleranssız Yaratıcı Karar verme isabeti yüksek İkna edici eyec.baskent.edu.tr Genele Açık YAZILIM TEST UZMANININ GÖREVLERİ Tüm dokümanları okumak ve neyin test edilmesi gerektiğini anlamak. Uygulamanın nasıl test edileceğine karar vermek. Test liderine yazılım testi için gerekli kaynaklar hakkında bilgi vermek. Test senaryosunu geliştirmek Test senaryosunu yürütmek, hataları bildirmek, kritiklik ve önceliğini tanımlamak. Hataların düzeltildiği kodda regresyon testini yapmak. Hata raporu yazarak ilgili birimleri/kişileri bilgilendirmek. Müşteri memnuniyetini dikkate alarak analiz ve testteki düzenlemeleri sağlamak. Analiz ve testlerdeki tüm hataların düzeltilmesini sağlayarak hatasız ürün sunmak. eyec.baskent.edu.tr Genele Açık YAZILIM KALİTE GÜVENCESİ (QA) MÜHENDİSİ İŞ TANIMI Alternatif Unvanlar: Test mühendisi,, kalite mühendisi, kalite güvence analisti Yazılım QA mühendisi, kalite güvence testini planlayarak, uygulayarak ve otomatikleştirerek yüksek kaliteli yazılım teslimini sağlar. Sorumluluklar arasında test planları geliştirme, test senaryoları oluşturma, test otomasyon kodunu yazma ve sonuçları raporlama yer alır. Temel Sorumluluklar Yeni ve mevcut işlevsellik için testler (örn. regresyon, fonksiyonel, veri doğrulama, sistem entegrasyonu, yük veya performans testleri) planlar ve uygular. Test stratejileri tasarlamak ve testi geliştirme sürecine entegre etmek için geliştirme ekipleriyle yakın bir şekilde çalışır. İş ortakları, geliştiriciler ve diğer paydaşlarla birlikte çalışarak test senaryolarını planlar, oluşturur, yürütür ve otomatikleştirir. Test sonuçlarını belgeler, analiz eder ve düzeltici eylem önerir. eyec.baskent.edu.tr Genele Açık YAZILIM KALİTE GÜVENCESİ (QA) MÜHENDİSİ İŞ TANIMI Kusurları izole eder ve tekrar oluşturur, test veritabanlarını günceller, düzeltmeleri doğrular. İş ortakları veya son kullanıcılar tarafından yürütülen kullanıcı kabul testlerine destek verir. Karmaşık özellikler için keşif testleri ve risk analizi yapar. Tekrarlanabilir testleri otomatikleştirerek test süresini ve çabasını azaltmaya çalışır. Test otomasyonu altyapısını geliştirir. Model tabanlı test veya kaydet&tekrar oynat gibi otomatik test yaklaşımlarını uygular. Makine öğrenimini gibi yeni test teknolojileri ve uygulamalarını araştırır, önerir ve uygular. Geliştirme ekipleri arasında kaliteyi tanımlayın ve savunun ve en iyi uygulamaları test edin. Bir uygulama topluluğuna katılarak, diğer yazılım QA mühendisleriyle işbirliği yapar ve bilgi paylaşır. Test kapsamını artırmak için geliştiricilerin test planlarını gözden geçirir. eyec.baskent.edu.tr Genele Açık YAZILIM KALİTE MÜHENDİSİ BECERİLER VE YETKİNLİKLER Yazılım geliştirme deneyimi. (Örnek: Java, JavaScript,.NET, Python) Test otomasyonu komut dosyaları yazma deneyimi. SQL ile deneyim. Test planlarını tasarlama ve uygulama deneyimi. Test yönetim araçlarıyla ilgili deneyim (Örnek: TestRail, XRay, Qtest, Quality Center). Test otomasyonu deneyimi (Örnek: Selenium, Cypress, Puppeteer, Playwright). Uygulama performansı izleme ve gözlemleme araçlarıyla deneyim. Cloud-Based çözümler, Multi-Layers, Microservices mimarileri hakkında bilgi. Ayrıntılara dikkat ve kusurları belirleme, izole etme ve belgeleme yeteneği. Çevik uygulamalar hakkında güçlü bilgi ve çevik planlama araçlarıyla (Örnek:Jira) deneyim. Hem teknik hem de teknik olmayan paydaşlar için etkili sözlü ve yazılı iletişim becerileri. eyec.baskent.edu.tr Genele Açık YAZILIM KALİTE MÜHENDİSİNDEN BEKLENEN BECERİLER Yazılım Kalite Mühendisleri için en çok talep edilen 10 beceri. 1. Otomasyon 2. Test Senaryoları (test cases) 3. İletişim 4. Analiz 5. Çevik 6. Selenyum 7. Yazılım geliştirme 8. İşbirliği 9. SQL 10. Java eyec.baskent.edu.tr Genele Açık