Notes

Best data= Better testing= Better Software

Database are too large to work within a testing environment
Production data is too sensitive to be used for testing
Refresing data from production needs to be quick and easy
Relying only on the database administrator to extract data is not scalable
Cut down test data preparation time by %50 or more
Satisfy compliance by masking test data
For working agile, refresh test data quickly for every test iteration you have
Resolve dependency between the testing team and the DBA resulting in fewer delays
Test Data Management = Fresh, safe data whenever you are ready to test

Test verisi gereksinimlerinin analizi, test veri yapılarının tasarlanması, test verisinin yaratılması ve sürdürülmesi süreci

Test Verisi Hazırlama Araçları
Test verisi hazırlama araçları çok sayıda fayda sunar. Bazı test verisi hazırlama araçları, gerekli kapsam seviyesine ulaşmak amacıyla test sırasında gerekli verileri tespit etmek için analiz dokümanı gibi bir dokümanı ya da kaynak kodu analiz edebilir. Diğer test verisi hazırlama araçları, canlı ortamdan bir veri kümesini alabilir ve verinin dahili bütünlüğünü korurken kişisel bilgileri silmek için söz konusu veri kümesini "anonimleştirebilir". Anonimleştirilen veri, kişisel bilgilerin kötüye kullanımına ya da güvenlik sızıntılarına dair herhangi bir risk olmaksızın testte kullanılabilir. Büyük hacimli gerçekçi verilerin gerekli olduğu durumlarda bu özellikle önemlidir. Diğer veri üretimi araçları, test verilerini belirli giriş parametrelerinden oluşan kümelerden üretmek için kullanabilir (diğer bir deyişle, rastgele testte kullanılması için). Bunlardan bazıları, test analistinin gerekli göreceği girdileri belirlemek üzere veritabanı yapısını analiz edecektir.

*Test data is the data that is used in tests of a software system.
In order to test a software application you need to enter some data for testing most of the features. Any such specifically identified data which is used in tests is known as test data.

You can have test data in excel sheet which can be entered manually while executing test cases or it can be read automatically from files (XML, Flat Files, Database etc.) by automation tools.

Some test data is used to confirm the expected result, i.e. When test data is entered the expected result should come and some test data is used to verify the software behavior to invalid input data.

Test data is generated by testers or by automation tools which support testing. Most of the times in regression testing the test data is re-used, it is always a good practice to verify the test data before re-using it in any kind of test.

Why is test data important?

If you're developing an application, you'll want to make sure you're testing it under conditions that closely simulate a production environment. In production, you'll have an army of users banging away at your app and filling your database with data, which puts stress on your code. If you're hand-entering data into a test environment one record at a time using the UI, you're never going to build up the volume and variety of data that your app will accumulate in a few days in production. Worse, the data you enter will be biased towards your own usage patterns and won't match real-world usage, leaving important bugs undiscovered.

Why is realistic data important?

When your test database is filled with realistic looking data, you'll be more engaged as a tester. When you demonstrate new features to others, they'll understand them faster. Real data is varied and will contain characters that may not play nice with your code, such as apostrophes, or unicode characters from other languages. Testing with realistic data will make your app more robust because you'll catch errors that are likely to occur in production before release day.

Test Data Management:
Test Data management is very critical during the test life cycle. The amount of data that is generated is enormous for testing the application. Reporting the results it minimizes the time spent for processing the data and creating reports greatly contributes to the efficiency of an entire product.

Test data Management - Checklist:
identify common test data elements
Aging, masking and archiving of test data
Prioritization and allocation of test data
Generating reports and dashboards for metrics
Creating and implementing business rules
Building an automation suite for master data preparation
Masking, archiving and versioning aging of data

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