Yapay Zeka Testlerinde Dikkat Edilecekler

Yapay zeka (YZ) sistemlerinin test edilmesi, geleneksel yazılım testlerinden önemli ölçüde farklılık gösterir. YZ modelleri, veri odaklı öğrenme ve karmaşık algoritmalar kullandığı için, test süreçleri de bu özelliklere uygun şekilde tasarlanmalıdır. Bu makalede, YZ sistemlerini detaylı olarak test etmek için kullanılabilecek yöntemleri ve örnek test senaryolarını inceleyeceğiz.

1. Veri Odaklı Testler

Veri odaklı testler, YZ modelinin eğitim verileriyle olan ilişkisini ve modelin veri üzerindeki performansını değerlendirir.

• Veri Kalitesi Testleri:
  • Eğitim verilerinin doğruluğunu, tutarlılığını ve eksiksizliğini kontrol eder.
  • Veri etiketlerinin doğru olup olmadığını ve veri setindeki olası önyargıları tespit eder.
  • Örnek Test Senaryoları:
    1. Görüntü tanıma modelinde, etiketlenmiş görüntülerin doğru kategoriye ait olup olmadığını kontrol etmek.
    2. Doğal dil işleme modelinde, metin verilerindeki yazım hatalarını ve tutarsızlıkları tespit etmek.
• Veri Çeşitliliği Testleri:
  • Modelin farklı veri dağılımlarına ve senaryolara karşı performansını değerlendirir.
  • Modelin, eğitim verilerinde az rastlanan veya hiç görülmeyen durumlara karşı nasıl tepki verdiğini test eder.
  • Örnek Test Senaryoları:
    1. Otonom araç modelinde, farklı hava koşullarında (yağmur, kar, sis) sürüş performansını test etmek.
    2. Öneri sisteminde, farklı kullanıcı demografilerine ve ilgi alanlarına sahip kullanıcılar için öneri doğruluğunu karşılaştırmak.

2. Model Odaklı Testler

Model odaklı testler, YZ modelinin yapısını, algoritmasını ve genel performansını değerlendirir.

• Doğruluk ve Performans Testleri:
  • Modelin tahminlerinin doğruluğunu ve hata oranını ölçer.
  • Modelin işlem hızını, kaynak kullanımını ve ölçeklenebilirliğini değerlendirir.
  • Örnek Test Senaryoları:
    1. Sınıflandırma modelinde, doğruluk (accuracy), kesinlik (precision), geri çağırma (recall) ve F1 skoru gibi metrikleri ölçmek.
    2. Tahmin modelinde, ortalama karesel hata (MSE) veya ortalama mutlak hata (MAE) gibi hata metriklerini hesaplamak.
• Genelleme Testleri:
  • Modelin, eğitim verilerinde görülmeyen yeni verilere karşı ne kadar iyi genelleme yaptığını test eder.
  • Modelin aşırı öğrenme (overfitting) veya yetersiz öğrenme (underfitting) sorunları olup olmadığını tespit eder.
  • Örnek Test Senaryoları:
    1. Görüntü tanıma modelini, eğitim verilerinde bulunmayan yeni nesnelerin görüntüleriyle test etmek.
    2. Doğal dil işleme modelini, eğitim verilerinde kullanılmayan farklı cümle yapıları ve kelime dağarcığıyla test etmek.

3. Davranış Odaklı Testler

Davranış odaklı testler, YZ modelinin gerçek dünya senaryolarında nasıl davrandığını ve kullanıcılarla nasıl etkileşim kurduğunu değerlendirir.

• Etik Testler:
  • Modelin önyargılı veya ayrımcı davranışlar sergileyip sergilemediğini kontrol eder.
  • Modelin, etik kurallara ve toplumsal değerlere uygun kararlar alıp almadığını değerlendirir.
  • Örnek Test Senaryoları:
    1. İşe alım modelinde, cinsiyet, ırk veya yaş gibi faktörlere dayalı ayrımcılık olup olmadığını test etmek.
    2. Kredi puanlama modelinde, farklı sosyoekonomik gruplara karşı adil olup olmadığını değerlendirmek.
• Güvenlik Testleri:
  • Modelin kötü niyetli saldırılara ve manipülasyonlara karşı ne kadar güvenli olduğunu test eder.
  • Modelin veri sızıntısı veya yetkisiz erişim gibi güvenlik açıklarına sahip olup olmadığını tespit eder.
  • Örnek Test Senaryoları:
    1. Otonom araç modelini, trafik işaretlerini yanıltıcı şekilde değiştirerek veya engelleyerek test etmek.
    2. Sohbet robotunu, kötü niyetli sorular veya komutlarla manipüle etmeye çalışmak.

Test Sürecinde Dikkat Edilmesi Gerekenler:

• Test verilerinin çeşitliliği ve gerçekçiliği.
• Test ortamının ve senaryolarının dikkatli bir şekilde tasarlanması.
• Test metriklerinin doğru seçimi ve yorumlanması.
• İnsan denetimi ve geri bildirim mekanizmalarının kullanılması.
• Sürekli test ve izleme süreçlerinin uygulanması.

YZ testleri, karmaşık ve sürekli gelişen bir alandır. Bu nedenle, test yöntemleri ve araçları da sürekli olarak güncellenmeli ve geliştirilmelidir.

JMeter ile Binance Web Sitesi Performans Test Planı

Binance, dünyanın en büyük kripto para borsalarından biri olarak, yüksek trafik ve işlem hacmiyle çalışır. Bu nedenle, web sitesinin performansının sürekli olarak izlenmesi ve test edilmesi kritik öneme sahiptir. Bu makalede, açık kaynaklı bir performans test aracı olan JMeter'i kullanarak Binance web sitesinin performans test planını detaylı olarak inceleyeceğiz.

Performans Testinin Amaçları:

• Yük Testi: Web sitesinin belirli bir kullanıcı yükü altında nasıl performans gösterdiğini belirlemek.
• Stres Testi: Web sitesinin aşırı yük altında nasıl tepki verdiğini ve çökmeye karşı dayanıklılığını ölçmek.
• Yanıt Süresi Testi: Web sitesinin farklı sayfalarının ve işlemlerinin yanıt sürelerini ölçmek.
• Kaynak Kullanımı Testi: Web sitesinin sunucu kaynaklarını (CPU, bellek, disk) ne kadar kullandığını izlemek.

Test Planı Adımları:

1. Test Senaryolarının Belirlenmesi:
   • En çok kullanılan sayfalar ve işlemler (örneğin, ana sayfa, giriş, piyasa verileri, alım/satım işlemleri) belirlenir.
   • Farklı kullanıcı senaryoları (örneğin, sadece bilgi alan kullanıcılar, aktif işlem yapan kullanıcılar) oluşturulur.
2. JMeter Kurulumu ve Ayarları:
   • JMeter, Apache JMeter web sitesinden indirilir ve kurulur.
   • JMeter'in performansını artırmak için gerekli ayarlar (örneğin, bellek ayarları) yapılır.
3. Test Planının Oluşturulması:
   • JMeter'de yeni bir test planı oluşturulur.
   • "Thread Group" eklenerek sanal kullanıcı sayısı, döngü sayısı ve artış süresi belirlenir.
   • "HTTP Request" eklenerek test edilecek sayfaların URL'leri ve HTTP yöntemleri (GET, POST) belirlenir.
   • "Listeners" eklenerek test sonuçlarının görselleştirilmesi sağlanır (örneğin, "View Results Tree", "Aggregate Report").
   • "Timers" eklenerek gerçek kullanıcı davranışlarını simüle etmek için gecikmeler eklenir.
   • "Assertions" eklenerek API'den dönen cevapların doğru olup olmadığı kontrol edilir.
4. Test Verilerinin Hazırlanması:
   • Test edilecek sayfalar için gerekli giriş verileri (örneğin, kullanıcı adı, şifre, semboller) hazırlanır.
   • Test verileri CSV dosyası gibi harici dosyalardan okunarak kullanılır.
5. Testin Çalıştırılması ve İzlenmesi:
   • Test planı JMeter'de çalıştırılır.
   • Test sırasında sunucu kaynakları (CPU, bellek, disk) izlenir.
   • JMeter'deki dinleyiciler (listeners) kullanılarak test sonuçları gerçek zamanlı olarak izlenir.
6. Test Sonuçlarının Analizi ve Raporlama:
   • Test sonuçları analiz edilerek yanıt süreleri, hata oranları ve kaynak kullanımı değerlendirilir.
   • Performans sorunları tespit edilir ve raporlanır.
   • Test sonuçları, grafikler ve tablolar halinde raporlanır.
7. Optimizasyon ve Tekrar Test:
   • Tespit edilen performans sorunları giderilir.
   • Testler tekrar çalıştırılarak iyileştirmelerin etkisi değerlendirilir.

Önemli Test Senaryoları:

• Ana Sayfa Yük Testi: Ana sayfanın yüksek kullanıcı yükü altında nasıl performans gösterdiğini test etmek.
• Giriş İşlemi Yük Testi: Giriş işleminin yüksek kullanıcı yükü altında nasıl performans gösterdiğini test etmek.
• Piyasa Verileri API Testi: Piyasa verileri API'sinin yüksek istek yükü altında nasıl performans gösterdiğini test etmek.
• Alım/Satım İşlemi Testi: Alım/satım işlemlerinin yüksek kullanıcı yükü altında nasıl performans gösterdiğini test etmek.

JMeter İpuçları:

• Testleri gerçekçi senaryolarla tasarlayın.
• Test verilerini dikkatlice hazırlayın.
• Test sonuçlarını detaylı olarak analiz edin.
• Testlerinizi düzenli olarak çalıştırın.

