Yazılım Projelerinde Test Otomasyon

5 min readSep 30, 2019

Her proje için yüksek kalitede yazılım çıktıları üretmek, gerçekleştirilmesi en zor hedeflerin başında gelmektedir.

Bu makale floodun da outsource ve insource olarak çalıştığım zaman zarfında tecrübe edindiğim test otomasyon süreçlerini sizlere aktarmaya çalışacağım.

Yazılım kalitesi her kurum ve her projenin başına dert olabilecek bir kapasiteye sahiptir. Yazılım kaynaklı sorunlar, yazılım endüstrisi için önemi her geçen gün artmaya devam eden, çözülmesi zor, karmaşık ve çok boyutlu bir problem alanı olmaya devam etmektedir.

Öyle ki en çok gözlemlediğim bulgular; performans sorunları, uygulama yetersizliği, alt yapı eksiklikleri, kaynak yetersizlikleri, kodlama hatası, güvenlik bulguları şeklinde söyleyebilirim.

Eğer bir yazılım ürünü sahibiyseniz ve bu hataları gözlemliyorsanız müşteri kaybına, itibar kaybına uğramanız an meselesidir. Yazılım tabanlı ürün ve servislerdeki hatalar firmaların itibarları, finansal performansları ve müşterilerinin bağlılığı üzerinde doğrudan etkiye sahiptir. Bazı yazılım hataları operasyonel performans, ölçeklenebilirlik, yanlış analiz ve kodlama sorunlarından da kaynaklanabilir. Düşük kalite aynı zamanda çalışan motivasyonu, ekip üretkenliği ve pazara çıkış hızı üstünde de çok önemli olumsuz etkiler yaratmaktadır. Test otomasyon süreçlerinde olmayan projelerde çalışanlar artık kendilerini geliştirebilmek için test otomasyon, dinamik süreçler, test analizi, KDD, BDD gibi kendilerine artı değerler katacak iş/pozisyon arıyorlar.

Test otomasyon, bahsi geçen tüm bulguların adreslemesinde kullanılan çözümlerden biridir ve günümüzde en çok tercih edilenidir.

Güncel test yaklaşımları arasında Fonksiyonel testler, Otomasyon testleri, Yük/Performans testleri ve Güvenlik testleri en çok bahsi geçenler arasında olmasına karşın hala avrupa da gördüğü saygınlığı ülkemizde görememiştir.

Araştırma raporlarına göre Türkiye’de firmaların test süreçlerine harcadığı zaman ve bütçe, toplam proje maliyetlerinin %7’sine karşılık geliyor. Dünya ortalamasının çok altında olan bu yaklaşımın sonucu olarak, test süreçlerine proje içinde gerektiği kadar önem verilmediği veya zaman ayrılmadığı için uygulamalarda “kalite problemleri ile sıklıkla karşılaşılmaktadır “ sonucu ortaya çıkıyor.

*ikiside dört ayaklı :) Herkes 4 nala koşarken biz hala 4 nalın olması yeterli sanıyoruz.*

Bir yandan ise test süreçlerini tamamen manuel olarak gerçekleştirmenin süre, maliyet ve en önemlisi çalışanlar açısından olumsuz etkileri olduğu ise bilinen bir gerçektir. İşte tam olarak test otomasyon araç ve yöntemleri bu aşamada devreye girerler. Doğru ve yerinde kullanıldığında test otomasyonu, test maliyetlerini ciddi oranlarda düşürecektir ve sürekli tekrarlanan testlere ayrılan zamanı kısaltacaktır.

Yazılanlara örnek verecek olursak, outsource çalıştığım sırada bir müşteride gerçekleştirdiğimiz 1,5 yıllık çalışmanın bazı sonuçlarını sizlerle paylaşıyorum.
(kurumdan gerekli izin alınmıştır)

Yukarıda da görüldüğü üzere Bug sayısı 346 > 52 — Kaynak yetersizliği tespiti ile 111 > 42 — Kod hatası 342 > 20 — Performans Sorunları 105 > 32 ortalamalarına kadar geliştirmeler ve tespitler ile gerçeklemesi yapılmıştır.

Başarılar

Yazılan testlerin Jenkins pipeline’a eklenerek ve her release sonrasında otomatik koşum yapılarak ilgili kişilere Assignee edilmiştir.
Sonar Qube üzerinde kod kalite takibi yapıldı. Yazılan standartlar ile müşterinin takip edeceği bir KPI oluşturuldu.
UFT üzerinde koşulan otomasyon senaryoları sayesinde bulunan bulgular etkilenme süresi yaşanmadan geliştiricilere raporlandı.

