Wednesday, November 14, 2018

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. 

Tuesday, November 13, 2018

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.

Monday, November 12, 2018

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?

Friday, July 20, 2018

Günde 1 Tanenin Gücü

Hepimizin hayatta amaçları ve hayalleri var. Bu amaçlara ve hayallere ulaşmak için ise çok azımız plan yapıyor, daha da azımız bu planları düzenli bir şekilde uyguluyor.

"Günde 1 Tane" ile kastettiğim şey, bizleri bu amaçlara ulaştıracak plan maddelerini her gün birer birer uygulamak. Bu konuda özlü sözler de var, örneğin, "100 kilometrelik bir yolculuk, her seferinde bir adım atılarak bitirilebilir", "bir pastayı nasıl yersiniz? küçük birer ısırık ile", ... 

"Günde 1 Tane" yaklaşımı ile neleri başarabileceğimize bir bakalım.

  • Günde 1 blog yazısı yazarak bir senede 365 makaleden oluşan bir blog sitemiz olabilir,
  • Günde 1 sayfa yazarak bir senede 365 sayfalık bir kitap yazabiliriz,
  • Günde 1 kelime öğrenerek bir senede 365 yeni kelime öğrenebiliriz,
  • Günde 1 kilometre yürüyerek sağlığımızı koruyabiliriz,
  • Günde 1 yeni kişiyle tanışarak senede 365 yeni insanla tanışmış ve iş ağımızı / çevremizi genişletmiş oluruz,
  • Günde 1 video kaydederek senede 365 videodan oluşan bir Youtube arşivimiz olur (öyle ki, bu videolar zamanla bize reklam geliri ile kazanç sağlar),
  • ...


"Günde 1 Tane" dediğimizde illaki "1" olmak zorunda da değildir, bu rakamı kendiniz belirleyebilirsiniz.

  • Günde 10 TL biriktirerek senede 3650 TL (yani gayet iyi bir tatil parası) biriktirebiliriz,
  • Günde 10 sayfa okuyarak her ay bir yeni kitap bitirebiliriz.


Burada önemli olan 1, 10, 100 olması değil, bu yöntemin her gün uygulanmasıdır.
Düşündüğünüz zaman size kolay gelebilir ama yapacağınız şey her ne olursa olsun, bunu her gün yapmak gerçekten çok zordur.

Fakat zor olması sizi korkutmasın; zor geldiği için pek çok insan amaçları doğrultusunda düzenli çalışmıyor ve sonuçta sizi, diğer insanlardan farklı kılacak şey de onların yapamadığını yapmak olacaktır.

Şöyle düşünelim. Türkiye'de sizinle aynı meslekte, sizinle aynı yaş grubunda bulunan 50.000 kişi olduğunu varsayalım. Eğer,

  • Kendi alanınız ile ilgili olarak, her gün 10 sayfa okursanız, senede 12 yeni kitap bitirirsiniz (kaldı ki çoğu insan kendi alanlarında meslek hayatları boyunca bile 12 kitap okumuyor),
  • Kendi alanınız ile ilgili olarak, her hafta 1 eğitim videosu / konferans kaydı izlerseniz, senede 52 yeni konuda bilgi sahibi olursunuz,
  • Kendi alanınız ile ilgili olarak, her hafta bir blog makalesi yazarsanız, senede 52 adet blog yazınız olur ( bu da sizin konuya olan ilginizi ve konu hakkındaki bilginizi ortaya koyar).

Örnekler çoğaltılabilir. Sadece bu 3 maddeyi sadece 1 sene uygulamanız durumunda bile sizinle aynı alanda çalışan ve dolayısıyla sizin rakibiniz olan akranlarınızın %90'ından daha bilgili, daha tecrübeli hâle gelirsiniz. Bu yöntemi 3 sene boyunca uygulayın, ülkedeki sizin alanınızdaki insanların %99'undan daha iyi olacağınız kesindir.

Sonuç olarak: hayattaki amaçlarınız belli ise, bu amaçları gerçekleştirmek için Günde 1 Tane yöntemini kullanmanız durumunda başarılı olmanız neredeyse kesindir.

Monday, March 19, 2018

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. 

Tuesday, March 13, 2018

Test Metrikleri

Bir sistem, sistem bileşeni veya sürecin sahip olduğu bir özelliğin derecesini gösteren nicel ölçüme "metrik" adını veriyoruz.

