SAP testi: türler, aşamalar ve sorumlular

SAP testi, yapılandırılmış bir SAP sisteminin iş süreçlerinizi sizin verilerinizle ve sizin hacimlerinizde doğru çalıştırdığını, canlıya geçişten önce ve sonrasında her değişiklikte kanıtlama işidir. Bir S/4HANA programında altı test türünü kapsar: birim testi, sistem entegrasyon testi (SIT), kullanıcı kabul testi (UAT), regresyon testi, performans testi ve cutover provası.

Her tür farklı bir soruyu yanıtlar ve hiçbiri bir diğerinin yerini tutmaz. Deneyimime göre test, program eforunun yaklaşık yüzde 35'ini alır. Bu yüzden geliştirmenin sonuna sıkıştırılmış birkaç hafta yerine kendi planını, bütçesini ve sorumlularını hak eder.

Bu sayfa genel bakıştır. Her türün kendi rehberi var; bağlantıları aşağıdaki bölümlerde.

Bir SAP sistemi; yapılandırma, ana veriler, özel kod ve arayüzlerin birlikte çalışmasıdır. Bir yerdeki değişiklik başka bir yerdeki süreci bozabilir, çoğu zaman da kimsenin dokunmadığı bir modülde.

SAP testinin ekranlar yerine iş süreçleri etrafında kurgulanmasının nedeni budur. Order to cash, procure to pay ve record to report süreçleri birden fazla modülü keser ve tek bir işlemde duran bir test çok az şey kanıtlar.

Test canlıya geçişte de bitmez. Destek değişiklikleri, SAP sürümleri ve yeni yaygınlaştırmalar sistemi değiştirir; dolayısıyla aynı disiplin Run aşamasında da sürer.

Bir S/4HANA programında planladığım altı tür bunlar. Tablo, her birinin neyi kanıtladığını, ne zaman çalıştığını ve kimin sorumluluğunda olması gerektiğini gösteriyor.

Test türü	Neyi kanıtlar	SAP Activate içindeki yeri	Sorumlusu
Birim testi	Her yapılandırma öğesi, program veya geliştirme tek başına çalışır	Realize, her geliştirme sprintinin içinde	Fonksiyonel ve teknik danışmanlar
Sistem entegrasyon testi (SIT)	Süreçler gerçekçi verilerle modüller ve arayüzler boyunca baştan sona çalışır	Realize, geliştirme istikrar kazandıktan sonra turlar halinde	Program test lideri, süreç sahipleriyle birlikte
Kullanıcı kabul testi (UAT)	İş birimi gerçek senaryolarını sistemde çalıştırabilir	Realize'ın sonu, Deploy'dan önce	İş birimi
Regresyon testi	Daha önce çalışan şey bir değişiklikten sonra da çalışır	Realize'dan itibaren, ardından Run'da her sürümde	Test lideri, hacmin gerektirdiği yerde otomasyonla
Performans testi	Sistem aynı anda çok sayıda kullanıcıya ve üretim hacimlerine dayanır	Realize, canlıya geçişten önce tamamlanır	Program düzeyinde performans lideri, Basis ile birlikte
Cutover provası	Canlıya geçiş sırası, veri yüklemeleri ve süreler baştan sona işler	Deploy	Cutover yöneticisi

SAP Activate boyunca SAP testi

1. 01

   Prepare

   Test aracını, ekibi ve test ortamını kurun.

2. 02

   Explore

   Fit-to-standard kararları alınırken test stratejisini yazın; böylece gereksinimler test edilebilir olur.

3. 03

   Realize

   Sprintlerde birim testleri, ardından geliştirme istikrar kazanınca SIT turları, performans testi ve UAT.

4. 04

   Deploy

   Üzerinde anlaşılmış bir kontrol listesine göre cutover provaları, ardından canlıya geçiş kararı.

5. 05

   Run

   Her destek değişikliği, yükseltme ve sürüm için regresyon testi.

Birim testi

Birim testini, öğeyi geliştiren kişiler yapar. Fonksiyonel danışman bir fiyatlandırma koşulunu, geliştirici bir geliştirmeyi veya bir arayüz eşlemesini kontrol eder.

Gereklidir ama yeterli değildir. Temiz bir birim testi, o öğe sürecin geri kalanıyla buluştuğunda ne olacağı hakkında size hiçbir şey söylemez.

Sistem entegrasyon testi

SIT, programın tasarımın işe yarayıp yaramadığını öğrendiği yerdir. Bir satış siparişi teslimata, faturalamaya, muhasebeye ve raporlamaya akmalı, yol boyunca her arayüz doğru kayıt atmalıdır.

SIT'yi tek seferlik bir geçiş olarak değil, turlar halinde planlarım. İlk turda bulunan hatalar düzeltilir, sonraki tur da düzeltmelerin başka hiçbir şeyi bozmadığını kanıtlar. Turların, giriş kriterlerinin ve çıkış kriterlerinin nasıl bir araya geldiğini S/4HANA test stratejisi rehberimde anlatıyorum.

Kullanıcı kabul testi

UAT, iş biriminin sistemin canlıya geçişten sonraki çalışma biçimini desteklediğini onaylamasıdır. Sistem entegratörüne değil iş birimine aittir, çünkü sistemi yalnızca iş birimi kabul edebilir.

UAT en az 6 ila 8 hafta gerektirir. Geç biten bir geliştirmeye sığdırmak için sıkıştırırsanız, kâğıt üzerinde onay, üretimde ise sorun alırsınız. SAP kullanıcı kabul testi rehberim senaryoları, rolleri ve onayı ele alıyor.

Regresyon testi

Regresyon testi, bir değişikliğin bozduğu her şeyi yakalamak için daha önce kanıtlanmış testleri değişiklikten sonra yeniden çalıştırır. Uzun bir programda canlı destek düzeltmeleri ve proje değişiklikleri sistemde aynı anda ilerler.

Benim yaklaşımım, biri proje, biri olağan iş (BAU) için iki ayrı ortam çalıştırmaktır. Böylece canlı destek değişiklikleri ile proje değişiklikleri ayrı ayrı test edilir ve hiçbiri diğerindeki bir hatayı gizlemez. SAP regresyon testi rehberim iki ortamlı yaklaşımı, yükseltmeleri ve etki analizini ele alıyor.

Performans testi

Performans testi canlıya geçişten önce yapılmalıdır. En önemli testler eşzamanlılık testleridir: çok sayıda kullanıcının aynı anda işlem çalıştırdığı testler.

Tek bir kullanıcı için doğru çalışan bir işlem iki yüz kullanıcıda zaman aşımına uğrayabilir. Fonksiyonel test bunu size asla göstermez. BT liderleri için hazırladığım SAP performans testi rehberi yük, stres ve dayanıklılık (soak) testlerini ve kabul kriterlerinin nasıl yazılacağını ele alıyor.

Cutover provası

Cutover provası canlıya geçişin kendisini test eder: teknik adımların sırasını, veri yüklemelerini, mutabakatları ve onayları, süreleriyle birlikte. Brownfield bir dönüşümde cutover'dan önce üç deneme dönüşümü planlarım.

Üzerinde ısrar ettiğim canlıya geçiş kriteri, önceden üzerinde anlaşılmış kapsamlı bir cutover kontrol listesidir. Kontrol listesi cutover hafta sonunda yazılıyorsa, provalar gerçekte prova değildi.

Deneyimime göre test, program eforunun yaklaşık yüzde 35'ini alır. Bu rakam, testi geliştirme ile canlıya geçiş arasındaki kısa bir boşluk olarak düşünen sponsorları şaşırtır.

Efor birçok kişiye dağılır. Danışmanlar birim testlerini çalıştırır, bir test ekibi SIT'yi hazırlar ve yürütür, iş kullanıcıları UAT'yi çalıştırır, Basis ve entegrasyon ekipleri de performans testini ve cutover provalarını destekler.

Veri taşıma bunun yanında ilerler ve tek başına eforun yüzde 30 ila 40'ını alır. İkisi büyük ölçüde örtüşür, çünkü her test turu üretime benzeyen taşınmış verilere ihtiyaç duyar.

En sık gördüğüm test başarısızlığı basitçe SIT ve UAT'de yeterince test yapılmamasıdır. Geliştirme geciktiğinde turlar kısaltılır, canlıya geçiş tarihi ise yerinde kalır. Yönettiğim veya kurtardığım 21 SAP programının tamamında en büyük hata hâlâ başlangıçta düzgün planlama yapılmamasıdır ve bu genellikle ilk önce testte kendini gösterir.

