İç uygulamalar için kontrol listeleriyle kodsuz QA onay iş akışı

Net bir onay olmayınca iç uygulamalar neden bozulur

İç uygulamalar ekip içinde kullanıldıkları için “güvenli” hissedilir. Bu yüzden tam da böyle can sıkıcı hatalar çıkar. Değişiklikler hızlı gönderilir, testler yüzeysel olur ve gerçek ilk sınama en yoğun kişinin Pazartesi sabahı yeni düğmeye basmasıyla ortaya çıkar.

Kodsuz araçlar riski ortadan kaldırmaz. Mantık, veri ve izinleri yine değiştiriyorsunuz. Bir "küçük" ayar diğer ekranlara, rollere veya unuttuğunuz otomasyonlara dalga dalga etki edebilir. Ayrıca iç kullanıcılar genellikle sorunları bildirmek yerine etraftan çözüm üretir; bu yüzden problemler sessizce kalıp yoğun bir haftada patlayana kadar görünmeyebilir.

Net bir onay yoksa aynı tür hatalar tekrar eder:

• Yapıcıda izinler doğru görünür, ama gerçek bir kullanıcı bir sekmeyi göremez veya kaydı düzenleyemez.
• “Basit” bir alan değişikliği raporu, dışa aktarmayı veya entegrasyonu bozar.
• Bir iş akışı gerekli bir değer eksik olduğu için takılır veya bir statüya ulaşılamaz.
• Veri yanlış yere kaydedilir, bir sonraki adım veriyi bulamaz.
• Bildirimler yanlış kanala gider veya gönderilmeyi durdurur.

Onay uzun bir QA aşaması değildir. Bu, geliştiriciden farklı birinin değişikliği üzerinde anlaşılan bir kontrol listesiyle hızlıca kontrol edip "Evet, hazır" dediği kısa, tekrarlanabilir bir andır. Amaç mükemmellik değil; güven duymaktır.

Hafif bir onay süreci size daha az sürprizle öngörülebilir sürümler verir. “Bitti” tanımını herkes için ortak kılar; geliştiriciler, inceleyiciler ve nihai onaylayıcı değişiklikleri aynı şekilde değerlendirir. Küçük bir düzeltme veya AppMaster gibi bir platformda yapılan daha büyük bir güncelleme olsun, bu onay adımı hızlı değişiklikleri güvenilir sürümlere dönüştürür.

Roller: talep sahibi, geliştirici, inceleyiciler ve nihai onaylayıcı

Onay, herkesin ne yapacağını bildiği zaman çalışır. Rolleri minimumda tutun ama karar haklarını netleştirin.

Çoğu iç ekip sürümleri dört rol ile karşılayabilir:

• Talep sahibi: ne değiştirileceğini, neden önemli olduğunu ve "bitti"nin nasıl göründüğünü açıklar.
• Geliştirici: değişikliği uygular ve QA için hazır bir sürüm hazırlar.
• İnceleyici(ler): kontrol listesini kullanarak test eder ve sonuçları kaydeder.
• Nihai onaylayıcı: tek “deploy için hazır” onayını verir.

Bir kural süreci temiz tutar: inceleyiciler "iyi görünüyor" diyebilir, ama sadece nihai onaylayıcı "deploy için hazır" diyebilir. Bu kişiyi kıdem yerine riske göre seçin. Destek aracı destek liderine ait olabilir. Finans iş akışı finans sonuçlarından sorumlu bir kişi tarafından onaylanmalıdır.

Gerçek kullanımı yansıtan inceleyiciler seçin. Birinin uygulamayı sık kullanan biri olması, diğerinin ise adımları birebir takip eden "taze göz" bir testçi olması iyi olur. AppMaster’da geliştiriyorsanız bu genellikle işe yarar çünkü UI, mantık ve veri değişiklikleri hızlıca test edilebilir; böylece inceleyiciler davranışa odaklanabilir, kod yerine.

QA’nın uzamaması için basit yanıt süreleri belirleyin: engelleyiciler için aynı gün, normal değişiklikler için 24 saat içinde ve düşük öncelikler için haftalık partiler.

