ISTQB Foundation Level Sertifikası

Merhabalar

ISTQB açılım olarak International Software Testing Qualification Board'dur ve 2002 yılından bu yana faaliyet göstermektedir.

Foundation Level sertifikası da en temel ve başlangıç seviye olan sertifikadır. Bu sertifikayı alabilmek için ;

1. Testin temelleri 
2. Yazılım döngüsünde test
3. Statik Test
4. Test Tasarım Teknikleri
5. Test Yönetimi
6. Test için araç desteği 

konularını bilmek gerekmektedir. Toplamda 40 soru sorulan ve İngilizce olarak yapılan bu sınavda en az 26 soruyu doğru cevapladığınız takdirde sertifikaya hak kazanıyorsunuz. Benim bildiğim kadarıyla sınavı Türkiye'de Keytorc'tan satın alabiliyorsunuz. Fakat her gün sınav yapmıyorlar. Ben sınavı Prometric'ten istediğim gün ve saate satın almıştım. Bu nedenle Prometric'i de tavsiye ederim. 

Sertifikayı almak için eğitime gitmek gerekiyor mu derseniz, bana kalırsa buna gerek yok. En başta, bu eğitimler 3-4 günlük oluyor ve 6 chapter'dan oluşan bir syllabus'ı sindirerek öğrenmek için yeterli değil bana kalırsa. Zaten şu an yazılım test mühendisi olarak çalışıyorsanız konuların bir çoğuna hakimsinizdir. Syllabus'taki konuları derinlemesine inceler ve çalışırsanız, ISTQB'nin sitesinde sağlamış olduğu örnek sınavı ve internetten güvenilir kaynaklardan bulabileceğiniz soruları çözerseniz zorlanmadan alacağınızı düşünüyorum. Ben yalnızca konulara çalışıp ve birkaç da mock test çözerek 39/40 yaparak sertifikayı aldım. 

Bu sertifikanın ne gibi yararları olacaktır derseniz, yazılım testi konusunda kariyerinizi ilerletmek istediğinizi, bu alanda gelişime açık olduğunuzu işverenlere yansıtmak için en önemli araç diye düşünüyorum. Ayrıca sertifikaya sahip olan kişilerin iş bulma konusunda sertifikası olmayanlara göre bir adım önde olduğunu söylemek de yanlış olmayacaktır. Sonuçta testi bilen, bunu sertifikası ile kanıtlamış kişiler herhangi bir yazılımın testini yapma uyumunu sağlamakta daha az zorlanacaktır. Ayrıca uluslararası geçerliliği olan bir sertifika oluğu için yurtdışı istihdamı için de faydası oldukça büyük. 

Sınav, sertifika, yukarıda belirttiğim konular ve herhangi başka bir şey için iletişime geçebilirsiniz. Memnuniyetle cevap veririm.

Sevgiler

Test case nasıl yazılır? Örnek test case formatı

ID	Priority	User Requirement	Title	Description	Pre-conditions	Post-Conditions
TC_1	High	Login fonksiyonu	Kullanıcı adı ve şifre ile login	ABC.com sitesi login fonksiyonu testi	Kullanıcı adı ve şifre	Ana sayfa ekranında Hoş Geldin! Metni görülmeli

Step	Test Steps	Test Data	Expected Result	Actual Result	Status	Notes
1	Kullanıcı adı girilir	a@b.com	Kullanıcı şifre alanına yönlendirilmelidir.		PASSED
2	Şifre girilir	“P@ssw0rd”	Login butonu deaktiften aktife dönüşmelidir.	Buton deaktif olarak kalmakta, kullanıcı login olamamaktadır.	FAILED

Yukarıda görmekte olduğunuz 1. tabloda test case'in business tarafının ihtiyacını karşılayan kısmını görmektesiniz. Bu tablodaki alanlarda analiz dokümanında belirtilen user-requirement'lardan hangisinin test case'i olduğunu, önceliği (bu öncelik regression test pack'i oluştururken çok önemlidir) pre ve post conditonlarını görmektesiniz. 

2. tabloda ise testin teknik tarafının işine yarayan kısmı bulunmaktadır. Test steplerinde testin koşulması için gereken adımların tamamı yazılır. Bu adımlar ayrı ayrı yazılmalıdır ki yukarıdaki örnekte olduğu gibi login fonksiyonunun hangi nedenle fail olduğu daha kolay şekilde anlaşılsın. Login fonksiyonunda a@b.com adresini ve P@ssw0rd şifresini girdiğimde login olamıyorum yerine, bu kullanıcı adı için doğru şifreyi girmeme rağmen buton deaktif kalıyor demek çok daha doğru ve tekrar edilebilir bir durumdur.

Expected result kısmında kullanılacak olan ifade Türkçe'de dilek kipi olarak bildiğimiz :) gereklilik ekidir. X yapınca Y olur yerine, X yapıldığında Y olmalıdır ifadesi expected result kısmında kullanımı daha doğru bir ifadedir.

