Azure Test Plans’ta Gerçek Sonuç: Kâğıt Üstünden Çıkıp İşe Giriyor
Manual test yapan ekipler bilir; bazen asıl soru test geçti mi kaldı mı olmuyor. Asıl mesele, o adımda gerçekten ne yaşandığı. Azure Test Plans tarafına gelen Actual Result alanı da tam bu boşluğu kapatıyor. Açık konuşayım, yıllardır test raporlarında “notlar” kısmına sıkışıp kalan bilgileri görünce içim biraz burkulurdu;. Orada kaybolan detay, sonra kök neden analizinde dönüp dolaşıp yine insanın önüne çıkıyor.
Bu özellik public preview olarak geldi ve bence baya iş görüyor. Herkes otomasyona abanırken manuel testin hâlâ kritik olduğunu bazen unutuyoruz, işte orası biraz sıkıntı. Bilhassa regülasyonlu sektörlerde, bir finans kuruluşunda ya da büyük bir entegrasyon projesinde, adım adım kanıt bırakmak şaka değil. Hani “test tamamlandı” demek var, bir de “şu adımda şu çıktı alındı, ekranda şu hata görüldü” diyebilmek var. İkisi arasında ciddi fark var.
Çok konuştum, örnekle göstereyim.
Neden Bu Özellik Şimdi Önemli Hâle Geldi?
Dürüst olmak gerekirse, Benim gözümde bu özellik biraz geç kalmış ama yine de iyi ki gelmiş kategorisinde. 2019’da İstanbul’daki bir kurumsal projede manuel test sonuçlarını Excel’de takip ediyorduk; her satırda ayrı bir hikâye vardı. Iz sürmek berbattı. Bir test adımı başarısız — itiraz edebilirsiniz tabi — olduğunda, gerçek davranışı görmek için tester’a dönüp tekrar sormak zorunda kalıyorduk. Neden önemli bu? Oysa kayıt anında alınan Actual Result olsaydı iş yarıya inerdi (bizzat test ettim)
Küçük bir detay: İşin aslı şu ki manuel test artık sadece QA ekibinin işi değil; ürün yöneticisi bakıyor, geliştirici bakıyor, müşteri temsilcisi bakıyor, denetçi bakıyor… herkes aynı kaydı farklı gözle okuyor. Böyle olunca netlik lazım. Azure Test Plans’ın bu alanı test adımı seviyesinde sunması güzel çünkü “test case geçti” gibi yuvarlak cümlelerin altını dolduruyor.
Bi saniye — Bir de compliance tarafı var tabiî. 2023’te Ankara’da çalışan bir sağlık sektörü müşterimizde buna benzer bir ihtiyaç çıkmıştı: kim neyi ne zaman gördü, hangi ekran çıktısı eklendi, hangi onay verildi… Kağıt üstünde basit duran şeyler pratikte audit günü geldiğinde hayat kurtarıyor. Bayağı kurtarıyor hatta.
Gel gelelim burada küçük bir hayal kırıklığı da yok değil: Preview olduğu için her org’da aynı anda görünmeyebiliyor ve bu biraz can sıkıyor. Hemen “ben açamadım” paniğine gerek yok ama rollout gecikmesi yüzünden ekipler arasında kafa karışıklığı çıkabilir.
Adım Seviyesinde Kayıt Neden Fark Yaratıyor?
Bir testi baştan sona tek satırda özetlemek çoğu zaman yanıltıcıdır. Mesela login senaryosu geçti diyelim; ama ikinci adımda OTP geciktiyse bunu kaydetmezseniz sonraki haftalarda aynı sorun tekrar eder ve kimse ilk sinyali hatırlamaz.
Step-level kayıt bana hep mutfaktaki tarif notlarını hatırlatır: “bir tutam tuz” demek yetmez, hangi aşamada eklendiğini bilmek gerekir. Test dünyasında da durum aynı.
Açılışta Ne Sunuyor? Güçlü Yanları ve Sınırlar
Bak şimdi, Azure Test Plans tarafındaki Actual Result yaklaşımı birkaç şeyi aynı anda çözüyor: kanıt toplama, izlenebilirlik. Ekip içi iletişim. Test koşulurken yazılan not ile sonradan oluşturulan rapor arasında ciddi kalite farkı oluyor. Çünkü hafıza insaflı davranmıyor; iki saat sonra yazılan açıklama genelde eksik kalıyor.
İlginç olan şu ki, Audit readiness, yanı denetime hazır olma hali burada önemli anahtar kelime oluyor. Denetim masasına oturduğunuzda — itiraz edebilirsiniz tabi — “evet çalıştı” demek pek işlemiyor; ekran görüntüsü lazım oluyor, tarih damgası lazım oluyor, yorum lazım oluyor… Actual Result bunların hepsini daha düzenli hâle getiriyor.
Hmm, bunu nasıl anlatsamdı…
E tabi her şey güllük gülistanlık değil. Public preview olması nedeniyle bazı organizasyonlarda kullanıcı deneyimi biraz ham gelebilir (özellikle büyük tenant’larda) (şaşırtıcı ama gerçek). Ben buna şaşırmadım açıkçası; preview ürünlerde ilk gün cilası tam olmuyor zaten.
| Konu | Klasik Manual Test Notu | Actual Result ile |
|---|---|---|
| Kayıt detayı | Kaba özet | Adım bazlı net çıktı |
| Köken analizi | Zor | Daha kolay |
| Denetim desteği | Zayıf | Daha güçlü iz bırakır |
| Ekip işbirliği | Sınırlı yorumlaşma | Daha anlaşılır paylaşım |
Büyük Kurum mu Küçük Ekip mi?
Küçük bir startup iseniz olay biraz daha sade: hızlıca deneyip işinizi görüyor mu diye bakarsınız ve yeterince iyiyse kullanırsınız. Büyük enterprise yapıda işe konu başka yere gidiyor; rol bazlı erişimler, plan standardizasyonu. Denetim beklentisi devreye giriyor.
Bence startup tarafında bu özellik nice-to-have gibi başlayıp kısa sürede must-have’e dönebilir. Enterprise tarafta işe doğrudan süreç — ki bu tartışılır — iyileştirme aracı olur çünkü onlar zaten belge düzenine daha çok takılıyorlar. Peki bunu neden söylüyorum? Aslında durun bir dakika — burada önemli olan sadece araç değil süreç disiplini de var.
Bunu biraz açayım.
Bunu Sahada Nasıl Kullanırım?
Lafı gevelemeden söyleyeyim: önce test plan seviyesinde karar verin hangi planlarda AR zorunlu olacak hangilerinde opsiyonel kalacak. Her plana aynı sertliği uygulamak bazen gereksiz yük bindirir. Örneğin UAT planlarında zorunlu yapmak mantıklı olabilir ama erken keşif testlerinde opsiyonel bırakmak işleri hızlandırır.
Ne yalan söyleyeyim, 2024 Mart’ta İzmir’deki bir üretim firmasında benzer yaklaşımı başka araçlarla kurgulamıştık.
Orada en büyük kazanım şu öldü:
tester ekran görüntüsünü anında iliştirince geliştirici ile tester arasındaki tartışma yarıya indi.
Çünkü veri vardı.
Yorum değil veri…
- Test planınızı açın ve AR politikasını belirleyin.
- Zorunlu olacak senaryoları seçin.
- Ekran görüntüsü veya kısa açıklama standardını tanımlayın.
- Ekipten örnek kayıt isteyin ve formatı netleştirin.
{
"testPlan": "UAT-Release-24",
"actualResultMode": "Mandatory",
"evidence": [
{
"step": 1,
"result": "Login başarılı",
"attachment": "otp-delay.png"
}
]
}Peki API Tarafı Ne İşe Yarar?
Bazı ekipler için web arayüzü yeterli. Otomasyonla birleşince gerçek güç ortaya çıkıyor.
REST API üzerinden actual result çekebilmek raporlama boru hattına güzel oturur.
Mesela Power BI dashboard’a beslersiniz ya da dış denetim sistemine gönderirsiniz.
Ben AZ-104 çalışırken bile hep şunu düşünürüm: elle yapılan iş kadar onun nasıl taşındığı da önemli!Ama şunu dürüstçe söyleyeyim: API dokümantasyonu ilk etapta beklediğim kadar akıcı gelmedi.
Ufak ufak toparlanmış ama bazı alanlarda örnek sayısı az kalmış.
Yine de Microsoft’un bunu genişleteceğini düşünüyorum çünkü kullanım senaryosu belli ölçüde büyüyor.
Sahada Karşılaşabileceğiniz İnce NoktalarBirinci nokta eğitim meselesi.
Testçi arkadaşlarınız yıllardır sadece pass/fail giriyorsa yeni alan başlangıçta ekstra iş gibi görünebilir.
Burada liderlik devreye giriyor:
“Şunu yazmak size yük değil, sonra sizi kurtaracak kayıt” diye anlatmanız gerekiyor.”İkinci nokta standartlaştırma…
Eğer herkes farklı dille actual result girerse rapor güzelleşmez; tam tersine gürültü oluşur.
Bir yerde “ok”, başka yerde “works fine”, başka yerde “sorunsuz” yazarsa arama yaparken boğulursunuz.”
Bu yüzden kısa sözlük iyi fikir olur.
💡 Bilgi: İlk pilotu tek takımda deneyin. Tüm organizasyona yaymadan önce iki hafta boyunca gerçek kullanım toplayın; aksi hâlde benimsenme düşer.
Sıkça Sorulan Sorular
Actual Result özelliği ne işe yarıyor?
İşin garibi, Manual test yaparken her adımda ne olduğunu — yanı metin ve eklerle birlikte — kaydetmenizi sağlıyor. Aslında sadece “geçti/kaldı” demekten çok daha fazlası; ne yaşandığını da saklıyorsunuz.
Her Azure DevOps organizasyonunda hemen aktif mi?
Açıkçası hayır, herkeste aynı anda açılmıyor. Public preview aşamasında olduğu için kademeli dağıtılıyor — biraz sabır gerekebilir.
Kullanmak zorunda mıyız?
Zorunlu değil, ama bence bazı süreçlerde zorunlu hâle getirmek mantıklı. Mesela UAT veya audit odaklı projelerde gerçekten çok işe yarıyor.
Sadece metin mi girebiliyoruz?
Hayır, ek dosya desteği de var. Yanı ekran görüntüsü eklemek isteyen ekipler için de oldukça kullanışlı — tecrübeme göre bu özellik özellikle hata raporlamada fark yaratıyor.
Kaynaklar ve İleri Okuma
Microsoft DevBlogs — Public Preview: Actual Result for Manual Tests in Azure Test Plans
Azure DevOps Manual Testing Documentation
Azure DevOps Test REST API Documentation
Sizin İçin İlgili Yazılarımdan Bazıları
Bunun yanında CI/CD tarafına da bakıyorsanız şu yazıyı öneririm:
GitHub Copilot ile azd: Terminalde Akıllı Kurulum, Hızlı Çözüm.
Hani test süreçlerini otomasyonla bağlamak isteyenler için fena bir referans değil (ben de ilk duyduğumda şaşırmıştım)
Benim görüşüm net: Actual Result küçük ekiplerde disiplin kazandırıyor, büyük yapılarda işe denetlenebilirlik sağlıyor. Ama gerçek değer ancak ekip önü düzenli kullanırsa ortaya çıkıyor!
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder