Yazılım Testi'nde Kendimi Geliştirmek İstiyorum, Önerileriniz Nedir?

Soru: Yazılım testine ilgi duyuyorum ve bu mesleği seçerek yolumda ilerlemeye çalışıyorum. Bilgisayar mühendisliği öğrencisiyim şuan software test specialist olarak çalışıyorum. Kendimi bu alanda geliştirmek istiyorum. Test türlerinide açıkladığınız bir dökümanınız varmı gerçi wikiden falan inceledim...
Test türlerini bir ağaç gibi oluşturmak istersem neler dikkat etmem gerekir örneğin fonsiyonel ve fonksiyonel olmayan testleri sınıflandırmak iki başlık altında toparlamak istiyorum bu konuda yardımcı olabilir misiniz? Yol gösterebilir misiniz?

Cevap: 

Benim test türlerini açıkladığım bir doküman yok.

Şurada bir kaç yazı paylaşmıştım bir boş zamanımda, aşağıdan yukarıya doğru okursan daha faydalı olur:  http://serdartorun.blogspot.com/search/label/Yaz%C4%B1l%C4%B1m%20Testi

Test türlerini bir ağaç gibi oluşturmak istiyorsan, ayırmak zorunda değilsin aslında ama, evet, çok üst seviyede fonksiyonel ve fonksiyonel olmayan diye iki ana dala ayırabilirsin.

Fonksiyonel, bir fonksiyonun / yeteneğin istendiği gibi çalışıp çalışmadığını doğrulamaktır. Bu birim seviyesinde de olabilir, sistem seviyesinde de. 

Fonksiyonel olmayanlar ise, bir sistemin kalitesi ile ilgilidir. Sistem çalışıyordur, kendisinden istenenler yapıyordur, ama 5 saat aralıksız çalıştığında memory leak oluyordur veya sistem yavaşlıyordur. sonuçta sistem çalışıyor, ama kaliteli mi? değil.

Veya sistem windows üzerinde çalışıyor ama bu sistemi linux üzerine taşımak istesem bir sürü masraf çıkıyordur.

Veya sistem aldım, kaynak kodu da bende, aradan 3 sene geçti, bir başka firmaya mevcut sistem üzerinde bir kaç ekleme yaptıracağım, "maintainable" değilse yeni firma tırmalar durur, gibi. Bunlar hep sistemin kalitesini artıran özellikler.

Bence ilk önce şöyle yap.

Fonksiyonel testlerin listesini çıkar internetten.

ISTQB, SQA Forum, Wikipedia, vesaire yerlerde var bunlar.

Bir de Test Glossary bul (istqb glossary of testing terms, gibi); bir kaç farklı kaynaktan bulup derlemen en iyisi. Uzun bir liste olacak bu.

Sonra fonksiyonel olmayanlara geçersin, ki o çok daha uzun olacak.

Şu standartlara bakman faydalı olur:

IEEE-STD-1012-2004-Standard for Software Verification and Validation

IEEE-STD-1044-2009-Standard Classification for Software Anomalies

IEEE-STD-829-2008-Standard_for_Software_and_System_Test_Documentation

ISO-STD-12207-2008_Software_life_cycle_processes

Mil-Std-498 ve ekleri (DID diye geçer).

Ayrıca fonksiyonel olmayan testler için bu "-ibility" ile biten kalite karakteristiklerinin tanımı için ISO-IEC-FDIS-25010_(E) standartına bakmalısın.

Böylelikle kendi dokümanını kendin hazırlamış olursun, bir taraftan da elinde standartlar birikmeye başlar. Mutlaka ama mutlaka standartlarda yazanlara öncelik ver, internette pek doğru olmayan / yanıltıcı bilgiler de oluyor.

Özetle şunlar elinde birikmiş olacak:

Test Türlerinin İsimleri,

Açıklamaları,

Kalite Karakteristiklerinin İsimleri,

Açıklamaları,

Test Sözlüğü,

IEEE Test Standartları,

ISTQB Syllabus

Mil-Std-498 Standartı

Gereksinim Analizi Yaparken Nelere Dikkat Edilmeli

Gereksinim analizinin amacı temel olarak, müşterinin / kullanıcının ihtiyaçlarının neler olduğunu ortaya çıkarmaktır.

Yazılım projelerinin önemli bir kısmının başarısız olmasının temel sebeplerinden biri budur.
Kısaca, cevaplanması gereken sorular şunlardır:

• Kim; kullanıcı kimdir? Eğitim seviyesi, bilgisayar / mobil cihaz bilgisi nedir? Kullanıcılar arasında bedensel /zihinsel engeli olanlar da var mı? 
• Nerede; kullanıcı bu ürünü ne tip bir ortamda kullanacak? Evde mi, iş yerinde mi, açık havada mı, atölyede mi, sarsıntılı / nemli / sıcak / soğuk bir ortamda mı, ...? Donanım / ağ altyapısı nedir?
• Ne; kullanıcı hangi sorununu çözmek için bu yazılımı kullanacak?
• Nasıl; kullanıcı bu yaşadığı sorunu çözerken nasıl bir iş akışından geçiyor? 
• Ne Sıklıkta; kullanıcının bu iş akışlarını hangi sıklıkta gerçekleştirdiği: her gün, her saat ? Gün içerisinde herhangi bir anda?
• Kaç Kişiyle; yazılımı kaç kişi kullanacak? Bu kullanıcılar hangi iş akışlarını hangi sıklıkta kullanacak? 

