Scrum ve çevik ekiplerde QA süreci: sprint içinde kalite nasıl kurulur

Çevik ekipte test ayrı bir aşama değildir

Geleneksel şelale yaklaşımında analiz, geliştirme ve test ardışık aşamalardır; test, geliştirme bittikten sonra başlar. Çevik ekiplerde ise sprint içinde küçük bir özellik tasarlanır, geliştirilir, test edilir ve tamamlanır. Test aşaması sona kalmaz; özellik üzerinde çalışmaya başlandığı anda başlar.

Bu fark, QA rolünün işini değiştirir. Çevik ekipte QA, hataları sondan toplayan bir kapı bekçisi değil, kaliteyi baştan inşa eden ekibin parçasıdır. Hata bulmaya odaklanmak yerine hatanın oluşmasını önlemeye çalışır: gereksinimdeki belirsizliği toplantıda yakalar, kabul kriterlerini geliştirmeden önce netleştirir, geliştiricinin yazdığı birim testlere katkı verir.

Scrum Guide'ın dilinde tanımlı bir "test uzmanı" rolü yoktur; ekip, geliştiriciler (Developers) olarak ortak sorumluluk taşır. QA uzmanlığı, bu geliştirici grubunun içinde bir yetkinliktir. Pratikte birçok ekipte bu yetkinliği ağırlıklı taşıyan bir ya da birkaç kişi bulunur ve kalite sorumluluğu tüm ekibe yayılır.

Bir sprintin içinde QA nerede devreye girer

Sprint döngüsü boyunca QA'nın katkısı şu noktalarda görünür:

Ürün listesi iyileştirme (refinement) oturumu: Kullanıcı hikâyesi henüz geliştirilmeden önce QA, "bu hikâye nasıl test edilir" sorusunu sorar. Belirsiz kabul kriteri, eksik hata durumu, tanımsız sınır değer bu aşamada ortaya çıkar. Hata bulmanın en ucuz yeri burasıdır.

Sprint planlama: Hikâyelerin test çabası görev olarak planlanır. Yalnızca geliştirme süresini tahmin etmek, "bitti" ile "test edildi" arasında sprint sonunda biriken bir yığın doğurur.

Sprint içi: Geliştirici bir parça tamamladıkça QA ile birlikte hızlıca denenir. Test, sprintin son günlerinde toplanmaz; tamamlanan her hikâye o gün test edilir. Otomasyon varsa bu akışta yeni testler birlikte yazılır.

Sprint gözden geçirme: QA, tamamlanan işin kabul kriterlerini gösterimde teyit eder.

Retrospektif: Sprintte kaçan hataların kök nedenleri konuşulur ve ekip çalışma biçimine bir iyileştirme ekler.

Bu akışın işlemesi için ekibin "tamamlandı" ölçütü ortak ve açık olmalıdır.

Definition of Done ve kabul kriterleri

Definition of Done (Tamamlanma Tanımı), bir işin bitmiş sayılması için karşılanması gereken ortak ölçütlerdir. Kalite ölçütleri bu tanımın doğal parçasıdır. Örnek bir tanım şunları içerebilir:

• Kod gözden geçirildi.
• Birim testler yazıldı ve geçti.
• Kabul kriterleri doğrulandı.
• Otomasyon paketine ilgili regresyon testi eklendi.
• Test ortamında hata kalmadı ya da kalan hatalar ürün sahibiyle kabul edildi.
• Güvenlik ve erişilebilirlik kontrolleri yapıldı.

Kabul kriterleri ise tek bir hikâyeye özgüdür: o hikâyenin başarılı sayılması için neyin doğru olması gerektiğini söyler. Kabul kriterleri doğrudan test senaryolarına dönüşür. "Verilen, olduğunda, o zaman" biçiminde yazılırsa hem ürün sahibi hem geliştirici hem QA aynı cümleyi okur.

Sık görülen sorun, Definition of Done'ın sprint baskısı altında sessizce gevşetilmesidir. QA'nın sorumluluğu, bu tanımı hatırlatmak ve bir ölçüt atlanıyorsa bunu görünür kılmaktır; kararı ise ekip birlikte verir.

Üç amigo oturumu: geliştirici, QA ve ürün

Üç amigo, bir hikâyeyi geliştirmeden önce farklı bakış açılarının bir araya geldiği kısa görüşmedir: ürün tarafı ne istendiğini, geliştirici nasıl yapılacağını, QA ise neyin ters gidebileceğini getirir. Oturumun çıktısı, örnekler ve netleşmiş kabul kriterleridir.

