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.

İş 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.

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.

Test Mühendisi Olarak İş Görüşmesinde Sorulabilecek Sorular

Başvuru yaptığınız iş hakkında ne kadar detaylı bilgi sahibi olursanız, hem firma hem de siz daha iyi bir seçim yapabilirsiniz.
Bana göre sorulması gereken soruları aşağıda listeledim. Hepsini sormak ve/veya cevap almak mümkün olmayabilir... :)

1. Benden beklentiniz tam olarak nedir?
2. Kaçar senedir bu firmada çalışıyorsunuz?
3. Bu firmayı 3 kelime ile nasıl anlatırsınız?
4. Bu pozisyona neden ihtiyaç duyuldu? Daha önce biri çalışıyordu da işten mi ayrıldı, yoksa yeni bir proje sebebiyle ihtiyaç mı doğdu? Ayrıldı ise neden ayrıldığını biliyor musunuz?
5. Projelerin / ürünlerin geliştirilme süreleri en az / en çok kaç ay?
6. Test mühendisi olarak kaç kişi çalışıyor?
7. Hangi test mühendisliği pozisyonları var?
8. Test mühendisleri hiyerarşide kimlere bağlı?
9. Eğer proje yöneticisine bağlı ise test mühendislerinin bağımsızlığını nasıl garanti ediyorsunuz?
10. Hangi seviyelerde test yapıyorsunuz? 
11. Bağımsız test ortamınız var mı?
12. Test süreçleriniz hangi standartlarla uyumlu?
13. Test otomasyonunu hangi seviyede yapıyorsunuz? Neler yapıyorsunuz? Beklentiniz ne?
14. Performans, Güvenilirlik, Uyumluluk, Güvenlik, vesaire testlerden kaç kişi sorumlu?
15. Dokümante edilmiş süreçleriniz var mı?
16. Analiz ve tasarımı kimler yapıyor? Ne tip bir kontrolden geçiyor?
17. Analizde ne tip sorular soruyorsunuz?
18. Müşteri tarafında analiz ve tasarım sonuçlarını yorumlayacak kimse yoksa, ne yapıyorsunuz?
19. Kullanıcı ortamına ilk ne zaman ve sonrasında hangi sıklıkla yayımlama yapıyorsunuz?
20. Her bir yayımdaki değişiklikleri müşteri ile nasıl koordine ediyorsunuz?
21. Eğitimleri kim / nasıl veriyor? Ne tür materyal kullanıyor?
22. Projeler / ürünler hangi teknolojiler ile geliştiriliyor?
23. Ar-Ge mi Taahhüt mü Ürün-temelli mi çalışıyorsunuz?
24. Feature Developer’lar müşteri ile hangi aşamalarda görüşüyor?
25. Müşteri istekleri ve şikayetleri ile kim yüzleşiyor?
26. Konfigürasyon Yönetimi hangi aşamalarda devreye giriyor? Kaç kişi çalışıyor?
27. Kalite Güvence hangi aşamalarda devreye giriyor? Kaç kişi çalışıyor?
28. Çalışana bağımlılığını nasıl en aza indirgiyorsunuz?
29. Fazla mesai yapıyor musunuz? Ne sıklıkta?

Yazılım Test Mühendisliği - İş Görüşmesinde Sorulan Sorular

Bu konuda oldukça sık e-posta alıyorum, o yüzden bir blog mesajı yazmayı uygun gördüm. Sorular genelde yeni mezun ve/veya test mühendisliği alanında çalışmamış ama yaptığı ilan başvurusu sonrasında iş görüşmesine çağrılmış kişilerden geliyor.

Genelde soru içeriği "iş görüşmesine çağırdılar, hangi soruları sorarlar, ne cevap vermeliyim" şeklinde oluyor.

Herhangi bir iş görüşmesinde sorulabilecek soruların sınırı yoktur, hepsini burada yazmaya imkân yok. Özel olarak, yazılım test mühendisliği iş görüşmelerinde sorulan / sorulabilecek soruları aşağıda listeledim, cevaplarını araştırmayı ise okuyucuya bıraktım :)

İş görüşmelerinde (özellikle yeni mezunlar ile yapılanda) sorulan her soruya doğru cevap vermeniz beklenmez (en azından ben beklemem), fakat daha ziyade bu sorulara karşı nasıl bir yaklaşım geliştirdiğiniz, nasıl çözüm ürettiğiniz ile ilgilenilir.

Sorular:

• Yazılım Testi sizce nedir? 

• Yazılımı neden test edelim, zaten yazılım geliştiriciler dikkatli bir şekilde kod yazıyorlar ve birim test yapıyorlar? 

• Sizce tek tip yazılım testi mi vardır, yoksa birden fazla test türü olabilir mi? 

• Bildiğiniz test türleri nedir? Bunlardan hangilerini icra ettiniz?
  

• Hata (Defect) ile Kusur (Deficiency) arasındaki fark nedir?

• Sorun, Arıza, Kusur, Hata, Bozukluk tanımları sizce aynı şey midir? Ne gibi farkları olabilir?

• Bir hatanın önem derecesi ile öncelik derecesi arasındaki fark nedir?

• Örneğin bir yazılımda hata tespit edildi ve yazılım geliştirici tarafından hatanın düzeltildiği söylendi. Sonrasında ne yaparsınız?

• Daha önce hangi test araçlarını kullandınız?

• Özgeçmişinizde HP Load Runner'ı bildiğiniz yazıyor, işte size bilgisayar ve Load Runner programı, şirketimizin web sitesine hemen bir yük testi hazırlayabilir misiniz?

• Bir hesap makinesini nasıl test edersiniz?

• Peki bir meşrubat şişesini nasıl test edersiniz?

• TürkSat 2A uydusunun yazılım test sorumlusu olsaydınız, ne tip testler yapardınız?

• Yazılım ekibi, geliştirdikleri uygulamanın 16 milyon adet rengi desteklediğini iddia etmektedir. Uygulamanın kullanıcısı olan grafik tasarımcılar için 16 milyon rengin desteklenmesi önemlidir. Uygulamanın gerçekten bu kadar rengi desteklediğini nasıl doğrularsınız?

• Bir yazılım mühendisinin geliştirdiği uygulamadaki hataları test mühendisi bulur, peki test mühendisinin olası hatalarını kim bulur?

• Test edilecek uygulamanın bir sayfasında bir metin alanı ve bir sayı alanı vardır. Bu iki alanın her birini nasıl / hangi girdileri kullanarak test edersiniz?

• Test etmekte olduğunuz uygulama ile ilgili açılmış 100 adet hata henüz çözülmemiş durumdadır. Ancak proje yöneticisi uygulamanın müşteri ortamına kurulmasında ısrar etmektedir. Sizce nasıl bir yol izlenmelidir?

• 20 adet alt modülden oluşan bir sistem olduğu düşünelim. Sistem, pek çok sensörden bilgi toplamakta, topladığı bu bilgileri bu 20 adet modül içerisinde çeşitli işlemlerden geçirmekte ve işlemler sonunda tek bir karar vermektedir (ve bu kararın ölümcül sonuçlarını olduğunu düşünelim). Sistemin doğru karar verdiğini test etmek için nasıl bir yol izlersiniz?

• Hangi yazılım test standartları hakkında bilgi sahibisiniz?

• Hangi yazılım geliştirme yaşam döngüleri hakkında bilgi sahibisiniz?

• Bir yazılım geliştirilirken baştan sona hangi aşamalardan geçilir?

• Yazılım ile sistem arasında sizce nasıl bir fark vardır?

• Gereksinim ne demektir? Neden ihtiyaç vardır?

• Gereksinimi olmayan bir uygulama olabilir mi? 

• Uygulamaların gereksinimlerinin olmamasının ne gibi sakıncaları olur? 

• Bir "Test Durumu" (Test Case) ile "Kullanım Durumu" (Use Case) arasındaki fark / ilişki nedir? 

• Gereksinim - Tanımlama (Specification) - Kullanım Durumu (Use Case) - Test Durumu (Test Case) arasında nasıl bir ilişki vardır? 

• Fonksiyonel bir gereksinim ile Fonksiyonel Olmayan bir gereksinim arasında ne gibi farklar vardır? 

• 10.000 adet gereksinimi ve 3500 adet test durumu olan bir projenin Kabul Komitesi'nde olsaydınız, uygulamanın eksiksiz olarak doğrulandığından emin olmak için neleri kontrol ederdiniz?
  

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ı

Yazılım Testi - Kendimi Geliştirmem Gerekiyor

Bana e-posta ile danışan arkadaşlara yazdığım cevapları blogumda (bazı yerlerini kırparak) paylaşıyorum.

Diğer test uzmanı ve adaylarına faydası olur umarım.

Soru: "Yazılım test mühendisliği sunumunuzu inceledim fakat benim bu konuda kendimi daha fazla geliştirmem gerekiyor nereden başlamalıyım nasıl bir yol izlemeliyim tavsiyeleriniz nelerdir beni bu konuda biraz daha aydınlatabilir misiniz?"


Cevap: "Konu ile ilgili çok fazla doküman var fakat çoğunluğu ingilizce; eğer
ingilizce biliyorsan işin daha kolay.
Blogumda konu ile ilgili 2 tane yazı var:
http://serdartorun.blogspot.com/search/label/Yaz%C4%B1l%C4%B1m%20Testi
Onları bi okuyun önce, sonrasında tekrar konuşalım."