Bu rehber, JMeter kullanarak Binance web sitesinin performans test planını oluşturmanıza yardımcı olacaktır. Daha karmaşık test senaryoları ve ihtiyaçlarınız için JMeter'in gelişmiş özelliklerini ve Binance web sitesinin özelliklerini inceleyebilirsiniz.

Postman ile Binance API Metotlarını Test Etme

Binance API, kripto para ticaretini otomatikleştirmek ve platformla entegrasyon sağlamak için kapsamlı bir arayüz sunar. Bu rehber, Postman kullanarak Binance API'nin tüm metotlarını nasıl test edeceğinizi ayrıntılı olarak açıklayacaktır.

Gereksinimler:

• Postman: Postman uygulamasının yüklü olması.
• Binance API Anahtarları: Binance hesabından oluşturulmuş API anahtarları.
• API Dokümantasyonu: Binance API dokümantasyonuna erişim.

Adım 1: Postman'de Çalışma Alanı ve Koleksiyon Oluşturma

1. Postman'i açın ve yeni bir çalışma alanı oluşturun.
2. Çalışma alanında, "Collections" sekmesine giderek yeni bir koleksiyon oluşturun (örneğin, "Binance API Testleri").

Adım 2: Ortam Değişkenlerini Ayarlama

1. Koleksiyonunuzun sağ üst köşesindeki "..." simgesine tıklayın ve "Edit"i seçin.
2. "Variables" sekmesine gidin ve aşağıdaki değişkenleri ekleyin:
   • baseUrl: https://api.binance.com
   • apiKey: API anahtarınız
   • apiSecret: Gizli anahtarınız

Adım 3: API İsteklerini Oluşturma ve Test Etme

Binance API dokümantasyonu, farklı uç noktaları ve metotları kategorilere ayırır. Bu kategorilere göre testleri düzenleyeceğiz.

3.1. Piyasa Verileri (Market Data)

• GET /api/v3/ping:
  • Sunucunun çalışır durumda olduğunu kontrol eder.
  • URL: {{baseUrl}}/api/v3/ping
• GET /api/v3/time:
  • Sunucu zamanını alır.
  • URL: {{baseUrl}}/api/v3/time
• GET /api/v3/ticker/price:
  • Sembolün güncel fiyatını alır.
  • URL: {{baseUrl}}/api/v3/ticker/price?symbol=BTCUSDT
• GET /api/v3/klines:
  • K-çizgisi/mum verilerini alır.
  • URL: {{baseUrl}}/api/v3/klines?symbol=BTCUSDT&interval=1m

3.2. Hesap Bilgileri (Account)

• GET /api/v3/account:
  • Hesap bilgilerini alır (imza gerektirir).
  • URL: {{baseUrl}}/api/v3/account
• GET /api/v3/myTrades:
  • Hesap işlem geçmişini alır (imza gerektirir).
  • URL: {{baseUrl}}/api/v3/myTrades?symbol=BTCUSDT

3.3. Emirler (Orders)

• POST /api/v3/order:
  • Yeni bir alım/satım emri verir (imza gerektirir).
  • URL: {{baseUrl}}/api/v3/order
• GET /api/v3/openOrders:
  • Açık emirleri listeler (imza gerektirir).
  • URL: {{baseUrl}}/api/v3/openOrders
• DELETE /api/v3/order:
  • Bir emri iptal eder (imza gerektirir).
  • URL: {{baseUrl}}/api/v3/order

Adım 4: İmza Oluşturma (Authentication)

1. Birçok Binance API metodu, isteğin imzalanmasını gerektirir.
2. Postman'de "Pre-request Script" sekmesini kullanarak imza oluşturma işlemini otomatikleştirebilirsiniz.
3. İmza oluşturmak için, isteğin parametrelerini ve gizli anahtarınızı kullanarak bir HMAC SHA256 hash'i oluşturmanız gerekir.

Adım 5: Testleri Otomatikleştirme ve Doğrulama

1. Postman'in "Tests" sekmesini kullanarak API yanıtlarını doğrulayabilirsiniz.
2. Test senaryoları oluşturarak API'nin beklenen davranışlarını doğrulayın.
3. Newman gibi araçlarla testlerinizi otomatikleştirebilir ve sürekli entegrasyon (CI) süreçlerinize dahil edebilirsiniz.

Önemli Notlar:

• Binance API dokümantasyonunu düzenli olarak kontrol edin, çünkü API değişiklik gösterebilir.
• API anahtarlarınızı ve gizli anahtarlarınızı güvenli bir şekilde saklayın.
• Binance api'si ile işlem yaparken testnet ağını kullanmanız olası kayıplarınızı engelleyecektir.
• Hata kodlarına ve mesajlarına dikkat edin.

STANAG Nedir, Hangi Amaçla Kullanılır?

