ISTQB-CTFL-Syllabusv4.pdf - Sertifikalı Test Uzmanı PDF

Sertifikalı Test Uzmanı Temel Seviye Ders Programı v4.0 International Software Testing Qualifications Board  Telif Hakkı Bildirimi Telif Hakkı Bildirimi © International Software Testing Qualifications Board (bundan böyle ISTQB® olarak Revizyon GeçmişiTelif Hakkı Bildirimi anılacak...

Sertifikalı Test Uzmanı Temel Seviye Ders Programı v4.0 International Software Testing Qualifications Board  Telif Hakkı Bildirimi Telif Hakkı Bildirimi © International Software Testing Qualifications Board (bundan böyle ISTQB® olarak Revizyon GeçmişiTelif Hakkı Bildirimi anılacaktır). ISTQB®, International Software Testing Qualifications Board'un tescilli ticari markasıdır. Telif Hakkı © 2023 Temel Seviye Ders Programı v4.0 yazarları: Renzo Cerquozzi, Wim Decoutere, Revizyon Klaudia Geçmişi Dussa-Zieger, Jean-François Riverin, Arnika Hryszko, Martin Klonk, Michaël Pilaeten, Meile Posthuma, Stuart Reid, Eric Riou du Cosquer (Başkan), Adam Roman, Lucjan Stapp, Stephanie Ulrich (Başkan Yardımcısı), Eshraka Zakaria. İçindekiler TablosuRevizyon GeçmişiTelif Hakkı Bildirimi Telif Hakkı © 2019; 2019 güncellemesi için yazarlar Klaus Olsen (Başkan), Meile Posthuma ve Stephanie Ulrich. Revizyon GeçmişiTelif Hakkı Bildirimi Telif Hakkı © 2018; 2018 güncellemesi için yazarlar Klaus Olsen (Başkan), Tauhida Parveen (Başkan Yardımcısı), Rex Black (Proje Yöneticisi), Debra Friedenberg, Matthias Hamburg, Judy McKay, Meile Telif Hakkı Posthuma, Bildirimi Hans Schaefer, Radoslaw Smilgin, Mike Smith, Steve Toms, Stephanie Ulrich, Marie Walsh ve Eshraka Zakaria. Telif Hakkı © 2011; 2011 güncellemesi için yazarlar Thomas Müller (Başkan), Debra Friedenberg ve Revizyon GeçmişiTelif Hakkı Bildirimi ISTQB Temel Seviye Çalışma Grubu (ÇG). Telif Hakkı © 2010; 2010 güncellemesi için yazarlar Thomas Müller (Başkan), Armin Beer, Martin Klonk Revizyon ve Rahul Verma.Geçmişi Telif Hakkı © 2007; 2007 güncellemesi için yazarlar Thomas Müller (Başkan), Dorothy Graham, Debra İçindekiler Friedenberg TablosuRevizyon ve Erik van Veenendaal. GeçmişiTelif Hakkı Bildirimi Telif Hakkı © 2005; 2005 güncellemesi için yazarlar Thomas Müller (Başkan), Rex Black, Sigrid Eldh, Revizyon Dorothy Graham,GeçmişiTelif Hakkı Klaus Olsen, Maaret Bildirimi Pyhäjärvi, Geoff Thompson ve Erik van Veenendaal. Tüm hakları saklıdır. Yazarlar, telif hakkını International ISTQB®'ye devretmektedir. Yazarlar (mevcut telif hakkı sahipleri olarak) ve ISTQB® (gelecekteki telif hakkı sahibi olarak) aşağıdaki kullanım koşullarını Telifetmişlerdir: kabul Hakkı Bildirimi Bu belgeden alınacak ve ticari kullanım amacı olmayan kısımlar, kaynağı belirtilmek şartıyla Revizyon GeçmişiTelif kopyalanabilir. Hakkı Herhangi bir eğitim kurumu, Bildirimi yazarların ve ISTQB®'nin bu ders programının kaynağı ve telif hakkı sahibi olduklarını belirtmeleri durumunda, bu ders programını bir eğitim kursuna temel oluşturmak için kullanabilir; ancak böyle bir eğitim kursunun herhangi bir reklamı, yalnızca eğitim Revizyon Geçmişi materyallerinin ISTQB® tarafından tanınan bir üye kurula (member board) resmi olarak akredite ettirilmesinden sonra yapılabilir. İçindekiler TablosuRevizyon GeçmişiTelif Hakkı Bildirimi Herhangi bir kişi veya grup, yazarların ve ISTQB 'nin bu ders programının kaynağı ve telif hakkı ® sahibi olduğunu belirtmeleri şartıyla, bu ders programını makaleler ve kitaplar için temel olarak Revizyon kullanabilir. GeçmişiTelif Hakkı Bildirimi ISTQB®'nin yazılı izni alınmadan bu ders programının başka herhangi bir şekilde kullanılması Telif Hakkı Bildirimi yasaktır. Revizyon GeçmişiTelif ISTQB® tarafından Hakkı tanınan herhangi bir üyeBildirimi kurul, yukarıda belirtilen telif hakkı bildirimini ders programının tercüme edilmiş versiyonunda yeniden yayınlamak koşuluyla bu ders programını tercüme edebilir. Revizyon Geçmişi 2 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 İçindekiler TablosuRevizyon GeçmişiTelif Tel: +90 212 276 Hakkı 06 48 | Faks: +90 212 276 06 47 Bildirimi Revizyon GeçmişiTelif Hakkı Bildirimi Telif Hakkı Bildirimi  Revizyon Geçmişi İçindekiler Versiyon TablosuRevizyon Tarih Notlar Geçmişi CTFL v4.0 21.04.2023 CTFL v4.0 – Genel yayın versiyonu İçindekiler TablosuRevizyon Geçmişi CTFL v3.1.1 01.07.2021 CTFL v3.1.1 – Telif hakkı ve logo güncellemesi İçindekiler CTFL v3.1 TablosuRevizyon Geçmişi 11.11.2019 CTFL v3.1 – Minör güncellemeler içeren bakım sürümü ISTQB 2018 27.04.2018 CTFL v3.0 – Aday genel yayın versiyonu İçindekiler ISTQB 2011 TablosuRevizyon 1.04.2011 Geçmişi CTFL Ders Programı Bakım Sürümü ISTQB 2010 30.03.2010 CTFL Ders Programı Bakım Sürümü İçindekiler ISTQB 2007 TablosuRevizyon Geçmişi 01.05.2007 CTFL Ders Programı Bakım Sürümü ISTQB 2005 01.07.2005 Sertifikalı Test Uzmanı Temel Seviye Ders Programı v1.0 İçindekiler ASQF V2.2 TablosuRevizyon 07.2003 Geçmişi ASQF Ders Programı Temel Seviye Versiyon v2.2 "Yazılım Testleri için Temel Seviye Ders Programı" İçindekiler ISEB V2.0 TablosuRevizyon 25.02.1999 ISEB YazılımGeçmişi Testlerinin Temelleri Ders Programı v2.0 İçindekiler TablosuRevizyon Geçmişi İçindekiler TablosuRevizyon Geçmişi İçindekiler TablosuRevizyon Geçmişi İçindekiler TablosuRevizyon Geçmişi İçindekiler TablosuRevizyon Geçmişi İçindekiler TablosuRevizyon Geçmişi İçindekiler TablosuRevizyon Geçmişi İçindekiler TablosuRevizyon Geçmişi İçindekiler TablosuRevizyon Geçmişi İçindekiler TablosuRevizyon Geçmişi 3 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 İçindekiler TablosuRevizyon Geçmişi Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47 İçindekiler TablosuRevizyon Geçmişi İçindekiler TablosuRevizyon Geçmişi  Önsöz ISTQB® Sertifikalı Test Uzmanı Temel Seviye Ders Programının 2018 Türkçe versiyonunun yayınlamasının üzerinden yaklaşık 5 yıl geçti. Bu süre zarfında hem yazılım test sektöründe çok önemli gelişmeler oldu hem de sektör Türkiye’de ve dünyada yıllık ortalama %20 oranında bir ivmeyle büyüme kaydetti. Haziran 2023 itibariyle Türkiye’de ISTQB® sınavlarına giren katılımcı sayısı 10.000’i geçmiş, 5.000’den fazla katılımcı da sınavlarda başarılı olarak ISTQB® Uluslararası Sertifikalı Test Uzmanı sertifikalarını almaya hak kazanmıştır. Bu rakamlar dünya genelinde 1.3 milyondan fazla sınav ve 914.000’den fazla sertifikalı test uzmanı olarak karşımıza çıkmaktadır. Sınava giren katılımcıların şu an okumakta olduğunuz Temel Seviye Ders Programını en az bir kere okuduğu düşünülürse bu doküman dünyada en çok okunan yazılım test dokümanı olma unvanını büyük ihtimalle elinde tutmaktadır. İşte bu doküman değişen yazılım ve yazılım test dünyasındaki son gelişmeleri yansıtmak amacıyla ISTQB® tarafından revize edilerek, Nisan 2023’de bilişim sektörünün hizmetine sunulmuştur. Dokümanda özellikle Çevik yazılım geliştirme ve DevOps yaklaşımlarının teste etkisi göze çarpmaktadır. Yazılım Test ve Kalite Derneği çeviri çalışma grubu olarak bizler de bu değerli dokümanı sektör profesyonellerine sunmak amacıyla 2024 yılı içerisinde çalışmalarımıza başlayıp çeviriyi Mart 2024 itibariyle bitirmiş bulunmaktayız. Daha önceki versiyonların çevirisinde de belirttiğimiz üzere Türkçeleştirme çalışması yapılırken daha önceden dernek tarafından çevirisi yapılmış ISTQB® Yazılım Testi Terimler Sözlüğü baz alınmış ve çevirinin yazılım test sektöründe kullanılan güncel Türkçe'ye uygun olmasına dikkat edilmiştir. Bu özene rağmen dilin yaşayan bir varlık olduğu, sürekli değiştiği, İngilizcedeki bazı kelimelerin Türkçemizde tam karşılığının olmadığı ve yazılım test sektöründe terimlerin halen standartlaşmadığı göz ardı edilmemelidir. Bu kısıtlardan dolayı çevirinin yaşanan gelişmeler ışığında her zaman güncel olabilmesi için yeni gelişmeleri ve önerilerinizi [email protected] e-posta adresine gönderebilirsiniz. Yazılım Test ve Kalite Derneği kar amacı gütmemekte ve faaliyetlerini gönüllülerin katkılarıyla sağlamaktadır. Derneğin karı test etkinlikleri, test çalışmaları ve üniversite burslarına aktarılmaktadır. Bu dokümanı indirip okuyarak aslında hem kendinize hem yazılım test sektörüne hem de geleceğimiz olan gençlerimize yatırım yapmış olmaktasınız. Çevirinin Türkiye bilişim sektörüne faydalı olması dileğiyle. Yazılım Test ve Kalite Derneği Mart, 2024 4 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47 Teşekkür ISTQB® Sertifikalı Test Uzmanı Temel Seviye Ders Programının Türkçeleştirme çalışmasına katkıda bulunan Yazılım Test ve Kalite Derneği çeviri çalışma grubu üyelerine burada tekrar teşekkür etmek isteriz. Çalışma grubu üyeleri (alfabetik sıraya göre): Abdurrahman Akın Abdurrahman Karabacak Ahmet Esat Genç Alieren Dasdemir Alp Ekin Alparslan Yiğid Alper Turp Barış Küçük Burak Yakupoğlu Burcu Özel Çiğdem Aldan Didem Çolak Arslan Ece Kılıç Ecem Güney Elif Göktaş Elif Yağlıkçı Esra Karaarslan Gençay Genç Gülsüm Güngör Hakan Güvez Hasan Özyer İbrahim Seyfullah Babaarslan İdil Bilginturan Kader Çelik Kadir Tepecik Kağan Hazal Kocdemi L. Koray Yitmen Mahir Aldağ Mehmet Kıvanç Bayram Meltem Aydaş Mert Çalışkan Muhammet Topcu Mustafa Aydın Nergiz Gençaslan Salim öncü Serkan Cura Zeynep Teke 5 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  Yazılım Test ve Kalite Derneği Hakkında (Turkish Testing Board – www.turkishtestingboard.org ) Yazılım Test ve Kalite Derneği, 2006 yılından bu yana Türkiye bilişim sektöründe yazılım testi farkındalığının artması ve gelişmesi için kar amacı gütmeden gönüllü bir şekilde aşağıdaki faaliyetleri gerçekleştirmektedir: Uluslararası Sertifikasyon Sınavları Dernek uluslararası ISTQB® sertifika sınavlarını gerçekleştirerek sınavlarda başarılı olan katılımcılara uluslararası geçerliliği olan sertifikalar vermektedir. 2006 yılından bu yana 10.000’den fazla test uzmanı adayı derneğe başvurarak sertifika sınavlarına girmiştir. Dernek bünyesinde Türkçe ve İngilizce olarak düzenlenmekte olan sertifika sınavları: ISTQB® Uluslararası Sertifikalı Temel Seviye Yazılım Test Uzmanı Sınavı ISTQB® Uluslararası Sertifikalı Temel Seviye Çevik Test Uzmanı Sınavı ISTQB® Uluslararası Sertifikalı İleri Seviye – Test Analisti Sınavı ISTQB® Uluslararası Sertifikalı İleri Seviye – Teknik Test Analisti Sınavı ISTQB® Uluslararası Sertifikalı İleri Seviye – Test Yöneticisi Sınavı ISTQB® Uluslararası Sertifikalı Performans Testi Sınavı ISTQB® Uluslararası Sertifikalı Test Otomasyon Mühendisi Sınavı ISTQB® Uluslararası Sertifikalı Yapay Zeka Sınavı ISTQB® Uluslararası Sertifikalı Mobil Uygulama Sınavı ISTQB® Uluslararası Sertifikalı Otomotiv Yazılım Sınavı Uluslararası TestIstanbul Konferansları – www.testistanbul.org Dernek, 2010 yılından bu yana Uluslararası TestIstanbul Konferanslarını düzenlemektedir. Geçtiğimiz 15 konferansta 50’den fazla ülkeden, 70’den fazla konuşmacı ve 7.000’den fazla katılımcı ağırlanmıştır. Paneller Dernek, yazılım test sektörünün gelişimi için sektör veya konu bazlı paneller organize etmektedir. Bu panellere şu ana kadar 1.000’den fazla profesyonel katılım göstermiştir. Şimdiye kadar düzenlenen paneller: TestFintech, TestDefence, TestGames, TestInsurance, TestAnkara, Testİzmir, Test Finance, Turkey Software Quality Report (TSQR) Dernek tarafından 2011 yılından itibaren yüzlerce bilişim profesyoneli ve akademisyeninin katılımıyla her yıl düzenlenen anket sonuçlarının değerlendirilmesiyle hazırlanan, Türkiye bilişim sektörüne yön verir nitelikte çıkarımların olduğu rapordur. İngilizce yayınlanan rapor tüm ISTQB® üye dernekleri 6 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  aracılığıyla 100'den fazla ülkedeki bilişim profesyoneline ulaşmaktadır. ISTQB® Worldwide Software Testing Practices Report (WSTPR) ISTQB® tarafından 100’den fazla ülkeden binlerce bilişim profesyoneli ve akademisyeninin katılımıyla düzenlenen anket sonuçlarının değerlendirilmesiyle hazırlanan, dünya bilişim sektörüne yön verir nitelikte çıkarımların olduğu rapordur. Türkçeleştirme Çalışmaları Uluslararası yazılım test terminolojisinin ülkemize kazandırılması için dernek bünyesinde yer alan gönüllü çeviri grubu ISTQB® dokümanlarının çevirisi üzerinde çalışmaktadır. Şu ana kadar çevrilen dokümanlar: ISTQB® Uluslararası Sertifikalı Temel Seviye Yazılım Test Uzmanı Ders Programı v4.0 ISTQB® Uluslararası Sertifikalı Temel Seviye Yazılım Test Uzmanı Ders Programı 2018 ISTQB® Uluslararası Sertifikalı Temel Seviye Yazılım Test Uzmanı Ders Programı 2011 ISTQB® Yazılım Testi Terimler Sözlüğü ISTQB® Uluslararası Sertifikalı İleri Seviye – Test Analisti Ders Programı Bir Ejderhadan Yazılım Test Dersi Çevik Bir Dünyada TMMi Burslar Dernek her yıl karından belli bir miktarı T.C. Üniversitelerinin Bilgisayar/Yazılım Mühendisliği ve Bilgisayar Programcılığı bölümlerinde okumakta olan başarılı ve ihtiyaç sahibi öğrencilere burs olarak aktarmaktadır. Mart 2024 itibariyle burs sağlanan toplam bursiyer sayısı 87’e ulaşmıştır. 7 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  İçindekiler Tablosu Telif Hakkı Bildirimi............................................................................................................................. 2 Revizyon Geçmişi............................................................................................................................... 3 Önsöz................................................................................................................................................... 4 Yazılım Test ve Kalite Derneği Hakkında.......................................................................................... 6 İçindekiler Tablosu.............................................................................................................................. 8 Teşekkür............................................................................................................................................ 11 0. Giriş................................................................................................................................................ 13 0.1. Bu Ders Programının Amacı.................................................................................................. 13 0.2. Yazılım Testlerinde Sertifikalı Test Uzmanı Temel Seviye.................................................. 13 0.3. Test Uzmanları için Kariyer Yolu.......................................................................................... 13 0.4. İş Çıktıları................................................................................................................................ 14 0.5. Sınav Kapsamındaki Öğrenme Hedefleri ve Bilginin Bilişsel Seviyesi............................. 14 0.6. Temel Seviye Sertifika Sınavı................................................................................................ 15 0.7. Akreditasyon........................................................................................................................... 15 0.8. Standartların Ele Alınması..................................................................................................... 15 0.9. Güncel Kalmak........................................................................................................................ 15 0.10. Ayrıntı Düzeyi........................................................................................................................ 15 0.11. Bu Ders Programı Nasıl Düzenlendi................................................................................... 15 1. Yazılım Testinin Temelleri – 180 dakika...................................................................................... 17 1.1. Yazılım Testi Nedir?............................................................................................................... 18 1.1.1. Test Hedefleri..................................................................................................................... 18 1.1.2. Yazılım Testi ve Hata Ayıklama........................................................................................ 19 1.2. Yazılım Testi Neden Gereklidir?............................................................................................ 19 1.2.1. Yazılım Testinin Başarıya Katkısı...................................................................................... 19 1.2.2. Test Etme ve Kalite Güvence (KG).................................................................................. 19 1.2.3. İnsan Hataları, Hatalar, Arızalar ve Kök Nedenler............................................................ 20 1.3. Test Prensipleri....................................................................................................................... 20 1.4. Test Aktiviteleri, Test Çalışma Ürünleri ve Test Rolleri...................................................... 21 1.4.1. Test Aktiviteleri ve Görevleri.............................................................................................. 21 1.4.2. Proje Bağlamında Test Süreci........................................................................................... 22 1.4.3. Test Çalışma Ürünleri........................................................................................................ 22 8 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  1.4.4. Test Esası ve Arasında İzlenebilirlik................................................................................. 23 1.4.5. Test Etme Sürecindeki Roller............................................................................................ 24 1.5. Test Etme Sürecinde Gerekli Beceriler ve İyi Uygulamalar................................................ 24 1.5.1. Test Etme Sürecinde Gerekli Genel Beceriler................................................................... 24 1.5.2. Tüm Ekip Yaklaşımı........................................................................................................... 25 1.5.3. Testin Bağımsızlığı............................................................................................................ 25 2. Yazılım Geliştirme Yaşam Döngüsü Boyunca Test – 130 dakika............................................. 26 2.1. Yazılım Geliştirme Yaşam Döngüsü Bağlamında Test........................................................ 27 2.1.1. Yazılım Geliştirme Yaşam Döngüsünün Test Üzerindeki Etkisi........................................ 27 2.1.2. Yazılım Geliştirme Yaşam Döngüsü ve İyi Test Etme Uygulamaları................................ 27 2.1.3. Yazılım Geliştirme Faktörü Olarak Test............................................................................. 28 2.1.4. DevOps ve Test Etme....................................................................................................... 28 2.1.5. Shift-Left Yaklaşımı............................................................................................................ 29 2.1.6. Geçmişe Dönük Öğeler ve Süreç İyileştirmesi................................................................... 29 2.2. Test Seviyeleri ve Test Çeşitleri............................................................................................ 30 2.2.1. Test Seviyeleri................................................................................................................... 30 2.2.2. Test Çeşitleri...................................................................................................................... 31 2.2.3. Onaylama Testleri ve Regresyon Testleri.......................................................................... 32 2.3. Bakım Testleri......................................................................................................................... 33 3. Statik Testler – 80 dakika............................................................................................................. 34 3.1. Statik Testin Temelleri........................................................................................................... 35 3.1.1. Statik Testlerle İncelenebilir Çalışma Ürünler................................................................... 35 3.1.2. Statik Testin Önemi........................................................................................................... 35 3.1.3. Statik Test ve Dinamik Test Arasındaki Farklar................................................................. 36 3.2. Geri Bildirim ve Gözden Geçirme Süreci............................................................................. 36 3.2.1. Erken ve Sık Paydaş Geri Bildiriminin Faydaları.............................................................. 36 3.2.2. Gözden Geçirme Süreci Faaliyetler.................................................................................. 37 3.2.3. Gözden Geçirmede Roller ve Sorumluluklar...................................................................... 37 3.2.4. Gözden Geçirme Çeşitleri................................................................................................. 38 3.2.5. Gözden Geçirmelerin Başarı Faktörleri.............................................................................. 38 4. Test Analizi ve Tasarımı – 390 dakika......................................................................................... 40 4.1. Test Tekniklerine Genel Bakış............................................................................................... 41 4.2. Kara Kutu Test Teknikler....................................................................................................... 41 4.2.1. Denklik Paylarına Ayırma.................................................................................................. 41 4.2.2 Sınır Değer Analizi............................................................................................................ 42 4.2.3. Karar Tablosu Testleri........................................................................................................ 43 4.2.4. Durum Geçişi Testleri........................................................................................................ 43 4.3. Beyaz Kutu Test Teknikleri.................................................................................................... 44 4.3.1. Komut Testleri ve Komut Kapsama Yüzdesi.................................................................... 44 4.3.2. Dal Testi ve Dal Kapsamı................................................................................................. 45 4.3.3. Beyaz Kutu Testinin Önemi............................................................................................... 45 9 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  4.4. Tecrübeye Dayalı Test Teknikleri......................................................................................... 45 4.4.1. Hata Tahminleme.............................................................................................................. 45 4.4.2. Keşif Testi.......................................................................................................................... 46 4.4.3. Kontrol Listesine Dayalı Testler......................................................................................... 46 4.5. İş Birliğine Dayalı Test Yaklaşımları..................................................................................... 47 4.5.1. İş Birliğine Dayalı Kullanıcı Hikayesi Yazımı..................................................................... 47 4.5.2. Kabul Kriterleri.................................................................................................................. 47 4.5.3. Kabul Testi Güdümlü Yazılım Geliştirme (ATDD).............................................................. 48 5. Test Aktivitelerini Yönetme – 335 dakika.................................................................................... 49 5.1. Test Planlama......................................................................................................................... 50 5.1.1. Test Planının Amacı ve İçeriği.......................................................................................... 50 5.1.2. Test Uzmanının Döngü ve Sürüm Planlamasına Katkısı.................................................. 50 5.1.3. Giriş Kriterleri ve Çıkış Kriterleri......................................................................................... 51 5.1.4. Tahminleme Teknikleri...................................................................................................... 51 5.1.5. Test Senaryosu Önceliklendirme...................................................................................... 52 5.1.6. Test Piramidi...................................................................................................................... 52 5.1.7. Test Çeyrekleri................................................................................................................... 53 5.2. Risk Yönetimi.......................................................................................................................... 53 5.2.1. Risk Tanımı ve Risk Özellikleri......................................................................................... 53 5.2.2. Proje Riskleri ve Ürün Riskleri........................................................................................... 54 5.2.3. Ürün Riski Analizi............................................................................................................... 54 5.2.4. Ürün Riski Kontrolü........................................................................................................... 55 5.3. Test Gözetimi, Test Kontrol ve Test Tamamlama................................................................ 55 5.3.1. Yazılım Testlerinde Kullanılan Metrikler............................................................................ 56 5.3.2. Test Raporlarının Amacı, İçeriği ve Hedef Kitlesi............................................................. 56 5.3.3. Testin Durumunun Bildirilmesi........................................................................................... 57 5.4. Yapılandırma Yönetimi........................................................................................................... 57 5.5. Hata Yönetimi.......................................................................................................................... 58 6. Test Araçları – 20 dakika.............................................................................................................. 60 6.1. Yazılım Testleri için Araç Desteği......................................................................................... 61 6.2. Test Otomasyonunun Faydaları ve Riskleri......................................................................... 61 7. Referanslar.................................................................................................................................... 63 8. Ek A – Öğrenme Hedefleri/Bilginin Bilişsel Seviyesi................................................................. 66 9. Ek B – Öğrenme Hedefleriyle İş Çıktıları izlenebilirlik matrisi.................................................. 67 10. Ek C – Sürüm Notları.................................................................................................................. 73 11. Dizin.............................................................................................................................................. 75 10 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  Teşekkür Bu doküman ISTQB® Genel Kurulu tarafından 21 Nisan 2023'te resmi olarak yayınlanmıştır. Doküman, ISTQB Temel Seviye ve Çevik Çalışma Gruplarından bir ekip tarafından hazırlanmıştır: Laura Albert, Renzo Cerquozzi (Başkan Yardımcısı), Wim Decoutere, Klaudia Dussa-Zieger, Chintaka Indikadahena, Arnika Hryszko, Martin Klonk, Kenji Onishi, Michaël Pilaeten (Eş Başkan), Meile Posthuma, Gandhinee Rajkomar, Stuart Reid, Eric Riou du Cosquer (Eş Başkan), Jean-François Riverin, Adam Roman, Lucjan Stapp, Stephanie Ulrich (Başkan Yardımcısı), Eshraka Zakaria. Ekip, teknik gözden geçirme için Stuart Reid, Patricia McQuaid ve Leanne Howard ile önerileri ve girdileri için gözden geçirme ekibi ve Üye Kurullara teşekkür eder. Bu ders programının gözden geçirilmesi, yorumlanması ve oylanmasında aşağıdaki kişiler yer almıştır: Adam Roman, Adam Scierski, Ágota Horváth, Ainsley Rood, Ale Rebon Portillo, Alessandro Collino, Alexander Alexandrov, Amanda Logue, Ana Ochoa, André Baumann, André Verschelling, Andreas Spillner, Anna Miazek, Armin Born, Arnd Pehl, Arne Becher, Attila Gyúri, Attila Kovács, Beata Karpinska, Benjamin Timmermans, Blair Mo, Carsten Weise, Chinthaka Indikadahena, Chris Van Bael, Ciaran O'Leary, Claude Zhang, Cristina Sobrero, Dandan Zheng, Dani Almog, Daniel Säther, Daniel van der Zwan, Danilo Magli, Darvay Tamás Béla, Dawn Haynes, Dena Pauletti, Dénes Medzihradszky, Doris Dötzer, Dot Graham, Edward Weller, Erhardt Wunderlich, Eric Riou Du Cosquer, Florian Fieber, Fran O'Hara, François Vaillancourt, Frans Dijkman, Gabriele Haller, Gary Mogyorodi, Georg Sehl, Géza Bujdosó, Giancarlo Tomasig, Giorgio Pisani, Gustavo Márquez Sosa, Helmut Pichler, Hongbao Zhai, Horst Pohlmann, Ignacio Trejos, Ilia Kulakov, Ine Lutterman, Ingvar Nordström, Iosif Itkin, Jamie Mitchell, Jan Giesen, Jean-Francois Riverin, Joanna Kazun, Joanne Tremblay, Joëlle Genois, Johan Klintin, John Kurowski, Jörn Münzel, Judy McKay, Jürgen Beniermann, Karol Frühauf, Katalin Balla, Kevin Kooh, Klaudia Dussa- Zieger, Klaus Erlenbach, Klaus Olsen, Krisztián Miskó, Laura Albert, Liang Ren, Lijuan Wang, Lloyd Roden, Lucjan Stapp, Mahmoud Khalaili, Marek Majernik, Maria Clara Choucair, Mark Rutz, Markus Niehammer, Martin Klonk, Márton Siska, Matthew Gregg, Matthias Hamburg, Mattijs Kemmink, Maud Schlich, May Abu-Sbeit, Meile Posthuma, Mette Bruhn-Pedersen, Michal Tal, Michel Boies, Mike Smith, Miroslav Renda, Mohsen Ekssir, Monika Stocklein Olsen, Murian Song, Nicola De Rosa, Nikita Kalyani, Nishan Portoyan, Nitzan Goldenberg, Ole Chr. Hansen, Patricia McQuaid, Patricia Osorio, Paul Weymouth, Pawel Kwasik, Peter Zimmerer, Petr Neugebauer, Piet de Roo, Radoslaw Smilgin, Ralf Bongard, Ralf Reissing, Randall Rice, Rik Marselis, Rogier Ammerlaan, Sabine Gschwandtner, Sabine Uhde, Salinda Wickramasinghe, Salvatore Reale, Sammy Kolluru, Samuel Ouko, Stephanie Ulrich, Stuart Reid, Surabhi Bellani, Szilard Szell, Tamás Gergely, Tamás Horváth, Tatiana Sergeeva, Tauhida Parveen, Thaer Mustafa, Thomas Eisbrenner, Thomas Harms, Thomas Heller, Tobias Letzkus, Tomas Rosenqvist, Werner Lieblang, Yaron Tsubery, Zhenlei Zuo ve Zsolt Hargitai. ISTQB Temel Seviye Çalışma Grubu (Basım 2018): Klaus Olsen (Başkan), Tauhida Parveen (Başkan Yardımcısı), Rex Black (Proje Yöneticisi), Eshraka Zakaria, Debra Friedenberg, Ebbe Munk, Hans Schaefer, Judy McKay, Marie Walsh, Meile Posthuma, Mike Smith, Radoslaw Smilgin, Stephanie Ulrich, Steve Toms, Corne Kruger, Dani Almog, Eric Riou du Cosquer, Igal Levi, Johan Klintin, Kenji Onishi, Rashed Karim, Stevan Zivanovic, Sunny Kwon, Thomas Müller, Vipul Kocher, Yaron Tsubery ve önerileri için tüm Üye Kurullar. ISTQB Temel Seviye Çalışma Grubu (Basım 2011): Thomas Müller (Başkan), Debra Friedenberg. Çekirdek ekip, ders programının mevcut versiyonuna yönelik önerileri için gözden geçirme ekibine (Dan Almog, Armin Beer, Rex Black, Julie Gardiner, Judy McKay, Tuula Pääkkönen, Eric Riou du Cosquier Hans Schaefer, Stephanie Ulrich, Erik van Veenendaal) ve tüm Üye Kurullara teşekkür eder. 11 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  ISTQB Temel Seviye Çalışma Grubu (Basım 2010): Thomas Müller (Başkan), Rahul Verma, Martin Klonk ve Armin Beer. Çekirdek ekip, önerileri için gözden geçirme ekibine (Rex Black, Mette Bruhn-Pederson, Debra Friedenberg, Klaus Olsen, Judy McKay, Tuula Pääkkönen, Meile Posthuma, Hans Schaefer, Stephanie Ulrich, Pete Williams, Erik van Veenendaal) ve tüm Üye Kurullara teşekkür eder. ISTQB Temel Seviye Çalışma Grubu (Basım 2007): Thomas Müller (Başkan), Dorothy Graham, Debra Friedenberg ve Erik van Veenendaal. Çekirdek ekip, önerileri için gözden geçirme ekibine (Hans Schaefer, Stephanie Ulrich, Meile Posthuma, Anders Pettersson ve Wonil Kwon) ve tüm Üye Kurullara teşekkür eder. ISTQB Temel Seviye Çalışma Grubu (Basım 2005): Thomas Müller (Başkan), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson ve Erik van Veenendaal. Çekirdek ekip, önerileri için gözden geçirme ekibine ve tüm Üye Kurullara teşekkür eder. 12 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  0. Giriş 0.1. Bu Ders Programının Amacı Bu ders programının amacı temel seviye uluslararası yazılım test uzmanı niteliklerine yönelik bir çerçeve oluşturmaktır. ISTQB® aşağıda belirtilen kişi ve kurumlarla bu ders programını paylaşır: 1. Üye Kurullar: kendi dillerine çevirmeleri ve eğitim kurumlarını akredite etmeleri için. Üye Kurullar ders programını kendi özel dil ihtiyaçlarına göre uyarlayabilir ve yerel yayınlarına uyacak şekilde referansları değiştirebilir. 2. Sertifikasyon kurumları: bu ders programına yönelik kendi dillerinde sınav soruları hazırlamaları için. 3. Eğitim kurumları: eğitim materyali üretmeleri ve uygun öğretim yöntemlerini belirlemeleri için. 4. Sertifika programı adayları: (bir eğitim kursunun parçası olarak veya bağımsız olarak) sertifika sınavına hazırlanmaları için. 5. Uluslararası yazılım ve sistem mühendisliği topluluğu: yazılım ve sistem test uzmanlığı mesleğini ilerletmek ve kitap ve makalelere bir temel oluşturmak için. 0.2. Yazılım Testlerinde Sertifikalı Test Uzmanı - Temel Seviye Temel seviye ders programı yazılım testiyle uğraşan herkese yöneliktir. Buna, test uzmanları, test analistleri, test mühendisleri, test danışmanları, test yöneticileri, yazılımcı ve geliştirme ekibi üyeleri gibi çeşitli rollerdeki kişiler dahildir. Bu ders programı ayrıca proje yöneticileri, kalite yöneticileri, ürün sahipleri, yazılım geliştirme yöneticileri, iş analistleri, BT yöneticileri ve yönetim danışmanları gibi temel bir yazılım testi anlayışına sahip olmak isteyen herkes için de uygundur. Temel Seviye Sertifikasına sahip profesyoneller, ISTQB ileri seviye yazılım test ders programlarına devam edebilirler. 0.3. Test Uzmanları için Kariyer Yolu ISTQB® programı tam kapsamlı bir bilgi birikimi sunarak kariyerlerinin tüm aşamalarında test uzmanlarına destek sağlar. ISTQB® Temel Seviye sertifikasını alan kişiler Çekirdek İleri Seviyeler (Test Analisti, Teknik Test Analisti ve Test Yöneticisi) ve dolayısıyla Uzman Seviyesi (Test Yönetimi veya Test Sürecinin İyileştirilmesi) konularıyla da ilgilenebilirler. Çevik bir ortamda test uygulamaları ile ilgili becerilerini geliştirmek isteyenler Çevik Teknik Test Uzmanlığı ya da Ölçek Bazında Çevik Test Liderliği sertifika programlarını düşünebilirler. Uzman müfredatı, spesifik test yaklaşımları ve test aktivitelerine yer verilen (ör. test otomasyonu, yapay zeka (YZ) testi, model bazlı test, mobil uygulama testlerinde), spesifik test alanlarıyla ilgili (ör. performans testi, kullanılabilirlik testi, kabul testi, güvenlik testi) veya belirli sektörler için (ör. otomotiv veya oyun) test bilgilerini bir araya getiren alanlara ilişkin derinlemesine bir inceleme sunar. ISTQB'nin Sertifikalı Test Uzmanı Programı hakkında en güncel bilgiler için www.istqb.org adresini ziyaret edin. 13 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  0.4. İş Çıktıları Bu bölümde, Temel Seviye sertifikasyonu alan bir kişiden beklenen 14 iş çıktısına yer verilmiştir. Temel Seviye Sertifikalı Test Uzmanları... FL-BO1 Testin ne olduğunu ve neden yararlı olduğunu anlayabilir FL-BO2 Yazılım testinin temel kavramlarını anlayabilir FL-BO3 Testin bağlamına göre uygulanacak test yaklaşımını ve aktiviteleri tanımlayabilir FL-BO4 Dokümantasyonun kalitesini değerlendirebilir ve iyileştirebilir FL-BO5 Testin etkinliğini ve verimliliğini artırabilir FL-BO6 Test sürecini yazılım geliştirme yaşam döngüsüyle uyumlu hale getirebilir FL-BO7 Test yönetimi prensiplerini anlayabilir FL-BO8 Net ve anlaşılır hata raporları yazabilir ve bunları aktarabilir FL-BO9 Testle ilgili öncelik ve eforu etkileyen faktörleri anlayabilir FL-BO10 Disiplinler arası bir ekibin üyesi olarak çalışabilir FL-BO11 Test otomasyonuyla ilgili riskleri ve faydaları bilebilir FL-BO12 Test için gerekli olan becerileri tanımlayabilir FL-BO13 Riskin test üzerindeki etkisini anlayabilir FL-BO14 Testin ilerleme durumu ve test kalitesi hakkında etkin bir rapor sunabilir 0.5. Sınav Kapsamındaki Öğrenme Hedefleri ve Bilginin Bilişsel Seviyesi Öğrenme hedefleri iş hayatına yönelik çıktıları destekler ve Sertifikalı Test Uzmanı Temel Seviye sınavlarını hazırlamakta kullanılır. Genel olarak, bu ders programının 1-6. konularının tüm içeriği, K1 seviyesinde sınav kapsamındadır. Adaydan altı konudan herhangi birinde belirtilen bir anahtar kelimeyi veya kavramı bilmesi veya hatırlaması istenebilir. Özel öğrenme hedefi seviyeleri, her konunun başında gösterilmektedir ve aşağıdaki gibi sınıflandırılmıştır: K1: Hatırla K2: Anla K3: Uygula Öğrenme hedeflerine ilişkin diğer detaylar ve örneklere Ek A'da yer verilmiştir. Konu başlıklarının hemen altında anahtar kelimeler olarak listelenen tüm terimlerin tanımlarının öğrenme hedeflerinde açıkça belirtilmiş olmasa bile hatırlanması gerekmektedir (K1). 14 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  0.6. Temel Seviye Sertifika Sınavı Temel Seviye Sertifika sınavı bu ders programını baz almaktadır. Sınav sorularını cevaplamak için, bu ders programının birden fazla bölümünü baz alan ders materyali gerekebilir. Giriş ve ekler hariç olmak üzere bu ders programının tüm bölümleri sınav kapsamındadır. Bu ders programına bazı standartlar ve kitaplar referans olarak dahil edilmiştir (Konu 7); ancak bunların içerikleri, bu ders programında bahsedildiği kadar sınava dahildir. Bahsedilmeyen kısım ve içerikler sınav kapsamına dahil değildir. Temel Seviye Sınav Yapıları ve Kuralları belgesine bakın. 0.7. Akreditasyon Bir ISTQB® Üye Kurulu, ders materyali bu ders programına uygun olan eğitim kurumlarını akredite edebilir. Eğitim kurumları, akreditasyonu gerçekleştiren üye kuruldan veya kuruluştan akreditasyon rehberini edinmelidir. Akredite edilmiş bir kursun bu ders programına uygun olduğu kabul edilir ve kursun bir parçası olarak ISTQB® sınavına girilmesine izin verilir. Bu ders programının akreditasyon yönergeleri Süreç Yönetimi ve Uyumluluk Çalışma Grubu tarafından yayınlanan genel Akreditasyon Yönergelerine uygundur. 0.8. Standartların Ele Alınması Temel Seviye Ders Programında bazı standartlar referans gösterilmiştir (ör. IEEE veya ISO standartları). Bu referanslar bir çerçeve sunar (kalite karakteristiğine ilişkin ISO 25010 standardına dair referanslarda olduğu gibi) veya okuyucu tarafından istenirse bir ek bilgi kaynağı sunar. Standart belgeleri sınav kapsamında değildir. Standartlar hakkında daha fazla bilgi için konu 7'ye bakın. 0.9. Güncel Kalmak Yazılım sektörü hızla değişiyor. ISTQB çalışma grupları, bu değişiklikleri ele almak ve paydaşların ilgili ve güncel bilgilere erişmesini sağlamak için www.istqb.org web sitesinde destek belgelere ve standartlardaki değişikliklere ilişkin bağlantılar oluşturdular. Bu bilgiler Temel Seviye ders programı kapsamında sınava tabi değildir. 0.10. Ayrıntı Düzeyi Bu ders programındaki ayrıntı düzeyi, uluslararası düzeyde tutarlı kurs ve sınavlara olanak sağlar. Bu amaca ulaşmak için, ders programında aşağıdakilere yer verilmiştir: Temel Seviyenin amacını tanımlayan genel öğretim hedefleri Öğrencilerin hatırlamaları gereken bir terimler (anahtar kelimeler) listesi Her bilgi alanı için, ulaşılacak bilişsel öğrenme çıktılarını tanımlayan öğrenme hedefleri Genel kabul görmüş kaynaklara verilen referanslar dahil olmak üzere temel kavramların açıklaması Ders programı içeriği, yazılım testlerindeki tüm bilgi birikiminin bir açıklaması değildir; sadece temel seviye eğitim kurslarında ele alınacak ayrıntı düzeyini gösterir. Kullanılan yazılım geliştirme yaşam döngüsünden (YGYD) bağımsız olarak tüm yazılım projelerine uygulanabilecek test kavramları ve 15 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  tekniklerine odaklanır. 0.11. Bu Ders Programı Nasıl Düzenlendi Ders programı sınava tabi olan altı konudan oluşmaktadır. Her konuda yer alan en üstteki başlık o konu için ayrılan eğitim süresini belirtir. Zaman planlaması o konunun geneli için verilmiştir, daha detayda bir planlama verilmemiştir. Akredite eğitim kursları için ders programı aşağıdaki gibi altı konuya ayrılmış olup toplamda en az 1135 dakika (18 saat 55 dakika) kurs alınmasını gerektirir: Konu 1: Yazılım Testinin Temelleri (180 dakika) o Öğrenci, testle ilgili temel prensipleri, testin neden gerekli olduğunu ve test hedeflerinin ne olduğunu öğrenir. o Öğrenci, test sürecini, önemli test aktivitelerini ve test çalışma ürünlerinı anlar. o Öğrenci, test için gereken temel yetenekleri anlar. Konu 2: Yazılım Geliştirme Yaşam Döngüsü Boyunca Test (130 dakika) o Öğrenci, test etmenin farklı yazılım geliştirme yaklaşımlarına nasıl dahil edildiğini öğrenir. o Öğrenci, önce-test-et yaklaşımları ve DevOps konseptlerini öğrenir. o Öğrenci, farklı test seviyelerini, test çeşitlerini ve bakım testini öğrenir. Konu 3: Statik Testler (80 dakika) o Öğrenci, statik test temellerini, geri bildirim ve gözden geçirme sürecini öğrenir. Konu 4: Test Analizi ve Tasarımı (390 dakika) o Öğrenci, çeşitli yazılım çalışma ürünlerinden test senaryoları elde etmek için kara kutu, beyaz kutu ve tecrübeye dayalı test tekniklerini nasıl uygulayacağını öğrenir. o Öğrenci, iş birliğine dayalı test yaklaşımını öğrenir. Konu 5: Test Aktivitelerini Yönetme (335 dakika) o Öğrenci, genel anlamda testleri nasıl planlayacağını ve test eforunu nasıl tahmin edebileceğini öğrenir. o Öğrenci, risklerin test kapsamını nasıl etkileyebileceğini öğrenir. o Öğrenci, test aktivitelerini nasıl izleyip kontrol edebileceğini öğrenir. o Öğrenci, yapılandırma yönetiminin testleri nasıl desteklediğini öğrenir. o Öğrenci, hataları net ve anlaşılır şekilde nasıl rapor edebileceğini öğrenir. Konu 6: Test Araçları (20 dakika) o Öğrenci, araçları sınıflandırmayı ve test otomasyonuna ilişkin risk ve faydaları anlamayı öğrenir. 16 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  1. Yazılım Testinin Temelleri – 180 dakika Anahtar kelimeler kapsam, hata ayıklama, hata, insan hatası, arıza, kalite, kalite güvence, kök neden, test analizi, test esası, test senaryosu, test tamamlama, test koşulu, test kontrolü, test verisi, test tasarımı, test koşumu, test uyarlama, test gözetimi, test nesnesi, test hedefi, test planlama, test prosedürü, test sonucu, test etme, test çalışma ürünleri, sağlama, doğrulama Konu 1 Öğrenme Hedefleri: 1.1 Yazılım Testi Nedir? FL-1.1.1 (K1) Genel test hedeflerini tanımlamak FL-1.1.2 (K2) Test ile hata ayıklamanın farklarını belirtmek 1.2 Yazılım Testi Neden Gereklidir? FL-1.2.1 (K2) Örnekler vererek yazılım testinin neden gerekli olduğunu açıklamak FL-1.2.2 (K1) Yazılım testi ve kalite güvence arasındaki ilişkiyi anımsamak FL-1.2.3 (K2) Kök neden, insan hatası, hata ve arıza arasındaki farkı ayırt etmek 1.3 Test Prensipleri FL-1.3.1 (K2) Yedi test prensibini açıklamak 1.4 Test Aktiviteleri, Test çalışma ürünleri ve Test Rolleri FL-1.4.1 (K2) Farklı test aktivitelerini ve görevlerini özetlemek FL-1.4.2 (K2) Proje bağlamının test süreci üzerindeki etkisini açıklamak FL-1.4.3 (K2) Test aktivitelerini destekleyen test yazılımlarını ayırt etmek FL-1.4.4 (K2) İzlenebilirliğin sağlanmasının önemini açıklamak FL-1.4.5 (K2) Test etme sürecindeki farklı rolleri karşılaştırmak 1.5 Test Etme Sürecinde Gerekli Beceriler ve İyi Uygulamalar FL-1.5.1 (K2) Test etme sürecinde gerekli genel becerilere örnekler vermek FL-1.5.2 (K1) Tüm ekip yaklaşımının avantajlarını hatırlamak FL-1.5.3 (K2) Testin bağımsızlığının yararlarını ve sakıncalarını açıklamak 17 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  1.1. Yazılım Testi Nedir? Yazılımlar günlük hayatımızın ayrılmaz bir parçasıdır. Çoğu insan, beklendiği gibi çalışmayan bir yazılım ile karşılaşmıştır. Düzgün çalışmayan yazılımlar; para, zaman veya ticari itibar kaybetme ve hatta en uç durumlarda yaralanma veya ölüm gibi birçok soruna yol açabilir. Yazılım testi yazılım kalitesini değerlendirir ve yazılımın kullanımı sırasında oluşabilecek yazılım hatası riskini azaltmaya yardımcı olur. Yazılım testi, hata bulmak ve yazılım geliştirme sırasında üretilen eserlerin kalitesini değerlendirmek için yapılan bir aktiviteler bütünüdür. Bu eserlere, test edilirken test nesnesi adı verilir. Yazılım testi hakkındaki yaygın yanlış kanılardan biri yazılım testinin yazılımı çalıştırmaktan ve test sonuçlarını kontrol etmekten ibaret olduğudur. Ancak yazılım testi aynı zamanda başka aktiviteleri de içerir ve yazılım geliştirme yaşam döngüsüyle uyumlu olmalıdır (bkz. konu 2). Test hakkındaki bir diğer yanlış kanı da test etme sürecinin tamamen test nesnesinin doğrulanmasına odaklı olduğudur. Her ne kadar yazılım testleri, doğrulamayı, diğer bir deyişle sistemin belirli gereksinimleri karşılayıp karşılamadığını kontrol etmeyi içerse de aynı zamanda sistemin operasyonel ortamda/ortamlarda kullanıcı ve diğer paydaş ihtiyaçlarını karşılayıp karşılamadığını kontrol etmek anlamına gelen sağlama yapmayı da içerir. Yazılım testleri dinamik veya statik olabilir. Dinamik test içerisinde yazılımın çalıştırılması yer alırken statik testte bu yoktur. Statik test, gözden geçirmeleri (bkz. konu 3) ve statik analizi içerir. Dinamik test, farklı test teknikleri ve yaklaşımları kullanarak test senaryolarını elde eder (bkz. konu 4). Yazılım testi sadece teknik bir aktivite değildir. Aynı zamanda uygun şekilde planlanması, yönetilmesi, tahmin edilmesi, izlenmesi ve kontrol edilmesi gerekir (bkz. konu 5). Test uzmanları araçlar kullanır (bkz. konu 6) ancak yazılım testinin büyük ölçüde düşünsel bir aktivite olduğu ve test uzmanının uzmanlık bilgisine sahip olması, analitik beceriler kullanması ve eleştirel ve sistemsel düşünme yaklaşımını uygulaması gerektiği unutulmamalıdır (Myers 2011, Roman 2018). ISO/IEC/IEEE 29119-1 standardı, yazılım testi kavramları hakkında daha fazla bilgi vermektedir. 1.1.1. Test Hedefleri Genel test hedefleri: Gereksinimler, kullanıcı hikayeleri, tasarımlar ve kod gibi çalışma ürünlerini değerlendirmek Arızaları tetiklemek ve hataları bulmak Test nesnesinin gerekli kapsamını sağlamak Yazılımın kalite kriterlerini karşılayamama riskini azaltmak Belirtilen gereksinimlerin yerine getirilip getirilmediğini doğrulamak Test nesnesinin sözleşmeden kaynaklanan, yasal veya düzenleyici gereksinimlere uyumluluğunu doğrulamak Sağlıklı kararlar almalarını sağlamak için paydaşlara yeterli bilgiyi sunmak Test nesnesinin kalitesi hakkında güven oluşturmak Test nesnesinin eksiksiz olup olmadığının ve paydaşların beklediği şekilde çalıştığının sağlamasını yapmak Test hedefleri; test edilen çalışma ürünü, test seviyesi, riskler ve takip edilen yazılım geliştirme yaşam döngüsünü (YGYD) içeren bağlama ve kurumsal yapı, rekabetçi hususlar veya pazara sürüm süresi gibi ticari bağlama ilişkin faktörlere bağlı olarak değişebilir. 18 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  1.1.2. Yazılım Testi ve Hata Ayıklama Test etme ve hata ayıklama birbirinden farklı aktivitelerdir. Test etme süreci yazılımdaki hataların neden olduğu arızaları tetikleyebilir (dinamik test) veya test nesnesindeki hataları doğrudan bulabilir (statik test). Dinamik test (bkz. konu 4) bir arızayı tetiklediğinde hata ayıklama işlemi bu arızanın (hataların) nedenlerinin bulunması, bu nedenlerin analiz edilmesi ve giderilmesiyle ilgilenir. Bu durumda tipik hata ayıklama süreci şunları içerir: Arızanın yeniden oluşturulması Teşhis (kök nedenin bulunması) Nedenin düzeltilmesi Sonrasında gerçekleştirilen onaylama testleri düzeltmelerin problemi giderip gidermediğini kontrol eder. Tercihen onaylama testi başlangıçtaki testi gerçekleştiren aynı kişi tarafından yapılır. Düzeltmelerin test nesnesinin diğer bölümlerinde arızalara neden olup olmadığını kontrol etmek için daha sonra bir regresyon testi de yapılabilir (onaylama ve regresyon testine ilişkin daha detaylı bilgi için bkz. bölüm 2.2.3). Statik test bir hata bulduğunda hata ayıklama işlemi bu hatayı gidermekle ilgilenir. Statik test hataları doğrudan bulduğundan ve arızalara neden olamayacağından yeniden oluşturmaya veya teşhise gerek yoktur (bkz. konu 3). 1.2. Yazılım Testi Neden Gereklidir? Bir tür kalite kontrolü olarak test etme süreci belirlenen kapsam, zaman, kalite ve bütçe kısıtları dahilinde önceden kararlaştırılmış hedeflere ulaşılmasına yardımcı olur. Testin başarıya olan katkısı test ekibi aktiviteleriyle sınırlandırılmamalıdır. Her paydaş kendi test becerilerini kullanarak projeyi başarıya daha da yaklaştırabilir. Test bileşenleri, sistemleri ve ilgili dokümantasyon, yazılımdaki hataların belirlenmesine yardımcı olur. 1.2.1. Yazılım Testinin Başarıya Katkısı Test süreci, hataların bulunmasına ilişkin maliyet etkin bir yol sunar. Daha sonra bu hatalar, test sürecinin daha yüksek kaliteli test nesnelerine katkıda bulunması için (test dışı bir aktivite olan hata ayıklama yoluyla) giderilebilir. Test etme süreci, YGYD'nin çeşitli aşamalarında test nesnesinin kalitesini doğrudan değerlendirme imkanı sunar. Bu ölçümler, daha geniş bir proje yönetimi kapsamında kullanılarak YGYD’nin sürüm kararı gibi bir sonraki aşamasına geçiş kararlarına katkıda bulunur. Test, yazılım geliştirme projesinde kullanıcıların dolaylı olarak temsil edilebilmesini sağlar. Test uzmanları, kullanıcı ihtiyaçlarının yazılım geliştirme yaşam döngüsü boyunca göz önünde bulundurulduğundan emin olurlar. Bunun alternatifi, yazılım geliştirme projesinin bir parçası olarak temsili bir kullanıcı grubunu sürece dahil etmek olsa da yüksek maliyetler ve uygun kullanıcıların bulunamaması nedeniyle bu genellikle mümkün değildir. Yazılım testleri aynı zamanda sözleşmeye bağlı veya yasal gereksinimleri ya da düzenleyici standartları karşılamak için de gerekli olabilir. 1.2.2. Test Etme ve Kalite Güvence (KG) Her ne kadar "test etme" ve "kalite güvence" (KG) genellikle birbirinin yerine kullanılan terimler olsa da test etme ve kalite güvence aynı şey değildir. Test etme süreci bir çeşit kalite kontrolüdür (KK). 19 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  Kalite kontrol, uygun kalite seviyelerine ulaşmayı destekleyen aktivitelere odaklanan ürün odaklı, düzeltici bir yaklaşımdır. Test, kalite kontrolün önemli bir ayağıdır, diğer bileşenler ise resmi yöntemleri (model kontrolü ve doğruluk kanıtı), simülasyonu ve prototiplemeyi içerir. KG, süreçlerin uygulanması ve iyileştirilmesine odaklanan süreç odaklı ve önleyici bir yaklaşımdır. İyi bir sürecin doğru uygulanıp uygulanmadığı esasına göre çalışır ve sonuçta iyi bir ürün ortaya çıkmasına odaklanır. KG hem yazılım geliştirme hem de test süreci için geçerli olup projedeki herkesin sorumluluğundadır. Test sonuçları KG ve KK sürecinde kullanılır. KK sürecinde test sonuçları hataların düzeltilmesinde kullanılır; KG sürecinde ise yazılım geliştirme ve test süreçlerinin ne kadar iyi gerçekleştirildiği hakkında geri bildirim sağlar. 1.2.3. İnsan Hataları, Hatalar, Arızalar ve Kök Nedenler İnsanlar hata (yanlışlık) yapar ve bu da yazılım hatalarına (arıza, hata) neden olur ve sonunda başarısızlık meydana gelir. İnsanlar zaman baskısı, işlerin karmaşıklığı, süreçler, altyapı veya iletişim gibi birçok sebeple veya sadece yorgun oldukları ya da yeterli eğitime sahip olmadıkları için hata yapabilir. Hatalar, gereksinim veya test betiği gibi dokümantasyonda, kaynak kodda veya derleme dosyası gibi destekleyici bir eserde bulunabilir. YGYD’nin ilk aşamalarında üretilen ürünlerdeki hatalar tespit edilmezse genellikle yaşam döngüsünün ilerleyen aşamalarında da hatalı ürünlerin ortaya çıkmasına sebep olur. Koddaki bir hata çalıştırılırsa sistem yapması gerekeni yapmayabilir veya yapmaması gereken bir şeyi yaparak bir arızaya neden olabilir. Bazı hatalar sistem çalıştırıldığında her zaman arızaya neden olurken, bazıları belirli koşullar altında arızaya neden olur, bazıları ise hiçbir zaman arızaya neden olmayabilir. Arızaların tek sebebi insan hataları ve yazılım hataları değildir. Arızalar, radyasyon veya elektromanyetik alanın donanım yazılımında hatalara neden olması gibi çevresel koşullardan da kaynaklanabilir. Kök neden, bir problemin ortaya çıkmasının temel sebebidir (ör. hataya yol açan bir durum). Kök nedenler genellikle bir arıza olduğunda veya bir hata tespit edildiğinde gerçekleştirilen kök neden analiziyle belirlenir. Kök nedenin ortadan kaldırılmasıyla benzer arızalar veya hatalar önlenebilir veya meydana gelme sıklıkları azaltılabilir. 1.3. Test Prensipleri Yıllar içinde tüm yazılım testleri için geçerli genel bir rehber sunan bir dizi test prensibi ortaya atılmıştır. Bu ders programında yedi prensip açıklanmaktadır. 1. Testin amacı, yazılımda hataların olduğunu göstermektir; yazılımda hata kalmadığını ispatlamak değildir. Testler, test nesnesinde hataların mevcut olduğunu gösterebilir ancak hiç hata kalmadığını ispatlayamaz (Buxton 1970). Testler, test nesnesinde keşfedilmemiş hataların kalma olasılığını azaltır. Yazılımda yeni hatalar bulunamasa bile bu durum test nesnesinin, kullanıcıların ihtiyaçlarını karşılayacağı anlamına gelmez. 2. Yazılımı %100 test etmek imkansızdır Yazılımdaki her unsuru test etmek çok basit yazılımlar dışında imkansızdır (Manna 1978). Herşeyi test etmeye çalışmak yerine, testten daha çok verim almak için test teknikleri (bkz. konu 4), test senaryosu önceliklendirme (bkz. bölüm 5.1.5) ve risk bazlı test yaklaşımı (bkz. bölüm 5.2) kullanılmalıdır. 3. Erken test, zaman ve para tasarrufu sağlar. Hataların sürecin erken aşamalarında giderilmesi, yazılımda sonradan hata ortaya çıkması olasılığını düşürür. Bu da YGYD’nin sonraki aşamalarında daha az arızaya sebep olacağı için kalite maliyetini azaltacaktır (Boehm 1981). Hataları erken bulmak için hem statik test (bkz. konu 3) hem de dinamik test (bkz. konu 4) mümkün olduğunca erken başlatılmalıdır. 20 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  4. Hatalar yazılımın belli alanlarında yoğunlaşır. Bulunan hataların büyük çoğunluğu genellikle çok az sayıda sistem bileşeninde bulunur veya çok az sayıda sistem bileşeni canlı kullanım sırasında ortaya çıkan arızalara sebep olur. (Enders 1975). Bu olgu Pareto prensibinin bir göstergesidir. Öngörülen hata kümeleri ile test ve canlı kullanım sırasında gözlemlenen gerçek hata kümeleri, risk-bazlı test için önemli bir girdidir (bkz. bölüm 5.2). 5. Antibiyotik direnci. Aynı testler birçok kez tekrarlandığında yeni hataları bulmada giderek daha etkisiz olurlar (Beizer 1990). Bu etkiyi önlemek için mevcut testler ve test verilerinin değiştirilmesi ve yeni testlerin yazılması gerekebilir. Ancak bazı durumlarda aynı testleri tekrar etmek faydalı olabilir (ör. otomatik regresyon testleri) (bkz. bölüm 2.2.3). 6. Yazılım testi, projenin bağlamına, koşullarına göre değişiklik gösterir. Test konusunda evrensel olarak uygulanan tek bir yaklaşım yoktur. Test, farklı proje bağlamlarında farklı şekillerde gerçekleştirilir (Kaner 2011). 7. Yeni hata bulamıyoruz başarılı bir yazılım elde ettik yanılgısı. Testin bir yazılımın başarısını garantileyeceğini beklemek bir yanılgıdır (yanlış bir kanıdır). Belirlenen tüm gereksinimleri titizlikle test etmek ve bulunan tüm hataları çözmek, kullanıcıların ihtiyaçlarını ve beklentilerini karşılamayan, müşterinin iş hedeflerine ulaşmasına yardımcı olmayan veya diğer rakip yazılımlara kıyasla daha zayıf bir yazılımın üretilmesini engelleyemeyebilir. Test sırasında doğrulamanın yanında sağlama da yapılmalıdır (Boehm 1981). 1.4. Test Aktiviteleri, Test Çalışma Ürünleri ve Test Rolleri Test süreci bağlama bağlıdır ancak daha kapsamlı ele alınacak olursa testlerin test hedeflerine ulaşma olasılığını artıran genel test aktivitesi grupları vardır. Bu test aktivitesi grupları bir test sürecini oluşturur. Test süreci çeşitli faktörlere dayalı olarak belirli bir duruma göre özelleştirilebilir. Hangi test sürecine hangi test aktivitelerinin dahil edileceğine, bunların nasıl uygulanacağına ve ne zaman gerçekleştirileceğine hazırlanan test planlaması kapsamında karar verilir (bkz. bölüm 5.1). Aşağıdaki bölümlerde test aktiviteleri ve görevler, bağlamın etkisi, test çalışma ürünleri, test esası ile test çalşma ürünleri arasındaki izlenebilirlik ve test rolleri açısından bu test sürecinin genel yönleri açıklanmaktadır. ISO/IEC/IEEE 29119-2 standardı, test süreçleri hakkında daha fazla bilgi sağlamaktadır. 1.4.1. Test Aktiviteleri ve Görevleri Bir test süreci genellikle aşağıdaki ana aktivite gruplarından oluşur. Her ne kadar bu aktivitelerin çoğu mantıklı bir sıra izliyor gibi görünse de bunlar genellikle tekrarlanarak veya paralel olarak uygulanır. Bu test aktivitelerinin genellikle sistem ve projeye uyarlanması gerekir. Test planlama test hedefini belirleyip ardından genel bağlam dahilinde gerekli olan kısıtlar kapsamında hedeflere en iyi şekilde ulaşılmasını sağlayacak yaklaşımı seçmektir. Test planlama bölüm 5.1'de ayrıntılı bir şekilde açıklanmıştır. Test gözetimi ve kontrolü. Test gözetimi tüm test aktivitelerinin devamlı izlenmesini ve planlanan ile gerçekleşenin karşılaştırılmasını içerir. Test kontrol test hedeflerine ulaşmak için gerekli aksiyonları almayı içerir. Test gözetimi ve kontrolü bölüm 5.3'te ayrıntılı bir şekilde açıklanmıştır. Test analizi test edilebilir özellikleri belirlemek ve ilgili riskler ve risk seviyeleri ile birlikte ilişkili test koşullarını tanımlamak ve önceliklendirmek üzere test esasının analiz edilmesini içerir (bkz. bölüm 5.2). Test esası ve test hedefleri aynı zamanda içerebilecekleri hataları belirlemek ve test edilebilirliği analiz etmek için de değerlendirilir. Test analizi genellikle test tekniklerinin kullanımıyla desteklenir (bkz. konu 4). Test analizi ölçülebilir kapsama kriterleri açısından "ne test edilecek?" sorusuna cevap verir. 21 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  Test tasarımı test koşullarının test senaryoları ve diğer test yazılımları halinde detaylandırılmasını içerir (ör. test başlatma belgeleri). Bu aktivite genellikle test senaryosu girdilerini belirlemeye yönelik bir rehber işlevi gören kapsam öğelerinin belirlenmesini içerir. Test teknikleri (bkz. konu 4) bu aktiviteyi desteklemek için kullanılabilir. Test tasarım aynı zamanda test verisi gereksinimlerinin belirlenmesi, test ortamının tasarlanması ve diğer gerekli altyapı ve araçların tespitini içerir. Test tasarımı "nasıl test edilecek" sorusunu cevaplar. Test uyarlama test koşumu için gerekli test çalışma ürünlerini oluşturmayı veya edinmeyi içerir (bkz. test verisi). Test senaryoları test prosedürleri şeklinde düzenlenebilir ve test grupları halinde birleştirilebilir. Manuel ve otomatik test betikleri oluşturulur. Test prosedürleri, etkin test koşumu için test koşum çizelgesi kapsamında önceliklendirilip düzenlenir (bkz. bölüm 5.1.5). Test ortamı oluşturulur ve kurulumunun uygun bir şekilde yapıldığı doğrulanır. Test koşumu testleri test koşum çizelgesine göre çalıştırmayı içerir. Test koşumu manuel veya otomatik olabilir. Test koşumu sürekli test veya eşli test oturumları gibi birçok şekilde gerçekleşebilir. Gerçek test sonuçları beklenen sonuçlarla karşılaştırılır. Test sonuçları kaydedilir. Olası nedenlerin belirlenmesi için anomaliler analiz edilir. Bu analiz gözlemlenen arızlara dayalı olarak anomalileri raporlamamızı sağlar (bkz. bölüm 5.5). Test tamamlama aktiviteleri genellikle çözülmemiş hatalar, değişiklik talepleri veya oluşturulan ürün iş listesi öğelerine ilişkin olarak proje kilometre taşlarında (ör. sürüm, döngü sonu, test seviyesi tamamlama) gerçekleşir. Gelecekte faydalı olabilecek test yazılımları belirlenir ve arşivlenir ya da uygun ekiplere devredilir. Test ortamı kararlaştırıldığı şekilde kapatılır. Test aktiviteleri tecrübeleri ve gelecekteki döngüler, sürümler veya projelere yönelik iyileştirmeleri belirlemek için analiz edilir (bkz. bölüm 2.1.6). Test tamamlama raporu oluşturulur ve paydaşlara iletilir. 1.4.2. Proje Bağlamında Test Süreci Test izole şekilde yapılmaz. Test aktiviteleri organizasyon içinde gerçekleştirilen yazılım geliştirme süreçlerinin ayrılmaz bir parçasıdır. Testler de proje paydaşları tarafından finanse edilir ve nihai hedefi proje paydaşlarının iş ihtiyaçlarını karşılamaya yardımcı olmaktır. Dolayısıyla testlerin yapılma şekli aşağıdakiler de dahil birçok bağlamsal faktöre bağlı olacaktır: Paydaşlar (ihtiyaçlar, beklentiler, gereksinimler, iş birliği isteği vb.) Ekip üyeleri (beceri, bilgi, deneyim seviyesi, elverişlilik, eğitim ihtiyaçları vb.) Kurumun faaliyet alanı (test nesnesinin kritiklik düzeyi, tanımlanan riskler, pazar ihtiyaçları, yasal düzenlemeler vb.) Teknik faktörler (yazılım türü, ürün mimarisi, kullanılan teknoloji vb.) Proje kısıtları (kapsam, zaman, bütçe, kaynaklar vb.) Organizasyonel faktörler (organizasyonel yapı, mevcut politikalar, kullanılan pratikler vb.) Yazılım geliştirme yaşam döngüsü (mühendislik uygulamaları, geliştirme yöntemleri vb.) Araçlar (elverişlilik, kullanılabilirlik, uyumluluk vb.) Bu faktörler test stratejisi, kullanılan test teknikleri, test otomasyonu derecesi, gerekli kapsam seviyesi, test dokümantasyonu ayrıntı düzeyi, raporlama vb. gibi testle ilgili konulara etki edecektir. 1.4.3. Test Çalışma Ürünleri Test çalışma ürünleri bölüm 1.4.1'de belirtilen test aktivitelerinden elde edilen çalışma ürünlerinin bir parçası olarak oluşturulur. Farklı organizasyonların çalışma ürünlerini nasıl ürettiği, şekillendirdiği, adlandırdığı, düzenlediği ve yönettiği konusunda 22 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  ciddi farklılılar vardır. Uygun yapılandırma yönetimi (bkz. bölüm 5.4) çalışma ürünleri arasında tutarlılık ve bütünlük sağlar. Aşağıda kapsamlı olmayan bir çalışma ürünleri listesi verilmiştir: Test planlama çalışma ürünleri şunları içerir: test planı, test zaman çizelgesi, risk kaydı ve giriş ve çıkış kriterleri (bkz. bölüm 5.1). Risk kaydı; risk olasılığı, risk etkisi ve riski azaltma bilgisini içeren bir riskler listesidir (bkz. bölüm 5.2). Test zaman çizelgesi, risk kaydı ile giriş ve çıkış kriterleri genellikle test planının bir parçasıdır. Test gözetimi ve kontrolü çalışma ürünleri şunları içerir: test ilerleme raporları (bkz. bölüm 5.3.2), kontrol direktifleri dokümantasyonu (bkz. bölüm 5.3) ve risk bilgisi (bkz. bölüm 5.2). Test analizi çalışma ürünleri şunları içerir: (önceliklendirilmiş) test koşulları (ör. kabul kriteri, bkz. bölüm 4.5.2) ve test esasındaki hatalara ilişkin hata raporu. Test tasarımı çalışma ürünleri şunları içerir: (önceliklendirilmiş) test senaryoları, test başlatma belgeleri, kapsam öğeleri, test verisi gereksinimleri ve test ortamı gereksinimleri. Test uyarlama çalışma ürünleri şunları içerir: test prosedürleri, otomatik test betikleri, test grupları, test verisi, test koşumu çizelgesi ve test ortamı öğeleri. Test ortamı öğelerine ilişkin örnekler: taklit uygulamalar, sürücüler, simülatörler ve servis sanallaştırması. Test koşumu çalışma ürünleri şunları içerir: test kayıtları ve hata raporları (bkz. bölüm 5.5). Test tamamlama çalışma ürünleri şunları içerir: test tamamlama raporu (bkz. bölüm 5.3.2), sonraki proje veya döngülerin iyileştirilmesine yönelik aksiyon öğeleri, tecrübeler ve değişiklik talepleri (ör. ürün iş listesi öğeleri). 1.4.4. Test Esası ve Test Çalışma Ürünleri Arasında İzlenebilirlik Etkili test gözetimi ve kontrolü uygulamak için test süreci boyunca test esası unsurları, bu unsurlarla ilişkili test çalışma ürünleri (ör. test koşulları, riskler, test senaryoları), test sonuçları ve tespit edilen hatalar arasında izlenebilirliği sağlamak ve sürdürmek önemlidir. Doğru izlenebilirlik kapsam değerlendirmesini destekler ve dolayısıyla test esasında ölçülebilir kapsama kriterleri tanımlanmışsa bunların takip edilmesinde çok faydalı olur. Kapsama kriterleri test hedeflerine ne ölçüde ulaşıldığını gösteren aktiviteleri gerçekleştirmek açısından anahtar performans göstergeleri olarak işlev görebilir (bkz. bölüm 1.1.1). Örnek: Test senaryolarının gereksinimlere göre izlenebilirliğine bakarak test senaryolarının gereksinimleri karşıladığını doğrulamak mümkündür. Test sonuçlarının risklere göre izlenebilirliği bir test nesnesindeki kalan risk seviyesini değerlendirmede kullanılabilir. İyi bir izlenebilirlik yalnızca kapsam değerlendirmesine değil, aynı zamanda etki analizine, test denetimlerine ve bilgi teknolojileri (BT) yönetişim gereksinimlerinin karşılanmasına da yardımcı olur. İyi bir izlenebilirlik, test esası unsurlarının durumunu da içererek test ilerleme durumu ve tamamlanma raporlarının anlaşılmasını kolaylaştırır. Aynı zamanda testin teknik yönlerinin paydaşlara anlaşılır şekilde bildirilmesine de yardımcı olur. İzlenebilirlik, iş hedeflerine göre ürün kalitesinin, süreç kapasitesinin ve proje ilerlemesinin değerlendirilmesi için bilgi sağlar 23 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  1.4.5. Test Etme Sürecindeki Roller Bu ders programında testteki iki önemli role yer verilmiştir: test yönetimi rolü ve test etme rolü. Bu iki role sahip kişilere atanan faaliyetler ve görevler, projenin ve ürünün bağlamı gibi faktörlere, o rolü üstlenen kişilerin becerilerine ve kuruma göre değişir. Test yönetimi rolü, genel olarak test sürecinden, test ekibinden ve test aktivitelerine liderlik edilmesinden sorumludur. Test yönetimi rolü temelde test planlama, test gözetimi ve kontrolü ve test tamamlama aktivitelerine odaklıdır. Test yönetimi rolünün yerine getirilme şekli, bağlama göre değişir. Örneğin, Çevik Yazılım Geliştirmede bazı test yönetimi görevleri Çevik ekip tarafından gerçekleştirilirken, birden fazla ekibi veya tüm organizasyonu ilgilendiren görevler geliştirme ekipleri dışındaki test yöneticileri tarafından yerine getirilebilir. Test etme rolü testin mühendislik (teknik) yönünün tüm sorumluluğuna sahiptir. Test etme rolü temelde test analizi, test tasarımı, test uyarlama ve test koşumu aktivitelerine odaklanır. Rollerin sorumluluğunu farklı zamanlarda farklı kişiler alabilirler. Örneğin, test yönetimi rolü bir ekip lideri, test yöneticisi, geliştirme yöneticisi vb. tarafından üstlenilebilir. Test etme ve test yönetimi rollerini aynı anda tek bir kişinin üstlenmesi de mümkündür. 1.5. Test Etme Sürecinde Gerekli Beceriler ve İyi Uygulamalar Beceri; kişinin bilgi birikiminden, pratiğinden ve kabiliyetinden ileri gelen, bir işi iyi yapma yeteneğidir. İyi test uzmanları işlerini iyi yapmak için bazı gerekli becerilere sahip olmalıdır. İyi test uzmanları etkin birer ekip üyesi olmalı ve çeşitli test bağımsızlığı seviyelerinde testler gerçekleştirebilmelidir. 1.5.1. Test Etme Sürecinde Gerekli Genel Beceriler Genel olmalarına rağmen, aşağıdaki beceriler test uzmanları için özellikle önemlidir: Test bilgisi (test etmenin etkinliğini artırmak için, ör. test teknikleri kullanarak) Titizlik, dikkat, merak, detaycı olmak, sistematik çalışmak (özellikle bulması zor olanlar başta olmak üzere hataları bulmak için) İyi iletişim becerileri, aktif dinleme, ekip oyuncusu olma (tüm paydaşlarla etkin iletişim kurmak, diğeriyle bilgi paylaşmak, anlaşılmak ve hataları raporlayıp görüşmek için) Analitik düşünce, eleştirel düşünce, yaratıcılık (test etmenin etkinliğini artırmak için) Teknik bilgi (test etmenin etkinliğini artırmak için, ör. uygun test araçlarını kullanarak) Alan bilgisi (son kullanıcıları/iş temsilcilerini anlayabilmek ve onlarla iletişim kurabilmek için) Test uzmanları genellikle kötü haberi veren taraftadırlar. Kötü haber verenleri suçlamak ise tipik bir insan davranışıdır Bu nedenle, test uzmanları için iletişim becerisi kritik önem taşır. Gerçekleştirilen testin sonucu, ürüne ve sahibine yöneltilmiş bir eleştiri olarak algılanabilir. Doğrulama yanlılığı, mevcut görüş ve inançlara uymayan bilgilerin kabul edilmesini zorlaştırabilir. Projenin başarısına ve ürün kalitesine büyük katkı sağlasa da, bazı insanlar testleri yıkıcı bir faaliyet olarak algılayabilir. Bu görüş doğrultusunda, hatalar ve arızalar hakkındaki bilgiler yapıcı bir şekilde iletilmelidir. 24 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  1.5.2. Tüm Ekip Yaklaşımı Bir test uzmanı için en önemli becerilerden biri, bir ekip bağlamında etkin çalışma ve ekip hedeflerine olumlu katkı sağlama becerisidir. Ekstrem Programlama (bkz. bölüm 2.1) metodolojisinden elde edilen bir pratik olan tüm ekip yaklaşımı bu beceriyi temel alır. Tüm ekip yaklaşımında, gerekli bilgi ve beceriye sahip tüm ekip üyeleri her türlü görevi yapabilir ve kaliteden herkes sorumludur. Ekip üyeleri aynı çalışma alanını (fiziksel veya sanal) paylaşır çünkü ortak çalışma alanı iletişim ve etkileşimi kolaylaştırır. Tüm ekip yaklaşımı ekip ilişkilerini geliştirir, ekip içinde iletişimi ve iş birliğini artırır ve ekibin farklı beceri setlerinin proje yararına kullanılmasına olanak sağlayarak sinerji yaratır. Test uzmanları, istenen kalite seviyelerine ulaşılabilmesi için diğer ekip üyeleriyle yakın iş birliği içinde çalışırlar. Bu, uygun kabul testleri oluşturmalarına yardımcı olmak için iş birimleriyle iş birliği yapmanın yanı sıra test stratejisi ve test otomasyonu metodolojilerine karar vermek için yazılımcılarla birlikte çalışmayı da içerir. Böylece test uzmanları, test alanındaki bilgilerini diğer ekip üyelerine aktarabilir ve ürünün gelişimine katkı sağlayabilir. Bağlama açısından tüm ekip yaklaşımı her zaman uygun olmayabilir. Örneğin, bazı emniyet hassasiyetli durumlarda, yüksek düzeyde test bağımsızlığı gerekli olabilir. 1.5.3. Testin Bağımsızlığı Belli bir ölçüde bağımsızlık, yazarın ve test uzmanının bilişsel önyargıları arasındaki farklar nedeniyle test uzmanının hataları bulmada daha etkili olmasını sağlar (bkz. Salman 1995). Ancak bağımsızlık, aşina olmanın yerine geçemez. Örneğin yazılımcılar kendi kodlarındaki birçok hatayı verimli bir şekilde bulabilir. Çalışma ürünleri; kendi yazarları (bağımsızlık yok), yazarın aynı ekipten arkadaşları (biraz bağımsız), yazarın ekibinin dışındaki fakat kurum içindeki test uzmanları (yüksek bağımsızlık) veya şirket dışından test uzmanları (çok yüksek bağımsızlık) tarafından test edilebilir. Çoğu proje için genellikle en iyi seçenek, testin birden çok bağımsızlık seviyesinde yapılmasıdır (ör. bileşen ve bileşen entegrasyon testi yazılımcılar tarafından, sistem ve sistem entegrasyon testi test ekibi tarafından, kabul testi ise iş temsilcileri tarafından yapılır). Bağımsız testin başlıca faydası farklı geçmiş deneyimleri, teknik bakış açıları ve eğilimleri nedeniyle bağımsız test uzmanlarının, yazılımcılara kıyasla farklı çeşitteki arızaları ve hataları bulma olasılıklarının daha yüksek olmasıdır. Ayrıca bağımsız bir test uzmanı, sistemin analiz edilmesi ve hayata geçirilmesi sırasında paydaşların yaptığı varsayımları doğrulayabilir, sorgulayabilir veya çürütebilir. Ancak bazı sakıncalar da söz konusudur. Bağımsız test uzmanları geliştirme ekibinden farklı hareket edebilir ve bu da iş birliği eksikliğine, iletişim problemlerine veya geliştirme ekibiyle olumsuz ilişkiler yaşanmasına yol açabilir. Yazılımcılar kalite konusunda sorumluluk bilincini kaybedebilir. Bağımsız test uzmanları bir dar boğaz olarak görülebilir veya sürümdeki gecikmelerden sorumlu tutulabilir. 25 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  2. Yazılım Geliştirme Yaşam Döngüsü Boyunca Test – 130 dakika Anahtar kelimeler kabul testi, kara kutu testi, bileşen entegrasyon testi, bileşen testi, onaylama testi, fonksiyonel test, entegrasyon testi, bakım testi, fonksiyonel olmayan test, regresyon testi, shift-left, sistem entegrasyon testi, sistem testi, test seviyesi, test nesnesi, test çeşidi, beyaz kutu testi Konu 2 Öğrenme Hedefleri: 2.1 Yazılım Geliştirme Yaşam Döngüsü Bağlamında Test FL-2.1.1 (K2) Seçilen yazılım geliştirme yaşam döngüsünün test üzerindeki etkisini açıklamak FL-2.1.2 (K1) Tüm yazılım geliştirme yaşam döngüsü için geçerli olan iyi test uygulamalarını hatırlamak FL-2.1.3 (K1) Geliştirmeye yönelik önce-test-et yaklaşımlarının örneklerini hatırlamak FL-2.1.4 (K2) DevOps'un test üzerinde nasıl bir etkisi olabileceğini özetlemek FL-2.1.5 (K2) Shift-left yaklaşımını açıklamak FL-2.1.6 (K2) Geçmişe dönük verilerin süreç iyileştirmesi için nasıl bir mekanizma olarak kullanılabileceğini açıklamak 2.2 Test Seviyeleri ve Test Çeşitleri FL-2.2.1 (K2) Farklı test seviyelerini ayırt etmek FL-2.2.2 (K2) Farklı test çeşitlerini ayırt etmek FL-2.2.3 (K2) Onaylama testleri ve regresyon testlerini birbirinden ayırmak 2.3 Bakım Testleri FL-2.3.1 (K2) Bakım testleri ve tetikleyicilerini özetlemek 26 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  2.1. Yazılım Geliştirme Yaşam Döngüsü Bağlamında Test Yazılım geliştirme yaşam döngüsü (YGYD) yazılım geliştirme sürecinin kavramsal, üst düzey bir tasviridir. Bir YGYD modeli, bu süreçte gerçekleştirilen farklı geliştirme aşamaları ve faaliyet türlerinin hem mantıksal hem de kronolojik olarak birbirleriyle nasıl ilişkili olduğunu gösterir. YGYD modellerine örnekler: sıralı yazılım geliştirme modelleri (ör. şelale modeli, V modeli), döngüsel geliştirme modeli (ör. spiral model, prototipleme) ve artımlı geliştirme modelleri (ör. Birleşik Süreç). Yazılım geliştirme süreçlerindeki bazı aktiviteler daha ayrıntılı yazılım geliştirme yöntemleri ve Çevik uygulamalarla da tanımlanabilir. Örnekler: kabul testi güdümlü yazılım geliştirme (ATDD), davranış güdümlü yazılım geliştirme (BDD), alan güdümlü tasarım (DDD), ekstrem programlama (XP), özellik güdümlü geliştirme (FDD), Kanban, Yalın BT, Scrum ve test güdümlü geliştirme (TDD). 2.1.1. Yazılım Geliştirme Yaşam Döngüsünün Test Üzerindeki Etkisi Başarılı olması için testlerin YGYD'ye uyarlanması gerekir. YGYD seçimi aşağıdakilere etki eder: Test aktivitelerinin kapsamı ve zamanlaması (ör. test seviyeleri ve test çeşitleri) Test dokümantasyonun ayrıntı düzeyi Test tekniklerinin ve test yaklaşımının seçimi Test otomasyonunun kapsamı Test uzmanının rol ve sorumlulukları Sıralı yazılım geliştirme modellerinde, ilk aşamalarda test uzmanları genellikle gereksinim gözden geçirmelerine, test analizine ve test tasarımına katılır. Çalıştırılabilir kod genellikle sonraki aşamalarda oluşturulur, bu nedenle tipik olarak dinamik testler YGYD'nin erken aşamalarında gerçekleştirilemez. Bazı döngüsel ve artımlı geliştirme modellerinde her döngünün bir çalışma prototipi veya ürün özelliği sağladığı varsayılır. Bu da her döngüde tüm test seviyelerinde hem statik hem de dinamik testlerin gerçekleştirilebileceği anlamına gelir. Yazılım özelliklerinin sık hayata geçirilmesi hızlı geri bildirim ve kapsamlı regresyon testleri gerektirir. Çevik yazılım geliştirme, projenin süresi boyunca değişikliklerin olabileceğini varsayar. Bu nedenle, çevik projelerde iş ürünü belgelerinin hafifletilmesi ve regresyon testlerini kolaylaştırmak için kapsamlı test otomasyonu tercih edilir. Ayrıca, manuel testlerin çoğu, tecrübeye dayalı test teknikleri kullanılarak yapılır ve bu teknikler, önceden kapsamlı test analizi ve tasarım gerektirmez (bkz. Bölüm 4.4). 2.1.2. Yazılım Geliştirme Yaşam Döngüsü ve İyi Test Etme Uygulamaları Seçilen YGYD modelinden bağımsız iyi test uygulamaları aşağıdakileri içerir: Her yazılım geliştirme aktivitesine karşılık gelen bir test aktivitesi vardır ve böylece tüm geliştirme aktivitelerinin kalite kontrole tabi olması sağlanır Farklı test seviyeleri (bkz. konu 2.2.1) belirli ve farklı test hedeflerine sahiptir ve bu da testin uygun şekilde kapsamlı olmasına olanak tanırken gereksiz tekrarlardan kaçınmayı sağlar Belirli bir test seviyesi için test analizi ve tasarımı YGYD’nin ilgili geliştirme aşamasında başlar ve böylece test “erken test” prensibine uygun şekilde test gerçekleşebilir. (bkz. bölüm 1.3) 27 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  Test uzmanları, dokümantasyonun taslakları hazır olur olmaz çalışma ürünlerini gözden geçirme sürecine dahil olur, böylece erken test ve hata tespiti “shift-left” stratejisini destekleyebilir (bkz. bölüm 2.1.5). 2.1.3. Yazılım Geliştirme Faktörü Olarak Test TDD, ATDD ve BDD benzer yazılım geliştirme yaklaşımlarıdır, burada testler geliştirme sürecini yönlendiren bir araç olarak tanımlanır. Bu yaklaşımların her biri erken test etme prensibini uygular (bkz. bölüm 1.3) ve shift-left yaklaşımını izler (bkz. bölüm 2.1.5), çünkü testler kod yazılmadan önce tanımlanır. Döngüsel bir geliştirme modelini desteklerler. Bu yaklaşımların karakteristik özellikleri aşağıdaki gibidir: Test Güdümlü Yazılım Geliştirme (TDD): Kodlamayı test senaryoları aracılığıyla yönlendirir (kapsamlı yazılım tasarımı yerine) (Beck 2003) Önce testler yazılır, sonra testleri yerine getirmek için kod yazılır ve ardından testler ve kod yeniden düzenlenir Kabul Testi Güdümlü Yazılım Geliştirme (ATDD) (bkz. bölüm 4.5.3): - Kabul kriterlerinden testler türetilir ve bu, sistem tasarım sürecinin bir parçası olarak yapılır (Gärtner 2011) - Testler, uygulamanın ilgili bölümü geliştirilmeden önce yazılır ve ardından testleri karşılayacak şekilde kodlama yapılır. Davranış Güdümlü Yazılım Geliştirme (BDD): - Uygulamanın istenen davranışını, genellikle Given/When/Then formatı kullanılarak, paydaşlar tarafından anlaşılması kolay bir doğal dilin basit bir formunda yazılan test senaryoları ile ifade eder. (Chelimsky 2010) - Test senaryoları daha sonra otomatik olarak yürütülebilir testlere çevrilir Yukarıdaki yaklaşımların tümünde, testler gelecekteki uyarlama/yeniden düzenleme süreçlerinde kod kalitesini sağlamak için otomatikleştirilmiş testler olarak kalabilir. 2.1.4. DevOps ve Test Etme DevOps, ortak hedeflere ulaşmak için yazılım geliştirme (test dahil) ve operasyonun birlikte çalışmasını sağlayarak sinerji oluşturmayı amaçlayan organizasyonel bir yaklaşımdır. DevOps, yazılım geliştirme (test dahil) ve operasyon arasında köprü görevi görmek ve işlevlerine eşit değerde muamele etmek için kuruluş içinde kültürel bir değişim gerektirir. DevOps ekip özerkliğini, hızlı geri bildirimi, entegre araç zincirlerini ve sürekli entegrasyon (CI) ve sürekli teslimat (CD) gibi teknik uygulamaları destekler. Bu, ekibin DevOps teslimat hattı aracılığıyla yüksek kaliteli kodları daha hızlı oluşturmasını, test etmesini ve yayınlamasını sağlar (Kim 2016). Test perspektifinden bakıldığında DevOps'un bazı faydaları şunlardır: Kod kalitesi hakkında hızlı geri bildirim sağlar ve değişikliklerin mevcut kodu olumsuz etkileyip etkilemediğini belirler. Sürekli Entegrasyon (CI), yazılım geliştiricileri bileşen testleri ve statik analiz eşliğinde yüksek kaliteli kodlar sunmaya teşvik ederek test konusunda shift-left yaklaşımı uygulanmasını destekler (bkz. bölüm 2.1.5). Stabil test ortamları oluşturmayı kolaylaştıran CI/CD gibi otomatik süreçleri destekler Fonksiyonel olmayan gereksinimlere (ör. performans ve güvenilirlik) ilişkin görüş alanını artırır Teslimat hattında yapılan test otomasyonu, tekrarlayan manuel testlere ihtiyacı azaltır 28 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  Otomatik regresyon testlerinin ölçeği ve kapsamı dolayısıyla regresyon riski en aza indirilir DevOps'un risk ve zorlukları da vardır; bunlar arasında: DevOps teslimat hattı tanımlanmalı ve kurulmalıdır CI / CD araçları tanıtılmalı ve bakımı yapılmalıdır Test otomasyonu ek kaynaklar gerektirir. Test otomasyonunun kurması ve sürdürmesi zor olabilir Her ne kadar DevOps kapsamında yüksek düzeyde test otomasyonu bulunsa da özellikle kullanıcı perspektifinden bakıldığında manuel testlere yine de ihtiyaç olacaktır. 2.1.5. Shift-Left Yaklaşımı Testin YGYD'nin başlarında gerçekleştirildiği bir yaklaşım olan “erken test” prensibi (bkz. bölüm 1.3) bazen shift-left olarak adlandırılır. Shift-left genellikle testlerin daha erken yapılmasını önerir (örneğin, kodun yazılmasını veya bileşenlerin entegre edilmesini beklemeden), ancak bu YGYD’nin ilerleyen aşamalarında testlerin ihmal edilmesi gerektiği anlamına gelmez. Testlerde "shift-left" yaklaşımının nasıl sağlanacağını gösteren birtakım iyi uygulamalar vardır: Test bakış açısıyla analizin gözden geçirilmesi. Analize ilişkin bu gözden geçirme aktiviteleri genelde belirsizlikler, eksiklikler ve tutarsızlıklar gibi potansiyel hataları tespit eder. Kod yazılmadan önce test senaryolarının yazılması ve kodun yazılması sırasında kodun bir test kuluçkasında çalıştırılması Kod deposuna gönderildiğinde kaynak koda eşlik edecek hızlı geri bildirim ve otomatik bileşen testleri sağladığı için CI'nin ve hatta daha da iyisi CD'nin kullanılması Dinamik test öncesinde veya otomatik süreç kapsamında kaynak kodun statik analizinin tamamlanması Mümkün olan durumlarda bileşen testi seviyesinden başlayarak fonksiyonel olmayan testlerin gerçekleştirilmesi. Bu bir tür shift-left uygulamasıdır. Çünkü fonksiyonel olmayan test türleri, YGYD’nin sonraki aşamalarında, eksiksiz bir sistem ve temsili bir test ortamı mevcut olduğunda gerçekleştirilmektedir. Bir shift-left yaklaşımı süreç başında ilave eğitim, efor ve/veya maliyete yol açabilir ancak bu yaklaşımın sürecin sonraki aşamalarında efor ve/veya maliyet tasarrufu sağlaması beklenir. Shift-left yaklaşımı açısından paydaşların ikna edilmesi ve bu konsepte inanmaları önemlidir. 2.1.6. Geçmişe Dönük Öğeler ve Süreç İyileştirmesi Geçmişe dönük öğeler ("proje sonrası toplantı" ve geriye dönük proje kazanımları olarak da bilinir) genelde bir proje veya döngü sonunda, bir sürüm kilometre taşında veya gerektiğinde ele alınır. Geçmişe dönük öğelerin zamanlaması ve organizasyonu, izlenen YGYD modeline bağlıdır. Bu toplantılarda katılımcılar (sadece test uzmanları değil, aynı zamanda ör. geliştiriciler, mimarlar, ürün sahibi ve iş analistleri) şunları görüşür: Başarılı olan neydi ve bu nasıl sürdürülmeli? Başarısız olan neydi ve bu konuda nasıl bir iyileştirme yapılabilir? 29 Yazılım Test ve Kalite Derneği | www.turkishtestingboard.org | [email protected] Versiyon v4.0 Tel: +90 212 276 06 48 | Faks: +90 212 276 06 47  Başarıları nasıl sürdürebilir ve ileriye dönük iyileştirmeleri nasıl uygulayabiliriz? Sonuçlar