Yazılım testi metrikleri, test faaliyetlerinin ölçümü ve takibini kolaylaştırmak amacıyla kullanılmaktadır.
Metrikler testlerin ilerleyişini, üretkenliği ve test edilen sistemin kalitesi ile ilgili öngörüler de sağlamaktadır. Metrikler "Neleri test ettik?" sorusunun cevabı olarak "her şeyi test ettik" tarzı bir cevaptan çok daha tutarlı ve anlaşılır cevaplar sunmaktadır.

Test metriklerini oluşturmanın amacı projenin ilerleyişi hakkında bilgi sahibi olmak, hesap verebilmek, olası sorunları önceden tespit edip önlem almaktır. 


Aşağıda uzun bir liste halinde test metrikleri listelenmiştir. Bunlara proje ihtiyaçlarınıza göre yenilerini de ekleyebilir, var olanlardan yeni metrikler türetebilirsiniz. Burada önemli olan, sadece amaçlarınıza hizmet eden, size fayda sağlayacak metrikleri toplamaktır.


Temel Metrikler:


  1. Test durumlarının sayısı
  2. "Geçti" durumundaki test durumlarının sayısı
  3. "Kaldı" durumundaki test durumlarının sayısı
  4. "Bloke" durumundaki test durumlarının sayısı
  5. Tespit edilen bulgu sayısı
  6. "Hata" olarak kabul edilmiş bulgu sayısı
  7. "Hata Değil" olarak kabul edilmiş bulgu sayısı
  8. "Çözümü Ertelenen" bulgu sayısı
  9. Kritik hata sayısı
  10. Test başına planlanan süreler
  11. Test başına gerçekleşen süreler
  12. Teslimat sonrası bulunan hata sayısı
Test Takibi Metrikleri:
  1. "Geçti" durumundaki testlerin oranı % = 100 * ("Geçti" durumundaki test durumlarının sayısı) / (Toplam test durumu sayısı)
  2. "Kaldı" durumundaki testlerin oranı % = 100 * ("Kaldı" durumundaki test durumlarının sayısı) / (Toplam test durumu sayısı)
  3. "Bloke" durumundaki testlerin oranı % = 100 * ("Bloke" durumundaki test durumlarının sayısı) / (Toplam test durumu sayısı)
Test Etkinliği Metrikleri:
  1. "Hata" olarak kabul edilen bulgu oranı % = 100 * ("Hata" olarak kabul edilmiş bulgu sayısı) / (Toplam bulgu sayısı)
  2. "Hata Değil" olarak kabul edilen bulgu oranı % = 100 * ("Hata Değil" olarak kabul edilmiş bulgu sayısı) / (Toplam bulgu sayısı)



Test Eforu:
Test eforu metrikleri, testlerin kaç defa yapılacağı, ne kadar zaman alacağı ve ne kadara mâl olacağı sorularına yöneliktir. Bu metrikler, ileri dönemlerde yapılacak test planlaması için temel teşkil edecektir. Ancak unutulmamalıdır ki bu metrikler ortalama değerleri göstermektedir. 

Bu metriklere örnek olarak aşağıdakiler verilebilir:

  1. Belirli bir zaman periyodu başına düşen test koşusu sayısı = (Toplam koşulan test sayısı) / (Toplam süre)
  2. Test tasarımının etkinliği = (Tasarımı yapılan test sayısı) / (Toplam süre)
  3. Test gözden geçirme etkinliği = (Gözden geçirilen test sayısı) / (Toplam süre)
  4. Saat başına düşen tespit edilmiş hata sayısı = (Tespit edilen hata sayısı) / (Saat cinsinden toplam süre)
  5. Test başına düşen hata sayısı = (Tespit edilen hata sayısı) / (Test sayısı)



#! Devam edecek...

Testlerin Yeterliliği:

Test Kapsama Oranları:

Test Maliyetleri:

Hata Dağılımları:

Saturday, March 3, 2018

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.

Wednesday, February 28, 2018

Gizlilik Gereksinimi Örnekleri

Yazılım sisteminin hassas veriyi koruma ve sadece yetkili kullanıcıların erişimine izin verme derecesini belirleyen gereksinim türüdür.

