Skip to main content

World Quality Report 2013-2014 | Dunya Yazılım Kalitesi Raporu 2013-2014

Dünya genelindeki üretilen yazılımın ve yazılım süreçlerinin kalitesi belirlemek için Capgemini, Sogeti ve HP tarafından yapılan çalışma yayınlandı. Bu çalışma 2013 yılında yazılım kalitesiyle ilgili toplanan verilerin 2012 yılındaki çalışmada elde edilen verilerle kıyaslanarak bu alandaki değişimleri de bize aktarmaktadır. Ayrıca 2015 yılı için beklentiler hakkında bilgiler de vermektedir. Dünya genelinde yapılan bir araştırma olmasından olayı değerlendirme yaparken Türkiye'nin veya kendi firmamızın bu verilerin neresinde kaldığını görmemiz adına güzel bir kaynak olabilir.

Araştırmayı değerlendirmeye başlamadan önce herzaman olduğu gibi önce araştırmanın kimler tarafından yapıldığını, bu araştırmadaki amaçlarını ve bu araştırma sonucunun araştırmacılara sağlandığı yararları belirlemek gerekir. Bu sayede araştırmanın kendimiz veya kendi firmamız için ne anlama geldiğini daha iyi analiz edebiliriz. 

Capgenimi dünya genelinde 44 ülkede 130.000 çalışanıyla faliyet gösteren ve yıllık geliri 10.3 Milyar Avro olan bir danışmanlık firması. Beş küresel sektöre odaklanmıştır: telekom, parakende, üretim, finans servisleri, kamu sektörü. Küresel ölçeklerde değerlendirildiğide gerçektende büyük işler yapan bir danışmanlık firması. Yazılım firmanın bir faliyet alanı ve bu alanda araştırma konusuyla ilgili yazılım test danışmanlığı ve dış kaynak kullanımı sağlamaktadır. Çalışan sayısının büyüklüğü buradan kaynaklanmaktadır. Danışmanlık işlerinde IBM, HP, Oracle gibi bilindik firmaların ürünleri kullanmaktadır. Bu firmanın ürünlerinin fiyatları herkesin tahmin edeceği gibi epey bir yüksek, ayrıca danışmanlık işleri genelde iyi bir kadroyla ve deneyimle yürütülmesinden dolayı maliyetleri yüksek olmaktadır. Bu nedenler ise Capgenimi'nin gelirinin neden bu denli yüksek olduğunu açıklar niteliktedir diyebiliriz.

Sogeti, yine dünya genelinde faliyet gösteren bir test danışmanlık firmasıdır. Capgenimi ile kıyasladığında çok daha küçük ölçekte kalmaktadır. Dünya genelinde Amerika ve Avrupa'da gelişmiş 15 farkı ülkede faliyet gösteriyor ve yaklaşık 20.000 çalışanı bulunmaktadır. Uygulama yönetimi, IT altyapı yönetimi, yüksek mühendislik ürünleri ve yazılım testi alanları firmanın odaklandığı alanlardır. T-Mobile, Citybank, Mercedes, Alcatel gibi büyük firmalara danışmanlık hizmeti vermiştir.

HP, çoğu kimse tarafından yazıcı üreten firma olarak bilinmektedir. İşin esası ise 1940'larda Amerika'da iki elektrik mühendisi tarafından kurulan firma elektronik test araçları (sinyal üretici, voltmetre, frekans hesaplayıcı gibi) üretmiştir. Şuanda yazılım, donanım ve hizmet üreten bir firma haline gelmiştir. Konumuzu ilgilendiren yönleri ise HP'nin İsrail menşeili Mercury firmasının alarak yazılım zaten varolduğu test ürünleri dünyasında en öne çıkmasıyla ilgilidir. Yazılım test ürünleri denilince ilk akla gelen ürünler genelde HP tarafından üretilen ürünlerdir. Örneğin, QC (Quality Center) daha sonra ALM (Application Lifecycle Management) olarak değişimiş test yönetim aracıdır; QTP (Quick Test Professionel) test otomasyonunda kullanılan çok etkili bir test aracıdır; Load Runner performans testlerinde kullanılan bir test aracıdır. Diğer test araçları ve yazılımlar için buraya bakabilirsiniz.

