Skip to content

Thread safety: nedir, nasıl test edilir?

Wednesday, October 3, 2007

Eğer yazılan kod, eş zamanlı olarak birden fazla iş parçacığı (thread) tarafından işletilirken fonksiyonlarını tam ve eksiksiz olarak yerine getirebiliyorsa, bu kod parçacığı thread safe‘tir denir. Çok işlemli (multi threaded) hesaplamanın en popüler sorunlarından biridir.

Thread safety ile ilgili yazılım hataları, çok büyük ve yıkıcı sonuçları ile biliniyor. Bu sebepten dolayı, bu konuyu buraya taşımak istedim.

Eş zamanlı olarak birden fazla iş parçası tarafından kullanılacak kaynak kodun

  • Kendisi yada kullandığı alt prosedürler yerel kaynaklar haricinde (stack hariç) kaynaklara ulaşıyor olabilir.
  • İçerisinde bazı nicelikler dışarıdan müdahale ile değişiyor olabilir.

ve belki de en önemlisi

  • Birden fazla iş parçası ortak bir kaynağa erişiyor olabilir.

Bu gibi durumlarda thread safety ile ilgili riskleri göz önünde tutmakta fayda vardır.

(DEVAM EDIYOR)


Kategori: Test Mühendisliği | Yorum yapilmamis

Yazılım testi ile ilgili özlü sözler

Wednesday, September 5, 2007

Yazılım testi ile ilgili ellerini kirletmekten çekinmeyen biri olarak, okuduğum bazı şeyler gerçekten sinirlerimi bozmakta. Birçok kişi ve kuruluş, yazılım testi ile ilgili konuştuklarında, kulağa güzel gelen birçok alıntıyı arka arkaya ekleyerek sarfetmekteler.

Örneğin test otomasyonu araçları satan firmalar, araçlarını neredeyse kendi kendine test eden yaratıklar olarak ifade ediyor. Bazı “test mühendisliği eğitimcileri” gereksinimlerin bire bir test edilerek ürünün kalitesi ile ilgili tam bir resmin çizilebileceğini salık vermekte. Kimi firmalar, hedefleri olmayan ve içi boş yük testleri yaparak, yazılım geliştiren firmaları göz göre göre kandırıyor.

Lakin gerçek hayatta, otomasyon çatısını kurmak ve sürekli değişen bir uygulamayı sürdürmek zorunda olmak, hazır olmayan firmalara milyonlarca dolarlara malolmakta. Bu firmaların büyük çoğunluğu şimdi, per-seat lisansına onbinlerce dolar ödedikleri ürünler ile otomatik bir kaosa sahipler.

Çoğu test mühendisi, tam olmayan gereksinimler ile geliştirilen ürünlerde, kimi testleri gerçeklemeyi reddediyor yada daha kötüsü kullanıcı beklentilerini es geçiyorlar.

Birçok ürünün, onbinlerce dolar ödenerek yaptırılan yük testleri ardından, performans tabanlı sorunlar sebebiyle, rampada kaldığını görüyoruz.

Sonuç olarak, iyi niyetle bu pratikleri alıp uygulamaya kalkan ekipler, kısa bir sürede başladıkları noktadan daha kötü bir yerde buluveriyorlar kendilerini.

Bu sebeple, yapısal olarak test yapmak isteyen her ekibin gümüş kurşunları bir kenara bırakarak, yazılım geliştirme biçimleri ve kalite ihtiyaçlarına odaklanmaları gerekmekte.

Sizin için en iyi yazılım testi, ihtiyacınız olan yazılım testidir.

Sizin ihtiyaçlarınız, o alıntıların ve grafiklerin çok ötesinde ve size en uygun biçimiyle gerçeklenen test aktiviteleri olacaktır.

Lütfen metodoloji edinin, çünkü şablonlar öldürür…


Kategori: Test Mühendisliği, Yazılım Geliştirme Süreçleri | Yorum yapilmamis

Nokia E50 ve basına yansıyan yazılım hatası

Wednesday, September 5, 2007

Ürettiğimiz ürünlerin taşıdıkları riskleri doğru biçimde saptayamadığımız durumlarda karşımıza çıkabilecek sorunlara çok iyi bir örnek olduğu için medyada gördüğüm bir haberi buraya taşımayı uygun gördüm.

22 Ağustos 2007 tarihinde gazetelere, Nokia E50 telefonlarda bulunan bir yazılım hatası ile ilgili, bir haber düştü. Bu hata ile ilgili Türkiye’de mobil cihazlar ile ilgili en bilgili insanlardan biri olan sevgili arkadaşım Burak Bayburtlu ile MSN üzerinden sohbet ettik.

