**XII.

Yazılım Evrimi**

**1. Yazılım Evrimi**

- Yazılım evriminin tanımı.
- Yazılım sistemlerinin işletmeler için kritik varlıklar olma önemi.
- Büyük şirketlerin yazılım bütçesinin çoğunluğunun var olan yazılımı
evrimleme amaçlı ayırılması.

**2. Yazılım Bakımı**

- Yazılım bakımının genel bakışı.
- Bakım türleri: düzeltici, uyumlu, iyileştirici.
- Bakım çabasının dağılımı.

**3. Güvenilirlik ve Kullanılabilirlik**

- Yazılımın güvenilirlik ve kullanılabilirliğini sürdürmenin önemi.
- Bakım maliyetlerini etkileyen faktörler.
- Bakım maliyet faktörleri: ekip istikrarı, sözleşme sorumluluğu,
personel becerileri, program yaşı ve yapısı.

**4. Yazılım Kalitesi**

- Yazılım bakımının yazılım kalitesi üzerindeki etkisi.
- Bakım tahmini ve potansiyel sorunları değerlendirmedeki rolü.
- Yazılım kalitesini koruma stratejisi olarak sistem mühendisliği.

**XIII. Evrimin Önemi**

- Organizasyonların yazılım sistemlerine büyük yatırımları vardır, bu

nedenle bunlar kritik varlıklardır.
- Bu varlıkların değerini korumak için yazılımın düzenli olarak
güncellenmesi ve değiştirilmesi gerekir.
- Büyük şirketlerin yazılım bütçesinin önemli bir kısmı, yeni yazılım
geliştirmek yerine var olan sistemleri evirmeye ayrılmıştır.

**XIV. Spiral Modeli ve Gelişim ve Evrim**

- Gelişim ve evrim için bir çerçeve olarak spiral modelinin genel bakışı.
- Spiral modelinin yinelemeli doğası, gelişimi ve evrimi içerir.

**XV. Evrim ve Servis**

**1. Evrim**
- Yazılımın operasyonel kullanım ve yeni gereksinimlere yanıt olarak
sürekli gelişimi.
**2. Servis**
- Yazılımın operasyonel kalmasını sağlamak için yapılan bakım, yeni
işlevsellik eklenmez.
**3. Aşama Dışı**
- Yazılımın kullanılması devam edebilir, ancak buna daha fazla değişiklik
yapılmaz.

**XVI. Evrim Süreçleri**

- Yazılım evrim süreçleri, yazılım türü, kullanılan geliştirme süreçleri

ve ilgili personelin becerilerine bağlıdır.
- Değişiklik teklifleri sistemi evrimine itici güç oluşturur, etkilenen
bileşenlerle ilişkilidir.
- Sistem yaşam süresi boyunca değişiklikleri tanımlama ve evrim devam
eder.

**XVII. Değişiklik Tanımlama ve Evrim Süreçleri**

- Değişiklik tekliflerini etkilenen bileşenlerle ilişkilendirme,

maliyetleri ve etkileri tahmin etme.
- Değişiklik tanımlama ve sistemin yaşam süresi boyunca evrim sürecinin
devam etmesi.

**XVIII. Yazılım Evrim Süreci**

- Yazılım evrim süreci, sisteme iteratif değişiklikler içerir.

- Değişiklik uygulama: revizyonları tasarlamak, uygulamak ve test etmek.
- Değişiklik uygulamanın erken aşamalarında program anlayışının önemi.

**XIX. Program Evrim Dinamikleri**

- Sistem değişim süreçlerinin incelenmesi.

- Lehman ve Belady'nin program evrim dinamikleri üzerine önerdiği
"kanunlar".
- Bu yasaların büyük organizasyonlar tarafından geliştirilen büyük
sistemlere uygulanabilirliği.

**XX. Lehman’ın Yasaları**

- Lehman'ın yasalarının tanımı ve tartışılması, sürekli değişim, artan

karmaşıklık, büyük program evrimi ve organizasyonel istikrarı içerir.

**XXI. Lehman’ın Yasalarının Uygulanabilirliği**

- Lehman'ın yasalarının genel olarak büyük, özel sistemlere

uygulanabilirliği.
- 2000'lerin başlarındaki çalışmalarla doğrulandı.
- Ancak, bunların büzünen yazılımlar, COTS bileşenler içeren sistemler,
küçük organizasyonlar ve orta büyüklükteki sistemler için nasıl
değiştirileceği belirsiz.

**XXII. Yazılım Bakımı**

- Yazılım bakımının tanımı.

- Bakım türleri: düzeltici, uyumlu, iyileştirici.
- Bakım çabasının yazılım yapısına etkisi.

**XXIII. Bakım Maliyetleri**

- Geliştirme ve bakım maliyetlerinin karşılaştırılması.

- Bakım maliyetlerini etkileyen faktörler, ekip istikrarı, sözleşme
sorumluluğu, personel becerileri ve program yaşı ve yapısı.

**XXIV. Bakım Maliyet Faktörleri**

- Bakım maliyetlerini etkileyen faktörlerin keşfi, ekip istikrarı,
sözleşme sorumluluğu, personel becerileri ve program yaşı ve yapısı gibi.

**XXV. Bakım Tahmini**

- Olası sorunları değerlendirmek ve yüksek bakım maliyetleri olan sistem

parçalarını belirlemekle ilgili.
- Değişiklik kabulü, bakılabilirlik ve değişikliklerle maliyetler
arasındaki

ilişki.

**XXVI. Sistem Yeniden Mühendislik**

- Fonksiyonelliğini değiştirmeden bir miras sisteminin bir kısmını veya

tamamını yeniden yapılandırma veya yeniden yazma.
- Sık bakım gerektiren alt sistemlere uygulanabilir.
- Yeniden mühendislik, bakımı kolaylaştırmak için çaba eklemeyi, sistemi
yeniden yapılandırmayı ve yeniden belgelemeyi içerir.

**XXVII. Yeniden Mühendisliğin Avantajları**

- Yeni yazılım geliştirmeye göre az risk.

- Yeni yazılım geliştirmenin maliyetlerinden önemli ölçüde daha düşük
maliyet.

**XXVIII. Yeniden Mühendislik Süreci**

- Yeniden mühendislik sürecinin genel bakışı.

- Yeniden mühendislik sürecindeki temel faaliyetler: kaynak kodu çevirme,
tersine mühendislik, program yapısı iyileştirme ve veri yeniden
mühendisliği.

**XXIX. Yeniden Mühendislik Yaklaşımları**

- Kaynak kodu çevirme, tersine mühendislik, program yapısı iyileştirme ve

veri yeniden mühendisliği gibi farklı yaklaşımlar.

**XXX. Yeniden Mühendislik Maliyet Faktörleri**

- Yazılımın kalitesi, yeniden mühendislik için mevcut araç desteği,

gereken veri dönüşümü ve uzman personelin kullanılabilirliği gibi
faktörleri etkileyen faktörler.

**XXXI. Önleyici Bakım ve Refactoring**

- Refactoring'in önleyici bakım olarak tanımı ve önemi.

- Programı geliştirmenin yavaşlaması için bir programı iyileştirmenin
süreci olarak düşünülebilir.
- Refactoring, programın yapısını, karmaşıklığını azaltmayı veya
anlaşılmasını kolaylaştırmayı içerir.
- Bir programı iyileştirme odaklı olarak değil, program iyileştirmeye
odaklanarak gerçekleştirilir.
**XXXII. Refactoring ve Yeniden Mühendislik**

- Geliştirme ve evrim süreci boyunca sürekli olarak gerçekleşen bir süreç

olarak refactoring.
- Sistem ve kod bozulmasını minimize etmek için sürekli bir iyileştirme
süreci olarak düşünülür.
- Refactoring ve yeniden mühendislik arasındaki sürekli ve periyodik
faaliyetler arasındaki ayrım.

**XXXIII. Yazılım Güvenilirliği ve Kalite Yönetimi**

**XXXIV. Yazılım Güvenilirliği**

- Yazılımın güvenilirliği temel olarak güvenilirlik veya bağlılık

anlamına gelir.
- Alternatif olarak, bir yazılım ürününün güvenilirliği, ürünün belirli
bir süre boyunca "doğru" şekilde çalışma olasılığı olarak da
tanımlanabilir.

**XXXV. Yazılım Güvenilirliği Özellikleri**

- Bir yazılım ürününün birçok hataya sahip olması güvenilir olmadığı

anlamına gelir.
- Bir sistemin güvenilirliği genellikle hataların azaltılmasıyla artar.
- Gözlemlenen sistem güvenilirliği ile gizli hatalar arasında basit bir
ilişki yoktur.

**XXXVI. Örnek ve Çekirdek İşleyiş**

- Nadiren yürütülen yazılım parçalarındaki hataları gidermek, genellikle

ürün güvenilirliğini çok az iyileştirir.
- Çoğu zaman, bir programın çalışma süresinin %90'ı talimatların sadece
%10'unun yürütülmesinde harcanır; bu, çekirdek olarak adlandırılır.
- Kalan %90'lık program ifadeleri (çekirdek dışı) sadece toplam yürütme
süresinin %10'u için yürütülür.

**XXXVII. Yazılım Güvenilirliğinin Zorlukları**

- Yazılım güvenilirliğinin zor olmasının nedenleri şunlardır:

- Bir hata düzeltildiğinde güvenilirliğin artışı, hatanın kod içinde
nerede bulunduğuna bağlıdır.
- Bir yazılım ürününün algılanan güvenilirliği, gözlemciye bağlıdır.
- Bir ürünün güvenilirliği hatalar tespit edildikçe ve düzeltildikçe
değişir.
- Donanım güvenilirliği ile yazılım güvenilirliği farklılık gösterir.