Bu bilgilerden sonra analiz yapmak ister isek şu sonuçları çıkartabiliriz: Bu üç firmada küresel ölçekte iş yapan firmalar. Capgenimi ve Sogeti test danışmanlığı verir iken büyük ölçekte HP ürünleri kullanıyor olabilir. Bu iki danışmanlık firması rakip gibi görünse de ortak iş yapmaktadırlar, buradan bilgilere ulaşabilirsiniz. Bu anlamda bakıldığında her üç firmanın ortak bir iş ilişkisi bulunmaktadır. Bu iş ilişkişinin büyüklüğü ise yazılım test dünyasının büyümesi ile alakalıdır. Yani sektördeki yazılım firmalarının test yatırımlarının büyümesi bu firmaların odaklandığı noktadır. Burada garipsenecek bir şey olmadığı gibi ortada ürün kalitesini arttırmak ile ilgili bir tasa veya hedef olduğunda herkes bundan yarar sağlayacaktır. HP ürünleri pahalı olabilir, açık kaynak taraftarları için belki göz ardı edilebilir, fakat ürünlerin arkasında yatan bilgi ve deneyim birikimi mutlaka her firmanın yararlanabileceği bir kaynak durumundadır. Araştırmada çıkan sonuçları değerlendirirken bu nokta unutulmamalı ve araşmada kullanılan verilerin doğruluğu da sorgulanmalıdır.

Araştırmanın sonuçları 64 sayfalık uzunca sayılabilecek bir döküman şeklindedir. İsteyenler buradaki linke giderek kayıt olup dökümanı indirebilir. Sonuçları dikkate aldığımda benim gözümde öne çıkan bazı noktaları şu şekilde sıralayabilirim:
  • Dünyada yazılım kalitesi için ayrılan bütce 2012 yılında %18 iken 2013'te %23 olmuş. 2015 için beklenti ise %28 olması
    • Firmalar rapora göre %30 bütcesini kalite için harcamaktan yana fakat deneyimli yetişmiş insan, gerekli test araçları ve test süreçleri olmadan uzun vadede kar edilmeyeceği vurgulanıyor
    • Yeni işlere harcanan emek toplam iş yükü içerisinde %41'dan %46'ya artmış yani varolan işlerde regresyon testlerine harcanan süre azalmış. Yine rapora göre bu rakam 2015 yılında yarıyarıya düşüş gözleneceği yönünde. 
    • Kalite grubu harçamalarını büyük çoğunluğu halen altyapı harcamalarına yönelikmiş. Yani test araçları, test ortamları gibi harcamalar aslında öncelikli yapılan harcamalardır ve kuruluş aşaması devam ettiğinin göstergesidir.

  • Test aktivitelerinin bir grup çatısı altında, tüm proje ve şirket geneline servis edecek şekilde değiştirilmesi yönünde yani bir QA grubu oluşturulması eğilimi gözlemlenmiş. 
    • 2012 yılında %8 üst düzey yönetici (Direktör ve CIO), 2013 yılında ise %26'lık bir kesim QA fonksiyonun şirket genelin hizmet ettiğini söylemiş.
    • 2012 yılında en cok arzu edilen test uzmanın sahip olması gereken fonksiyonları: test yönetimi, metrik, raporlama iken; 2013 yılında ise iş alanında (business domain) bilgisi ve deneyimi olan test uzmanları olmuş.
      • Üstteki maddeden şunu çıkarabiliriz: test altyapısı kurulduktan ve yönetimide sağlandıktan sonra işin özüne inilebildi. Yani gerçek anlamda test yapabilmek için teknik bilgi ve becerilerin olması gerekiyor bunun yanında domain bilgisi ise olmazsa olmazdır. Detaylı yorumlarım için bu yazımı okuyabilirsiniz.
   

Bu çalışma Nisan-Mayıs 2013 aralığında yaklaşık 1500 telefon ile anket yapılarak veriler toplanmış. 25 farklı ülkeden büyük ölçekli firmalardan orta ve küçük ölçekli firmalara kadar geniş bir şirket araştırması yapılmış ve sorular bu firmaların üst düzey yöneticilerine sorulmuş. Detaylar için buradan dökümanı indirebilirsiniz.