Anomali, Internet sitelerinde şu şekilde tanımlanmış: “Gelen arama yanıtlandığında, tüm tuş takımı kilitleniyor ve telefon hands-free moda geçiyor. Hiçbir şekilde telefona müdahale edemediğiniz için, tek yapılabilen telefon bataryasının sökülmesi”. (DEVAM EDIYOR)


Kategori: Genel, Test Mühendisliği | Yorum yapilmamis

EAI Testing | Kurumsal uygulama entegrasyonu testlerinde sorunlar

Wednesday, August 22, 2007

Uzunca bir aradan sonra tekrar merhabalar. Bu makalemde sizlere kurumsal uygulama entegrasyonu (EAI - Enterprise Application Integration) projelerinin testlerinde karşılaşılan sorunlardan bahsetmek istiyorum. Bu makalede yazanlar, evimden yüzlerce (bazen binlerce) kilometre uzakta, uzayan test projeleri süresince sıla hasreti katık edilerek derlenmiştir. Okurun yazıyı okurken, bu ruh halimi dikkate alacağından hiç bir şüphem bulunmuyor.

Evet, müşteriniz uzak diyarlara kendi yazılımını satmıştır. Uygulama diğer birçok uygulama ile entegre çalışacak ama belki de önemli olan sizin müşterinizin de sonunda yazılım ihracatçısı bir firma haline gelmesi. Entegrasyon ekibinin parçası olarak siz de projeye dahilsiniz. Biletiniz, vizeniz ve yeteri kadar çalışacağınız ülkenin yerel parasından cebinizde var. gideceğiniz ülke ile ilgili arkadaşlarınızdan ve Internet‘ten bilgi de topladınız. Artık hazırız!

Hayır! Öncelikle nasıl bir belaya bulaştığınız hususunda bu yazıyı okuyun derim.

(DEVAM EDIYOR)


Kategori: Test Mühendisliği | Yorum yapilmamis

Yazılım test mühendisi ne yapar, ne yapmaz

Tuesday, August 7, 2007

Tekrar selamlar,

Yazmaya uzun bir ara verince, yazılım testi ile ilgili yazmaktan ne kadar keyif aldığımı tekrar gördüm. Gün içerisinde, ofiste oradan oraya koştururken bile burada yayınlamayı düşündüğüm konular ile ilgili notlar alıyorum. İşte bugün de son birkaç günün notlarından çıkanları sizlerle paylaşacağım.

Yazılım testi için ayrı ekipleri olmayan firmalarda genel bir inanış vardır. Gün gelir de, gerçekten adanmış bir ekip ile yazılım testlerini gerçeklerlerse, yazılımlarının daha kaliteli olacağını düşünürler. Hali hazırda yazılım testi ekibine sahip firmalar, bu saptamanın doğru olduğunu görürler, lakin küçük bir detayı da eklemeden duramazlar. (DEVAM EDIYOR)


Kategori: Genel, Test Mühendisliği | Yorum yapilmamis

Test mühendisi olmamak için sebepler

Tuesday, August 7, 2007

Aktif geliştirme, ardından yürüttüğüm geliştirme ekibi yöneticiliği sonrasında başladığım test mühendisliği kariyerim, bende apayrı hisler uyandırmıştır. Bir anda kendimi psikoloji makaleleri okurken, insanın ne şekilde kavradığı konusunda uzun sohbetler içerisinde yada Nüfus Müdürlüğü’nün çalışma sisteminin hatalara ne kadar açık olduğunu düşünürken bulmak benim geek tarafımı gerçekten çok tatmin ediyor.

Ama her meslek gibi test mühendisliğinin de bazı garip tarafları mevcut… Birçok zaman, içine sürüklendiğim durumlardan çıkmak için, çalıştığım disiplin dışındaki bilgilerimden ve deneyimlerimden faydalanmak zorunda kalıyorum. Bu durum beni gerçekten çok sıkıyor. Bir test mühendisi, gerekli formasyona sahip ise, bu formasyonu ile yapması gerekeni yapıp evine mutlu ve mesut gidebilmelidir diye düşünüyorum.

(DEVAM EDIYOR)


Kategori: Genel, Test Mühendisliği | Yorum yapilmamis

Test ekipleri ve iletişim

Friday, August 3, 2007

Yazılım geliştirme süreçlerinde, her bir iş ekibi, çoğunlukla benzer altyapılara sahip kişilerden meydana gelirler. Örneğin sistem analizi konusunda gelişmiş insanlar bir araya gelerek sistem analizi ekiplerini oluştururlar. Benzer altyapılara sahip de olsalar, bu insanların beraberce çalışmaları, ancak yönetim biliminin incelikli detayları yardımıyla birçok sorunun çözülmesiyle sağlanabilir.

