Bölüm 1: Giriş (Introduction) Bölüm 2: Hata Ne Zaman Tespit Edilebilir? (When Can a Defect be Detected?) Bölüm 3: Hata Raporu Alanları (Defect Report Fields) Bölüm 4: Hata Sınıflandırma ( Defect Classification) Bölüm 5: Kök Neden (Ana Neden) Analizi (Root Cause Analysis) Bölüm 6: Soru Örnekleri

1. ISTQB Metodolojisi ile
Projelerde Hata Yönetimi
05 Ocak 2015
Beşiktaş / İstanbul
Vedat Çelikel

2. Eğitim İçeriği
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Bölüm 1: Giriş (Introduction)
Bölüm 2: Hata Ne Zaman Tespit Edilebilir? (When Can a Defect be Detected?)
Bölüm 3: Hata Raporu Alanları (Defect Report Fields)
Bölüm 4: Hata Sınıflandırma ( Defect Classification)
Bölüm 5: Kök Neden (Ana Neden) Analizi (Root Cause Analysis)
Bölüm 6: Soru Örnekleri

3. t
Bölüm 1 : Giriş (Introduction)
Certified Tester
Faundation Level Syllabus
Relesed
Version 2011
International Softwair Testing
Qualifications Board

4. Projelerde Hata Yönetimi (Defect Management)
Hata ve Test Analisti ?
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Hata Nedir? Hata,çözülmesi gereken gerçek bir problemdir.
Test analsti,sistemin doğru davranıp davranmadığını,mevcut durum ile
beklenen sonucu karşılaştırarak belirler.
Test Analistleri iş ve kullanıcıların ihtiyaçları açısından sistem davranışını
değerlendirirler.
Test Analistinin Rolü
Nedir?
Test Analisti Hatayı
Nasıl Belirler?

5. t
Bölüm 2 : Hata Ne Zaman Tespit
Edilebilir? (When Can a Defect be
Detected?)
Certified Tester
Faundation Level Syllabus
Relesed
Version 2011
International Softwair Testing
Qualifications Board

6. ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Yazılım geliştirme yaşam döngüsünün her aşaması
potansiyel hataları tespit ve giderilmesi için
yöntemler,olanaklar sağlamalıdır.
Örneğin, geliştirme aşamasında, kod ve tasarım yorum
hatalarını tespit etmek için kullanılmalıdır.
Dinamik Test sırasında, test case ler başarısızlıkları tespit
etmek için kullanılır.
Statik
Test
• Bir hata, statik test ve arıza
belirtileri ile tespit edilebilir
Dinamik
Test
• Başarısızlık, dinamik testler ile
tespit edilebilir.
Projelerde Hata Yönetimi (Defect Management)
Bir Hata Ne Zaman Tespit Edilebilir?
Hata tespit etme aşamaları

7. Projelerde Hata Yönetimi (Defect Management)
Bir Hata Ne Zaman Tespit Edilebilir?
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Bir hata önceden tespit edilir ve düzeltilir
ise, sistemin genel kalite maliyeti düşer
Hata takip sistemi, test analistine
yaşam döngüsü içerisinde yer alan ve
hata bulunanan aşamaya kayıt girme
olanağı sağlamalı
Gereksinim inceleme sırasında
hatalı gereksinim tespit edilip,
düzeltilmesi; pahalıya mal olacak
ek iş yükünü önlemiş olacaktır.
Hatalı gereksinim, gereksinim
inceleme sırasında gözden
kaçarsa, yazılım geliştirme, test
analisti ve son kullanıcı için boşa
harcanan zaman oluşturacaktır.
Faz kapsamı, hataların sebep olacağı
maliyetleri düşürmenin en etkili yoludur.
Maliyet
Kayıt Girme
Olanağı
Hatalı
Gereksinim
Tespiti
Zaman
Kaybı
Faz
Kapsamı
Hata Tespitinin Etkileri

8. t
Bölüm 3 : Hata Raporu Ala ları
(Defect Report Fields)
Certified Tester
Faundation Level Syllabus
Relesed
Version 2011
International Softwair Testing
Qualifications Board

9. Projelerde Hata Yönetimi (Defect Management)
Hata Raporu Alanları
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Düzenli Hata
Raporu
Tamamlanmış
Özlü
Objektif
Bütün gerekli bilgiler
rapora girilmiştir.
Konu ile ilgisi olmayan
bilgiler raporda yer
almaz.
Rapor gerçek
anlamda ve ustalıkla
(düzenli) yazılmış
durumdadır.
Doğru
Raporda yer alan
bilgiler, doğru ve net
bir şekilde beklenen
gerçek sonuçlarından
oluşur.
Olması gereken hata
raporu bilgileri
Hata raporu için verilen
alanlar yeterli bilgi
sağlama amaçlıdır