Testler, üzerinde çalıştıkları veriler kadar iyidir. Kuralım maskelenmiş veridir, ama üretim düzeyinde: üretim ölçeğinde hacimler ve gerçekçi kayıtlar, kişisel ve hassas alanlar maskelenmiş olarak.

Küçük ve temiz test verileri önemli sorunları gizler. Birkaç bin kayıtta saniyeler içinde çalışan bir rapor, bir yıllık kayıtların tamamında saatlerce sürebilir.

Ortam da veri kadar önemlidir. Test ortamını Prepare'da planlayın, turlar arasında nasıl yenileneceğine karar verin, proje ve BAU değişikliklerini birbirinden ayrı tutun. SAP test verisi yönetimi rehberim kopyaları, maskelemeyi ve seçici test verilerini ele alıyor.

Otomasyon konusundaki kuralım basit. Kapsamlı ve tekrar tekrar test edilmesi gereken çok sayıda test senaryosu varsa otomatikleştirin. Bunun altında manuel test yeterlidir.

Otomasyonun ilk geri dönüşü genellikle regresyonda olur, çünkü aynı testler her değişiklikten sonra çalışır. UAT büyük ölçüde manuel kalır, çünkü amacı bir betiğin değil, bir iş kullanıcısının değerlendirmesidir.

Erken karar vermenin pratik bir nedeni var. Otomatik testlerin oluşturulması ve bakımı zaman alır; bu yüzden ancak çok kez çalıştıklarında kendilerini amorti ederler. SAP test otomasyonu rehberim nereden başlanacağını ve otomasyonun ne zaman karşılığını verdiğini ele alıyor.

Araçlar üç gruba ayrılır: test yönetimi, fonksiyonel otomasyon ve performans testi. Yönettiğim veya birlikte çalıştığım ekipler Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath ve LoadRunner kullandı.

Her grubun ne yaptığı ve içindeki ürünler şöyle:

Araç grubu	Ne yapar	Ekiplerin sık kullandığı ürünler
Test yönetimi	Test planları, test senaryoları, yürütme kayıtları, hatalar ve gereksinimlere izlenebilirlik	SAP Cloud ALM, SAP Solution Manager, Panaya
Fonksiyonel test otomasyonu	SAP ve SAP dışı uygulamalarda betikli veya model tabanlı testler çalıştırır	Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft, UiPath
Performans testi	Çok sayıda eşzamanlı kullanıcıyı ve üretim hacimlerini simüle eder	OpenText LoadRunner, artık OpenText Professional Performance Engineering adıyla satılıyor

Seçim yapmadan önce bilmeye değer birkaç ürün bilgisi var.

1. SAP Cloud ALM, SAP Enterprise Support'a veya Enterprise Support, cloud editions içeren bir bulut aboneliğine sahip müşteriler için dahildir (SAP Support). Test yönetimi; test hazırlığını, test planlarını ve yürütmeyi, UAT için manuel test senaryoları da dahil olmak üzere kapsar (SAP Learning).
2. SAP Solution Manager 7.2'nin ana bakım dönemi 2027 sonunda sona eriyor; test paketi de dahil olmak üzere işlevlerin bir bölümü için 2030 sonuna kadar isteğe bağlı uzatılmış bakım var (SAP Support).
3. SAP Test Automation by Tricentis, SAP'nin yeniden sattığı, SAP Cloud ALM ile entegre ve SAP ile üçüncü taraf sistemler için geliştirilmiş otomasyon ürünüdür (SAP).
4. LoadRunner bir OpenText ürünüdür. LoadRunner Professional'ın adı artık OpenText Professional Performance Engineering'dir ve SAP GUI ile SAP Web protokollerini destekler (OpenText).

Yeni bir programa başlıyorsanız test yönetimini Solution Manager yerine Cloud ALM'de planlayın. Daha ayrıntılı bir karşılaştırma için SAP test araçları rehberimi okuyun.

