Skip to content

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

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!

Genç Girişimcilerle Beraber

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.

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

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.

Test Otomasyonu Aracınızı Anlamak

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

Genç girişimciler ile beraber

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.

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

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.

Ne zaman uzman sayılırız?

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.

Test Dokümantasyonu

Test aktivitelerinin ne şekilde dokümante edilmeli? Yada test aktiviteleri gerçekten dokümante edilmesi gereken aktiviteler midir? Bu soruları çok sık duymakla beraber, bunlar ayrıca meslektaşlarımızın da uzun süredir tartıştiğı sorular.

Ben kendimi dokümantasyon konusunda gayet orta yolcu biri olarak düşünürüm. Faydalarına inanır ama imkansızlıkları da kabullenirim. Bu sebeple kendi yaklaşımımı burada kabaca masaya yatırmak istedim –ki tekrar bu soruyu duyduğumda, soruyu sorana gönderebileceğim bir permalink’im olsun.

Dokümantasyonun fonksiyonel katkilari tabii ki yadsınamaz. Bu sebeple mümkün olan her durumda test aktivitelerinin dokümante edilmesi gerektiğini düşünüyorum.

Özellikle hetorojen bilgi ve deneyime sahip bireylerden oluşan bir ekip ile çalismak durumundaysanız, dokümantasyon, ekibin tümünün büyük resmi görerek aynı hedefe daha net biçimde ilerlemesine yardımcı olacaktır. Ayni şekilde geliştirme ekibinin tümünün de aynı kalite bilincine sahip olması için dokümantasyon iyi bir araçtir.

Diger taraftan dokümante edilmis bir test planı, yazılım yasam döngüsü süresince, test ekipleri gibi yoldan çıkmaya müsait ekipleri dogru yolda tutabilir. Öngörülen riskler ve başlangıçtaki hedeflerimizi birinin gözümüze sokuyor olması, gereksiz test aktivitelerinin engellenmesi için “olmazsa olmaz” dır.

(DEVAM EDIYOR)

Yazılımlarınızı kullanmak fizik doktorası gerektiriyor mu?

Biraz önce yazılım ergonomisi ile ilgili küçücük bir detay aklıma takıldı ve bunu sizlerle paylaşmak istedim.

Okumakta olduğunuz sitenin yazılımının yeni versiyonu 10 gün önce duyurulmuştu. Her ne kadar daha önce bu güncellemeyi yapmayı düşünmüş te olsam, taşınma telaşı ile ancak bugün gerçekleştirebildim. İzlediğim adımlar gerçekten basitti ve sonuç ise sevindirici. Yükseltme sadece 3 dakikamı aldı. İşim bitip bu yazının başına oturmadan önce, sürüm yükseltmeyi bu kadar beklettiğim için de kendimden utandım doğrusu.

Yaptıklarımı anlatayım size

  1. Önce yedekleme betiklerimi çalıştırarak okumakta olduğunuz sitenin tüm kaynak kodunun ve veri tabanının yedeğini bilgisayarıma indirdim.
  2. WordPress 2.3′ü sitesinden indirdim ve eklentiler haricindeki tüm dosyaları SFTP ile yerlerine attım.
  3. Wordpress ile beraber gelen sürüm yükseltme betiğini çalıştırdım

Okuduğunuz site sadece 3 dakikalık bir down-time yaşayarak gıcır gıcır hale geldi.

Lakin bir iki ufak detay aklıma takılmadı değil:

(DEVAM EDIYOR)

Bazen savaşmak zorunda da kalabilirsiniz

Eğer bir hatanın ciddi olduğuna inanıyorsanız, bu hatanın düzeltilmesi için mücadele etmekten çekinmeyin. Bu, bir test mühendisinin yaptığı işe saygısı gereği takınması gereken bir tavırdır. Eğer bir hata düzeltilmeyecek ise, bunun geçerli bir sebebi sunulmalıdır.

Hata durum toplantılarında siz de buna benzer birşeyler duymuşsunuzdur eminim: “Evet bu bir yazılım hatası ama hiçbir kullanıcı bu hatayı tetikleyecek birşey yapmaz!” Yada kahve almaya gittiğinizde karşılaştığınız geliştiriciye, üzerinde çalıştığınız anomaliden söz ederseniz, omuzlarını kaldırıp kaşlarını çatarak “Ah, evet.. Ne olduğunu biliyorum.. Raporlayın bunu, aradan çıkarırız..” derler.

Lafı uzatmaya gerek yok. Geliştiriciler hataları önemsememe eğilimindedirler. Bunu biliyorum, zira bende bir zamanlar onlardan biriydim.

Evet mission critical olmayan her yazılım, bilinen hatalar ile sunulurlar. Ama her hata, yazılım ile birlikte sunulmak zorunda da değildir. Eğer bir hatanın ciddi olduğuna inanıyorsanız, bu hatanın düzeltilmesi için mücadele etmekten çekinmeyin.

Uğruna savaşılacak şeyleri dikkatle seçip, savaşmak gerektiğinde de kazanmak için savaşmak hiç de kötü bir alışkanlık değildir.