Ayrıca bir yedek onaylayıcı belirleyin. İnsanlar izne çıkar, olaylara çağrılabilir veya mesajları kaçırabilir. Bir yedek onay gecikmeleri önler ve onayın anlamını korur.

Rolleri, isimleri ve zaman beklentilerini sürüm kaydında (veya kontrol listesinin başında) yazın ki her çalışma aynı temel kurallarla başlasın.

Sürüm kapsamını ve basit kabul kriterlerini belirleyin

Kimse test etmeden önce ne göndereceğiniz konusunda anlaşın. Bir “sürüm” hata düzeltme, yeni özellik, veri değişikliği veya yapılandırma güncellemesi olabilir. İsimlendirme yoksa insanlar yanlış şeyleri test eder, riskli kısımları kaçırır ve yine de "QA yaptık" hissine kapılır.

Pratik bir yaklaşım, her sürümü tür ve risk açısından etiketlemek ve testi ona göre eşleştirmektir. Bir kopya değişikliği izin, ödeme veya birçok ekranı etkileyen bir iş akışı değiştirmekle aynı değildir.

Sürüm türleri ve risk seviyeleri

Herkesin uygulayabileceği tanımlar kullanın:

• Hata düzeltme: davranışı olması gerektiği şekilde geri getirir.
• Yeni özellik: yeni bir ekran, adım veya otomasyon ekler.
• Veri değişikliği: alanları, kuralları, içe aktarmaları veya varsayılan değerleri değiştirir.
• Entegrasyon değişikliği: e-posta/SMS, Stripe, Telegram veya diğer bağlı hizmetleri etkiler.
• Erişim değişikliği: roller, izinler veya oturum açma ayarlarını değiştirir.

Ardından düşük, orta, yüksek gibi bir risk seviyesi seçin. Yüksek risk genellikle daha fazla inceleyici, daha fazla test vakası ve kenar durumlara daha yakından bakmayı gerektirir.

Ayrıca düşük riskli sürümler için bile her zaman test edilecekleri kararlaştırın. Küçük ve istikrarlı tutun. İç uygulamalar (AppMaster’da yapılanlar dahil) için genelde her zaman test listesi: oturum açma, rol tabanlı erişim ve günlük olarak güvendiğiniz bir veya iki ana akıştır.

İnsanların gerçekten kullanabileceği kabul kriterleri

Kabul kriterlerini sonuç odaklı ve sade bir dille yazın. "Beklendiği gibi çalışıyor" gibi ifadelerden kaçının. Teknik yapı adımlarından kaçının.

Onay formuna yapılan bir değişiklik için örnek kriterler:

• Bir inceleyici bir isteği açıp onaylayabilmeli ve durum 2 saniye içinde güncellenmeli.
• Sadece yöneticiler Onay düğmesini görebilmeli; temsilciler asla görememeli.
• Talep sahibi doğru istek ID’siyle bir e-posta bildirimi almalı.
• Zorunlu alanlar eksikse uygulama net bir mesaj göstermeli ve kaydetmemeli.

Kriterler bu kadar açık olduğunda onay, kağıt üzerinde bir mühür yerine gerçek bir karar olur.

İnsanların gerçekten tamamlayacağı bir kontrol listesi hazırlayın

Bir QA kontrol listesi ancak tamamlaması kolay olduğunda işe yarar. Bir ekran ve 10–15 dakika hedefleyin. Uzunsa insanlar maddeleri atlar ve onay formaliteye döner.

Her satırı spesifik ve test edilebilir tutun. "Kullanıcı yönetimini doğrula" muğlaktır. "Bir kullanıcı oluştur, role ata, yeniden giriş sonrası erişim değişikliğini doğrula" ise nettir. Maddeleri gerçek bir kişinin uygulamayı kullandığı sıraya göre sıralayın, yapıldığı sıraya göre değil.

Büyük bir listeye ihtiyacınız yok. İç uygulamaların genellikle başarısız olduğu alanları kapsayın: ana akış uçtan uca, rol izinleri, temel veri doğruluğu ve kötü giriş yapıldığında ne olduğu. Gerekliyse bir denetim kontrolü ekleyin.

Her satırı netçe geç/kal (pass/fail) yapın. İşaretlenemiyorsa muhtemelen çok geniştir.