SAP Cloud ERP public edition'da (S/4HANA Cloud Public Edition) SAP her müşteriyi kendi takvimine göre yükseltir. SAP Learning, yükseltmelerin altı ayda bir, şu anda şubat ve ağustos aylarında yapıldığını, aradaki dönemde ise yeni özelliklerin aylık olarak sunulduğunu belirtiyor (SAP Learning).

Yükseltme tarihini siz seçmezsiniz; dolayısıyla regresyon testi bir proje olmaktan çıkar, takvimde sabit bir kalem haline gelir. Public cloud bir sistemde regresyonu erkenden otomatikleştirmenin en güçlü gerekçesi budur.

Private cloud ve on-premise ortamlarda yükseltmelerin zamanlamasını siz kontrol edersiniz. Yine de her biri, değişikliğin dokunduğu süreçlere göre boyutlandırılmış bir regresyon döngüsü gerektirir.

Her şeyden önce testi, kendi sahibi ve bütçesi olan, eforun yaklaşık üçte biri olarak boyutlandırılmış bir iş akışı olarak plana koyun. Ardından UAT için iş birimi sahibini belirleyin ve geliştirme onu sıkıştırmadan önce, şimdiden takvimde 6 ila 8 hafta ayırın.

Test sonuçlarını ölçülebilir çıkış kriterleriyle go/no-go kararlarınıza bağlayın. SAP kalite kapıları rehberim bunun nasıl yapılacağını gösteriyor. Programınız zaten sorun yaşıyorsa, SAP programı kurtarma notlarım önce neyin düzeltilmesi gerektiğini ele alıyor.

Bir test stratejisine veya bir canlıya geçiş kararına bağımsız bir gözle bakılmasını istiyorsanız, kurumlara bu konuda yardımcı oluyorum. Bana buradan ulaşabilirsiniz.

SAP testi nedir?

SAP testi, yapılandırılmış bir SAP sisteminin iş süreçlerinizi sizin verilerinizle ve sizin hacimlerinizde doğru çalıştırdığını kanıtlar. Bir S/4HANA programında birim testi, sistem entegrasyon testi, kullanıcı kabul testi, regresyon testi, performans testi ve cutover provasını içerir. Canlıya geçişten sonra da her destek değişikliği ve sürüm için devam eder.

SAP test türleri nelerdir?

Altı ana tür birim testi, sistem entegrasyon testi (SIT), kullanıcı kabul testi (UAT), regresyon testi, performans testi ve cutover provasıdır. Birim testleri tek tek öğeleri, SIT modüller ve arayüzler boyunca süreçlerin tamamını kontrol eder, UAT ise iş biriminin sistemi kabul etmesidir. Regresyon, performans testi ve cutover provası; değişikliklere, yüke ve canlıya geçişin kendisine karşı koruma sağlar.

SAP kullanıcı kabul testi ne kadar sürer?

UAT için en az 6 ila 8 hafta planlayın. Sahibi iş birimi olmalı; gerçek senaryolarını çalıştırmalı ve onayı vermelidir. UAT ve SIT'de yeterince test yapılmaması, en sık gördüğüm test başarısızlığıdır.

Bir SAP projesinin ne kadarı testtir?

Deneyimime göre test, program eforunun yaklaşık yüzde 35'ini alır. Bu; birim testlerinin, SIT turlarının, UAT'nin, regresyonun, performans testinin ve cutover provalarının hazırlanmasını ve yürütülmesini kapsar. Veri taşıma bunun yanında ilerler ve her test turu için üretime benzer veri gerektirir.

SAP testi otomatikleştirilmeli mi?

Kapsamlı ve tekrar tekrar test edilmesi gereken çok sayıda test senaryonuz olduğunda otomatikleştirin; bu genellikle regresyon anlamına gelir. Bunun altında manuel test yeterlidir. UAT büyük ölçüde manuel kalır, çünkü amacı iş biriminin değerlendirmesidir.

SAP testi için hangi araç kullanılır?

Programların çoğu bir test yönetimi aracını bir otomasyon aracı ve bir performans testi aracıyla birleştirir. Yaygın tercihler test yönetimi için SAP Cloud ALM veya Solution Manager; otomasyon için Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft veya UiPath; performans için ise OpenText LoadRunner'dır. Solution Manager'ın ana bakım dönemi 2027'de sona erdiği için yeni programlar Cloud ALM üzerine plan yapmalıdır.