1 / 43

Yazılım Projelerinde Test Süreci

Yazılım Projelerinde Test Süreci. Necdet Terkeş (QA / ISTQB) necdet.terkes@gmail.com necdett.com twitter.com/necdet tr.linkedin.com/in/nterkes. Gündem. Son 5 senede sektör… Test nedir? Test niçin yapılır? Testin ilkeleri Tester, Testçi, Test Uzmanı… Test Süreci Risk Analizi (FMEA )

ailsa
Télécharger la présentation

Yazılım Projelerinde Test Süreci

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Yazılım Projelerinde Test Süreci Necdet Terkeş (QA / ISTQB) necdet.terkes@gmail.com necdett.com twitter.com/necdet tr.linkedin.com/in/nterkes

  2. Gündem • Son 5 senede sektör… • Test nedir? • Test niçin yapılır? • Testin ilkeleri • Tester, Testçi, Test Uzmanı… • Test Süreci • Risk Analizi (FMEA) • Test Seviyeleri • Test Çeşitleri • Test Sertifikaları • Gelecek…

  3. Son 5 senede sektör… • Bilişim dünyasındaki (yazılım ve donanım) gelişmeler rekabeti arttırdı, • İş odaklılığından müşteri odaklı bir sisteme geçildi, • Rekabette öne geçmek isteyenler hizmet kalitesinde fark yaratmaya çalıştılar, • Ürünlerin daha az hata ile müşterilere sunulması için teste verilen önem arttı, • Test danışmanlığı ve dış kaynak kullanımı başladı, • Şirketlerin test süreçleri oturmaya başladı ve test ekipleri kurulmaya başladı…

  4. Test Nedir? Ürünün beklenilen seviyede olduğunu belirlemek, değilse de istenilen ölçüyegelmesini sağlamak için kullanılan bir süreç

  5. Test Niçin Yapılır? • Müşteriye sunulmadan önce ürün kalitesinden emin olmak, • Yeniden çalışma (düzeltme) ve geliştirme masraflarını azaltmak, • Geliştirme işleminin erken aşamalarında yanlışları saptayarak ileri aşamalara yayılmasını önlemek, böylece zaman ve maliyetten tasarruf sağlamak, • Müşteri memnuniyetini arttırmak ve izleyen siparişler için zemin hazırlamak.

  6. Test Niçin Yapılır?

  7. Testin İlkeleri • İlke 1: Test defectlerin varlığını gösterir;Test defectin varlığını gösterir ama defect olmadığını kanıtlayamaz. Test, yazılımdaki keşfedilmemiş defectlerin olasılığını azaltır, hiç defect bulunamamış olması yazılımın doğruluğunun kanıtı değildir. Kaynak: http://testgaraji.com

  8. Testin İlkeleri • İlke 2: Exhaustive (her şeyi kapsayan) test mümkün değildir;Her şeyi test etmek yapılabilir değildir. Her şeyin test edilmesi yerine, test çabalarının odaklanmasında risk analizi ve öncelikler kullanılmalıdır. Kaynak: http://testgaraji.com

  9. Testin İlkeleri • İlke 3: Erken test;Test faaliyetleri yazılım ve sistem geliştirme yaşam döngüsünde mümkün olduğunca erken başlamalı ve tanımlı hedeflere odaklanmalıdır. Kaynak: http://testgaraji.com

  10. Testin İlkeleri • İlke 4: Defect Kümelenmesi (Clustering);Az sayıdaki modül, sürüm öncesi testleri sırasında tespit edilen defectlerin büyük bölümünü içerir ya da operasyonel başarısızlıkların büyük bölümünden sorumludur. Kaynak: http://testgaraji.com

  11. Testin İlkeleri • İlke 5: Pesticide (tarım ilacı) paradoksu;Aynı testler üst üste tekrarlandığında, aynı test durumlarından oluşan testler artık yeni defect bulamazlar. Bu paradoksu aşmak için, test durumları düzenli olarak gözden geçirilmeli, düzeltilmeli, yazılımın ve sistemin farklı bölümlerindeki potansiyel defectler için yeni testler yazılmalıdır. Kaynak: http://testgaraji.com

  12. Testin İlkeleri • İlke 6: Test içerik bağımlıdır;Farklı bağlamlarda farklı test yapılmalıdır. Örneğin, güvenliği kritik bir yazılımın testi bir e-ticaret sitesinin testinden farklı gerçekleştirilmelidir. Kaynak: http://testgaraji.com

  13. Testin İlkeleri • İlke 7: Hata yokluğu yanılgısı (Absence of error fallacy);Sistem buildi kullanılabilir değilse, kullanıcının ihtiyaçlarını ve beklentilerini karşılamıyorsa, defect bulmanın ve defecti düzeltmenin bir yararı olmaz. Kaynak: http://testgaraji.com

  14. Tester, testçi, test uzmanı... Google Images’a göre

  15. Tester, testçi, test uzmanı...

  16. Tester, testçi, test uzmanı...

  17. Tester, testçi, test uzmanı...

  18. Tester, testçi, test uzmanı...

  19. Tester, testçi, test uzmanı...

  20. Tester, testçi, test uzmanı... • Süreci iyi bilmeli, • Metodolojisi olmalı, • Planlı olmalı, • Her iki profili de kapsamalı, • Net olmalı, • Araçları olmalı, • Test ortamı olmalı, • Şüpheci olmalı...

  21. Tester, testçi, test uzmanı... • Hatayı bul, • Erken bul, • Çözüldüğünden emin ol. • Hatayı çöz, • İyi niyetle test et, • Gereksinimler olmadan test et, • Çok belirgin hataları raporlama, • Hataları yüzünden başkaları ile alay et,

  22. Test Süreci Yazılım Süreci Test Süreci

  23. Test Süreci • Analiz • Teknik Analiz • Geliştirilecek olan ürünü tanımak, müşteri isteğini anlamak, • Eğer kullanılan ürün ise mevcut durumu saptamak, • Risk analizi yapmak, • Test zamanlarını belirlemek, • Test planını oluşturmak, • Use case ve senaryoları belirlemek.

  24. Test Süreci • Development • Senaryoları risk durumlarına göre sınıflandırmak, • Senaryoları test case leri ile detaylandırmak, • Birim (unit) testleri yapmak, • Analiz’deki değişiklikleri takip etmek.

  25. Test Süreci • Test • Smoke testleri yapmak, • Test senaryolarını çalıştırmak (riskli olanlar öncelikli), • Hataları raporlamak, • Çözülen hataları tekrar test etmek (regression), • Riskli olan senaryoları tekrar test etmek.

  26. Test Süreci • UAT • Uygulamadaki tüm fonksiyonaliteyi müşteriye test ettirmek, • Çıkan hataları raporlamak, • Çözülen hataları test edip, müşteriden onay almak, • Test raporu yayınlamak

  27. Risk Analizi (FMEA) Testi planlamaya başlamadan önce risklerin belirlenmesi gerekir. Bu alanda FMEA (Failure Mode Effect Analysis) yöntemi kullanılır. FMEA risk analizi 3 adımdan oluşur; 1- Risklerin kategorize edilmesi 2- Risklerin ölçeklendirilmesi 3- Risklerin RPN (risk priority number) değerinin belirlenmesi

  28. Risk Analizi (FMEA) • Risk kategorileri; • Fonksiyonelite: Sistemin işlevselliğini tam olarak yerine getirememesine neden olabilecek risklerdir, • Yük & Kapasite: Maksimum sayıda kullanıcıyı sistemin destekleyebilmesini engelleyebilecek risklerdir, • Güveninirlik: Sistemin çökmesine sebep olabilecek risklerdir, • Sürdürülebilirlik: Operasyonların devamlılığını kesintiye uğratabilecek risklerdir.

  29. Risk Analizi (FMEA) • Veri kalitesi: Verilerin düzgün bir şekilde işlenmesi, saklanması ve çekilmesini engelleyebilecek risklerdir, • Performans: Normal şartlar altında işlemlerin belirlenen sürede yapılmasını engelleyebilecek risklerdir, • Dökümantasyon:Şirket personeli için hazırlana kullanım klavuzu riskleridir, • Arayüz: Sistemin arayüzlerinde ortaya çıkabilecek risklerdir, • Entegrasyon: Sistemin diğer sistemlerle olan etkileşimi sırasında ortaya çıkabilecek risklerdir.

  30. Risk Analizi (FMEA) Risklerin ölçeklendirilmesi; A) Sistem Açısından Önemine Göre ( Severity)1. Veri Kaybı2. İşlevsellik Kaybı3. Giderilebilir İşlevsellik Kaybı4. Kısmi İşlevsellik Kaybı5. Kozmetik Riskler

  31. Risk Analizi (FMEA) Risklerin ölçeklendirilmesi; B) Müşteri Açısından Önemine Göre ( Priority)1. Acil2. Zorunlu3. Önemli4. Düzeltilmesi İyi Olacak5. İsteğe Bağlı

  32. Risk Analizi (FMEA) Risklerin ölçeklendirilmesi; C) Gerçekleşme Olasılığına Göre ( Likelihood)1. Muhtemel2. Mümkün3. İhtimal Dahilinde Olmayan

  33. Risk Analizi (FMEA) RPN hesaplama; RPN hesaplanırken risklerimiz için belirlediğimiz severity, priority ve likelihood ölçeklerinin katsayıları ile çarparız; Örneğin severity (1), priority (2), likelihood(2) olan bir riskin RPN değeri 4 tür. RPN değeri ne kadar az olursa riskin önemi o kadar artar.

  34. Test Seviyeleri • Test 4 temel aşamadan oluşur; • Birim (unit) seviyesi • Modül seviyesi • Sistem seviyesi • Kabul seviyesi

  35. Test Seviyeleri Birim (unit) seviyesi Sistemi oluşturan ufak parçaların kendi içerindeki testlerdir. Kod testi olarak da bilinir. Genelde bu level daki testleri developer veya yazılım skilleri olan testçiler yapar.

  36. Test Seviyeleri Modül seviyesi Ayrık parçaların birbirleri ile olan etkileşimlerinin testi.

  37. Test Seviyeleri Sistem seviyesi Parçalar birleştikten sonra bütün yazılımın gereksinimlere uyumluluk testidir. Fonksiyonel ve görsel test olarak bilinir.

  38. Test Seviyeleri Kabul seviyesi Üretilen yazılımın müşteri tarafından test edilmesidir.

  39. Test Çeşitleri • Black box testing• White box testing• unit testing• integration testing• functional testing• end-to-end testing• sanity testing or smoke testing• regression testing• acceptance testing• load testing• stress testing• performance testing

  40. Test Çeşitleri • usability testing• install/uninstall testing• security testing• compatability testing• exploratory testing• user acceptance testing• comparison testing• alpha testing• beta testing

  41. Test Sertifikaları Uluslararası düzeydeki eğitim programları ve sertifikasyonlarını veren kurumlar; ISQTB - http://www.istqb.org/CSTE -   http://www.qaiglobal.com/CSTP -   http://www.testinginstitute.com/CTM -    http://www.testinginstitute.com/ctm.phpCSQA -  http://www.qaiindia.com/Certification/note.htmCSPM -  http://www.qaiindia.com/Certification/note_cspm.htmCSPE - http://www.qaiasia.com/edistacertification/Certification.asp

  42. Gelecek… • Mobilitenin yayılması ile beraber platform bağımsız sistemler, • Cloud computing • Cloud testing (SOASTA, Gomez…)

  43. Sorularınız... Necdet Terkeş (QA / ISTQB) necdet.terkes@gmail.com necdett.com twitter.com/necdet tr.linkedin.com/in/nterkes

More Related