ERP yanına yazan katmanı olan işletmeler
Mevcut kurumsal sistemin yanında çalışan özel yazılımı bulunan firmalar. Ana sistem güncellendiğinde neyin bozulduğunu hızlı görebilmek, bu yapılarda doğrudan bir risk yönetimi meselesidir.
ÖZEL YAZILIM · TEST OTOMASYONU
Yazılım Test ve Kalite Otomasyonu: Bozulduğunu Müşteriden Önce Bilmek
Kritik iş akışlarınızı otomatik testlerle koruruz: kabul kriterlerinin yazılması, uçtan uca senaryolar, regresyon paketi ve sürüm öncesi otomatik koşum. Bir güncellemenin neyi bozduğu, müşteriden değil testten öğrenilir.
Bir yazılımın en pahalı hatası, üretimde ve müşteri tarafından bulunan hatadır. Ondan biraz daha ucuzu, canlıya alındıktan sonra ekip tarafından fark edilendir. En ucuzu ise değişiklik yapılırken yakalanandır. Test otomasyonu bu sıralamayı tersine çevirmeye yarayan yöntemdir; amacı hata sayısını sıfırlamak değil, hatanın bulunduğu yeri geriye çekmektir.
Uygulamada en sık karşılaşılan tablo şudur: sistem çalışır, ekip yeni bir özellik ekler, bir hafta sonra tamamen başka bir yerde bir şeyin bozulduğu anlaşılır. Bozulan yer genellikle kimsenin dokunmadığını düşündüğü yerdir. Elle test bu durumu yakalamakta zorlanır, çünkü her değişiklikten sonra tüm sistemi baştan denemek pratikte mümkün değildir. Elle test ilk kurulumda yeterlidir; sistem büyüdükçe yetersiz kalır.
Bizim yaklaşımımız kapsamlı değil seçici olmaktır. Her satırı test etmeye çalışmak, bakımı ağır ve kimsenin güvenmediği bir test yığını üretir. Bunun yerine iş açısından kritik akışlar belirlenir: sipariş girişinden faturaya, mal kabulden stok hareketine, hakediş hesabından bordro dosyasına. Bu akışlar uçtan uca test edilir; bozulduğunda gerçekten para ve itibar kaybettiren yerler korunmuş olur.
Bu işin özellikle değerli olduğu bir durum var: mevcut bir kurumsal sistemin yanına yazan katmanlar. Ana sistem güncellendiğinde ya da bir sürüm yükseltmesi yapıldığında, yanındaki katmanın neyi kaybettiğini anlamak normalde günler alır. Kritik akışlar testle korunuyorsa aynı soru dakikalar içinde cevaplanır: hangi entegrasyon çalışıyor, hangi alan değişmiş, hangi kayıt artık açılamıyor. Bu, yükseltme kararını korkuyla değil bilgiyle vermeyi sağlar.
Kimler için?
Yazılım Test ve Kalite Otomasyonu kimler için uygun?
Kendi yazılım ekibi olan şirketler
İç geliştirme yapan ama test disiplini kurulmamış ekipler. Bu ekiplerde her sürüm bir gerilim kaynağıdır ve zamanla değişiklik yapmaktan kaçınma alışkanlığı doğar.
Devraldığı yazılımı yaşatanlar
Eski bir yazılımı devralmış ve içine dokunmak zorunda kalan işletmeler. Testler burada aynı zamanda dokümantasyon işlevi görür: sistemin ne yapması gerektiğini yazıya döker.
Müşteriye yazılım teslim eden firmalar
Ürününü başka şirketlere kuran işletmeler. Farklı müşterilerde farklı yapılandırmalar çalıştığında, regresyon paketi olmadan her sürüm bir kumar haline gelir.
Ne geliştiriyoruz?
Yazılım Test ve Kalite Otomasyonu kapsamında neler yapıyoruz
| Yetenek | Ne sağlar |
|---|---|
| Kabul kriterlerinin yazılması | Bir işin ne zaman bitmiş sayılacağı yazılı hale getirilir. Test otomasyonunun ilk adımı araç değil, beklentinin netleşmesidir; kriteri yazılmamış bir davranış test edilemez ve tartışması bitmez. |
| Kritik akışların uçtan uca testi | İş açısından en pahalı akışlar baştan sona test edilir: veri girişinden çıktının doğrulanmasına kadar. Kapsam bilinçli olarak dar tutulur; geniş ve bakımsız bir test paketi, hiç test olmamasından daha zararlı olabilir. |
| Regresyon paketi | Daha önce yaşanmış hatalar teste dönüştürülür. Aynı hatanın ikinci kez çıkması engellenmiş olur ve paket zamanla sistemin gerçek hafızası haline gelir. |
| Test verisi yönetimi | Testlerin çalışacağı veri hazırlanır; her koşumda aynı başlangıç noktasından başlanması sağlanır. Canlı veriyle test edilmesi gereken durumlarda kişisel veriler maskelenir. Test verisi düzeni kurulmadığında testler kısa sürede güvenilmez hale gelir. |
| Sürüm öncesi otomatik koşum | Testler, kod değiştiğinde ve sürüm alınmadan önce otomatik çalışır; sonuç ekibe bildirilir. Elle çalıştırılan testler unutulur; otomatik koşum, disiplinin kişiye bağlı olmaktan çıkmasını sağlar. |
| Hata tekrarlanabilirliği | Bildirilen bir hatanın hangi adımlarla oluştuğu kayda geçirilir ve teste dönüştürülür. Tekrarlanamayan hata düzeltilemez; bu adım, en çok zaman kaybettiren tartışmayı ortadan kaldırır. |
Teknolojiler
Kullandığımız teknolojiler
- Uçtan uca test araçları
- Birim ve entegrasyon testleri
- API test paketleri
- Test verisi hazırlama ve maskeleme
- Sürekli entegrasyon hattı
- Raporlama ve bildirim
- Kayıt ve yeniden oynatma
- Ortam yönetimi
Süreç
Keşiften canlıya nasıl ilerliyoruz
- 01
1. Kritik akışların belirlenmesi
Hangi akışın bozulmasının en pahalı olduğunu birlikte çıkarırız. Sıralama teknik değil ticari yapılır: para, teslimat ve itibar kaybı hangi akıştan gelir. Kapsam bu sıralamanın en üstünden başlar.
- 02
2. Beklenen davranışın yazılması
Seçilen akışların ne yapması gerektiği yazılı hale getirilir. Bu adımda çoğu zaman ekip içinde farklı beklentiler olduğu ortaya çıkar; bu ayrışmanın çözülmesi tek başına değerlidir.
- 03
3. Ortam ve test verisinin hazırlanması
Testlerin koşacağı ortam kurulur, test verisi hazırlanır. Canlı veriden kopya alınıyorsa kişisel veriler maskelenir. Bu altyapı olmadan yazılan testler kısa sürede terk edilir.
- 04
4. Testlerin yazılması ve hatta bağlanması
Testler yazılır ve otomatik koşuma bağlanır. Sonuçların kime bildirileceği ve kırmızı bir sonuç geldiğinde ne yapılacağı belirlenir. Kimsenin bakmadığı bir test sonucu, olmayan testle aynıdır.
- 05
5. Ekibe devir ve alışkanlığın kurulması
Yeni bir hata çıktığında önce teste dönüştürülmesi, yeni bir özellik geldiğinde kabul kriteriyle başlanması gibi alışkanlıklar ekibe devredilir. Test otomasyonu bir kurulum değil, sürdürülen bir düzendir.
Sıkça sorulan sorular
Yazılım Test ve Kalite Otomasyonu hakkında merak edilenler
Her şeyi test edecek miyiz?
Hayır ve bunu hedeflememek gerekir. Geniş ve bakımsız bir test paketi, sürekli kırılır, kimse bakmaz ve zamanla tamamen görmezden gelinir. Bizim yaklaşımımız, iş açısından en pahalı akışları korumak ve kapsamı zaman içinde ölçülü genişletmektir. Az sayıda ama güvenilen test, çok sayıda ama güvenilmeyen testten değerlidir.
Yazılımı biz yazmadık, yine de test edilebilir mi?
Edilebilir. Kaynak koda erişim olmasa bile arayüz ve veri tarafından uçtan uca testler yazılabilir; sistemin ne yapması gerektiği dışarıdan tanımlanır. Devralınmış sistemlerde bu çalışma ayrıca değerlidir, çünkü testler aynı zamanda sistemin davranışını belgeler.
ERP'mizi güncellersek ne olacağını gösterir mi?
Kritik akışlar testle korunuyorsa büyük ölçüde evet: güncelleme bir kopya ortamda uygulanır, testler koşulur ve neyin bozulduğu kısa sürede listelenir. Bu, yükseltme kararını tahminle değil ölçümle vermeyi sağlar. Testlerin kapsamadığı alanlar için aynı güvenceyi veremeyiz ve kapsamı baştan yazılı olarak belirleriz.
Testler bakım yükü getirmez mi?
Getirir, bunu saklamıyoruz. Her test, sistem değiştiğinde güncellenmesi gereken bir varlıktır. Bu yüzden kapsamı dar ve değerli tutmak, testleri kırılgan olmayacak biçimde yazmak ve gereksizleşen testleri silmekten çekinmemek gerekir. Bakım yükünü göz ardı eden bir test yaklaşımı birkaç ay içinde çöker.
Ne zaman başlamak doğru?
En doğru zaman, sistemin ilk kritik hatasını yaşadığı andır; ikinci sırada gelen zaman ise şimdidir. Yeni bir proje başlıyorsa kabul kriterleriyle başlamak en ucuz yoldur. Mevcut ve büyük bir sistemde ise en son yaşanan üç ciddi hatayı teste dönüştürerek başlamak, hem hızlı hem ikna edici bir başlangıç olur.
Sonunda elimize ne geçer?
Yazılı kabul kriterleri; kritik akışları kapsayan uçtan uca test paketi; geçmiş hatalardan oluşan regresyon seti; tekrarlanabilir test verisi düzeni; sürüm öncesi otomatik koşum ve raporlama ile testlerin nasıl sürdürüleceğini anlatan devir dokümantasyonu. Test paketleri ve kaynak kod dahil üretilen her şey size aittir.
İletişim
Yazılım Test ve Kalite Otomasyonu projenizi konuşalım
30 dakikalık keşif görüşmesinde ihtiyacınızı dinler, özele mi yoksa hazır çözüme mi ihtiyacınız olduğunu dürüstçe söyleriz.
İlgili
İlgili sayfalar ve rehberler
DevOps ve Bulut Yazılım Devralma ve Kurtarma Uygulama Güvenliği ve Kod Denetimi Yazılım Bakım ve Destek Rehberi Kritik Akışlarınızı Konuşalım
Uygulama Güvenliği ve Kod Denetimi
Teslim edilmiş ya da devralınmış uygulamalarda güvenlik denetimi yaparız: yetkilendirme ve veri erişim hataları, kimlik doğrulama zayıflıkları, enjeksiyon riskleri, sır ve anahtar yönetimi, bağımlılık zafiyetleri. Bulguları kapatma tarafında da çalışırız.
Detay →Mimari Danışmanlık ve Teknik Borç Denetimi
Mevcut yazılım varlığınızı bağımsız olarak değerlendiririz: mimari haritası, teknik borç envanteri ve önceliklendirmesi, bağımlılık ve tedarikçi kilitlenmesi riski, ekibin çalışma biçimi ve gerçekçi bir yol haritası. Kod yazmadan yön veren bir çalışmadır.
Detay →Yazılım Ürünleştirme: Projeden Ürüne
Tek müşteri için yazılmış ve çalışan bir yazılımı satılabilir bir ürüne dönüştürürüz: çekirdek ile müşteriye özel katmanın ayrılması, konfigürasyon motoru, çok kiracılı veri izolasyonu, kurulum ve sürüm yönetimi ile abonelik altyapısı.
Detay →Tedarik Zinciri Yönetimi (SCM)
Talep ile tedariğin nerede ayrıştığını, hangi tedarikçinin termininde durduğunu ve malın şu anda hangi noktada beklediğini tek yerden görünür kılarız. Amaç yeni bir ERP kurmak değil; mevcut sistemin bilmediği zincir dışı bilgiyi toplayıp planlama kararını veriye bağlamaktır.
Detay →Satın Alma Yönetimi (PMS)
Talebin nereden geldiğini, hangi tekliflerin alındığını, kimin neyi onayladığını ve gelen faturanın siparişle örtüşüp örtüşmediğini tek bir zincirde toplarız. Satın alma kişilerin hafızasında değil sistemde yürür; her adım geriye dönük olarak gerekçesiyle birlikte okunabilir. Mevcut ERP'niz yerinde kalır.
Detay →Tedarikçi İlişkileri Yönetimi (SRM)
Tedarikçinin kim olduğunu, hangi belgesinin ne zaman dolduğunu, geçen yıl terminine ne kadar uyduğunu ve hangi fiyat anlaşmasının yürürlükte olduğunu tek kayıtta toplarız. Onaylı tedarikçi listesi bir Excel dosyası olmaktan çıkar. Tedarikçi portalı isteğe bağlı olarak aynı yapıya bağlanır.
Detay →