**XXXVIII. Güvenilirlik Ölçütleri**

- Yazılım ürünlerinin güvenilirliğini nicel olarak ifade etmek için

kullanılabilecek altı güvenilirlik ölçütü vardır:
- ROCOF (Failure Rate)
- MTTF (Mean Time To Failure)
- MTTR (Mean Time To Repair)
- MTBR (Mean Time Between Failure)
- POFOD (Probability of Failure on Demand)
- Availability (Kullanılabilirlik)

**XXXIX. Hata Türleri ve Güvenilirlik Ölçümleri**

- Transient (Geçici) hatalar yalnızca belirli giriş değerleri için

oluşurken, kalıcı hatalar tüm giriş değerleri için oluşur.
- Kurtarılabilir hatalar, sistem operatör müdahalesi olmadan
kendiliğinden veya operatör müdahalesi ile iyileşir.
- Kurtarılamayan hatalarda sistem yeniden başlatılabilir.
- Kozmetik hatalar, yalnızca küçük rahatsızlıklara neden olur ve yanlış
sonuçlara yol açmaz.

**XL. Yazılım Güvenilirliğinin Sınıflandırılması**

- Yazılım ürünlerinin beş farklı türdeki hatalara sınıflandırılması

mümkündür:
- Transient (Geçici)
- Permanent (Kalıcı)
- Recoverable (Kurtarılabilir)
- Unrecoverable (Kurtarılamaz)
- Cosmetic (Kozmetik)

**XLI. Yazılım Bakımı**

- Yazılım bakımı, özel yazılımı değiştirmeyi veya yazılımın bir ortamdan

diğerine uyum sağlamasını sağlamayı içerir.
- Bakım genellikle özelleştirilmiş yazılımın yapısal değişiklikleri
gerektirmez.
- Bakım, genellikle mevcut bileşenleri değiştirerek ve yeni bileşenler
ekleyerek uygulanır.

**XLII. Yazılım Bakımı Türleri**

- Yazılım bakımının üç temel türü vardır:

- Hata Onarımı (Corrective Maintenance)
- Çevresel Değişiklik (Adaptive Maintenance)
- İyileştirme (Perfective Maintenance)

**XLIII. Yazılım Bakım Maliyeti**

- Yazılım bakım maliyetleri genellikle geliştirme maliyetlerinden daha

büyüktür (uygulamaya bağlı olarak 2 ila 100 kat arasında).
- Hem teknik hem de teknik olmayan faktörlerden etkilenir.
- Bakım, yazılım yapısını bozar ve daha fazla bakımı zorlaştırır.
- Yaşlanan yazılımın yüksek destek maliyetleri olabilir.

**XLIV. Yazılım Bakım Maliyet Faktörleri**

- Bakım maliyetlerini etkileyen faktörler şunlardır:

- Takımın Kararlılığı
- Sözleşmeye Dayalı Sorumluluk
- Personel Becerileri
- Program Yaşı ve Yapısı

**XLV. Bakım Tahmini ve Yeniden Mühendislik**

- Bakım tahmini, sistemin hangi kısımlarının sorunlara neden

olabileceğini değerlendirmekle ilgilidir.
- Değişiklik kabulü, etkilenen bileşenlerin bakım süreçlerini tahmin
eder.
- Tahmin maliyetleri, yazılımın kalitesine, mühendislik sürecine, destek
araçlarına ve uzman personel bulunabilirliğine dayanır.

**XLVI. Sistem Yeniden Mühendisliği**

- Sistem yeniden yapılandırma, bir yazılım

ın belirli bir işlevselliğini veya tamamını değiştirmeden, sadece

bakımını kolaylaştırmak için bir kısmını veya tamamını yeniden yazmayı
içerir.
- Yeniden yapılandırma, genellikle bir sistemin sık sık bakım gerektiren
ancak sadece belirli alt sistemlerine ihtiyaç duyulan durumlar için
uygundur.

**XLVII. Yeniden Mühendisliğin Avantajları**

- Riskin Azaltılması
- Maliyetin Düşürülmesi
- Mevcut Bilginin Kullanımı
- Zaman Kazanımı

**XLVIII. Yeniden Mühendislik Süreci**

- Kaynak kod çevirisi

- Tersine mühendislik
- Program yapısı iyileştirmesi
- Program modülerleştirmesi
- Veri mühendisliği

**XLIX. Yeniden Mühendislik Maliyet Faktörleri**

- Yazılımın kalitesi
- Yeniden mühendislik için kullanılabilir araç desteği
- Gerekli veri dönüşümünün kapsamı
- Yeniden mühendislik için uzman personel bulunabilirliği

**L. Önleyici Bakım ve Yeniden Şekillendirme**

- Yeniden şekillendirme, yazılımın değişikliklere bağlı olarak zaman

içinde bozulmasını yavaşlatmayı amaçlayan sürekli bir iyileştirme
sürecidir.
- Yeniden şekillendirme, programın yapısını, karmaşıklığını azaltmaya
veya anlaşılabilir hale getirmeye odaklanır.
- Yeniden şekillendirme sırasında işlevsellik eklememelidir, sadece
program iyileştirmeye odaklanmalıdır.

**XLVII. Yazılım Kalitesi**

**XLVIII. Yazılım Kalitesi Yönetim Sistemi**

- Geleneksel olarak, bir kaliteli ürün, amacına uygunluğu açısından

tanımlanır.
- Yazılım ürünleri için amaç uygunluğu genellikle SRS belgesinde
belirtilen gereksinimlerin karşılanması olarak yorumlanır.
- Modern bir kalite anlayışı, bir yazılım ürünü ile ilişkilendirilen
birkaç kalite faktörünü içerir, bunlar şunlardır:
- Taşınabilirlik: Yazılım ürünü, farklı işletim sistemlerinde, farklı
makinelerde, diğer yazılım ürünleriyle vb. kolayca çalıştırılabilirse
taşınabilir olarak adlandırılır.
- Kullanılabilirlik: Yazılım ürünü, uzman ve acemi kullanıcılar dahil
olmak üzere farklı kullanıcı kategorilerinin ürünün fonksiyonlarını
kolayca çağırabiliyorsa iyi kullanılabilirliğe sahiptir.
- Yeniden Kullanılabilirlik: Yazılım ürünü, ürünün farklı modüllerinin
yeni ürünler geliştirmek için kolayca yeniden kullanılabiliyorsa iyi
yeniden kullanılabilirliğe sahiptir.
- Doğruluk: Yazılım ürünü, SRS belgesinde belirtilen gereksinimleri doğru
bir şekilde uygulamışsa doğru olarak adlandırılır.
- Bakım Kolaylığı: Yazılım ürünü, hataların kolayca düzeltilebildiği,
yeni işlevlerin kolayca eklenebildiği ve ürünün işlevselliğinin kolayca
değiştirilebildiği şekilde bakım kolaylığına sahiptir.

**XLIX. Yazılım Kalitesi Yönetim Sistemi**

- Bir kalite yönetim sistemi (sıklıkla kalite sistemi olarak da

adlandırılır), organizasyonların geliştikleri ürünlerin istenen kaliteye
sahip olduğundan emin olmak için kullandıkları temel metodolojidir.
- Kalite yönetim sistemi (QMS), belgelenmiş süreçleri, prosedürleri ve
kalite politikalarını ve hedeflerini başarmak için sorumlulukları
belirleyen formalize edilmiş bir sistem olarak tanımlanır.
- Bir QMS, bir organizasyonun faaliyetlerini koordine etmeye ve
yönlendirmeye yardımcı olarak müşteri ve düzenleyici gereksinimleri
karşılamak ve sürekli olarak etkinlik ve verimliliğini artırmak için
tasarlanmıştır.

**L. Kalite Sistemine İlişkin Unsurlar**

- Kalite sistemi, aşağıdaki unsurlardan oluşur:

- Yönetim Yapısı ve Bireysel Sorumluluklar: Kalite sistemi, genel olarak
organizasyonun sorumluluğudur. Ancak, her organizasyonun çeşitli kalite
sistem faaliyetlerini yerine getirmek için ayrı bir kalite departmanı
bulunmaktadır.
- Kalite Sistem Faaliyetleri: Kalite sistem faaliyetleri, projelerin
denetlenmesini, kalite sisteminin gözden geçirilmesini, standartların,
yöntemlerin ve yönergelerin geliştirilmesini ve organizasyondaki kalite
sisteminin etkinliğini özetleyen belgelerin üst yönetim için üretilmesini
içerir.

**LI. Kalite Yönetim Sistemi Faydaları**

- Müşteri gereksinimlerini karşılama, bu da organizasyona güven

aşılamaya, daha fazla müşteriye, daha fazla satışa ve daha fazla tekrar
işe yol açar.
- Organizasyonun gereksinimlerini karşılama, bu da düzenlemelere uyumu ve
ürün ve hizmetleri en ekonomik ve kaynak verimli şekilde sağlamayı
içerir; bu da genişleme, büyüme ve kar sağlama olanağı yaratır.
- Bu faydalar, süreçleri tanımlamanın, iyileştirmenin ve kontrol etmenin
yanı sıra organizasyonun sürekli olarak güçlendirilmesi ve verimliliğinin
artırılmasının bir sonucudur.

**LII. ISO 9000 Sertifikası**

- ISO (Uluslararası Standartlar Organizasyonu), standartlaştırmayı

