ISTQB PROJELERDE HATA YÖNETİMİ

ISTQB Metodolojisi ile

Projelerde Hata Yönetimi

05 Ocak 2015

Beşiktaş / İstanbul

Vedat Çelikel

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

t

Bölüm 1 : Giriş (Introduction)

Certified Tester

Faundation Level Syllabus

Relesed

Version 2011

International Softwair Testing Qualifications Board

Projelerde Hata Yönetimi (Defect Management) Hata ve Test Analisti ?


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?

t

Bölüm 2 : Hata Ne Zaman Tespit Edilebilir? (When Can a Defect be Detected?)

Certified Tester


Relesed

Version 2011



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ı

Projelerde Hata Yönetimi (Defect Management) Bir Hata Ne Zaman Tespit Edilebilir?


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

t

Bölüm 3 : Hata Raporu Ala ları (Defect Report Fields)

Certified Tester


Relesed

Version 2011


Projelerde Hata Yönetimi (Defect Management)

Hata Raporu Alanları


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

Hata Raporu Alanları


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

Fonksiyonel olmayan hata

Kullanabilirlik hatası

t

Bölüm 4 : Hata Sı ıfla dır a ( Defect Classification)

Certified Tester


Relesed

Version 2011



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ı



Ö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,Entegrasyon testi,Sistem testi ve K.K.T.

Hatanın Tespit

Edildiği proje aşaması

Hatanın-

Şüphe nedeni

Tekrarlanabilirlik

Bulgu

Örneğin: Gereksinimler,tasarı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



Ö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



Ö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



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)



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.



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.



Hata (Takip) Sınıflandırma Tablosu

Örneği

Hata Takip Tablosu

Hata No

Açıklama Hata Tarihi

Hata -Prj.Aktivitesi

Hata Tanımı- Prj.Aşaması

Hata Tespiti-Prj.Aşama

Şüpheli Neden

Tekrarlanabilirlik

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.xxxx

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.xxxx

IS-002

Gereksinimlerde hesaplama

hatası

xx.xx.xxxx

İnceleme Gereksinimle

r

Gereksinim

inceleme

Gereksinim

Veri

hatası

Hatalı gereksi

nim

Gereksinimler

Hesaplama sorunu

Gereksinim revize

Gereksinim revize

3 3

Hatalı Hesaplama

Var Yok var Çalışılıyor

Projenin içeriğine göre eklenebilir.

t

Bölüm 5 : Kök Neden (Ana Neden) Analizi (Root Cause Analysis)

Certified Tester


Relesed

Version 2011


Onay

Amacı Nedir?

Projelerde Hata Yönetimi (Defect Management) Kök Neden Analizi ( Root Cause Analysis )


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?



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ı



Ö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.

t

Bölüm 6 : Örnek Sorular

Certified Tester


Relesed

Version 2011


ISTQB Metodolojisi ile Projelerde Hata Yönetimi

Soru 1


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


Soru 2


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


Soru 3


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


Soru 4


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?

[email protected] www.thebasolutions.com

Business

ISTQB PROJELERDE HATA YÖNETİMİ