Her madde için bir “Kanıt” alanı ekleyin. İnceleyiciler anında önemli olanı yakalamalı: kısa not, tam hata metni, kayıt ID’si veya ekran görüntüsü.

Takımların uyduğu basit bir format: Madde, Geç/Kal, Kanıt, Sahip. Örnek: “Yönetici rolü istekleri onaylayabiliyor” -> “Fail - Onay düğmesi İstek #1042'de eksik, manager_test hesabıyla test edildi.”

AppMaster’da dahili uygulamalar inşa ediyorsanız, bu kontrol listesini bir QA görev kaydının içinde yansıtarak sonuçların sürüme ekli kalmasını sağlayabilirsiniz.

Test verisi, test hesapları ve sıfırlama kurallarını hazırlayın

Çoğu onay süreci basit bir nedenle başarısız olur: inceleyiciler geliştiricinin test ettiklerini yeniden üretemez. Test verisi ve test hesaplarını sürümün bir parçası sayarak bunu düzeltin.

İlk olarak gerçek rolleri yansıtan test hesaplarıyla başlayın. İzinler davranışı değiştirir, bu yüzden her rol için bir hesap tutun ve açıkça adlandırın (Admin QA, Manager QA, Agent QA, Viewer QA). Eğer arayüzde mevcut rol görünüyorsa bunu gösterin ki inceleyiciler doğru erişimi test ettiklerini onaylasın.

Sonra test verisinin nerede yaşadığını ve nasıl sıfırlanacağını belirleyin. İnceleyicilerin neyi güvenle düzenleyebileceğini, "atıl" kayıtlar kullanıp kullanmayacaklarını ve test koşusundan sonra ne olacağını bilmeleri gerekir. AppMaster’da geliştiriyorsanız sıfırlama yöntemini kontrol listesi maddesinin içine ekleyin (manuel temizleme, zamanlanmış sıfırlama veya temel veri setinin klonlanması).

Gerekli temel bilgileri tek bir yerde belgeleyin:

• Her testçi personası için test hesapları ve roller
• Temel veri setinin yeri ve son yenileme tarihi
• Sıfırlama kuralları (ne düzenlenebilir, ne asla değişmemeli ve nasıl geri alınır)
• Faydalı referanslar: kayıt ID’leri, örnek müşteri adları, örnek faturalar ve yüklenmiş dosyalar
• İade, iptal veya tırmanma gibi karmaşık durumlar için kısa notlar

Karmaşık durumlar kısa, pratik notlar hak eder. Örneğin: “İade testi Invoice ID 10482 kullanır, önce Ödendi durumda olmalı” veya “İptal bir e-posta tetikleyecek ve ardından düzenlemeyi kilitleyecek.”

Son olarak her sürüm için bir “test veri sahibi” belirleyin. Bu kişi QA sırasında soruları yanıtlar ve retestlerden sonra verinin sıfırlandığını onaylar. Bu, onayların üretim davranışıyla artık eşleşmeyen eski verilere dayanmasını önler.

“QA için hazır”dan “deploy için hazır”a adım adım iş akışı

Bir onay akışı, herkesin sıradaki adımı ve sonuçların nereye gideceğini bildiğinde çalışır. Amaç QA’ye tek, net bir devretme, yapılandırılmış geri bildirim ve anlamlı tek bir “evet”tir.

1. Geliştirici bir sürüm adayı oluşturur ve kapsamı dondurur. QA sürümü olarak işaretleyin (takip sisteminde bir not bile olsa). Kontrol listesini ekleyin. Nelerin değiştiğini, nelerin kapsam dışında olduğunu ve test ortamının nerede olduğunu yazın.

2. İnceleyiciler atanmış hesaplar ve verilerle test eder. Her inceleyici bir dilimi (izinler, ana akışlar, kenar durumlar) alır ve kararlaştırılan girişlerle test eder. Eğer uygulamanızda Admin ve Agent gibi roller varsa, her rol kendi hesabıyla test edilmeli; ortak giriş paylaşılmamalıdır.