Kurum içerisinde test otomasyon kültürü ekipler bazında kabul edildi.
Müşteri, tüm sürecin hesaplamasını yaptı ve uzun vadede eforlarını azaltacagını fark etti.

Bu 1,5 yıllık maratonda oluşturulan katma değer ve finanslar kazanımlar gün geçtikçe müşterileri daha mutlu ediyor :)

Unutmayın!
Kaliteli bir iş için yapılan yatırım hiçbir zaman boşa giden bir ödeme kalemi değildir.

Bir otomasyon projesine başlamadan önce otomasyondan beklentilerimizi ve amacımızı doğru bir şekilde belirlemeliyiz.

Yazının özeti olarak Tunç Kavaklıoğlu’nun yazdığı “Test otomasyonu projelerinde başarı nasıl yakalanabilir?” yazısını okuyabilirsiniz.
Somut bilgi ve tecrübe aktarımı yapılmış iyi bir makaledir.

Peki test otomasyon projelerinde bilinmesi gereken minimum pratikler nelerdir?

Doğru test aracının belirlenmesi
Test otomasyonu için efor tahminlemesi
Test otomasyonu işini yapacak kişinin seçilmesi ve ekiplerde yer alacak kişi/yetenek bilgilerinin güncellenmesi
Verilen eforun getireceği kârın hesaplanması
En önemli ve en can alıcı noktadır TEST DATA’ları
Browser senkronizasyonu , testlerin olmazsa olmazıdır
UI testler var ise selenium ile değil UFT ve muadili ürünler ile ilerlemekte fayda vardır
Kişi geçici, iş kalıcıdır. Bu yüzden yazılan test kodlarının belirli kabul görmüş standartlarda yazılması ve herkesin anlayacağı şekilde açıklama satırları girilmesi gerekir
Kod hatası ve test hatası birbirinden ayırt edilerek kontrol edilmesi gerekir. Bunun içinde Monitoring yapılması ve log çıktı kontrollerinin yapılmasında fayda var
Test değişkenlerini ve ortamlarını belirlemek test conversion geliştirmeleri üzerinde en etkili yöntemdir.
Örneğin; Iphone 5 ile koşulan testleri Iphone 5s ile koşulmasına gerek yoktur
Happypath ve en basit senaryolar ile Proof Of Consept şeklinde ilerleyerek yapılacak olan Road Map’in planı çıkarılmalıdır
Ve tabiki pratiklerimizin assolisti olan her elementin html id, uniq id bilgisinin olması. Test otomasyonda Name yada diğer properties özellikleri üzerinden kodlama yaptığınızda minimjum 3 release sonrası tekrar yazdığınız kodu güncellemek zorunda kalırsınız
Test otomasyonu geliştirmek teknik bir iştir. Scriptlerin yazılması, testware architecture dizaynı, otomasyon problemlerinin çözümü, debug edilmesi gibi aşamalar içerir
Bir otomasyon ekibindeki minimum gereksinimli roller şu şekilde olmalı: Test developer, test analiz, süreç yönetimi
Her otomasyon proje ekip odasının duvarında asılması gereken bir not olmalıdır
“Tests find bugs, not automation”
Otomasyonun ölçümü için EMTE (Equivalent Manual Test Effort) metodu kullanılabilir. Bu metod da hesaplama yapılabilir
Test otomasyon araçlarının sağladığı mimariyi kullanmak kolaya kaçmaktır. Otomasyon aracından bağımsız bir testware architecture oluşturmak en güzeli. Bu şekilde herhangi bir otomasyon aracı değişimi durumunda efor kaybı en aza inecektir
Otomasyon scriptleri geliştirilirken belirlenmiş standartlara uyulmalı ve tekrar kullanılabilir scriptler hazırlanmalı
Otomasyon için test statüleri pass ve fail’den çok daha fazlasıdır

Pratiklerden bahsetmişken Software Testing Life Cycle Test yönetimi için Mesut Erdoğmuş’un “Agile Yazılım Test Yaşam Döngüsü” yazısını okumanızda fayda var.

Yazının devamında şuanda gerçekleştirdiğimiz bir test otomasyon projesinin adım adım planlanması ve test koşum süreci ile raporlanması ve raporun yorumlanmasına dair bir paylaşım yapacağım.

Bu makalemizde bize ayırılan sürenin sonuna geldik (: