1.
APPLICATION TEST
ddemirel/20171123

2.
Test Nedir?
 Bir sistemin ya da birimin, belirli şartları yerine getirip
getirmediğini bulmak niyetiyle değerlendirilmesi
işlemidir.
 Bir uygulamada var olan özellikler ile olması gereken
özellikleri analiz etmeyi sağlar.

3.
Testleri Kimler Yapar?
 Yazılımcı
 Yazılım Destek/Test Personeli
 Proje Yöneticisi
 Son Kullnıcı

4.
Teste Ne Zaman Başlarsınız? >>
 Testlere erken başlanılması son kullanıcıya teslim
edilen yazılımın hatasız olmasını sağlar, yeniden
düzenleme işlemleri için gereken zamanı ve maliyeti
azaltır.
 Testler yazılım geliştirme yaşam döngüsünün bir
aşaması olan «gereksinimleri toplama» aşamasında
başlayabilir ve bu yazılımın teslimine kadar devam
edebilir.

5.
Teste Ne Zaman Başlarsınız?
 İhtiyaçların toplanması aşamasında gereksinimlerin
analizi ve doğrulanması da test olarak kabul edilir.
 Tasarım aşamasında tasarımın gözden geçirilmesi
de test olarak kabul edilir.
 Kodun tamamlanmasından sonra geliştirici tarafından
yapılan kontroller de test olarak kabul edilir.

6.
Testler Ne Zaman Bitirilir?
 Testin sonsuz bir süreç olduğu ve hiç kimsenin bir yazılımın
%100 test edildiğini iddia edememesi nedeniyle, testi ne
zaman durduracağınızı belirlemek zordur.
 Aşağıdaki hususlar göz önüne alınarak buna karar verilebilir;
 Belirlenen test case’lerin başarılı çalıştırılmasının tamamlanması
 Belirli bir noktaya kadar fonksiyonel testlerin tamamlanması
 Hata sayısının belirli bir seviyenin altına inmesi ve yüksek öncelikli
hata tespit edilmemesi
 Yönetim kararı

7.
Testler İle İlgili Bazı Doğru Bilinen
Yanlışlar

8.
Test Süreci Çok Maliyetlidir
 Yazılımı geliştirirken yapılan test için ödediğiniz
bedel, bakım ve düzeltme aşamasında ödediğiniz
bedelden daha azdır.
 Erken yapılan testler zaman ve maliyet açısından
tasarruf sağlar, ancak test edilmeden maliyeti
düşürmeye çalışmak uygulamanın yanlış
geliştirilmesi ile ürünün işe yaramaz hale gelmesini
sağlar.

9.
Test Yapmak Zaman Kaybıdır
 SDLC Aşamaları gerçekleşirken, test yapmak zaman
kaybı değildir.
 Bununla birlikte test aşamasında hataların tespit
edilip düzeltilmesi zaman alan fakat üretken bir
faaliyettir.

10.
Sadece Tamamlanmış Ürünler Test
Edilebilir
 Test yapmak source code’a bağlıdır fakat müşteri
isteklerinin gözden geçirilmesi ve test planlarının
oluşturulması source koddan bağımsızdır.
 Ancak iterative veya incremental SDLC yaklaşımı
testlerin projeninin tamamının bitmesinden bağımsız
olarak yürütülmesini kolaylaştırır.

11.
Tümüyle Test Etmek Mümkündür
 Müşteri ya da test eden kişilerin eksiksiz testin
mümkün olduğunu düşünmesi bir sorun haline
gelebilir. Tüm durumların ele alınmış olması
mümkündür fakat eksiksiz test edilmesi asla
gerçekleşemez.
 SDLC sürecinde hiç test edilmeyen senaryolar
olabilir. Bu durum proje kullanıma başlandığında
ortaya çıkabilir.

12.
Test Edilmiş Yazılım Hatasızdır
 Bu müşterilerin, proje yöneticilerinin ve diğer
yöneticilerin inandığı ortak bir yanılgıdır.
 Uygulamayı mükemmel bir test sürecinden geçirseniz
bile kimse uygulamanın %100 hatasız olduğunu iddia
edemez.

13.
Kusurlar, Test Yapan Kişilerden
Kaynaklanmaktadır
 Testler tamamlandıktan sonra bile uygulamada kalan
