Up next in 10
Auzef Yazılım Kalite ve Testi 2025-2026 Final Soruları
https://lolonolo.com/2026/09/15/yazilim-kalite-ve-testi-2025-2026-final-sorulari/
auzef, Bilgisayar Programcılığı, Yazılım Kalite ve Testi, Yönetim Bilişim Sistemleri
Show More Show Less View Video Transcript
0:00
Dolo Nolo platformuna hoş geldiniz. Bu
0:02
dersimizde yazılım kalite ve testi
0:04
2025-2026
0:06
final soruları konularını, çıkmış
0:08
sorularını ve detaylı açıklamalarını
0:10
derinlemesine inceliyoruz. Yani şu göz
0:13
korkutan, karmaşık gibi duran konular
0:15
var ya hepsini bugün adım adım çok net
0:17
bir şekilde zihninize oturtacağız.
0:19
Hazırsanız hadi hemen başlayalım.
0:22
İncelememizin kısa bir yol haritasına
0:24
bakalım. Yazılım testinin temelleriyle
0:26
başlayacağız. Sonra kutu ve çevik
0:28
yaklaşımlara bakacağız. test
0:29
otomasyonunun o pek bilinmeyen
0:31
gerçeklerine gireceğiz. Ardından sektör
0:34
standartları ve roller, kalite
0:36
metrikleri ve son olarak gözden geçirme
0:38
ve hata önleme diyerek toparlayacağız.
0:41
Bölüm 1. Yazılım testinin temelleri.
0:44
Şimdi yazılım testi denince akla hep kod
0:46
bitti. Hadi bir de şuna bakalım gibi
0:48
sonradan akla gelen bir yama işlemi
0:50
gelir. Değil mi? Aslında durum hiç de
0:51
öyle değil. Ürünler canlıya alınmadan
0:54
yani son kullanıcıyla buluşmadan önce
0:56
hataları yani sektördeki meşhur adıyla
0:58
bugları tespit edip genel kaliteyi
1:00
arttırdığımız o en kritik, en hayati
1:02
süreçtir bu. Bakın buradaki en kilit
1:05
nokta canlıya alınmadan önce kısmı.
1:07
Neden mi? Çünkü bir hata canlı sistemde
1:09
kullanıcı tarafından bulunduğunda inanın
1:11
bana bunun maliyeti ve itibar kaybı
1:13
geliştirme aşamasında bulunmasına
1:14
kıyasla binlerce kat daha fazla
1:16
olabiliyor. Kısacası bu süreç bizim
1:19
nihai koruma kalkanımız. Asıl ilginç
1:21
olan ne biliyor musunuz? Test dediğimiz
1:23
şey öyle tek bir hamlede olup bitmez.
1:25
Belirli yapısal seviyeleri vardır. İlk
1:27
adım birim yani unit testleri. Burada
1:30
kodun en küçük parçasını alıyoruz. Tek
1:32
başına doğru çalışıyor mu diye
1:33
bakıyoruz. İkinci adım olan entegrasyon
1:36
testleri işte burası sınavlar için
1:38
ekstra önemli. Neden derseniz bu aşama
1:41
farklı modüller bir araya geldiğinde
1:42
ortaya çıkan o sinir bozucu
1:44
uyumsuzlukları arar. Yani parçalar tek
1:46
başlarına tıkır tıkır çalışsa bile
1:48
birbirleriyle konuşurken sorun çıkarıyor
1:50
mu? Buna bakıyoruz. Ve son olarak sistem
1:52
testi. Burada artık parçaları bırakıp
1:55
bütünleşmiş sistemin baştan sona nasıl
1:57
çalıştığını test ediyoruz. Bu üçlü
1:59
hiyerarşi aslında hiçbir açığın gözden
2:01
kaçmamasını sağlayan dev bir güvenlik
2:03
ağı. Tabii işin sadece yapısal değil
2:06
kronolojik bir boyutu da var. Alfa ve
2:08
beta fazları. Eminim duymuşsunuzdur.
2:11
Alfa daha çok geliştirici ekibin veya
2:13
şirket içindeki kullanıcıların o
2:15
güvenli, kontrollü ortamda yaptığı
2:17
testlerdir. Beta ise işin biraz daha
2:20
heyecanlı kısmı. Ürünün artık dış
2:22
dünyaya, gerçek kullanıcılara açılıp
2:24
tabiri caizse vahşi doğada nasıl hayatta
2:26
kaldığının gözlemlenmesi aşamasıdır.
2:29
Bölüm 2. Kutu yaklaşımları ve çevik.
2:32
Sınavlarda banko karşınıza çıkacak iki
2:34
klasik kavram var. Beyaz kutu yani white
2:38
box ve kara kutu BlackBX. Beyaz kutu
2:41
testleri kodun en ince ayrıntılarına
2:43
kadar inen o derinlemesine testlerdir.
2:46
Bunu yapabilmek için sistemin iç
2:48
yapısını, algoritmasını ve kodunu
2:50
gerçekten çok iyi bilmeniz gerekir.
2:52
Tıpkı bir arabanın kaputunu açıp motorun
2:54
her detayını inceleyen usta bir tamirci
2:56
gibi düşünün bunu. Kara kutu testlerinde
2:59
ise kod yapısı falan kesinlikle
3:00
bilinmez. Sistem adından da anlaşılacağı
3:03
gibi kapalı ve karanlık bir kutu. Sadece
3:06
ne verdim, ne aldım? Yani girdilere ve
3:08
çıktılara bakılır. Radyonun düğmesine
3:10
basarsınız, ses geliyor mu diye
3:12
dinlersiniz. Değil mi? İçerideki
3:14
kabloların nasıl bağlandığı hiç
3:16
umurunuzda olmaz. İşte bu ayrım test
3:18
stratejilerinin temel felsefesini
3:20
oluşturur. Peki modern yazılım dünyası
3:23
şu an nerede? Bunu özetleyen kavram TDD
3:26
yani test güdümlü geliştirme. Bu
3:28
yaklaşım bildiğimiz tüm geleneksel
3:30
yöntemleri alıp adeta tepe taklak
3:32
ediyor. Çevik yani agile ortamlarda
3:35
normalde ne beklenir? Önce kod yazılır
3:38
sonra test edilir. Ama TDD'de
3:40
geliştirici henüz tek bir satır kod bile
3:43
yazmadan önce oturup test senaryosunu
3:45
yazar. E tabii ortada kod olmadığı için
3:47
o test doğal olarak patlar, başarısız
3:49
olur. Ardından geliştirici sadece ama
3:52
sadece o testi geçecek kadar kod yazar.
3:54
Yani test kodun yazım sürecini bizzat
3:57
güdümler, onu yönetir. Hatasız kod
3:59
yazmak için bulunmuş gerçekten en
4:01
zekice, en disiplinli modern
4:03
yaklaşımlardan biri. Bölüm 3. Test
4:06
otomasyonunun gerçekleri. Şimdi size çok
4:09
provokatif bir soru soracağım. Bir
4:10
düşünün. Test otomasyonu bir kere
4:12
kurduğunuzda bu sistem değişmeyi ve
4:14
güncellenmeyi hiç bırakır mı? Çoğu
4:16
kişinin düştüğü çok büyük bir yanılgı
4:18
var burada. Sanki otomasyonu bir kez
4:20
yazıyorsun sonra o kendi kendine sonsuza
4:22
dek tıkır tıkır çalışıyor sanılıyor.
4:24
Peki gerçek dünyada veya akademik olarak
4:27
durum gerçekten de böyle mi? Elbette
4:29
hayır. Böyle bir şey yok. Süreçleri
4:31
hızlandırmak için kurduğumuz bu test
4:33
otomasyon sistemleri aslında kelimenin
4:35
tam anlamıyla yaşayan organizmalardır.
4:38
Yazılım dünyası değiştikçe, ürünlere
4:40
yeni özellikler eklendikçe ya da o
4:42
arayüzler ufaktan güncellendikçe
4:44
otomasyon kodunun kendisinin de
4:45
değişmesi şarttır. Öyle benim hiç
4:47
güncellenmeyen kaya gibi sağlam kararlı
4:49
bir otomasyon sürümüm var diyemezsiniz.
4:52
Sürekli bir bakım, sürekli bir
4:53
adaptasyon ister. Aksi takdirde ne olur?
4:56
Ya sürekli yanlış alarmlar verir ya da
4:57
daha kötüsü kritik hataları gözden
4:59
kaçırmaya başlar. Bölüm 4. Sektör
5:02
standartları ve roller. Yazılım test
5:05
dünyasında kuralları koyan en büyük
5:07
kurumlardan biri ISQB'dir. Türkiye'de de
5:10
bunun uzantısı olan TTB yani Turkish
5:13
testing board var. Bu kurumlar sınavlar
5:15
yapar, sertifikalar verir, sektörü bir
5:18
nevi şekillendirir. Ama durun burada
5:20
sınavlarda çok sık yapılan bir
5:22
şaşırtmaca, bir hile var. Lütfen buraya
5:25
dikkat. Bu kurumlar standart belirler,
5:28
eğitim verir ama kesinlikle ticari
5:30
yazılım üretmezler. Onlar kural koyucu,
5:33
düzenleyici hakemlerdir. Sahada top
5:35
koşturan yazılım satıcıları değil. Bu
5:38
ince ayrımı mutlaka aklınızın bir
5:40
köşesine yazın. Bir de organizasyon
5:42
şemasına, işin mutfağına inelim.
5:44
Rollerin çok kesin çizgilerle
5:45
ayrıldığını göreceksiniz. Mesela test
5:47
yöneticisi. Bu kişi genel stratejiyi
5:49
belirleyen, bütçeyi yöneten, kaynakları
5:51
planlayan yani işin tamamen yönetimsel
5:54
tarafındaki kişidir. Test uzmanı ise
5:56
sahada ter döken kişidir. Test
5:58
verilerini hazırlar. Senaryoları bizzat
6:00
koşar. Sistemle doğrudan boğuşur. Biri
6:02
orkestra şefi ise diğeri o enstrümanı
6:04
çalan müzisyendir diyebiliriz. İkisinin
6:06
sorumluluklarını kesinlikle birbirine
6:08
karıştırmamamız gerekiyor. Bölüm 5.
6:10
Kalite metrikleri ve Sumi. Peki en temel
6:14
soru. Bir ürünün gerçekten kaliteli olup
6:16
olmadığını ne belirler? Bunun akademik
6:19
ve çok doğru bir cevabı var. Kullanım
6:21
bağlamı. Ders notlarımızda geçen harika
6:23
bir analoji var. Havlu ve banyo
6:25
eşleşmesi. Düşünün bir havlu suyu çok
6:28
iyi emer. Yumuşacıktır. Yani banyo
6:31
bağlamında kusursuz, muazzam, kaliteli
6:33
bir üründür. Değil mi? Ama aynı havluyu
6:35
alıp çölün ortasında çadır kurmak için
6:37
kullanırsanız ne olur? Tamamen işlevsiz
6:40
ve anında kalitesiz bir beze dönüşür.
6:42
İşte yazılımda da kalite tam olarak
6:44
böyledir. Ürünün gerçek dünyadaki o
6:47
kullanım bağlamına ne kadar cuk
6:48
oturduğuyla ölçülür. Bu kullanım
6:50
bağlamını ve kullanılabilirliği resmi
6:52
yollarla ölçmek için endüstride sumi
6:55
kullanılır. Yani kullanılabilirlik ölçüm
6:57
envanteri. Bu envanter yazılıma aslında
7:00
üç kritik soru sorar. Bir verimlilik.
7:03
Kullanıcı işini ne kadar hızlı ve
7:05
zahmetsiz hallediyor? 2. Etki.
7:08
Kullanıcının yazılımla etkileşimi onda
7:10
psikolojik olarak nasıl bir his
7:11
bırakıyor? Mutlu mu? Sinirli mi? Ve 3.
7:15
Hakimiyet. Kullanıcı sistemi ben kontrol
7:17
ediyorum diyebiliyor mu? Yoksa yazılım
7:19
mı onu sağa sola sürüklüyor? Bu üç
7:21
başlık kullanıcı deneyimini ölçmenin o
7:24
soyut hisleri analitik verilere dökmenin
7:26
en iyi yoludur. Tasarım aşamasına
7:28
geldiğimizde ise işler biraz daha
7:30
teknikleşiyor. Nesne yönelimli
7:32
yazılımların yani object oriented
7:34
sistemlerin kalitesini ölçerken özel
7:36
metrikler devreye girer. Hani o
7:38
geleneksel log yani kod satır sayısı
7:40
metriği var ya o artık oldukça eski ve
7:43
yetersiz bir yaklaşım. Çünkü bilirsiniz
7:45
binlerce satır çok kötü bir kod yazmak
7:47
da mümkün. Modern nesne yönelimli
7:50
sistemlerde biz CK metrikleri dediğimiz
7:52
şeyleri kullanıyoruz. Bunların en
7:54
önemlileri RFC yani sınıfın tetiklediği
7:57
metot sayısı ve kalıtım ağacı
8:00
derinliğidir. İsimleri uzun olabilir ama
8:02
mantığı basit. Bu metrikler sistemin
8:04
karmaşıklığını yazdığınız satır sayısına
8:06
bakarak değil o nesnelerin birbirleriyle
8:09
olan ilişkilerine ve hiyerarşilerine
8:10
bakarak okur. Bölüm 6. Gözden geçirme ve
8:14
hata önleme. Geldik son ve belki de en
8:17
hayati konuya. Yazılımda altın bir kural
8:19
vardır. Bir hatayı ne kadar erken
8:21
bulursanız çözümü de o kadar ucuz olur.
8:23
Resmi gözden geçirme yani formal review
8:25
toplantıları işte tam da bu yüzden var.
8:28
Düşünün daha ortada yazılmış tek bir
8:29
satır kod bile yok. Ürün kodlanmadan
8:32
henüz o kağıt üzerindeki tasarım ve
8:34
mimari aşamasındayken yapılır bu
8:35
toplantılar. İleride telafisi imkansız
8:37
veya çok çok pahalıya patlayacak o
8:39
devasa mimari hataları daha doğmadan bu
8:41
an güçlü güvenlik ağımızdır bu. Fakat
8:44
aklınıza öyle kahve eşliğinde yapılan
8:45
rastgele sohbetler gelmesin. Bu
8:47
toplantıların son derece katı askeri
8:50
düzeyde bir kurumsal yapısı vardır.
8:52
Rolleri nettir. Yazar belginin veya
8:54
tasarımın bizzat sahibidir. Yönetici
8:56
toplantının sınırlarını çizen, kuralları
8:58
koyan ve ilerleyişi denetleyen kişidir.
9:01
Bir de kaydedici vardır. O da tartışılan
9:03
her teknik detayı, masaya yatırılan
9:05
muhtemel açıkları resmi bir protokole
9:07
döker. Eğer bu rollerden biri bile
9:09
eksikse o toplantı resmi statüsünü
9:11
kaybeder. Allahade bir görüşmeye
9:13
dönüşür. Tabii bu toplantılardaki
9:15
teknikler de bir o kadar yapılandırılmış
9:17
durumda. Öyle ya bence şu da bozulabilir
9:19
gibi belirsiz tahminlere yer yoktur.
9:21
Mesela senaryolara dayalı teknikler
9:23
kullanırız. Kullanıcı şifresini unutursa
9:25
ve aynı anda sistem çökerse ne olur gibi
9:28
çok net ihtimaller konuşulur. Ya da
9:30
rollere dayalı tekniklerle bir sistem
9:32
yöneticisinin gözünden buradaki açık
9:34
nedir veya kötü niyetli bir hacker
9:36
buradan nasıl sızar diye farklı
9:38
pencerelerden tasarıma saldırılır. Her
9:41
bir farklı bakış açısı saklanan bambaşka
9:44
bir hatayı günyüzüne çıkarır. İşin özü
9:46
budur. Videoda incelediğimiz bu dersin
9:48
ve yıla ait çıkmış soruları kendiniz
9:50
deneme sınavı formatında çözmek,
9:52
eksiklerinizi kapatmak ve kendinizi
9:53
detaylıca test etmek için lolonolo.com
9:56
adresini ziyaret edebilir, videonun
9:58
altındaki açıklama kısmında yer alan
9:59
bağlantıya tıklayabilirsiniz.
Jobs & Education