planlamak ve teşvik etmek amacıyla kurulmuş 63 ülkenin bir grup veya
konsorsiyumudur.
- ISO, 1987'de 9000 serisini duyurdu. Bu seri, bağımsız taraflar
arasındaki sözleşmelere bir referans olarak hizmet eder.
- ISO 9000 standardı, bir kalite sistemi sürdürme yönergelerini belirler.
- ISO standardı, temel olarak üretim süreciyle ilgili operasyonel
yöntemleri ve sorumlulukları ele alır.
- ISO 9000, üretim süreci için bir dizi kılavuz belirler ve doğrudan
ürünle ilgili değildir.

**LIII. ISO 9000 Kalite Standartlarının Türleri**

- ISO 9000, üç standart serisinden oluşur: ISO 9001, ISO 9002 ve ISO
9003.
- ISO 9000 serisi, doğru bir süreç izlenirse kaliteli ürünlerin otomatik
olarak takip edeceği temeline dayanmaktadır.
- ISO 9001, tasarım, geliştirme, üretim ve hizmet sunumu ile uğraşan
organizasyonlara uygundur.
- ISO 9002, ürün tasarımı yapmayan ancak sadece üretimle il

gilenen organizasyonlara uygundur.

- ISO 9003, sadece ürün kurulumu ve testiyle uğraşan organizasyonlar için
uygundur.

**LIV. ISO 9000 Sertifikası Nasıl Alınır?**

- Bir organizasyon, ISO 9000 sertifikası almayı düşündüğünde, ISO kayıt

ofisine başvurur.
- Süreç aşamalarını şu şekilde özetleyebiliriz:
- Başvuru: Bir organizasyon, ISO sertifikası için başvuruda bulunur.
- Ön Değerlendirme: Bu aşamada, kayıt ofisi organizasyonun bir genel
değerlendirmesini yapar.
- Belge İnceleme ve Denetleyicilik: Bu aşamada, kayıt ofisi organizasyon
tarafından sunulan belgeleri gözden geçirir ve bir iyileştirme önerisinde
bulunur.
- Uyum Denetimi: Bu aşamada, kayıt ofisi organizasyonun, gözden geçirme
sırasında önerilenleri uygulayıp uygulamadığını kontrol eder.
- Kayıt: Kayıt ofisi, tüm aşamaların başarıyla tamamlanmasının ardından
ISO sertifikasını verir.
- Devam Eden İnceleme: Kayıt ofisi zaman içinde organizasyonu devam
ettirir ve denetler.

**Program testi,**

bir yazılımın beklendiği gibi çalıştığını göstermek ve kullanılmadan önce

program kusurlarını ortaya çıkarmak amacıyla gerçekleştirilen bir
süreçtir. Yazılımı yapay veri kullanarak çalıştırır, test sonuçlarını
hatalar, anormallikler ve programın işlevsel olmayan özellikleri
açısından kontrol eder.

**Program Testi Hedefleri:**

1. Yazılımın gereksinimleri karşıladığını geliştirici ve müşteriye
göstermek.
- Özel yazılım için her gereksinim için en az bir test olmalıdır. Genel
yazılım ürünleri için, ürün sürümüne dahil edilecek tüm sistem
özellikleri ve bu özelliklerin kombinasyonları için testler olmalıdır.
2. Yazılımın davranışının yanlış, istenmeyen veya spesifikasyonla uyumsuz
olduğu durumları keşfetmek.
- Hata testi, sistem çökmeleri, istenmeyen diğer sistemlerle
etkileşimler, yanlış hesaplamalar ve veri bozulmaları gibi istenmeyen
sistem davranışlarını ortaya çıkarmakla ilgilidir.

**Doğrulama ve Hata Testi:**

- Birinci hedef doğrulama testine yol açar; sistem beklenen kullanım
durumlarını yansıtan bir test kümesini başarıyla geçtiğinde, sistemin
istendiği gibi çalıştığını gösterir.
- İkinci hedef, hata testine yol açar; test durumları kasti olarak
anlaşılmaz olabilir ve sistem normalde nasıl kullanıldığını yansıtmak
zorunda değildir.

**Doğrulama ile Doğrulama Arasındaki Farklar:**

- Doğrulama, yazılımın spesifikasyonlarına uygun olup olmadığını sağlar.
- Doğrulama, kullanıcının gerçekten istediği şeyi yapup yapmadığını
kontrol eder.

**Doğrulama ve Doğrulama Güveni:**

- V & V'nin amacı sistemin 'amaç için uygun' olduğuna dair güven
oluşturmaktır.
- Güven, sistemin amacına, kullanıcı beklentilerine ve pazar ortamına
bağlıdır.

**İncelemeler ve Test:**
- İncelemeler, statik sistem temsilinin analizi ile ilgilenir,
problemleri ortaya çıkarmak için (statik doğrulama).
- Test, ürün davranışını gözlemleyerek ve işlevsel olmayan davranışa
odaklanarak dinamik doğrulama ile ilgilenir.

**Test Aşamaları:**
1. Geliştirme testi - sistemdeki hataları keşfetmek için geliştirme
aşamasında yapılır.
2. Sürüm testi - ayrı bir test ekibi, kullanıcılara sunulmadan önce
sistemin tam bir sürümünü test eder.
3. Kullanıcı testi - kullanıcılar veya potansiyel kullanıcılar, sistemi
kendi ortamlarında test eder.

**Test Kılavuzları:**
- Sistemin tüm hata mesajlarını üretmesini sağlayacak girişleri seçin.
- Giriş tamponlarının taşmasına neden olacak tasarımlar yapın.
- Aynı girişi veya giriş serisini defalarca tekrarlayın.
- Geçersiz çıktıların üretilmesini zorlayın.
- Hesaplama sonuçlarının çok büyük veya çok küçük olmasını zorlayın.

**İşlevsel Test:**
- Her yazılım işlevinin gereksinim ve spesifikasyonlara uygun olduğunu
doğrulayan bir test türüdür.
- Kaynak koduyla ilgilenmez, uygulama işlevselliğini test eder.
- Uygulama arayüzünü, API'ları, veritabanını, güvenliği, istemci veya
sunucu uygulamasını ve uygulamanın işlevselliğini test eder.
- Manuel veya otomatik olabilir.

**İşlevsel Test Türleri:**

- Beyaz kutu, siyah kutu, gri kutu, birim, entegrasyon, kullanıcı kabul,
arayüz, bileşen, duman, kullanılabilirlik, sistem, regresyon, anlık,
veritabanı, ad hoc, kurtarma, statik test.

**Beyaz Kutu Test:**

- Bir yazılım uygulamasının iç yapısını ve işleyişini test eden bir
yazılım testi tekniğidir.
- Tester, kaynak koda erişime sahiptir ve bu bilgiyi kullanarak yazılımın
kod düzeyinde doğruluğunu doğrulayabilen test durumları tasarlar.
- İç yapıları, kullanılan veri yapıları, iç tasarım, kod yapısı ve
yazılımın işleyişini siyah kutu testinde olduğu gibi sadece işlevsellik
değil, inceleyen bir yazılım testi tekniğidir.
- Ayrıca cam kutu testi veya şeffaf kutu testi veya yapısal test olarak
da adlandırılır.
- Beyaz Kutu Testi, şeffaf test veya açık kutu testi olarak da bilinir.

**Beyaz Kutu Test Çalışma Süreci:**

1. Giriş: Gereksinimler, Fonksiyonel özellikler, tasarım belgeleri,
kaynak kodu.
2. İşleme: Tüm süreci rehberlik etmek için risk analizi yapma.
3. Uygun test planlama: Tüm kodu kapsayacak şekilde test durumları
tasarlama. Hata içermeyen yazılıma ulaşılana kadar tekrar et ve ayrıca
sonuçları ileti.
4. Çıktı: Tüm test sürecinin nihai raporunu hazırlama.

**Beyaz Kutu Test Adımları:

**
1. Kodu iyi anlamak.
2. Bazı test durumları için kod yazmak ve bunları yürütmek.
**Beyaz Kutu Testinin Avantajları:**
- Beyaz kutu testi, tüm kod ve yapıların test edilmesi nedeniyle
kapsamlıdır.
- Kodu optimize ederek hataları giderir ve gereksiz kod satırlarını
kaldırır.
- Arayüz gerektirmediği için siyah kutu testi gibi erken başlayabilir.
- Kolay otomatize edilebilir.
- Yazılım Geliştirme Yaşam Döngüsü'nde kolayca başlatılabilir.
- Kod Optimizasyonu Kolaydır.

**Beyaz Kutu Testinin Dezavantajları:**

- Çok maliyetlidir.
- Kodu yeniden tasarlamak ve yeniden yazmak test durumlarının tekrar
yazılmasını gerektirir.
- Testçilerin kod ve programlama dilinin derin bilgisini gerektirir, bu
siyah kutu testine göre daha karmaşıktır.
- Kod test edilen mevcut olduğu için eksik işlevsellikleri tespit edemez.
- Çok karmaşık ve bazen gerçekçi olmayabilir.
- Üretimde çok daha fazla hata olasılığı vardır.

**Black Box Testing (Siyah Kutu Testi):**

- Yazılımın işlevselliği bilinmeden gerçekleştirilen bir yazılım testi
türüdür.
- Ürünün iç yapısı hakkında bilgi olmadan test yapılır.
- Fonksiyonel testleme olarak da adlandırılır.
- Siyah kutu testi, yazılımın dış özelliklerine ve davranışına odaklanır.
- Bu tür test, bir uygulamanın yazılımının kullanıcı bakış açısından
beklenen davranışına odaklanır.

**Black Box Testing Türleri:**

- Fonksiyonel Testleme
- Regresyon Testleme
- Fonksiyonel Olmayan Testleme (NFT)

**Black Box Testing Türleri:**

