Test Mühendisliğine Giriş Eğitimi - Bölüm 1Mesut Günes
ISTQB ve ISEB Foundation level gibi "Test Uzmanlığı" ile ilgili yapılan sınavlara hazırlık olarak tüketilecek dökümandır. Ayrıca yazılım test mühendisliği ile ilgili bilgi edinmek isteyenlerin okuyabileceği Türkçe kaynaktır.
What is main difference between Behavior Driven Development and Acceptance Test Driven Development? How can we start using one of these practices. What books should you read to get more details about Testing By Specification?
Test Mühendisliğine Giriş Eğitimi - Bölüm 2Mesut Günes
ISTQB ve ISEB Foundation level gibi "Test Uzmanlığı" ile ilgili yapılan sınavlara hazırlık olarak tüketilecek dökümandır. Ayrıca yazılım test mühendisliği ile ilgili bilgi edinmek isteyenlerin okuyabileceği Türkçe kaynaktır.
Test Mühendisliğine Giriş Eğitimi - Bölüm 1Mesut Günes
ISTQB ve ISEB Foundation level gibi "Test Uzmanlığı" ile ilgili yapılan sınavlara hazırlık olarak tüketilecek dökümandır. Ayrıca yazılım test mühendisliği ile ilgili bilgi edinmek isteyenlerin okuyabileceği Türkçe kaynaktır.
What is main difference between Behavior Driven Development and Acceptance Test Driven Development? How can we start using one of these practices. What books should you read to get more details about Testing By Specification?
Test Mühendisliğine Giriş Eğitimi - Bölüm 2Mesut Günes
ISTQB ve ISEB Foundation level gibi "Test Uzmanlığı" ile ilgili yapılan sınavlara hazırlık olarak tüketilecek dökümandır. Ayrıca yazılım test mühendisliği ile ilgili bilgi edinmek isteyenlerin okuyabileceği Türkçe kaynaktır.
- Understand the principles behind the agile approach to software development
- Differentiate between the testing role in agile projects compared with the role of testers in non-agile projects
- Positively contribute as an agile team member focused on testing
- Appreciate the challenges and difficulties associated with the non-testing activities performed in an agile team
- Demonstrate a range of soft skills required by agile team members
4 Nisan 2015 tarihinde Kadir Has Üniversitesi'nde yapılan 9. Yazılım Teknolojileri Seminer etkinliğinde Eralp Erat'ın yaptığı TDD (Test Driven Design) sunumu
Eğiti İçeriği
ISTQB Metodolijisi ile Test planlama ve Tahminleme
Bölüm 1: Test Planlama (Test Planing)
Bölüm 2: Test Planlama Adımları (Test Planing Activities)
Bölüm 3: Test Tahminleme (Test Estimation)
Bölüm 4: Test Stratejisi,Test Yaklaşımı (Test Strategy,Test Approach)
Bölüm 5: ISTQB Metodolojisi ile Test Planlama ve Tahminleme Soru
Örnekleri
ISTQB eğitiminde yazılım testi ile ilgili önemli konulara ve örneklere değinilmiştir. "Test Nedir?", "Testin Prensipleri", "Test Teknikleri", "Yazılım Metodolojileri" ve daha birçok önemli başlık hakkında detaylı ve teknik bilgiler yaşanmış örneklerle verilmiştir. Bu sunumda, bahsedilen konu başlıkları ve daha fazlası genel haliyle anlatılmıştır.
- Understand the principles behind the agile approach to software development
- Differentiate between the testing role in agile projects compared with the role of testers in non-agile projects
- Positively contribute as an agile team member focused on testing
- Appreciate the challenges and difficulties associated with the non-testing activities performed in an agile team
- Demonstrate a range of soft skills required by agile team members
4 Nisan 2015 tarihinde Kadir Has Üniversitesi'nde yapılan 9. Yazılım Teknolojileri Seminer etkinliğinde Eralp Erat'ın yaptığı TDD (Test Driven Design) sunumu
Eğiti İçeriği
ISTQB Metodolijisi ile Test planlama ve Tahminleme
Bölüm 1: Test Planlama (Test Planing)
Bölüm 2: Test Planlama Adımları (Test Planing Activities)
Bölüm 3: Test Tahminleme (Test Estimation)
Bölüm 4: Test Stratejisi,Test Yaklaşımı (Test Strategy,Test Approach)
Bölüm 5: ISTQB Metodolojisi ile Test Planlama ve Tahminleme Soru
Örnekleri
ISTQB eğitiminde yazılım testi ile ilgili önemli konulara ve örneklere değinilmiştir. "Test Nedir?", "Testin Prensipleri", "Test Teknikleri", "Yazılım Metodolojileri" ve daha birçok önemli başlık hakkında detaylı ve teknik bilgiler yaşanmış örneklerle verilmiştir. Bu sunumda, bahsedilen konu başlıkları ve daha fazlası genel haliyle anlatılmıştır.
Application Lifecycle Management Services by 4SSerdar Zeybek
Application Lifecycle Management Services by 4S. 4S is one of the leading companies in Turkey. 4S has finished many sucessfull projects in EMEA Region.
Yazılım projelerinde çıkan hatalar ne kadar geç fark edilirlerse o kadar yüksek maliyetlere yol açarlar. Yazılım geliştirme yaşam döngüsünün ilk aşamalarında yapılan testlerle ortaya çıkan hatalar projeye efor maliyeti olarak yansır, son aşamalarında ortaya çıkartılan hatalar ise müşterinin bilgisi dahilinde olabileceği için hem yüksek maliyetli hem de itibar zedeleyici bir şekil alabilir.
Test maliyetleri hataların projede tespit edildiği aşamaya bağlı olarak çok değişkenlik göstermektedir. Önemli olan hataları yazılım geliştirme yaşam döngüsünün ilk adımlarından başlayarak gidermeye yönelik test aşamaları ile yürütmek, yönetmek ve raporlamaktır. Bu şekilde amaçlanan kalite ve standart seviyesine ulaşmak ve süreçleri iyileştirmek mümkündür.
Detaylı bilgi için tıklayınız: http://mirsis.com.tr/TestHizmeti
Yazılım Güvenliği Yönetimi Eğitimimiz aşağıdaki konu başlıklarını içermektedir:
Güvenli Yazılım Geliştirme Modelleri
-TOUCHPOINTS
-Secure Development Lifecycle (Microsoft)
-CLASP (Comprehensive, Lightweight Application Security Process)
Risk Yönetimi
Güvenlik Gereksinim Analizi
Teknik Riskler
Sızma Testi ve Statik Kod Analizi
Güvenlik Operasyonu
Dr. Mustafa DEĞERLİ - 2017 - Etkili bir kalite güvence sürecinin parçası olar...Dr. Mustafa Değerli
Değerli, M., Özbudak, E. K., Aytaç, A. A. ve Demirel, Ö. E. (2017). Etkili bir kalite güvence sürecinin parçası olarak proje seviyesindeki denetimler: Uygulanan pratikler ve öğrenilen dersler. On Birinci Ulusal Yazılım Mühendisliği Sempozyumu (UYMS 2017). Bildiri Kitabı, 1980, 391-402. ISSN: 1613-0073
Etkili Bir Kalite Güvence Sürecinin Parçası Olarak Proje Seviyesindeki Deneti...Dr. Mustafa Değerli
Değerli, M. (2017). Etkili Bir Kalite Güvence Sürecinin Parçası Olarak Proje Seviyesindeki Denetimler: Uygulanan Pratikler ve Öğrenilen Dersler, 1980, 391-402. ISSN: 1613-0073- http://ceur-ws.org/Vol-1980
Bölüm 1: Giriş (Introduction)
Bölüm 2: Hata Ne Zaman Tespit Edilebilir? (When Can a Defect be Detected?)
Bölüm 3: Hata Raporu Alanları (Defect Report Fields)
Bölüm 4: Hata Sınıflandırma ( Defect Classification)
Bölüm 5: Kök Neden (Ana Neden) Analizi (Root Cause Analysis)
Bölüm 6: Soru Örnekleri
Bir CMMI Seviye 5 Organizasyonel Performans Yönetim Projesi Örneği: Kod Kalit...Deniz Gungor
Bu sunum UYMS (Ulusal Yazılım Mühendisliği Sempozyumu) 2017 Antalya’da sunulan `Bir CMMI Seviye 5 Organizasyonel Performans Yönetim Projesi Örneği: Kod Kalitesini İyileştirmek ` başlıklı makalenin sunumudur.
Makaleye ulaşmak için aşağıdaki linke tıklayınız.
http://ceur-ws.org/Vol-1980/UYMS17_paper_86.pdf
*****
This presentation is a presentation of the article titled "A CMMI Level 5 Organizational Performance Management Project Example: Improving Code Quality" presented at the UYMS (National Software Engineering Symposium) 2017 Antalya.
Click on the link below to access the article or published paper.
2. Test Nedir?
Bir sistemin ya da birimin, belirli şartları yerine getirip
getirmediğini bulmak niyetiyle değerlendirilmesi
işlemidir.
Bir uygulamada var olan özellikler ile olması gereken
özellikleri analiz etmeyi sağlar.
3. Testleri Kimler Yapar?
Yazılımcı
Yazılım Destek/Test Personeli
Proje Yöneticisi
Son Kullnıcı
4. Teste Ne Zaman Başlarsınız? >>
Testlere erken başlanılması son kullanıcıya teslim
edilen yazılımın hatasız olmasını sağlar, yeniden
düzenleme işlemleri için gereken zamanı ve maliyeti
azaltır.
Testler yazılım geliştirme yaşam döngüsünün bir
aşaması olan «gereksinimleri toplama» aşamasında
başlayabilir ve bu yazılımın teslimine kadar devam
edebilir.
5. Teste Ne Zaman Başlarsınız?
İhtiyaçların toplanması aşamasında gereksinimlerin
analizi ve doğrulanması da test olarak kabul edilir.
Tasarım aşamasında tasarımın gözden geçirilmesi
de test olarak kabul edilir.
Kodun tamamlanmasından sonra geliştirici tarafından
yapılan kontroller de test olarak kabul edilir.
6. Testler Ne Zaman Bitirilir?
Testin sonsuz bir süreç olduğu ve hiç kimsenin bir yazılımın
%100 test edildiğini iddia edememesi nedeniyle, testi ne
zaman durduracağınızı belirlemek zordur.
Aşağıdaki hususlar göz önüne alınarak buna karar verilebilir;
Belirlenen test case’lerin başarılı çalıştırılmasının tamamlanması
Belirli bir noktaya kadar fonksiyonel testlerin tamamlanması
Hata sayısının belirli bir seviyenin altına inmesi ve yüksek öncelikli
hata tespit edilmemesi
Yönetim kararı
8. Test Süreci Çok Maliyetlidir
Yazılımı geliştirirken yapılan test için ödediğiniz
bedel, bakım ve düzeltme aşamasında ödediğiniz
bedelden daha azdır.
Erken yapılan testler zaman ve maliyet açısından
tasarruf sağlar, ancak test edilmeden maliyeti
düşürmeye çalışmak uygulamanın yanlış
geliştirilmesi ile ürünün işe yaramaz hale gelmesini
sağlar.
9. Test Yapmak Zaman Kaybıdır
SDLC Aşamaları gerçekleşirken, test yapmak zaman
kaybı değildir.
Bununla birlikte test aşamasında hataların tespit
edilip düzeltilmesi zaman alan fakat üretken bir
faaliyettir.
10. Sadece Tamamlanmış Ürünler Test
Edilebilir
Test yapmak source code’a bağlıdır fakat müşteri
isteklerinin gözden geçirilmesi ve test planlarının
oluşturulması source koddan bağımsızdır.
Ancak iterative veya incremental SDLC yaklaşımı
testlerin projeninin tamamının bitmesinden bağımsız
olarak yürütülmesini kolaylaştırır.
11. Tümüyle Test Etmek Mümkündür
Müşteri ya da test eden kişilerin eksiksiz testin
mümkün olduğunu düşünmesi bir sorun haline
gelebilir. Tüm durumların ele alınmış olması
mümkündür fakat eksiksiz test edilmesi asla
gerçekleşemez.
SDLC sürecinde hiç test edilmeyen senaryolar
olabilir. Bu durum proje kullanıma başlandığında
ortaya çıkabilir.
12. Test Edilmiş Yazılım Hatasızdır
Bu müşterilerin, proje yöneticilerinin ve diğer
yöneticilerin inandığı ortak bir yanılgıdır.
Uygulamayı mükemmel bir test sürecinden geçirseniz
bile kimse uygulamanın %100 hatasız olduğunu iddia
edemez.
13. Kusurlar, Test Yapan Kişilerden
Kaynaklanmaktadır
Testler tamamlandıktan sonra bile uygulamada kalan
hatalar için test yapan kişileri suçlamak doğru bir
yaklaşım değildir.
Bu durum zaman, maliyet ve gereksinimleri
değiştiren kısıtlara bağlıdır.
Bununla birlikte, test stratejisi hataların test ekibi
tarafından kaçırılmasına neden olabilir.
14. Test Yapanlar Ürünün Kalitesinden
Sorumludur
Uygulamanın kalitesinden sadece test yapanların ve
test ekibinin sorumlu olması çok yaygın bir yanılgıdır.
Test yapanların sorumluluğu hataların belirlenmesini
sağlamak ve bunun ilgililere bildirmektir. Hataların
düzeltilip düzeltilmeyeceği kararını vermezler.
Projenin zamanında tamamlanması test ekibi
üzerinde fazlaca baskıya sebep olur. Çünkü oluşan
herhangi bir hatadan sorumlu tutulabilirler.
15. Test Otomasyonu Zaman Maliyetini Düşürmek İçin
Mümkün Olan Her Yerde Kullanılabilir
Test otomasyonunun test zamanlarını azalttığı
doğrudur, fakat yazılım geliştirme aşamasında
herhangi bir zamanda test otomasyonuna başlamak
mümkün değildir.
Test otomasyonu, uygulama manuel test edilip belirli
bir kararlılığa ulaştığında başlatılır. Gereksinimler
değişmeye devam ederse test otomasyonu
kullanılamaz hale gelir.
16. Herhangi Birisi Uygulama Testi
Yapabilir
IT sektörünün dışındaki kişiler, testlerin herhangi birisi
tarafından yapılabileceğini düşünürler. Hatta test yapma
işinin yaratıcılık gerektiren bir iş olmadığını da düşünürler.
Fakat testçiler bunun bir safsata olduğunu çok iyi bilirler.
Alternatif senaryoları düşünerek, uygulamayı hataya
düşürecek durumları ortaya çıkarmak uygulamayı
geliştiren/tasarlayan kişiler tarafından yapılamaz.
17. Kalite Güvence(QA), Kalite
Kontrol(QC), Test
Bu konular her ne kadar bir araya gelmiş ve bir
dereceye kadar aynı faaliyetler olarak görülse de
belirgin farklılıkları vardır.
18. Kalite Güvence(QA), Kalite
Kontrol(QC), Test
Kalite Güvence Kalite Kontrol Test
KG geliştirilmesi yapılmış
yazılımların doğruluğuna
ve amaçlanan gerekliliklere
bağlı olarak süreçlerin,
prosedürlerin ve
standartların
uygulanmasını sağlayan
faaliyetleri içerir.
Belgelenmiş
gereksinimlerle ilgili olarak
gelişmiş yazılımın
doğrulanmasını sağlar.
Yazılımdaki hataların
tanımlanmasını sağlayan
faaliyettir.
19. Kalite Güvence(QA), Kalite
Kontrol(QC), Test
Kalite Güvence Kalite Kontrol Test
Sistem üzerinde fiili test
yapmak yerine süreçlere
ve prosedürlere odaklanır.
Müşteri gereksinimlerinin
doğru tanımlanıp
tanımlanmadığını kontrol
eder.
Tanımlanan prosedürlerin
uygulanması yoluyla hata /
eksikleri tespit etmek
amacıyla testleri yapar.
Gerçek teste odaklanır.
Süreç odaklıdır. Prosedürleri doğrulamaya
odaklanır.
Sürecin işlemesinde
oluşacak hataları
önlemeye odaklanır.
20. Kalite Güvence(QA), Kalite
Kontrol(QC), Test
Kalite Güvence Kalite Kontrol Test
Software Test Life
Cycle(STLC)’nin bir alt
kümesidir.
KG’nin bir alt kümesidir. KK’ün bir alt kümesidir.
21. Test Çeşitleri
Functional Test : Yazılımın belirtilen müşteri gereksinimleri karşılayıp karşılamadığını tespit etmeyi sağlar.
Unit Test
Source kodun belirli bölümlerini test etme yöntemidir.
Integration Test
Uygulamanın birleşik bölümlerinin birlikte doğru şekilde çalışıp çalışmadığını test etme yöntemidir.
System Test
Sistemin tümünü test etmeyi hedefler, tüm sistemin istenen kalite standartına uygun olup olmadığını kontrol etmeyi sağlar.
Regression Test
Sistemde yapılan bir geliştirmenin ya da hata gidermenin sistemin çalışan diğer bölümlerinde bir hataya sebep olup
olmadığını anlamayı sağlayan test yöntemidir.
Acceptance Test
Yapılan geliştirmenin istenen özelliklere uygun olup olmadığını, müşterinin gereksinimlerini karşılayıp karşılamadığını tespit
edildiği test yöntemidir.
Alpha Test
Geliştiriciler ve QA ekipleri için ilk test aşamasıdır. Unit test, integration test ve system test alfa testi olarak tanımlanabilir.
Test edilecek konular; Yazım hataları, bozuk bağlantılar, kötü yönlendirmeler vb.
Beta Test
Yayın öncesi test olarak adlandırılabilir. Uygulamayı kullanacak kitleden bir örnek kitle testi yapar. Yayın öncesi gerçek
kullanıcıların beklentilerini tespit etmeyi sağlar. Yazılımın kalitesini istenen düzeye çekmeyi hedefler.
22. Test Çeşitleri
Non-Functional Test
Performans Test : Yazılımdaki oluşabilecek tıkanıklığı veya performans sorununu tespit etmeyi
sağlar.
Hata sebepleri; Ağ gecikmesi, client sayısı, db transaction sayısı, load balancing problemi, veri işleme
Performans testi; hız(response time), kapasite, stabilite ve ölçeklenebilirlik açısından önemli ve
zorunludur.
Load Test
Bu test normal ve yoğun zamanlarda yazılımın maks. kapasitesini ve davranışını tespit etmeyi sağlar.
Stress Test
Anormal koşullar altında yazılımın davranışını test etmeyi sağlar. Örneğin db bağlantısının kesilmesi
veya limitlerin ötesinde bir yük uygulamak gibi durumlar olabilir. Bu testin amacı yükü sisteme
uygulayarak yazılımın kırılma noktasını belirlemektir. Bu test; ağ bağlantılarını rastgele kapatarak yada
yeniden başlatarak, veritabanını kapatıp açarak veya yazılımın çalıştığı makinada sistem kaynaklarını
tüketecek farklı uygulamalar çalıştırılarak yapılabilir.
Usability Test
Kullanılabilirlik testi, kullanıcıların kullanımları ve çalışma şekillerini gözlemleyerek yazılımın daha iyi
kullanım kolaylığına sahip olup olmadığını tespit etmeyi sağlar. Yani bir sistemin kullanıcı dostu,
öğrenmesi kolay, hatırlanması kolay, kullanılması verimli, tatmin edici ve anlaşılması kolay olup
olmadığını anlamayı sağlar. Bu maddelerin sınırlarını çizen bazı ISO standartları ve kalite modelleri
mevcuttur(ISO-9126, ISO-9241-11, ISO-13407 ve IEEE).
23. Test Çeşitleri
Security Test
Uygulamayı güvenlik açısından herhangi bir hataya sahip olup
olmadığını test etmeyi sağlar. Aşağıdaki konulara dikkat edilmelidir;
Doğrulama, Yetkilendirme , Giriş kontrolü ve doğrulama, SQL ekleme
saldırıları, Enjeksiyon kusurları, Oturum yönetimi sorunları, Siteler arası
komut dosyası çalıştırma saldırıları, Dizin traversal saldırıları
Portability Test
Taşınabilirlik testi, yazılımın tekrar kullanılabilirliğini sağlamak amacıyla
test edilmesini sağlar. Bu testin temel amacı farklı donanım, işletim
sistemi ve browserlarda çalışabilirliğini test etmektir.
Aşağıdaki stratejiler izlenebilir;
Yüklü bir yazılmın bir bilgisayardan farklı bir bilgisayara aktarma
Yazılımı farklı platformlarda çalıştırma