Skip to content

Keyword Driven Automation

Tuesday, December 4, 2007

Web tabanlı uygulama geliştiren ekipler için keyword driven automation birçok artıyı beraberinde getiriyor. Bu yazıda beraberce basit bir keyword driven automation alt yapısını inceleyeceğiz.

Keyword Driven YaklaşımLakin dikkat! Burada bahsettiğimiz konsepti birebir alıp uygulamak işinize yaramayabilir yada daha kötüsü sizin durumunuz için hiç de uygun olmayan şeylerden bahsediyor olabiliriz. Bu sebeple kendiniz için benzer bir sistem üretmeden yada satın almadan önce konu ile ilgili yazdıklarıma ve Cem Kaner’in makalesine -özellikle “Maintainability is a Requirements Issue” başlığına- göz atmanızı tavsiye ederim.

Bizim çok statik bir senaryomuz var. Testlerimizi otomasyon altına almaya karar verdik ve uygun model olarak keyword driven bir yaklaşımı seçtik. Bu ön koşullar ile fikir üretmeye başlayalım.

(DEVAM EDIYOR)


Kategori: Test Mühendisliği | Yorum yapilmamis

Test dokümantasyonu – Perde II (James ve Jim birbirine girer)

Monday, November 26, 2007

jbachBugün BlogLines üzerinde bu flame-war dikkatimi çekti. (Siz de sürekli okuduğunuz blog yazarlarını benim gibi BlogLines kullanarak takip ediyorsunuz değil mi? ) James Bach ve Jim Pensyl (Jake Brake olarak da anılıyor kendileri) yakın zamanda test dokümantasyonu konusunda bir flame-war başlatmış durumdalar. Jim ani bir kararla oyundan çekildiği için şu anda sadece bir yerde yazı altındaki yorumları görebiliyoruz.

Tartışma kabaca "dokümante etmek genelde gereksizdir" ile "çoğunlukla gereklidir" arasında gidip geliyor. Sürekli okurlar, benim konu ile ilgili fikirlerimi biliyorlar zaten, lakin bu durumda şunu da belirtmeden geçemeyeceğim.

Böylesine kadar siyah ve beyaz bir algı ile bu gibi konuların tartışılması ne kadar doğrudur bilemiyorum. Zira James de durumu irdelerken "dokümante edilmesi gereken projeler de mevcuttur" demiş ama Jim "bu da benim dediğime gelebilir. Gerekmediği durumlarda neden gerekmiyor peki?" gibi çıkışlar yapmış.

Böylesine bir tartışmanın laf dalaşını aşıp yapıcı bir noktaya gelmesi, özellikle Jim’in "büyüklük bende kalsın" tavrından sonra, biraz zor görünüyor. Lakin dışarıdan katılan insanların konu ile ilgili fikirleri ilginç. Göz atmanızı şiddetle tavsiye ederim.

İyi Testler


Kategori: Genel | Yorum yapilmamis

Kaygan yokuşta yazılım testi ve hata sınıflandırmaları

Friday, November 23, 2007

Bir kişiye ne zaman kel dersiniz? Alnı açıldığında mı? Yoksa başının tepesinde bir açıklık oluştuğunda mı? Böylesine muğlak bir durumda nasıl karar veririz? Etrafımızdaki insanları kel yada değil şeklinde sınıflandırmamıza gerek yok, kabul ediyorum. Ama, test mühendisleri olarak yazılımlarda farkettiğimiz anomalileri benzer bir muğlaklık içerisinde sınıflandırıyoruz.886220_blue

Saptadığınız anomali bug mı? Eğer bir bug ise ciddiyeti nedir? Bu tip soruların yanıtları zordur ve imkan verirseniz kişiden kişiye değişir.

Temellere dönelim ve saçları gür olan bir arkadaşımızı alalım ele. Bu arkadaşımızın saçından bir tel koparırsak bu onu kel yapmaz. Peki saç tellerini teker teker koparmaya devam etsem, hangi aşamadan sonra bu kişi kel kabul edilir?

Günlük yaşantımızda bu tip muğlak durumlarda düşünmeden karar veririz. Eğer bir kişinin kel olup olmadığından emin değilsek, “kelleşiyor” diyebiliriz mesela. Algımızda böylesi iki uç arasındaki ayrım net olmadığında, istemsizce bunu nesnelleştirir ve sınıflandırırız.

Bu duruma felsefede kaygan yokuş yanılsaması (Slippery Slope Fallacy) denir. En basit haliyle aralarında süreklilik barındıran iki terim arasındaki muğlaklıktan kaynaklanır.

(DEVAM EDIYOR)


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

Yazılım hatalarının maliyeti üzerine

Friday, November 23, 2007