Örnekler:

  1. T.C. Kimlik Numarası'nın sisteme girişi sırasında veya sonrasında hiçbir kısmı görüntülenmeyecektir. Basılı belgeler üzerinde sadece son 4 rakamı görünür olacaktır.
  2. Hasta Verileri Sistemi sadece hastanın ıslak imzalı izni olduğu durumlarda hastanın kayıtlarına erişim izni verecektir.
  3. Sistemde kayıtlı her veri türünün gizlilik dereceleri olacaktır. Her veri türü içindeki tekil veriye farklı seviyelerde gizlilik dereceleri atanabilecektir. Bir kullanıcı sadece kendi yetki seviyesi ve bunun altındaki seviyedeki gizlilik derecesine sahip veriye erişim sağlayabilmelidir.
  4. "Gizli" gizlilik derecesindeki ve daha üst seviyedeki gizlilik derecesindeki veri hiçbir surette harici bir ortama kaydedilemeyecek ve/veya basılı hale getirilemeyecektir.

Kullanılabilirlik Gereksinimi Örnekleri

Kullanıcının, sistem ile etkileşim kurarak öğrenme, işlem yapma, girdileri hazırlama ve çıktıları yorumlamasının kolay olmasına yönelik gereksinim türüdür.

Aşağıdaki gereksinim örnekleri okuduğunuzda göreceksiniz ki Kullanılabilirlik gereksinimlerini sadece yazılım ürünleri için değil hemen hemen tüm ürün ve hzimetler için geçerlidir. Ve bunları doğrulamak için A/B Testi ve daha genel olarak Odak Grubu (Focus Group) çalışmaları yapmak gerekmektedir.

Örnekler:

  1. Ürün, tek el ile erişkin nüfus (18 - 80 yaş) tarafından kolaylıkla kullanılabilmelidir.
  2. Gıda otomatı, herhangi bir eğitim gerektirmeden, erişkin nüfus tarafından kullanılabilmelidir. Otomatı ilk defa gören insanların en az %95'i başarılı bir şekilde alışveriş yapabilmelidir.
  3. Ürünün yeni sürümünün kullanımının, bunu değerlendirecek kullanıcıların en az %90'ı tarafından "eski sürüme göre daha kolay" olarak değerlendirilmelidir.
  4. Deneyimli bir sipariş giriş personeli, tedarikçi kataloğundan seçilen bir ürün için azami 7 dakika ve ortalama olarak 4 dakikada sipariş girebilmelidir.
  5. Türkçe bilmeyen kullanıcılar, herhangi bir eğitim ihtiyacı olmadan, ürünü kullanabilmelidir.
  6. Daha önce ATM cihazı kullanmış olan banka müşterileri, ortalama 2 dakika içinde ATM'den para çekebilmelidir.
  7. Daha önce ATM cihazı kullanmamış olan müşterilerin en az %90'ı ortalama 4 dakika içinde ATM'den para çekebilmelidir.
  8. ATM'den ayda en az 6 defa para çekmiş olan müşteriler ortalama olarak 30 saniyede ATM'den para çekebilmelidir.

Tuesday, February 27, 2018

Emniyet Gereksinimi Örnekleri

Yazılım sisteminin insanlara veya hedef kullanım alanı içindeki ortama zarar vermesini engellemeye yönelik gereksinim türüdür.

Örnekler:

  1. Operatör Koruması "Etkin" durumuna gelmeden Radyasyon Sistemi işlem yapmaya izin vermemelidir.
  2. İlaç İzleme Sistemi, doktor tarafından belirtilmiş azami miktardan daha fazla oranda doz kullanımına izin vermemelidir.
  3. Yiyecek Satış Makinesi, bir soğuk gıda ürününün ısısı 4 derecenin üzerine çıkması durumunda bu ürünün satışına izin vermeyecektir.

Tekrar-Kullanılabilirlik Gereksinimi Örnekleri

Yazılım sisteminin bir parçasının diğer bir sistem tarafından kullanımı için dönüştürülmesine yönelik gereksinim türüdür.

Örnekler:


  1. Elektronik Fon Transferi ödeme seçeneğinin geliştirilmesi öyle yapılmalıdır ki organizasyonun diğer bölümleri tarafından tekrar kullanılabilsin.
  2. İstemci cihaz üzerinde çalışması için geliştirilen tüm yazılımlar, destekleyici bir ortamın indirilmesini gerektirmeden kişisel bir bilgisayar üzerinde çalışacak şekilde geliştirilmelidir.
  3. Devlet arşivlerindeki basılı materyal elektronik hale dönüştürülürken, var olan bilginin farklı maksatlarla kullanılabilmesi için farklı formatlarda sunulabilmesinin sağlanması gerekmektedir. Bilgiye erişim aynı zamanda fikrî mülkiyet yasalarına uygun bilgileri de içermelidir.

