YZM 320 - Yazılım Doğrulama ve Geçerlileme

1. YZM 320 - Yazılım Doğrulama ve Geçerlileme Hazırlayan:Emin BORANDAĞ

2. 3. BÖLÜM: Yazılım Test Modellileri ve Yazılım Geliştirme Modelleri

3. Yazılım geliştirme modelleri her zaman kullanılır mı?İdeal midir? • Yazılımların çoğu yazılım geliştirmek için bir yazılım geliştirme modeli izlemez.Neden? • Müşterinin ihtiyaçları hiçbir zaman tam olarak tanımlanamaz! • İkinci neden ise; bütün durumların gerçekleştirilmesi için yeterli zaman ve kaynak yoktur. • Ne olursa olsun yazılım geliştirmede bir yazılım geliştirme modeli kullanılmalıdır.

4. Plato’nun “ideal” ile ilgili ilginç benzetmeleri • Fiziksel nesneler ve fiziksel olaylar, ideal veya mükemmel formların gölgeleridir. • Onlar ölçeğine yaklaşabildiği kadar mükemmeldirler. • Waterfall modeli mükemmelidir?

5. Yazılım Testine İlişkin… • Yazılım test karmaşıklığı kesin olarak bilinemez! • Yazılımın testi yazılım risk temelli olarak yapılmalıdır. • Yazılımın testi yazılımda hata olmadığını gösterir. • Daha fazla hata bulduğunda daha fazla test yapmalısın. • Bulunan bütün hataların düzeltildiği söylenemez. • Tanımlamalar nihaiyi değildir. • Yazılım geliştiriciler arasında Yazılım testleri popüler değildir. • Yazılım testi bir disiplindir ve yazılım projeleri içerisinde profesyonelce incelenmelidir.

6. Yazılım Testi ile ilgili belirtiler ve zorluklar-1,2. • Yazılımı tam olarak test etmek imkansızdır. • Kaç tane test case oluşturulmalı. • Tek yol, yazılımın mevcut olan bütün girişlerinin doğru olarak alındığından emin olup. Bütün girişleri ve çıkışları kontrol etmek. • Tanımlamaların doğru olduğu bilinmeli. • Yazılım üretiminin ilk safhasında oluşan isterler yorumlamaya açık. • Yazılım içerisine alınan giriş sayıları çok fazla. • Yazılımda oluşturulan çıkış sayıları çok fazla. • Yazılım içerisinde oluşan yol (path) sayısı çok fazla.

7. Yazılım Testi ile ilgili belirtiler ve zorluklar-3 • Eğer yazılım içerisindeki bütün girişleri test edemez ise yazılım içerisinde risk almış olursun! • Bütün durumları test etmediğin için yazılımın düzgün çalıştığı umarsın. • Girişleri test etmedin ve bir hata ile karşılaştın ne olur? • Risk:Güven kaybı,para,zaman,etc • Bu yüzden testi yapan kişi üzerinde baskı kodlayan kişiye göre daha fazladır. • Bu dersin temel amaçlarından biride bu riski azalatmaya çalışmak.

8. “Software testing is a risk-based exercise” Test maliyeti Kaçırılan hata sayısı • Eğer çok fazla test yaparsan yazılımın maliyeti artar. • Eğer az test yaparsan yazılım içerisindeki kaçırılan hata sayısı artar. Kalite Optimum Test Az Test Daha Fazla Test Test Sayısı

9. Ödev=2 Roma Problemi Kullanıcıdan alınacak giriş sayısı Örnek=5 Adım sayısı Örnek=3 Bulunacak değerler Örnek = 2,4

10. Ödev=3 Proje Şartnamesini oluştur! • “If you don't know where you're going any road will take you there” • Müşteriden alınan bilgiler, yapılan toplantıdan çıkarılan sonuçlara göre toparlanır. • Bu aşama sonucunda • Yazılım özellikleri neler olacak? • Formal mi yoksa informal mi olmalı???

11. Şartname??? • Tanımlı istekler belirlenmeli. • Kayıt,Güncelleme,Raporlama,vb • Tanımlı olmayan istekler belirlenmeli. • Güzenlik,Sağlamlık,Kolay bir arayüz

12. Tasarım • Kodlama öncesi, • yazılım projeleri • Üzerinde önce,tasarım • dokümanları bir dizi • Hazırlık planları oluşturulur. • Yazılım Mimarisi • Veri akış diyagramı • Durum geçiş diyagramı • Akış şeması