Geçen günlerde geliştireceğimiz E-Ticaret sitesinin spesifikasyonları elimize geçti. Statik teste başladık. Verilen bir siparişin kargo bedeli ile ilgili aşağıdaki maddelere yer verilmişti.

eS 4.5.49 Sipariş 100 YTL’yi geçiyor ise, kargo bedeli 0 YTL olarak hesaplanır.

…..

eS 11.6.3 Yurtdışı siparişlerinde kargo bedeli, teslimat adresinde belirtilen ülkeye ait desi-kargo bedeli tablosu uyarınca hesaplanır.

Tüm dokümanı tekrar inceledim, kargo bedelinin hesaplanması ile ilgili başka birşey bulamadım. Yurt dışına yapılan gönderiler 100 YTL’yi geçtiğinde ne olacağını merak edip örnek bir ürün için Almanya’ya gönderi bedelininin 45€ olacağını öğrendiğimde tedirgin olmuştum. Zira eğer 100 YTL’ye şişe mantarı satmıyorsanız, böyle bir durumda sizi temin ederim zarar edersiniz.

Çözümü tabii ki basitti. Yukarıda gördüğünüz ilk madde "Yurt içine gönderilen sipariş 100 YTL’yi geçiyor ise.." şeklinde değiştirildi.

Böylesine küçük bir detayı farketmeseydik ne olurdu?

Böyle bir olasılığın geliştirme ekibi içerisinde saptanıp giderilmesi imkansız, imkan olsa da maliyetlidir. Belki de bitmiş üründe bir bu durumu farkedecek ve uygulamanın bazı noktalarının tekrar kodlanması gerekecekti. Grafik tasarımındaki yanar-döner "Ücretsiz Kargo" flash’larından bahsetmiyorum bile!

six sigma portalına link

Biz gerekli değişikliği zamanında yaptık. Bu sayede pazarlama ve grafik tasarım ekipleri sloganları ve Flash banner’ları buna göre tasarladılar. Yazılım tasarım ekibi kargo bedeli hesaplanması ile ilgili iş mantığını buna göre yazdı ve ürün çalışmaya başladığında müşterimizin başı artık ağrımayacak. Geliştiriciler tekrar kod yazmadılar ve hala proje takvimine uygun ilerliyoruz.

604aYazılım hatalarını sadece kaynak kodda aramak yanlıştır. Bazen yazılım "spesifikasyona bire-bir uyumlu" ama hatalarla dolu olabilir. Burada önemli olan, yazılım geliştirme süreçlerinden ziyade, yazılımın kullanılma amacı ve karşıladığı ihtiyaçlardır. Belki de yazılım geliştirme süreçlerimize o kadar gömülüyoruz ki, ürettiğimiz "şeyin" amacını unutuveriyoruz.

Diğer bir nokta ise bu hatayı erken bularak kazandığımız zaman ve paradır. Yazılım spesifikasyonlarına iki kelime ekleyerek çok daha düşük bir maliyetle bu hatayı giderebildik. IBM Systems Science Institute tarafından yapılan bir araştırmaya göre bir hatanın düzeltilme maliyeti yukarıdaki grafikte gösterilmiş durumda.

Sizi temin ederim, oturup yazılım spesifikasyonu yazmak ve bunları gözden geçirmek, örneğini verdiğimize benzer hatalardan kaybedeceğinizden çok daha az zamanınızı alacaktır.

Sizleri, yukarıdaki grafiği de aldığım hata önleme ile ilgili makale ile başbaşa bırakıp kahvemi içmeye dönüyorum.

İyi Testler!


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

Genç Girişimcilerle Beraber

Friday, November 9, 2007

Geçen hafta sonu, Genç Girişimcilerle beraber çok güzel saatler geçirdik.ggk_banner Bu beraberlik sırasında yaptığım sunuma PDF formatında buradan da link verelim.

Bu gibi aktivitelerin en güzel tarafı, verdiğimiz çabalarımızın fikir kıvılcımları olarak görünür hale gelmesi. Sektörümüzün gelişmesi için tek çaba sarfedebilecek olan, yine sektörümüz içindeki bizleriz. Bu yüzden bu tip toplantıları önemsiyorum.

Umarım GGK gelecekte daha da güçlenir ve gelişir. Ayrıca umarım GGK gibi daha birçok organizasyonu daha görme şansı elde ederiz.

Tüm emeklerinden dolayı GGK’daki arkadaşları tekrar kutlar ve teşekkür ederim.


Kategori: Genel | Yorum yapilmamis

ReadySet : Proje yöneticileri için dokümantasyon şablonları

Thursday, November 8, 2007

