Ö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.