10. Hata Raporu Alanları
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
1. Bir hata raporuna
kaydedilen bilgiler veri
alanlarına bölünmüş
olmalıdır.
Projelerde Hata Yönetimi (Defect Management)
5. Farklı tipdeki hata
raporları farklı bilgiler
gerektirir ve hata yönetimi
araçları doğru alanları
isteyecek kadar hata
tiplerine bağlı olarak esnek
olmalı.
6, Veri giriş hatalarını
önlemek ve etkin raporlama
sağlamak için,ideal veri
doğrulama tarafından
desteklenen veriler farklı
alanlarda kayıt altına
alınmalıdır.
8. Hata raporu bilgisi her
zaman açıkça
tanımlanan ve problemi
tespit edilen seneryoya
yönelmelidir.
9. Fonksiyonel olmayan
hata raporları daha
detaylı bilgi gerektirebilir,
(örneğin : yükün
boyutu),adımların sırası,
beklenen sonuçlar.
10. Bir kullanılabilirlik
hatası dökümante
edilirken,önemli
durum,kullanıcının
yazılımdan beklentisi
nedir.
2. İyi tanımlanmış alanlar,
tek tek hataları hem de
eğilim raporları ile diğer özet
raporları üretmeyi
kolaylaştırır.
3. Mevcut bir alan
için,seçeneklere numara
tanımlandığı zaman,açılan
listelere hata kaydı
girildiğinde ihtiyaç duyulan
zaman kısalacaktır.
4. Seçenek numaraları
sınırlandırıldığında,açılan listeler
daha verimli kullanılabilecek ve
kullanıcılar doğru seçeneği
bulmak için daha uzun bir liste
içerisinde gezinmek zorunda
kalmayacak.
7. Fonksiyonel olan ve
Fonksiyonel olmayan
testler esnasında
keşfedilen başarısızlıklar
için hata raporları yazılır.
Bir hata raporu yazmak,soruna yönelik bir düzeltme elde etmektir,
ayrıca hata bilgileri doğru sınıflandırmaya destek olmalıdır.
Hata
yönetimi
araçları
Alan
tanımı
Numara
tanımı
Numara
sınırıVeri alanı
Doğru
veri
Ayrı
rapor
Seneryo
yönelme
Fonksiyon
el olmayan
hata
Kullanabilir
lik hatası

11. t
Bölüm 4 : Hata Sı ıfla dır a (
Defect Classification)
Certified Tester
Faundation Level Syllabus
Relesed
Version 2011
International Softwair Testing
Qualifications Board

12. ISTQB Metodolijisi ile Projelerde Hata Yönetimi
1
• Sınıflandırmanın farklı seviyeleri vardır ve bunlara
yaşam döngüsü içerisinde erişilebilir.
2
• Doğru hata sınıflandırma,doğru hata raporunun
ayrılmaz bir parçasıdır.
3
• Sınıflandırmalar, testin verimliliğini değerlendirmek,
• Geliştirme yaşam döngüsü ve ilginç eğilimleri
belirlemek amacıyla, hata grupları için kullanılır.
Projelerde Hata Yönetimi (Defect Management)
Hata Sınıflandırılması

13. Projelerde Hata Yönetimi (Defect Management)
Hata Sınıflandırılması
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Örneğin:
İnceleme,
denetim,teftiş,
kodlama ve
test
Tespit edilen
hatanın
sonuçlanması
nda ki Proje
Aktivitesi
Örneğin:
Gereksinimler,
Tasarım,
Detaylı
tasarım, kod.
Hatanın
Tanımlandı
ğı Proje
Aşaması
Örneğin:
Gereksinimler,
Tasarım,
Detaylı tasarım,
Kod,Kod
inceleme,Birim
testi,Entegrasyo
n testi,Sistem
testi ve K.K.T.
Hatanın
Tespit
Edildiği
proje aşaması
Hatanın-
Şüphe
nedeni
Tekrarlanabilirlik
Bulgu
Örneğin:
Gereksinimler,t
asarım,arayüz,
kod,veri
Örneğin:
önce bir kere,
aralıklı, tekrar
üretilebilir.
Örneğin:
Çökme,Kullanıcı,
Arabirimi
hatası,sistem
hatası,
performans
Hata sınıflandırma,
yeni belirlenen hatalar
için ortak
sınıflandırma bilgileri
içerir