Yazılımları ise, bu ekipleri bir araya getirerek üretiriz. Yazılım üretimi ekipler arası bir ekip çalışması olarak adlandırılabilir. Bu yapılanma içerisinde her alt birim kendisi ile ilişkili diğer ekipler ile ortak çalışmak ile yükümlüdür. Tasarımcılar, analistlerin çıktılarını kullanırlar ve ürettikleri ürünler geliştiriciler için çok önemlidir. Geliştirdikleri ürünler test ekiplerince test edilir. Bunun dışında yazılım tasarım ekibi, proje takvimine de uymak konusunda –diğer tüm ekip üyeleri gibi- proje yöneticisine karşı da sorumludurlar.

Test ekipleri ise, müşterilerin, geliştiricilerin, analistlerin, tasarımcıların, proje yöneticilerinin, satış-pazarlama ekibinin, dokümantasyon ekibinin ve belki de muhtemelen ürünün GUI’sinin ne kadar anlaşılır olduğu ile ilgili soru sorduğunuz babanızın da katılımıyla daha da kaotik bir yapılanma içinde çalışırlar.

(DEVAM EDIYOR)


Kategori: Test Mühendisliği | Yorum yapilmamis

Test otomasyonunun kazandırdıkları neye göre ölçülür?

Wednesday, June 20, 2007

Test aktiviteleri gerçeklerken amaçlarımız nelerdir? Belki de test aktivitelerinin en büyük değeri bizlere ürün hakkında sağladığı bilgilerdir. Bu bakış açısından baktığımızda test otomasyonunun katkısını çalışma zamanındaki düşüş ile ölçmek biraz yadırgadığım bir durum.

Konuyu açalım isterseniz. Manuel test ve otomasyon arasında, genel kanının aksine, ciddi farklar mevcuttur. Öncelikle hiçbir çalışma şekli, manuel testin ve dolayısıyla bir insanın gözleminin ötesinde başarılı olamaz. Test otomasyonu ile bu sebeple daha fazla hata bulmak söz konusu değildir. Test otomasyonunu sürekli yapılan kontrollerin bir otomasyonu yada testlerin kapsamını arttıran bir çalışma olarak görmek daha mantıklı olacaktır.

İşin matematiğine bakarsak;

(DEVAM EDIYOR)


Kategori: Test Mühendisliği | Yorumlar (1)

Safari ve kitap ikonlu kapama butonu…

Friday, June 15, 2007

Sanırım iki gün önce Safari web tarayıcısının 3.0 Public Beta versiyonunu bilgisayarıma kurdum. Joel Spolsky’nin bahsettiği gibi performans sorunları ile karşılaşmadım.

Sanırım uyumluluk testi yapan herkes gibi, Windows XP yüklü bilgisayarımda Safari kullanabilecek olmaktan dolayı ben de çok mutluydum. Çünkü özellikle web tabanlı uygulamaların uyumluluk testlerini yaparken sayfaların çeşitli tarayıcılarda ne şekilde göründüklerine dair bazı çalışmalar yapmamız gerekiyor.

Eskiden BrowserShots gibi servisler ile yetinebilen bizler, artık AJAX ve benzeri istemci tarafı iş mantığı barındıran web tabanlı uygulamalar yüzünden bazen bir Mac edinmek durumundaydık. Bu ise her zaman sahip olunan bir imkan olmadığı için zor durumlarda kalabiliyorduk.

Zamanında Internet Explorer’in Mac ve PC versiyonları arasında ECMA Script yorumlayıcılarında ciddi farklar yakalamıştım. Benzer farklılıkları, bu tarayıcıda da bulacağımdan şüphem yoktu. Ama açıkcası ben bu kadar sorunu bir arada göreceğimi de düşünmüyordum.

(DEVAM EDIYOR)


Kategori: Genel | Yorumlar (2)

Yük testleri için iyi pratikler

Friday, June 15, 2007

Uygulamaların yük testlerini yaparken dikkat ettiğimiz birkaç noktayı sizlerle paylaşmak isterim.

Yük testlerini birkaç farklı amaç için yapıyor olabiliriz. Bu testleri kimi zaman sistemin “performansını”, bazen “stabilitesini” yada “sağlamlığını” test etmek için yaparız. Bazı özel koşullarda da sistem üzerindeki hafıza taşması hatalarını dürtüklemek için sistemi yüklediğimiz de olur. Hangi sebeple bu testleri yapıyor olursak olalım, dikkat etmemiz gereken bazı noktalar mevcuttur.

(DEVAM EDIYOR)


Kategori: Test Mühendisliği | Yorum yapilmamis