live_tv
Livestream Starting Soon
00
Hours
:
00
Minutes
:
00
Seconds
Up next in 10
Auzef Yazılım Kalite ve Testi 2025-2026 Vize Soruları
https://lolonolo.com/2025/12/25/yazilim-kalite-ve-testi-2025-2026-vize-sorulari/
Bu kaynaklar, 2025-2026 akademik yılı için hazırlanan Yazılım Kalite ve Testi dersinin vize sınavı konularını ve örnek sorularını içermektedir. Metinlerde, Test Güdümlü Geliştirme (TDD), Duman Testi ve Regresyon Testi gibi temel metodolojiler ile yazılım dünyasındaki şüphecilik yaklaşımı detaylandırılmaktadır. Ayrıca, testlerin verimliliğini engelleyen Tarım İlacı Paradoksu ve girdi sınırsızlığı nedeniyle ortaya çıkan kapsamlı test imkansızlığı gibi kritik prensipler üzerinde durulmaktadır. Belge genelinde, yazılım hatalarının tarihsel kökeninden risk önceliklendirme tekniklerine kadar geniş bir teknik bilgi yelpazesi sunulmaktadır. Örnek soru ve cevaplar aracılığıyla, kuramsal bilgilerin pratik sınav senaryolarına nasıl dönüştüğü gösterilmektedir. Sonuç olarak kaynaklar, yazılımın güvenilirliğini ve performansını ölçen süreçlerin bütüncül bir özetini sunar.
https://lolonolo.com
Show More Show Less View Video Transcript
0:00
Şöyle bir düşünün. Her gün kullandığımız
0:02
o uygulamalar, web siteleri yani dijital
0:04
hayatımızı döndüren ne varsa bütün
0:07
bunların arkasında tıkır tıkır
0:08
çalışmalarını sağlayan genelde pek de
0:10
göremediğimiz koskoca bir dünya var.
0:13
İşte şimdi o dünyanın yani yazılım
0:16
testinin gizli dehlizlerine dalıyoruz.
0:18
Madem bu dünyaya girdik o zaman size
0:20
şöyle ilginç bir soruyla başlayayım.
0:22
Hani yazılımlarda bir hata olunca bug
0:24
var deriz ya. Böcek yani. Peki bu terim
0:26
nereden geliyor? Hiç merak ettiniz mi?
0:28
Çünkü işin aslı bildiğiniz gibi değil.
0:30
Evet. Evet, yanlış duymadınız. Tarihteki
0:33
ilk bilgisayar bugı bir kod hatası falan
0:36
değildi. Kelimenin tam anlamıyla bir
0:39
böcekti. 1947 yılında o zamanların oda
0:43
büyüklüğündeki bilgisayarlarından
0:44
birinin içine girip sıkışan ve sisteme
0:47
arıza verdiren gerçek bir güveydi. Ve bu
0:50
olayı kayıt defterine yapıştıran,
0:51
üzerine de bulunan ilk gerçek bug vakası
0:54
notunu düşen kişi de bilgisayar
0:56
biliminin öncülerinden Amiral Grace
0:58
Hopper'dan başkası değildi. İşte o gün
1:00
bugündür yazılımlardaki o beklenmedik,
1:02
sinir bozucu hatalara bu ismi veriyoruz.
1:05
Peki bu güzel tarihi hikayeden yola
1:08
çıkıp günümüze gelelim. bir test
1:10
uzmanını bir yazılımcıdan ayıran o temel
1:13
felsefene gelin onların o gizli
1:15
zihniyetine bir bakalım. İşte bütün
1:17
mesele bu iki soru arasındaki farkta
1:19
yatıyor aslında. Bakın bir yazılım
1:21
geliştiricisi bir şeyi yaratırken ne
1:23
düşünür? Bu kod nasıl çalışır? Değil mi?
1:26
Amacı bu. Ama bir test uzmanı o masaya
1:29
oturduğunda bambaşka bir soru sorar.
1:31
Peki ben bu kodu nasıl bozarım? Şimdi bu
1:35
nasıl bozarım sorusu kulağa biraz yıkıcı
1:37
hatta negatif gelebilir ama aslında tam
1:40
tersi. Bu son derece yaratıcı bir
1:42
yaklaşım. Çünkü test uzmanının işi o
1:45
sistemin zayıf noktalarını, çatlaklarını
1:47
yani potansiyel hataları bizler yani son
1:50
kullanıcılar onlarla karşılaşmadan çok
1:53
önce bulup çıkarmaktır. Yani bu
1:54
şüphecilik onların en keskin, en değerli
1:57
aracı. Peki bu özel zihniyeti anladık.
2:01
Şimdi sıra geldi test uzmanının alet
2:03
çantasına. Bu şüpheci bakış açısını
2:05
pratiğe dökerken hangi araçları, hangi
2:07
yöntemleri kullanıyorlar? Gelin birlikte
2:10
bakalım. Karşımıza ilk çıkan duman
2:12
testi. Bu en temel, en hızlı kontrol.
2:16
Adı üstünde bir nevi duman tütüyor mu
2:19
testi. Hani bir arabayı tamir edersiniz
2:21
de ilk olarak konto çevirip motor
2:24
çalışıyor mu diye bakarsınız ya. İşte
2:26
tam olarak o. Yazılım açılıyor mu? Giriş
2:29
yapılabiliyor mu? Bu en temel
2:30
fonksiyonlar çalışmıyorsa daha derin
2:33
testlere girmenin zaten bir anlamı
2:34
kalmaz. Motor çalışıyor diyelim. Harika.
2:37
Peki ya diğer parçalar? Motor tek başına
2:39
mükemmel. Tekerlekler, direksiyon hepsi
2:42
kendi içinde kusursuz. Ama bunları bir
2:44
araya getirdiğinizde işte o zaman
2:46
entegrasyon testi devreye giriyor.
2:48
Farklı parçaların yani yazılım
2:50
modüllerinin birbiriyle uyum içinde
2:52
sorunsuz çalışıp çalışmadığına bakıyor.
2:54
Çünkü bilirsiniz bazen tek harika olan
2:57
parçalar bir araya gelince hiç
2:58
beklenmedik sorunlar çıkarabilir. Şimdi
3:01
de çok sık yaşanan bir durumu düşünelim.
3:03
Diyelim ki ekibiniz yazılıma süper bir
3:05
yeni özellik ekledi ya da can sıkan
3:07
küçük bir hatayı düzeltti. Her şey
3:09
yolunda görünüyor ama bir saniye.
3:11
Yaptığımız bu küçük değişikliğin
3:13
sistemin daha önce tıkır tıkır çalışan
3:15
başka bir yerini bozmadığından nasıl
3:17
emin olabilirsiniz? İşte bu sorunun
3:19
cevabı regresyon testi. Bu da şuna
3:21
benzer. Arabanın radyosunu tamir ettiniz
3:23
diye sevinirken bir bakmışsınız farlar
3:25
yanmıyor. İşte regresyon testi tam
3:27
olarak bunu engellemek için var. Yani
3:29
yaptığınız yeni bir değişikliğin eski ve
3:32
normalde düzgün çalışan özellikleri
3:33
bozup bozmadığını kontrol eder. Hayati
3:35
bir güvencedir. Şimdi gelin işleri biraz
3:38
daha ilginçleştirelim. Çünkü test
3:40
dünyasının kendine has hatta ilk bakışta
3:42
biraz tuhaf, mantığa aykırı gibi gelen
3:45
bazı kuralları var. Mesela şu soruya bir
3:48
bakın. Neden sürekli tekrar ettiğiniz
3:50
testler bir süre sonra işe yaramaz hale
3:52
gelir? Kulağı çok garip geliyor, değil
3:53
mi? Sonuçta bir test sürekli çalışıyor
3:56
ve hiç hata bulmuyorsa bu harika bir şey
3:58
olmalı. Ama aslında bu tehlike
4:00
çanlarının çaldığı anlamına gelebilir.
4:02
İşte bu duruma tarım ilacı paradoksu
4:05
diyoruz. Analoji harika. Tarladaki
4:07
zararlı böceklere sürekli aynı ilacı
4:09
sıkarsanız ne olur? Bir süre sonra o
4:11
böcekler ilaca karşı bağışıklık
4:13
geliştirir ve ilaç işe yaramaz olur.
4:15
Yazılım da böyledir. Sürekli aynı
4:17
testleri koşturursanız yazılım adeta bu
4:20
testlere karşı bağışıklık kazanır ve o
4:22
testler artık yeni hataları bulamaz hale
4:25
gelir. Yani döngü çok basit. Aynı
4:27
testleri çalıştırdur. Yazılım bu
4:29
testlerin kör noktalarına karşı
4:30
bağışıklık kazansın ve sonuç artık yeni
4:33
hataları bulamıyorsun. İşte tam da bu
4:35
yüzden test senaryolarını sürekli taze
4:37
tutmak, gözden geçirmek ve güncellemek
4:40
bu işin en kritik kurallarından biridir.
4:42
Peki madem bu kadar test var, bu kadar
4:45
yöntem, bu kadar paradoks var, o zaman
4:47
hepimizin aklındaki o büyük soruya
4:49
gelelim. Neden ama neden kullandığımız
4:51
programlarda, uygulamalarda hala
4:54
hatalarla karşılaşıyoruz? Bu sorunun
4:56
cevabını anlamak için sizinle küçük bir
4:59
düşünce deneyi yapalım. Hayal edin. Bir
5:01
web sayfasında sadece ve sadece öğrenci
5:04
numaranızı gireceğiniz küçücük bir
5:06
kutucuk var. Tek bir kutu. Bunu kaç
5:09
farklı şekilde test edebiliriz ki? Hadi
5:11
düşünelim. İçine doğru numarayı
5:13
yazabilirsiniz. Yanlış sayıda rakam
5:15
yazabilirsiniz. Rakam yerine harf
5:17
yazmayı deneyebilirsiniz. Ya da ünlen,
5:19
soru işareti gibi özel karakterler.
5:21
Belki de alanı boş bırakırsınız veya
5:23
kopyala yapıştırla upuuzun bir metin
5:25
yapıştırırsınız. Milyonlarca karakterlik
5:27
bir veri mesela. Gördünüz mü? Basit bir
5:29
kutucuk için bile olasılıklar bir anda
5:31
çağı gibi büyüverdi. Ve işte bu basit
5:33
örnek bile bizi yazılım testinin en
5:36
temel, en acımasız gerçeğiyle
5:37
yüzleştiriyor. Kapsamlı test yani her
5:40
şeyi test etmek imkansızdır.
5:43
Okutucuğa girilebilecek her veriyi,
5:45
yapılabilecek her tıklamayı, her olası
5:48
senaryoyu, tüm kombinasyonları denemek
5:51
ne matematiksel olarak ne de zaman
5:53
olarak mümkün değil. Çünkü test
5:55
edilebilecek kombinasyonların sayısı
5:57
işte bu sonsuz. Peki madem her şeyi test
6:01
edemiyoruz o zaman ne yapıyoruz? İşte en
6:04
kritik nokta da bu. Yazılım testi
6:07
mükemmeli aramak yani her bir hatayı
6:09
bulmak demek değildir. Yazılım testi bir
6:12
risk yönetimidir. Amaç en kritik, en
6:15
olası, en çok can yakacak hataları
6:18
bularak riski kabul edilebilir bir
6:20
seviyeye indirmektir. Sıfırlamak değil,
6:23
yönetmektir. Ve bu bizi son bir soruyla
6:26
başa bırakıyor. Madem her şeyi test
6:28
etmek imkansız ve kullandığımız her
6:30
yazılımın içinde potansiyel
6:33
keşfedilmemiş hatalar saklı, o zaman
6:35
bankacılık uygulamalarından sosyal
6:37
medyaya, hayatımıza emanet ettiğimiz bu
6:39
dijital dünyaya ne kadar güvenebiliriz?
6:42
İşte bu da üzerinde düşünmeye değer bir
6:44
soru.
#Software
#Education