NATO Standartlaştırma Anlaşmaları (STANAG'lar), NATO üyesi ülkeler arasında askeri ve teknik prosedürlerin, teçhizatların ve iletişim sistemlerinin uyumluluğunu sağlamak amacıyla geliştirilmiş standartlardır. Bu standartlar, üye ülkelerin birlikte operasyon yapabilmesini, lojistik destek sağlayabilmesini ve bilgi paylaşımında bulunabilmesini kolaylaştırır.

STANAG'ların Amaçları

•     Birlikte Çalışabilirlik (Interoperability): NATO kuvvetlerinin birlikte etkili bir şekilde çalışabilmesi için ortak prosedürler ve standartlar oluşturmak.
•     Lojistik Uyumluluk: Üye ülkelerin askeri teçhizatlarının, mühimmatlarının ve yedek parçalarının birbirleriyle uyumlu olmasını sağlamak.
•     İletişim Standardizasyonu: Farklı iletişim sistemlerinin birbirleriyle etkili bir şekilde iletişim kurabilmesi için ortak protokoller ve frekanslar belirlemek.
•     Güvenlik ve Verimlilik: Ortak standartlar sayesinde askeri operasyonların daha güvenli ve verimli bir şekilde yürütülmesini sağlamak.

STANAG'ların Kullanım Alanları

STANAG'lar, askeri alanda geniş bir yelpazede kullanılır. Bazı örnekler:

•     Mühimmat Standartları: Farklı ülkelerin silahlarının aynı mühimmatı kullanabilmesini sağlamak (örneğin, 5.56x45mm NATO mühimmatı).
•     İletişim Protokolleri: Telsiz frekansları, veri iletimi ve şifreleme gibi konularda ortak standartlar belirlemek.
•     Harita ve Navigasyon: Ortak harita sembolleri, navigasyon sistemleri ve coğrafi bilgi standartları oluşturmak.
•     Lojistik ve Tedarik: Yakıt, yiyecek, yedek parça ve diğer malzemelerin tedariki ve depolanması için standartlar belirlemek.
•     Zırhlı Araç Koruma Seviyeleri: Zırhlı araçların ve lojistik araçların mayın ve balistik tehditlere karşı koruma seviyelerini standartlaştırmak (örneğin, STANAG 4569).
•     Denizcilik Standartları: Gemilerin elektrik sistemleri, iletişim protokolleri ve denizcilik taktikleri gibi konularda ortak standartlar belirlemek.

STANAG'ların Önemi

STANAG'lar, NATO'nun etkinliği ve gücü için kritik öneme sahiptir. Bu standartlar sayesinde:

•     NATO kuvvetleri, farklı ülkelerden olsalar bile birlikte sorunsuz bir şekilde operasyon yapabilir.
•     Lojistik destek, daha hızlı ve verimli bir şekilde sağlanabilir.
•     İletişim sorunları en aza indirilir.
•     Askeri operasyonların maliyeti düşer.

Özetle, STANAG'lar, NATO'nun uyum içinde çalışmasını sağlayan ve askeri yeteneklerini artıran temel bir unsurdur.

API Testleri: Yazılım Kalitesinin Temel Taşı (Örneklerle)

API'ler (Uygulama Programlama Arayüzleri), yazılım sistemlerinin birbirleriyle iletişim kurmasını sağlayan kritik bileşenlerdir. Bu nedenle, API'lerin doğru ve güvenilir bir şekilde çalıştığından emin olmak, yazılım kalitesi için hayati önem taşır. API testleri, bu doğruluğu ve güvenilirliği sağlamak için yapılan testlerdir.

API Testlerinin Önemi

• Erken Hata Tespiti: API testleri, hataların erken aşamalarda tespit edilmesini sağlayarak geliştirme maliyetlerini düşürür.
• Güvenilirlik: API'lerin doğru çalıştığından emin olarak sistemlerin güvenilirliğini artırır.
• Güvenlik: API'lerdeki güvenlik açıklarını tespit ederek sistemlerin güvenliğini sağlar.
• Performans: API'lerin performansını ölçerek sistemlerin verimli çalışmasını sağlar.
• Entegrasyon: Farklı sistemlerin birbirleriyle sorunsuz bir şekilde entegre olmasını sağlar.

API Test Türleri ve Örnekleri

1. Fonksiyonel Testler:
   • API'nin beklenen işlevleri doğru bir şekilde yerine getirip getirmediğini kontrol eder.
   • Örnek 1: Bir e-ticaret API'sinde, doğru ürün ID'si ile yapılan bir GET isteğinin, beklenen ürün bilgilerini döndürüp döndürmediğini test etmek.
   • Örnek 2: Bir kullanıcı kayıt API'sinde, geçersiz bir e-posta adresi ile yapılan bir POST isteğinin, uygun hata mesajını döndürüp döndürmediğini test etmek.
2. Performans Testleri:
   • API'nin hızını, yanıt süresini, kaynak kullanımını ve kararlılığını ölçer.
   • Örnek 1: Bir hava durumu API'sine, aynı anda 1000 kullanıcıdan gelen istekleri simüle ederek, API'nin yanıt süresini ve sunucu yükünü ölçmek.
   • Örnek 2: Bir dosya yükleme API'sine, büyük boyutlu dosyalar göndererek, API'nin yük altında nasıl performans gösterdiğini test etmek.
3. Güvenlik Testleri:
   • API'deki güvenlik açıklarını (örneğin, yetkisiz erişim, veri sızıntısı) tespit eder.
   • Örnek 1: Bir kullanıcı giriş API'sine, SQL enjeksiyonu saldırısı yaparak, API'nin veritabanına yetkisiz erişimi önleyip önlemediğini test etmek.
   • Örnek 2: Bir API'nin, hassas kullanıcı verilerini (örneğin, kredi kartı bilgileri) şifrelenmemiş olarak gönderip göndermediğini test etmek.
4. Güvenilirlik Testleri:
   • API'nin kararlılığını ve tutarlılığını test eder.
   • Örnek 1: Bir API'yi, 24 saat boyunca sürekli olarak çağırarak, API'nin kesintisiz çalıştığını ve hata vermediğini test etmek.
   • Örnek 2: Bir API'nin, farklı giriş parametreleri ile tutarlı sonuçlar döndürüp döndürmediğini test etmek.
5. Birim Testleri:
   • API'nin tek tek bileşenlerinin (örneğin, fonksiyonlar, metotlar) doğru çalıştığını test eder.
   • Örnek 1: Bir API'deki bir fonksiyonun, doğru girişlerle doğru sonuçlar döndürüp döndürmediğini test etmek.
   • Örnek 2: Bir API'deki bir metodun, beklenen istisnaları (exceptions) doğru bir şekilde fırlatıp fırlatmadığını test etmek.
6. Entegrasyon Testleri:
   • API'nin diğer sistemlerle (örneğin, veritabanları, harici servisler) doğru bir şekilde entegre olup olmadığını test eder.
   • Örnek 1: Bir API'nin, bir veritabanından doğru verileri okuyup yazabildiğini test etmek.
   • Örnek 2: Bir API'nin, bir ödeme sistemi API'si ile doğru bir şekilde iletişim kurabildiğini test etmek.

API Test Araçları

• Postman: API testleri için popüler ve kullanıcı dostu bir araçtır.
• JMeter: Performans testleri için yaygın olarak kullanılan açık kaynaklı bir araçtır.
• SoapUI: SOAP ve REST API'lerini test etmek için kullanılan bir araçtır.
• Karate DSL: API otomasyonu için açık kaynaklı bir araçtır.
• Rest Assured: Java tabanlı REST API testleri için kullanılan bir kütüphanedir.

API Test Stratejisi

• Test senaryolarını ve test verilerini dikkatlice planlayın.
• Testleri otomatikleştirerek sürekli test yapılmasını sağlayın.
• Test sonuçlarını düzenli olarak analiz edin ve raporlayın.
• Geri bildirimleri dikkate alarak API'yi sürekli olarak iyileştirin.

Java Uygulamalarında En Sık Karşılaşılan Exception Türleri ve Test Yöntemleri

Java, geniş kullanım alanı ve platform bağımsızlığı sayesinde en popüler programlama dillerinden biridir. Ancak, Java uygulamaları da diğer yazılımlar gibi çeşitli hatalarla karşılaşabilir. Bu hataların en yaygın türlerinden biri de "exception" olarak adlandırılan istisnai durumlardır. Exception'lar, programın normal akışını bozan ve beklenmedik sonuçlara yol açan olaylardır. Bu makalede, Java uygulamalarında en sık karşılaşılan exception türlerini ve bu exception'ları ortaya çıkarmak için yapılabilecek örnek testleri inceleyeceğiz.

En Sık Karşılaşılan Exception Türleri

1. NullPointerException:
   • Bir nesnenin null olduğu bir durumda, o nesnenin bir metodunu veya değişkenini çağırmaya çalıştığınızda ortaya çıkar.
   • Örneğin, String str = null; ve sonra str.length() çağırdığınızda bu hatayı alırsınız.
   • Bu hata, Java'da en yaygın karşılaşılan hatalardan biridir.
2. ArrayIndexOutOfBoundsException:
   • Bir dizinin (array) sınırları dışında bir indekse erişmeye çalıştığınızda ortaya çıkar.
   • Örneğin, 5 elemanlı bir dizide 5. indekse (diziler 0'dan başlar) erişmeye çalıştığınızda bu hatayı alırsınız.
3. ClassCastException:
   • Bir nesneyi, uyumsuz bir sınıfa dönüştürmeye çalıştığınızda ortaya çıkar.
   • Örneğin, bir Object nesnesini String'e dönüştürmeye çalıştığınızda, eğer nesne gerçekten bir String değilse bu hatayı alırsınız.
4. IllegalArgumentException:
   • Bir metoda geçersiz bir argüman geçirdiğinizde ortaya çıkar.
   • Örneğin, bir metodun pozitif bir sayı beklediği yerde negatif bir sayı geçirdiğinizde bu hatayı alırsınız.
5. NumberFormatException:
   • Bir string'i sayısal bir tipe (örneğin, int veya double) dönüştürmeye çalıştığınızda, string sayısal bir değer içermiyorsa ortaya çıkar.
   • Örneğin, "abc" string'ini int'e dönüştürmeye çalıştığınızda bu hatayı alırsınız.
6. IOException:
   • Giriş/çıkış işlemleri sırasında bir hata oluştuğunda ortaya çıkar.
   • Örneğin, bir dosyayı okurken veya yazarken bir hata oluştuğunda bu hatayı alırsınız.
7. FileNotFoundException:
   • Bir dosyayı okumaya veya yazmaya çalıştığınızda, dosya bulunamadığında ortaya çıkar.
8. ArithmeticException:
   • Aritmetik bir hata oluştuğunda ortaya çıkar.
   • Örneğin, sıfıra bölme işlemi yapmaya çalıştığınızda bu hatayı alırsınız.
9. NoSuchElementException:
   • Bir koleksiyondan (örneğin, bir List veya Set) bir eleman almaya çalıştığınızda, koleksiyon boşsa veya istenen eleman yoksa ortaya çıkar.
10. SQLException:
    • Veritabanı işlemleri sırasında bir hata oluştuğunda ortaya çıkar.
    • Örneğin, bir SQL sorgusu çalıştırırken bir hata oluştuğunda bu hatayı alırsınız.

Exception'ları Ortaya Çıkarmak İçin Yapılabilecek Örnek Testler

1. NullPointerException Testi:

   • Bir nesneyi null olarak başlatın.
   • Nesnenin bir metodunu veya değişkenini çağırmaya çalışın.
   • try-catch bloğu kullanarak NullPointerException'ı yakalayın ve hata mesajını yazdırın.
   • Örnek Kod:
    

   public class NullPointerExceptionTest {
       public static void main(String[] args) {
           String str = null;
           try {
               int length = str.length();
               System.out.println("String uzunluğu: " + length);
           } catch (NullPointerException e) {
               System.out.println("NullPointerException yakalandı: " + e.getMessage());
           }
       }
   }

   
   

   2. ArrayIndexOutOfBoundsException Testi:

   • Belirli bir boyutta bir dizi oluşturun.
   • Dizinin sınırları dışında bir indekse erişmeye çalışın.
   • try-catch bloğu kullanarak ArrayIndexOutOfBoundsException'ı yakalayın ve hata mesajını yazdırın.
   • Örnek Kod:

   
   

   public class ArrayIndexOutOfBoundsExceptionTest {
       public static void main(String[] args) {
           int[] numbers = {1, 2, 3};
           try {
               int number = numbers[3];
               System.out.println("Sayı: " + number);
           } catch (ArrayIndexOutOfBoundsException e) {
               System.out.println("ArrayIndexOutOfBoundsException yakalandı: " + e.getMessage());
           }
       }
   }

    

    

   3. ClassCastException Testi:

   • Bir nesneyi yanlış bir sınıfa dönüştürmeye çalışın.
   • try-catch bloğu kullanarak ClassCastException'ı yakalayın ve hata mesajını yazdırın.
   • Örnek Kod:

    

   public class ClassCastExceptionTest {
       public static void main(String[] args) {
           Object obj = "Merhaba";
           try {
               Integer number = (Integer) obj;
               System.out.println("Sayı: " + number);
           } catch (ClassCastException e) {
               System.out.println("ClassCastException yakalandı: " + e.getMessage());
           }
       }
   }

    

    

   4. NumberFormatException Testi:

   • Sayısal olmayan bir string'i sayıya dönüştürmeye çalışın.
   • try-catch bloğu kullanarak NumberFormatException'ı yakalayın ve hata mesajını yazdırın.
   • Örnek Kod:

    

   public class NumberFormatExceptionTest {
       public static void main(String[] args) {
           String str = "abc";
           try {
               int number = Integer.parseInt(str);
               System.out.println("Sayı: " + number);
           } catch (NumberFormatException e) {
               System.out.println("NumberFormatException yakalandı: " + e.getMessage());
           }
       }
   }
   

Mobil Uygulama Yazılım Testlerinde En Sık Karşılaşılan Hata Türleri: Kullanıcı Deneyimi ve Cihaz Uyumluluğu Odaklı Sorunlar

Mobil uygulamalar, günlük hayatımızın ayrılmaz bir parçası haline geldi. Ancak, farklı işletim sistemleri, cihaz modelleri ve ekran boyutları gibi faktörler nedeniyle, mobil uygulamalarda çeşitli hataların ortaya çıkması kaçınılmazdır. Bu hatalar, kullanıcı deneyimini olumsuz etkileyebilir, uygulamanın işlevselliğini bozabilir ve hatta kullanıcıların uygulamayı terk etmesine neden olabilir. Bu nedenle, mobil uygulama yazılım testleri, hataların erken tespiti ve giderilmesi için kritik öneme sahiptir.

En Sık Karşılaşılan Hata Türleri ve Etkileri

Mobil uygulama yazılım testlerinde en sık karşılaşılan hata türleri şunlardır:

• Uyumluluk Hataları:
  • Farklı işletim sistemleri (iOS, Android), cihaz modelleri ve ekran boyutlarında uygulamanın düzgün çalışmamasıdır.
  • Örneğin, bir Android uygulamasının bazı cihazlarda çökmesi veya iOS uygulamasının farklı ekran boyutlarında bozuk görünmesi.
  • Bu hatalar, uygulamanın geniş bir kullanıcı kitlesine ulaşmasını engelleyebilir.
• Performans Hataları:
  • Uygulamanın yavaş çalışması, aşırı pil tüketmesi veya çok fazla bellek kullanmasıdır.
  • Örneğin, uygulamanın açılış süresinin uzun olması veya karmaşık işlemler sırasında donması.
  • Performans sorunları, kullanıcıların uygulamayı kullanmaktan vazgeçmesine neden olabilir.
• Kullanılabilirlik Hataları:
  • Uygulamanın kullanıcı dostu olmaması, karmaşık arayüzler veya anlaşılması zor navigasyonlar içermesidir.
  • Örneğin, butonların çok küçük olması veya menülerin karmaşık bir şekilde düzenlenmesi.
  • Kullanılabilirlik sorunları, kullanıcıların uygulamayı etkili bir şekilde kullanmasını zorlaştırır.
• Fonksiyonel Hatalar:
  • Uygulamanın temel işlevlerinin (örneğin, giriş, kayıt, ödeme) doğru çalışmamasıdır.
  • Örneğin, kullanıcının giriş yapamaması veya ödeme işleminin başarısız olması.
  • Fonksiyonel hatalar, uygulamanın amacına ulaşmasını engeller ve kullanıcıların güvenini sarsar.
• Ağ Bağlantısı Hataları:
  • Uygulamanın ağ bağlantısı kesildiğinde veya zayıf olduğunda düzgün çalışmamasıdır.
  • Örneğin, uygulamanın çevrimdışı modda çalışmaması veya verilerin senkronize edilememesi.
  • Ağ bağlantısı sorunları, kullanıcıların uygulamayı her zaman ve her yerde kullanmasını engeller.
• Güvenlik Hataları:
  • Uygulamanın güvenlik açıklarının (örneğin, veri sızıntısı, yetkisiz erişim) bulunmasıdır.
  • Örneğin, kullanıcı verilerinin şifrelenmemiş olarak saklanması veya uygulamanın kötü amaçlı yazılımlara karşı savunmasız olması.
  • Güvenlik sorunları, kullanıcıların gizliliğini ve güvenliğini tehlikeye atar.

Hata Tespiti ve Giderme Süreci

Mobil uygulama yazılım testleri, bu hataların erken tespiti ve giderilmesi için çeşitli yöntemler kullanır. Bunlar arasında şunlar yer alır:

• Fonksiyonel Testler: Uygulamanın işlevlerinin doğru çalışıp çalışmadığını kontrol eder.
• Performans Testleri: Uygulamanın hızını, pil tüketimini ve bellek kullanımını ölçer.
• Uyumluluk Testleri: Uygulamanın farklı cihazlarda ve işletim sistemlerinde nasıl çalıştığını test eder.
• Kullanılabilirlik Testleri: Kullanıcıların uygulamayı ne kadar kolay kullanabildiğini değerlendirir.
• Güvenlik Testleri: Uygulamanın güvenlik açıklarını tespit eder.

Web Sitesi Yazılım Testlerinde En Sık Karşılaşılan Hata Türleri: Kullanıcı Deneyimini ve Güvenliği Tehdit Eden Unsurlar

Web siteleri, günümüz dijital dünyasında işletmeler, kurumlar ve bireyler için vazgeçilmez bir araç haline gelmiştir. Ancak, karmaşık yapıları ve sürekli değişen teknolojiler nedeniyle, web sitelerinde çeşitli hataların ortaya çıkması kaçınılmazdır. Bu hatalar, kullanıcı deneyimini olumsuz etkileyebilir, güvenlik açıklarına yol açabilir ve hatta işletmelerin itibarını zedeleyebilir. Bu nedenle, web sitesi yazılım testleri, hataların erken tespiti ve giderilmesi için kritik öneme sahiptir.

En Sık Karşılaşılan Hata Türleri ve Etkileri

Web sitesi yazılım testlerinde en sık karşılaşılan hata türleri şunlardır:

• Fonksiyonel Hatalar:
  • Web sitesinin temel işlevlerinin (örneğin, kayıt, giriş, arama, ödeme) doğru çalışmamasıdır.
  • Örneğin, bir e-ticaret sitesinde sepete ürün ekleme veya ödeme işlemlerinin başarısız olması, kullanıcıların alışveriş yapmasını engelleyerek satış kaybına neden olabilir.
  • Bir bankacılık web sitesinde para transferi işleminin başarısız olması, kullanıcıların finansal işlemlerini gerçekleştirememesine ve güven kaybına yol açabilir.
• Kullanılabilirlik Hataları:
  • Web sitesinin kullanıcı dostu olmaması, karmaşık arayüzler, anlaşılması zor navigasyonlar veya okunması güç içerikler içermesidir.
  • Örneğin, mobil cihazlarda düzgün görüntülenmeyen veya yavaş yüklenen sayfalar, kullanıcıların web sitesini terk etmesine neden olabilir.
  • Karmaşık menüler veya arama fonksiyonlarının yetersizliği, kullanıcıların aradıkları bilgilere ulaşmasını zorlaştırabilir.
  • Kullanıcıların web sitesinde gezinirken kaybolması veya istedikleri işlemleri gerçekleştirememesi, olumsuz bir kullanıcı deneyimi yaratır.
• Performans Hataları:
  • Web sitesinin yavaş yüklenmesi, çökmesi veya aşırı kaynak tüketmesidir.
  • Örneğin, yüksek trafik altında web sitesinin yanıt vermemesi veya uzun süre yüklenmesi, kullanıcıların sabrını zorlar ve web sitesini terk etmelerine neden olabilir.
  • Yavaş yükleme süreleri, arama motoru sıralamalarını da olumsuz etkileyebilir.
  • Aşırı kaynak tüketimi, sunucu maliyetlerini artırabilir ve web sitesinin genel performansını düşürebilir.
• Güvenlik Hataları:
  • Web sitesinin güvenlik açıklarının (örneğin, SQL enjeksiyonu, XSS, CSRF) bulunmasıdır.
  • Örneğin, kullanıcı verilerinin yetkisiz erişime açık olması veya hassas bilgilerin şifrelenmemiş olarak saklanması, ciddi güvenlik ihlallerine yol açabilir.
  • Güvenlik açıkları, kötü niyetli kişilerin web sitesine sızmasına ve kullanıcı verilerini çalmasına veya değiştirmesine olanak tanır.
  • Güvenlik ihlalleri, işletmelerin itibarını zedeler ve yasal sorunlara yol açabilir.
• Uyumluluk Hataları:
  • Web sitesinin farklı tarayıcılar, cihazlar veya işletim sistemlerinde düzgün çalışmamasıdır.
  • Örneğin, bir tarayıcıda düzgün görüntülenen bir sayfanın başka bir tarayıcıda bozuk görünmesi, kullanıcıların web sitesini doğru şekilde kullanamamasına neden olabilir.
  • Mobil cihazlarda uyumsuzluk, mobil kullanıcıların web sitesine erişimini kısıtlar.
  • Farklı işletim sistemleri ve ekran çözünürlüklerinde uyumsuzluk, web sitesinin tutarsız görünmesine ve çalışmasına neden olabilir.
• Kodlama Hataları:
  • Söz dizimi hataları, mantıksal hatalar ve çalışma zamanı hataları.
  • Örneğin, yanlış değişken kullanımı veya hatalı döngüler, web sitesinin beklenmedik şekilde davranmasına veya çökmesine neden olabilir.
  • Kodlama hataları, güvenlik açıklarına da yol açabilir.
• Test Eksiklikleri:
  • Yetersiz test kapsamı ve eksik test senaryoları.
  • Örneğin, web sitesinin tüm özelliklerinin veya işlevlerinin test edilmemesi, bazı hataların gözden kaçmasına neden olabilir.
  • Eksik test senaryoları, kullanıcıların karşılaşabileceği tüm durumları kapsamayabilir.

Hata Tespiti ve Giderme Süreci

Web sitesi yazılım testleri, bu hataların erken tespiti ve giderilmesi için sistematik bir süreç izler. Bu süreç genellikle şu adımları içerir:

1. Test Planlaması: Test edilecek özelliklerin, test senaryolarının ve test ortamının belirlenmesi.
2. Test Tasarımı: Test senaryolarının oluşturulması ve test verilerinin hazırlanması.
3. Test Uygulaması: Test senaryolarının çalıştırılması ve sonuçların kaydedilmesi.
4. Hata Raporlama: Tespit edilen hataların detaylı olarak raporlanması.
5. Hata Giderme: Geliştiricilerin hataları düzeltmesi ve yeniden test yapılması.
6. Test Tamamlama: Tüm testlerin tamamlanması ve test raporunun hazırlanması.

Reverse a String in Python without using any built-in Functions

 metin = """This text will be reversed without using any built-in functions"""

ters_metin = ""
i = 0
y = []
a = [0]
for x in metin:
    i = i+1
    a[0] = i
    y = y + a

for z in y:
    ters_metin = ters_metin + metin[-z]
print(metin)
print(ters_metin)

Özet Olarak Yazılım Testi Nedir

Yazılım sistemlerinin hedeflenen kullanım ortamında tam, doğru ve tutarlı olarak müşteri istek ve beklentilerine uygun çalıştığının kontrolüdür.

Ürünü En Hızlı Şekilde Nasıl Test Edebilirim?

Projelerin doğası gereği bazen regresyon testi kapsamında bazen sistemin canlıya alınmasında bazen de müşteriye yapılacak sunum öncesinde, ürünün beklendiği gibi çalıştığının doğrulamasının yapılması gerekmektedir.

Tabii ki en güvenilir yöntem %100 kapsama oranına sahip testlere sahip olmak ve test otomasyonu kullanarak tüm testleri baştan sona çalıştırmaktır. Fakat çoğu zaman bu rüya-senaryoyu gerçekleştirme imkanı olmaz. 

Böyle bir ihtiyaç varsa şu kararın verilmesi gerekir; ürünün hangi yetenekleri / isterleri daha kritiktir?
Tüm testleri koşturamayacağımıza göre risk temelli test yaklaşımı ile hangi yeteneklere odaklanmamız gerektiğini belirlememiz gerekiyor.

Bankacılık uygulamalarında bu yetenekler farklıyken, stok yönetim yazılımlarda çok daha başka yetenekler önemlidir.

En kritik yetenekler belirlendikten sonra, kritiklik derecesi yüksekten aşağıya doğru sıralanır ve en üstteki yeteneğe en çok zaman ayrılırken, listenin altına doğru inildikçe test süresi de kısaltılır.
Örneğin toplam 10 yetenek varsa ve test için de toplam 20 saat süre ayrılmışsa, 1. yetenek için 3 saat, 2. için 2,5 saat, 3. için 2 saat, ..., 10. için 20 dakika, şeklinde bir planlama yapılabilir.

Burada önemli olan bir diğer konu da testi yapacak kişinin o alandaki bilgisidir. Test altındaki yetenekle ilgili 10 yıl deneyimi olan bir test mühendisinin, 3 yıl deneyimi olan birine göre çok daha etkin test yapacağı da unutulmamalıdır. Test yöneticisinin bu durumu da göze alması önemlidir.

STANAG Doğrulama

Askeri (çoğunlukla NATO) projelerde sözleşmelerde tanımlı STANAG'lar kullanılarak ürünlerin geliştirilmesi ve doğrulanması gerekmektedir.

STANAG, Standardization Aggrement'in kısaltmasıdır ve tüm listeye buradan ulaşabilirsiniz; fakat çoğuna doğrudan erişim yoktur.

STANAG kullanılarak ürünleri geliştirmenin ve test etmenin güzel tarafı; istenen her yeteneğin detaylı olarak tanımlanmış olması, muğlaklıkların olmamasıdır. 

Zor tarafı ise, kimi STANAG 300-400 sayfa olabilmekte kimi zaman da diğer standartlara referanslar vererek binlerce sayfaya çıkabilmektedir. (Her zaman olduğu gibi) Bu zorluk aynı zamanda bir de fırsat yaratmaktadır. Sektörde bu kadar kalın dokümanları okumaya ve öğrenmeye hevesli çok kimse olmadığı için herhangi bir STANAG ailesini iyi öğrenmeniz durumunda hem yurtiçi savunma sanayinde hem de NATO ve diğer askeri oluşumlara yönelik yazılım yapan yurtdışı firmalarda kolaylıkla iş bulabilirsiniz. Fakat tekrar söyleyeyim; bu dokümanlara hâkim olmak kolay değildir. Çoğunlukla bu dokümanlara uygun olarak geliştirilen ürünler test edildiği zaman standartın ne anlattığı daha iyi anlaşılır olmaktadır.

STANAG kullanarak doğrulama yaparken dikkat edilmesi gereken konu, hazırlanacak test senaryolarının birebir standarttaki maddelerle eşleştirilmesidir; bir senaryo birden çok maddeyi içerebilir. Ve tabii her zaman olduğu gibi, izlenebilirlik matrisini de doğru ve detaylı hazırlamak önemlidir.

Başlamış bir Projeye Atanan Test Mühendisinin Yapması Gerekenler

Bir test mühendisinin projenin sözleşme aşamasında projeye dahil olması en ideal durumdur. Çünkü, henüz sözleşme aşamasında gereksinimleri inceleyebilecek, gözden geçirip yorum verebilecektir. Böylece projenin sonraki aşamalarında ortaya çıkabilecek eksiklikleri çok daha önceden tespit edebilecektir.

Ancak kimi zaman, projenin ortasından projeye dahil olmak durumunda kaldığımız çok oluyor. Gereksinimlere / ürüne / sürece hızlı bir şekilde hâkim olunabilmesi için gerekli adımları aşağıda listeledim. Bu neden önemli? Çünkü projenin kabul aşaması yaklaştığında, daha henüz sözleşmeyi / gereksinimleri bile okumamış iseniz, (muhtemelen) bir başkasının hazırladığı test senaryolarının geçerliliğinden, tamlığından, doğruluğundan asla emin olamayacaksınız demektir. "Gereksinim İzlenebilirlik Tablosu'na bakarım, her gereksinim en az bir teste atanmışsa, bence testler tamdır, doğrudur" diyemezsiniz. Evet, bu gereklidir ama yeterli şart değildir. Belki testler gereksinimlerde bahsedilen durumları karşılamıyordur? Bu riski almaya gerek yok.

1. İlk olarak mutlaka sözleşme okuyun. En kapsamlı sözleşme bile 50 sayfayı geçmez. Bir günde okur, 2-3 günde tamamına hâkim olursunuz.
2. Sözleşmede belirtilen her maddenin (ister yönetimsel ister teknik maddeler olsun) bir proje çıktısı ile karşılandığından emin olun. Örneğin, bir Test ve Değerlendirme Ana Planı ve bir de Yazılım Test Planı istenmişse, sizden önce bunların hazırlanmış olduğundan emin olun. Aylık / haftalık proje ilerlerme raporları isteniyorsa, bunların formatının, içeriklerinin belirlendiğinden emin olun; yoksa hazırlayın.
3. Sözleşme maddeleri ile Sistem Gereksinimleri arasında izlenebilirlik kurulduğundan, her bir sözleşme maddesinde belirtilen isterin, sistem gereksinim(ler)i tarafından gerçekten karşılandığından emin olun; yoksa sonradan çok sorun çıkacaktır.
4. Geri kalan dokümantasyon için V döngüsünü uygulayın.
5. Ürüne en hızlı şekilde adapte olmanın yolu:
1. Hazır test dokümanları ile sistemi test etmek,
2. Hazır kullanım dokümanı ile sistemi kullanmaktır.
3. Ayrıca, (proje ekibine, direktörlere, müşteriye,...) arada bir ürünün tanıtımını yapmak da çok faydalı olacaktır.
6. Asla varsayım yapmayın: "Nasıl olsa benden öncekiler bunları yapmıştır, dokümanları hazır, gözden geçirme de yapılmış, demek ki bunlar doğrudur" diye düşünmeyin !!!
7. Kim hazırlamış olursa olsun, kime atanmış olursa olsun, sizin işinizi etkileyen konularda kimseye güvenmeyin. Çünkü onlar da projeden ayrılıp gittiklerinde, aslında bu işlerin kısmen veya tamamen eksik olduğunu görebilirsiniz. Bu durumda da o işleri kim yapacak? :) Evet, bildiniz; siz yapacaksınız.

Bu Yöntemle Yazılım Kabul Testlerinde Başarıya Ulaşın

Projelerin kullanıma alınmadan önceki son test aşaması olan Kabul Testleri'nden önce yapılması gereken ama genelde vakit ayrılmayan önemli bir konu olan Oryantasyon'dan bahsedeceğim.

Test dokümanları genelde oldukça kapsamlı ve aşırı dikkat verilmediği sürece kolaylıkla içinde kaybolabileceğiniz belgelerdir.

Yazılım projelerinin kabul testlerinin başarıya ulaşmasında en etkili yöntemlerden biri katılımcılara verilecek olan Test Oryantasyonu'dur.

Oryantasyonun amacı, testin ilerleyişinin nasıl olacağı, hangi testte hangi yeteneklerin nasıl test edildiği, hiçbir gereksinimin gözden kaçırılmadığı, test sırasında verinin hangi kaynaktan nasıl girileceği, test çıktılarının nasıl toplanacağı ve saklanacağı, testte ortaya çıkan hataların ve isteklerin nasıl yönetileceği konularında test katılımcılarına detaylı bilgi vermektedir.

Bu yüzden, her ne kadar testten önce müşteri test belgelerini gözden geçirmiş olsa bile (ki çoğu zaman detaylı bir gözden geçirme de yap(a)maz müşteri), testin katılımcılarına (gerekirse 1-2 gün boyunca) oryantasyonun verilmesi, hem müşterinin test sürecine olan güveninin artırılmasına, hem test faaliyetine daha çok katkı sağlamasına, hem de ürünün nihai ortamdaki kullanımı sırasında ortaya çıkabilecek hataların çok daha erken farkedilmesine imkan sağlayacaktır.

Kullanıcı Tanıma Anketi (Sistem Analizi)

Geliştirilmesi planlanan yazılım sistemlerinin amacına uygun, yüksek performanslı, etkinliği yüksek ve müşteri beklentilerinin ötesine geçmesini sağlamanın en kolay yolu detaylı bir sistem analizinin yapılmasıdır.

Sistem Altsistem Tanımları dokümanının Fonksiyonel Gereksinimler kısmında sisteminin "ne yapması" gerektiği belirtilirken "Sistem Karakteristikleri" başlıklarında da yapacağı işi "nasıl yapması" gerektiği belirtilir.

Pek çok projede "Sistem Karakteristikleri" başlıkları bütçe yetersizliği, zaman darlığı veya yeterli uzmanlık olmaması sebepleri ile U/D, N/A, DSB gibi kısaltmalar konularak boş bırakılır.

Sistem kullanıma alındıktan sonra da kullanılabilirlik, erişebilirlik, performans, idame edilebilirlik, gibi konularda ardı ardına sorunlar yaşanmaya başlanır.

Standartlara uygun proje geliştiren şirketler çoğunlukla (kısmen de olsa) "Sistem Karakteristikleri"ni belirlemeye çalışmaktadır. Ancak daha düşük bütçeyle iş yapan şirketlerin bu tarz belgeler oluşturma imkanı olmayabilir.

Bu sebeple, bu tarz şirketlerin kullanımı için, son kullanıcıları tanımaya yönelik soruları aşağıda listeledim. Bu sorulara ek sorular da eklenebilir. Sorulara verilecek cevaplara uygun olarak geliştirilecek yazılım sistemlerinin çok daha az hata içeren ve yüksek müşteri memnuniyeti içeren sistemler haline geleceğine emin olabilirsiniz.

Kullanıcı Beklentileri: 

• Kullanıcıların sistemden beklentileri nelerdir?
• Mevcut durumda ne tip işlerde ne tip maliyetler / zararlar oluyor?
• Kullanıcıların bilgisayar okuryazarlığı hangi seviyededir?
• Kullanıcılar içinde bedensel / zihinsel engeli olanlar var mı? Ne tür engelleri var?
• Sistem tek bir yerleşke içinde mi kullanılacak yoksa geniş bir alanda mı?

Kullanıcıları Tanıma:

• Toplam kaç kullanıcı olacak? Önümüzdeki 5 yılda kullanıcı sayısında tahminen kaç kişilik bir artış olur?
• Hangi rollerde kullanıcılar olacak? Yönetici, sistem yöneticisi, veri giriş, raporlama / sunum, …
• Rollere göre kullanıcı sayıları nedir?
• Rollere göre kullanıcılar hangi gün ve saatlerde sistemi kullanacaklar?
• Rollere göre hangi kullanıcı sistemi ne kadar süre kullanacak?
• Rollere göre kullanıcıların en stresli / yoğun / yorucu iş akış(lar)ı nelerdir?
• Rollere göre kullanıcıların çalışma ortamı kısıtları var mı? Sahada kullanım gibi.
• Rollere göre kullanıcı için en kritik / beklemeye tahammül edemeyeceği iş akış(lar)ı nelerdir?
• Kullanıcıların uygulama üzerinden ve/veya dosya sistemi / veritabanı üzerinden girecekleri veri tipleri nelerdir?
• Kullanıcıların girecekleri veri dosyalarının adet ve/veya boyut sınırı var mıdır?
• Kullanıcıların sisteme toplu halde girmeleri gereken veriler ve/veya başka bir sistemden aktarılması gereken veriler var mı?
• İşin zorluklarını ve olası dar boğazlarını anlamak açısından bir müddet çalışma ortamında kullanıcılar ile birlikte vakit geçirmemiz mümkün mü?

Kullanıcı Eğitimi:

• Kullanıcılara hangi konularda eğitim verilecek?
• Eğitim hangi ortamda yapılacak?
• Eğitim sırasında (projenin ilk aşamasında) Kullanabilirlik testi için prototip hazırlanması.
• Toplamda hangi rolde kaç kullanıcı eğitim alacak?
• Eğitim materyali nelerden oluşacak?

Donanım/Yazılım Altyapısını Tanıma:

Yazılım:

• Kullanılan işletim sistem(ler)i nelerdir?
• Kullanılan internet gezginlerinin isimleri ve versiyonları nedir?
• İnternet Gezginleri'nde yüklü addon - pluginler var mı?
• İnternet gezginlerinin / pluginlerin güncellenmesine izin verilmekte midir?
• Kullanıcı doğrulama için LDAP benzeri bir sistem var mıdır?

Donanım:

• Sistemin kullanılacağı tesis(ler)in fiziksel altyapısı nedir? Kablosuz iletişim gerekli ise, ortam uygun mudur?
• Kullanıcıların sistemi kullanacakları donanımın (bilgisayar, tablet, telefon) özellikleri nelerdir? Rollere göre hangi tip donanımlar kullanılacaktır?

Kalite Karakteristikleri:

• Sistemin herhangi bir çevresel şart kısıtı var mıdır? Sıcaklık, nem, toz, gürültü, sarsıntı, ...
• Sistemin kullanılacağı tesis(ler)in donanım altyapısı nedir? Ağ hızı, sunucu sayısı, elektrik altyapısı, jeneratör / UPS varlığı, …
• Sistemin Genişleyebilirlik ihtiyacı var mı? Sınırları nedir?
• Sistemin Yedekleme ihtiyacı var mı? Nasıl bir süreç düşünülüyor?
• Sistemin uyması gereken bir Sertifikasyon kısıtı var mı?
• Sistemin birlikte çalışması gereken (Uyumluluk) başka sistemler var mı? Arayüzler ve veri tipleri nedir?
• Sistemin Kaynak Kullanım kısıtları var mı? CPU, bellek, disk alanı, ağ kapasitesi kullanım sınırları gibi.
• Sistemin Afet Kurtarma özelliği ihtiyacı var mı?
• Sistemin Efficiency (belirli bir yük için kaynak tüketimi) kısıtı var mı?
• Sistemin Effectiveness (harcanan efor sonrasında elde edilen performans) kısıtı var mı? Bir işlemin en fazla 3 adımda yapılması gibi.
• Sistemin uyması gereken bir yasal mevzuat / standart var mı? Nedir?
• Sistemin Performans (tepki süreleri) kısıtı var mı? Hangi yük altında bu süreler nedir?
• Sistemin Platform Uyumluluk kısıtı var mı? Hangi platformlar?
• Sistemin veri / bilgi Gizliliği kısıtı var mı? Ne tür veriler, hangi roldeki kullanıcılar?
• Sistemin Kurtarılabilme (Recovery / recoverability) kısıtı var mı? Ölümcül hata durumunda en geç 5 dakikada sistemin faal hale gelmesi gibi.
• Sistemin Bakımı için izin verilen gün / saatler nelerdir?
• Sistem için Hizmet Seviyesi Anlaşma şartları nelerdir?

Kullanıcı Destek:

• Kullanıcıların eğitim sonrası sorunlarında hangi yöntem ile yardımcı olunacak?
• Bir Destek Merkezi kurulması ihtiyacı var mı?
• Destek hangi ortam üzerinden sağlanacak? E-posta, telefon, video konferans, …
• Soru ve hata bildirimleri nerede kayıt altına alınacak?

İş Hayatında Öne Çıkan Yetkinlikler

Uzun yılların birikimi olarak rahatlıkla şunu söyleyebilirim; iş hayatında başarılı olmak için gereken yetkinlikler teknik bilgiden ziyade sosyal yetkinlik ve etik değerlerden oluşuyor.

Aşağıdaki liste tam olmayabilir ama iş hayatında saygı duyulan ve takdir edilen bir çalışan olmak için gerekli özelliklerin bunlardan oluştuğunu düşünüyorum:

1. İşe erken gelmek, geç çıkmak.
2. Yöneticilerin isteklerine olumlu cevap vermek.
3. Zor işlere talip olmak.
4. İş önceliklendirmesi yapmak; önemsiz işleri sonraya ertelemek, öncelikli işlere daha fazla efor harcamak.
5. İş saatlerinde sadece ve sadece işle uğraşmak.
6. Altına imza attığınız, içinde isminiz geçen işleri en iyi şekilde yapmaya çalışmak.
7. Şirket kaynaklarını özel işleriniz için kullanmamak.
8. Şirket kaynaklarının israfını engellemek.
9. Şirket süreçlerini ve kültürünü sürekli iyileştirmek.
10. Birlikle çalıştığınız kişilerin bireysel gelişimlerini desteklemek.
11. Kişilerin başarılarını diğer çalışanlarla paylaşmak, hatalı yaptıklarını ise sadece o kişiyle paylaşmak.
12. Kendinizde eksik gördüğünüz alanlarda sürekli eğitimle gelişim sağlamak.

Mikro ve Küçük Ölçekli Yazılım Firmaları için Test Stratejileri

24.06.2018'de güncellenen KOBİ tanımına göre Mikro Ölçekli firmalar çalışan personel sayısı 10'dan az olan ve Küçük Ölçekli firmalar da çalışan personel sayısı 50'den az olan firmalardır.

Nakit akışı, yüksek ve düzenli kâr bırakan pazarlara erişim, çalışan motivasyonunu yüksek tutamamak gibi yönetim seviyesi zorluklar bir yana, az sayıdaki personelin pek çok farklı faaliyeti yoğun ve fazla mesai yaparak gerçekleştirmeleri sonucu hatalar yapılabilmekte, bu da nihai ürünün toplam kalitesinde zayıflığa ve müşteri memnuniyetsizliğine sebep olabilmektedir.

Bir soru sorarak başlayalım: 
Mikro ve küçük ölçekli yazılım firmalarının nihai müşteri memnuniyetlerini nasıl yükseltebiliriz?
Şunu belirtmekte fayda var: bu firmaların CMMI, SPICE, ISO 12207 gibi ağır metodolojilere uymaya yetecek kaynakları çoğunlukla olmayacaktır. Hatta bazen çevik yöntemleri bile uygulamakta zorlanabilirler.

Tümdengelim yaparsak; 

• Müşteriler ne kadar az hata ile karşılaşırlarsa o kadar "Düzelt-Test Et-Yayınla" döngüsü işletilir,
• Ürünün kullanımı ne kadar kolaysa o kadar az eğitim / kullanım desteği verilmesi gerekecektir,
• Personel teslimat sonrası ne kadar az hata ve destek ile uğraşırsa, bir sonraki ürünü geliştirmek için daha çok zamanı olacaktır.

"Test Mühendisliğinde Olası Riskler ve Alınabilecek Tedbirler" başlıklı yazımda belirttiğim pek çok durum firmanızın işleri zorlaştırıyor olabilir ancak sorunun özü kısıtlı kaynaklar sebebiyle firmaların Test ve dokümantasyona yeterince zaman harcayamamalarıdır.

Aşağıda, bu sorunu çözmeye katkı sağlayabileceğini düşündüğüm maddeleri veriyorum. Firmanızın kaynaklarına ve yapısına en uygun yöntemi yine kendiniz belirleyebilirsiniz. Bunların uygulanması konusunda veya firmanızın yapısına özel sorularınız olursa da yardımcı olmaya çalışırım.

• PERSONEL:

1. İmkanınız varsa, mesleği test mühendisliği olan personel istihdam edin. Yazılımı geliştirenler (ve müşteriler) test yapmaktan genelde hoşlanmaz, bazen üstünkörü yaparlar, genelde de sadece "happy path"i test ederler. 1 kişi bile olsa istihdam edeceğiniz test mühendisi, müşteriden dönme ihtimali olan hataları çok büyük oranda azaltacaktır. Eğitim dokümantasyonu, müşteri desteği vermesi de cabası; çünkü sistemin genelini (çoğu zaman) en iyi bilen kişi test mühendisidir. 
2. Sürekli olarak test mühendisi istihdam edemiyorsanız, stajyer / yarı-zamanlı çalışacak öğrencilere test yaptırabilirsiniz. Fakat bu personelin "test  mühendisi bakış açısı" olmadığından bu konuda eğitim almaları gerekecektir, bir danışmanın vereceği 2 günlük bir eğitim bile çok fark yaratacaktır. Aksi durumda çok fayda sağlanamayabilir. 
3. Sürekli veya yarı zamanlı personel istihdamı da sizin için mümkün değilse, yine mesleği test mühendisliği olan bir danışman sadece ihtiyaç zamanlarında size destek verebilir.  Bu ihtiyaç zamanları şunlar olabilir:
• Projenin ilk aşamasında sözleşme / sistem gereksinimlerinin gözden geçirilmesi ve bir ana test planı / stratejisi hazırlanması,
• Sistem tasarımı sonrasında sistem seviyesi test senaryolarının ("Öncelikli Senaryo") yazılması,
• Ara teslimat dönemlerinden önce testlerin koşturulması ("Detaylı Senaryo"),
• Nihai teslimat öncesinde tüm senaryoların koşturulması.

"PERSONEL" konusunu çözüme ulaştırdıysanız;

• TEST SÜRECİ: 

1. Mutlaka gereksinim yönetimi yapılmalı. Böylece hiçbir istek/gereksinim göz kaçamaz.
2. Müşterinin en çok önem verdiği, olmazsa olmaz dediği, beklemeye tahammül edemeyeceği işlevlerin neler olduğunu listeleyin. Bu işlevler belirlenirken kullanıcı ile empati kurabilmek çok önemlidir.
• "Kullanıcı ile Empati Kurabilmek Neden Önemlidir?"
3. Risk temelli test yaklaşımı ile bu listedeki maddelerin tamamını üst seviyede test eden bir senaryo oluşturun ("Öncelikli Senaryo").
4. Her teslimat öncesi "Öncelikli Senaryo"yu mutlaka çalıştırın.
5. "Öncelikli Senaryo"yu alt parçalara ayırıp detaylı senaryolar hazırlayın ("Detaylı Senaryo").
6. Geri kalan kısımlar için "İkincil Senaryolar" oluşturun.
7. Teslimatları ayda bir yaptığınızı varsayarsak, haftada 1 kere "Öncelikli Senaryo", 2 haftada 1 "Detaylı Senaryo", ayda 1 kere de "İkincil Senaryolar"ı koşturabilirsiniz.
• "Ürün bitsin, testleri sonra yaparız" diye düşünmeyin, böyle bir yaklaşım kaosa davetiye çıkartmaktır.
8. Eğer resmi bir "Kabul Testi" yapılacaksa, "Kabul Testi Nedir, Nelere Dikkat Etmek Gerekir" başlıklı yazımda belirttiklerim uygulanmalı.

• HATA YÖNETİMİ:

1. Proje ilerledikçe hata sayıları da doğal olarak artacaktır.
2. Eğer müşteriye bir ara ürün / demo ürünü teslimatı yapılmışsa, önem derecesi ne olursa olsun müşteriden gelen hata bildirimlerine öncelik verin ve en kısa zamanda ilk onları çözün ("ÖNCELİK 1").
• Bizler için önemsiz gibi görünen hatalar, son kullanıcı gözünde çok önemli olabilir.
3.  "Öncelikli Senaryo" ve "Detaylı Senaryo"dan bulunan hatalara 2. seviye öncelik verin ("ÖNCELİK 2").
4. "İkincil Senaryo"dan bulunan hatalara 3. seviye öncelik verin ("ÖNCELİK 3").
5. Firmanıza daha yüksek katma değer sağlayacak ve müşteri memnuniyetini artıracak hata çözüm sırası da doğal olarak ÖNCELİK 1 > ÖNCELİK 2 > ÖNCELİK 3 şeklindedir.
6. Jira, Mantis veya diğer bir hata yönetim uygulaması kullanmak şarttır. Mümkünse son kullanıcıların da bu sistem üzerinde hata açabilmelerini sağlamak geri bildirim hızınızı artıracaktır. 
• Şurada hazırladığım yapıyı kullanabilirsiniz: Testlerde Hata Bildiriminde Dikkat Edilmesi Gereken Girdiler

• DOKÜMANTASYON:

1. Kod içinde mutlaka "comment"ler ile neyin ne iş yaptığını belirtmek, hata düzeltme ve bakım dönemlerinde hayat kurtarıcı olmaktadır.
2. Müşteriniz eğer formal test dokümantasyonu istiyorsa (örneğin TÜBİTAK), Mil-Std-498'i kullanabilirsiniz, ücretsizdir.
3. Uygulamanın kurulumu ve kullanımı ile ilgili kısa da bir belgeyi tercihen web sayfası veya uygulamanın içine entegre olarak hazırlamanız, sonrasında kullanımla ilgili gelecek pek çok sorudan kurtaracaktır sizi.
4. Ürünün kapsamlı eğitimi gerekiyorsa, ürün olgunlaştıktan sonra eğitim videosu hazırlayarak maliyeti azaltabilirsiniz.

• ARAÇ KULLANIMI:

1. Eğer ürününüz test otomasyonuna uygunsa, personelinizin bu konuda deneyimi varsa ve en önemlisi otomasyona alınan testlerin çok sık güncellenmesi gerekmeyecekse, test otomasyonu fayda sağlayacaktır. Ancak uyarmam gerekir: bu iş ayrı bir uzmanlık alanıdır ve kimi zaman faydadan çok zarar da verebilir.
2. Sadece açık kaynaklı test araçlarından faydalanın. Ticari test araçları genelde fazlasıyla pahalıdır, eğitim / destek maliyeti olabilmektedir, alınan araç âtıl kalabilmektedir.
3. Test verisi hazırlama ve kaynak kodu sık değişmeyecek kısımlar için otomasyon kodu yazılabilir. Bir kere yaparsınız, proje boyunca sizi tekrarlayan işlerden kurtarır.

Fonksiyonel Olmayan Gereksinimler: Uygunluk

Kullanıcıların, "normal çalışma zamanlarında" sistemin çalışabilir olduğuna güvenme derecesidir. Diğer bir deyişle, kullanıcılar normal çalışma saatlerinde sistemi kullanmak istediklerinde sistemin kullanıcı isteklerine cevap verebiliyor olması gerekmektedir.

Örnekleyecek olursak;

• Çevrimiçi Ödeme Sistemi saat 06 ile 23 arasında kullanıma uygun olmalıdır.
• Çevrimiçi Ödeme Sistemi 100 saatlik MTBF (Mean Time Between Failures - Arızalar Arasındaki Ortalama Süre) değerine sahip olması gerekmektedir.
• Çevrimiçi Ödeme Sistemi, kullanıcıların isteklerinin %95'ine 15 saniye içinde cevap verebilmelidir. Geri kalan zamanlarda 20 saniye içinde cevap verebilmelidir.
• ATM cihazı hafta içi günlerde saat 06 ile 23 arasında %99 oranında uygun olmalıdır. 
• Sistemin yeni bir kurulumu, kurulum işlemi başlatıldıktan sonra 24 saat içinde ilk kullanıma hazır olmalıdır.
• Sistem kullanıma kapatıldıktan sonra sistemin veritabanı yedeği 15 dakika içinde alınabilmelidir.
• Sisteme kapatma komutu gönderildikten sonra 3 dakika içinde sistem kapanmış olmalıdır.
• Acil durum veri silme komutu gönderildiğinde 15 saniye içinde her 3 sabit diskteki tüm veri geri kurtarılamaz şekilde silinmelidir. 

Fonksiyonel Olmayan Gereksinimler: Hayatta Kalabilirlik

Bir sistem arızası ortaya çıktığında yazılım sisteminin kendini toparlaması ve çalışmaya devam etmesinin ölçüsüdür.

Örnekleyecek olursak;

• Denetleme yazılımı arıza sonrası kapanırsa kullanıcının sözleşme dosyasında yaptığı değişiklikler kurtarılmalı ve dosya arıza oluşumundan bir dakika öncesindeki duruma gelmeli.
• Yazılımın güncellenmesi sırasında bir arıza ortaya çıkarsa yapılan tüm veri ve güncellemeler geri alınmalı ve yazılım eski haline dönmelidir.
• Bir arıza durumu sonrasında işletime devam edilirken kullanıcıya yazılımın "güvenli mod"da çalıştığı ve tüm verinin salt okunur durumda gözden geçirmeye hazır olduğunun bilgisi verilmelidir.
• Sistem, arızalı olduğu tespit edilen yeteneklere erişimi engellerken diğer tüm yeteneklere erişime izin vermelidir.
• Montaj hattındaki tüm donanım bileşenleri yedekli olmalıdır, böylece herhangi bir donanım bileşeni arızalandığında montaj hattının durması engellenmelidir.

Testler Ne Zaman Biter?

Yazılım sektöründe bir süre çalışanların çok iyi bildiği gibi, yazılım ve sistem projelerinin karmaşıklık sebebiyle, test edilebilecek patikaların sayısı neredeyse sonsuzdur. Ve proje yöneticilerinin en sık sorduğu sorulardan biri "testler ne zaman biter"dir.

Öncelikle testlerin sayısının neden çok olabileceğini inceleyelim.

Örnek olarak E-Devlet giriş sayfasını kullanabiliriz.

Uygulayabileceğimiz testleri listeleyelim:

1. T.C. Kimlik No alanı ve e-Devlet Şifresi alanını boş bırak, "Sisteme Giriş Yap" düğmesine tıkla,
2. T.C. Kimlik No alanına geçerli değer gir ve e-Devlet Şifresi alanını boş bırak, "Sisteme Giriş Yap" düğmesine tıkla,
3. T.C. Kimlik No alanını boş bırak ve e-Devlet Şifresi alanına geçerli değer gir, "Sisteme Giriş Yap" düğmesine tıkla,
4. T.C. Kimlik No alanına boşluk karakteri gir ve e-Devlet Şifresi alanına boşluk karakteri gir, "Sisteme Giriş Yap" düğmesine tıkla,
5. T.C. Kimlik No alanına geçerli değer gir ve e-Devlet Şifresi alanına boşluk karakteri gir, "Sisteme Giriş Yap" düğmesine tıkla,
6. T.C. Kimlik No alanına boşluk karakter gir ve e-Devlet Şifresi alanına geçerli değer gir, "Sisteme Giriş Yap" düğmesine tıkla,
7. T.C. Kimlik No alanına 500 adet karakter gir ve e-Devlet Şifresi alanına 500 adet karakter gir, "Sisteme Giriş Yap" düğmesine tıkla,
8. T.C. Kimlik No alanına Kopyala-Yapıştır ile 10 karakterlik değer gir ve e-Devlet Şifresi alanına Kopyala-Yapıştır ile 10 karakterlik değer gir, "Sisteme Giriş Yap" düğmesine tıkla,
9. 1-8 arasındaki testleri tekrarla, "Sisteme Giriş Yap" düğmesine tıklamak yerine klavyedeki ENTER tuşuna bas,
10.  T.C. Kimlik No alanına geçerli bir değer gir ve e-Devlet Şifresi alanına geçerli değer gir, "Sisteme Giriş Yap" düğmesine tıkla,

Yukarıda tanımlanan 10 (aslında 17) adet teste daha pek çok test eklenebilir. 

Görüldüğü üzere sadece 2 tane alan için bile bu kadar test tanımlanabiliyorken, yüzlerce ekran ve binlerce veri giriş alanı / kontrol düğmesi içeren, birden fazla yazılım ve donanımın entegre olduğu, yedekli veritabanı sistemleri, yük dengeleyiciler, CBS yazılımları, masaüstü / web / mobil arayüzleri olan devasa bir sistemde, yapılabilecek testlerin sayısı (sonsuz olmasa bile) on binlere ulaşabilir.

Peki soru şu: Testler ne zaman biter?

1. Atanan efor / süre bittiğinde: Proje takviminde test için ayrılan süre bittiğinde,
2. Test durumları belirli bir başarı yüzdesine ulaştığında,
3. Hata oranı belirli bir yüzdenin altına indiğinde,
4. Tüm gereksinimler %100 doğrulandığında
• Gereksinimlerin %100 doğrulanmış olmasının, geçilebilecek tüm patikalardan geçildiği anlamına gelmediğini de belirteyim.

Anlaşıldığı üzere, bir sistemi %100 test etmek hem ekonomik değil hem de kimi durumlarda mümkün değildir.

Bunun istisnası, görev-kritik yazılımlardır; hata yapması durumunda insan yaşamına ve ülke güvenliğine ciddi zararları olabilecek yazılımlar için yazılan birim testlerin %100 kapsama oranına sahip olması beklenmektedir.

Peki, madem sistemi %100 test etmek ekonomik / mümkün değil, o zaman "nasıl bir test stratejisi izlersek hem sistemi yeterli derecede test etmiş oluruz hem de hataların büyük kısmını müşteri ortamına kurulum yapılmadan önce tespit etmiş oluruz?".

Bu da bir başka yazının konusu: En Uygun Test Stratejisini Nasıl Belirleriz?

Yazılım Testi ile Sistem Testi Arasında Ne Fark Vardır?

Sistem, yazılım ürünleri ile (kimi zaman) donanım ürünlerinin birleşiminden oluşmuş yapıya verilen isimdir.
Yazılım ise sadece yazılım ürünleri ve destekleyici konfigürasyon ve veri dosyalarından oluşan yapıya verilen isimdir.

Eğer geliştirilen ürün, sadece yazılım parçalarından oluşuyorsa, bu bütüne yazılım sistemi adı da verilebilmektedir.

Test açısından bakıldığında yazılım testi ile ifade edilen;

• yazılım seviyesi gereksinimlerin doğrulandığı,
• normal girdiler haricinde sınır değerlerin, boş değerlerin, hatalı ve eksik değerlerin de testlere dahil edildiği,
• testin akışının (test betiği / test durumu) sadece hedeflenen fonksiyonu test ettiği 

yapı anlaşılır.

Sistem testi dendiğinde ise;

• sistem seviyesi fonksiyonel gereksinimler ile kalite karakteristiklerinin doğrulandığı,
• (çok büyük çoğunlukla) sadece normal girdilerin testlere dahil edildiği,
• çünkü yazılım seviyesi testlerde ekranlardaki / servislerdeki sınır değerler vesaireyi zaten test ettik,
• belirli bir operasyonel konsept senaryosu kullanılarak sistemi baştan sona bir ana akış dahilinde test eden,
• yazılımın, sistemin diğer bileşenleri olan donanım ürünleri etkileşiminin de test edildiği,

bir yapı anlaşılır.

Yazılım testleri de birer senaryo dahilinde işletilir ama bu senaryolar sadece bir veya birkaç fonksiyonu içerir. 

Taşınabilirlik Gereksinimi Örnekleri

Yazılım sisteminin bulunduğu mevcut donanımdan veya yazılım ortamından bir başka donanıma / ortama kolay taşınabilmesine yönelik gereksinim türüdür.

Örnekler:

1. Hesap Hareketleri İşleme Sistemi tarafından kaydedilen tüm zaman damgaları kalıcı depolama birimine yerleştirildiklerinde Evrensel Koordine Zaman yapısında olmalıdır.
2. Bir zaman değerinin kullanıcıya görüntülendiği her yerde zaman kuşağı belirgin olarak görüntülenmelidir.
3. Ürünün, önümüzdeki sene Avrupa pazarında satışı hedeflenmektedir.
4. Ürün, işyeri ofislerinde çalışacak şekilde tasarlanmıştır ancak, üretim montaj fabrikalarında çalışacak olan bir sürüm de amaçlanmaktadır.
5. Sistem, Microsoft Windows 10 ve Macintosh işletim sistemleri için geliştirilmelidir.
6. "EvMuhasebesi" yazılımı en az aşağıdaki özelliklerdeki kişisel bilgisayarlar veya iş istasyonlarına taşınabilir olmalıdır:
1. En az 16-bit renk destekli 15 inç ve üzeri monitör,
2. Asgari 1GB disk alanı.

Bütünlük Gereksinimi Örnekleri

(Integrity'nin karşılığı olarak Bütünlük - Tamlık kullanılmakta. Bu tanıma Dürüstlük kavramını da eklemek gerekiyor)

Yazılım sistemi tarafından idame ettirilen verinin kesin, tam, gerçek ve doğru olma seviyesine yönelik gereksinim türüdür.

Örnekler:

1. Tüm mali değerler noktadan sonra 2 haneye kadar doğru olmalıdır.
2. Depo sıcaklık değerleri artı / eksi 2 santigrat derece kesinliğe sahip olmalıdır.
3. Proje belgelerinde yapılan değişikliklerin sebebi bir veritabanı veya eşdeğer bir teknoloji ile kayıt altına alınacak ve düzenli olarak yedeklenecektir. Bu işlem, disklerde veri kaybı olması durumunda belgelerde yapılan değişiklikleri belirlemek için gerekmektedir.
4. Kredi Sorgulama Sistemi, tüm yuvarlama hesaplarını önce noktadan sonra 5 haneye kadar yapmalı, ardından da noktadan sonra 2 haneye kadar yapmalıdır.
5. Sistem verisinin bütünlüğü, dahili kontrol sistemi tarafından saniyede 2 defa gözden geçirilmelidir; eğer veride tutatsızlık tespit edilirse, sistemin işlem yapmasına izin verilmemelidir.