Monday, February 26, 2018

Yüksek Seviyede Verimli Test Mühendislerinin 5 Özelliği

Her meslek alanının uygulayıcılarının kendi alanlarında en iyi olabilmeleri için sahip olmaları gereken bazı yetkinlikler vardır.

Yazılım Testi de bu açıdan bir istisna değildir. Sıkı çalışma ve adanmışlık her meslek için önemlidir. Bu yazıda, test mühendislerinin alanlarında en iyi olmaları için kesinlikle kaçınılmaz olan 5 özellik sıralanmıştır. Sizin de önemli gördüğünüz yetkinlikler varsa, bunları yorum olarak ekleyebilirsiniz.

#1) Merak:
Merak, listenin ilk sırasındadır. Bir test mühendisi olarak, kesin olarak belirli olmayan her şeyi sorgulamak durumundayız. "Acaba 'Kaydet' düğmesine ard arda 2 kere tıklarsam ne olur? Veya 3 kere? Veya 'Kaydet'e tıkladıktan hemen sonra 'ESC' tuşuna basarsam ne olacak? Alanları boş bırakıp 'Kaydet'e basarsam ne olacak?" diye merak etmek gerekiyor.

Zaten deneyimli bir test mühendisi iseniz bu tarz bir yaklaşıma çoktan sahip olmuşsunuzdur. Eğer meslekte yeni iseniz, bu yaklaşıma en kısa zamanda sahip olmanızı tavsiye ederim. Eğer soruları siz sormazsanız, ürünün son kullanıcısı soracaktır ve hatalarla karşılaşabilirler. Eğer düşünebildiğiniz tüm senaryoları test etmezseniz, son kullanıcınız edecektir.


#2) Detaylara Gösterilen Dikkat:
Bu madde gerçekten çok önemlidir ama dürüst olmak gerekirse bunun insanın içinden gelmesi gerekir; öğretilebilecek bir yetkinlik değildir. 

Detaylara yeterince dikkat gösteren biriyseniz uygulamadaki en ufak bir kusur / uygunsuzluk gözünüze takılıp sizi rahatsız edecektir.

Bu şekilde çalışarak yaptığınız testlerden memnun kaldınız mı? O halde bunu bir alışkanlık haline getirin. Bu şekilde doğmamış olabilirsiniz ama bu konuda özen gösterirseniz zamanla bu yetkinliğe ulaşabilirsiniz.
#3) Odaklanabilme ve Parçalara Ayırabilme Yeteneği
Kısaca ifade edersek, büyük resimden ayrılmadan zihnimizi en küçük detaylara odaklayabilme yeteneğidir. 

Bir test mühendisi olarak, büyük resmin gözünüzü korkutmasına veya dikkatinizi dağıtmasına izin vermemelisiniz. Sistemin tamamına ayrı gözle bakarken, sistem içindeki birimlere tek tek bakmanız gerekecektir. Bu sayede, o en küçük birimi bile kendi başına ele alıp test edebilirsiniz.

#4) Yapıcı İletişim:
Yapıcı iletişim bir yetkinlikten ziyade bir kişilik özelliğidir. İyi bir iletişim kurabilmek için öncelikle karşıdaki kişiyi dinlemeli, söyleyeceklerimizi tartmalı, uygun bir ton belirlemeliyiz. Kimi insanlarda bu özellik doğal olarak vardır, kimileri de üzerinde çalışarak sonradan geliştirebilirler. Peki bu neden önemli?

Çünkü aslında test mühendisliği teknik bir iş olsa da aslında sosyal bir iştir. İnsanlar tarafından, insanlar için geliştirilen bir ürünü test ettiğimiz için hem kullanıcı/müşteri ile hem de yazılım geliştiren ekip ile yapıcı bir iletişim kurmamız sorunların krize dönmesini engellediği gibi, ürünün çok daha hızlı ve amaca uygun olarak geliştirilmesine katkı sağlar.

