Piyasa yapıcıların kotasyonları SEAQ adı verilen bir sistem üzerinden elektronik olarak dağıtılıyordu. Telefon ve faks içeren hesaplara alım satım ve alım satım sonrası tahsisler.

Tradepoint pazarı ve sistemi tamamen farklıydı. Kotasyon yerine kesin alış ve satış emirleri, tüm üyelerin anında görebileceği bir emir defterine verilir. Kitaptaki bir emrin üzerine tıklayarak ve ticaret yapma niyetini onaylayarak bir ticaret gerçekleştirilir. Hesaplaşmaya yönelik tüm ticaret sonrası hazırlıklar da tamamen elektroniktir.

Piyasa düzenleyici endişeleri

Tradepoint’in ilk gelişimi boyunca, finansal hizmetler sektörü düzenleyicileri, piyasanın elektronik doğası ve Tradepoint’in piyasadaki tüm oyuncular için eşit bir oyun alanı sağlama yeteneği konusunda son derece endişeliydi. “Eşit oyun alanı” birkaç temel teknik soruna çevrildi:

• değişken sistem performansı nedeniyle hiçbir kullanıcı dezavantajlı duruma düşmez;
• sistem tüm katılımcılara eşit olarak açık olmalıdır;
• yazılım, alım satımı engelleyen veya yanlış alım satımlara neden olan hatalar içermemelidir.

Bunlar hemen hemen her bilgisayar sisteminin gereksinimleri olacaktır. Ancak yeni başlayan bir elektronik finans piyasası söz konusu olduğunda, herhangi bir hatanın piyasanın istikrarı üzerinde feci bir etkisi olabilir.

Ticari müşterilerini kaybedebilir, bir ticaret hatasını düzeltmek için hayal bile edilemeyecek meblağlara mal olabilir ve en sonunda işletmenin bir borsa olarak lisansını kaybedebilir. Bu olmadan, hiçbir iş olmazdı. Öyleyse, Tradepoint geliştiricilerinin en başından beri testlere sağlıklı bir saygı duymalarına şaşmamalıdır.

Sistem ve testler

Sistem VCT’ye dayalı olsa da, büyük ölçüde Tradepoint için yeniden yazıldı. Kapsam hakkında bir fikir vermek için, başlangıçta yaklaşık yedi milyon satırlık kaynak kodu vardı. Yaşamaya giden yeniden yazmaya kırk sekiz kişi-ay girdi. Sistemin son birkaç yılda önemli ölçüde değişmeyen yapısı. Ancak çeşitli ürünler, özellikle iş istasyonları ve merkezi ticaret sistemi sürekli olarak yükseltildi.

Piyasanın faaliyete geçmesinden beş ay sonra Tradepoint’e test yöneticisi olarak katıldım. Zaten, o zamana kadar, geliştiriciler iyileştirmelerin ilk sürümünü hazırlıyorlardı. Test kitaplığı, temel olarak işlevsel test niteliğindeki yaklaşık 1800 manuel test durumundan oluşuyordu.

Windows 3.11’deki iş istasyonlarıyla desteklenen tek platforma karşı çalıştırıldılar. İki tür API sunucusu vardı: X.25 iletişimleri yoluyla ticaret sistemine bağlanan ve yerel olarak merkezi ticaret sistemini simüle eden yerel bir ‘gösterici’ye bağlanan bir sunucu. Üç iş istasyonu uygulaması vardı. Manuel test dört kişi-hafta sürdü.

Devam Eden Geliştirme ve Test Gereksinimleri

Sistemin hem ticari hem de teknolojik nedenlerle düzenli iyileştirmelere tabi tutulacağı başından beri iyi anlaşılmıştı. Pazar yayına girer girmez, müşterilerden ve pazarlamadan gelen geri bildirimler, sürekli bir iyileştirme talepleri akışı oluşturdu.

Teknolojik açıdan, iş istasyonlarını Windows 3.11’den Windows 95, Windows NT 3.51 ve Windows NT 4.0’a taşıma ihtiyacı vardı. UNIX tabanlı ürünlerle entegrasyona izin vermek için MS Windows’a özgü DDE’den Corba’ya geçiş ihtiyacı da vardı. İlk canlı yayın sürümüne giden testin bir defaya mahsus olmadığı açıktı.

Her yeni sürüm, yeni özelliklerin test edilmesini ve geri kalanının regresyon testini gerektirecektir. Piyasanın düzenli ve adil bir şekilde işlemesini sağlamaya yönelik düzenleyici yükümlülükler yürürlükte kaldı ve yeni sürümlerin dağıtılmasındaki risk, varsa bile, orijinal geliştirmeden daha yüksekti.

Geliştirme yöneticisinin bakış açısına göre, test yükü artmaya başladı ve geliştirmeyi zorlaştırma tehlikesiyle karşı karşıya kaldı. Yeni işlevsellik, test senaryolarının sayısını otomatik olarak artıracaktı ve yeni platformlar ve sunucular, test döngülerinin sayısını çoğaltmak için ayarlandı.

