1

“Daha Çok Test = Daha Çok Kalite” midir?

Posted by mgocean on September 2, 2012 in Bilgi Teknolojileri, ITIL, Yönetim |

Yazılım firmaları için artık çok tekil ve karmaşık çözümler bulmak ve üretmek gittikçe zorlaşmakta. 5 sene önce hayal edemediğimiz yazılımları artık günümüzde neredeyse lisans ücreti ödemeden bulabiliyoruz. Geçtiğimiz senelerde genelde savunma sanayi ve finans sektöründeki yazılımlar daha çok fonksiyonalite odaklı iken artık kalite, ERP, CRM, BPM ve hatta en basit oyun yazılımları için öne çıkaran bir unsurdur.

Peki kaliteli yazılım üretmek için neler yapmak gerekir? Projeler, “Kalite”, “Maliyet”, “Zaman” kenarlarından oluşan bir üçgenle ifade edilir ve üçgenin alanının da projenin kapsamını belirler. Bu üçgenin “Kalite” kenarını arttırmanız durumunda “Zaman” ve / veya “Maliyet” faktörlerinden birini de arttırmanız gerekir. Tabii bu işin sadece geometri kısmı.

Pratik hayatta projenin maliyetinin üzerine biraz da bir paydaşa para vererek (maliyeti yanlış yönde arttırarak) daha kaliteli bir yazılım üretme şansınız yoktur. Her eforun bir kısmını kalite için harcanacak kaynağı da verimli kullanmak gerekir. Kaliteyi sağlamanın ilk yöntemi teste daha çok zaman ayırmak ve hatta birçok testi otomatize etmekten geçmekte gibi görünmekte. Fakat test, kalite sürecinin sadece bir adımıdır. Maalesef kaliteli ürün üretmek ve süreklilik kazanmak bu kadar kolay ve kısa vadeli çözümlerle kazanılmamakta. Hayat bu kadar kolay olsaydı birçok firma test kaynaklarını arttırarak dünya çapında çok prestijli bir kalite olgunluk seviyesi olan CMMI 5 ve benzeri seviyelerde sertifike edilirdi. Fakat pratik hayatta kullandığımız bir çok yazılım ürününden de anlayabileceğimiz gibi kaliteli ürün üretmek bu kadar kolay değil.
En yaygın uygulamalarda, Office yazılımlarında, İşletim Sistemlerinde, Nasa’nın Mars’a gönderdiği araçlarda, Savaş uçaklarında, Intel İşlemcilerinde bulunan meşhur bölme işlemi ile ilgili bug’lar uluslararası hatta gezegenler arası sorun çıkartan en popüler yazılım hataları arasında sayılabilir. “Tarihin En Büyük Yazılım Hataları” yazısında bu sorunlarla ilgili daha detaylı bilgiye erişebilirsiniz.

Aynı zamanda teste harcanacak kaynağın artması üretim aşamasındaki önlenebilen aksaklıkları üretim aşamasında tespit ederek düzeltmeme tembelliğini beraberinde getirir ki bu maliyetleri zaman içerisinde eksponansiyel olarak arttıracaktır. Yani yazılım aşamasında yapılacak çalışmanın daha özensiz yapılmasına sebebiyet verecektir. Örneğin yazılım ekibinizde çok da kaliteli iş çıkartmayan ama gelişmeye açık junior yazılımcılarınızın yanısıra çok tecrübeli ve kaliteli iş çıkaran yazılımcılarınız var. Junior yazılımcıları, dokümantasyon ve iç eğitimlerle eğitmek yerine bu yazılımcıların yaptıkları hataları daha çok test kaynağı harcayarak düzelttirmek sadece günü ve mevcut projeyi kurtarır. Oluşturulacak kurumsal hafıza ve bigi paylaşımı ile kısa zamanda çok daha düşük maliyetle daha kaliteli ürünler üretilebilinir.

Şekilde de görülebileceği gibi ekmeği kızarttıktan sonra kontrol edip kızarmış kısımları kazımaktan (Test Süreci) ziyade daha önce kızartılan ekmeklerden edinilen tecrübe ile ekmeği yakmadan ne kadar sürede kızartılması gerektiğini bilmek (kurumsal hafıza, eğitimler, dokümantasyon vs.) hem üretim zamanını azaltır, hem de ürün maliyeti azaltır. İşte bu nedenle kaliteyi sadece test olarak algılayan ve kalite adına sadece teste odaklanıp teste yatırıp firmalar, yanmış ekmekleri temizlemekle zaman kaybederler.

Kalite aslında bir yazılıma değil şirkete atfedilmesi gereken bir özelliktir. Akabinde şirketin kalitesi zaten ürünlerine yansıyacaktır. Kaliteli ürün üretmeye aday bir firma öncelikle süreçlerini tanımlamalı ve tanımladığı süreçlere ne kadar uygun hareket ettiğini her an sorgulamalı. Örnek vermek gerekirse; Analiz sonucunda çıkan dokümantasyonun, yazılımı geliştirecek ekip tarafından çok net bir şekilde anlaşıldığından emin olmak, anlaşılmaması durumunda analiz adımından yazılım adımına geçilmemesinin sağlanması bu konu için tipik bir örnektir. Her adım geçişlerinde üretilmesi gereken dokümantasyon, organize edilmesi gereken toplantılar, alınması gereken onaylar vs. çok net tanımlanmalı ve bağımsız bir kalite ekibi tarafından denetlenmeli. Bu ekibin işi gerçekten çok zordur. Kalite ekiplerinin hızlı balığın yavaş balığı yediği ortamda şirketin üretim hızının önünde bir hız tümseği gibi algılanma olasılığı çok yüksektir. İşte bu nedenle bu ekipler şirket organizasyonu içerisinde herhangi bir üretim ekibinin yönetimine bağlanmadan üst yönetim ile direkt hiyerarşik bir bağ ile bağlanmalı ve gücünü kalitenin orta ve uzun vadedeki faydalarına inanan bir üst yönetimden almalıdır. Sonuçta bu ekibin elinde olup olabilecek tek güç, üst yönetimden alacağı güç olacaktır.

Yazının başlığındaki sorunun cevabını vermek gerekirse, Test Faaliyetleri, ürün kalitesi için çok önemli bir adımdır fakat kaliteyi sağlamak için tek unsur değildir. Daha çok test kaliteyi sadece belirli bir seviyeye kadar arttırır. Kalitenin sürekliliğini sağlamak ve kaliteyi şirketin güçlü bir bileşeni yapmak için çok daha geniş kapsamlı bir bakış açısı ve çalışmaya gerek duyulmaktadır.

Tags: , , , , , ,

1 Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyright © 2006-2017 Güzel Blog All rights reserved.
This site is using the Desk Mess Mirrored theme, v2.0.3, from BuyNowShop.com.