Bu konu gerçekten çok önemli olduğu için, test mühendisliğinde iletişim konularda daha önceden yazdığım yazılara da bakmanızı öneririm. "Testin Sosyal Yönü".
#5) Kendini Sürekli Geliştirme
Hemen hemen her meslek alanı zamanla gelişim göstermektedir. Ancak teknoloji yoğun alanlar özellikle de yazılım mühendisliği neredeyse her gün yeni yöntemler ve teknolojiler doğurmaktadır.

Bir test mühendisi olarak gelişmelerden uzak kalmak, meslekte geriye düşmemize sebep olacaktır. Fonksiyonel, performans, güvenlik ve kalite karakteristikleri (güvenilirlik, erişebilirlik, vs.) gibi pek çok farklı test türü ile ilgili kısa aralıklarda yeni ürünler çıktığı gibi Web, mobil ve diğer platformlarda da sürekli yenilikler yapılmakta.

Bu ürün ve yeniliklere çok değil 1 sene uzak kalmak bile sıradanlaşmamıza sebep olacaktır.

Esneklik Gereksinimi Örnekleri

Yazılımın farklı ortamlara, konfigürasyonlara ve kullanıcı beklentilerine kolay uyum sağlamasına yönelik gereksinim türüdür.

Örnekler:
  1. Uygulama, gelecekteki çoklu dil kullanımına uygun olmalıdır. Bu uygunluk şunları içermelidir:
    • Veritabanının yapısı öyle olmalıdır ki çoklu dil desteğini desteklemek için ek bileşenler veya mevcut bileşenlerin değiştirilmesi gerekmemelidir,
    • Kullanıcı, kişisel bilgilerini girerken tercih ettiği dili seçebilmelidir.
  2. Kullanıcıya görüntülenen hiçbir metin, programın kaynak kodu içinde olmamalıdır. Kullanıcının gördüğü her metin, kaynak kodun güncellenmesine gerek olmadan değiştirilebilmelidir. 
  3. Faturalama sistemi birden fazla para biriminde fatura kesme işlemi yapabilmelidir. 
  4. Ders programı yönetim sistemi birden fazla bağımsız dersin birden fazla takvim seçeneğini desteklemelidir. Dersler hakkındaki bilgiler birbirinden bağımsız olmalıdır ve kullanıcılar kayıtlı olmadıkları derslerle ilgili hiçbir bilgiye erişememelidir.
  5. Sistem, kaynak kodunda herhangi bir değişiklik gerektirmeden, yeni bir kullanıcı bildirim yönteminin uygulama içinden tanımlanabilmesine imkan sağlamalıdır.

Sunday, February 25, 2018

Platform Uygunluk Testi

Platform Uygunluk Testi'nin amacı, geliştirilen ürünün hedef işletim sistemlerinin tamamında sorunsuz olarak çalıştığının doğrulanmasıdır. Web ürünlerinin farklı internet gezginlerinde çalışmasına yönelik testler de bu kapsamda değerlendirilebilir.

Normal şartlar altında, kurulum işlemleri hariç olmak üzere, ürünün arayüzünün ve yeteneklerinin her platformda birebir aynı olması beklenmektedir. Ancak, test adımlarında komut ekranı / terminal ekranında yazılması gereken komutlar varsa, Windows ve Linux temelli işletim sistemleri için bu komutlar farklı olduğundan, bu detay test adımlarında belirtilmelidir.

Bu test türünün zorluğu, aynı testlerin her bir platform için tekrarlanması gerekliliğidir. O sebeple, mümkün mertebe test otomasyonu yapılarak harcanacak eforun asgari seviyeye indirilmesi önemlidir [test otomasyonu için harcanacak efor da ayrıca göz önünde bulundurulmalıdır, çünkü kimi durumda otomasyon kodunun yazılması, bakımının yapılması, farklı platformlarda çalışır olduğunun garanti edilmesi çok zor olabilir].

Bu test türünde karşılaşılabilecek bazı sorunlar şunlardır:

  • Kütüphane / eklenti uyumsuzlukları,
  • Konfigürasyon dosyalarındaki dizin adreslerinin gösterim farklılıkları sebebiyle dosyalara erişim sorunu,
  • Performans farkları,
  • Dosya formatlarındaki farklılık sebebiyle gösterim sorunları.

İdame Edilebilirlik Gereksinimi Örnekleri

Yazılım sistemindeki arızaların bulunması ve düzeltilmesine yönelik olan gereksinim türüdür.

