Rapor kalitesi: veri mutabakatı, ölçü testleri, belgeleme ve kabul testi

Finans uzmanı yazıyor: “Raporunuz toplam satışı 1.250.772,45 ₺ diyor, bizim ERP dökümü 1.346.189,85 ₺. Hangisi doğru?” İkisi de doğru olabilir. Fark tam olarak 95.417,40 ₺ ve bu, iptal edilen satırların tutarıdır: ERP tüm satırları topluyor, rapordaki [Net Satış] iptalleri dışlıyor. Bu cevabı beş dakikada verebilmek için mutabakatı önceden yapmış olman gerekir. Kullanıcı bir kez “bu rapor yanlış” derse, sonra doğru da olsa güveni geri kazanmak zordur.

Veri mutabakatı: rapor kaynağı tutuyor mu?

Mutabakat (reconciliation), rapordaki sayıların kaynak sistemdeki sayılarla aynı kurala göre aynı sonucu verdiğini göstermektir. Üç katmanda yapılır:

1. Satır sayısı: Kaynakta kaç satır var, modelde kaç satır var? Bizim modelde Satislar tablosu 1.620 satır; SatirNo sütununda da 1.620 farklı değer var, yani yinelenen satır yok.
2. Kontrol toplamları (control totals): Ham tutar toplamı, durumlara göre dağılım. Ham tutar 1.346.189,85 ₺; iptal 95.417,40 ₺; ikisinin farkı net satış 1.250.772,45 ₺.
3. Dönem kırılımı: Toplam tutsa bile aylar kayabilir (saat dilimi, yanlış tarih sütunu). Yıl ve ay düzeyinde karşılaştır.

Kaynak taraftaki karşılığını SQL ile alırsın (COUNT(*), SUM(Tutar), yıla göre GROUP BY); bunun için “Power BI analisti için SQL” dersine bak. Model tarafında aynı tabloyu DAX sorgu görünümünde (DAX query view) tek sorguyla üretirsin:

EVALUATE
ROW(
    "Satır", COUNTROWS(Satislar),
    "Tekil satır", DISTINCTCOUNT(Satislar[SatirNo]),
    "Ham tutar", SUM(Satislar[Tutar]),
    "İptal", CALCULATE(SUM(Satislar[Tutar]), Satislar[Durum] = "İptal"),
    "Net", [Net Satış]
)

Test sayfası ve DAX sorgu test paketi

Yazılımcılar kodlarını otomatik testlerle korur; ölçülerini sen de koruyabilirsin. Fikir: bilinen değerleri (brifteki ya da mutabakattaki sayılar) bir tabloya yaz, ölçülerin bugünkü sonucunu yanına koy ve farkı işaretle. Bir ölçüyü değiştirdikten sonra sorguyu tekrar çalıştırırsın; “FARK” görürsen bir şeyi bozmuşsundur.

EVALUATE
VAR Testler =
    DATATABLE(
        "Test", STRING, "Beklenen", DOUBLE,
        {
            { "Satır sayısı", 1620 },
            { "Net satış", 1250772.45 },
            { "Sipariş sayısı", 838 }
        }
    )
VAR Sonuc =
    ADDCOLUMNS(
        Testler,
        "Gerçek",
            SWITCH(
                [Test],
                "Satır sayısı", COUNTROWS(Satislar),
                "Net satış", [Net Satış],
                "Sipariş sayısı", [Sipariş Sayısı]
            )
    )
RETURN
    ADDCOLUMNS(Sonuc, "Durum", IF(ABS([Gerçek] - [Beklenen]) < 0.01, "OK", "FARK"))

Aynı testleri raporda gizli bir Test sayfasına da koyabilirsin: her test için bir kart, kart değeri “OK” ya da “FARK” döndüren bir ölçü. Sayfa yayımlanan uygulamada gizlenir; geliştirici her yayından önce bakar.

Uç durumlar: testin asıl yeri

Ölçülerin çoğu ortalama durumda doğru çalışır. Hatalar kenarlarda saklanır. Bizim modelde her biri gerçek olan beş kenar:

Bunlara ek olarak her sayfayı filtrelerle dene: tek bir yıl, hiç verisi olmayan bir kategori ve kanal kombinasyonu, birden çok dilimleyici seçimi. Satır düzeyi güvenlik varsa “Rol olarak görüntüle” ile her rolü tek tek test et (“Satır ve nesne düzeyinde güvenlik” dersi).

Veri sözlüğü: her ölçünün kimliği

Veri sözlüğü (data dictionary), modeldeki her ölçünün ve önemli sütunun ne anlama geldiğini yazan tablodur. Raporu devralan kişinin ilk açtığı belgedir.

Tanımı modelin içine de yaz: Model görünümünde ölçüyü seçip Özellikler bölmesindeki Açıklama (Description) alanını doldurursan, kullanıcı Veri bölmesinde ölçünün üzerine geldiğinde bu metni görür. Sözlüğün ham hâlini DAX sorgu görünümünde INFO.VIEW.MEASURES() fonksiyonu verir: her ölçünün adı, tablosu, açıklaması, ifadesi ve biçim dizesi gelir. İfade sütununu yalnızca modelde yazma izni olanlar görür.

EVALUATE
SELECTCOLUMNS(
    INFO.VIEW.MEASURES(),
    "Ölçü", [Name],
    "Açıklama", [Description],
    "Biçim", [FormatString],
    "İfade", [Expression]
)

Sürüm notları

Her yayında kısa bir not yaz ve raporun “Hakkında” sayfasına ya da çalışma alanındaki bir belgeye ekle:

Sürüm notunun en önemli satırı etkisidir: kullanıcı, dün indirdiği Excel’deki sayının neden bugün farklı olduğunu orada görür. Dosyaları PBIP biçiminde Git’te tutuyorsan, not commit mesajıyla birlikte geçmişe de yazılır (“Yaşam döngüsü: PBIP, TMDL, Git, dağıtım işlem hatları, şablonlar” dersi).

Kullanıcı kabul testi (UAT)

Kullanıcı kabul testi (user acceptance testing), raporu yapan değil kullanan kişinin, brifteki kabul kriterlerine göre “evet, bu iş görüyor” demesidir. Kriterleri brifte yazmıştın; burada testi yönetiyorsun:

1. Test kişilerini seç: her rolden en az bir kullanıcı (müdür, bölge sorumlusu).
2. Senaryo ver, tur verme: “Aralıkta hedefin altında kalan kategoriyi bul ve geçen yılla karşılaştır.” Kullanıcı kendisi yapsın.
3. Bulguları tek listede topla: madde, kim buldu, önem (engelleyici / önemli / küçük), durum.
4. Engelleyici yoksa onay al: e-postayla ya da iş takip aracında “Kabul edildi” durumu, tarih ve kişi.

Yayımlamadan önce kontrol listesi

• Test sorgusu ve test sayfası: tüm satırlar OK.
• Mutabakat tablosu güncel; son kontrolden sonra kaynakta yapı değişikliği yok.
• Uç durumlar denendi: ilk ve son dönem, boş değerler, toplam satırı, filtre kombinasyonları.
• Her ölçünün açıklaması dolu; veri sözlüğü güncel.
• Satır düzeyi güvenlik her rolle test edildi.
• Sayfa, Performans Analizi’nde (Performance analyzer) kabul edilebilir sürede açılıyor.
• Erişilebilirlik ve mobil düzen kontrol edildi (“Mobil düzen, erişilebilirlik, dışa aktarma ve kişiselleştirme” dersi).
• Sürüm notu yazıldı, kullanıcılara duyuru hazır.