Kullanıcı ile Empati Kurabilmek Neden Önemlidir?

Bunu örnek bir senaryo üzerinden inceleyelim. Bazı konuları bilerek abartıyorum, çünkü bizler en kötü duruma hazırlıklı olmak için test senaryoları geliştirmeliyiz.

"Ayşe hanım, 4 aylık hamiledir. İstanbul'da toplam çalışanı 750 olan bir devlet dairesinde veznede çalışmaktadır. Aylardan Temmuz ve aynı zamanda Ramazan ayıdır. Dışarıda sıcaklık 37 derece. Klima / havalandırma sistemi arıza yaptığı için çalışma ortamındaki sıcaklık bunaltıcıdır. Saat 16:00'dır ve Ayşe hanımın veznesi önünde bekleyen 25 kişi vardır. Bekleyenler, işlemlerin uzun sürdüğü gerekçesi ile söylenmektedir. İşlem sırası kendisinde olan yaşlı amcamız, evraklarında nelerin eksik olduğunu pek anlayamamıştır ve Ayşe hanımla tartışmaktadır. Bu arada Ayşe hanım, yaşlı amcaya detaylı bilgi vermek istemektedir, fakat 'Detayları Göster' düğmesine tıklamasının üzerinden 3 dakika geçmesine rağmen halen sistem bir cevap verememiştir. Sırada bekleyenlerin sesleri daha da yükselmekte, ortamdaki gerilim de artmaktadır. Ayşe hanım, yan veznedeki Hüseyin beye sistemin onda da çalışıp çalışmadığını sorar. Hüseyin bey 'bu sisteme geçtik geçeli iki yakamız bir araya gelmedi, sürekli donuyor, bekletiyor, garip garip hatalar veriyor' der..."

Biraz hikaye havasında oldu :) Fakat gerçekte de olması gereken de bu.
Şimdi kendinizi o veznede çalışan insanın yerine koyun. Orada bir hizmet vermeye çalışıyorsunuz fakat işlerinizi kolaylaştırması gereken "sistem", sizi engelliyor. Ne yaparsınız? Ne söylersiniz? :)

Bu yüzdendir ki, test mühendisleri olarak, kullanıcılar ile yakın temasta olup, onların hangi zorluklar altında çalıştığı, onlar için nelerin kritik olduğunu öğrenip, geliştirdiğimiz sistemi, bu tür şartlar altında sorunsuz olarak çalışacak hale getirmemiz gerekiyor. Bazı konuları / sıkıntıları kullanıcı size söylemez / söylemek istemeyebilir veya henüz farkında değildir. Fakat siz, deneyiminiz ile, ilerde ne tür ortam olacağını hayal edip, ona göre tedbirlerinizi almalısınız.

Test Mühendisliğinde Teknik mi Önemlidir Sosyal Yetkinlikler mi?

Yani, iyi bir test mühendisi olmak için teknolojilere ve tekniklere mi ihtiyacımız var yoksa sosyal yetkinliklere mi?

Hayatta her konuda olduğu gibi bu konuda da en optimal yaklaşım "denge" sağlamak olmalıdır;
 hem teknik hem de sosyal yetkinlikler önemlidir.

Çok özel durumlarda, örneğin, son kullanıcı / müşteri ile hiç görüşmeyecekseniz ve şirket içinde de tüm iletişimi elektronik yoldan yapıyorsanız, sosyal yeteneklere çok ihtiyacınız olmayabilir.
Fakat böyle çalışan kaç kişi var?

Aslında sadece test mühendisliği değil, genel olarak yazılım mühendisliği yoğun olarak sosyal yetkinliklere (özellikle de empatiye) ihtiyaç duyulan bir alandır.
Kendini müşterinin yerine koyamıyorsan, her gün defalarca ve de saatlerce kullanacağı bir yazılımı geliştiren ekip olarak, müşteri / kullanıcının dertlerini ve önceliklerini anlayamamışsan, "kaliteli" bir ürün verme ihtimalin düşük olacaktır.