Örnekler:

  1. Müşteri hizmetleri çağrı merkezi, sorun raporlarının %95'ini 2 saat içerisinde analiz etmelidir. "Acil" olarak sınıflandırılan arızalardan %98'i 3 iş günü içerisinde düzeltilmelidir.
  2. Uygulama geliştirme süreci, 2 iş günü içinde tüm sistemi tekrar test eden bir regresyon test prosedürü içermelidir.
  3. Bir bakım mühendisi, geliştirme ve test eforu da dahil olmak üzere, yasal mevzuatta yapılan değişiklikleri en geç 24 iş saati içerisinde sisteme yansıtmalıdır.
  4. Sistem, bakım amacıyla 24 saatten daha uzun bir süre kapalı kalmamalıdır.

Saturday, February 24, 2018

Kurulabilirlik Gereksinimi Örnekleri

Yazılım sisteminin, hedef ortama kurulumu, kurulumun kaldırılması veya tekrar kurulmasının kolay ve zahmetsiz olmasını sağlamaya yönelik gereksinim türüdür.

Örnekler:
  1. Sistemin veya 3.parti ürünlerinin detayını bilmeyen ama üzerine kurulum yapılacak işletim sistemi ile ilgili yeterli bilgiye sahip bir sistem yöneticisi tarafından sistemin ana sunucu yazılımının kurulumu mümkün olmalıdır.
  2. Yazılım sistemi hedef işletim sistemi olan Windows 10, Ubuntu Linux ve Redhat Linux işletim sistemleri üzerine kurulum arayüzü üzerinden kurulabilmelidir.
    1. Kurulum arayüzünde belirtilen tüm alanların yanında detay açıklamaları anlaşılabilir bir dilde yazılmalıdır.
    2. Kurulumun yapılacağı hedef işletim sistemi, kurulum dizini, veritabanı bağlantı ayar bilgileri, vekil sunucu ayar bilgileri yine bu arayüz üzerinden girilebilmelidir. Böylece kullanıcı, kurulum sonrasında konfigürasyon dosyalarında değişiklik yapmak zorunda bırakılmamalıdır.
  3. Ana sistemin yeni bir sürümü yayınlandığında, sistemin güncellemesi bu yeni sürüm ile yapılabilmelidir. Bu esnada kullanıcı bilgisayarlarındaki ve/veya tüm sunuculardaki kayıt dosyaları, konfigürasyon ayarları, kullanıcı verileri, veritabanı dosya ve tabloları yapılan bu güncellemeden olumsuz etkilenmemelidir / silinmemeli / kaybolmamalıdır.
  4. Yazılım sisteminin kurulu olduğu ortamdan kaldırılması, Kurulum Kaldırma yazılımı kullanılarak yapılmalıdır. 
    1. Kurulumun kaldırılması esnasında, kaldırılan yazılımın, sistemde yüklü diğer yazılımlar ile ortak kullandığı dosyalar silinmemelidir.
    2. Kurulum Kaldırma yazılımı, sadece yazılımın mı yoksa hem yazılım hem de verilerin mi silinmek istediği bilgisini kullanıcıdan almalıdır ve bu doğrultuda silme işlemini yapmalıdır.
    3. Kurulum Kaldırma yazılımı, yazılım sisteminin kendi oluşturduğu dosya ve kayıtlar ile kullanıcılar tarafından oluşturulmuş kayıtların yedeklenmesine imkan veren bir yetkinliğe sahip olmalıdır.
    4. Yedeklenme işlemi sonrasında, yedeklenen veri ile yedeği oluşturan kaynak veri karşılaştırması yapılarak eksik veri olmadığı doğrulanmalıdır.

Friday, February 23, 2018

Ölçeklenebilirlik Gereksinimi Örnekleri

Müşterinin ticari faaliyetinin büyümesini destekleme amacıyla, sistemin kabiliyetlerinin yukarı ve dışarı doğru genişleme derecesini gösteren gereksinim türüdür.