1. **Fonksiyonel Testleme:** Sistemin yazılım fonksiyonel
gereksinimlerini belirler.
2. **Regresyon Testleme:** Yeni eklenen kodun mevcut kod ile uyumlu
olduğunu sağlar. Yani, yeni bir yazılım güncellemesinin yazılımın
işlevselliği üzerinde bir etkisi olmaz. Bu, bir sistem bakım işlemi ve
güncellemelerden sonra gerçekleştirilir.
3. **Fonksiyonel Olmayan Testleme:** Fonksiyonel olmayan testleme olarak
da bilinir (NFT). Bu test, yazılımın performansı, kullanılabilirliği ve
ölçeklenebilirliğine odaklanır.

**Siyah Kutu Testleme Özellikleri:**

- Bağımsız testleme
- Bir kullanıcının bakış açısından testleme
- İç kod bilgisi olmaması
- Gereksinimlere dayalı testleme
- Farklı test teknikleri
- Otomatize etmesi kolay
- Ölçeklenebilirlik
- Sınırlı uygulama bilgisi
**Siyah Kutu Testleme Avantajları:**
- Testçinin Siyah Kutu Testleme uygulamak için daha fazla işlevsel
bilgiye veya programlama becerilerine ihtiyacı yoktur.
- Büyük sistemlerde testleri uygulamak için etkilidir.
- Testler, kullanıcının veya müşterinin bakış açısından yürütülür.
- Test durumları kolayca tekrarlanabilir.
- Fonksiyonel özelliklerdeki belirsizlikleri ve çelişkileri bulmada
kullanılır.

**Siyah Kutu Testleme Dezavantajları:**

- Test sürecini uygularken aynı testleri tekrarlama olasılığı vardır.
- Belirgin fonksiyonel özellikler olmadan test durumlarını uygulamak
zordur.
- Farklı test aşamalarında karmaşık girişlerden dolayı test durumlarını
yürütmek zordur.
- Test başarısızlığının nedeni bazen tespit edilemez.
- Uygulamanın bazı bölümleri test edilmez.
- Kontrol yapısındaki hataları ortaya çıkarmaz.
- Büyük bir örnek uzayıyla çalışmak yorucu ve zaman alıcı olabilir.

**Gri Kutu Testleme:**

- Gri Kutu Testleme, Siyah Kutu Testleme tekniği ile Beyaz Kutu Testleme
tekniğinin bir kombinasyonudur.
- Siyah Kutu Testleme tekniğinde testçi, test edilen öğenin iç yapısını
bilmezken, Beyaz Kutu Testleme'de iç yapısı testçi tarafından bilinir.
- Gri Kutu Testleme' de iç yapının bilinme durumu kısmen vardır. Bu, test
durumlarını tasarlamak için iç veri yapılarına ve algoritmalarına erişim
içerir.

**Gri Kutu Testleme Özellikleri:**

- Kısmen saydam veya gri bir kutu olarak adlandırılır çünkü yazılım
programı testçi tarafından kısmen görülebilir.
- Genellikle web sistemleri ile ilgili bağlam özel hatalara odaklanır.
- Bu, programın test edilmeden önce tüm koşulların sunulduğu bir
gereksinim test durumu üretimine dayanır.

**Gri Kutu Testleme Teknikleri:**

- Matris Testleme
- Desen Testleme
- Ortogonal Dizi Testleme
- Regresyon Testleme
- Durum Geçişi Testleme
- Karar Tabloları Testleme
- API'ları Test Etme
- Veri Akış Testleme

**Gri Kutu Testleme Avantajları:**

- Kullanıcılar ve geliştiriciler test yaparken net hedeflere sahiptir.
- Gri kutu testleme çoğunlukla kullanıcı perspektifinden yapılır.
- Testçilerin bu test için yüksek programlama becerilerine ihtiyacı
yoktur.
- Gri kutu testleme, müdahaleci değildir.
- Ürünün genel kalitesi artar.
- Gri kutu testleme ile geliştiricilere hata düzeltme için daha fazla
zaman verilir.
- Gri kutu testleme, hem siyah kutu hem de beyaz kutu testlemenin
avantajlarını sağlar.
- Gri kutu testleme tarafsızdır ve bir testçi ile bir geliştirici
arasındaki çatışmalardan kaçınır.
- Gri kutu testleme entegrasyon testlerinde daha etkilidir.

**Gri Kutu Testleme Dezavantajları:**

- Gri testleme dağıtılmış sistemler için yapıldığında hata birlikteliği
zordur.
- İç yapılara sınırlı erişim, kod yolu gezinmesi için sınırlı erişim
anlamına gelir.
- Kaynak koduna erişim mümkün olmadığından tam beyaz kutu testleme yapmak
mümkün değildir.
- Gri kutu

testleme, algoritma testi için uygun değildir.

- Test durumlarının çoğu zordur tasarlanması.

**Beyaz Kutu, Siyah Kutu ve Gri Kutu Testlemenin Farkları:**

| No | Beyaz Kutu Testleme | Gri Kutu Testleme | Siyah Kutu Testleme |

|----|--------------------|-------------------|---------------------|
| 1 | Düşük granulariteye sahiptir. | Orta düzeyde granülerdir. | Yüksek
düzeyde granüleriteye sahiptir. |
| 2 | Son kullanıcılar ve testçiler ve geliştiriciler tarafından yapılır.
| Son kullanıcılar (kullanıcı kabul testi olarak adlandırılır) ve
testçiler ve geliştiriciler tarafından yapılır. | Genellikle testçiler ve
geliştiriciler tarafından yapılır. |
| 3 | İç yapının bilinmesine gerek yoktur. | Test ile ilgili olan iç yapı
bilinir. | Uygulama ve veritabanının iç kodu bilinir. |
| 4 | Diğer ikisine göre daha az kapsamlıdır. | Orta noktada bir
durumdur. | En kapsamlı olanıdır. |
| 5 | Gereksinimlere dayalıdır ve içlerinin bilinmemesi nedeniyle
fonksiyonel özelliklere dayalıdır. | İçerideki bilgilerin yüksek düzeyde
olması nedeniyle test durumlarındaki çeşitliliği ve derinliği sağlar. |
İlgili veri çeşitliliği ile kodu etkileyebilir. |
| 6 | Algoritma testi için en uygun değildir. | Algoritma testi de
kullanılmaz. | Algoritma testi için en uygunudur. |
| 7 | Fonksiyonel veya iş testleri için uygundur. | Fonksiyonel veya iş
domain testleri için derindir. | Tüm test türleri için uygundur. |
| 8 | Bu test, belirli girişler için çıktıları doğrulamayı içerir ve
uygulama bir siyah kutu tekniği olarak test edilir. | İçeride daha fazla
giriş çeşitliliği ve veritabanından test sonuçlarını çıkarabilme
yeteneğimiz olduğu için daha iyi bir çeşitliliğe sahibiz. | Kod içindeki
yapıları, kararları, vb. içeren yapısal testi içerir. |
| 9 | Bu, Opaque-box testi, Closed-box testi, input-output testi, Data-
driven testi, Behavioral, Functional testleme olarak da adlandırılır. |
Bu, ayrıca translusent kutu testleme olarak adlandırılır. | Bu, Glass-box
testleme, Clear-box testleme, Design-based testleme, Logic-based
testleme, Structural testleme ve Code-based testleme olarak da
adlandırılır. |
| 10 | Siyah kutu testi tasarım teknikleri - Decision table testleme,
All-pairs testleme, Equivalence partitioning, Error guessing | Gri kutu
testi tasarım teknikleri - Matrix testleme, Regression testleme, Pattern
testleme, Orthogonal Array testleme | Beyaz kutu testi tasarım teknikleri
- Control flow testleme, Data flow testleme, Branch testleme |
| 11 | Siyah kutu testleme, viral saldırılara karşı dayanıklılık ve
güvenlik sağlar. | Gri kutu testleme, viral saldırılara karşı
dayanıklılık ve güvenlik sağlamaz. | Beyaz kutu testleme, viral
saldırılara karşı dayanıklılık ve güvenlik sağlamaz. |
**Development Testing (Geliştirme Testi):**
- Geliştirme testi, sistemi geliştiren takım tarafından gerçekleştirilen
tüm test faaliyetlerini içerir.
- **Unit Testing (Birim Testi):** Bireysel program birimleri veya nesne
sınıfları test edilir. Odak, nesnelerin veya yöntemlerin işlevselliğini
test etmeye yönelmelidir.
- **Component Testing (Bileşen Testi):** Birkaç bireysel birim, bileşik
bileşenleri oluşturmak için entegre edilir. Bileşen testi, bileşen
arabirimlerini test etmeye odaklanmalıdır.
- **Integration Testing (Entegrasyon Testi):** Yazılım uygulamasının
farklı birimleri veya bileşenleri birbirleriyle etkileşimde bulunur.
- **System Testing (Sistem Testi):** Bir sistemin bazı veya tüm
bileşenleri entegre edilir ve sistem bütün olarak test edilir. Sistem
testi, bileşen etkileşimlerini test etmeye odaklanmalıdır.

**Unit Testing (Birim Testi):**

- Birim testi, bireysel bileşenleri izole bir şekilde test etme
sürecidir.
- Bir hata testleme sürecidir.
- Birimler, bireysel bir nesnenin içindeki işlevler veya yöntemler,
birkaç özellik ve yönteme sahip nesne sınıfları veya tanımlanmış
arayüzleri kullanarak işlevselliğine erişilen bileşik bileşenler
olabilir.

**Unit Testing Avantajları:**