Bu durumda, test mühendisi olarak, en kötü durumlar için senaryolar geliştirip, bunları test etmek için gerekli teknik yetkinliklere ihtiyacımız olduğu gibi müşteri / kullanıcının önceliklerini anlamak ve etkili iletişim kurabilmek için sosyal yetkinliklere ihtiyacımız vardır.

Yazılım Test Mühendislerinin Eksiklikleri

Yazılım geliştirme mühendisleri, gelişen teknoloji ve müşteri / şirket beklentileri doğrultusunda sürekli olarak yeni teknolojileri öğrenme ve uygulama mecburiyetindedilrer; en azından "mühendislik" yapan büyük bir kısmı.

Fakat yazılım test mühendislerinde durumun böyle olmadığını gözlemliyorum.
Test mühendisliği teknikleri daha yavaş ilerleme ihtiyacı duyuyor olabileceği gibi test yazılımları / teknolojileri de daha yavaş gelişim gösterme gereği duyuyor olabilir.
Bu bir tarafa...

Asıl sorun, test mühendislerinin bir aşamaya kadar kendilerini eğitip sonrasında "duraklama dönemi"ne girmeleri. Pek çok meslekte var bu sorun fakat onlar hakkında yorum yapacak deneyimim yok...

Gördüğüm sorunlar şu şekilde:
- Birkaç manuel test tekniği, planlama, test tasarımı ve geliştirme konusunda deneyim sahibi olunur,
- Bir parça SDLC bilgisine sahip olunur,
- Çok nadiren, mecbur kalındıkça test araçları öğrenilir,
- Ve "zaten ben bu işte her şeyi biliyorum" diye uzunca yıllar bu bilgilere yenisi pek eklenmeden devam edilir.

Ben de aslında çok farklı değildim; bunun sebepleri biraz deneyimsizlik biraz da yol gösteren / referans alabileceğin kişilerin azlığı.

Fakat günümüzde durum farklı.
Bu meslek dalı yaygınlaştı; kitaplar, videolar, bloglar, standartlar, metodolojiler fazla fazla var.
Geriye kalan tek ihtiyaç kişinin öğrenme isteği oluyor.

Gereksinim ile Tanımlama Arasında Ne Fark Vardır?

IEEE Yazılım Mühendisliği Terminolojisinin Standart Sözlüğü'ne göre:

Gereksinim (Requirement) 
(1) Bir problemi çözme veya bir amacı gerçekleştirmek için kullanıcı tarafından ihtiyaç duyulan bir durum veya kabiliyet,
(2) Bir sistem veya sistem bileşeninin bir sözleşme, standart, tanımlama veya resmi olarak dayatılan diğer dokümanların isteklerine cevap verebilmesi için karşılaması veya sahip olması gereken bir durum veya kabiliyet.
(3) (1) ve (2)deki gibi, bir durum veya kabiliyetin dokümante edilmiş gösterimi.

Tanımlama (Specification) 
Bir sistem veya bileşenin gereksinimleri, tasarımı, davranışı veya diğer karakteristiklerini tam, kesin, doğrulanabilir bir şekilde tanımlayan bir dokümandır.

İstisnai Durum (Exception) Nedir ve Java'da Yaygın Karşılaşılan İstisnai Durumlar Nelerdir?

"Exception" kelimesini İstisna veya İstisnai Durumu olarak tercüme edebiliriz.
Oracle'a göre istisnanın açıklaması şöyle:
"Bir programın çalışması sırasında ortaya çıkan ve programın normal komut akışını bozan bir durumdur."

İstisnaların "throw" ile atılması, "try/catch/finally" ile yakalanması gerekmektedir. Kontrol altına alınmamış istisna durumları RuntimeException olarak adlandırılır.

