Bir cümlelik özet
Test senaryosu, bir projeyi rastgele denemek yerine "şu girdiyi verince şu çıktıyı beklerim" diye önceden yazıp adım adım kontrol etmenin planlı yoludur.
Neden önemli?
Prototipin çalıştı; peki gerçekten çalışıyor mu? Bir kez denedin, oldu diye sevindin. Fakat ertesi gün aynı projeyi başkası açtığında farklı davranırsa ne yapacaksın?
Testi "kafadan" yaparsak her seferinde farklı şeyleri deneriz ve neyi kontrol ettiğimizi unuturuz. Test senaryosu bunu düzeltir. Her senaryo üç şeyi net söyler: hangi girdiyi vereceğiz, ne beklediğimizi ve gerçekte ne olduğunu. Böylece test tekrarlanabilir olur; yani aynı adımları başka biri de, sen de bir hafta sonra da aynı şekilde uygulayabilirsin.
Bu, projeyi rastgele "kurcalamaktan" farklıdır. Planlı test, hatanın nerede olduğunu tahmin etmek yerine göstermeni sağlar. Bu modülün ilerleyen derslerinde göreceğin Test Parkuru fikri de aynı mantığa dayanır: robotu farklı durumlardan tek tek geçirip her birinde ne yaptığını yazmak.
Test senaryosu nedir?
Bir test senaryosu, tek bir durumu kontrol eden küçük bir plandır. En yalın hali şudur:
- Girdi: Projeye ne veriyoruz? (bir buton, bir ışık miktarı, bir sayı, bir engel)
- Beklenen çıktı: Bu girdi karşısında ne olmasını istiyoruz?
- Gerçek çıktı: Denediğimizde gerçekten ne oldu?
- Sonuç: Beklenen ile gerçek aynı mı? (Geçti / Kaldı)
Bu derste tek bir örnek proje kullanacağız: önceki modüllerden tanıdığın otomatik gece lambası. Fikir basit: ortam karanlıksa LED yansın, aydınlıksa sönsün. Bir ışık sensörü (LDR) ortamın ne kadar aydınlık olduğunu ölçer.
Girdi → beklenen çıktı düşüncesi
Önce net bir kural yazalım: "Işık seviyesi 300'ün altındaysa LED yansın; değilse sönsün." Buradaki 300 sayısına eşik denir.
Şimdi bu kuralı senaryolara çeviriyoruz:
- Girdi: ışık seviyesi 100 (karanlık oda) → Beklenen: LED yanıyor.
- Girdi: ışık seviyesi 800 (aydınlık oda) → Beklenen: LED sönük.
Dikkat et: henüz projeyi denemedik bile. Beklenen çıktıyı önceden yazdık. Bu çok önemli, çünkü test sırasında sonucu görüp "eh, herhalde böyle olmalıydı" demeyi engeller.
Sınır durumları
En kolay hata yaptığımız yer tam eşiğin olduğu noktadır. Kuralımız "300'ün altındaysa yansın" diyor. Peki ışık tam 300 olursa ne olmalı? Yanmalı mı, sönmeli mi? Buna karar vermezsek proje bu noktada bazen yanar bazen sönebilir.
İşte tam eşik, hemen altı ve hemen üstü gibi noktalara sınır durumu denir. İyi bir test listesi mutlaka sınırları da içerir:
- Girdi: 299 → Beklenen: yanıyor.
- Girdi: 300 → Beklenen: sönük (çünkü kuralımız "altındaysa" diyor, 300 altında değil).
- Girdi: 301 → Beklenen: sönük.
Sınırları test etmek çoğu gizli hatayı ortaya çıkarır. Bir hesap makinesi düşün: 5'e kadar olan sayıları kabul ediyor. O zaman 4, 5 ve 6 senaryoları en değerli testlerdir; ortadaki 2 veya 3 nadiren sürpriz yapar.
Test senaryosu tablosu
Senaryoları düzenli tutmanın en iyi yolu bir tablodur. Her satır bir senaryodur. Böyle bir tablo test listesi olur ve onu istediğin kadar tekrar edebilirsin.
Gece lambası için örnek tablo:
| # | Adım / Girdi | Beklenen çıktı | Gerçek çıktı | Sonuç |
|---|---|---|---|---|
| 1 | Işık = 100 (karanlık) | LED yanıyor | LED yanıyor | Geçti |
| 2 | Işık = 800 (aydınlık) | LED sönük | LED sönük | Geçti |
| 3 | Işık = 299 (sınır altı) | LED yanıyor | LED yanıyor | Geçti |
| 4 | Işık = 300 (tam eşik) | LED sönük | LED yanıyor | Kaldı |
| 5 | Işık = 301 (sınır üstü) | LED sönük | LED sönük | Geçti |
Bu tabloda 4. satır "Kaldı" çıktı. Yani kod "300 ve altında yak" diye yazılmış olabilir, oysa biz "sadece 300'ün altında" istemiştik. Test bize hatanın tam yerini gösterdi. Bir sonraki derste bu tür hataları Hata Günlüğü'ne yazmayı öğreneceksin.
"Gerçek çıktı" ve "Sonuç" sütunlarını testi çalıştırmadan önce boş bırak. Ancak denedikten sonra doldur. Böylece kendini yanıltmazsın.
İkinci örnek: çizgi izleyen robot
Aynı yöntemi başka bir projeye uygulayalım. Önceki modüllerden çizgi izleyen robot: siyah çizgiyi görürse üstünde kalmaya çalışır. Girdi artık bir sayı değil, sensörün altında çizgi olup olmaması.
| # | Adım / Girdi | Beklenen çıktı | Gerçek çıktı | Sonuç |
|---|---|---|---|---|
| 1 | Çizgi tam ortada | Robot düz gidiyor | — | — |
| 2 | Çizgi sağa kayıyor | Robot sağa dönüyor | — | — |
| 3 | Çizgi sola kayıyor | Robot sola dönüyor | — | — |
| 4 | Çizgi tamamen kayboldu | Robot duruyor (kaybolma durumu) | — | — |
| 5 | Keskin viraj | Robot çizgide kalıyor | — | — |
- satıra dikkat: "çizgi kaybolursa" bir sınır durumudur ve çoğu kişi bunu düşünmez. Robot çizgiyi kaybedince ne yapmalı? Buna önceden karar vermek, sahada robotun masadan düşmesini engelleyebilir.
Mini uygulama
Kendi seçtiğin küçük bir projeye (gece lambası, çizgi izleyen robot ya da butonla çalışan bir zil) beş satırlık bir test tablosu hazırla. Şu adımları izle:
- Projenin tek cümlelik kuralını yaz. Örnek: "Buton basılıysa zil çalsın."
- Bu boş şablonu doldur:
Proje: ...................
Kural: ...................
# | Girdi | Beklenen çıktı | Gerçek çıktı | Sonuç
1 | (normal durum) | | |
2 | (başka normal durum)| | |
3 | (sınır: hemen altı)| | |
4 | (sınır: tam eşik) | | |
5 | (beklenmedik girdi)| | |
- "Beklenen çıktı" sütununu, projeyi denemeden önce doldur.
- Sonra projeyi çalıştır ve "Gerçek çıktı" ile "Sonuç" sütunlarını doldur.
- Aynı testi bir arkadaşına ver ve aynı sonuçları alıp almadığını gör. Aynı sonuçları alıyorsa testin tekrarlanabilir demektir.
En az bir tane sınır durumu ve bir tane beklenmedik girdi (örneğin sensör kablosu takılı değilken) eklemeye çalış.
Uygulama laboratuvarı: Test Senaryoları
Test Senaryoları konusunu kalıcı hâle getirmenin en iyi yolu, kavramı küçük ve ölçülebilir bir göreve dönüştürmektir. Bu çalışmada Test senaryosu nedir? ile Sınır durumları arasındaki ilişkiyi kullanarak sorun tanımı, gereksinim listesi, prototip, test kaydı ve kısa sunum hazırlayacaksın. Amaç yalnız sonucun çalışması değil; hangi kararı neden verdiğini, neyi test ettiğini ve hangi durumda tasarımı değiştireceğini açıklayabilmektir.
Görev senaryosu
Şu senaryoyu ele al: başarısız denemeleri de belgeleyen dürüst proje günlüğü oluşturma. Dersin ana hedefi “Projeni 'girdi → beklenen çıktı' senaryolarıyla planlı ve tekrarlanabilir biçimde test etmeyi öğren” olduğuna göre önce problemi tek cümleyle tanımla. Ardından sistemin alacağı girdiyi, uygulayacağı işlemi ve üreteceği çıktıyı ayrı ayrı yaz. Bilmediğin bir ayrıntı varsa onu varsayım olarak işaretle; varsayımı gerçek bilgi gibi kullanma.
- Planla: Başlangıç durumunu, beklenen sonucu ve kullanacağın kavramları yaz.
- En küçük sürümü kur: Yalnız temel davranışı çalıştır; süsleme ve ek özellikleri sonraya bırak.
- Üç test hazırla: Normal bir durum, sınırda bir durum ve hatalı ya da beklenmeyen bir durum seç.
- Sonucu kaydet: Beklenen ile gerçekleşeni yan yana yaz; fark varsa olası nedeni belirt.
- Tek değişiklik yap: Aynı anda birçok şeyi değiştirmek yerine bir kararı düzeltip testi yeniden çalıştır.
Başarı ölçütleri
- Sorun ve kullanıcı tek cümlede tanımlı mı?
- Gereksinimler ölçülebilir mi?
- Prototip en riskli varsayımı gerçekten deniyor mu?
- Test sonucu tarih ve koşulla kaydedildi mi?
- Sunumda çalışmayan noktalar da dürüstçe açıklanıyor mu?
“Test Senaryoları” çalışmasını bitirdiğinde ürünü bir arkadaşına yalnız bölüm başlıklarıyla anlat. Arkadaşın başarısız denemeleri de belgeleyen dürüst proje günlüğü oluşturma senaryosundaki adımları ve karar nedenlerini takip edebiliyorsa anlatım yeterince açıktır. Anlaşılmayan noktayı daha fazla terim ekleyerek değil, Test senaryosu nedir? ve Sınır durumları ilişkisini daha küçük adımlara bölerek düzelt.
Sık yapılan hatalar
Beklenen çıktıyı testten sonra yazmak
Denemeyi yapıp sonucu gördükten sonra "beklenen buydu zaten" demek en yaygın hatadır. Beklenen çıktı her zaman önce yazılır; yoksa test hiçbir şeyi doğrulamaz.
Sadece "iyi" durumları test etmek
Herkes projenin çalıştığı durumu dener. Asıl değerli olan sınırlar ve beklenmedik girdilerdir: tam eşik, boş girdi, takılı olmayan sensör, çok parlak ışık.
Belirsiz beklenti yazmak
"LED düzgün çalışsın" test edilebilir değildir. "Işık 100 iken LED yanıyor" test edilebilirdir. Beklentiyi ölçülebilir yaz.
Tek seferlik deneme
Bir kez çalıştı diye bitmiş saymak yanıltıcıdır. Aynı senaryoyu tekrar çalıştırınca aynı sonucu vermiyorsa proje henüz güvenilir değildir.
Güvenlik notu
Robot ve motor içeren testlerde robotu masadan düşmesin diye bir kenara yakın çalıştırmaktan kaçın; zemine yakın veya çevresi kapalı bir alanda dene. Motorları test ederken parmaklarını dişli ve tekerlek gibi hareketli parçalardan uzak tut. Sensör kablosunu takıp çıkarırken önce gücü kes. Pil ısınırsa testi durdur. Kesici alet, sıcak yüzey veya lehim gerektiren bir düzeltme yapman gerekirse bir yetişkinle birlikte yap.
Ders özeti
- Test senaryosu; girdi, beklenen çıktı, gerçek çıktı ve sonuç olarak dört parçadan oluşur.
- Beklenen çıktı, testi çalıştırmadan önce yazılır.
- Sınır durumları (tam eşik ve hemen çevresi) en çok gizli hatayı ortaya çıkarır.
- Senaryoları bir tabloda tutmak testi düzenli ve tekrarlanabilir yapar.
- İyi bir test, projenin sadece çalıştığı durumu değil, sınırları ve beklenmedik girdileri de dener.
Kontrol soruları
- Bir test senaryosunun dört temel parçası nedir?
- "Beklenen çıktı"yı neden testi çalıştırmadan önce yazarız?
- Sınır durumu ne demektir? Gece lambası örneğinden bir sınır durumu ver.
- Kuralımız "ışık 300'ün altındaysa LED yansın" ise, ışık tam 300 iken LED yanmalı mı? Neden?
- Bir test yaptın ve çalıştı. Yine de "tekrarlanabilir" demek için ne yapman gerekir?
Cevaplar
- Girdi, beklenen çıktı, gerçek çıktı ve sonuç (geçti/kaldı).
- Çünkü sonucu gördükten sonra yazarsak kendimizi kandırıp "zaten böyle olmalıydı" deriz; önceden yazmak testi gerçek bir doğrulama yapar.
- Sınır durumu, kuralın değiştiği noktaya çok yakın girdilerdir. Örnek: ışık 299, 300 ve 301 değerleri gece lambası için sınır durumlarıdır.
- Hayır, sönük olmalı. Kural "altındaysa" diyor; 300 sayısı 300'ün altında değildir, o yüzden eşiğe eşit değer kuralın dışında kalır.
- Aynı senaryoyu tekrar çalıştırıp aynı sonucu aldığını görmen ve mümkünse başka birinin de aynı adımlarla aynı sonucu almasını sağlaman gerekir.
Kaynak ve doğrulama notu
“Test Senaryoları” dersi için doğrulama odağı Test senaryosu nedir? ile Sınır durumları arasındaki ilişkinin örnekler üzerinde tutarlı çalışmasıdır. Proje sayfalarında sonuç iddiası ancak gerçek prototip, test kaydı veya gözlemle desteklendiğinde kullanılmalıdır. Maliyet, süre ve başarı oranı gibi sayılar tahminse açıkça “tahmin” olarak işaretlenmelidir.
Sonraki ders
Hata Günlüğü: Testte "Kaldı" çıkan durumları tek tek yazıp, ne denediğini ve neyin işe yaradığını düzenli biçimde kaydetmek.