- Hataların erken aşamada tespit edilmesine yardımcı olur, böylece
düzeltmek için zaman ve para tasarrufu sağlar.
- Kod değişikliklerinin yeni hataları içermemesini sağlar.
- Kodu daha modüler, anlaşılır ve bakımı kolay hale getirir.
- Genel kalite ve güvenilirliği artırmaya yardımcı olur.

**Component Testing (Bileşen Testi):**

- Yazılım bileşenleri genellikle birkaç etkileşen nesneyi içeren bileşik
bileşenlerdir.
- Örneğin, hava istasyonu sisteminde, yeniden yapılandırma bileşeni,
yeniden yapılandırmanın her yönü ile ilgilenen nesneleri içerir.
- Bu nesnelerin işlevselliğine, tanımlanan bileşen arabirimine erişim
aracılığıyla odaklanır.
- Bileşen testi, dolayısıyla, bileşen içindeki bireysel nesneler üzerinde
yapılan birim testlerin tamamlandığını varsayabilir.

**Component Testing ve Unit Testing Arasındaki Farklar:**

- Component Testing, tüm yazılım geliştirildikten sonra yürütülür. Unit
Testing, her geliştirme adımından sonra uygulanır.
- Component Testing, her bir bireysel bileşenin kullanılabilirliğini test
eden bir yazılım testi türüdür. Unit Testing, her bir kod birimini test
etmek için her bir kod birimini göz önüne alır ve tüm kod setlerinin
uygun olduğundan emin olmak için yapılır.

**Integration Testing (Entegrasyon Testi):**

- Entegrasyon testi, ilişkili bir grup modülü test ettiğimiz ikinci bir
test seviyesidir.
- Bu testte, birbirleriyle etkileşim halinde olan iki veya daha fazla
birim test edilir. Yani, entegre modüllerin bu modüllerin beklentiye
uygun olarak çalışıp çalışmadığı ve arayüz hataları da kontrol edilir.

**Integration Testing (Entegrasyon Testi):**

- Entegrasyon testi, bir yazılım uygulamasının farklı birimlerinin
birbirleriyle nasıl etkileşim kurduğunu test etme yöntemidir. Farklı
yazılım birimleri birleştirildiğinde ortaya çıkabilecek herhangi bir
sorunu tanımlamak ve çözmek için kullanılır.
- Entegrasyon testi genellikle birim testinden sonra ve işlevsel testten
önce yapılır ve yazılımın farklı birimlerinin beklendiği gibi bir araya
gelip gelmediğini doğrulamak için kullanılır.

**Integration Testing (Entegrasyon Testi):**

- Hedef, modüller arasındaki arayüz sorunlarını bulmaktır; yani bireysel
birimlerin bir alt sistem olarak doğru bir şekilde entegre edilip
edilemeyeceğini belirlemektir.
- Dört türü vardır:
- Big-bang,
- Top-down,
- Bottom-up ve
- Hybrid.

**Integration Testing (Entegrasyon Testi):**

- Big-bang entegrasyonunda, tüm modüller önce tamamlanmalı ve ardından
entegre birim olarak test edilmelidir.
- Top-down entegrasyon testinde, test akışı, hiyerarşide daha yüksek olan
üst düzey modüllerden başlayarak alt düzey modüllere doğru ilerler. Alt
düzey modüllerin başlangıçta geliştirilmemiş olma olasılığı olduğundan,
üst düzey modüllerle başlarken kullanılan taklit modüller veya işlevler
olan stub'lar kullanılır.
- Bottom-up entegrasyon testi de artan bir yaklaşıma dayanır, ancak alt
düzey modüllerden başlayarak yukarı doğru hareket eder. Yine, alt düzey
modüller test edilirken üst düzey modüller geliştirilmemiş olabilir. Bu
durumlarda driver'lar kullanılır. Bu driver'lar, alt düzey modülleri test
etmek için üst düzey modüllerin işlevselliğini taklit eder.
- Hybrid entegrasyon testi, aynı zamanda Sandviç entegrasyon yaklaşımı
olarak adlandırılır. Bu yaklaşım, entegrasyonun orta katmandan
başlamasını sağlar ve gerektiğinde hem stub'ları hem de driver'ları
kullanarak her iki yönde test yapar.

**Entegrasyon Testinin Avantajları:**

- Yazılım birimleri birleştirildiğinde ortaya çıkabilecek sorunları
tanımaya ve çözmeye yardımcı olur.
- Yazılımın farklı birimlerinin amaçlandığı gibi bir araya gelip
gelmediğini doğrulamaya yardımcı olur.
- Yazılımın genel güvenilirliğini ve istikrarını artırmaya yardımcı olur.
- Farklı bileşenlerin birleştirildiği karmaşık sistemlerde entegrasyon
testi önemlidir.
- Entegrasyon testi, yazılımın kullanıcı ihtiyaçlarını karşıladığından
emin olmak için birim testi, işlevsel test ve kabul testi gibi diğer test
türleriyle birleştirilerek kullanılmalıdır.

**Entegrasyon Testi Örneği:**

- **Black Box Testing (Siyah Kutu Testi):** Doğrulama için kullanılır. İç
işleyiş mekanizmalarını yok sayar ve sadece çıktıya odaklanır.
- **White Box Testing (Beyaz Kutu Testi):** Doğrulama için kullanılır. İç
mekanizmalara odaklanır, yani çıktının nasıl elde edildiği.
- Başka bir örnek: Finans uygulamasının entegrasyon testinde,
hesaplamaların ve veritabanı etkileşimlerinin doğru çalışıp çalışmadığı
kontrol edilebilir.

**System Testing (Sistem Testi):**

- Geliştirme sırasında sistem testi, bileşenleri entegre ederek sistem
sürümünü oluşturmayı ve ardından entegre sistemi test etmeyi içerir.
- Sistem testindeki odak, bileşenler arasındaki etkileşimleri test
etmektir.
- Sistem testi, bileşenlerin uyumlu olup olmadığını, doğru zamanında
doğru veriyi transfer edip etmediğini kontrol eder.
- Sistem testi, bir sistemin ortaya çıkan davranışını test eder.

**System Testing (Sistem Testi):**

- Sistem testi, test seviyelerinin üçüncü seviyesidir.
- Tamamen entegre bir uygulamanın bütün olarak test edildiği bir
seviyedir.
- Uygulamanın iş gereksinimlerine uygun olup olmadığını belirlemeyi
amaçlar.
- Sistem testi, üretim ortamına çok benzeyen bir ortamda
gerçekleştirilir.

**System Testing Örneği:**

- Bu, fonksiyonel ve fonksiyonel olmayan testleri içerir.
- Başka bir örnek: Bir proje yönetimi yazılımının tüm modüllerinin
kombinasyonunu kontrol ederek QA ekibi, kullanıcıların farklı özellikleri
bir arada kullanma yeteneklerini test edebilir.

**System ve Component Testing (Sistem ve Bileşen Testi):**

- Sistem testi sırasında, ayrı

olarak geliştirilmiş ve rafa koyulmuş sistemler, yeni geliştirilen

bileşenlerle entegre edilebilir. Tam sistem test edilir.
- Farklı takım üyeleri veya alt takımlar tarafından geliştirilen
bileşenler bu aşamada entegre edilebilir. Sistem testi, bireysel bir
süreçten ziyade kolektif bir süreçtir.
- Bazı şirketlerde, sistem testi, tasarımcıların ve programcıların
katılımı olmadan tamamen ayrı bir test ekibi tarafından
gerçekleştirilebilir.
**User Testing (Kullanıcı Testi):**
- Kullanıcı veya müşteri testi, kullanıcıların veya müşterilerin sistem
testi üzerine giriş ve tavsiyelerde bulunduğu bir test süreci aşamasıdır.
- Kapsamlı sistem ve sürüm testleri gerçekleştirilmiş olsa bile,
kullanıcı testi esastır.
- Bunun sebebi, kullanıcının çalışma ortamının, bir sistemin
güvenilirliği, performansı, kullanılabilirliği ve sağlamlığı üzerinde
büyük bir etkisi olmasıdır ve bunlar test ortamında çoğaltılamaz.

**Kullanıcı Testi Türleri:**

1. **Kabul Testi:**
- Müşteriler, bir sistemin sistem geliştiricilerinden kabul edilecek
durumda olup olmadığına karar vermek için bir sistem testine tabi
tutarlar. Genellikle özel sistemler için kullanılır.
2. **Alfa Testi:**
- Yazılımın kullanıcıları, yazılımı geliştirici yerinde test etmek için
geliştirme ekibiyle birlikte çalışırlar.
3. **Beta Testi:**
- Yazılımın bir sürümü kullanıcılara sunularak, kullanıcıların sistemi
deneyimlemelerine ve keşfettikleri sorunları sistem geliştiricilerine
bildirmelerine izin verilir.

**Kabul Testi:**
- Kabul testi, uygulamanın belirtilen iş gereksinimlerine uygunluğunu ve
tanımlanan kalite standardını karşılayıp karşılamadığını sağlamayı
amaçlayan en son ve en önemli test seviyelerinden biridir.
- İki türü vardır: alfa testi ve beta testi.
- Kabul testi, testlerin veya başka bir organizasyonun içindeki iç
çalışanlar tarafından geliştiricinin yerinde gerçekleştirildiğinde alfa
testi olarak bilinir.
- Kullanıcı kabul testi, son kullanıcılar tarafından son kullanıcının
yerinde gerçekleştirilen bir beta testidir.

**Kabul Testi Türleri:**