Geliştirme yöneticisi, test uygulama kalitesinin ve testin genişliği ve derinliğinin iyileştirilmesi gerektiğinin de farkındaydı. Test yürütme tutarlılığını manuel olarak sağlamak zordu. Daha derin, daha kapsamlı test durumlarına ihtiyaç duyan işlevsellik alanları vardı ve sistemin performans gibi daha sistematik, tekrarlanabilir bir yaklaşıma ihtiyaç duyan tüm alanları vardı.

Bunu akılda tutarak, işlev ve performans testini otomatikleştirmeye başladık. Test otomasyonu, aynı zamanda test eforundan daha fazlasını elde etmemizi ve geçen sürede daha fazlasını yapmamızı sağlarken, test kalitesini iyileştirme konusunda bir miktar söz verdi.

Ticaret BAKANLIĞI Piyasa Gözetimi ve Denetimi YÖNETMELİĞİ
Piyasa gözetimi ve denetimi YÖNETMELİĞİ mevzuat
Sanayi ve Teknoloji Bakanlığı
Sanayi ve Teknoloji Bakanlığı Piyasa Gözetimi ve Denetimi Yönetmeliği
Piyasaya arz nedir
7223 sayılı Kanun
Yatırım Teşvik Belgesi başvuru
Piyasa Gözetimi ve Denetimi YÖNETMELİĞİ 2022

Test Otomasyonu Gereksinimleri

Test Paketlerini daha önce otomatikleştirdiğim için, bir araç seçmeden önce gereksinimlerimizi analiz etmemiz gerektiğini biliyordum.

Üç merkezi noktaya odaklandık:

• otomasyonun hedefleri – neyi başarmak istediğimizi netleştirmemiz gerekiyordu;
• geliştirme ve test süreci – sürecin otomatikleştirilmeye uygun olduğundan emin olmamız gerekiyordu;
• Otomasyonun kapsamı – aracın hangi yeteneklere sahip olması gerektiğini anlamak için.

Test kaynaklarının, test bütçesinin ve test ekibinin azaltılması kesinlikle test otomasyonunun hedefleri değildi. Amaç, kapsamlı regresyon testi sağlamak, kritik özelliklerin daha derin testlerini yapmak için kaynak sağlamak, yeni işlevlere odaklanmak ve yeni sürümlerin performans etkilerini test etmekti.

Canlı yayınlandıktan sonra ilk sürüm için manuel test kitaplığını kapsamak, geçen iki haftada dört kişi-hafta sürdü. Otomasyonun amacı, yeni platformların, yeni sunucuların ve yeni iş istasyonlarının yaygınlaşmasının yanı sıra sistemdeki işlevsel iyileştirmelerin, doğrusal olarak test etmek için geçen süreyi basitçe çoğaltmamasını sağlamaktı.

Test ekibi organizasyonu: bağımsız ekipler terk edildi. Geliştirme süreci, ortalama olarak üç aylık sürümlere ayrılmış, zaman sınırlamalı, RAD benzeri yinelemeli bir süreçti. Testin aşamaları açıkça tanımlanmıştır. Programcılar birim testi yapar; test cihazları entegrasyon ve sistem testi yapar. Otomasyon için yalnızca sistem testi hedeflenecekti. Değişikliklerin ve hataların yönetimi için zaten bir veri tabanı mevcuttu.

Test ekibi, geliştirme ekibinin bir parçasıydı. Geliştirme yöneticisi, ilk geliştirme sırasında bağımsız test ekipleriyle ilgili ders kitabını izlemiş ve daha fazla acı çekmek istemediği bir dizi ciddi dezavantajı olduğunu görmüştür. Bağımsız bir test ekibiyle, hataları bildirmek daha uzun sürüyordu, hata raporlamanın kalitesi düşüktü ve hataları düzeltmek birkaç yineleme gerektiriyordu.

Geliştiriciler ve testçiler birbirlerinin sorunlarını anlamadı ve tüm bunlar gecikmelere neden oldu. Bağımsız test uzmanlarına sahip olmak, ancak geliştirme ekibi içinde olmak daha iyi bir çözüm gibi görünüyordu. Testçilerin bir sürümün geliştirilmesine erken dahil edilmesini sağladı. Yeni testlerin planlanmasının yanı sıra betiklerin güncel tutulmasına yardımcı olan kodun ön izlemelerini alıyoruz.

Bu nedenle otomatik testin kapsamı, sistem testinin bir parçası olarak test ekibi tarafından gerçekleştirilen fonksiyonel regresyon testi olarak belirlendi. Amaç, iş istasyonlarının tekrarlanabilir test yürütmesini sağlamak için otomatikleştirmekti. “Dıştan içe” bir test stratejisi kullanılarak, iş istasyonu aracılığıyla girilen test senaryoları, iş istasyonlarını ve merkezi sistemin yeteneklerini kapsayacak şekilde tasarlanmıştır.

The post Teknoloji İle Piyasa Düzenleme first appeared on Akademi Delisi (Tez Yaptırma).