Up next in 10
Auzef Yazılım Kalite ve Testi 2025 Üç Ders Soruları
https://lolonolo.com/2026/08/29/yazilim-kalite-ve-testi-2025-uc-ders-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
Lolo Molo platformuna hoş geldiniz. Bu
0:02
incelememizde yazılım kalite ve testi
0:05
2025 3 ders konularını ve öne çıkan
0:07
sorularını masaya yatırıyoruz.
0:08
Biliyorsunuz yazılım dünyasının belki de
0:11
en kritik, en can alıcı aşaması test ve
0:14
kalite güvence süreçleridir. Hazırsanız
0:16
bu heyecan verici dünyaya hep birlikte
0:18
hızlıca bir dalış yapalım. Bugünkü
0:20
haritamız aslında çok net. Üç ana
0:22
durağımız var. Önce temel ilkelere ve
0:24
yaklaşımlara bakacağız. Sonra test
0:26
seviyeleri ve türlerini konuşacağız. Son
0:28
olarak da kalite metrikleri ve riskleri
0:30
inceleyip toparlayacağız. Hiç vakit
0:32
kaybetmeden başlayalım. Birinci
0:34
bölümümüz temel ilkeler ve yaklaşımlar.
0:37
Şunu baştan söylemek lazım. Başarılı bir
0:40
yazılım testi yapmak sadece oturup kod
0:42
yazmak değildir. Bu kelimenin tam
0:44
anlamıyla yepyeni bir psikolojik
0:46
zihniyet gerektirir. Yani geliştirici
0:49
zihniyeti ile test uzmanı zihniyeti
0:51
arasındaki fark aslında inanılmazdır.
0:53
Düşünsenize bir yazılımcıysanız doğal
0:56
olarak kendi yazdığınız, emek verdiğiniz
0:58
koda güvenirsiniz. Çalışacağından
1:00
eminsinizdir ama bir test uzmanı işte
1:02
onun en hayati özelliği şüpheciliktir.
1:05
Sürekli acaba burası nasıl kırılır?
1:07
sistemin neresinde bir açık var diye
1:09
sormak zorundadırlar. Tıpkı ipucu arayan
1:11
bir dedektif gibi son derece analitik ve
1:13
eleştirel bir bakış açısı şart. Peki
1:16
diyelim ki süper şüpheciyiz. Oturup
1:19
sistemdeki her bir ihtimali, her bir
1:21
girdiyi tek tek test edebilir miyiz? Acı
1:24
gerçek şu: Kesinlikle hayır. Yazılımdaki
1:27
tüm olası durumları test etmek fiziksel
1:29
olarak imkansızdır. Sonsuz sayıda
1:32
kombinasyon var. İşte tam da bu yüzden
1:34
risk bazlı test yaklaşımları bizim için
1:37
bir zorunluluk. Yani enerjimizi ve
1:39
zamanımızı hatanın en çok zarar
1:41
verebileceği veya sistemin çökme
1:44
ihtimalinin en yüksek olduğu noktaları
1:46
harcamalıyız. Bu noktada çok sevdiğim
1:49
harika bir kavram karşımıza çıkıyor.
1:51
Tarım ilacı paradoksu. Hani bir tarlanız
1:53
vardır. Hep aynı böcek ilacını
1:55
sıkarsanız böcekler bir süre sonra
1:57
bağışıklık kazanır ve o ilaç artık
1:59
hiçbir işe yaramaz.
2:01
İnanın yazılım testinde de durum tamamen
2:03
aynı. Siz aynı test senaryolarını tekrar
2:06
tekrar çalıştırırsanız bir noktadan
2:08
sonra yeni hataları bulamazsınız. Çünkü
2:11
geride kalan o kurnaz hatalar sizin test
2:13
senaryolarınızın bakmadığı köşelere
2:15
saklanmıştır. Çözüm basit.
2:18
Senaryolarınızı sürekli
2:19
geliştirmelisiniz. Temel ilkelerdeki son
2:21
durağımız ise test tekrarlanabilirlik
2:23
kavramı. Peki bu neden yazılım testinin
2:26
temel taşıdır? Çok basit. Güvenilirlik
2:28
için. Diyelim ki çok kritik bir hata
2:30
buldunuz. Bunu geliştiriciye kanıtlamak
2:32
ve sorunun çözülmesini sağlamak
2:34
zorundasınız, değil mi? İşte bunun için
2:36
o hataya giden adımları tamamen aynı
2:39
koşullar altında birebir
2:40
tekrarlayabilmeniz ve aynı sonucu
2:43
almanız gerekir. Yoksa o hata bir
2:45
efsaneden ibaret kalır. Geldik ikinci
2:47
bölüme. Test seviyeleri ve türleri. İşin
2:50
felsefesini o şüpheci zihniyeti
2:53
kavradığımıza göre artık bu zihniyeti
2:55
sahda yazılım yaşam döngüsünde nasıl
2:58
kullanılacağımıza bakabiliriz. Yazılım
3:00
testini aslında adım adım yükselen bir
3:02
inşaat süreci gibi düşünebilirsiniz. Her
3:05
şey birim testleri ile başlar. Burada
3:08
yazılımı oluşturan o en küçük kod
3:10
parçalarının yani tuğlaların tek sağlam
3:13
olup olmadığını kontrol ederiz. Eğer
3:15
tuğlalar sağlamsa bir sonraki aşamaya
3:18
entegrasyon testine geçeriz. Yani bu
3:21
farklı modülleri bir öre getirdiğimizde
3:23
birbirleriyle düzgün konuşabiliyorlar
3:25
mı? Çünkü bazen ayrı ayrı mükemmel
3:27
çalışan iki modül birleştiğinde devasa
3:30
bir çökmeye neden olabilir. Entegrasyon
3:33
testi tam olarak bunu engellemek için
3:35
var. Peki sisteme yepyeni bir özellik
3:37
eklediğimizde ne oluyor? İşte regresyon
3:40
testi, namı değer gerileme testi tam da
3:43
burada hayat kurtaran bir güvenlik ağı
3:44
olarak devreye giriyor. Düşünün sisteme
3:47
yeni bir kod eklediniz. Harika
3:49
çalışıyor. Ama ya bu yeni kod sistemin
3:51
eskiden tıkır tıkır çalışan başka bir
3:53
yerini bozduysa hani derler ya kaş
3:55
yaparken göz çıkarmak. Regresyon testi
3:58
bakım testleriyle de kol kola girerek
4:01
yeni güncellemelerin eski özellikleri
4:03
mahvetmediğinden emin olmamızı sağlar.
4:05
Ve geldik yazılım dünyasının en popüler
4:07
terimlerinden birine. Duman testi yani
4:10
smoke test. Düşünün devasa ve zaman
4:13
alıcı testlere başlamadan önce yapılan
4:15
çok hızlı ön kontrollerdir bunlar.
4:18
Sistemin temel omurgası ayağa kalkıyor
4:20
mu? Fişi taktığımızda cihazdan mecazi
4:23
anlamda tabii duman çıkıyor mu? Eğer
4:26
yazılım daha giriş ekranında bile
4:27
çöküyorsa günlerce sürecek o
4:29
derinlemesine analizi yapmanın hiçbir
4:31
anlamı yoktur. Değil mi? Vakit kaybından
4:33
başka bir şey olmaz. Tabii bir sistemin
4:36
sadece temel işlemlerini yapması hiçbir
4:37
zaman yeterli değildir. Bunların nasıl
4:39
yaptığı da kaliteyi belirler. İşte
4:41
burada sonksiyonel olmayan testler
4:43
devreye giriyor. Özellikle üç tanesi çok
4:45
kritik. Birincisi kurtarma testi. Sistem
4:47
bir felaket anında çöktüğünde ne kadar
4:49
sürede toparlanıyor? Veriye kaybediyor
4:51
mu? İkincisi kullanılabilirlik. Arayüz
4:53
ve anlaşılır mı? Kullanıcı sistemi
4:54
kolayca öğrenebilir mi? Ve üçüncüsü
4:56
uyumluluk. Yani bu uygulama telefonda,
4:58
tablette veya farklı tarayıcılarda aynı
5:01
kusursuzlukla çalışıyor mu? Kalite
5:03
dediğimiz şey işte tüm bu özelliklerin
5:05
toplamıdır. Bence harika ilerliyoruz.
5:07
Şimdi gelelim 3üncü ve son ana
5:09
bölümümüze. Kalite metrikleri ve
5:11
riskler. Yönetim ve strateji tarafına
5:14
geçiyoruz. Testleri yaptık ama başarıyı
5:16
nasıl ölçeceğiz veya piyasaya çıkış
5:18
risklerimizi nasıl hesaplayacağız? Biraz
5:20
da bunlara bakalım. Ünlü bir söz vardır
5:22
bilirsiniz. Ölçemediğiniz şeyi
5:24
yönetemezsiniz. Bu yüzden metrikleri
5:27
ikiye ayırıyoruz. Önce doğrudan
5:29
metrikler var. Bunlar elimizle
5:30
sayabildiğimiz somut veriler. Kod satırı
5:33
sayısı veya testin kaç saat sürdüğü
5:35
gibi. Bir de dolaylı metrikler var ki
5:38
bunlar biraz daha soyuttur. Mesela bir
5:40
geliştiricinin performansı veya sistemin
5:43
genel güvenilirliği. Bunları tek bir
5:45
sayıyla ifade edemezsiniz. Doğrudan
5:47
metrikleri yorumlayarak dolaylı bir
5:49
çıkarım yaparsınız. Gelelim risklere.
5:52
Riskleri doğru ayırmak çok önemlidir.
5:54
Proje riskleri projenin kendisini tehdit
5:56
eden dış unsurlardır. Kurum içi
5:58
politikalar, bütçenin bitmesi, teknik
6:00
altyapı eksikliği veya tedarikçinin işi
6:02
geciktirmesi gibi ama ürün riskleri
6:05
bambaştadır. Bu tamamen ürünün
6:07
kendisiyle yani yazılımla ilgilidir.
6:09
Uygulamanın sahada müşterideyken çökmesi
6:11
veya kritik bir hesaplamayı yanlış
6:13
yapması. İşte bunlar doğrudan ürün
6:15
riskidir. Riskleri belirledik. Peki
6:18
hangi riske öncelik vereceğiz? İşte
6:21
burada RPN yani risk öncelik numarası
6:24
formülü imdadımıza yetişiyor. Özellikle
6:27
sınavlar için bu üçlü formülü aklınızda
6:29
tutmanız çok önemli. Formülümüz üç
6:32
çarpanı bir araya getiriyor. Hatan
6:34
sisteme etkisi yani şiddeti, müşteri
6:37
açısından önemi ve tabii ki gerçekleşme
6:39
olasılığı. Bu üç değeri birbiriyle
6:41
çarpıyorsunuz. Ortaya çıkan puana
6:43
bakıyorsunuz. Sonra ne mi yapıyorsunuz?
6:46
O kısıtlı vaktinizi puana en yüksek
6:48
çıkan yani en tehlikeli riski çözmeye
6:51
ayırıyorsunuz. Kalite güvence
6:53
sistemlerinin kalbinde yatan iki temel
6:55
eylemden bahsederek toparlayalım. Bir
6:57
yanda önleyici faaliyet var. Adı üstünde
7:00
tamamen proaktif bir yaklaşım.
7:02
Potansiyel bir hatayı daha hiç
7:03
gerçekleşmeden sadece öngörerek
7:06
engellemeye çalışıyoruz. Diğer yanda ise
7:08
düzeltici faaliyet bulunuyor. Eğer bir
7:10
hata artık meydana gelmişse sorunun
7:13
üstüne sadece yara bandı yapıştırıp
7:15
geçemezsiniz. sorunun kök nedenine
7:17
inmek, onu bulmak ve aynı hatanın bir
7:20
daha asla tekrarlanmamasını garanti
7:21
altına almak zorundasınız. Şimdi tüm bu
7:24
konuştuklarımızı, metrikleri ve
7:26
stratejileri bir araya getirdiğimizde
7:28
akla gerçekten çok kışkırtıcı bir soru
7:30
geliyor. Madem en başta her şeyi %100
7:33
test etmenin imkansız olduğunu kabul
7:34
ettik, peki o test ağlarımıza takılmayan
7:37
ve ancak sahada tam da müşterinin
7:40
karşısında ortaya çıkacak o öngörülemez
7:42
hatalar için nasıl bir hazırlık
7:44
yapmalıyız? İşte mükemmel bir kalite
7:46
mühendisliği tam olarak bu belirsizliği
7:48
yönetmekte yatıyor. Bu incelemede ele
7:50
aldığımız dersin ve yıla ait çıkmış
7:53
soruları kendiniz deneme sınavı
7:54
formatında çözmek için lolonolo.com
7:57
adresini ziyaret edebilir, açıklama
7:58
kısmındaki bağlantıya tıklayabilirsiniz.
Jobs & Education