3. Sonuçlar geç/kal ve kısa kanıtla kaydedilir. Her bir kontrol listesi maddesi için bir satır. Bir şey başarısızsa ekran görüntüsü veya kopyalanmış hata mesajı ekleyin. "Hesabımda çalışıyor" ise hangi hesapla ve adımlarla olduğunu not edin.

4. Geliştirici sadece başarısız olanları düzeltir ve hedeflenmiş yeniden test ister. Tüm listeyi yeniden çalıştırmayın; değişiklik riskliyse istisna vardır. Hangi maddelerin yeniden test edilmesi gerektiğini ve neyi değiştirdiğinizi açıkça belirtin. AppMaster güncellemeler sonrası uygulamayı yeniden üretebilse bile, retestler etkilenen akışlara odaklanmalıdır.

5. Nihai onaylayıcı özet sonuçları gözden geçirir ve “deploy için hazır” onayını verir. Gerekli maddelerin geçtiğini, risklerin kabul edildiğini ve "düzeltmeyecek" öğelerin belgelenmiş olduğunu kontrol eder. Sonra dağıtımı açan tek onayı verir.

Her defasında aynı adımları çalıştırın. Tutarlılık onayı tartışma yerine bir alışkanlığa dönüştürür.

Bulgularla başa çıkma: sorun kaydı ve yeniden testler

Bulgular sadece anlaşılır ve göz ardı edilmesi zor olduğunda yardımcı olur. Her sorunun yaşadığı tek bir yer seçin; "Sohbette söyledim" rapor kabul etmeyin. Tek bir takip yeri ya ortak bir pano, bir formun oluşturduğu bilet veya uygulamanızın içindeki bir "Issues" tablosu olabilir.

Her sorun iki dakika içinde başka birinin yeniden üretebileceği şekilde yazılmalı. Küçük bir zorunlu şablon tutun:

• Yeniden üretme adımları (3–6 kısa adım)
• Beklenen sonuç (bir cümle)
• Gerçek sonuç (bir cümle)
• Kullanılan test verisi (kayıt ID’leri, müşteri adı, sipariş numarası veya kaydedilmiş filtre)
• Gerekirse ekran görüntüsü veya kısa kayıt

Düzeltmeler geldikçe statüleri basit ve görünür tutun. Dört durum yeterlidir: bulundu, düzeltildi, yeniden test gerekli, doğrulandı. Ana devretme noktası "düzeltildi": geliştirici neyi değiştirdiğini ve testçilerin veriyi sıfırlaması veya yeni hesap kullanıp kullanmayacağı bilgisini eklemeli.

Yeniden testler zaman kutulu ve odaklı olmalı. Önce orijinal adımları yeniden kontrol edin, sonra sık birlikte bozulan şeyler için hızlı bir yakın kontrol yapın (izinler, bildirimler, dışa aktarma). AppMaster veya benzeri platformlarda üretilen build'ler bir anda birden çok kısmı etkileyebilir; bu yüzden yakın kontrol sürprizleri yakalar.

Onayı anlamlı tutmak için bir durdurma kuralı belirleyin. Aşağıdakiler olduğunda sürümü erteleyin:

• Kritik bir akış başarısız (oturum açma, kaydetme, ödeme veya ana onay adımı)
• Aynı sorun "düzeltildi" olarak işaretlendikten sonra tekrar ortaya çıkarsa
• Veri bütünlüğü risk altındaysa (kopyalar, yanlış düzenlemeler, eksik denetim izi)
• İki veya daha fazla yüksek öncelikli sorun hâlâ "yeniden test gerekli" durumundaysa

Bu kural, umuda değil kanıta dayanarak göndermenizi sağlar.

Onayı anlamsız yapan yaygın hatalar

Onay sizi yayın sonrası ortaya çıkan sorunlardan korumalıdır. Bu hatalar sessizce onayı bir kaşe haline getirir.

Mutlu yol (happy path) test etmek en büyük tuzaktır. Gerçek kullanıcılar adımları atlar, garip değerler yapıştırır, akış ortasında sayfayı yeniler veya hata sonrası tekrar dener. Onay birkaç "ya şöyle olursa" kontrolü içermiyorsa en çok zaman kaybettiren hataları yakalayamaz.