Soru: "Size sıkıntımı açık açık belirteyim. ... öğrencisiyim ve bir ... firmasında hem kendimi geliştirmek hemde cep harçlığımı çıkartmak amacıyla çalışıyorum. ... üretilen cihazların testlerini yapıyorum gerek simülatörler ile gerekse yeterli donanımlar ile bu işi yaptım. 
Kendi iş sistemimizde bir bug ya da iş açılır. Yazılımcı işe başlar, belirli bir sürede bitirir ve işi bana bırakır bende işin diğer etkileyebilecekleri vs. gibi tüm durumları göz önünde tutarak test ederim. 
Ancak artık firma artı bu konuda kendimi dahada geliştirmemi istiyor. Buna ek olarak kendi düşüncem her test için adımları dökümanlayıp detaylarını çıkartma her işin detaylarını rapor halinde tamamlanmış işlerin altına eklemek bunu yapmam bir derece daha iyi olur düşüncesindeyim fakat buna ek olarak yapabileceğim şeyler olabilir düşüncesiyle bir uzman görüşü almak istiyorum. 
Benim sizden rica ettiğim Bu sistemimi geliştirmek için bir öneriniz var mı? Bu öneriniz geliştirme ekleme adına olabilir adımları düzenleme adına olabilir her türlü görüşe açığım."


Cevap: "Güzel, zaten belli başlı aktivitleri gerçekleştirmişsin ve daha sistematik, süreçlere dayalı bir iş akışı tanımlamak istiyorsun. Gerçekten güzel.

Şimdi:
Mil-STD-498 isimli eski bir askeri standart vardır. Bu standart yazılım geliştirme sürecini sistematik olarak inceler; ilgili kısımları ekte gönderdim.
Özellikle DID dokümanlarını okumanı tavsiye ederim; diğerlerine de ihtiyaç oldukça bakarsın.
Plan dokümanında testleri nerede, nasıl, neleri kullanarak yapacağını anlatırsın.
Test Description dokümanında adım adım Yapılacak İşlem - Beklenen Sonuç adımlarını anlatırsın.
Test report'ta da testin bitiminde hazırlanıp o testte neler olduğunu anlatılır (fakat bu kadar detaylı bir rapor hazırlaman da gerekmez, 1-2 sayfalık özet bir rapor da işini görür).

DID dokümanlarını okuduğunda pekçok sorunun cevabını bulacaksın. Sonrasında ISTQB'nin dokümanlarını ve CMMI dokümanlarını okumanı tavsiye edeceğim; ama önce DID'ler.

Hata takibi için ne kullanıyorsunuz bilmiyorum. Eğer bir aracınız yoksa Mantis'i (http://www.mantisbt.org/) tavsiye ederim; ücretsizdir, kullanışlıdır, iyidir.

Yaptığın testlerin takibi için bir tane excel dosyası işini görür, orada çok otomasyona geçmene gerek yok bence.
Testin Adı - Başlama Zamanı - Bitiş Zamanı - (Eğer varsa) Bulunan Hatanın Numarası - Testin Sonucu (Geçti - Kaldı gibi) bu bilgiler yeterli olur bence.

Öneriler:
Test edilen yazılımın mutlaka revizyonlanması yapılsın; böylece hangi revizyonda hangi hata çıktı takibi yapılabilir. Bir hata hangi revizyonda çıkmıştı, hangisinde kapandı? önemli bir bilgidir.

Test planlaması -> Test Adımlarının yazılması -> Testlerin yapılması
sırasını her zaman takip etmeni öneririm; çünkü planlama yapmadan doğrudan işe geçersen, tam testi yaptığın sırada şu eksikmiş bu eksikmiş diye bir çok kez kestiye uğrarsın.

Bir test "neyi test ediyor", "önkoşulları neler", "testin sonucunda ne bekleniyor" bilgileri mutlaka olmalı.

Test durumlarında da (yani test adımlarının olduğu kısım) 2 farkllı yol izleyebilirsin:
1) Test adımlarını, o yazılımı hayatında hiç görmemiş birinin bile sadece senin dokümanına bakarak test edebileceği detayda yazmak,
2) Test adımlarını daha genel ve daha kısa tutmak.

1. yolda çok efor harcarsın fakat doğrusu budur.
2. yolda, eğer uygulama sık sık değişiyorsa veya henüz olgunlaşmamışsa, tercih edilir.