Örnekler:

  1. Sistemde yapılan işlemlerle ilgili olarak üretilecek raporların üretilme süreleri, sistemde depolanmış toplam verinin miktarına değil, raporda içerilen verinin miktarına bağlı olmalıdır.
  2. Personel maaş sisteminin yönetimi için harcanacak efor, çalışan sayısının artması durumunda, artış göstermemelidir. 
  3. Personel maaş sistemi, çalışan sayısının sürekli olarak artması durumunu desteklemek üzere ölçeklenebilir olmalıdır.
  4. İş kuralları veritabanı, sınırsız sayıda ek kuralın yönetimini desteklemek üzere ölçeklenebilir olmalıdır.
  5. Tatil rezervasyon sistemi, dünya genelinde sınırsız sayıda tatil ofisinin kullanımını desteklemek üzere ölçeklenebilir olmalıdır.
  6. Yapılan alışverişlerin tatil dönemlerinde tepe noktasına ulaşması durumu sebebiyle, ödeme onay sistemi, saatlik potansiyel %1000 artışlara karşı ölçeklenebilir olmalıdır. Bu gibi durumlarda yedek donanım ve sistemler ihtiyaç ortaya çıktığı anda devreye girmelidir.
  7. E-ticaret sitesinin kullanıcı sayısının zamanla artması beklendiği için, herhangi bir ek kodlama ihtiyacı olmadan, sistem bu artışı desteklemek üzere ölçeklenebilir olmalıdır.

Thursday, February 22, 2018

Erişim Güvenliği Gereksinimi Örnekleri

Sistemin, dahili ve harici kaynaklar tarafından sebep olunan kasıtlı veya istemsiz hatalarına karşı olarak korunmasına yönelik gereksinim türüdür.

Örnekler:
  1. Çalışanlar, eğer "şifre geçerlilik süresi" tarafından belirlenmiş zaman aralığı içinde şifrelerini güncellememişse, bir sonraki sisteme girişlerinde şifrelerini değiştirmeye zorlanmalıdır.
  2. Kullanıcılar, kendilerine atanan ilk şifreyi, sisteme ilk giriş yaptıkları zaman değiştirmeye zorlanmalıdır. İlk atanan şifre hiçbir zaman yeniden kullanılamamalıdır.
  3. Personel sisteminde yer alan çalışan maaş bilgisi, sadece yetkili kullanıcı tarafından görülebilir olmalıdır. 
  4. Çalışanlar, kendi maaş bilgilerini değiştirememelidir. Bu bilgiyi değiştirmeye yönelik her girişim, güvenlik yöneticisine raporlanmalıdır.
  5. Sadece halihazırda geçerli bir güvenlik kleransına sahip çalışanlar karargah binasına girebilmelidir.
  6. Sistem verisine erişim yetkileri sadece sistem veri yöneticisi tarafından değiştirilebilmelidir.
  7. Şifreler ne girildikleri anda ne de başka herhangi bir anda okunabilir olmamalıdır.
  8. Belirli bir gizlilik derecesi üstünde belgelere erişen kullanıcıların erişim zamanları kayıt altına alınmalıdır.
  9. Belirli bir gizlilik derecesi üstünde belgeleri yazıcıya, USB/DVD kaydediciye veya e-posta mesajı ile gönderen tüm kullanıcıların gönderdikleri dosya ismi ve işlem zamanı kayıt altına alınmalıdır.
  10. Kullanıcı işlem kayıtlarının tutulduğu dosyada (veritabanı tablosunda) hiçbir şekilde değişiklik yapılamamalı, dosya silinememelidir.

Erişebilirlik Gereksinimi Örnekleri

Mümkün olduğu kadar çok "engelsizlik" kabiliyetleri sunarak sistemin kullanmasını sağlayan gereksinim türüdür.

Örnekler:

  1. Sistem, 1990 yılı Amerikan Engelliler Yasası ile uyumlu olarak, engelli bireylerin erişimine izin vermelidir.
  2. Sistem, belirli görme zorlukları çeken bireyler tarafından erişebilir olmalıdır, öyle ki:
    • Görüntülenen metin veya diğer değerler kırpılmadan tüm kullanıcı arayüzü büyük fontta görüntülebilmelidir,
    • Ekranın istenen bölgesi ekran büyüteci ile büyütülebilmelidir,
    • Görüntülenen enformasyon bir ekran okuyucu tarafından sesli olarak okunabilmelidir.
  3. Sistem, renk körü bireylerin erişimine açık olmalıdır, öyle ki, sistemin görüntülediği enformasyon renk körü olmayan biri tarafından nasıl görülüyorsa, renk körü birey tarafından da aynı şekilde görüntülenebilmelidir. (Tahmini olarak, erkeklerin %9'u, kadınların %0.5'i renk körüdür).