13. Gantt graf • Bir  projeye ait zamanlama çizelgesini gösterençubuk graf

14. Yazılım testti risk temelli olarak incelenmelidir!Bununla ilişkili Murphy kanunları nedir?-4 • Eğer yazılım hatalı bir sonuç üretiyorsa bundan yazılımı üreten kişiler sorumludur ve bu sorunu onlar halletmelidir! • Bu kural Edward Murphy tarafından yazılım geliştirimi ile ilgili bir ölçü geliştirmek için ortaya atılmıştır.

15. Test yazılımda hata olmadığını göstermez!-4 • “Program testti, ancak hataların varlığını göstermek için kullanılır onların yokluğunda göstermek için değil!” Edsger Wybe Dijkstra • “Test ile hata bulabilirsin ama hala daha fazlası vardır” • Hatalar nerelerden kaynaklana bilir. • Programcılar kötü günleri olabilir. • Programcılar aynı hataları yapmak eğilimindedir. • Bazı hatalar buzdağının sadece ucu gibidir. • Boris Beizer yaklaşımı: Daha fazla yazılım daha fazla testti beraberinde getirir “pestisit paradoksu”. Bu nedenle Boris Beizer bağışıklık testleri kavramını ortaya attı. Çözüm sürekli yazılımın farklı bölgelerinde yazılım kullanımı ile ve test kodu ile yazılımları test edin.

16. Bulunan bütün hatalar çözümlenemez!-5 • Yeterli bilgi birikimi eksikliği! • Bazen yeterli zaman yoktur! • Bazı son tarihler ertelenemez. • Bazen çok riskli olabilir! • Murphy’nin koduna dokunma • Buna değer mi! • Bazı ek özellikle bekleyebilir! • Neden bir sonraki sürüm için müşteriden ücret almayalım ki? • Kod ile ilgili bir hata olmaya bilir! • Tanımlama yanlışlığından olabilir • Neden Bulduğunuz bir hatayı onaramazsınız!

17. TanımlaMA ve İsterleri belirleME

18. Hatanın bir başka içerdiğini söylemek zordur-6. • Eğer yazılım içerisinde bir hata bulmuş ve diğerlerini keşfedemiyorsanız ne olur? • Parody “Ormanda bir ağaç düşerse gerçekten ses yapar mı?” • Görülemeyen hata hatamıdır? • Görülemeyen hatalara örtük(gizli) hata“latent bugs”

19. Tanımlamalar nihaiyi değildir! • Yazılım geliştirmede isterler oldukça sıra dışı ve özgürdür. • Rekabet çok fazladır. • Yaşam döngüleri çok hızlıdır. • Yazılımı değiştirme “kolaydır.” • Diğer mühendislik alanlarında durum nasıl?

20. Bir hikaye… • Sayın mimar; • Lütfen bana bir ev inşa ediniz.Ama tam olarak ne istediğimden emin değilim.Bu nedenle kendi taktirinizi kullanınız. • Evimde 2 ila 45 adet yatak odası olsun. Yatak odalarını kolaylıkla ekleyip kaldırabileyim bir şekilde planlayınız. Siz bana planları getirin ben nihaiyi kararları ona göre vereyim. Ayrıca her bir plan için tek tek maliyet dökümlerini de getirmeyi unutmayınız.Böylelikle bende bana uygun olanı seçebilirim.

21. Bir hikaye devam… • Şunu da aklınızda tutun ben sonuçta maliyeti düşük olanı seçeceğim.Maliyeti şu anki evden daha düşük olmalı. Şu anda yaşadığım evde çeşitli aksilikler var(Mutfak ile ilgili sorunlarım var. Ben evde yürüdüğümde eşyalar sallanıyor ayrıca yalıtımda çok iyi değil.) • Ayrıca bu evi yıllık olarak tutmak istiyoruz yani önümüzdeki sene maliyeti daha düşük bir ev bulursak çıkarım haberiniz olsun. Tararımı yaparken de yıllık masrafları oldukça az tutun fazla paramız yok.

22. Bir hikaye devam… • Lütfen en son malzemeleri kullanın ve en güzel şekilde tasarlamaya çalışın.Eğer böyle yaparsanız ev gerçekten çok güzel olur. Aaa unutmadan, mutfakta benim 1952 model Gibson buz dolabını barındıracak şekilde olsun. • Evin güvenliği bizim için çok önemli; kanunlar karşısında belirlenmiş yönetmeliklere göre evi hazırlayın yoksa olmaz. Benim eşimin annesi yılda en az bir kere bizi ziyarete gelir geldiğinde ev ile ilgili tararım ve diğer konularda her hangi bir eksiklik bulmaya çalışacaktır aman dikkat edelim.