Tavsiye şu olur: eğer bir Yazılım Geliştirme Döngüsü kullanmıyorsanız (Spiral, Incremental, Waterfall,...), yazılımın analiz ve tasarım aşamaları olması gerektiği gibi detaylı yapılmıyor demektir. Ve bu durumda yazılımda sürekli olarak arayüz, etiket, fonksiyon değişecek demektir. Eğer böyle bir durum varsa ve adımları çok detaylı yazarsan, her seferinde yüzlerce sayfalık bir dokümanı güncellemek zorunda kalırsın ve test yapacak zamanın olmaz.
Anladığım kadarıyla gömülü sistem cihazların testini yapıyorsun, bu tür sistemlerle ben çok çalışmadım; o yüzden net bir şey söylemem bu konuda.

Konu çok derin, eğer bu verdiğim bilgiler tatmin edici değilse, bunları zaten biliyor / yaptıysan, soru cevap şeklinde takıldığın konulara bakabiliriz."

İş Başvurularında Başarı Şansınızı Artırmanın Birkaç Yolu

Yıllar içinde mülakatlarda karşılaştığım temel sorunları burada paylaşıp, yeni mezunların iş başvurularında başarı şanslarını artırmalarına yardımcı olma amacıyla bu sunumu hazırladım. Firmanın ve iş ilanının incelenmesi ilk başlarda biraz zaman alabilir ancak bu alışkanlığı edindiğinizde çok hızlı bir şekilde tüm süreci tamamlayabileceksiniz.

FİRMANIN ARAŞTIRILMASI
Nasıl ki firmalar, özgeçmişleriniz üzerinden sizleri incelerlerse, siz de firmayı mümkün olan tüm yöntemlerle araştırmalısınız; zaten firmaların beklentileri de bu yöndedir.
Firmayı araştırmanın sizin için en az iki olumlu geri dönüşü olacaktır: 1) Firmalar, kendilerini ciddiye aldığınızı ve size yatırım yapabileceklerini düşüneceklerdir, 2) Yanlış bir firma seçme riskini azaltmış olacaksınız.

Firmayı internette (Google, firmanın internet sitesi, İş İlanı Siteleri, glassdoor.com, …) araştırın:
– Hangi sektörde çalışıyorlar,
– Firmanın çalıştığı sektördeki ana rakipleri kimlerdir,
– Daha önce hangi işleri bitirmişler,
– Bu işleri kimlere yapmışlar,
– Hangi alanlarda katma değer üretmektedirler,
– Hangi kalite standartlarına sahipler,
– Çalışan profili nedir,
– Firmanın vizyonu nedir.

Firma ve firmanın bitirdiği işler ile ilgili Google’da arama yapın; (ciddi dergi, site, bloglarda) herhangi bir olumsuz blog, makale, haber var mı?
Bu olumsuzlukları gidermesi için şirkete nasıl bir katma değer sağlayabileceğinizi listeleyin.
Firmanın bitirdiği işleri (yüzeysel de olsa) inceleyin ve bu işleri daha da “iyi”leştirmek için aklınıza gelen birkaç öneriyi listeleyin.

Firmanın sahip olduğu kalite standartlarının (eğer bilmiyorsanız) hangi amaca hizmet ettiğini öğrenin. Örneğin ISO, CMMI, AQAP gibi standartlar hakkında (yüzeysel bile olsa) bilgi sahibi olun.
Çalışanların mezuniyet dereceleri nedir? – Lisans öncesi, Lisans, Yükseklisans ve Doktoralı çalışan sayısı nedir?
– Firma yükseklisans ve doktora çalışmalarını destekliyor mu? Hangi şartlarda destekliyor? [Yüksekeğitimi destekleyen firmaların Araştırma-Geliştirme ve İnovasyon yetenekleri yüksektir. Bu yetenekleri yüksek firmalar çalıştıkları sektörde daha yüksek rekabet gücüne sahip olurlar. Daha yüksek rekabet gücünün çalışanlara yansıması iş sürekliliği, çalışan memnuniyeti ve rekabetçi ücret şeklinde olacaktır.]

İŞ İLANININ İNCELENMESİ
Başvurduğunuz / başvuracağınız iş ilanını (ezberlercesine) inceleyin !
İlanda belirtilen yetkinlikler, özellikler ve deneyimler sizinle ne kadar uyumlu?
– Eğer ilanda belirtilen özelliklerden birkaçını karşılayamıyorsanız;
Bu eksikliklerinizi kısa sürede giderebilir misiniz? O zaman görüşme gününe kadar bu eksikleri giderin.
Bu eksiklikleri gidermek uzun sürecekse ve mülakatta bu eksiklikleriniz ortaya çıkarsa (ki çıkacaktır), bahsi geçen eksiklikleri gidermek için çalışmaya başladığınızı belirtin (ve gerçekten de çalışmaya başlayın !).