Actual result, execution sırasında doldurulan bir alandır. Status de testin passed/failed/untested/blocked/partially passed gibi sonuçlanan durumlarını gösterir. 

Notes kısmında da test case ile ilgili test sırasında herhangi bir sorun ile karşılaşılırsa bu alana yazılabilir. Ya da, test versiyonlarının dikkatle kontrol altında tutulduğu durumlarda, bu case için açılan defect id'leri yazılarak bir sonraki test sırasında bu defect'in fix edilip edilmediği takip edilebilir.

Yıllardır kullanmakta olduğum test case formatı yukarıdaki gibi ve şimdiye kadar da bu şekilde test case yazmanın çok faydasını gördüm diyebilirim. Case'leri bu şekilde yazmak uzun sürüyor olabilir, fakat zamanla defect açmanın ve bu case'leri koşmanın ne kadar kolaylaştığını fark ediyorsunuz. Bütün bu case'leri neye göre yazdığımız ise iş analistinin göndermiş olduğu teknik/fonksiyonel analiz dokümanında saklı :)

Sevgiler

Regression Testi nedir ? Ne zaman yapılmalıdır?

Merhabalar,

Birkaç hafta aradan sonra bugün sizlere regression testinden bahsedeceğim. Regression testi genel anlamda, kod üzerinde yapılan değişikliğin, değişiklik yapılmayan yerleri etkilemediğinden emin olmak için yapılır.

Özellikle Agile modeli kullanılarak geliştirilen yazılımların testinde regression önemli bir rol oynamaktadır. Sürekli artan fonksiyonlar ve yeni gelen geliştirmeler nedeniyle onaylanmış/geliştirmesi tamamlanmış fonksiyonların hala çalışıp çalışmadığı veya yeni eklenen fonksiyonlar nedeniyle çalışmasının etkilenip etkilenmediği test edilmelidir.

Regression için full fonksiyonel test yapmaya safety-critical olan yazılımlar dışında çok fazla gerek yoktur. Bu yüzden full fonksiyonel test caseler arasından regression test case'leri seçilerek yalnızca bu case'ler koşulur. Olmazsa olmaz fonksiyonların kesinlikle test edildiği, diğer fonksiyonlardan da kullanıcının hata ile karşılaşabileceği düşünülen yerler alınarak bir regression test pack oluşturulur.

Regression testi "ütopik" ama aslında "olması gereken" süreçte sanity testinden sonra koşulmalıdır.

Burada karşılaştırılan önemli bir nokta var :

• Regression testi re-test'ten farklı olarak ne yapıyor?

Regression testi kodun etkilenip etkilenmediğini konfirme etmek için yapılırken, re-test; test edilmiş ve hata çıkan yazılım fix edilip tester'a hatanın ortadan kaldırıldığına emin olmak için yapılır. Yani herhangi bir yazılımın testi sırasında developer'a bir defect açtığınız zaman bu defect çözüldüğünde re-test, çözülen defect'in kodun herhangi başka bir alanını etkilemediğini görmek için de regression testi yaparsınız.

Bugünlük bu kadar :)

Sevgiler

Yazılımcılar ve test mühendisleri birbirine düşman mı?

Merhabalar,
3 yıl tecrübesi olan bir yazılım test mühendisi olarak bu soruya kolaylıkla Hayır cevabı verebilirim. Her ne kadar test yıkıcı bir aktivite olarak görülse de, developer ve tester'lar iyi ilişkilere sahip olduğunda ne test yıkıcı bir aktivite oluyor, ne de bu iki meslek grubu insanları birbirine düşman oluyor.

Tip 1 Developer
Gözlemlediğim kadarıyla, junior developer'larda olan davranış biçimi : Uygulamasında bug çıktığı zaman işinin bittiğini düşünür, bug bulunduğu an işten çıkarılma kaygısı yaşar. Ya da yazdığı kodda bu hata ile kendi karşılaşmadı mı diye sorgulanacağını düşünür.

Tip 2 Developer
Bulunan bug'ları küçümser (Kendi bulamadığı halde) Onu ben zaten çözdüm, siz testlerde bunları mı arıyorsunuz diye bulunan tüm hataları küçümseme eğilimindedir. Kod yazıyor olmasını dünyanın en büyük başarısı olarak görür, ve sizin kod yazmıyor olmanızı da sizin beceriksiz olmanıza bağlar.

Tip 3 Developer
Test ve development'ın bütün bir aktivite olduğunu düşünerek herkesin kendi işini yaptığını ve herkesin yaptığı işin ortak sonucu olduğunu kanıksamıştır. Bulunan bug'ları itina ile çözer, yaptığı geliştirmelerden önce kendi testini yapar. Yaptığı iş ile ilgili içi rahat değilse de size "Şu kısımlarda hata çıkabilir, biraz zorlamaya çalışır mısın?" diye size ön bir feedback verir. Çalışmayı en sevdiğim ve nadir bulunan developerlardır bunlar :)