23. Bir hikaye devam… • Eğer anneciğim her hangi bir yerini beğenmez ise o kısım ile ilgili değiştirme hakkımı elimde tutmak isterim. Lütfen şu anda beni küçük tararım ayrıntıları ile rahatsız etmeyin. Bu tasarım sizin işiniz karışmak istemem. Büyük resmi düşünün ona göre tasarlayın. Bu arada eşim yeşil renkli halıları sever tasarım buna da aklınızda tutun.Ev ile ilgili kaynak sorununu düşünmeyin. Sizin ilk önceliğiniz detaylı bir ev planı ve tanımlamaları oluşturmak. Tabi şunu da beklerim, ben tasarımı seçtikten sonra 48 saat içinde çatının ilk şekli oluşmuş olsun.

24. Bir hikaye devam… • Evi tasarlarken önce ve sonra olabilecek isteklerimi göz önemde bulundurun. Bu evi satmak istiyorum o nedenle potansiyel alıcıları için cazip olmasını da dikkat edin. • Bizim yan komşularda evlerini geçen sene yenilediler onların evlerinin de çok güzel yönleri var. Onların ayrıca büyük bir yüzme havuzları var. İnanıyorum ki güzel bir tasarım ile maliyetleri yukarı çekmeden buna benzer bir yüzme havuzu yapabilirsiniz.

25. Bir hikaye devam… • Tasarımları komple bir set olarak hazırlayın, yeni nesil inşaatçılık yöntemleri kullanabilirsiniz, bakın sizin için ne büyük bir kolaylık bu günlerde böyle anlayışlı müşteri bulmak çok zor. Ama tasarımla ilgili konuları değiştirmeyin yoksa maliyet artar aman maliyetlere dikkat. • Böyle bir proje üzerinde çalışmaktan çok mutlu olduğunuzu düşünüyorum. Bunun gibi tasarımları çok özgür bir şekilde yapılacak olmak ve yeni inşaat yöntemleri kullanmak güzel olsa gerek.

26. Son notlar. • Unutmadan bu arada karım biraz önce söyledi evde olacak bu işlerden ötürü çok ses çıkmasın. Tabi mimar sissiniz nasıl olacağını da siz bizden daha iyi bilirsiniz. • Daha önceden inşaat yaptırma işine girdim ama olmadı umarım bu sefer olur.Eğer siz yapamazsanız başka bir mimar bulurum. • Belki de bu evi yenilemek yerine güzel bir tatil yapsam daha iyi olur neyse başladık bir kere beni bilgilendirin. Sizden haber bekliyorum.

27. Yazılım test uzmanları proje içerisinde en sevilen kişiler değillerdir-8. • Yazılım Test mühendisinin amacı • Hataları bulmak • Hataları erken safhalarda oluşmadan bulmak • Hataların düzeltildiğinden emin olmak • Popülerlik için ipuçları • Hataları erken bul. • Ani sinirlenme. • Kötü haberleri erkenden proje yöneticisine ulaştırma

28. Yazılım mühendisliği teknik bir meslektir-9 • Yazılım kolay ve yönetilebilir olduğunda(parçaları birbirinden ayrılmış) yazılımı test etmek daha kolaydır. Aksi durumlarda test işlemi daha zordur. • Günümüzdeki yazılımlar çok büyük ve karmaşık o nedenle test için • Yöntemler • Araçlar

29. Biraz Terminoloji. • Verification: • Biz ürünümü doğrumu yapıyoruz? • Yazılım şartnamedeki özellikleri ve tanımlamaları karşılanıyor mu? • Validation: • Doğru ürünü mü yapıyoruz? • Ürün kullanıcı ihtiyaçlarını karşılıyor mu? • Kalite Güvencesi • Yöntem ve standartlar uygulayarak; yazılım sürecleri içinde meydana gelen hataları önle.

30. Bu derste…. • … Yazılım testinin 9 belirtisi nelerdir? • … Kalite güvencesi ile test arasındaki ilişki nasıldır? • …Yazılım geçerlileme nedir? • … Yazılım doğrulama nedir? • … Yazılım kalitesi ve güvenirlilik arasındaki ilişki nedir? • Proje temellinin oluşturmak için gerekenler