İzinler sık yapılan bir diğer kaçırma noktasıdır. İç uygulamalarda genellikle birçok rol vardır: talep eden, yönetici, finans, destek, admin. QA tek güçlü bir hesapla yapılırsa normal kullanıcılar için ne kırıldığını asla görmezsiniz. Hızlı bir rol taraması çok şey yakalar: her rol doğru ekranları görebiliyor mu, sadece düzenlemesi gerekenleri düzenleyebiliyor mu ve erişmemesi gereken verilere erişemiyor mu?

Test verisi sessiz hatalara neden olur. Üretime benzer kayıtlar kullanılabilir ama sıfırlama kuralları yoksa her QA koşusu yavaşlar ve güvenilirliği düşer çünkü "doğru" kayıt zaten kullanılmış, statüler değişmiş ve toplamlar artık tutmaz.

Sadece geliştiricinin onayı ile yetinmeyin. Değişikliği yapan kişi ne olması gerektiğini bilir ve bilinçsizce riskli yolları atlayabilir. Nihai onay sonuçlardan sorumlu bir kişiden gelmeli, yapıdan değil.

Zayıf onaylar genelde şu görünümdedir:

• 2–3 kritik akış uçtan uca doğrulanmadan onaylama
• Rol kontrollerini atlama (en az bir non-admin hesap)
• Test kayıtları, statüler veya ödemeler için sıfırlama planı olmaması
• Kanıt olmadan "İyi görünüyor" (notlar, ekran görüntüleri, sonuçlar)
• Sessizce başarısız olabilen entegrasyonları doğrulamamak (e-posta/SMS, Stripe, Telegram)

AppMaster’da inşa ediyorsanız entegrasyonları ve rolleri birinci sınıf QA maddeleri olarak görün. Onay sonrası ekipleri en çok şaşırtan yerler burasıdır.

Yayına almadan önce hızlı kontrol listesi (onaydan 5 dakika önce)

Onaya tıklamadan hemen önce gerçek kullanıcıları en çok etkileyen şeylere son bir bakış yapın: erişim, ana akış ve insanları spamlayabilecek veya kafa karıştırabilecek her şey.

Taze bir tarayıcı oturumu (veya gizli pencere) kullanın ve şunları çalıştırın:

• Rol erişim akıl sağlığı kontrolü: her rol olarak oturum açın (temsilci, ekip lideri, admin). Doğru ekranların görünür olduğunu ve kısıtlı eylemlerin engellendiğini doğrulayın.
• Bir tam mutlu yol: ilk ekrandan başlayıp ana görevi uçtan uca bitirin.
• Doğrulama ve hata metinleri: kasıtlı olarak bir yanlış değer girin. Hatalar açık olmalı ve alanın yanında görünmeli.
• Mesajlar ve bildirimler: e-posta/SMS/Telegram veya uygulama içi bir bildirimi tetikleyin. Kanalı, alıcıyı ve iki kez tetiklenmediğini doğrulayın.
• Test veri temizliği: geride kalan sahte kayıtları silin. Sıfırlama kuralları varsa bir kez çalıştırın.

Örnek: AppMaster’da oluşturulmuş bir destek aracını onaylıyorsanız, dağıtmadan önce bir temsilci olarak giriş yapın ve admin ayarlarını göremediklerinden emin olun; bir test talebi gönderip iş akışının tamamlandığını doğrulayın; bir bildirimin doğru paylaşılan posta kutusuna ulaştığını doğrulayın; sonra raporların temiz kalması için “TEST - ignore” biletlerini kaldırın.

Örnek senaryo: destek ekibi aracına yapılan bir değişikliğin onayı

Bir destek ekibi, temsilcilerin alım formundan yeni bir bilet oluşturduğu dahili bir portal kullanıyor. Bu hafta form iki alan eklemek için güncelleniyor (Müşteri segmenti ve Aciliyet gerekçesi) ve öncelik kuralları değişiyor.

Ekip her seferinde aynı onay iş akışını uygular, küçük düzenlemeler için bile. AppMaster’da geliştirici değişikliği QA hazır hale getirir, atanan inceleyiciler kendi açılarından test eder.

İnceleyiciler ve odak alanları:

