ERP ve MES Uygulamaları İçin Kurulum Öncesi Test Süreçlerinde İki Ortamlı ve Katmanlı Bir Test Yaklaşımının Tasarımı ve Değerlendirilmesi
Anıl YILMAZ
Özet
ERP (Kurumsal Kaynak Planlama) ve MES (Üretim Yürütme Sistemi) çözümleri kurumsal süreçlerin dijital dönüşümünde kritik roller üstlenir. Müşteri sunucusuna kurulum öncesinde test stratejileri, yalnızca öngörülebilir hatalara değil öngörülemez durumlara da hazırlıklı olmalıdır. Bu yazı, ERP/MES yazılımlarında kuruluma hazırlık aşamasında uygulanabilecek test süreçlerini ayrıntılı biçimde incelemekte; öngörülebilir ve öngörülemez hata sınıflandırması, iki cihazlı test yaklaşımı, kaos mühendisliği prensipleri, ortam izolasyonu ve risk analizine dayalı bir test stratejisi önermektedir. Ayrıca kurumsal BT yönetimi bağlamında bu yaklaşımın değerini ve bir vaka çalışması örneğini tartışmaktadır.
1. Giriş
ERP ve MES sistemleri, kurumsal kaynak yönetiminden üretim takibine kadar geniş bir yelpazede kritik iş süreçlerini entegre eder. Bu sistemler, yüksek maliyetli projelerle kurulur, uzun süre kullanılmaları hedeflenir ve iş süreçlerine gömülü hale gelir. Başarısız bir kurulum yalnızca doğrudan maddi kayıplara değil, üretim durması, müşteri memnuniyetinin azalması ve marka itibarının zedelenmesi gibi dolaylı zararlara da yol açabilir.
Kurulumdan önce yürütülecek testlerin kapsamlı olması, yazılımın hem öngörülebilir hem de öngörülemez hatalara karşı dirençli olmasını sağlar. Ne yazık ki, pek çok projede test süreçleri yalnızca “öngörülebilir” işlevsel hatalara odaklanır ve altyapı, donanım veya ağ arızalarından kaynaklanan “öngörülemez” senaryolar yeterince test edilmez.
Bu makale, test süreçlerinde hem öngörülebilir hem de öngörülemez senaryoların kapsamlı biçimde nasıl ele alınabileceğini ve iki cihazlı bir test ortamının bu hedefe nasıl hizmet edebileceğini incelemektedir.
2. ERP ve MES Sistemlerinde Test Süreçlerinin Yeri ve Önemi
2.1. ERP/MES Sistemlerinin Kritik Özellikleri
- Çok modüllü yapı
- Farklı donanım ve yazılım bileşenleriyle entegrasyon
- Müşteriye özel özelleştirmeler
- Kritik üretim süreçleri ile doğrudan bağlantı
Bu özellikler, test süreçlerini diğer yazılım projelerine göre daha karmaşık kılar (Somers & Nelson, 2004).
2.2. Test Süreçlerinin Hedefleri
- Doğrulama(Verification) ve Geçerleme(Validation): Sistemin tasarlandığı gibi çalıştığını göstermek
- Risk azaltma: Canlıya geçişte felaket senaryolarını önlemek
- Müşteri güveni oluşturma: Kurulum öncesinde kabul testlerini geçmek
- Maliyet kontrolü: Sonradan yapılacak düzeltme maliyetlerini düşürmek
IEEE 829 standardı (2008) yazılım test dökümantasyonu için bu hedeflerin açıkça belirtilmesini zorunlu kılar.
3. Öngörülebilir ve Öngörülemez Senaryoların Ayrıntılı Sınıflandırılması
3.1. Öngörülebilir Senaryolar
- Kullanıcı giriş hataları (yanlış formatta veri, boş alanlar)
- Yanlış parametre ayarları
- Versiyon uyuşmazlıkları
- Uyumlu olmayan konfigürasyon dosyaları
- Yanlış kullanıcı rolü veya yetkisi
Bu senaryolar, işlevsel testler, regresyon testleri ve kullanıcı kabul testleri kapsamında doğrulanır.
3.2. Öngörülemez Senaryolar
- Donanım hatası: Disk arızası, bellek hatası
- Ağ kesintisi veya yüksek gecikme
- Elektrik kesintisi veya ani restart
- İşletim sistemi güncellemesi sonrası uyumsuzluk
- Veritabanı kilitlenmesi veya bozulması
- Sunucu aşırı yüklenmesi
- Donanım firmware güncellemeleriyle oluşabilecek sürpriz hatalar
Öngörülemez senaryolar, test mühendisliği literatüründe “fault injection”, “chaos engineering” ve “resilience testing” kavramlarıyla incelenir.
4. Test Ortamı Yönetimi: İki Cihazlı Yaklaşımın Kuramsal Temelleri
4.1. Test Ortamı İzolasyonu
ISO/IEC/IEEE 29119 standardı, test ortamlarının birbirinden bağımsız tutulmasını önerir. Çünkü:
- Test ortamına yapılan riskli müdahaleler üretim veya satış ortamını etkilememelidir.
- Öngörülemez hata senaryoları ana ortamı kirletebilir.
4.2. İki Cihazlı Test Modeli
Cihaz A (Satış Öncesi/Kabul Test Ortamı):
- Temiz, stabil
- Müşteriye gösterim amaçlı
- Kullanıcı eğitimi
- Kabul testi
Cihaz B (Öngörülebilir ve Öngörülemez Senaryo Test Ortamı):
- Negatif testler
- Donanım, ağ, veri bozulması simülasyonları
- Performans stres testleri
- Kaos mühendisliği senaryoları
4.3. Teorik Dayanak
- Geçiş Ortamı ile Test Ortamı Ayrımı (Staging vs Testing Separation): Staging ortamı müşteriye veya canlıya birebir benzeyen ama değişiklik yapılmayan ortamdır. Testing ortamı ise riskli deneyler içindir.
- Kaos Mühendisliği (Chaos Engineering): Sistem davranışının bozulma altında da gözlemlenmesi.
- Hata Enjeksiyonu (Fault Injection): Hata durumlarını kontrollü biçimde üretmek.
5. İki Cihazlı Yaklaşımın BT Yönetiminde Katkısı
Kurumsal BT yönetimi açısından iki cihazlı yaklaşım şunları sağlar:
- Risk ayrıştırması
- İş sürekliliği koruması
- Rolleri ayırarak uzmanlaşma
- Süreçlerin denetlenebilirliği
- Regülasyon ve standart uyumu (ISO 27001, ISO/IEC 29119)
Örneğin bir firmada satış ekipleri yalnızca Cihaz A ortamına erişirken, QA mühendisleri Cihaz B ortamında deneysel testler yapabilir. Böylece müşteri gösterimleri sırasında beklenmeyen hatalarla karşılaşma riski azalır.
6. Uygulanabilir Senaryo Örnekleri
6.1. Cihaz A için Senaryolar
- Tam müşteri veri seti yükleme
- Canlıya benzer kullanıcı rollerini oluşturma
- İş süreci uçtan uca test akışı
- Müşteri temsilcisiyle kullanıcı kabul testi (UAT)
6.2. Cihaz B için Senaryolar
- Ağ bağlantısını koparıp yeniden başlatma
- Veritabanını bozuk dump ile yükleme
- Ağ gecikmesini artırma (latency simulation)
- Disk alanını yapay olarak doldurma
- RAM kullanımını sınırlayarak aşırı yük testi
- Donanım sıcaklık artışını simüle eden yazılım araçları
- Veri tabanı transaction lock oluşturma
7. Risk Analizi Tablosu
Risk Senaryosu | Etkisi | Cihaz A | Cihaz B |
Ağ kopması | Sistem bağlantısız kalır | Hayır | Evet |
Donanım arızası | Veri kaybı, sistem çökmesi | Hayır | Evet |
Yanlış kullanıcı rolü | İşlev engellenir | Evet | Evet |
Bozuk veri girişi | Veri bütünlüğü bozulur | Evet | Evet |
Yüksek işlem hacmi | Performans düşer | Hayır | Evet |
Donanım güncelleme sonrası hata | Sistem açılmaz | Hayır | Evet |
8. Önerilen Uygulama Yapısı
Kurulum öncesi test stratejisinin iki ayrı ortam veya cihaz üzerinde planlanması aşağıdaki öneri çerçevesinde tasarlanabilir:
Müşteri Benzeri Ortam (Cihaz A):
- Tek tip donanım yapılandırması kullanılması önerilir.
- Stabil ve temiz bir veri seti yüklenerek gerçek müşteri kullanımına yakın senaryoların çalıştırılması sağlanmalıdır.
- Kullanıcı eğitimi için uygun bir ortam olarak yapılandırılmalı ve müşteri kabul testleri burada yürütülmelidir.
Hata Senaryoları ve Dayanıklılık Test Ortamı (Cihaz B):
- Farklı donanım yapılandırmalarının oluşturulması önerilir.
- Ağ trafiğini bozacak senaryoların ve yüksek gecikme koşullarının simülasyonu yapılmalıdır.
- Disk arızası veya donanım hatası gibi durumlar için yazılım tabanlı arıza simülatörleri kullanılabilir.
- Farklı veritabanı motorları veya sürümleri ile uyumluluk ve beklenmeyen hata senaryoları test edilmelidir
9. Sonuç ve Öneriler
ERP ve MES sistemlerinin kurulum öncesi test süreçleri hem öngörülebilir hem de öngörülemez durumları kapsayacak şekilde tasarlanmalıdır. Önerilen iki cihazlı yaklaşım:
- Satış öncesi temiz gösterim ortamını korur.
- Negatif ve kaotik testleri izole biçimde gerçekleştirir.
- Kurumsal BT yönetimine uyumlu, denetlenebilir bir süreç sağlar.
Firmalar test stratejilerini ISO/IEC/IEEE standartlarına uygun hale getirerek ve kaos mühendisliği prensiplerini benimseyerek müşteri memnuniyetini ve sistem sürekliliğini önemli ölçüde artırabilirler.
Anıl YILMAZ
Kaynakça:
- IEEE Standard for Software and System Test Documentation (IEEE 829-2008). IEEE.
- ISO/IEC/IEEE 29119-2:2013. Software and systems engineering — Software testing — Part 2: Test processes.
- Somers, T. M., & Nelson, K. (2004). A taxonomy of players and activities across the ERP project life cycle. Information & Management, 41(3), 257–278.
- Monk, E., & Wagner, B. (2012). Concepts in Enterprise Resource Planning. Cengage Learning.
- Bass, L., Weber, I., & Zhu, L. (2015). DevOps: A Software Architect’s Perspective. Addison-Wesley.
- Fowler, M. (2012). Continuous Integration and Staging. Retrieved from https://martinfowler.com.
- Basiri, A., et al. (2016). Chaos engineering. IEEE Software, 33(3), 35–41.