14. Projelerde Hata Yönetimi (Defect Management)
Hata Sınıflandırılması
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Örneğin: süreç,kod hatası,kullanıcı
hatası,test hatası,yapılandırma
sorunu,data sorunu,harici yazılım
sorunu, dökümantasyon hatası.
Kök sebep
(ana neden)- Hatanın kusurlu
sonuçlanması
Örneğin: gereksinimler,tasarım,detaylı
tasarım,mimari,veritabanı tasarımı,
kullanıcı dökümanı,test dökümanı.
Kaynak - Hata yapılan çalışma ürünü
Örneğin: mantık problemi,
hesaplama problemi,
zamanlama sorunu,veri işleme.
Tip
İncelemelerden sonra da, sınıflandırma mümkün olabilir

15. Projelerde Hata Yönetimi (Defect Management)
Hata Sınıflandırılması
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Örneğin:
kod değişikliği,dökümantasyon
değişikliği,ertelenen, problem
olmayan,tekrarlı sorun.
Çözüm
Örneğin:
gereksinimlerin gözden geçirilmesi,kodun
gözden geçirilmesi,birim testi,yapılandırma
dökümantasyonu,veri hazırlama,yapılan
değişiklik yok.
Düzeltici eylem
Kusur sabitlendiğinde (veya ertelediğinde/onaylanmadığında) daha da
sınıflandırma bilgileri olabilir

16. Projelerde Hata Yönetimi (Defect Management)
Hata Sınıflandırılması
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Etki-Şiddet ( Severity )
(Sistem bazlı)
Öncelik ( Priority )
(Kullanıcı bazlı)
Hatalar, etki ve öncelik temeline dayalı olarak ayrıca sınıflandırılır.
5 - Kritik (Critical)
4 - Önemli (Major)
3 - Orta (Moderate)
2 - Küçük (Minor)
1 - Görsel (Cosmetic)
3 - Düşük (Low)
2 - Orta (Medium)
1 - High (Yüksek)

17. Projelerde Hata Yönetimi (Defect Management)
Hata Sınıflandırılması
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Proje Risk ve Proje Kalite Etkisi
Güvenlik Etkisi Proje Takvimi Etkisi
Proje Maliyet Etkisi
Yapılan sınıflandırma kategorilerine ek olarak,aşağıda belirtilen
sınıflandırmalar da yapılabilir.

18. Projelerde Hata Yönetimi (Defect Management)
Hata Sınıflandırılması
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Problem olmayan
Sabitlenmiş Doğrulanmış,Kapatılmış
Ertelenen, Açık
Nihai çözümler (Statü),sınıflandırmaların son alanıdır.Hatalar sıklıkla nihai
çözümlerine göre birlikte gruplandırılır
Çözülmeyen
Yaşam döngüleri içerisinde takip edilen hatalar gibi, sınıflandırmalar da genellikle proje
boyunca takip edilir.

19. Projelerde Hata Yönetimi (Defect Management)
Hata Sınıflandırılması
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Hata (Takip)
Sınıflandırma Tablosu
Örneği
Hata Takip Tablosu
Hata
No
Açıklama
Hata
Tarihi
Hata -
Prj.Aktivites
i
Hata
Tanımı-
Prj.Aşaması
Hata
Tespiti-
Prj.Aşama
Şüpheli
Neden
Tekrarla
nabilirlik
Bulgu
Kök
Sebep
Kaynak HataTipi Çözüm
Düzeltici
Eylem
Etki-
Şiddet
Öncelik
Risk ve
Kalite
etkisi
Maliyet
etkis
Güvenlik
Etkisi
Takvim
etkisi
Statü
Statü
Tarihi
IS-
001
Veri girişinde
xxxx Hatası
alınıyor
xx.xx.xxx
x
Test Kod Birim Test Kod Aralıklı Çökme
Kod
mantık
hatası
Veritabanı
Tasarımı
Veri
İşleme
Kod
Değişikliği
Kod
Değişikliği
2 3
Hatalı
rapor
var Yok Yok Kapatıldı
xx.xx.xx
xx
IS-
002
Gereksinimler
de hesaplama
hatası
xx.xx.xxx
x
İnceleme
Gereksinimle
r
Gereksini
m
inceleme
Gereksini
m
Veri
hatası
Hatalı
gereksi
nim
Gereksiniml
er
Hesaplam
a sorunu
Gereksini
m revize
Gereksini
m revize
3 3
Hatalı
Hesapla
ma
Var Yok var Çalışılıyor
Projenin içeriğine göre
eklenebilir.

