2.3.2016
5.00 / 1 oy

Yazılımlar Neden Hep Geç Kalır?

Yazılım Hazırlamayı Geciktiren Unsurlar Nelerdir?

Kodlaması tamamlanıp teste verilen bir yazılımın testlerinin belirlenen sürede bitmesi beklenir. Ancak bazen test ekibinden beklenen raporlar bir türlü alınamaz. Test ortamına aktarılan kodun kalitesinin yeterli olduğunu varsayalım ve bu gecikmenin nedenlerinin yazılımcılardan kaynaklanmayan kısmı ile ilgilenelim. Bu şartlarda top testçilerdedir. Testçilerden kaynaklanan gecikmelerin nedenini iki maddede toparlayabiliriz:

testçinin testlere haşlamada gecikmesi: Kodlaması bitmiş bir versiyon için ilk beklenti, bu versiyonun bir an önce tümleştir-me testlerinin yapılarak ana hatlarıyla yazılım parçalarının birbiriyle uyumlu çalışıp çalışmadığına bakılarak geliştiricilere bir dönüş yapılması, varsa yazılımı bloke eden hataların da kayıt altına alınıp geliştiricilere iletilerek acilen bunların çözümünün takip edilmesidir. Eğer tümleştirmeye ayrılan sürede testçiler hemen testlerine başlamaz ve durumu raporlamaz ise geliştiriciler kendilerine iletilen bir hata olmadığından testlerin yolunda gittiğini düşünürler. Gecikmeli olarak başlayan tümleştirme testleri sonucu da haliyle gecikmeli olarak geliştiricilere iletildiğinden çıkan hataların çözümü de gecikir. Yazılımcı, kendine geç iletilen önemli bir hatayı gördüğünde "Bunu şimdi mi fark ettiniz" diyerek testçilere hesap sorar ve sonuçta bir gerginlik oluşur. Özellikle tümleştirme testlerinin geciktirilmesi böyle birkaç kez tekrarlandığında geliştiriciler test ekibinin işinin düzgün yapmadığını düşünür ve testçilerle geliştiriciler arasında sorunlar başlar. Böyle bir sıkıntıya neden olmamak için testçilerin teste başlama zamanına riayet etmeleri gerekir. Özellikle büyük hataların tespitinde bu çok önemlidir.

Yazılım Testinin Gecikmesi

Testçinin ayarlara dikkat etmemesi: Teste verilen her yazılım kurulurken bir takım ayarlar yapılır. Bu ayarlar bir dokümanda adım adım listelenmiş olmalıdır. (Örneğin bir dosyadaki bir parametrenin değerinin değiştirilmesi) Testçiler her versiyon çıktığında yazılımı test ortamına kurduklarından artık kurulum aşaması adımlarını ezberlerler ve ayarları ezbere yapmaya başlarlar. Bu böyle sürüp giderken bir versiyonda kurulum sırasında ezberden yaptığı ayarlardan birini unutup atlar. Testçi bunun farkında olmaz. Yazılımda yeni hatalar çıkmaya başlar. Bunlar test yönetim aracı ile kayıt altına alınarak yazılımcılara bildirilir. Yazılımcı ilk kontrolünde bu hataların nedeninin ayarların eksikliğinden kaynaklandığını bulamaz ve hataya sebep olan kod parçasını aramakla zaman kaybeder. Hatta testçiye çıkışıp "Ama benim makinemde çalışıyor" diyerek testçinin bu yazılımı tekrar tekrar kurmasını ister. Sorun yine çözülemez ve geliştirici test laboratuarına gelerek sorunu yerinde inceler. Burada da bir müddet zaman kaybettikten sonra hatanın gerçekte bazı ayarların yapılmamış olmasından kaynaklandığını tespit eder. Bunu fark ettiği anda bu ayarlara dikkat etmeyen testçiye kızar. Testçinin işini titizlikle yapmadığını düşünür. Bu tür gerginliklere ve zaman kaybına neden olmamak için testçiler kurulum ayarlarına dikkat etmeli, kurulum dokümanının adımlarına birebir uyguladıklarını teyit etmelidirler. Kısacası testçiler de titiz çalışmalıdırlar.