Geçen yıl için yapılan çalışmayla ilgili bilgiler için bu yazımı okuyabilirsiniz. 



Popular posts for software testing and automation

Selenium Error "Element is not currently interactable and may not be manipulated"

Selenium webdriver can drive different browsers like as Firefox, Chrome or Internet Explorer. These browsers actually cover the majority of internet users, so testing these browsers possibly covers the 90% of the internet users. However, there is no guaranty that the same automation scripts can work without a failure on these three browsers. For this reason, automation code should be error-prone for the browsers you want to cover. The following error is caught when the test script run for Chrome and Internet Explorer, but surprisingly there is no error for the Firefox. Selenium gives an error like below: Traceback (most recent call last):   File "D:\workspace\sample_project\sample_run.py", line 10, in <module>     m.login()   File "D:\workspace\ sample_project \test_case_imps.py", line 335, in login     driver.find_element_by_id("id_username").clear()   File "C:\Python27\lib\site-packages\selenium-2.35.0-py2.7.egg\selenium\webdriver\r

Change Default Timeout and Wait Time of Capybara

One of the biggest challenge for automation is handling timeout problem. Most of the time, timeout is 60 seconds but it may sometimes not enough if you have badly designed asynchronous calls or the third party ajax calls. This makes handling timeout more complex. set large enough to tolerate network related problems. For Selenium based automation frameworks, like Capybara, default Webdriver timeout is set to Net::ReadTimeout (Net::ReadTimeout) Changing ReadTimeout If you have timeout problem for Capybara, it gives an error like above. This means that the page is not fully loaded in given timeout period. Even you can see that page is loaded correctly but webdriver wait until the Ajax calls finish. class BufferedIO #:nodoc: internal use only def initialize (io) @io = io @read_timeout = 60 @continue_timeout = nil @debug_output = nil @rbuf = '' end . . . . . def rbuf_fill beg

Create an Alias for Interactive Console Work: Selenium and Capybara

If you are working on shell most of the time Aliases are very helpfull and time saving. For testing purposes you can use Alias for getting ready your test suites. In this post, I want to explain both running Selenium and Capybara on console and creating aliases for each.  This post is for Windows machines, if you are using Unix-like see   this post . Creating Scripts for Selenium and Capybara First of all, it is assumed that you have installed Selenium and Capybara correctly and they work on your machines. If you haven't installed, you can see my previous posts. I am using the Selenium with Python and the Capybara with Ruby. You can use several different language for Selenium but Capybara works only with Ruby.  Create scripts in a directory called scripts (in your home folder, like as  ~/scripts ) for your automation tool as following, save them as capybara.rb, sel.py :  Creating Aliases Depends on your favourite shell, you need to add the alias to .bashrc bash

Page-Object Pattern for Selenium Test Automation with Python

Page-object model is a pattern that you can apply it to develop efficient automation framework. With the page-model, it is possible to minimize maintenance cost. Basically page-object means that your every page is inherited from a base class which includes basic functionalities for every page. If you have some new functionalities that every page should have, you can simple add it to the base class. Base class is like the following: In this part we are creating pages which are inherited from base page. Every page has its own functionalities written as python functions. Some functions return to a new page, it means that these functions leave the current page and produce a new page. You should write as much as functions you need in the assertion part because this is the only part you can use the webdriver functions to interact with web pages . This part can be evaluate as providing data to assertion part.   The last part is related to asserting your test cases against to the

Performance Testing on CI: Locust is running on Jenkins

For a successful Continuous Integration pipeline, there should be jobs for testing the performance of the application. It is necessary if the application is still performing well. Generally performance testing is thought as kinds of activities performed one step before going to live. In general approach it is true but don't forget to test your application's performance as soon as there is an testable software, such as an api end point, functions, and etc. For CI it is a good approach to testing performance after functional testing and just before the deployment of next stage. In this post, I want to share some info about Jenkins and Locust. In my previous post you can find some information about Locust and Jenkins. Jenkins operates the CI environment and Locust is a tool for performance testing. To run the Locust on Jenkins you need command line arguments which control the number of clients ,   hatch rate,  running locust without web interface and there should be so