Bu soruların tamamına doyurucu cevaplar alındığında geliştirilecek yazılım ile müşteri beklentileri çok büyük oranda örtüşmüş olacaktır.

Test Mühendisi Projenin Sahibidir

Yazılım projeleri, tanımları gereği genelde bir "proje" olarak algılanırlar. Proje, başlangıç ve bitiş tarihi belirli olan bir süreçtir. Dolayısıyla bu projede çalışanlar da (genelde) "bana verilen işi yaptım, ücretimi aldım" gözüyle bakarlar projelere.
Yani aslında kendilerini projenin sahibi olarak görmezler; sonuçta proje müşterinin ve projeyi yapan şirket sahiplerinindir diye düşünülür. Proje ile ortaya çıkan ürün veya hizmetin kimlerin hayatını kolaylaştıracağı veya zorlaştıracağı, kimlerin bu ürün/hizmetten dolayı mutlu olacağı veya acı çekeceği pek düşünülmez (düşünenler vardır tabii, genel izlenimlerimi aktarıyorum).

Bu tarz bir düşünce yanlıştır diyemeyiz; herkesin algısı ve hayata bakışı farklı.

Bir test mühendisi olarak eğer ki yaptığınız işin altına imza atacaksanız ve/veya bulunduğunuz şirkette uzun seneler çalışmayı düşünüyorsanız, sorumluluğunuz altına aldığınız veya verilmiş projelerin "genel sağlığı"ndan da birinci derecede sorumlusunuzdur. Şöyle ki;
- Eğer yaptığınız işin altına imzanızı atacak kadar güvenmiyorsanız veya "aman yapılsın bitsin de..." tarzında düşünüyorsanız, bu işler bir süre sonra sizi takip edecek ve isminizi kötüye çıkaracaktır (gerçi bu her sektör ve her iş grubu için aynı).
- Eğer bulunduğunuz şirkette uzun seneler boyunca çalışmayı düşünüyorsanız ve çalıştığınız projeler uzun soluklu (operasyon denilebilecek tarzda) projeler ise, diğer herkes (proje yöneticisi, yazılım geliştiriciler) başka projelere veya şirketlere gittiğinde o üründen neredeyse tek başınıza sorumlu olursunuz, çünkü şirkette o projeyi detaylı olarak bilen bir başkası kalmamıştır.

Test mühendisi ürünün doğru, hızlı ve kullanılabilir olmasından sorumludur, ürünün şirket içindeki müşterisidir, ürünü müşteriye ve son kullanıcıya kabul ettirecek kişidir; bu açıdan bakıldığında projenin sahibidir.

Eğer aşağıda yazdığım konulara zamanında dikkat etmezseniz, projenin ilerleyen aşamalarında büyük zorluklar çekmeniz ve/veya ürün kalitesinde düşüş kaçınılmazdır .

- Fonksiyonel Doğruluk: Ürün/hizmet istendiği şekilde ilgili kullanıcıların ihtiyacını karşılamak zorunda. Bundan aslında bahsetmeye gerek bile yok.

- Kullanılabilirlik: Mümkün olduğu kadar az işlem yaptırarak, kullanıcının istediği bilgiyi mümkün olduğu kadar hızlı bir şekilde sunmak, şeklinde özetleyebiliriz. Diğer bir durum da, kullanıcının karşısına çıkardığınız ürün/hizmette tek bir tane bile gereksiz simge, resim, yazı vesaire olmamalıdır. Sunulan fonksiyon, arayüz, hizmet, ... amacına uygun olmalıdır.
Ayrıca Erişebilirlik (Accessibility) yani engelli kişilere kolaylık sağlayacak özellikler de bu kapsamda değerlendirilebilir.

- Performans: Ürünler/hizmetlerin sanki bunu tek bir kişi kullanacakmış tasarlanması ve geliştirilmesi ölümcül bir hatadır. Hedef kullanıcı kitlenizin büyüklüğünü bilmek durumundasınız.

- Ölçeklenebilirlik: Bugünün veya yakın geleceğin şartlarına göre üretilen bir ürün/hizmetin senelerce insanlara hizmet etmesi isteniyorsa, bu ürün/hizmetin artan kullanıcı sayısı ile paralel olarak genişletilebilmesi gerekir.

Yazılımın Test Edilebilirliği

Sözleşmelere genelde eklenen ama ne sözleşmeyi yazanların ne de proje takımlarının net olarak bilmediği bir konu olan Yazılımın Test Edilebilirliği ile ilgili bir blog mesajıdır bu.