hatalar için test yapan kişileri suçlamak doğru bir
yaklaşım değildir.
 Bu durum zaman, maliyet ve gereksinimleri
değiştiren kısıtlara bağlıdır.
 Bununla birlikte, test stratejisi hataların test ekibi
tarafından kaçırılmasına neden olabilir.

14.
Test Yapanlar Ürünün Kalitesinden
Sorumludur
 Uygulamanın kalitesinden sadece test yapanların ve
test ekibinin sorumlu olması çok yaygın bir yanılgıdır.
 Test yapanların sorumluluğu hataların belirlenmesini
sağlamak ve bunun ilgililere bildirmektir. Hataların
düzeltilip düzeltilmeyeceği kararını vermezler.
 Projenin zamanında tamamlanması test ekibi
üzerinde fazlaca baskıya sebep olur. Çünkü oluşan
herhangi bir hatadan sorumlu tutulabilirler.

15.
Test Otomasyonu Zaman Maliyetini Düşürmek İçin
Mümkün Olan Her Yerde Kullanılabilir
 Test otomasyonunun test zamanlarını azalttığı
doğrudur, fakat yazılım geliştirme aşamasında
herhangi bir zamanda test otomasyonuna başlamak
mümkün değildir.
 Test otomasyonu, uygulama manuel test edilip belirli
bir kararlılığa ulaştığında başlatılır. Gereksinimler
değişmeye devam ederse test otomasyonu
kullanılamaz hale gelir.

16.
Herhangi Birisi Uygulama Testi
Yapabilir
 IT sektörünün dışındaki kişiler, testlerin herhangi birisi
tarafından yapılabileceğini düşünürler. Hatta test yapma
işinin yaratıcılık gerektiren bir iş olmadığını da düşünürler.
 Fakat testçiler bunun bir safsata olduğunu çok iyi bilirler.
Alternatif senaryoları düşünerek, uygulamayı hataya
düşürecek durumları ortaya çıkarmak uygulamayı
geliştiren/tasarlayan kişiler tarafından yapılamaz.

17.
Kalite Güvence(QA), Kalite
Kontrol(QC), Test
Bu konular her ne kadar bir araya gelmiş ve bir
dereceye kadar aynı faaliyetler olarak görülse de
belirgin farklılıkları vardır.

18.
Kalite Güvence(QA), Kalite
Kontrol(QC), Test
Kalite Güvence Kalite Kontrol Test
KG geliştirilmesi yapılmış
yazılımların doğruluğuna
ve amaçlanan gerekliliklere
bağlı olarak süreçlerin,
prosedürlerin ve
standartların
uygulanmasını sağlayan
faaliyetleri içerir.
Belgelenmiş
gereksinimlerle ilgili olarak
gelişmiş yazılımın
doğrulanmasını sağlar.
Yazılımdaki hataların
tanımlanmasını sağlayan
faaliyettir.

19.
Kalite Güvence(QA), Kalite
Kontrol(QC), Test
Kalite Güvence Kalite Kontrol Test
Sistem üzerinde fiili test
yapmak yerine süreçlere
ve prosedürlere odaklanır.
Müşteri gereksinimlerinin
doğru tanımlanıp
tanımlanmadığını kontrol
eder.
Tanımlanan prosedürlerin
uygulanması yoluyla hata /
eksikleri tespit etmek
amacıyla testleri yapar.
Gerçek teste odaklanır.
Süreç odaklıdır. Prosedürleri doğrulamaya
odaklanır.
Sürecin işlemesinde
oluşacak hataları
önlemeye odaklanır.

20.
Kalite Güvence(QA), Kalite
Kontrol(QC), Test
Kalite Güvence Kalite Kontrol Test
Software Test Life
Cycle(STLC)’nin bir alt
kümesidir.
KG’nin bir alt kümesidir. KK’ün bir alt kümesidir.

