evcil.net noktanın egemenliği

Team System Web Access Buluşması

Geçtiğimiz bir gün, Microsoft TFS'in Kuzey Carolina ekibinin ufak çaplı bir video konferansına katıldık. En sağdaki Hakan Eskici.

Hakan Bey'i tanırsınız belki, 2enetworkx zamanlarından. Pek güzel ASP uygulamalarıyla dünyada adından söz ettiren bir Türk'tü. Arkadaşıyla kurduğu ufak yazılım şirketi (bir İzmir Şirketi) DevBiz de bulduğu niş sahada yine dünyanın dikkatini üzerine çekmiş ve en nihayetinde Microsoft tarafından iç edilmişti.

Ekip, Microsoft'un yeni nesil proje yönetim ürünü Team Foundation Server'a web üzerinden erişim için bir ASP.NET uygulaması geliştirerek meşhur oldu. Şimdi bu uygulama Microsoft bünyesine katılıp Team System Web Access adıyla kullanıma sunuluyor.

Video konferans, daha çok bu ürünle ilgili tanıtıma adanmıştı. Israrla gelmesini istediğimiz soru-cevap kısmında ise, cevapların Web Access ile sınırlı olduğunu görmek TFS ile ilgili beklentileri ve talepleri olan geliştiriciler için biraz can sıkıcı oldu.

Web Access ile ilgili bizim söyleyeceklerimiz şunlar:

TFS'in kaynak kod kontrolü dışındaki mekanizmalarını (özellikle Work Item denen şeyler) kullanıyorsanız Web Access, bunlara web'den eriştiriyor ve hayatı biraz daha kolaylaştırıyor. (Bu zaten web'in erişim kolaylığından kaynaklanıyor, mucizevi bir haber değil.)

Yalnız, gülümseyerek kayda giren bir nokta var ki o da ekibin Web Access'i anlatırken, sanki son kullanıcıya internet'i anlatıyor gibi bir edaya bürünmesiydi. Diyelim ki ofisteki bilgisayarınızda değilsiniz. Laptop'unuzla bilmem ne...

Evden, ofisten, tatilden de kullanabileceğimiz bir şeymiş bu Web Access. Bu güzel ürün için tebrik ederiz.

Yazılım Test Mühendisi Hata Yapar mı?

Yazılım testi için ayrı test ekipleri olmayan firmalarda genel bir saplantı vardır. Bir gün, gerçekten bu iş için oluşturulmuş 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, fakat küçük bir detayı da eklemeden duramazlar.

Yazılım testi konusunda çalışan o işe has bir ekibinizin olması, her zaman geliştirdiğiniz uygulamaların daha kaliteli olacağı anlamına gelmez. Çünkü yazılım kalitesini test mühendisleri değil, tüm ekip beraber sağlar.

Test mühendisleri bir ürünü test eder ve hataları raporlar. Raporlanan hataların bir kısmı gerçekten ürün üzerinde düzeltilir ama bir kısmı düzeltilmez yada düzeltilemez. Yazılım kalitesini sadece geliştirici arkadaşlara hata raporlayarak, maalesef elde edemeyiz. Yazılımın kalitesinden şunu anlarız;

1. En baş şart olan müşteriş istekleri
2. O yazılımı geliştirme işine bir şekilde katılmış herkesin sorumlu olması

Test mühendisleri, ürün ile ilgili sürekli, anlaşılır ve kantitatif bilgiler üreten bir ekiptir. Bu sayede yazılımcılar geliştirdikleri ürüne ait hataları minimum hata ile öğrenirler ve düzeltirler. Yönetim tarafına gelince, sürekli olarak ürünün ne kadar hazır olduğu ile ilgili bilgiler edinirler.

Test ekibinin yaptığı hataların ürün kalitesine doğrudan yansıyacağı yadsınamaz bir gerçektir. Atlanan bir test case ya da unutulan bir konfigürasyon, sakıncalı anormallikler barındıran bir ürünün müşterilere gitmesine sebep olabilir.

Test Mühendisleri Her Zaman Hatasız Değildir

Fakat bu durum, yazılımcıların kodlarında hatalar olması, yapılan tasarımın eksik olması ya da ürün dokümantasyonundaki genel hatalar kadar normal bir durumdur. Tabi ki bizler test mühendisi olarak durumun bu tarafının farkında olsak da denetimde son kademe olduğumuzdan dolayı, takım içerisindeki herkesten daha sistematik çalışmak zorundalığını hissetmekteyiz.

Test mühendisleri, bir ürün geliştirilirken sistematik gözlem ve deneylerle, ürün ile ilgili şeffaf, objektif ve doğru amaca hizmet eden bilgileri üretir ve tüm ekip ile paylaşırlar. Bu oldukça zorlu bir iştir ve birden fazla disiplinde yaklaşıma ve deneyime sahip olunmasını gerektirir.

Bu bilgi ve deneyimleri sağlayan kişiler, üretilen ürünün kalitesinden sorumlu tutulamaz. Fakat ekibin ürettiği bilgiler olmadan da, geliştirilen yazılımın kalitesinin pek de yüksek seviyelerde olmayacağı unutulmamalıdır.

Test Araçları – 1

Quality Assurance (QA) aktiviteleri üç önemli bileşenden oluşur.

• Yeterli kalifikasyona ulaşmış insan kaynağı
• Doğru Metodoloji
• Uygun Test Araçları

Test teknik yoğun bir aktivitedir. Gerek test aktivitelerinin planlanması gerekse de uygulanması için farklı bir bakış açısına sahip insan kaynakları gerekmektedir. Bunları göz önüne alarak test otomasyonu satan firmaları ile ilgili kısa bir analiz yapabilir ayrıca test araçlarının bir can simidi olup olmadıklarına karar verebiliriz.

Günümüzde test otomasyonu araçları satan firmalar, araçlarını neredeyse kendi kendine test eden robotlar 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 işaret etmektedir. 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ırmaktan bir an olsun bile çekinmemektirler.

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 çok ama çok pahalıya mal olmaktadır. Bu firmaların büyük çoğunluğu şimdi, per-seat lisansına onbinlerce dolar ödedikleri ürünler ile otomatik bir kaosa sahiplerdir.

Çoğu test mühendisi, tam olmayan gereksinimler ile geliştirilen ürünlerde, kimi testleri gerçeklemeyi reddediyor ya da 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, yarı yolda kaldığını görüyoruz ki bu büyük bir sorundur.

Ekipler belki iyi niyetle bu pratikleri alıp uygulama kararı veriyorlar fakat kısa sürede başladıkları noktadan daha da geri 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.

Bir firma ya da ekip için en iyi yazılım testi, ihtiyaca uygun olarak planlanmış yazılım testidir. Metodolojiniz yoksa şablonlar arasında kaybolup gitmek kaçınılmaz olacaktır.

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.

FxCop – Code Analysis Çarpışması

Microsoft'un verdiği iki adet statik kod analiz aracı bulunuyor. Birisi, daha önceden kendi içinde (internal) kullandığını beyan ettiği FxCop. Diğeri de Visual Studio'ya çakılı gelen Code Analysis.

Analiz işine yeni başlayan geliştirici, durduk yere nur topu gibi bir ikilemin içine düşüyor: hangisini kullanmalıyım? İşin duayenlerine sormak istiyor, destek almak istiyor. İnterneti eviriyor, çeviriyor.

Görüyor ki bunun cevabını Microsoft bile vermiyor. Tamamen senin tercihin diyor. Ya da evet, VS 2008'i bekle: çok enteresan şeyler geliyor.

FxCop'ın Code Analysis ile en büyük farkı, onun IDE'den bağımsız çalışan (stand-alone) bir araç olması. Code Analysis, FxCop temelinin IDE'ye entegre edilerek geliştirilmesi demek oluyor. Ama bu şu demek değil sevgili okur: FxCop = Code Analysis.

Code Analysis, FxCop'ın bilmem kaç versiyonundan başladı ama şimdi aynı değiller. İkisi farklı koldan gelişiyor ve ilerliyor. Microsoft bir analiz kuralını FxCop'a yazmış, Code Analysis'e yazmamış olabilir. Yapar mı yapar, kendi söylüyor efendim, benim iddiam değil.

Öte yandan, Code Analysis sadece "Maintainability" ve "Reliability" kurallarını içeriyor. FxCop bunun üzerine "Spelling" kurallarını da içerdiği için daha detaylı analiz yapıyor. Ama Microsoft, Orcas'ta FxCop'ı tamamen kapsadığını ifade ediyor. Güveniyoruz kendisine.

Bir diğer gerçek de şu ki, FxCop her zaman olacak ve öylece bağımsız bir uygulama olarak duracak. Lâkin Code Analysis'in IDE ile, Team Foundation Server ile ilişkileri gitgide gelişecek, kabiliyetleri artacak (misal, Code Metrics). VS ve TFS kullanan ekiplerin olmazsa olmazı hâline gelecek. Varacağımız yer, Code Analysis. Bunu görmek zor değil.