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/