Jira'da Hata Açmak

Not : Yazıda hata kelimesini kullandım çünkü Jira'yı bir talep takip sistemi olarak değil, yazılım sürecini destekleyici bir araç olarak anlatmak istedim. Ancak bir çok firma Jira'tı talep takip sistemi olarak ta başarıyla kullanıyor. Bu gibi kullanım durumlarında Issue Type olarak Purchase Request Form, Software Installation Request Form gibi tipleri seçiliyor.

Giriş

Jira'da hata açmak için bir sürü alan tanımlanabiliyor. Alan sayısını mümkün olduğunca az tutmak lazım. Bazı alanlarla ilgili notlarım aşağıda.

Hata Standardı
İyi çalışan firmalarda hata açmanın da bir standardı var. Description alanına belli bir formatta açıklama girilebilir. Örnek:

Steps to reproduce:
1. Access customer manager for user Test01
2. Check "User must change password" and click Apply
3. Access login page
4. Enter user name and password
5. Click Login

Expected results:
6. Site displays user profile page (see use case 21.1.2)

Actual results:
6. Site displays error page (see attached screen shot)

Hata Açarken Ana Sebep Ne Kadar İncelenmeli
QA hatayı açarken iki şekilde çalışabilir.

• Hatayı sadece açıp geçebilir 
• Hatanın ana sebebini detaylı inceleyerek gösterebilir. 

Projede hangi yöntemin kullanılacağını belirlemek faydalı olabilir. Geliştirme ekibi açısından hatanın ana sebebinin sıcağı sıcağına bulunması işleri kolaylaştırabilir.

Hata Yaratmak İçin Kullanılan Alanlar

Summary 
Hatanın özetini içerir. Hata listeleri üzerinde dolaşırken hatanın içine bakmadan ne hakkında olduğunu kolayca anlayabilmemizi sağlar.

Issue Type - Hata Türü
Yazılım İçin Açılan Hatalar
Bug henüz formal hale gelmemiş ürün için açılır. Formal hale gelmiş ürün için PR (Problem Report), SPR (Software Problem Report), SCR (Software Change Request) gibi isimler kullanılıyor.

Aslında Bug ve Defect arasında fark var.

• A bug is the result of a coding error
• A defect is a deviation from the requirements

Ancak çoğunluklar her şey bug olarak isimlendiriliyor. Bug'lar da kendi aralarında sınıflandırılabilir.
Dormant bug veya Latent Bug : Uyumakta olan, henüz ortaya çıkmamış bug anlamına gelir. Latent Bug bilinen ancak müşteriye söylenmeyen bug olarak ta tanımlanıyor.


QA Tarafından Açılan Hatalar
Hata türü olarak NR (Non Compliance Report) kullanılıyor.

İyileştirme amaçlı (Improvement) öneriler de kullanılabilir.

Priority - Hatanın Önem Seviyesi:
Hata yaratırken, önem seviyesinin girilmesi gerekir. Bunlar Blocker, Critical, Major, Minor, Trivial gibi seviyelerdir.

 Blocker : "Release will not be completed until issue is resolved. An example would be a severe problem that bridges multiple tools, or prevents core functionality in one tool."
 Critical : "Issue will most likely be resolved for release."
 Major : "Issue should be resolved for release."
 Minor : "Issue may be resolved for release."
 Trivial : "Issues that might be resolved before a release."

Çoğu proje sadece tek boyutlu önem seviyesi girer. Hata seviyeleri çözüm önceliklendirmesinde kullanılır. Örneğin Issues linki altında Blocker hatalar görülebilir. Toplantılarda üzerinden geçmek için kolaylık sağlar.

Hataların önem seviyesi değişik araçlarda farklı farklı isimlendirilebilir. Örneğin urgent, high, medium, low gibi seviyeler de kullanılabilir.

Process Detected:
MIL-STD-498 projelerinde aşağıdaki alanlar kullanılabiliyor.

• Operation & Maintenance
• Source Code Review
• Unit Integration Test
• CSCI Level Pre-Integration Test (*)
• CSCI Qualification Dry-Run
• CSCI Qualification Test
• System Pre-Integration Test
• System Integration Dry-Run
• System Integration Test
• System Qualification Dry-Run
• System Qualification Test

Process Injected:

• System Requirements Development
• Software Requirements Development
• System Design
• Software Design
• Software Implementation

Bu alan Root Cause olarak belki kullanılabilir. Root Cause hatanın yakalandığı yeri değil, asıl oluştuğu yeri gösterir. Root Cause olarak şunlar sıralanabilir
1. Lack of education
2. Communication problems
3. Immature processes
4. Omission or oversight
5. Interpretation or transcription
Root cause daha sonra şu işe yarar.
Detailed documentation of the defect enables us to note all the information obtained during this identification phase and helps developers to correct the defect and carry out any subsequent statistical analysis based on defect data (i.e identification of the most frequent root causes)

Açılan hataların nasıl çok boyutlu olarak önceliklendirileceğini gösteren güzel bir yazı burada. Açılan hatalara önem seviyesi verirken müşteri ve geliştirici açısından bakılmasını tavsiye ediyor.

Affects Version
"Version(s) in which an issue is observed" şeklinde tanımlanıyor.

Fix Version
"Version(s) for which an issue is anticipated to be fixed (for Unresolved issues) or in which it is actually fixed (for Resolved/Closed and Fixed issues)" şeklinde tanımlanıyor.

Kime Atananacağı
Assignee alanı "Automatic" olarak bırakılırsa takım liderine atanır.

Dosya Eklentisi
Yazılım hatalarında ekran görüntüsü veya logları eklenti olarak koymak faydalı olabilir.