Java'da yaygın olarak karşılaşılan istisnai durumlar ve açıklamaları aşağıdadır. Yaptığınız testlerde bu istisna durumlarına özellikle dikkat etmeniz faydalı olur.
(Tam liste için http://docs.oracle.com/javase/7/docs/api/java/lang/Exception.html adresine bakabilirsiniz.)

ArithmeticException 
İstisnai bir aritmetik durum ortaya çıktığında atılır.

ArrayIndexOutOfBoundsException 
Bir diziye (array) geçerli olmayan bir indeks numarası ile erişilmeye çalışıldığında atılır.

ArrayStoreException 
Bir nesne dizisi içine yanlış tipte bir nesne kaydedilmeye çalışıldığında atılır.

ClassNotFoundException 
Bir uygulama bir sınıfı karakter dizisi ismi ile (Class sınıfındaki forName metodunu kullanarak) yüklemeye çalıştığında atılır.

IllegalArgumentException 
Bir metotun geçerli veya uygun olmayan bir argümanı geçirmeye çalıştığını belirtmek için atılır.

IllegalStateException 
Bir metot geçerli veya uygun olmayan bir zamanda çağrıldığında atılır.

IllegalThreadStateException 
Bir iş parçacığının, talep edilen işlem için uygun bir durumda olmadığını belirtmek için atılır.

IndexOutOfBoundsException 
Herhangi bir tipteki (dizi, karakter dizisi, veya vektör gibi) indeksin sınırları dışında olduğunu belirtmek için atılır.

InterruptedException 
Bir iş parçacığı ("thread") beklerken, uyurken veya diğer türlü bir şekilde meşgulken, bu iş parçacığına iş yaparken veya işini bitirmeden müdahale edilirse atılır.

NegativeArraySizeException
Uygulama negatif genişlikte bir dizi oluşturmaya çalıştığında atılır.

NoSuchMethodException 
Belirli bir metot bulunamadığında atılır.

NullPointerException 
Bir uygulama, bir nesnenin gerektiği bir durumda "null" kullanmaya çalıştığında atılır.

NumberFormatException 
Uygulamanın bir karakter dizisini nümerik tiplerden birine dönüştürmeye çalıştığı ama karakter dizisinin uygun formata sahip olmadığını belirtmek için atılır.

RuntimeException 
RuntimeException, Java Sanal Makinası'nın normal çalışması sırasında atılabilecek diğer istisnaların bir süpersınıfıdır.

SecurityException 
Güvenlik yöneticisii tarafından bir güvenlik ihlali olduğunu belirtmek için atılır.

StringIndexOutOfBoundsException 
Bu istisna "String" methodları tarafından, bir indeksin ya negatif veya karakter dizisinin uzunluğundan büyük olduğunu belirtmek için atılır.

UnsupportedOperationException 
Talep edilen işlemin desteklenmediğini belirtmek için atılır.

Ayrıca, aşağıda belirtilen durumlarda en sık karşılaşılan istisnalar listelenmiştir:

Casting: ClassCastException
Arrays: ArrayIndexOutOfBoundsException, NullPointerException
Collections: NullPointerException, ClassCastException
IO: java.io.IOException, java.io.FileNotFoundException, java.io.EOFException
Serialization: java.io.ObjectStreamException
Threads: InterruptedException, SecurityException, IllegalThreadStateException

Şu video da oldukça faydalı: How to handle 10 common Java Exceptions

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ı

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

Yazılım Ekiplerinde Performansı Olumsuz Etkileyen 1 Numaralı Etken

Son 10 senedir yazılım projelerinde çalışarak edindiğim deneyim sonucu diyebilirim ki, bir proje ekibinin günlük performansını en çok olumsuz etkileyen faktör, çalışanın kısa süreli aralıklarla bölünmesidir.
Yüksek bir seviyede odaklanma gerektiren diğer işlerde de olduğu gibi, özellikle yazılım geliştirme (kodlama) ve test (doğrulama ve geçerleme) aktiviteleri de yoğun bir konsantrasyon gerektirmektedir.

Her 3-5 dakikada bir çalışması bölünen kişinin gün içindeki performansı aşırı derecede düşmesi de kaçınılmazdır. Bu performans kaybının hem üretkenliği hem çalışan memnuniyetini hem de nihai ürünün kalitesini olumsuz etkilediğini rahatlıkla söyleyebilirim.

Yazılımda Bulunan Hata, Kimin Hatası?

Bir ürünü geliştiren kişi yeterli bilgiye sahip olmayabilir, dikkatsiz davranmış olabilir, önemsememiş olabilir, ..., en nihayetinde üründe bir hataya sebebiyet verilmiş olabilir.
Evet, ürünü geliştiren kişinin bu hatada payı vardı, fakat bulunan hata gerçekten de sadece geliştirene mi aittir?

Nihai bir yazılım ürününde bulunan bir hatayı sadece o uygulama kodunu geliştiren kişiye atfedebilir miyiz?
Hayır !

Çünkü, her ne kadar geliştirme/yazma işini yapan kişinin gözünden bu hata kaçmışsa da, o yazılım kodunu gözden geçirmekle, birim testlerini yapmakla, fonksiyonel testlerini yapmakla, gerekli kaynakları sağlamakla sorumlu kişiler de bu hatayı kaçırmış demektir !

Dolayısıyla, (daha önceden de yazdığım gibi) üründe yapılmış olan hata, sadece ilgili kod parçasını yazan kişinin değil, proje ekibinindir.

Ve eğer proje ekibi, üründe bulunan hatalara bu bakış açısıyla yaklaşırsa, kimseyi rencide etmeden, ekibin motivasyon ve performansını olumsuz etkilemeden süreci yönetmiş olacaktır.

Yazılım Testinde İletişim Ne Kadar Önemli?

Sosyal olma ve kolay iletişim kurabilme bir yazılım test uzmanı için hayati öneme sahiptir; özellikle de müşterili projelerde...

Test uzmanları şirket içinde projenin müşterisi rolünü üstlenirler. Bu rol sebebiyle tam olarak nihai müşterinin istediği ürünün teslim edildiğine ikna olana kadar ürünleri sorgulamak durumundadırlar.
Test uzmanı, geliştirilen projeyi nihai müşteriye kabul ettirecek kişidir. Bu sebeple, kabul testlerinde herhangi bir sorun / aksama olmaması için, şirket içindeki testlerde gereksinimlerin tam olarak karşılandığından ve üründe (bilinen) herhangi bir hata olmadığından emin olmak zorundadır; aksi halde ürünün teslimatı gecikecek ve hem şirket hem de müşteri zarara uğrayacaktır.


Bu sorgulama süreci, yazılım geliştirme ekibi ile sürtüşmelere sebep olabilir; özellikle uygulamada bulunan bir uygunsuzluğun hata olarak değerlendirilip değerlendirilemeyeceği konusunda...

Gerek şirket içerisinde gerekse de müşteri ile olan iletişimde esas önemli olan empati kurabilmektir.

Projelerde yazılım geliştirme ekipleri, bir ürünün analizi, tasarımı, kodlaması, birim testi, dokümantasyonu, hataların giderilmesi gibi pek çok konuda yoğun ve stresli bir şekilde çalışmak durumda kalabilirler; özellikle kısa takvime sahip projelerde...

Böyle stresli durumlarda iletişim kurulan kişilerin bu durumlarını da göz önünde bulundurarak, üzerinde konuşulan konu ne ise, karşı tarafı suçlamadan ve çözüm odaklı bir şekilde müşteri isteğinin karşılanması esastır.

Bu noktada bir test uzmanına düşen görev, bildirdiği uygunsuzluğun içeriği, gerekli veri setleri, uygulama çıktıları, ekran görüntüleri ve müşteri isteğinin ne olduğu, sistemin hangi özelliğini veya özelliklerini etkilediğini anlaşılır bir şekilde yazılım ekibine iletmektir; bildirilen uygunsuzluk ne kadar anlaşılır tanımlanmış ise ilgili geliştirici de uygunsuzluğu o kadar hızlı tespit edip, düzeltecektir.

Uygulamada bulunan hatayı herhangi bir çalışana adreslemek (senin hatan izlenimini vermek) yanlıştır. Gerçekte de, hata bir kişinin değil, proje ekibinindir.

Nihai müşteri tarafında ise test uzmanı ürünü müşteriye kabul ettiren kişidir; şüphesiz ki proje yöneticisi, lider yazılım geliştirme uzmanı, kalite güven uzmanı da kabul sürecinde yer alır, ancak kabule esas teşkil edecek testlerin gerçekleştirilmesi ve başarılı olması test uzmanının sorumluluğundadır.

Peki test uzmanı test dokümanlarını kullanarak bir kabul testini gerçekleştirirken müşteri ile ilişkilerinin kabulde ne gibi bir etkisi vardır?

Aynı şirket içerisindeki ekiple iletişim kurduğu gibi müşteri ile de iletişiminde empati kurabilmelidir. Müşteri, belli bir ücret karşılığında şirketinin/kurumunun işlerinde kullanmak üzere bir yazılım sipariş etmiştir ve verdiği paranın tam karşılığını aldığından emin olmak istemektedir.

Test uzmanı nihai müşteri ile sadece kabul testlerinde değil, sözleşmenin imzalanmasından itibaren analiz, ekran tasarımları, prototiplerin kullanımı, ilerleme toplantıları gibi pek çok proje aktivitesinde yakın bir şekilde çalışma imkanı bulur. Bu süreçte sözleşme, konsept dokümanları, analiz dokümanlarında belirtilenlerden öte müşterinin uygulamayı hangi amaçla kullanacağını, müşteri için nelerin kritik olduğunu, hangi tür iş adımlarını daha sık yaptıklarını, uygulamayı kullanacak nihai kullanıcının deneyim ve bilgi seviyesini mümkün olduğunca irdeleyip, "müşterinin ruhu"nu yakalamaya çalışmalıdır.

Böylece, kendisini müşteri yerine koyup, şirket içindeki testlerde, tabii ki gereksinimlere uygun olarak, fakat gereksinimlerde belirtilmemiş kullanım alışkanlıkları, iş adımlarında sık tekrarlanan ve kritik olan özelliklere daha da önem vererek testlerini hazırlaması ve koşturması önemlidir. Çünkü en nihayetinde bir yazılım ürünü kullanıcı gereksinimlerini bire bir karşılıyor olsa da "müşterinin ruhu"nu yakalayamıyorsa, kabul aşamasında sorunlar yaşanması kaçınılmazdır.

Bu nedenlerle bir test uzmanının empati kurarak, müşterinin ruhuna uygun ürünü teslim edebilmek için, hem proje ekibi hem de müşteri ile iyi, yakın ve çözüm odaklı ilişkiler kurması önemlidir.

Yazılım Testi ve Kalite Güvence Dergisi (İngilizce)

Uzun zamandır takip ettiğim ve çok da başarılı bulduğum bir dergiyi paylaşıyorum.
Software Test and Quality Assurance (Eski adı Software Test and Performance idi):
http://www.softwaretestpro.com/Publication/p/STPM/2012

Geçmiş yıllara ait sayıları da okumanızı öneririm, zira bazı konseptler çok da hızlı değişmiyor.
Ücretsiz üyelik seçeneği de var.

Yazılım Testi Terimler Sözlüğü

Yazılım Testine ait terimlerin (ki yazılım teknolojileri ilerledikçe yeni terimler literatüre giriyor) listesini buraya yazmaktansa iki adet güvenilir (İngilizce) bağlantı paylaşıyorum:

Software Testing Glossary (by ApTest): http://www.aptest.com/glossary.html

ISTQB Glossary of Testing Terms: http://istqb.org/downloads/finish/20/14.html

1012-2004 IEEE Standard for Software Verification & Validation

IEEE'in Yazılım Geçerleme ve Doğrulama Standartı'nın mevcut güncel versiyonu IEEE 1012-2004.
Bunu IEEE'nin sitesinden ücreti karşılığında satın alabilirsiniz (şirketinize aldırabilirsiniz).
http://standards.ieee.org/findstds/standard/1012-2004.html

(Yasal olmayan bir şekilde bazı sitelere de yüklenmiş; kişisel kullanımda sorun olacağını sanmam ama şirketinize bu tür yasal olmayan standartları sokmanızı tavsiye etmem.)

IEEE Standards Errata Page / IEEE Standartları Hata Sayfası

For errata of IEEE standards, check the link periodically:
IEEE Standartlarında tespit edilen hata/eksiklikler için aşağıdaki bağlantıyı kontrol edin:

http://standards.ieee.org/findstds/errata/index.html

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

Yazılım Testi - Entegrasyon Testi

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: "ben sizin hazirladiginiz slayti internetteki arastimalarim sirasinda buldum. bir sistem gelistiren X kisilik bir grubumuz var. test kismi ile ben ilgileniyorum. entegrasyon testlerinin tam olarak nasil ve hangi toolla yapildigini aciklayan birseyler bulamadim. bu konuda bana yardimci olursaniz cok sevinirim."


Cevap: "Entegrasyon testleri size ne çağrıştırıyor? Araç kısmını boşverin şimdilik. Yöntem olarak neyi çağrıştırıyor? Bir de hangi seviyede test yapıyorsunuz? Birim mi yazılım mı? (Unit / CSCI / System / ...)"


Soru: "hazirladigimiz projenin gerekliligi olarak once unit test ardindan component test sonra integration test ve son olarak sistem testyapacagim. internetten ogrendigim kadariyla integration testleri birbirinden bagimsiz calisan komponentlerin birlikte dogru calisip calismadigini kontrol ediyor. ama acikcasi su anda herhangi birseyi cagristirmiyor :) daha evvel yalnizca unit test yaptim. "


Cevap: "V-cycle'ı biliyorsunuzdur. Her geliştirme seviyesine bir test karşılık geliyor. 
Birim testini sonuçta Software Design'a göre yapıyorsunuz.
Birim entegrasyon testini Interface Design maddelerine göre yapıyorsunuz.
Bileşen testini Software Requirements'a göre,
Sistem entegrasyon testini Interface Requirements'a göre (SRS veya SSS içindeki arayüz gereksinimleri) yapıyorsunuz.

Burada amaç nedir?
Kendi başına (gerektiğinde mock-up'la , simülatörle, ... desteklenerek) çalıştığını gördüğümüz bileşenleri, System Integration Verification Plan'da hangi sırada entegre edileceğini belirledikten sonra, entegrasyon sırasına göre bu bileşenleri "gereksinimlerine göre" test etmek.

Örnek: 4 tane bileşen olsun (1-2-3-4). Bunları bottom-up, top-down, big-bang gibi yöntemlerle entegre edebiliriz (ki genelde maliyeti düşürmek için big-bang yaparlar). Önce 1 ile 2, sonra 3 ile 4, sonra 12 - 34'ü entegre edebiliriz.
Ya da, Önce 2-3, sonra 1-23, sonra da 123-4'ü entegre edebiliriz...
Sıra ne olursa olsun, sonuçta bu entegre edilen bileşenler birbirlerinden bir bilgi alacak veya dışarıya bir bilgi vereceklerdir.
Entegrasyon testinde yapılan da bu giden-gelen bilginin doğru aktarılıp aktarılmadığını görmek, ki sistem seviyesi testte hem bu detayda teste zaman olmaz (gerek de olmaz). Bir diğer yararı da entegrasyon sebebiyle ortaya çıkacak hatalar daha erkenden tespit edilebilir..."

Yazılım Testi - İş Değiştirmeli Miyim?

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: "... bilgisayar mühendisiyim ve mezun olduktan sonra  ... 6 ay çalıştım.Ardından başka bir şirkette test uzmanı olarak göreve başladım. hala aynı yerde devam etmekteyim.

... yoğundum ve o kadar çok işe yaradığımı düşünüyordum ki,buraya gelince test uzmanı olarak sanki bana ihtiyaç yokmuş.Fazladan gidermiş gibi hissetmeye başladım kendimi. Aslında karakter olarak test uzmanlığına çok yatkın birisiyim.İşimi iyi yaptığım söyleniyor. Fakat bazen okadar boş oluyorumki. 

...

Fakat yazılımcıları beklemekten başka çare yok:(

Acaba iş yerinden ayrılmalı mıyım diye düşünmekteyim.Ama çok sık iş değiştirmek iyi değil diye ne yapacağımı bilemiyorum. ..."

Cevap: Tabii şirketten şirkete göre değişir senin durumun. Bazı şirketlerin süreçleri test aktivitelerini tüm projeye yararlar, böyle olunca boş vaktin hiç kalmaz; bazıları ise daha kesik kesik gider, bir dönem insanlar boş kalabilir.

Ben sorunun sende olduğunu sanmıyorum; kendini kötü hissetmeni gerektirecek bir durum da yok bence.
Eğer şirketin işleri çok değilse, nedenlerden biri bu olabilir.
Şirket teste önem vermiyorsa, sadece son kullanıcı testini yeterli görüyorsa, neden bu da olabilir...
...

Yani özetle bence sende bir sorun yok. Kaldı ki boşta kaldığı için bunu kendine dert edecek kadar bilinçli bir çalışan her firmanın başına :)

Hangi testleri yapıyorsun orada? Sadece fonksiyonel son kullanıcı testi mi?
Belki diğer test türlerini de uygularsan hem kendini geliştirirsin hem de boş kalmamış olursun: performans (yük ve stres) testi, web servis testi, (belki) birim test, (farklı sistemlere) uyumluluk testi, (standartlara) uygunluk testi, gibi.

Eğer şirkette bu konuda bir süreç yoksa, süreç geliştirme faaliyetlerine de başlayabilirsin; eminim şirketin de oldukça işine yarayacak ve hoşuna gidecektir (tabii şirketin bakış açısı bu yöndeyse :) ).

"Yazılımcıları beklemekten başka çare yok" dediğin için şunu anlıyorum; o şirkette analiz sonrasında tasarım pek yapılmıyor ve sen de test dokümanı yazmak ve test yapmak için beklemek zorunda kalıyorsun; ki aslında tasarımı yapıyor olsalar, sen onlara ihtiyaç duymadan testlerini yazabilirsin.

Eğer şirket agile yöntemle geliştirme yapıyorsa, şu şekilde boşta kalmazsın; sana iterasyonlar halinde release yaparlar, sen de bunları 1-2 haftalık periyotlarla test edersin (yani spiral yöntemdeki gibi).

Sık iş değiştirmek, evet, pek hoşlanılan bir şey değildir. Sanıyorum ki yeni mezunsun.
Fakat yeni başvuracağın yere derdini iyi anlatırsan çok da bir sorun olacağını sanmıyorum. Hani 10 senedir çalışıyor olsaydın ve 1-2 senede bir yer değiştiriyor olsaydın, yeni şirkete verdiğin mesaj şu olacaktı: "1-2 sene içinde sizden de ayrılacağım!".

İş değiştirmek istemenin tek nedeni boşlukta kalmaksa, bence bu boşluğu yukarıda anlattıklarımı yaparak doldurabilirsin.

Firmalar "geliştir-sat" döngüsüne odaklandığı için genelde süreçleri göz ardı ederler. Özellikle mikro / küçük ölçekli firmaların zaten genelde ya haberi yoktur ya da buna ayıracak kaynakları.

Madem ki müdürün destek oluyor sana, bence bir yol haritası hazırla, SDLC'lere göre nerede ne yapılması gerekiyor ve bu süreçlerin her biri için ne tür test aktiviteleri yapılacak, hangi dokümanlar çıkacak, ... sonra bunu detaylandırırsın:
standartlara uygun doküman şablonları, teknik terimler sözlüğü, test süreci prosedürü (ne zaman kim ne yapacak), testlere input olacak doküman / süreçler hangileri, test sürecinin çıktıları neler, hata takip süreci nasıl olacak,... gibi aslında 100lerce konu var.

Tüm bunları baştan sona yapıp, uyguladığın zaman hem iyi bir test developer hem de test manager olabilirsin.

Sana yardımı dokunacak keywordler:
CMMI, TMMI, ISO, IEEE, ISTQB, http://www.sqaforums.com,
http://www.softwaretestingstandard.org/

Yazılım Sektörü Açısından İki Temel Sorun

Ülkede sorun çok; sorunun çok olduğu yerde aslında iş fırsatları da çok olur. Tabii, "fırsat temelli girişimcilik" anlayışı varsa...

Sorunlardan ilki standartlarımız yok.
Kamu web sitelerinin her biri diğerinden farklı; içeriği, tasarımı, çalışma hızı,... hepsi farklı.
Hatta bir kurumun kendi il ve ilçe müdürlüklerinin web siteleri bile birbirinden farklı.
Semboloji standartı yok; TSE'de de bulamadım.
Bu konuda talep aslında özel sektörden gelmeli. Kamu politikalarını şekillendiren üç etmenden birisi "baskı grupları"dır ve özel sektör de bu baskı grubunun içinde yer alır. Eğer firmalar bir komisyon oluşturup (örneğin TÜSİAD veya TOBB içinde) devleti en erken zamanda (kendi sektörleri ile ilgili konularda) standart belirlemeye teşvik ederse, bu hem ürünler arasındaki uyumsuzluğu ciddi derecede azaltır, hem gerek firmaların gerekse de devletin maliyetlerini azaltır, hem de sektöre yeni giren firmaların kalitelerini artırır. İkincil derecede faydaları üzerine bir miktar düşünüldüğünde konunun önemi ortaya çıkar.
(Uluslararası standartlara uygunluk tabii ki önemlidir. Fakat şu da unutulmamalı ki, bazı standartlar her ne kadar "uluslararası" diye anılsa da, aslında standartı ortaya çıkaran ülkenin ekonomik gücü ile orantılı olarak kendi standartının küresel ölçekte geçerli bir standart haline gelmesi için gerekli baskıları yapmaktadır. Konu ile ilgili olarak TCP/IP'nin neden ve nasıl bir internet standartı haline geldiğini araştırabilirsiniz.)

İkinci ve daha da büyük olan sorun ise "firmalar arası işbirliği" eksikliği.
Kamu-Üniversite-Özel Sektör işbirlikleri üzerine pekçok makale ve kitap var. Firmalar arasındaki işbirlikler ile ilgili literatür de oldukça geniş (kümeleşme, iş ağları, rekabet öncesi işbirlikleri)... Hatta devletin bu konuda teşvikleri bile var (bakınız KOSGEB).

Fakat her firma bir diğerini rakip olarak (hatta rakip tanımı az bile kalıyor) görme eğiliminde. Evet, kapitalist ekonominin dinamikleri ve inovasyonun yarattığı ekstra baskı yüzünden firmalar hayatta kalmak için diğerleri ile sürekli rekabet halindeler ve bu gayet de doğal bir durum.
Fakat yine aynı doğallıkla, yerli firmaların sektörü büyütmek, yabancı firmaların monopolcü baskılarına direnmek ve bunu bertaraf etmek, özümseme ve inovasyon kapasitelerini artırmak, ihracatlarını artırmak, ... için işbirliklerine şiddetle ihtiyaçları vardır.
Teknoloji Geliştirme Bölgeleri her ne kadar firmaları (biraz zoraki bir şekilde) bir araya getirse de, bu bir arada bulunma yeterli derecede kümeleşmeye ve iş ağları kurmaya dönüşmüyor.

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