Tigris.org bünyesinde yürütülen ReadySet, proje yöneticileri için hazır bir dokümantasyon şablon seti. Birçoklarının yanında, yazılım testi ile ilgili de birkaç şablona yer vermişler. Her ne kadar önerilen dokümantasyonu tam bulmasam da, konfigürasyon matrisi ve test durumları taksonomileri gibi konularda örnekler vermesi açısından incelemeye değer buluyorum.

Projenin geliştiricileri, ReadySet’in amacını şöyle anlatıyorlar

ReadySET is an open source project to produce and maintain a library of reusable software engineering document templates. These templates provide a ready starting point for the documents used in software development projects. Using good templates can help developers work more quickly, but they also help to prompt discussion and avoid oversights.

210696_new_text_documentŞablonları kullanırken dikkat edilmesi gereken noktalar konusunda da iki çift laf etmek istiyorum. Şablonlar standardizasyonu sağlayıp, bazı noktaların atlanıp unutulmasını engellemenin yanında, düz biçimde uygulandıklarında da vakit kaybına yada tünel görüşüne sebep olabilirler.

Sadece şablonlarda var olduğu için eklenen bölümler dokümanların okunurluğunu azaltıp, okuyucunun (dokümantasyon okunsun diye yazıyoruz değil mi?) vaktini boşa harcamamıza sebep olacaktır. Ayrıca yazılım testi gibi esnek ve analitik düşünmeyi gerektiren çalışmalarda, yöntem dayatan dokümantasyon şablonları, yazılımın test ihtiyaçları ile ilgili önemli noktaları atlamanıza sebep olabilir.


Kategori: Genel | Yorum yapilmamis

Test Otomasyonu Aracınızı Anlamak

Thursday, November 8, 2007

Testlerimizi otomasyon altına alırken yaşadığımız sorunların çözümünde, bazen test otomasyon araçlarının özüne dönmemiz gerekmekte.

img_apodora

Durumu net biçimde görmek için Apodoro incelemenizi tavsiye edebileceğim bir araç. Apodoro henüz emekleme aşamasında bir test otomasyonu aracı. Geliştirme ekibi, kullanım kolaylığından ziyade beceriyi öne aldığı için, arabirim üzerinden uygulamayı çalışırken izleme ve iç yapısını keşfetme şansı elde ediyoruz.

Apodoro’yu çalışırken izlediğinizde –ki bunu yapmak için uygulamayı kurmanıza bile gerek yok, online demo işinizi görecektir – bir test otomasyonu aracının bir GUI nesnesini ne şekilde algıladığını ve bu bilgiyi içerisinde hangi şekilde tasnif ettiğini görebilirsiniz. Kulağınıza şunu da fısıldamak isterim: Devasa HP Mercury QuickTest Professional aracı da – onlarca nefis özellik ile süslenmiş olsa da- GUI nesnelerini aynı mantık ile tasnif etmektedir.

Tüm modern test otomasyonu araçları, GUI nesnelerini tanımlamak için Apodoro’ya benzer biçimde çalışırlar. İşte bazen bu sebeple GUI nesnelerine gerektiğinde aşağıdakine benzer eklentiler yaparız.

// Otomasyon alt yapımız bunun buton olduğunu biliyor ve
// dolayısıyla "Click" edebilir yada "Enabled" özelliği
// "Expected Results" içerisinde kullanabiliriz.
public String sWidgetType = "wgButton";

Yada

// Artık bu butonun hangi buton olduğunu biliyoruz
newAccButton.sWidgetID   = "Home.Accounts.NewAccount.Ok";

Kategori: Test Mühendisliği | Yorum yapilmamis

Genç girişimciler ile beraber

Saturday, October 27, 2007

BarCamp’in sıcacık ortamında Genç Girişimciler Klübü‘nden Sayın İbrahim Ulga ve Atakan Eser ile tanışma şansını yakaladım. 20 Ekim’deki güzel sohbetimizi, son bir haftadır büyük fedakarlıklar ile organize ettikleri bir etkinlik ile süslediler. Bir aksilik olmazsa, 4 Kasım Pazar günü saat 13:00′de 14:00′de, klübün Genç Girişimciler KlübüMaltepe’deki salonunda bir seminer veriyor olacağım.

Bu seminerde epistemoloji, antropoloji, psikoloji ve yazılım mühendisliği ile örülü bir pencereden yazılım ile ilgili fikirlerimizi tazeleyeceğiz. Eğer bugüne kadar yazılıma sadece teknik tarafından bakıyorsanız, Kalite mi teknikten, Teknik mi kaliteden? başlıklı bu seminer, sizler için de eğlenceli geçebilir.


Kategori: Genel | Yorum yapilmamis

Yazılım Geliştirme Kültürü ve Personel Sürekliliği Üzerine

Sunday, October 21, 2007