Test mühendisleri bulunan hataları developer'ların suçu gibi görmez, eleştirmeden objektif bir biçimde iletirse, yazılımcılar da manuel test yapanların "kod yazamadığı" için bu mesleğe yönelmediğini idrak ederse test mühendisleri ve developerlar arasında husumet çıkmıyor. Yaşadım gördüm :)

Herkese mutlu günler

Smoke ve Sanity testi

Selamlar,

Bugün sizlere benim de arasındaki farkı öğrenmemin uzun zaman aldığı Sanity ve Smoke testlerinden bahsedeceğim.
Öncelikle Smoke test, herhangi bir yazılımda bugfix yapıldıktan sonra gelen release üzerinde yapılır. Bu testin amacı ise, eğer release üzerinde yapılan değişiklikler yazılımın hayati fonksiyonlarını etkilemiş ise teste devam etmemektir. Çünkü hayati fonksiyonları çalışmayan bir yazılımı test etmek aslında zaman kaybıdır. Smoke test, çok kapsamlı bir test olmamakla birlikte, yazılımın sadece en önemli fonksiyonlarının çalıştığından emin olunur. Her seviyede (kullanıcı kabul, sistem testi gibi) koşulabilir.

Sanity test için kısaca, yazılım test mühendislerinin kabul testi denilebilir. Smoke test koşulup kabul edildikten sonra başlanır. Sanity koşulup test mühendisleri tarafından kabul edildikten sonra daha kapsamlı olan regression testine geçilir. Regression testinin yapılması gerekliliği yazılımın değişmiş olmasından kaynaklanıyor. Regression testinden de ilerleyen zamanlarda bahsedeceğim.

Kendi tecrübelerimden bahsetmem gerekirse, sanity test ve smoke testi çoğu yerde birlikte yani aynı anda koşmuşumdur. Bunun sebebi hem yukarıda bahsettiğim kadar profesyonel test yapılan bir yerde çalışmamam, hem de henüz Türkiye'de yazılım testine hala yeterince önem verilmiyor olmasından kaynaklanıyor.


Sevgiler

Hello World!

Merhabalar,

Bu benim ilk blogpostum ve umarım son olmaz :) Buradan şu anda çalışmakta olduğum test mühendisliği alanıyla ilgili faydalı bulduğum, challenge olarak gördüğüm ve bu işe yeni başlayacaklara ışık tutacak, bana da boş zamanlarımı 'boş' geçirmemi sağlayacak şeyler paylaşmayı hedefliyorum.

Kısaca kendimden bahsetmem gerekirse, bilgisayar mühendisliği mezunuyum, şu anda da İstanbul Teknik Üniversitesinde yüksek lisansımı icra etmekteyim :) Önde gelen telekominikasyon şirketlerinden birinde yazılım test mühendisi olarak çalışmaktayım. Kariyer hedefim ise 'gerçekten' test yapılan uluslarası bir şirkette test yöneticiliği yapmak diyebilirim.

En çok karşılaştığım sorulardan biri bilgisayar mühendisi olmama rağmen neden test alanını seçmiş olduğum. Bunun başlıca sebebi yazılım alanında kendimi mutlu hissetmedim hiçbir zaman. Üniversite son sınıfta olduğum zamanlarda, android cihazlar yeni yeni raflarda yerini alırken, mobil uygulama yazan sayılı developer varken mobil yazılım denemiş biri olarak gerçekten çok mutsuz bir geleceğe doğru yol aldığımı farkedip, bilgisayar mühendisi olarak yazılım dışında başka ne yapabilirim diye kara kara düşünmeye başlamıştım. Araştırarak, hocalarıma danışarak gördüğüm kadarıyla önümde 2 seçenek vardı : İş analistliği ve yazılım test mühendisliği.

İş analistliği, teknik analiz yapmadığınız sürece 'bana kalırsa' bilgisayar mühendisi olmanızı gerektirmeyen bir alan. Gerçi şu an Türkiye'de çoğu yazılım şirketinde yapılan testler de ne kadar mühendislik orası tartışılır. Kısacası, teknik bilgi birikimimi de kullanabileceğim, yazılımın birincil görevim olmayacağı bir alan olarak test mühendisliğini tercih ettim.

Yazılım test mühendisliği nedir, bu insanlar ne yaparlar, neleri bilmeleri gerekir, bu işin geleceği var mı, neden gerçek test yazdım, Türkiye'de yapılan yazılım testleri ne kadar sağlıklı/profesyonel gibi ucu açık olan bir çok soruma yavaş yavaş giriş yapacağımı belirterek şimdilik veda ediyorum.

Bir sonraki post'a kadar,
Peace out!