Test verisi F1 kalitesinde olmalı
Nasıl ki bir F1 aracı kaliteli benzin isterse, test sürecinde kullanılan test verisi de normal veriden daha kalitesiz olmamalı. Türkiye Yazılım Kalite Raporu 2016/17 sonuçları ve genel test algısı, test veri yönetimine bakış açılarını da ortaya koyuyor.
Doğu Avrupa ve Orta Doğu’nun önde gelen yazılım testi konferansı Uluslararası TestIstanbul Konferansı, 26 Nisan’da Renaissance Istanbul Polat Bosphorus Hotel’de gerçekleştirildi. ‘Türkiye Yazılım Kalite Raporu 2016/17’ sonuçlarının da açıklandığı etkinliğin açılış konuşmasını TTB (Turkish Testing Board, Yazılım Test ve Kalite Derneği) Başkanı Koray Yitmen yaptı. Yedincisi düzenlenen etkinlik ışığında sektörün de büyüdüğüne dikkat çeken Koray Yitmen, test veri yönetiminin entegrasyon sürekliliğini beraberinde getiren bir yapı olduğunu vurguladı. Yitmen, bu yapının F1 yarışları ile benzerliklerini sunumunda örnekledi.
F1’de amaç pilotların hızlı ve kaza yapmadan pisti tamamlaması. Pit-stop molasında da ekibin çalışma hızı önemli. Aynı şeyi yazılım testi ile ilişkilendirdiğimizde, hızlı, güvenilir ilerleme ile yüksek kaliteli işi, var olan sistemi bozmadan çıkarma gerekliliği öne çıkıyor. Yani ufak bir kod değişiminin canlıya geçmesi de hızlı olmalı. “F1 ortamını yazılıma, pit-stop’u da süreklliği olan entegrasyon, değişikliklerle kodun çalışır hale gelmesi olarak nitelendirebiliriz” diyen, “Ama bu da yetmez” diye ekleyen Koray Yitmen’in belirttiği gibi, arabanın yakıtı, yazılımda da kaliteli veri demek. Nasıl F1 aracı kaliteli benzin isterse, test sürecinde kullanılan test verisi de normal veriden daha kalitesiz olmamalı.
Test verisi yönetim süreçlerinde veri tanımlamak, ihtiyaç olan verileri belirlemek, bu verileri hangi veri tabanından çekmek gerektiğini saptamak, güvenlik için maskeleme yapmak, bu sonucu test ortamına dahil etmek, ama bunu da doğrulamak şart. Yitmen’in dikkat çektiği gibi, test verisi sürekli değişiyor ve bunu sürekli güncellemek, süreçleri de otomatize etmek şart. “Yazılımın kalitesi teste, testin kalitesi de test verisine bağlı” diyen Koray Yitmen’e göre, test veri yönetiminde sıkıntılar, ama aynı zamanda boşluk ve fırsatlar olduğu da unutulmamalı. “Araştırmayı özellikle yeni mezunların okumasını tavsiye ederim” diyen Koray Yitmen, eklemeden geçmedi: “kinci sınıfa geçmiş, ayrıca üçüncü ve dördüncü sınıftaki öğrencilere burs vermeye başladık ve konuyla ilgili bilgileri www.turkishtestingboard.org sitemize koyduk. Burada iki kriterimiz var: Kişinin ihtiyaç sahibi olması ve başarılı bir öğrenci olarak 3.0 ve üstü not ortalaması.”
SANALLAŞTIRMA, GÜVENLİK, FARKINDALIK
Koray Yitmen, sunumunun ardından gerek Türkiye Yazılım Kalite Raporu 2016/17 sonuçları ve genel olarak test algısı, test veri yönetimine bakışa dair sorularımızı yanıtladı:
Test veri yönetiminde nasıl bir farkındalık seviyesi var?
Raporda da görüldüğü gibi düşük. Sorduğumuz bir sorumuz var: Test veri yönetiminizin kalitesini nasıl buluyorsunuz? Tüm yanıtlara bakınca diyebiliriz ki, sektörde yüzde 80’lik bir kesim test veri yönetiminde problem yaşıyor. Bu da, bu alanda test uzmanları, BT profesyonelleri, yeni mezunlar için çok büyük fırsatlar olduğunu gösteriyor. Biz de bunu değerlendirmelerini hep öneriyoruz.
Peki şirketlerin farkındalığı ışığında, nasıl bir değerlendirme yapılabilir?
Bir farkındalık oluşmaya başladı ve sektör bazında öne çıkanlar var. Bazı sektörlerde ise test algısı emekleme sürecinde. Bu nedenle öncelikle teste gönül vermiş olmanız, kaliteye önem vermeniz, bir testin genel konseptine hakim olmanız lazım. Tüm bunların içinde test veri ile ilgili çalışmalar var. Örneğin hangi test verisinin size gerektiğini bilmelisiniz. Sonuçta bütün veriyi canlıdan alıp test ortamına koymanız anlamlı değil. Çünkü test yaparken hepsine ihtiyacınız olmuyor. Burada ihtiyacı iyi tespit edebilmeniz lazım. Bunun için de analiz yetkinlikleri gerek. İkinci tarafta, bu analizin yani ihtiyacın karşılığının nerede olduğunu bulmak. Yani kendi veri tabanlarımda bu ihtiyacın karşılığını nereden çekebileceğini belirlemek gerek. Burada da yaptıkları analizi bir şekilde karşılaştıracaklar. Sonraki en önemli kısım ise bu veriyi çekerken maskeleme yöntemleri. Bunun için şifreleme yöntemleri, ‘shuffle’ dediğimiz yer değiştirme veya bilgiyi bölerek sadece gerekli olan kısmını almak gibi yöntemler var.
Bunu nasıl örnekleyebiliriz?
Örneğin sağlık sektörü ile ilgili bir araştırma yapacaksanız, kişilerin adreslerine değil, sağlık bilgilerine ihtiyacınız var. Ama bir veri tabanına veya bir hastaneye eriştiğiniz zaman, bu ayrıştırmayı yapmadan size tüm bilgileri verebilirler. Test uzmanı bu yönüyle üstün analitik yeteneklere, temel veri tabanı bilgilerine sahip olmalı. Bunun üstüne, maskeleme teknikleri hakkında da bilgi sahibi olursa, sektörün ihtiyacını da tam anlamıyla karşılar.
Yanlış veri nelere yol açabiliyor?
Bu aslında yanlış teşhis koymak gibi. Bu nedenle veri tarafında tutarlılık, güncel, tutarlı ve doğrulanmış olması şart. Aksi halde kirli veri ile karşı karşıya kalırsınız. Kontrol edilmemiş bu veri ile doğru işlem yaptığınızı sanırsınız, ama sonuç tepeden tırnağa yanlış olur. Bu nedenle şirketlerin testten önce kendi verilerinin doğruluğu, güncelliği, tekilliği gibi unsurlara çok iyi bakması gerek. Çünkü en büyük derdimiz kirli veri. Test veri yönetimine girerken, önce verinizi temizlemeniz, gözden geçirmeniz, bu farkındalıkla teste adım atmanız şart. Ayrıca burada yapılan çalışma, aslında tüm şirketi bağlıyor, sadece pazarlama, BT veya test ekiplerini değil. Misal, bayide veriyi giren kişinin de bunu doğru yapması ya da kontrollerle kişinin doğru veri girmeye zorlanması lazım. Örneğin bayinin bilgileri girdiği ekranda doğum tarihi bölümünde 14'üncü ayı işaretleyememesi lazım. Yani siz tablonuzu doğru yaparsanız, doğru veriyi de toplama imkanınız olur. Bundan sonra da test verisini doğru biçimde çekmeniz gerek. Bu nedenle bu kavram, aslında bir şirkette tüm birimlere ve tüm çalışanlara, tüm paydaşlara dokunuyor. Geldiğimiz noktada, test algısının doğru gelişimi için hangi test yöntemini daha çok sevdiğinizden ziyade, bu belirttiğim altyapıyı doğru kurgulayıp doğru geliştirmelisiniz. Bu sizin oyun alanınız ve bu alan temiz olmak zorunda. Bundan sonra istediğiniz test metodunu seçebilirsiniz.
Peki ya güvenlik?
Bu konu, maskeleme tarafına da giriyor. Şirketlerin verileri zaten düzenli bir formatta değil ve sadece hantal bir büyük veri yapıları var. Bir banka olarak çok hızlı EFT yaptırabiliyor olabilirsiniz, ama kişinin bilgileri çalındığı zaman o hızın bir anlamı yok. Bir taraftan bireylerin de kişisel verileri ve bunların korunması ile ilgili beklentileri de artıyor. Çünkü eskiden SPAM geliyordu, ama bugün çok iyi maskelenmiş hileler bireyleri hedef alıyor. Bu sıkıntıya 10’uncu soruda değiniyoruz. Testte güvenlikle ilgili en büyük sıkıntı canlı veriyi kullanmayı sevmek. Çünkü bu maskelenmemiş veriyi kullanmak herkesin kolayına geliyor. Şirketlerin de yüzde 40’ı testlerinde maskelenmemiş canlı veriyi kullandığını belirtiyor.
Bu eğilim, ne gibi sorunlara yol açabilir?
Siz canlı yapıda gerekli güvenlik önlemlerini alabilirsiniz. Ama test ve yazılım geliştirme ortamında belli bir rahatlık vardır ve yayına almadan önceki süreç buradadır. Sizin gizli ve özel bilgilerinizin orada ortalıkta olması, yanlışlıkla mutfağa giren biri karşısında birçok verinin erişime açık hale gelmesi demek. Bu yüzden maskelemeden canlı veriyi kullanmamak gerektiğini hep vurguluyoruz. Test veri yönetiminde en önemli alan maskeleme ve kullanıcı gizliliği, güvenliği sıkıntı haline gelmemeli. Bu arada test başlığı, kullanılacak veri ve test önceliği gibi başlıkların her biri, farklı maskelemeleri gerekli kılar. Yani tek maske yapısı her zaman kullanılabilir denilemez. Bu başlıkta birçok yöntem var. Bu arada canlı veri çok büyük ve bunu kullanmanın da zaten bir maliyeti var.
Servis sanallaştırma, testte nasıl kullanılıyor?
Misal, bir test çalışması için TC Kimlik No onayı alacaksınız diyelim. Bunun için MERNİS’e bağlanmıyor, bunun yerine sanal bir hizmet yaratıyorsunuz ve size ilgili kimlik bilgisini onaylar gibi bir cevap dönüyor. Bu sahte yapı işinizi görüyor ve ilerlemenizi sağlıyor. Bu nedenle önemli. Aynı veriyi kopyalamanız, tüm altyapıyı oluşturmanız ya da gidip MERNİS’ten her bir test için TC Kimlik No doğrulatmanız maliyet demek. Oysa gelecek onay mesajını biliyorum ve onaylatacağım setler belli. İşte bunun için canlı ortama birebir benzer test ortamınızı, sanal bir servisi yaratıyorsunuz. Araştırmada da görüldüğü gibi hız herkesin önceliği ve elinizde araçlar olmalı, siz de ihtiyacınıza bağlı olarak doğru araçları bir araya getirmeli ve bunun için çok vakit harcamamalısınız. En ufak servisi bile sanallaştırabilirsiniz.
Türkiye Yazılım Kalite Raporu 2016/17 ve ‘test veri yönetimi’ne bakış
- Şirketinizde test verisi üretiminden kim sorumlu?
Yüzde 73 Yazılım test ekipleri
Yüzde 26 İş analistleri
Yüzde 22 Yazılım geliştiriciler
Yüzde 6 İş birimleri/operasyon
Yüzde 5 Veritabanı yöneticileri
Yüzde 5 Altyapı mimari ekipleri
Yüzde 4 Üçüncü parti yapılar
- Test verisini nasıl oluşturuyorsunuz?
Yüzde 64 Elle toplanan veri
Yüzde 40 Yayın verisinin alt kümesi
Yüzde 28 Yayındaki verinin tümünün kopyası
Yüzde 17 Veritabanı sanallaştırma
- Test çalışmalarınızın yüzde kaçı test veri yönetimi için kullanılıyor?
Yüzde 11 Çalışmaların yüzde 0-5’i
Yüzde 19 Çalışmaların yüzde 6-10’u
Yüzde 32 Çalışmaların yüzde 11-25’i
Yüzde 26 Çalışmaların yüzde 26-50’si
Yüzde 12 Çalışmaların yüzde 50’sinden fazlası
- Test verisi yaratırken karşılaştığınız temel zorluklar neler?
Yüzde 44 Güncellik
Yüzde 42 Tutarlılık ve süreklilik
Yüzde 37 Gerçek veri ile benzerlik
Yüzde 31 Güvenlik
Yüzde 28 Tanımsız veri ilişkileri
Yüzde 26 Gizlilik
Yüzde 22 Yetkin İK
Yüzde 21 Veri büyüklüğü
Yüzde 18 Sektör düzenlemelerine uyum
Yüzde 17 Gerekli araçların eksikliği
Yüzde 15 Bürokratik izin süreçleri
- Test ortamında hassas veriyi nasıl koruyorsunuz?
Yüzde 51 Veri maskeleme
Yüzde 27 Suni veri üretimi
Yüzde 22 Verileri kendi içinde karıştırmak
Yüzde 19 Özel bütünlüğe güvenmek
Yüzde 18 Hassas test verisi korumuyoruz
- Test veri kalitenizi en iyi hangisi tanımlar?
Yüzde 13 Zayıf
Yüzde 15 Noksan
Yüzde 53 İyiye gidiyor
Yüzde 19 İyi
- Test verisini yönetme çalışmalarının yüzde kaçı otomatize edilmiş durumda?
Yüzde 59 Çalışmaların yüzde 0-20’si
Yüzde 20 Çalışmaların yüzde 21-50’si
Yüzde 17 Çalışmaların yüzde 51-75’i
Yüzde 76-100 Çalışmaların yüzde 4’ü
- Otomatize fonksiyonel testlerin kullandığı verileri nasıl yönetiyorsunuz?
Yüzde 41 Elle bakım (entegre veri)
Yüzde 24 Veritabanı yönetimi
Yüzde 18 Veri odaklı yaklaşım (dış kaynaklı veri kaynakları)
Yüzde 17 Dinamik veri üretimi
- Test verisi üretmek için ihtiyaç duyduğunuz öncelikli üç test seviyeniz/türünüz hangileri?
Yüzde 91 Fonksiyonel test
Yüzde 63 Entegrasyon testi
Yüzde 57 Regresyon testi
Yüzde 45 Performans testi
Yüzde 30 Birim test
Yüzde 14 Güvenlik testi
- Maskelenmemiş canlı verileri testlerinizde kullanıyor musunuz?
Yüzde 40 Evet
Yüzde 60 Hayır