Arada sırada kitabevlerini gezerek ilgilendiğim alanlarda çıkan kitapları inceliyorum. Bugün de onlardan biriydi ve bilgisayarımı ve okuyacak bir iki şey de alıp kendimi dışarıya attım. Mola vermek ve bir iki fincan kahve içmek için oturduğum yerde The Culture Code isimli kitabı karıştırırken kafamda bir iki soru işareti oluştu.

The Culture Code’un yazarı Clotaire Rapaille, ABD kültürünü “ergenlik döneminde” olarak tanımlıyor kitabThe Culture Codeında. Böyle bir iddaa olduğu hali ile bırakılmaz diyerek de ABD yaşam tarzı ve hatta ABD dış ilişkilerindeki tavırlarını inceleyerek savını destekler bir dolu da örnek sunmuş.

Bunları okuduktan sonra, ister istemez yazılım ekiplerini de bu prensipler içerisinde değerlendirdim. Zorlandığımı da söyleyemem. Zira yazılım geliştiren ekiplerin seçtikleri yöntemler ile modern kültürlerin oluşması arasında çok ciddi benzerlikler mevcuttu.

Toplumları oluşturan bireylerin beraberinde getirdikleri kültürlerin başkalaşması ile yeni kültürlerin oluştuğunu görüyoruz. Aynen yazılım geliştirme ekipleri oluşturulurken, geliştirici ekip üyelerinin kendi deneyimleri ile beraber gelmesi ve ortaya çıkan sinerjinin oluşan ekibin yazılım ekibinin iş yapma biçimlerini belirlemesi gibi.

Ayrıca toplumların kültürleri de bir anda değişmezler. Aynen yazılım ekiplerinin iş yapma biçimlerini bir anda değiştirmemeleri gibi. Clotaire Rapaille kitabında kültürlerin değişmesi için birkaç jenerasyon geçmesi gerektiğini söylerken, benzer biçimde de yazılım ekiplerinin belirli bir konudaki uygulamalarını tam anlamıyla değiştirmeleri (değişikliğin benimsenmesi ve kültürün bir parçası olması kastediliyor) için birkaç projenin geçmesi gerektiğini görüyoruz.PeopleWare Kitap Kapağı

O halde yazılım geliştirme ekiplerinde, yazılım geliştirme kültürünün de, toplumlara benzer biçimde emekleme, yürüme ve konuşma evreleri geçirdiğini, biraz daha ileri gidersek bu kültürlerin “çocukluk”, ”ergenlik” ve “olgunluk” dönemlerini gördüğünü söyleyebilir miyiz?

Benim şahsen vardığım sonuçta, yazılım ekiplerinin olgunluğunun, hiçbir koşul altında ekip üyelerinin ekipteki ortalama bulunma süresini aşamayacağıdır.

Eğer yazılım geliştirme ekibinizde sürekli bir personel değişimi varsa ne olur? Yazılım geliştirme kültürünüz bundan nasıl etkilenir?

Bu noktada ise sizleri Tom DeMarco ve Timothy Lister’ın yazdıkları PeopleWare isimli kitabı ile başbaşa bırakıp, ben kendi kitabımı okumaya devam ediyorum.


Kategori: Genel, Yazılım Geliştirme Süreçleri | Yorum yapilmamis

Ne zaman uzman sayılırız?

Friday, October 19, 2007

Test mühendisliği sistematik şüpheciliktir demiştik. Görünen o ki ne yazarsak yazalım, hiç şüphe etmeden olduğu hali ile kabul görüyor. Biz ne dersek diyelim, insanlar kendilerine söylenenleri olduğu gibi kabullenme niyetindeler.

Burada yazmaya başladığımdan beri yüzlerce e-posta mesajı aldım. Bu mesajlar içerisinde çeşitli konular etrafında fikirlerim soruluyordu. Elimden geldiği kadarıyla bunlara yanıt vermeye çalıştım. Yazdıklarım hakkında beni tebrik eden birçok insan ile de tanıştım, lakin şimdiye kadar söylediklerim ile ilgili şüphe duyan kimseler çıkmadı.

Sıkıntım dilimin ucunda : Henüz kimse ile yazılım kalitesi konusunda tartışamıyoruz. Oysa kBarcamp Logoi bizi uzmanlaştıracak olan fikirlerimizi tartışmak, diğer insanların fikirlerini sorgulamak ve fikirlerimizin sorgulanmasıdır.

“Gelişimin” sadece tartışarak geleceğini düşündüğüm için 20 Ekim 2007 tarihinde BarCamp etkinliğinde, gelişim adına özgürce tartışan ve paylaşan insanlarla bir arada olacağım. Sanırım test mühendisliği camiamızın daha katetmesi gereken çok yol var.


Kategori: Test Mühendisliği | Yorum yapilmamis