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 ?
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?
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
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ı
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
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
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
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
Fonksiyonel olmayan hata
Kullanabilirlik hatası
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
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ı
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,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
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
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
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)
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.
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.
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.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
Faundation Level Syllabus
Relesed
Version 2011
International Softwair Testing Qualifications Board
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?
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ı
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.
t
Bölüm 6 : Örnek Sorular
Certified Tester
Faundation Level Syllabus
Relesed
Version 2011
International Softwair Testing Qualifications Board
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
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
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
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?
[email protected] www.thebasolutions.com
Top Related