Şimdi de testi yavaşlatan ama testçilerden kaynaklanmayan iki neden verelim:

Ayarların Dağınık Olması: Bazı projelerde projenin başında iken düzenli çalışma konusunda kararlar alınmamışsa, örneğin ayarların tutulacağı dosyaların formatının nasıl olacağı, hangi dizinlerde tutulacağı belirlenmemişse her geliştirici kendinin ihtiyaç duyduğu ayarlar ile ilgili olarak farklı yerlerde farklı dosyalar tutar. Örneğin bir yazılımcı "A/B/C..." dizininde "ayarlar.properties" dosyasına ihtiyaç duyduğu parametreleri kaydeder ve kurulum sırasında bazı satırlardaki bazı parametreleri kurulum ortamı nedeniyle testçinin değiştirmesi gerekir. Başka bir yazılımcı da örneğin "F/G..." dizini altında "ayarlanm.txt" dosyası oluşturur ve kodunun kullandığı parametreleri buraya kaydeder. Testçinin de bulup değiştirmesi gereken ayarlar böylece farklı yerlerde farklı dosyalarda olur. Özellikle teste hazırlanılırken kurulum aşamasında testçinin elinde bu ayarları anlatan bir doküman olsa bile ortaya bu düzensizlikten kaynaklanan kurulum zorluğu, zaman kaybı çıkacaktır. örneğin bir yerde bir şeyin çalışmadığı fark edilince bunun nereden kaynaklandığını bulmak için testçinin ayarları kontrol etmesi gerekecektir. Ayarlar farklı dosyalarda tutulduğu için kontrol etmesi ve hatalı yerin tespit edilmesi zaman alacaktır. Bu nedenle yazılımcılar da işin başında kodlama standartlarını belirlerken bu tür dosyaların düzenini de hesaba katmalıdırlar. Mümkünse tek bir dosyada ayarları bulundurmalıdırlar. Projenin yapısı gereği tek dosya olmasa bile belli bir formatta en az sayıda dosyada tutulmalıdır. Bunlar her ne kadar yazılım tarafını ilgilendiren bir konu gibi görünse de etkileri doğrudan testçilere yansımaktadır. Sonuçta çalışmalara standartların konulması tüm tarafların yararına olacaktır.

Projenin karmaşıklığı: Projenin özellikle bağımlılık topolojisinin büyüklüğü teste yük getirir. Bağımlılık topolojisinden kastımız, yazılım sisteminde yer alan uygulamaların ağ yapısı olarak birbirine bağlılığıdır. Mesela bir A uygulaması bir sunucudan hizmet alıyordur ve bu sunucu da A'ya hizmet verebilmek için başka bir sunucudan hizmet alıyordur. Bu ağ bağlantısı gerektiren bağımlılıklar ne kadar fazla ise testi yavaşlatacak etkenler de fazla olacak demektir. Çünkü örneğin sunuculardan birinde bir sorun olması ona bağlı olan diğer yazılım parçalarının çalışamaması anlamına gelir. Bu tarz sorunlar giderilene kadar bazı testler bekletilir. Bu da zaman kaybına yol açar.

Yazılımlar Neden Hep Geç Kalır?
Bu makalenin telif hakkı ve tüm sorumlulukları yazara ait olup, şikayetler için lütfen bizimle iletişime geçiniz.
URL:
Etiketler:

Bu makale 626 kez okundu

2.3.2016 tarihinde yazıldı
Reitix

Yorumlar

  • alakran
    alakran
    26.9.2017

    parayı verdikten sonraki garanti ve destek sürecini de unutmamak lazım. en ufak bir ihtiyacınızda dahi ulaşmanıza imkan yoktur bu insanlara. ulaşsan bile ne kadar kolay bir şey istersen iste 3 günde yaptığı işin güncellemesi için 30 gün isterler

  • alagirl
    alagirl
    26.9.2017

    yazılımcının hiç kabahati yok zaten :) abi/abla 6 günlük işi var bunun derken güzel de o 6. gün geldiğinde neden telefon hep kapalı olur? ödeme zamanı geldiğinde ise sanki hiçbirşey olmamış gibi pişkin tavırlar sergilenebilmesi mesleki bir meziyet midir?

Bu yazıya siz de yorum yapabilirsiniz