İş ilanında belirtilen tüm gerekliliklere sahip olduğunuzu ispatlayacak belgeleri hazırlayın (özgeçmiş, okul döneminde yapılan projeler, katıldığınız seminer / eğitim sertifikaları,…).
İlanda bilmediğiniz kelime / terim / tanımlar var mı? Bunların ne olduğunu mutlaka öğrenin! Mülakatta sorulacağından emin olabilirsiniz.
İlanda yazmasa bile, sahip olduğunuz özellikleri / yetkinlikleri bir liste haline getirin. Mülakatta can kurtarıcı olabilir !

MÜLAKAT
Görüşmeye mutlaka 15 dakika erken gidin. Bunun faydaları:
– Görüşme öncesi doldurmanız istenen belgeler olabilir, bunları doldurup tam zamanında görüşmeye başlayabilirsiniz,
– Herhangi bir sebeple gecikme ihtimalini en aza indirmiş olursunuz, böylece görüşmeyi yapacak kişilerin gözünde puan kaybetmesiniz,
– Aynada kendinize çeki düzen vermek için bolca zamanınız olur.

Mutlaka temiz olun ve işe uygun giyinin.
Yanınızda mavi renk bir dolma kalem / tükenmez kalem bulundurun.
Firmayı ve iş ilanını incelerken aldığınız notları, özgeçmişinizin bir kopyasını, sertifikalarınızın kopyalarını, mülakatta soracağınız soruların listesini de mutlaka yanınızda bulundurun.
Firmaya girdiğiniz andan itibaren “her şeyi” inceleyin: duvardaki resimleri, ofisi, yangın söndürme cihazlarını,… Yani “her şeyi” !
Kendinize güvenin ve bunu görüntünüze yansıtın: Rahat Olun, Dik Durun, Gülümseyin !
Eğer bir şey içmek isteyip istemediğiniz sorulursa sadece su isteyin; çay, kahve veya gazlı bir içecek risklidir.
Ayrıca, yanınızda kağıt mendil bulundurmanız da iyi olacaktır.

Her ne olursa olsun görüştüğünüz kişilere karşı saygılı olun.
Söz sırası size geldiğinde (gerekiyorsa) kendinizi tanıtın; görüşmeyi yapanlar özgeçmişinizi incelemişlerdir fakat bunu bir de sözle duymak isteyeceklerdir.
Size sorulan soruyu tamamen dinlemeden (yani soru bitmeden) cevap vermeye başlamayın.
Soruyu tam olarak anlamadıysanız, tekrar edilmesini isteyin: bu sizi yanlış / eksik bir cevap vermekten kurtarır.

Mülakat süresince bilgi seviyenizi ölçmek için çok çeşitli sorular sorulacaktır. Bu sorulara tam ve anlaşılır cevaplar vermeye çalışın.
Bilmediğiniz konuda bir soru gelirse, konuyu net olarak bilmediğinizi ama bu konu hakkında fikir yürütebileceğinizi belirtin; çoğunlukla fikir yürütmeniz istenecektir. İyi düşünün, bağlantılar kurun ve cevabınızı verin.
– Net olarak bilmediğiniz bir konuda biliyormuşcasına cevap vermeye çalışmak sizi çok zor bir duruma sokabilir.

Eğer iş ilanında yabancı dil belirtilmişse, mülakat tamamen o dilde olabileceği gibi, o dili bildiğinize emin olmak için kısmen de olsa o yabancı dilde birkaç cümle duymak isteyebilirler.
Buna hazırlıklı olun. Eğer pratiğiniz yoksa, yabancı dil bilen bir arkadaşınız ile pratik yapın. Bu, mülakatta daha akıcı konuşmanızı sağlayacaktır.

Kendinizi sürekli geliştirdiğinizi vurgulayın:
– Ve gerçekten de geliştirin; herhangi bir konuda rekabeti kazanmanın en güvenilir yolu Sürekli Gelişme’dir.
– Firmaların bir “yeni mezun”da aradıkları en önemli iki özellik “kendini geliştirme” ve “işe isteklilik”tir.

Kendinizi geliştirmek için süreli yayınları (dergiler), makaleleri, internet sitelerini,… takip edin, mülakatta bu yayınlardan bahsedin.
– Eğer gerçekten takip etmiyorsanız, 1-2 soruda bu anlaşılacaktır.

Özgeçmişinize yazdığınız veya mülakatta söylediğiniz her bir kelime size soru olarak gelebilir:
– Eğer yabancı dil bildiğinizi yazmışsanız, konuşmanız istenecektir,
– “Kurumsal bir firmada çalışmak istediğim için başvurdum” diyorsanız “Kurumsal kelimesini açıklar mısınız?” diye sorulacaktır,
– “Kitap okumayı çok severim” dediyseniz “Son okuduğunuz kitap hangisiydi? Konusunu anlatabilir misiniz?” denecektir,
– 3DS Max kullanabildiğinizi yazdıysanız, “İşte bilgisayar, işte 3DS Max, bir animasyon çizebilir misiniz?” denecektir,