- **Kullanıcı Kabul Testi (UAT):** Geliştirilen uygulama, son kullanıcı
bakış açısından değerlendirilir, son kullanıcılar için çalışıp
çalışmadığı kontrol edilir. Sadece geliştirici organizasyonunun
çalışanları tarafından yapılır. 'Son Kullanıcı Testi' olarak da bilinir
ve siyah kutu testi modunu takip eder.
- **İş Kabul Testi (BAT):** İş kabul testi, geliştirilen uygulamayı iş
hedefleri ve süreçleri perspektifinden değerlendirir. Sistemin gerçek
dünya operasyonel zorluklara ve gerçek dünya ihtiyaçlarına hazır
olduğundan emin olmak için yapılır. Bağımsız bir test ekibi tarafından
gerçekleştirilir ve her ekibin müşterinin alanı ve iş hakkında kesin
bilgiye sahip olması gerekir.
- **Sözleşme Kabul Testi:** Bu tür bir test, geliştirilmiş sistemi
sözleşmede belirlenen kriterlere veya özelliklere karşı kontrol etmeyi
içerir. Sözleşme, müşteri ve geliştirme tarafından imzalanmış olmalıdır.
- **Regülasyon Kabul Testi:** Regülasyon kabul testi aynı zamanda
Uygunluk kabul testi olarak da bilinir. Sistemin yazılımın piyasaya
sürüleceği ülkenin kurallarına ve düzenlemelerine uygun olup olmadığını
kontrol eder. Genellikle uluslararası piyasaya sürülen bir ürün veya
uygulama, farklı ülkelerin farklı kuralları ve yasaları olduğu için böyle
bir teste ihtiyaç duyabilir.
- **Operasyonel Kabul Testi:** Bu, işlevsel olmayan bir testtir.
Uygulamanın operasyonel olarak hazır olduğundan emin olmayı amaçlar.
Operasyonel kabul testi, yedekleme veya geri yükleme olanaklarını,
kullanıcı kılavuzlarını, bakım görevlerini ve güvenlik kontrolünü içerir.

**Kabul Testi Süreci Aşamaları:**

1. Kabul kriterlerini tanımla
2. Kabul testini planla
3. Kabul testlerini türet
4. Kabul testlerini çalıştır
5. Test sonuçlarını müzakere et
6. Sistemi reddet/ona

**Agile Metodlar ve Kabul Testi:**

- Agile metodlarda, kullanıcı/müşteri geliştirme ekibinin bir parçasıdır
ve sistemın kabul edilebilirliği üzerinde kararlar almakla sorumludur.
- Testler, kullanıcı/müşteri tarafından tanımlanır ve değişiklikler
yapıldığında otomatik olarak çalıştırılan diğer testlerle entegre edilir.
- Ayrı bir kabul testi süreci yoktur.
- Temel sorun burada, gömülü kullanıcının 'tipik' olup olmadığı ve tüm
sistem paydaşlarının çıkarlarını temsil edip edemeyeceğidir.

**Kabul Testi:**
- Kabul testi, müşteriler tarafından teslim edilen ürünlerin belirli
görevleri gerçekleştirip gerçekleştirmediğini kontrol etmek için yapılır.
Test planları hakkında konuşmak ve projeleri yürütmek için Nesne
Yönelimli Test kullanırız.
- Kullanıcı ihtiyaçları, gereksinimler ve iş süreçlerine uygun olarak
resmi bir testtir. Bir sistem, kabul kriterlerini karşılayıp
karşılamadığını belirlemek ve kullanıcılara, müşterilere veya diğer
yetkili kişilere sistemi kabul ed

ip etmeme kararı vermek için test edilir.

- Kabul testi, yazılım geliştirme sürecinin son aşaması olan Sistem
Testi'nden sonra ve sistemi gerçek kullanım için kullanıma sunmadan önce
gerçekleştirilir.

**Kabul Testi Avantajları:**

- Bu test, kullanıcılardan doğrudan kullanıcı gereksinimlerini öğrenmek
için projeler ekibine yardımcı olur.
- Otomatik test yürütme.
- Bu test, müşterilere doğrudan katılım sağladığı için güven ve
memnuniyet getirir.
- Kullanıcının ihtiyacını açıklamak daha kolaydır.
- Yalnızca Siyah Kutu test sürecini kapsar ve bu nedenle ürünün tüm
işlevselliği test edilir.

**Kabul Testi Dezavantajları:**

- Kullanıcıların ürün veya uygulama hakkında temel bilgi sahibi olmaları
gerekir.
- Bazı durumlarda, kullanıcılar test sürecine katılmak istemeyebilir.
- Testin geri bildirimi uzun sürer, çünkü birçok kullanıcıyı içerir ve
görüşler bir kullanıcıdan diğerine farklılık gösterebilir.
- Geliştirme ekibi bu test sürecine katılmaz.

**Alfa Testi:**
- Alfa testi, bir tür onay testidir. Genellikle ürün müşterilere
sunulmadan önce gerçekleştirilen bir kullanıcı kabul testi türüdür.
Genellikle QA uzmanları tarafından yapılır.
- Alfa testi, ürünün gerçek kullanıcılara veya genel halka piyasaya
sürülmeden önce hataları belirlemek için gerçekleştirilen bir yazılım
testi türüdür.
- Alfa testi, genellikle yerel yazılım mühendisleri veya kalite güvence
personeli tarafından gerçekleştirilir. Bu, yazılımın gerçek dünya
ortamında piyasaya sürülmeden önce geçen bir son test aşamasıdır.

**Alfa Testi Süreci:**

1. Tasarım spesifikasyonunu ve işlevsel gereksinimleri gözden geçirin.
2. Kapsamlı test durumları ve test planları geliştirin.
3. Test planını uygulayın.
4. Hataları kaydedin.
5. Sorunlar düzeltildikten sonra tekrar test edin.

**Alfa Testinin Faydaları:**

- Hataların ve sorunların erken tanımlanması.
- İyileştirilmiş kalite.
- Artan kullanıcı memnuniyeti.
- Sorunların daha hızlı çözülmesi.
- Maliyet tasarrufu.

**Alfa Testinin Avantajları:**

- Yazılımın güvenilirliği hakkında erken bilgi.
- Ekibinizi diğer projeler için serbest bırakın.
- Piyasaya sunulma süresini kısaltır.
- Erken geri bildirim, yazılım kalitesini artırmaya yardımcı olur.

**Alfa Testinin Dezavantajları:**

- Proje büyükse, test planı uygulaması daha uzun sürebilir.
- Büyük projelerde bu alfa testinde üründeki hatalar bilinmez olabilir.
- Ürün henüz geliştirme aşamasında olduğu için tüm ürünü test etmek
zordur.
- Küçük projeler için alfa testine harcanan zaman yeterince değerli
olmayabilir.
- Güvenilirlik ve güvenlik testi yapılmaz.
- Bu test, iş müşterisi tarafından belirtilen iş gereksinimlerini kapsar.
Proje ekibi her bir modülün derin testinden geçmez.
- Ayrı bir laboratuvar ortamına ihtiyaç duyar.

**Alfa Testi Örneği:**

- Yazılım testi organizasyonu içinde gerçekleştirilen iç yazılım
testleri.
- Başka bir örnek: Şirket içinde yeni bir proje yönetimi yazılımı
kullanarak, şirket içindeki erken kullanıcılar yazılımın genel
performansını ve kullanılabilirliğini değerlendirebilirler.
**Beta Testing:**
- Beta testi, yazılımın son kullanıcısı tarafından bir veya daha fazla
müşteri sitesinde gerçekleştirilir. Bu sürüm, gerçek bir ortamda test
etmek için sınırlı sayıda kullanıcıya resmi olarak sunulur.
- Beta testi, yazılım ürününün veya hizmetinin resmi piyasaya sürülmeden
önce gerçek bir dünya ortamında test edilmesi sürecidir.
- Bu, yazılım geliştirme yaşam döngüsünde önemli bir adımdır çünkü
geliştirme süreci sırasında gözden kaçırılmış olabilecek hataları ve
hataları tespit etmeye yardımcı olur.

**Beta Testi:**
- Beta testi, yazılım uygulamasının gerçek kullanıcıları tarafından
gerçek bir ortamda gerçekleştirilir. Beta testi, Kullanıcı Kabul
Testi'nin bir türüdür.
- Yazılımın gerçek son kullanıcılarına bir ürünün Beta sürümü, ürün
kalitesi hakkında geri bildirim almak için sınırlı sayıda kullanıcıya
sunulur.
- Beta testi, ürün başarısızlık riskini en aza indirgemeye yardımcı olur
ve müşteri onayı aracılığıyla ürün kalitesini artırır.
- Bu, ürünü müşterilere göndermeden önce gerçekleştirilen son testtir.
- Beta testinin önemli avantajlarından biri, müşterilerden direkt geri
bildirim alınmasıdır.

**Beta Testi Özellikleri:**

- Beta testi, genellikle şirketin çalışanları olmayan müşteriler veya
kullanıcılar tarafından gerçekleştirilir.
- Güvenilirlik, güvenlik ve sağlamlık beta testi sırasında kontrol
edilir.
- Beta testi genellikle siyah kutu testi kullanır.
- Beta testi, kullanıcının yerinde gerçekleştirilir.
- Beta testi, bir laboratuvar veya test ortamı gerektirmez.

**Beta Testi Avantajları:**

- Müşteri onayı ile ürün başarısızlık riskini azaltır.
- Beta testi, lansman sonrası altyapıyı test etme olanağı sağlar.
- Müşteri geri bildirimi aracılığıyla ürün kalitesini artırma.
- Benzer veri toplama yöntemlerine göre maliyet etkilidir.
- Müşterilerle ilişkileri güçlendirir ve müşteri memnuniyetini artırır.

**Beta Testi Dezavantajları:**

