Yazılım Test Mühendisliği Dersleri: Bölüm 5
Agile Test Süreçleri: Scrum, Kanban, Jira, Kullanıcı Hikâyeleri ve INVEST Yaklaşımı
Çevik (Agile) yazılım geliştirmede test etkinliği, sprint döngüsüne ve ekip iş akışına derinlemesine entegre olur. Bu rehberde Scrum ve Kanban çerçevelerini, Jira ile iş takibini, iyi bir kullanıcı hikâyesinin nasıl yazılacağını ve INVEST kriterlerini adım adım ele alıyoruz.
Bu Sayfada
i Agile Test Süreçlerine Giriş
Geleneksel (Waterfall) yaklaşımlarda test, geliştirme tamamlandıktan sonra ayrı bir aşama olarak yürütülürken; Agile (çevik) yaklaşımlarda test, geliştirmeyle iç içe, sürekli ve erken başlayan bir etkinliktir. Bu felsefeye “shift-left testing” denir — yani test faaliyetleri süreç içinde mümkün olduğunca sola, yani en başa kaydırılır.
Bu sayfada, Agile dünyasının iki temel çerçevesi olan Scrum ve Kanban‘ı, bu çerçevelerde en yaygın kullanılan iş takip aracı Jira‘yı, gereksinimlerin nasıl kullanıcı hikâyeleri haline getirildiğini ve iyi bir hikâyenin sahip olması gereken INVEST kriterlerini inceliyoruz.
1 Scrum ve Test Mühendisinin Rolü
Scrum, işi sabit uzunluktaki zaman dilimlerine (genellikle 1-4 hafta) bölen, bu dilimlere sprint denilen, yinelemeli (iterative) bir çevik çerçevedir. Her sprint sonunda potansiyel olarak yayınlanabilir bir ürün artırımı (increment) hedeflenir.
Scrum Rolleri
🎯 Product Owner
Ürün vizyonundan ve backlog’un önceliklendirilmesinden sorumludur. Hangi özelliğin, hangi sırayla geliştirileceğine karar verir.
🧭 Scrum Master
Ekibin Scrum kurallarına uymasını sağlar, engelleri (impediment) ortadan kaldırır, süreci kolaylaştırır.
👥 Geliştirme Ekibi
Geliştirici ve test mühendislerinden oluşan, kendi kendini yöneten (self-organizing) çapraz fonksiyonlu ekiptir.
Sprint Döngüsü ve Törenler (Ceremonies)
2 Kanban ile Sürekli Akış
Kanban, işin sabit zaman dilimlerine (sprint) bölünmediği, bunun yerine görselleştirilmiş bir pano (board) üzerinde sürekli akış (continuous flow) halinde ilerlediği bir çevik yaklaşımdır. Temel prensipleri: iş akışını görselleştirmek, devam eden iş miktarını sınırlamak (WIP Limit) ve akışı sürekli ölçüp iyileştirmektir.
Backlog 8
Devam Ediyor 3 / 3 WIP
Test / Review 2
Tamamlandı 5
3 Scrum vs Kanban Karşılaştırması
Scrum
- Sabit uzunlukta sprint‘ler (1-4 hafta)
- Sabit roller: Product Owner, Scrum Master, Ekip
- Belirli törenler (Planning, Daily, Review, Retro)
- Sprint sonunda değişiklik yapılmaz (dondurulmuş kapsam)
- İlerleme ölçümü: Velocity, Burndown Chart
Kanban
- Sabit zaman dilimi yok, sürekli akış
- Rol zorunluluğu yok, esnek yapı
- Zorunlu tören yok, istenirse eklenebilir
- İstenildiği zaman yeni iş eklenebilir (WIP limit dahilinde)
- İlerleme ölçümü: Cycle Time, Lead Time, Cumulative Flow
| Boyut | Scrum | Kanban |
|---|---|---|
| En uygun olduğu durum | Öngörülebilir, planlı ürün geliştirme | Sürekli destek, bakım, hızlı değişen öncelikler |
| Test yaklaşımı | Sprint içinde test tamamlanır (Definition of Done) | Her kart “Test” sütununu geçmeden “Done” olamaz |
| Değişikliğe açıklık | Sprint ortasında düşük | Her zaman yüksek |
4 Jira ile İş ve Hata Takibi
Jira (Atlassian), Agile ekiplerin hem Scrum hem de Kanban panolarını yönetmek, gereksinimleri (hikâyeleri), görevleri ve hataları izlemek için en yaygın kullandığı araçlardan biridir. Test mühendisleri için Jira genellikle şu amaçlarla kullanılır:
- Issue (İş kalemi) türleri: Epic (büyük iş paketi), Story (kullanıcı hikâyesi), Task (görev), Bug (hata), Sub-task (alt görev).
- Workflow (İş akışı): To Do → In Progress → In Review → In Testing → Done gibi özelleştirilebilir durumlar arasında geçiş.
- Hata kaydı: Önceki bölümde ele aldığımız hata yaşam döngüsü (New, Assigned, Fixed, Retest, Closed vb.) doğrudan Jira’nın “Bug” issue tipi ve workflow’u üzerinden yönetilir.
- Bağlantılar (Links): Bir Bug, ilgili Story’ye “relates to” veya “blocks” ilişkisiyle bağlanarak izlenebilirlik (traceability) sağlanır.
- Test yönetimi eklentileri: Xray, Zephyr Scale gibi Jira eklentileri, test senaryolarını, test koşumlarını (test run) ve kapsam raporlarını doğrudan Jira içinde yönetmeyi sağlar.
Örnek Jira Issue Kartı
Issue Tipi : Bug
Anahtar : SEPET-482
Başlık : Kupon kodu %100 indirimde negatif tutar hesaplıyor
Öncelik : Yüksek
Şiddet : Kritik
Sprint : Sprint 24
Durum : In Progress
Atanan : Ayşe Yılmaz (Geliştirici)
Raporlayan : Mehmet Demir (Test Mühendisi)
Bağlı Story: SEPET-410 - Kullanıcı sepete kupon kodu uygulayabilmeli
Etiketler : regresyon, ödeme, sprint-24
5 Kullanıcı Hikâyeleri (User Stories)
Kullanıcı hikâyesi, bir yazılım özelliğinin, teknik detaylardan çok kullanıcı değeri odaklı, kısa ve sade bir dille anlatılmasıdır. Klasik gereksinim dokümanlarının aksine, hikâyeler ekip içinde tartışılmaya ve birlikte netleştirilmeye açık bir başlangıç noktasıdır.
Bir
böylece
Örnek: Bir e-ticaret müşterisi olarak, sepetime kupon kodu girebilmek istiyorum, böylece siparişimde indirim kazanabilirim.
Kabul Kriterleri (Acceptance Criteria)
Her kullanıcı hikâyesi, “ne zaman tamamlanmış sayılır” sorusuna cevap veren kabul kriterleriyle desteklenmelidir — bu kriterler doğrudan test senaryolarına dönüşür:
Hikâye: Kullanıcı sepetine kupon kodu uygulayabilmeli
Kabul Kriterleri:
1. Geçerli bir kupon kodu girildiğinde indirim sepet toplamına yansır.
2. Süresi dolmuş bir kupon kodu girildiğinde hata mesajı gösterilir.
3. Aynı kupon kodu bir siparişte yalnızca bir kez kullanılabilir.
4. Kupon kodu alanı boş bırakılırsa "Uygula" butonu pasif kalır.
6 INVEST Yaklaşımı
İyi yazılmış bir kullanıcı hikâyesinin sahip olması gereken altı özellik, Bill Wake tarafından tanımlanan ve baş harflerinden oluşan INVEST kısaltmasıyla özetlenir:
Independent
Bağımsız — diğer hikâyelere aşırı bağımlı olmamalı, tek başına geliştirilip test edilebilmeli.
Negotiable
Müzakere edilebilir — katı bir sözleşme değil, ekip ve müşteri arasında tartışılabilir bir başlangıç noktasıdır.
Valuable
Değerli — son kullanıcıya veya müşteriye somut bir değer sunmalıdır.
Estimable
Tahmin edilebilir — ekip, hikâyenin büyüklüğünü/karmaşıklığını makul ölçüde tahmin edebilmelidir.
Small
Küçük — tek bir sprint içinde tamamlanabilecek kadar küçük ve yönetilebilir olmalıdır.
Testable
Test edilebilir — net kabul kriterleriyle, “tamamlandı” durumunun nesnel olarak doğrulanabilmesi gerekir.
| Kriter | İyi Uygulama | Kötü Uygulama |
|---|---|---|
| Independent | “Kullanıcı profil fotoğrafı yükleyebilmeli” | “Profil sayfasının 3. adımı tamamlanmadan bu hikâye başlayamaz” |
| Small | “Kullanıcı e-posta ile giriş yapabilmeli” | “Kullanıcı yönetim modülünün tamamı” (çok büyük, epic seviyesinde) |
| Testable | “3 başarısız girişten sonra hesap 15 dakika kilitlenmeli” | “Giriş ekranı güvenli olmalı” (ölçülemeyen, belirsiz) |
✓ Sonuç ve Öneriler
Agile test süreçleri, testin ayrı bir aşama değil, geliştirme akışının doğal bir parçası olduğu bir kültür değişimini temsil eder. Scrum öngörülebilir, döngüsel bir yapı sunarken; Kanban sürekli akış gerektiren, önceliklerin sık değiştiği ortamlarda daha uygundur. Her iki çerçevede de Jira gibi araçlar, hikâyelerden hatalara kadar tüm iş kalemlerinin şeffaf şekilde izlenmesini sağlar.
Sürecin kalitesi, büyük ölçüde girdisinin kalitesine bağlıdır: iyi yazılmış kullanıcı hikâyeleri ve bu hikâyelerin INVEST kriterlerini karşılaması, test mühendisinin işini kolaylaştırır ve sprint sonunda ortaya çıkan belirsizlikleri en aza indirir.