İtiraf edelim, kimse fazla mesai yapmaktan hoşnut olmaz. “Fazla mesai sizi rahatsız eder mi?” diye sorulursa “Kesinlikle hayır, aksine çok severim fazla mesaiyi” gibi bir cevap vermeyin, hiç inandırıcı değil.
Özellikle özel sektörde, kimi zaman fazla mesai yapma ihtiyacı olabilmektedir. Bu gibi bir durumda firmanın menfaatleri icabında elinizden geldiğince destek olabileceğinizi belirtmeniz yeterlidir.

Ve lütfen, stres yapmayın !
– Bir parça heyecan hem sizi uyanık tutacaktır, hem de işe karşı heyecanlı olduğunuzun bir göstergesi olacaktır.
– Ama stres, doğru cümle kurmanızı bile engelleyecek ve görüşmecilerin sanki hiçbir şey bilmediğiniz kanısına kapılmalarına sebep olabilecektir.

Fırsat buldukça firmayı detaylı olarak incelediğinizi, işe ne kadar uygun olduğunuzu ispat edebilmek için daha önceden hazırladığınız listelerde (bakınız “Firmanın Araştırılması” ve “İş İlanının İncelenmesi” sayfaları) önem verdiğiniz konular hakkında konuşun.

Özellikle, firmaya katma değer sağlayacağınızı düşündüğünüz konular varsa, bunları belirtin. – Bu, sizi diğer tüm adaylardan ayıracaktır.

Size “Sizin sormak istedikleriniz var mı?” diye sorulduğunda daha önceden hazırladığınız soruların listesini çıkarın ve (5 dakikayı geçmemek kaydıyla) sorularınızı sorun.
– Bu, sizin firmaya ve işe olan ilginizin bir göstergesidir.
– Ayrıca, firmanın ve işin size uygun olup olmadığını anlamanıza yardımcı olacaktır.

Mülakat sona erdiğinde, size bu şansı tanıdıkları için görüşmecilere teşekkür edin, “umarım birlikte çalışma imkanımız olur” (veya benzer bir cümle) ile görüşmeden ayrılın.

Görüşme sonrasında kendi performansınızı değerlendirin; hangi sorulara cevap veremediniz, hangi durumlarda tutukluk yaşadınız / paniklediniz, özetle, neleri yanlış yaptığınızı liste haline getirin ve bu eksikliklerinizi ilk fırsatta giderin.
– Bir mülakat sizin için olumlu sonuçlanmasa bile, size mülakat deneyimi kazandırmış olacaktır,
– Ayrıca olumsuzluğa neden olan sebepleri tespit edip gidererek daha da güçlenmenize yardımcı olacaktır.

Yazılım Test Mühendisliği Sertifikası

Son zamanlarda tarafıma gelen birkaç e-posta sebebiyle, bir blog mesajı yazmanın faydalı olacağını düşündüm.

Özetle: Test mühendisliği alanında deneyiminiz yoksa, sertifika almak "konuyu ciddiye aldığınız"ın bir göstergesi olacak ve işe girişte size kolaylık sağlayacaktır. Fakat bu iş için birkaç günlük kısa bir eğitime avuç dolusu para vermek gerekir mi? Çok sıcak bakmıyorum. 
Ayrıca, ziyaretçilerin bu makaleye girmiş oldukları sayfanın sonundaki yorumlara da göz atmanızı tavsiye ederim.

Detay:
Yazılım test mühendisliğinin Türkiye'de önemi anlaşılmaya başladıkça, pek çok firma da bu konuda eğitim vermeye başladı. Eğitimler genelde (doğal olarak) sertifika sınavlarının içeriğine yönelik olarak veriliyor diye biliyorum; Google'layarak daha detaylı araştırma yapabilirsiniz.

Gördüğüm bir kaç eğitimin başlığı "ISTQB Uluslararası Sertifikalı Yazılım Test Uzmanı Eğitimi" olarak geçiyor.

Test uzmanı olarak çalışmayı gerçekten istiyorsanız ve test uzmanlığı deneyiminiz yoksa bu tarz bir eğitim konuya daha hızlı ve derli toplu giriş yapmanızı sağlayabilir.
İncelediğim bir eğitim KDVsiyle, sertifika sınavıyla beraber 1,000$ - 1,500$ civarı bir maliyete sahip. Fakat "eğitim" için 3-4 gün gibi süre ayırmışlar ki hem çok pahalı olmuş hem de etkinliğinin yeterli olduğunu düşünmüyorum (2004 yılından beri profesyonel olarak bu alanda çalıştığım için, bu tarz bir değerlendirme yapma lüksümün olduğunu düşünüyorum).