20. t
Bölüm 5 : Kök Neden (Ana Neden)
Analizi (Root Cause Analysis)
Certified Tester
Faundation Level Syllabus
Relesed
Version 2011
International Softwair Testing
Qualifications Board

21. Onay
Amacı Nedir?
Projelerde Hata Yönetimi (Defect Management)
Kök Neden Analizi ( Root Cause Analysis )
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Hataya neyin neden olduğunu belirlemek , süreç değişikliklerini desteklemek için veri
sağlamak ve hataların önemli bir kısmının kök nedenlerini ortadan kaldırmak.
Ön kök değerlendirme işlemi genellikle, probleme ‘’muhtemelen’’ neyin neden olduğunu
tahmin eden Test Analisti tarafından yapılır.
Kök neden analizi, genellikle problemi inceleyen ve problemi gideren veya problemin
giderilip,giderilmeyeceğini belirleyen kişi tarafından yürütülür. Bu kişi genellikle
Geliştiricidir.
Düzeltme onaylandığı zaman geliştirici tarafından girilen kök neden bilgileri ,Test
Analisti tarafından doğrulanır. Hatanın tanımlandığı faz onaylanır.
Genellikle
kimlerin rolü
var?

22. Projelerde Hata Yönetimi (Defect Management)
Kök Neden Analizi ( Root Cause Analysis )
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
2. Eksik Gereksinim
1. Net açıklanmayan
gereksinim
5. Yanlış arabirim uygulaması
4.Yanlış tasarım uygulaması
3. Hatalı gereksinim
Kök Neden Tipleri:
7. Hesaplama hatası
6. Kod mantık hatası
10. Geçersiz veri
9. Arayüz hatası
8. Donanım hatası

23. Projelerde Hata Yönetimi (Defect Management)
Kök Neden Analizi ( Root Cause Analysis )
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Örneğin: eğer çok sayıda hataya net
açıklanmayan gereksinimler neden oluyor ise
daha verimli(etkili) gereksinimleri yürütmek
daha mantıklı olur.
Yaygın sorunları belirlemek için hataların
sonuçlarından oluşan kök nedenler
toplanır
Süreç değişikliği, ek araç ve ekipman satın alınmanın yanı sıra, takvimleme değişikliği gerektirebilir,bu
nedenle de fon sağlamada yardımcı olur.
Benzer olarak eğer arayüz uygulaması geliştirme grupları arasında bir sorunsa ortak tasarım oturumları
gerekebilir.

24. t
Bölüm 6 : Örnek Sorular
Certified Tester
Faundation Level Syllabus
Relesed
Version 2011
International Softwair Testing
Qualifications Board

25. ISTQB Metodolojisi ile Projelerde Hata Yönetimi
Soru 1
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Soru : Aşağıdakilerden hangisi sınıflandırma kriterlerinden değildir?
A. Kök neden.
B. Tip.
C. Kaynak.
D. Gereksinim.
Cevap : D. Anahtar kelimeler: Kök neden,Tip,Kaynak

26. ISTQB Metodolojisi ile Projelerde Hata Yönetimi
Soru 2
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Soru : Aşağıdakilerden hangisi Kök neden tipi değildir?
A. Net açıklanmayan gereksinim.
B. Donanım hatası.
C. Kaynak.
D. Geçersiz veri.
Cevap : C. Anahtar kelimeler: Net açıklanmayan gereksinim,Donanım hatası,Geçersiz veri

27. ISTQB Metodolojisi ile Projelerde Hata Yönetimi
Soru 3
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Soru : İş ve Kullanıcıların ihtiyaçları açısından sistem davranışını değerlendirirler.
Tanımı, aşağıdakilerden hangisinin rolü dür?
A. Test Analisti
B. İş Analisti
C. Yazılımcı
D. Son Kullanıcı
Cevap : A. Test Analisti

28. ISTQB Metodolojisi ile Projelerde Hata Yönetimi
Soru 4
ISTQB Metodolijisi ile Projelerde Hata Yönetimi
Soru : Çözülmesi gereken gerçek bir problemdir.
Açıklaması, aşağıdakilerden hangisinin tanımıdır?
A. Severity nedir?
B. Hata nedir ?
C. Kök neden nedir?
D. Prority nedir?
Cevap : B. Hata nedir?

29. contact@thebasolutions.com
www.thebasolutions.com