- Bazen, hataları veya hataları takip etmek karmaşık olabilir çünkü test
ortamı kullanıcıdan kullanıcıya değişir.
- Hataların veya hataların tekrarı olasılığı vardır.
- Geliştirme ekibi ve test ekibi bu gerçek zamanlı test ortamında kontrol
sahibi değildir.
- Bu test süreci, gerçek zamanlı kullanıcılar veya müşteriler içerdiği
için zaman alıcıdır ve bu nedenle tüm ürün hakkında geri bildirimde
gecikmeye neden olabilir.
- Ürünü test eden kullanıcılardan yeterli bilgiye sahip olmaları
beklenir. Aksi takdirde, test etme etkili bir şekilde uygulanmaz.

**Beta Testi Örneği:**

- Yazılım testi, sınırlı sayıda kişi için gerçekleştirildiğinde.
- Başka bir örnek: Bir sosyal medya uygulamasının beta sürümünü
kullanarak, genel kullanıcılar uygulamanın farklı cihazlarda nasıl
çalıştığını test edebilirler.

**Alfa ve Beta Testi Arasındaki Farklar:**

| Alfa Testi | Beta Testi |

|------------|------------|
| Alfa testi hem beyaz kutu hem de siyah kutu testini içerir. | Beta
testi genellikle siyah kutu testi kullanır. |
| Alfa testi, genellikle organizasyonun iç çalışanları olan testçiler
tarafından gerçekleştirilir. | Beta testi, organizasyonun bir parçası
olmayan müşteriler tarafından gerçekleştirilir. |
| Alfa testi, geliştiricinin yerinde gerçekleştirilir. | Beta testi,
ürünün son kullanıcısı tarafından gerçekleştirilir. |
| Alfa testinde güvenilirlik ve güvenlik testi kontrol edilmez. | Beta
testi sırasında güvenilirlik, güvenlik ve sağlamlık kontrol edilir. |
| Alfa testi, ürünü beta teste göndermeden önce kalitesini sağlar. | Beta
testi de ürün kalitesine odaklanır ancak kullanıcı geri bildirimini
toplar ve ürünün gerçek kullanıcılar için hazır olduğunu sağlar. |
| Alfa testi, bir test ortamı veya laboratuvar gerektirebilir. | Beta
testi, bir test ortamı veya laboratuvar gerektirmez. |
| Alfa testi uzun bir yürütme döngüsü gerektirebilir. | Beta testi sadece
birkaç haftalık bir yürütme gerektirir. |
| Alfa testinde geliştiriciler, kritik sorunları hemen ele alabilir. |
Beta testinden toplanan çoğu sorun veya geri bildirim, gelecekteki ürün
sürümlerine uygulanır. |
| Alfa testinde birden fazla test döngüsü düzenlenir. | Beta testinde
sadece bir veya iki test döngüsü vardır. |

**Regression Testing:**
- Regresyon testi, değişikliklerin önceki şekilde çalışan kodu 'bozup
bozmadığını' kontrol etmek amacıyla sistem testini içerir.
- Manuel test sürecinde regresyon testi maliyetli olabilir, ancak
otomatik test ile bu süreç basit ve doğrudur. Her değişiklik yapıldığında
tüm testler tekrar çalıştırılır.
- Değişiklik yapılmadan önce testlerin "başarıyla" çalışması gereklidir.

**Regresyon Testi:**
- Regresyon testi, yazılıma yapılan değişikliklerin yeni hatalar
eklememesi veya mevcut işlevselliği bozmamasını sağlamak için kullanılan
bir test yöntemidir. Genellikle kod üzerinde hata düzeltmeleri veya yeni
özellikler gibi değişiklikler yapıldıktan sonra gerçekleştirilir.
- Regresyon testi, yazılımın hala amaçlandığı gibi çalıştığını doğrulamak
için kullanılır.

**Regresyon Testi:**
- Regresyon testi farklı şekillerde gerçekleştirilebilir, örneğin:
- Yeniden test: Bu, değişikliklerden etkilenen tüm uygulama veya belirli
işlevselliğin test edilmesini içerir.
- Yeniden yürütme: Bu, daha önce yürütülmüş bir test paketinin
değişikliklerin mevcut işlevselliği bozup bozmadığını kontrol etmek için
yeniden çalıştırılmasını içerir.
- Karşılaştırma: Bu, mevcut yazılım sürümünü bir önceki sürümle
karşılaştırarak değişikliklerin mevcut işlevselliği bozup bozmadığını
kontrol etmeyi içerir.

**Regresyon Testinin Avantajları:**

- Yazılıma yapılan değişikliklerin yeni hatalar eklememesini veya mevcut
işlevselliği bozmamasını sağlar.
- Yazılımın değişikliklerden sonra hala amaçlandığı gibi çalıştığını
doğrular.
- Yazılımın genel güvenilirliğini ve istikrarını artırabilir.
- Regresyon testi, yazılım geliştirme yaşam döngüsü boyunca sürekli
olarak yapılmalıdır ve mümkünse otomatikleştirilmelidir. Ayrıca, iyi
tanımlanmış bir regresyon test paketinizin olması önemlidir.

**Regresyon Testi Örnekleri:**

- Okul kayıtlarında, personel, öğrenci ve finans modülü gibi modüllerin
birleştirilmesi ve bu modüllerin entegrasyonunun regresyon testinde uygun
çalışıp çalışmadığının kontrol edilmesi.

**Yayın Testi (Release Testing):**

- Yayın testi, geliştirme ekibinin dışında kullanım için tasarlanmış bir
sistemin belirli bir sürümünü test etme sürecidir.
- Yayın testi sürecinin temel amacı, sistem tedarikçisini sistemın
kullanım için yeterli olduğuna ikna etmektir. Bu nedenle, yayın testi,
sistemin belirtilen işlevselliğini, performansını ve güvenilirliğini
sağlamalı ve normal kullanım sırasında hata vermemelidir.
- Yayın testi genellikle bir siyah kutu testi sürecidir ve testler
genellikle sistem spesifikasyonlarından türetilir.

**Yayın Testi ve Sistem Testi:**

- Yayın testi, bir sistem testi türüdür.
- Önemli farklar:
- Yayın testinden sorumlu olan, sistem geliştirmesine katılmamış ayrı bir
ekip olmalıdır.
- Sistem testi, geliştirme ekibi tarafından sistemdeki hataları
keşfetmeye odaklanmalıdır (defect test). Yayın testinin amacı, sistemin
gereksinimlere uygun olduğunu ve dış kullanım için yeterli olduğunu
kontrol etmektir (geçerlilik testi).

**Mentcare Sistemi Kullanım Senaryosu:**

- George, zihinsel sağlık alanında uzmanlaş

mış bir hemşiredir. Sorumluluklarından biri, hastaların evde

tedavilerinin etkili olup olmadığını ve ilaç yan etkilerinden muzdarip
olup olmadıklarını kontrol etmektir.
- Mentcare sistemine giriş yapan George, ev ziyaretleri için gününü
yazdırır ve ziyaret edilecek hastalarla ilgili özet bilgileri alır. Bu
hastaların kayıtlarının bilgisayarına indirilmesini talep eder.
Bilgisayarında kayıtları şifrelemek için anahtar kelimesi sorulur.
- Ziyaret ettiği hastalardan biri, depresyon için ilaç tedavisi gören
Jim'dir. Jim, ilacın ona yardımcı olduğunu düşünüyor, ancak onu geceleri
uyanık tutma yan etkisi olduğuna inanıyor. George, Jim'in kaydını kontrol
eder ve ilacın yan etkilerini sorgular. Uykusuzluk, bilinen bir yan
etkidir, bu nedenle George, Jim'e ilacını değiştirmesi için kliniğe
gitmesini önerir. Jim kabul eder, bu nedenle George, bir randevu almak
için kliniğe geri döndüğünde onu aramak için bir bilgi girer. George,
danışmayı sonlandırır ve sistem Jim'in kaydını tekrar şifreler.
- Danışmalarını tamamladıktan sonra George, ziyaret edilen hastaların
kayıtlarını veritabanına yükler. Sistem, George için iletişim bilgilerini
toplaması ve klinik randevuları yapması gereken hastalardan bir çağrı
listesi oluşturur.

**Senaryo İle Test Edilen Özellikler:**

- Sisteme girişle kimlik doğrulama.
- Belirli hasta kayıtlarının bir dizüstü bilgisayara indirilmesi ve
yüklenmesi.
- Ev ziyareti planlaması.
- Mobil cihazda hasta kayıtlarının şifrelenmesi ve şifresinin çözülmesi.
- Kayıt alımı ve değiştirme.
- Yan etki bilgilerini içeren ilaç veritabanındaki bağlantılar.
- Arama hatırlatma sistemi.

**Non-Fonksiyonel Test (Non-Functional Testing):**

- Non-fonksiyonel test, bir uygulamanın non-fonksiyonel gereksinimlerini
doğrulamak için gerçekleştirilen bir yazılım test türüdür.
- Sistemin davranışının gereksinimlere uygun olup olmadığını kontrol
eder.
- Fonksiyonel testte test edilmeyen tüm yönleri test eder.
- Non-fonksiyonel test, bir yazılım uygulamasının non-fonksiyonel
özelliklerini kontrol etmek için bir yazılım testi tekniğidir.
- Non-fonksiyonel test, yazılım uygulamasının non-fonksiyonel
parametreleri açısından sistem hazırlıklarını kontrol etmek için
tanımlanır.

**Non-Fonksiyonel Test Türleri:**

- Uyumluluk testi
- Uygunluk testi
- Dayanıklılık testi
- Yük testi
- Performans testi
- Kurtarma testi
- Güvenlik testi
- Ölçeklenebilirlik testi
- Stres testi
- Kullanılabilirlik testi
- Hacim testi
- Yedekleme testi
- Taşınabilirlik testi
- Güvenilirlik testi
- Temel çizgi testi
- Belgelendirme testi
- Yerelleştirme testi
- Uluslararasılaştırma testi