Bir firmadan / kişiden eğitim alsanız bile, hemen sertifika sınavına girmeyin, 3-4 günde sertifikadan geçecek düzeye gelebilir mi bir katılımcı, emin değilim (bence zor). Sınava, kendinizi yeterli hissettiğinizde girersiniz.

Birkaç eğitimin içeriğine şöyle bir baktım, samimi olmak gerekirse, 3 günde ancak bu eğitimler kapsamındaki konularda "ne nedir", yani giriş seviyesinde bilgi edinebilirsiniz, bir miktar da pratik yapma şansınız olur.
Yani 3 günün sonunda "tamam, ben bu işi hallettim" diye düşünmeyin. Çünkü mesela sırf "performans testi" kendi başına apayrı bir uzmanlık alanıdır. Veya bir yük testi aracını hakkını vererek kullanmak 1-2 aylık çalışma gerektirir; öyle birkaç saatte işin içinden çıkılamaz.

Eğitim duyurularında "... eğitimlerimiz sonunda test mühendisliğinde uzmanlaşacaksınız" gibi iddialı ifadeler de var; bu şaka sanırım :)
Dedikleri konularda o kadar kısa bir sürede ancak temel bilgi sahibi olunabilir, "uzman" ise kesinlikle olunamaz!

Yani beklentiniz bu yönde olsun; sonrasında sürekli pratik yaparak (en kolay yolu da bir yazılım firmasında test uzmanı olarak çalışmaktır) bence gayet iyi bir seviyeye gelebilirsiniz.

Sertifikayı almak sektöre girmek için yeterli olur mu?
Bence sertifikaya bile gerek yok, ben yetiştirmek için yanıma aldığım genç arkadaşlarda hiç sertifika aramadım açıkcası.
Sabır, dikkat, kuvvetli insan ilişkileri (ki bence en önemlisi bu), bir işi ard arda yapabilme dirayeti, düzenli çalışma, yazılım alanına ilgi, verilen bir metindeki veya uygulamadaki hatayı görebilme, farklı senaryolar üretebilme... bu tür özelliklere bakılır.

Hiç mi işe yaramaz sertifika? Tabii ki de sektöre girişinizi kolaylaştıracaktır; hiç sertifikası ve/veya deneyimi olmayan birini test uzmanı olarak çalıştırmakla, en azından sertifikası olan birini çalıştırmak tabii ki farklıdır, işveren sertifikalı olanı tercih edecektir, çünkü öğrenme süresi, adaptasyonu daha kolay olacaktır.

O yüzden ben yine sertifika almanızın faydası olacağını düşünüyorum, bu alanda iş deneyiminiz olmadığı için bir ispat olur. Ve belki bir miktar daha yüksek ücret almanıza da vesile olabilir.

Bunun en kolay yolu şu: iş ilanı sitelerindeki test uzmanı, test mühendisi ilanlarına bakın, sertifika lafı geçiyorsa, sektöre girişte faydası olabilir demektir.

Son olarak;
Diyorsanız ki eğer, "kısa bir eğitim için 1,000$ - 1500$ verip eğitime gireceğime, vaktim var, 3 gün değil 3 hafta boyunca uğraşırım, ingilizcem yeterli, internet bağlantım da var, ISTQB, CMMI, Mil-STD, Scrum, Agile, ... konularında zaten standartlar ve eğitim PDF'i kaynıyor internette, ben bunları indirir okurum, öğrenirim, kendime bir portfolyo hazırlarım (örnek bir projenin tüm aşamalarında test süreçlerini uygulamak gibi), test araçlarını SQAFORUM'dan araştırır, deneme sürümlerini kurar öğrenirim...
http://istqb.org/display/ISTQB/Home adresine gider, Syllabi bölümünden Foundation, Expert, Advanced, Glossary bölümlerinden PDF'lerini indiririm, gerekirse amazon.com'dan 1-2 kitap siparişi verir, bunların hepsine çalışırım.
Sonrasında gider 200$'a sertifika sınavına girerim".

Olmaz mı? Bence olur :) Gayet de iyi olur :)

Tüm bu süreci kendi başınıza, tabiri caizse "tırmalayarak", yaşayıp / öğreneceğiniz için, bence daha faydalı olur.

Sonrasında gider sertifikanızı alırsınız.

Yazılım Test Uzmanı / Mühendisi olmak için nereden başlamalıyım?

Bu konuda son zamanlarda pek çok e-posta almaya başladığım için bir blog mesajı oluşturmaya karar verdim.

[ Konu ile ilgili daha önceden hazırladığım özet bir sunuma buradan ulaşabilirsiniz ]