21.
Test Çeşitleri
 Functional Test : Yazılımın belirtilen müşteri gereksinimleri karşılayıp karşılamadığını tespit etmeyi sağlar.
 Unit Test
 Source kodun belirli bölümlerini test etme yöntemidir.
 Integration Test
 Uygulamanın birleşik bölümlerinin birlikte doğru şekilde çalışıp çalışmadığını test etme yöntemidir.
 System Test
 Sistemin tümünü test etmeyi hedefler, tüm sistemin istenen kalite standartına uygun olup olmadığını kontrol etmeyi sağlar.
 Regression Test
 Sistemde yapılan bir geliştirmenin ya da hata gidermenin sistemin çalışan diğer bölümlerinde bir hataya sebep olup
olmadığını anlamayı sağlayan test yöntemidir.
 Acceptance Test
 Yapılan geliştirmenin istenen özelliklere uygun olup olmadığını, müşterinin gereksinimlerini karşılayıp karşılamadığını tespit
edildiği test yöntemidir.
 Alpha Test
 Geliştiriciler ve QA ekipleri için ilk test aşamasıdır. Unit test, integration test ve system test alfa testi olarak tanımlanabilir.
Test edilecek konular; Yazım hataları, bozuk bağlantılar, kötü yönlendirmeler vb.
 Beta Test
 Yayın öncesi test olarak adlandırılabilir. Uygulamayı kullanacak kitleden bir örnek kitle testi yapar. Yayın öncesi gerçek
kullanıcıların beklentilerini tespit etmeyi sağlar. Yazılımın kalitesini istenen düzeye çekmeyi hedefler.

22.
Test Çeşitleri
 Non-Functional Test
 Performans Test : Yazılımdaki oluşabilecek tıkanıklığı veya performans sorununu tespit etmeyi
sağlar.
 Hata sebepleri; Ağ gecikmesi, client sayısı, db transaction sayısı, load balancing problemi, veri işleme
 Performans testi; hız(response time), kapasite, stabilite ve ölçeklenebilirlik açısından önemli ve
zorunludur.
 Load Test
 Bu test normal ve yoğun zamanlarda yazılımın maks. kapasitesini ve davranışını tespit etmeyi sağlar.
 Stress Test
 Anormal koşullar altında yazılımın davranışını test etmeyi sağlar. Örneğin db bağlantısının kesilmesi
veya limitlerin ötesinde bir yük uygulamak gibi durumlar olabilir. Bu testin amacı yükü sisteme
uygulayarak yazılımın kırılma noktasını belirlemektir. Bu test; ağ bağlantılarını rastgele kapatarak yada
yeniden başlatarak, veritabanını kapatıp açarak veya yazılımın çalıştığı makinada sistem kaynaklarını
tüketecek farklı uygulamalar çalıştırılarak yapılabilir.
 Usability Test
 Kullanılabilirlik testi, kullanıcıların kullanımları ve çalışma şekillerini gözlemleyerek yazılımın daha iyi
kullanım kolaylığına sahip olup olmadığını tespit etmeyi sağlar. Yani bir sistemin kullanıcı dostu,
öğrenmesi kolay, hatırlanması kolay, kullanılması verimli, tatmin edici ve anlaşılması kolay olup
olmadığını anlamayı sağlar. Bu maddelerin sınırlarını çizen bazı ISO standartları ve kalite modelleri
mevcuttur(ISO-9126, ISO-9241-11, ISO-13407 ve IEEE).

23.
Test Çeşitleri
 Security Test
 Uygulamayı güvenlik açısından herhangi bir hataya sahip olup
olmadığını test etmeyi sağlar. Aşağıdaki konulara dikkat edilmelidir;
 Doğrulama, Yetkilendirme , Giriş kontrolü ve doğrulama, SQL ekleme
saldırıları, Enjeksiyon kusurları, Oturum yönetimi sorunları, Siteler arası
komut dosyası çalıştırma saldırıları, Dizin traversal saldırıları
 Portability Test
 Taşınabilirlik testi, yazılımın tekrar kullanılabilirliğini sağlamak amacıyla
test edilmesini sağlar. Bu testin temel amacı farklı donanım, işletim
sistemi ve browserlarda çalışabilirliğini test etmektir.
 Aşağıdaki stratejiler izlenebilir;
 Yüklü bir yazılmın bir bilgisayardan farklı bir bilgisayara aktarma
 Yazılımı farklı platformlarda çalıştırma

24.
Kaynak
 https://www.tutorialspoint.com