**Performans Testi:**
- Yayın testinin bir parçası, sistemle ilgili özelliklerin performans ve
güvenilirlik testini içerebilir.
- Testler, sistemin kullanım profiline yansıtılmalıdır.
- Performans testleri genellikle yük sistem performansı kabul edilemez
hale gelene kadar artırıldığı bir dizi test planını içerir.
- Stres testi, sistemin kasıtlı olarak aşırı yüklendiği ve sistem
performansının nasıl tepki verdiğini test ettiği bir performans testi
türüdür.

**Stres Testi:**
- Stres testinde, sisteme olumsuz koşullar verilir ve bu koşullarda nasıl
performans gösterdiği kontrol edilir.
- Örnek:
- Maksimum bellek veya diğer kaynakları gerektiren test durumları
yürütülür.
- Sanal bir işletim sisteminde yavaşlatan test durumları yürütülür.
- Aşırı disk gereksinimine neden olabilecek test durumları.
- Performans Testi, yazılımın çalışma zamanı performansını test etmek
için tasarlanmıştır. Programın hızını ve etkinliğini test etmek için
kullanılır. Ayrıca yük testi olarak da adlandırılır.

**Functional Testing vs. Non-Functional Testing:**

| Parametreler | Fonksiyonel Test | Non-Fonksiyonel Test |
| ------------ | ----------------- | -------------------- |
| Tanım | Fonksiyonel test, bir uygulamanın işlemlerini ve eylemlerini
doğrular. | Non-fonksiyonel, bir uygulamanın davranışını doğrular. |
| Temel | Müşteri gereksinimlerine dayanır. | Müşteri beklentilerine
dayanır. |
| Amaç | Yazılım eylemlerini doğrulamak için tasarlanmıştır. | Yazılım
sistem performansını doğrulamak için tasarlanmıştır. |
| Gereksinimler | Fonksiyonel test, fonksiyonel spesifikasyon
kullanılarak gerçekleştirilir. | Non-fonksiyonel test, performans
spesifikasyonları kullanılarak gerçekleştirilir. |
| Fonksiyonalite | Ürünün ne yaptığını açıklar. | Ürünün nasıl
çalıştığını açıklar. |
| Örnekler | - Birim testi - Entegrasyon testi - Akıl sağlığı testi -
Duman testi - Regresyon testi | - Performans testi - Yük testi - Stres
testi - Hacim testi - Kullanılabilirlik testi |

### Test-Driven Development (TDD)

**TDD Süreç Aktiviteleri:**

1. **İnkrementi Belirleme:** İlk olarak, küçük ve uygulanabilir bir
inkrementi belirleme.
2. **Test Yazma:** Belirlenen işlevsellik için otomatik bir test yazma.
3. **Testi Çalıştırma:** Testi var olan testlerle birlikte çalıştırma.
Yeni test başlangıçta başarısız olmalıdır.
4. **İşlevselliği Uygulama:** Belirlenen işlevselliği uygulamak için kodu
yazma.
5. **Testleri Tekrar Çalıştırma:** Tüm testleri tekrar çalıştırma. Yeni
test, var olan testlerle birlikte başarılı olmalıdır.
6. **Sonraki İnkremente Geçme:** Bir sonraki inkremente geçmeden önce tüm
süreci tekrarlamak.

**TDD'nin Avantajları:**
- **Kod Kapsamı:** Yazdığınız her kod parçasının en az bir testi
olduğundan, yazılan kodun en az bir testi bulunur.
- **Regresyon Testi:** Bir program geliştirildikçe regresyon test kümesi
aşamalı olarak oluşturulur.
- **Hata Ayıklamayı Basitleştirme:** Bir test başarısız olduğunda sorunun
nerede olduğu açık olmalıdır. Yeni yazılan kod kontrol edilmeli ve
değiştirilmelidir.
- **Sistem Belgesi:** Testler kendileri, kodun ne yapması gerektiğini
açıklayan bir belge biçimidir.

### Kodlama ve Hata Ayıklama

**Kodlama ve Hata Ayıklama:**

- **Kodlama:** Makineye hangi eylemleri gerçekleştirmesi ve görevleri
nasıl tamamlaması gerektiğini söyleyen bir süreçtir. Kodlama, bir yazılım
programı ile bilgisayar donanımı arasında başarılı bir iletişim kurma
sürecidir.
- **Hata Ayıklama:** Bir yazılım sistemindeki hataları, hataları veya
hataları belirleme ve çözme sürecidir. Hata ayıklama, bir yazılım
sisteminin doğru çalışmasını sağlamak için esastır.

**Hata Ayıklama Süreci:**

1. **Sorun Tanımlama ve Rapor Hazırlama:** Sorunu tanımlama ve bir rapor
hazırlama.
2. **Raporu Değerlendirme:** Raporu, gerçek bir hata olup olmadığını
doğrulamak için yazılım mühendisine atama.
3. **Hata Analizi:** Modelleme, belgeleme, aday hataları bulma ve test
etme gibi yöntemleri kullanarak hata analizi.
4. **Hata Çözme:** Gerekli düzeltmeleri yaparak sorunu çözme.
5. **Düzeltmeleri Onaylama:** Düzeltmelerin doğrulanması.

**Hata Ayıklamanın Avantajları ve Dezavantajları:**

**Avantajları:**
- **Geliştirilmiş Sistem Kalitesi**
- **Azaltılmış Sistem Durdurma Süresi**
- **Artan Kullanıcı Memnuniyeti**
- **Azaltılmış Geliştirme Maliyetleri**
- **Artan Güvenlik**
- **Değişiklikleri Kolaylaştırma**
- **Sistem Hakkında Daha İyi Anlama**
- **Testleri Kolaylaştırma**

**Dezavantajları:**
- **Zaman Alıcı**
- **Uzmanlık Gerektirir**
- **Yinelemesi Zor Olabilir**
- **Tanımlaması Zor Olabilir**
- **Düzeltmesi Zor Olabilir**
- **Sınırlı İçgörü**
- **Pahalı Olabilir**

**Hata Ayıklama ve Test Arasındaki Farklar:**

- Hata ayıklama, test etmekten farklıdır.
- Test, hata veya hataları bulmaya odaklanırken, hata ayıklama bir
hatanın yazılımda tanımlandığı yerden sonra başlar.
- Test, programın doğru olup olmadığını ve belirli bir minimum başarı
oranına sahip olup olmadığını sağlamak için kullanılır. Test manuel veya
otomatik olabilir.
- Birçok farklı türde test vardır: birim test, entegrasyon testi, alfa ve
beta testi gibi.
- Hata ayıklama çok bilgi, beceri ve uzmanlık gerektirir.
- Belirli hataların belirlenmesi için birçok farklı teknik olduğu için
genellikle manuel bir süreçtir.

### Test Etme ve Geliştirme ile İlgili Ana Noktalar

1. **Test Etmenin Sınırlamaları:**

- Test etme, bir programdaki hataların varlığını gösterebilir ancak
geriye kalan hataların olmadığını garanti edemez.
- Yazılımın davranışı hakkında değerli bilgiler sağlar, ancak bunun
tamamen doğruluğunu kanıtlayamaz.

2. **Geliştirme Testi Sorumlulukları:**

- Geliştirme testi, yazılım geliştirme ekibinin sorumluluğundadır.
- Bir sistem müşterilere sunulmadan önce, geliştirme ekibinden ayrı bir
ekip test işlemlerinden sorumlu olmalıdır.

3. **Geliştirme Test Türleri:**

- Geliştirme testi, birim test, bileşen testi ve sistem testi gibi
çeşitli seviyeleri içerir.
- Birim test, bireysel nesneleri ve yöntemleri test etmeyi içerir.
- Bileşen testi, ilgili nesnelerin gruplarını test etmeye odaklanır.
- Sistem testi, kısmi veya tam sistemleri kontrol eder.

4. **Yazılımı Zorlama:**
- Yazılım testinde, yazılımı 'zorlamaya' çalışmak, deneyim ve yönergeleri
kullanarak etkili test durumlarını seçmeyi amaçlar.
- Yazılımı zorlamak, zayıflıkları belirlemeye ve hataları keşfetmeye
yardımcı olur.

5. **Otomatik Test Etme:**

- Mümkünse otomatik testler yazmak tercih edilir. Bu testler, bir
programın her değişiklik sonrasında otomatik olarak çalıştırılabilir.
- Otomatik testler zaman kazandırır ve yazılımın doğruluğu hakkında hızlı
geri bildirim sağlar.

6. **İlk Test Yaklaşımı:**

- İlk test yaklaşımı, testlerin test edilecek koddan önce yazıldığı bir
yöntemdir.
- Bu yaklaşım, kodun belirli test durumlarını ve gereksinimleri
karşılamak üzere geliştirilmesini sağlar.

7. **Senaryo Test Etme:**

- Senaryo test etme, tipik kullanım senaryolarını oluşturarak test
durumları türetmeyi içerir.
- Bu, yazılımın gerçek dünya durumları ve kullanıcı etkileşimleri altında
nasıl performans gösterdiğini ortaya çıkarmaya yardımcı olur.
8. **Kabul Test Etme:**
- Kabul test etme, kullanıcı odaklı bir test sürecidir ve yazılımın
dağıtıma ve operasyonel ortamda kullanıma hazır olup olmadığını belirler.
- Yazılımın belirtilen gereksinimlere uygun olup olmadığını ve
kullanıcılar için uygun olup olmadığını değerlendirir.