1) Yazılım Test Uzmanı / Mühendisi olmak için nereden başlamalıyım?
Test konseptinin ne olduğunu araştırın. Test nedir? Neden yapılır? Kim yapar? Yapılmazsa ne olur? Ne tür kişisel özellikler gerektirir? Bu özellikler sizde var mı?

Test konsepti ile ilgili olarak internetten bulamayacağınız bir bilgi yok.

2) "Bana Türkçe kaynak sağlayabilir misiniz?"
Ben sağlayamam, fakat internet sağlayacaktır. Aradığınız tüm dokümantasyonu internetten bulabilirsiniz.
Fakat bu belgelerin büyük çoğunluğu ingilizce olacaktır; hiç birimizin bunca belgeyi Türkçeye tercüme etmeye vakti yok.

Kaynak olarak ilk etapta Terimler Sözlüğü'ne, ardından Temel Seviye Test Uzmanı Müfredatı'na bakmakla işe koyulabilirsiniz.
Wikipedia'da da benim yazdıklarımdan kat kat daha fazla bilgiye ulaşabilirsiniz: http://en.wikipedia.org/wiki/Software_testing

J.D. Ph.D Cem Kaner'in web sitesindeki "Publications" kısmı da oldukça güzel kaynaklar içermektedir; Sık Kullanılanlara eklemenizi tavsiye ederim.

3) Yabancı dil bilmek zorunda mıyım?
Kısa cevap: Evet !
Hatta yoğun olarak kullanılan dil ingilizce. Bu benim tercihim değil, dünya genelinde bir tercih. Teknolojiyi üretenler ingilizce kullandığı için sizin de en azından mesleki yayınları takip edebilecek ve gerekmesi durumunda uzmanlığınızı "sunabilecek" derecede ingilizce bilmeniz gerekiyor.
[ Ben diğer yabancı dilleri bilmediğim için diğer yabancı dillerde yazılmış kaynak var mı diye de araştırmadım ]

4) Yeni mezunum, ama test uzmanı / mühendisi olmak istiyorum, firmalara kendimi nasıl kabul ettirebilirim?
Firmalar yeni mezun (deneyimsiz) kişilerden ilgili konuda detaylı bilgi sahibi olmalarını beklemezler; zaten yeni mezunsunuzdur.

Fakat sizi, diğer adaylardan öne çıkartacak birkaç ipucu önerebilirim.
- Hazırlık yapın ! Görüştüğünüz şirketi, çalıştığı sektörü araştırın, bilgi edinin.

- Görüşeceğiniz pozisyonun gerektirdiği özellikleri araştırın, deneyiminiz olmasa bile, pozisyon hakkında araştırma yaptığınızı, genel olarak bilgi sahibi olduğunuzu gösterin.

- Deneyimsiz bir başvuran olarak görüşmecileri etkilemenin en güzel yolu "portfolyo" sunmaktır. Sadece grafik tasarımcıların, mimarların portfolyoları olduğunu düşünüyorsanız, yanılıyorsunuz.

- Bir test mühendisi adayı olarak şöyle bir portfolyo oluşturabilirsiniz: Yazılım geliştirme standartları / metodolojilerini inceleyin. Bu standartlardan bir tanesi için (ISO veya Mil-STD işinizi görecektir) test planlaması ve test tanımları dokümanlarını edinin. Kendi seçtiğiniz bir web sitesi (veya yapabiliyorsanız kendi geliştirdiğiniz bir bilgisayar uygulaması) için bir Test Planı hazırlayın. Bu test planından beslenen bir tane Test Tanımları dokümanı hazırlayın. Testler sırasında otomatik test araçları kullanmaya özen gösterin (en az bir tanesini kullanmayı öğrenin). Seçtiğiniz site / uygulamayı bu dokümanları ve test araçlarını kullanarak test edin. Bir Test Raporu hazırlayın.

Bu konuyla ilgili daha detaylı bir blog mesajım şurada: http://serdartorun.blogspot.com/2011/08/is-basvurularnda-basar-sansnz-artrmann.html

5) Yazılım geliştirme standartlarını bilmek zorunda mıyım? Sadece test yapacağım, kodlama yapmayacağım ki?
Evet, bilmek zorundasınız. Yazılım geliştirme yaşam döngüsünün hangi aşamasında neler üretiliyor, bu üretilen çıktıların test sürecine bir girdisi var mı, bu girdiler test faaliyetlerinin hangi aşamasında neden gereklidir, bu yaşam döngüsü içinde farklı disiplinlerin (sistem mühendisliği, kalite, yazılım geliştirme, test, ...) biriyle ilişkisi nedir ...

Bunları (zamanla) öğrenmek zorundasınız.


{ Yeni sorular geldikçe bu mesaj da güncellenecektir}