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