Aşağıdaki 1. bölüm Wikipedia'dan tercümedir (tercüme sonrasında anlamın korunmasına gayret ettim).
2. bölümde standartlardaki konu ile ilgili açıklamalar verilmiştir.

1) Yazılım test edilebilirliği, bir yazılım ürününün (örneğin bir yazılım sistemi, yazılım modülü, gereksinim veya tasarım dokümanı) test faaliyetini desteklemesidir.
Test edilebilirlik bir yazılım ürünün doğal olarak içinde olan bir özellik değildir ve doğrudan ölçülemez. Aksine, test edilecek ürün ile testin amaçları, kullanılan test yöntemleri ve test kaynakları arasındaki karşılıklı bağımlılıktan doğan dışsal bir özelliktir.
Düşük seviye test edilebilirlik, test eforunun artmasına sebep olur. Bir uç durum olarak, test edilebilirliğin olmayışı yazılımın test edilecek parçalarının gizlenmesine sebep olabilir.

Yazılım bileşenlerinin (modüller, sınıflar) test edilebilirliği aşağıdaki gibi faktörler tarafından belirlenir:
Kontrol Edilebilirlik: Test edilmesi gereken bileşenin bulunduğu durumun kontrolüne ne ölçüde imkan sağlandığı,
Gözlemlenebilirlik: Ara veya nihai test sonuçlarının gözlenmesine ne ölçüde imkan sağlandığı,
İzole Edilebilirlik: Teste tabi bileşenin izole bir ortamda test edilebilme seviyesi,
Sorumluluğun Ayrıştırılması: Teste tabi bileşenin ne seviyede iyi tanımlı, tek bir sorumluluğu olduğu,
Anlaşılabilirlik: Teste tabi bileşenin ne seviyede dokümante edildiği veya kendinden-anlaşılabilir olduğu,
Otomatikleştirilebilmesi: Teste tabi bileşenin testlerinin otomatikleştirilmesine ne oranda imkan sağlandığı,
Ayrışıklık: Paralel olarak farklı test yöntemlerinin ve araçlarının kullanımının gerektiği.

Yazılım bileşenlerinin test edilebilirliği Test-Odaklı Geliştirme ve Test Edilebilirlik için Tasarım yaklaşımları ile artırılabilir.

Gereksinimlerin Test Edilebilirliği: Test edilebilir olması için gereksinimlerin aşağıdaki kriterleri sağlaması gerekmektedir:
Tutarlı,
Tam,
(Tartışmasız bir şekilde) Kesin,
Nicel ("hızlı tepki süreleri" gibi ifadeler olmamalı),
Uygulamada Doğrulanabilir (Test, sınırlı kaynaklar ile sadece teoride değil uygulamada da yapılabilir olmalı).

2) Bu bölümde doğrulama ile ilgili çeşitli standartlardaki Test Edilebilirlik tanımları verilmiştir:
IEEE Std 12207-2008: "Tarafsız ve uygulanabilir bir testin, bir gereksinimin karşılanıp karşılanmadığını belirlemesi ölçütü"


ISTQB (ISO 9126'dan faydalanarak): "Bir yazılımın ürününün, değiştirilmiş yazılımın test edilmesine imkan sağlama kabiliyetidir".

Fonksiyonel Olmayan Gereksinimlere Örnekler

Sistem mühendisliği ve gereksinim mühendisliğinde fonksiyonel olmayan bir gereksinim belirli davranışlardan ziyade sistemin işleyişini yargılamak için kullanılabilecek kriterleri belirten bir gereksinimdir. Bu açıdan, belirli davranış veya fonksiyonları tanımlayan fonksiyonel gereksinimden farklıdırlar. Fonksiyonel gereksinimler sistem analizi / tasarımında detaylandırılırken, fonksiyonel olmayan gereksinimler sistem mimarisinde detaylandırılırlar.

Fonksiyonel gereksinimler bir sistemin ne yapması gerektiğini belirtirken, fonksiyonel olmayan gereksinimler ise sistemin nasıl olması gerektiğini belirtirler. Fonksiyonel olmayan gereksinimlere aynı zamanda sistemin kalite karakteristikleri de denir.

Fonksiyonel olmayan gereksinimleri iki ana kategoriye ayırabiliriz:
- İcra Özellikleri: Güvenlik, Kullanışlılık gibi işleyiş süresi içinde gözlemlenebilenler.
- Gelişim Özellikleri: Test Edilebilirlik, İdame Edilebilirlik, Genişleyebilirlik ve Ölçeklenebilirlik gibi yazılım sisteminin durağan yapısına gömülü olanlar.

Fonksiyonel olmayan gereksinimlerden sıklıkla kullanılanlarından bazılarını aşağıda listeledim. Her biri için yapılan tanımın altında örnekleri de verdim:

Bütünlük
Emniyet
Erişebilirlik
Erişim Güvenliği
Esneklik
Gizlilik
Hayatta Kalabilirlik
İdame Edilebilirlik
Kullanılabilirlik
Kurulabilirlik
Ölçeklenebilirlik
Taşınabilirlik
Tekrar Kullanılabilirlik