• Geliştirici (Nina): form yerleşimi, alan doğrulamaları, bilet kaydının kaydedilmesi
• Destek lideri inceleyicisi (Marco): yeni alanların temsilcilerin iş akışına uyumu ve ekstra tıklama eklememesi
• Operasyon inceleyicisi (Priya): raporlama ve yönlendirme kuralları (kuyruk ataması, öncelik, SLA zamanlayıcıları)
• IT/güvenlik inceleyicisi (Sam): rol erişimi (temsilci vs süpervizör) ve hassas alan maruziyeti
• Nihai onaylayıcı (Elena): kapsamı doğrular, sonuçları gözden geçirir ve “deploy için hazır” onayını verir

Herkes aynı test kurulumunu kullanır ki sonuçlar karşılaştırılabilir olsun:

• Test hesapları: agent_01, agent_02, supervisor_01 ve salt okunur bir denetçi
• Örnek biletler: “Şifre sıfırlama”, “İade talebi”, “VIP kesinti” ve doğrulama testi için boş bir bilet
• Sıfırlama kuralı: her koşudan sonra test biletlerini sil ve varsayılan yönlendirmeyi baseline'a geri yükle

Test sırasında Priya bir hata bulur: "VIP" segmenti seçildiğinde önceliğin otomatik olarak P1 olması gerekirken bilet P3 olarak kalmaktadır. Bunu kullandığı tam bilet adıyla (“VIP outage”), beklenen sonuç, gerçek sonuç ve kaydedilmiş ekran görüntüsüyle bildirir.

Nina iş akışı kuralını düzeltir, QA ortamına dağıtır ve Priya sadece başarısız olan kontrolleri artı bir yakın kontrolü (SLA zamanlayıcısının başlaması) yeniden çalıştırır. Retest geçtikten sonra Elena kontrol listesini gözden geçirir, tüm maddelerin işaretlendiğini doğrular ve sürümü “deploy için hazır” olarak işaretler.

Sonraki adımlar: iş akışını tekrarlanabilir ve kolay çalıştırılır hale getirin

Bir onay süreci sadece insanlar her seferinde aynı şekilde çalıştırabiliyorsa yardımcı olur. Her iç uygulama değişikliği için yeniden kullandığınız bir kontrol listesi şablonuyla başlayın. 2–3 sürümden sonra eksik kalanları ekleyerek geliştirin.

Şablonu kısa ama tutarlı tutun. Her sürüm için baştan yazmayın. Sürüm-spesifik detayları (ne değişti, nerede test edilecek, hangi hesaplar) değiştirin; geri kalan sabit kalsın.

Süreci takımlar arasında tekrarlanabilir kılmak için birkaç temel standardı belirleyin: kim “QA için hazır” diyebilir, kim onaylayabilir (ve kimin yedeği var), bulgular nerede kaydedilir, ne “engelleme” sayılır vs. ve test verisi nasıl sıfırlanır.

İş akışını sohbetler, dökümanlar ve elektronik tablolar arasında dağıtmayın. Süreç tek bir yerde yaşadığında durum peşinde koşmaya daha az zaman harcarsınız ve gerçek sorunları düzeltmeye daha çok zaman kalır. Basit bir seçenek, her sürümü bir kayıt olarak saklayan, inceleyicileri atayan, kontrol listesini tutan ve onay eylemiyle sürümü “deploy için hazır”a çevirebilen küçük bir dahili “QA Onay” uygulamasıdır.

Zaten AppMaster ile iç araçlar geliştiriyorsanız, aynı platform onay uygulamasını diğer sistemlerinizle yan yana barındırabilir; roller (geliştirici, inceleyici, onaylayıcı), bir kontrol listesi formu ve sürümü "deploy için hazır" yapan bir onay eylemi içerebilir. AppMaster (appmaster.io) tam backend, web ve native mobil uygulamalar üretecek şekilde tasarlanmıştır; QA süreciniz operasyon araçlarınızın içinde yaşaması gerektiğinde bu işe yarayabilir.

10 dakikalık bir yayın sonrası değerlendirme planlayın ve tek bir soru sorun: "Son sürprizi engelleyecek olan kontrol listesi maddesi hangisiydi?" Bunu ekleyin, sonraki iki sürümde deneyin ve geliştirmeye devam edin.