Örneğin bir "şifremi unuttum" hikâyesinde ürün sahibi akışı anlatır. QA şu soruları sorar: e-posta sistemde kayıtlı değilse ne gösterilecek? Bağlantı bir kez kullanılınca ya da süresi dolunca ne olacak? Aynı kullanıcı arka arkaya birçok kez talep ederse? Geliştirici ise bu durumların teknik maliyetini ve riskini söyler. Görüşme bitince hikâyede belirsiz hiçbir soru kalmamalıdır.

Bu oturum uzun olmak zorunda değildir; hikâye başına kısa bir görüşme yeterli olabilir. Önemli olan, geliştirme başlamadan, yanlış anlamaların henüz ucuz olduğu anda yapılmasıdır. Kayıtlar kabul kriterlerine ve doğrudan otomasyon senaryolarına dönüştürülür.

Sürekli test ve otomasyon piramidi

Kısa döngüde sık yayın yapan bir ekip, her değişiklikte tüm sistemi elle test edemez. Bu nedenle çevik ekiplerde testler katmanlandırılır (test piramidi): altta çok sayıda hızlı birim test, ortada servis ve entegrasyon testleri, üstte az sayıda uçtan uca arayüz testi. Altta çalışan testler dakikalar içinde sonuç verir ve geliştirme hattında (CI) her değişiklikte otomatik çalışır.

QA'nın sorumluluğu, hangi riskin hangi katmanda yakalanacağına karar vermede ekibe yardım etmektir. İş kuralları birim ya da servis düzeyinde, kullanıcı akışının kritik yolları ise arayüz düzeyinde sınanır. Her şeyi arayüzden otomatikleştirmeye çalışan ekip, yavaş ve kırılgan bir test paketi biriktirir (buz dağı anti-deseni).

Otomasyon her şeyin yerine geçmez. Yeni bir özelliği keşfetmek, kullanılabilirliği değerlendirmek ve beklenmeyen davranışları aramak için keşif testi (exploratory testing) manuel olarak sürer. Çevik QA, otomasyon ile keşif testinin dengesini kurar: tekrar eden yoklamayı makineye, insan yargısı gerektiren soruları insana bırakır.

Çevik QA'da ölçme ve yaygın tuzaklar

Ölçme: Test sayısı ya da "bulunan hata sayısı" tek başına kalite göstergesi değildir. Daha anlamlı sorular şunlardır: sprint sonunda kaç hikâye test edilmiş halde teslim ediliyor, üretime kaçan hatalar hangi aşamada yakalanabilirdi, regresyon paketi ne kadar sürüyor ve ne kadar güvenilir, hata düzeltme süresi nasıl eğilim gösteriyor. Bu ölçümler suçlu aramak için değil, süreci iyileştirmek için kullanılmalıdır.

Sık tuzaklar: • Mini şelale: Sprintin ilk yarısında geliştirme, sonraki yarısında test. Çözüm: hikâyeleri küçük kesmek ve tamamlanan işi hemen test etmek. • QA'yı tek sorumlu görmek: "Kalite QA'nın işi" tutumu. Çözüm: kaliteyi Definition of Done ile ortak sorumluluk yapmak. • Sprint sonuna sıkışan regresyon: Çözüm: her hikâye için regresyon testini hikâyenin kendi içinde otomasyona eklemek. • Kabul kriterleri olmadan başlamak: Test edilemeyen hikâye sprinte alınmamalıdır. • Teknik borcu görünmez bırakmak: Atlanan testleri kayıt altına alıp bir sonraki planlamada ele almak.

Küçük ekiplerde ayrı bir QA kişisi olmayabilir. Bu durumda yetkinlik geliştiriciler arasında paylaşılır; yine de bağımsız bakış açısı değerlidir, çünkü kodu yazan kişi kendi varsayımlarını sınamakta zorlanır.

Bu süreci Mindset programlarında nerede çalışırsınız

Test Otomasyonu ve QA Temelleri programının Çevik Ortamda QA modülü, sprint içinde test entegrasyonunu, Definition of Done ve kabul kriterlerini, üç amigo oturumunu, sürekli test ve pipeline entegrasyonunu, hata kaçış oranı gibi QA metriklerini ve çevik QA kültürünü ele alır. Çevik geçiş yapan, test fonksiyonunu sprint ritmine uyarlamak isteyen ekipler ve Scrum Master ile ürün sahibi gibi kalite sürecine dışarıdan bakan roller için uygulanabilir bir çerçeve sunar.