=Paper=
{{Paper
|id=Vol-1980/YTM_2017_paper_1
|storemode=property
|title=Test Otomasyonunda Karsilasilan Zorluklar ve Ogrenilen Dersler: Telekomunikasyon Sektorunden Deneyimler(Challenges and Lessons Learned in Test Automation: Experiences from Telecommunications Industry)
|pdfUrl=https://ceur-ws.org/Vol-1980/YTM_2017_paper_1.pdf
|volume=Vol-1980
|authors=Gokhan Buyukyumukoglu,Ersin Ersoy,Mehmet Sevket Ozdemir,Selami Bagriyanik,Adem Karahoca
|dblpUrl=https://dblp.org/rec/conf/uyms/BuyukyumukogluE17
}}
==Test Otomasyonunda Karsilasilan Zorluklar ve Ogrenilen Dersler: Telekomunikasyon Sektorunden Deneyimler(Challenges and Lessons Learned in Test Automation: Experiences from Telecommunications Industry)==
https://ceur-ws.org/Vol-1980/YTM_2017_paper_1.pdf
Test Otomasyonunda Karşılaşılan Zorluklar ve
Öğrenilen Dersler: Telekomünikasyon Sektöründen
Deneyimler
Gökhan Büyükyumukoğlu1, Ersin Ersoy1, Mehmet Şevket Özdemir1, Selami
Bağrıyanık1, Adem Karahoca2
1 Turkcell, İstanbul, Türkiye
{gokhan.buyukyumukoglu, ersin.ersoy, ozdemir.mehmet, selami.bagriyanik}@turkcell.com.tr
2 Bahçeşehir Üniversitesi, İstanbul, Türkiye
adem.karahoca@eng.bau.edu.tr
Abstract. Yüksek kalitede yazılım üretmek gerçekleştirilmesi zor bir hedeftir.
Yazılım kalitesi 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. 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. Gereksinim analizi, tasarım veya gerçeklenmiş
yazılım kaynaklı hatalar, müşteri memnuniyetini olumsuz şekilde etkilemekte,
firmanın uymakla yükümlü olduğu regülatif kurallara uyamaması ve ceza riski
ile karşı karşıya kalmasına sebep olabilmektedir. Bazı yazılım hataları
operasyonel performans, ölçeklenebilirlik, kullanırlık ve güvenlik sorunlarından
da sorumludur. 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 otomasyonu, bahsi geçen sorunun adreslenmesinde
kullanılan çözümlerden biridir. Bu çalışmada, bir teknoloji ve iletişim
hizmetleri sağlayıcı firmanın bir portföyünün web tabanlı uygulamaları
kullanılarak yapılan servis, tarife ve kampanya testlerinin test otomasyonu
dönüşümünde yaşanan deneyimler aktarılmıştır. Söz konusu deneyimler dört
temel boyutta ele alınmıştır. Bu boyutlardan birincisi kullanılan teknoloji ve
tasarım, ikincisi yazılım yaşam döngüsünü oluşturan süreçlere entegrasyon,
üçüncüsü hem otomasyonu yapılan uygulamaların geliştirmesinde hem de
otomasyon yazılım ve testlerinde çalışan test geliştiricilerinin ve uygulama
kullanıcılarının motivasyonu ve sonuncusu da değişiklik yönetimi boyutlarıdır.
Keywords: Test Otomasyonu, Süreç Otomasyonu, Endüstriyel Deneyimler.
78
Challenges and Lessons Learned in Test Automation:
Experiences from Telecommunications Industry
Gökhan Büyükyumukoğlu1, Ersin Ersoy1, Mehmet Şevket Özdemir1, Selami
Bağrıyanık1, Adem Karahoca2
1 Turkcell, İstanbul, Türkiye
{gokhan.buyukyumukoglu, ersin.ersoy, ozdemir.mehmet, selami.bagriyanik}@turkcell.com.tr
2 Bahçeşehir
Üniversitesi, İstanbul, Türkiye
adem.karahoca@eng.bau.edu.tr
Abstract. Producing high quality software is a hard-to-achieve target. Problems
arising from software quality continue to be a difficult, complex, and
multidimensional problem area that continues to grow in importance for the
software industry. Errors in software-based products and services have a direct
impact on the company's reputation, financial performance and customer
loyalty. Requirement analysis, design or software based errors negatively affect
customer satisfaction and can cause the firm to fail complying with regulations
and face criminal fines. Some software faults are also responsible for
operational performance, scalability, usability, and security issues. Low quality
software also creates very significant negative effects on employee motivation,
team productivity and time to market speeds. Test automation is one of the
solutions used to address such problems. In this study, experiences from the test
automation of service, tariff and campaign tests of a web-based application of a
portfolio of technology and communication services provider firm is presented.
These experiences are discussed in four basic dimensions. The first of these
dimensions is used technology and design, the second is the integration to the
processes that make up the software life cycle, the third is motivation of both
test automation developers and application users working in automation
software and tests and the last dimension is change management.
Keywords: Test Automation, Process Automation, Industry Experiences.
79
1 Giriş
Tüm yazılım projelerinde üretilen yazılımların testi vazgeçilmez bir gerekliliktir.
Birim testleri, performans testleri, entegrasyon testleri, API testleri ve erişilebilirlik
testleri bunlardan bazılarıdır.
Bu çalışmada uygulama ekranlarının test edilmesini kapsayan fonksiyonel testler
üzerinde durulmuştur. El ile yapılan testlerde bir test uzmanı uygulamayı çalıştırır ve
uygulama ekranlarında çeşitli senaryoları dener, değişik girdiler kullanarak
uygulamanın beklenen davranışları sergileyip sergilemediğini, iş ve teknik
gereksinimleri karşılayıp karşılamadığını test eder. Günümüzde yazılım
endüstrisindeki test mühendisliği farkındalığı artırıp iyi test pratiklerinin
uygulanmasını sağlasa da her projede belli seviyelerde yazılım hataları ortaya
çıkmaktadır. Yazılım projelerinin kodlama aşamasında çıkan hata sayılarına
bakıldığında Amerika Birleşik Devletleri ortalaması işlev puanı (function point)
başına 1.75 yazılım hatasıdır [15].
Test otomasyonu ise kullanıcının yaptığı testlerin otomasyon yazılımları
aracılığıyla bilgisayar tarafından yapılmasıdır. Test otomasyonu ile yazılım test hızı,
test kapsamı, test maliyeti, yazılım kalitesi ve pazara sürüm süresi kriterlerinde
kazanımlar sağlanmaktadır. Genellikle test otomasyonu çok sık tekrarlanan, yapılması
zor olan ve kritik olan testler için geliştirildiğinden dolayı elle test pratiklerini
tamamen ortadan kaldırmayı hedeflememektedir. Çok nadir yapılan testler için veya
çok sık değişiklik gösteren sistemlerin testinde elle test yöntemleri kullanılmaktadır.
Test otomasyon projeleri tıpkı diğer yazılım projeleri gibi devamlı bakım gerektirir,
test edilen sistemler güncellendikçe, ilgili test otomasyon kodlarının da güncellenmesi
gerekmektedir. Bu anlamda düşünüldüğünde test otomasyon projelerinde kapsamın
belirlenmesi en önemli aşamalardan biridir. Günümüzde birçok test otomasyon
yazılımları bulunmaktadır. Selenium [17], Sahi [18], HP UFT [19] bunlardan
bazılarıdır. Test otomasyon projelerinde bu araçların desteklediği özellikler dikkatle
incelenmeli ve test edilecek sistemler ile uyumlu olup olmaması dikkate alınmalıdır.
Kurulum gerektirip gerektirmediği, dokümantasyon yeterliliği, otomasyon kodlarının
test edilecek sistem kullanılırken kayıt yapılarak otomatik olarak oluşturulabilmesi
gibi özellikler endüstride bu tip araçları değerlendirirken bakılan özelliklerden
bazılarıdır [16]. Test otomasyon ürünlerinde bulunan özelliklerden bir tanesi de teknik
olmayan kişilerin de test otomasyon yapabilmelerini sağlayacak yapılar içermeleridir.
Buna rağmen birçok projede yazılım geliştirici seviyesinde kodlama bilgi ve
becerisine sahip test uzmanlarına ihtiyaç duyulmaktadır. Hem bu yazılım araçlarının
ücretli olabilmesi, hem de geliştirme ve bakım aşamasında teknik personele ihtiyaç
duyulması göz önüne alındığında, test otomasyon projelerinin yatırım ve kaynak
gerektirdiği görülmektedir.
Çalışmada, kazanılan deneyimler teknoloji, yazılım yaşam döngüsü, motivasyon ve
değişiklik yönetimi başlıkları altında gruplanmıştır. Makalenin ikinci bölümünde test
otomasyonu ile ilgili literatür verilmiştir. Üçüncü bölümde firmadaki projenin
detayları tanıtılmıştır. Dördüncü bölümde karşılaşılan zorluklar ve öğrenilen dersler
aktarılmış, son bölümde ise sonuçlar ve gelecek çalışmalara ilişkin planlar
paylaşılmıştır.
80
2 İlgili Çalışmalar
Test otomasyonu, 25 seneyi aşkın bir geçmişe sahiptir ve test koşturma alanında belli
bir olgunluğa erişmiştir [1]. Test otomasyonu maliyetli bir etkinlik olmasına rağmen
doğru kapsam, süreç ve araçlarla tasarlandığında yatırımın geri dönüşünün
alınabileceği uzun bir süredir bilinmektedir [6,7]. Hız, maliyet ve kaliteye olumlu
etkileri de bazı yeni çalışmalardaki bulgularca da desteklenmiştir [5,11]. Ayrıca, test
otomasyonuna konu olan senaryoların sistem modelinden yarı otomatik bir yöntemle
türetilmesi ve türetilen senaryoların kodlamaya gerek olmaksızın otomatik
çalıştırılmasını sağlamak gibi daha ileri araştırmalar gerçekleştirilmiş ve test
zamanında kısalmalar tespit edilmiştir [14]. Bununla birlikte yazılım endüstrisinde
otomasyon kullanımı buna koşut olarak yaygınlaşamamıştır. Örneğin geniş bir mobil
uygulama kümesi üzerinde yapılan bir araştırmada, test otomasyonu pratiklerinin
kullanılmadığı, mobil uygulamaların sadece % 9’unun koşulabilir test senaryolarına
sahip olduğu ve test kapsamının % 40 civarında olduğu tespit edilmiştir [3]. Türkiye
ve Norveç yazılım endüstrilerinde yapılmış iki araştırmanın çıktılarından biri, test
otomasyonundan yeterince faydalanılmadığı sonucu olmuştur [4,13]. Bir başka
çalışmada anahtar başarı faktörlerinin önemi konusunda akademisyenler ile
profesyoneller arasında algı farklılıkları bulunduğu sonucuna varılmıştır. Sözü edilen
çalışmada [8] akademik literatür daha çok planlama aktivitelerine en büyük önemi
verirken, pratisyenler adanmış ve yetkin bir ekibin en önemli başarı faktörü olduğuna
inanmaktadır. Demiryolu ve telekomünikasyon sektörlerinde gerçekleştirilen iki vaka
çalışmasından yola çıkarak test otomasyonunda karşılaşılan güçlükleri detaylı bir
şekilde irdeleyen ve çözüm önerileri sunan yakın tarihli bir çalışmada öne çıkan iki
temel sorun ekip içindeki iletişim ve kaynak eksiklikleri olarak belirlenmiştir [9].
Günümüzde DevOps ve çevik yöntemlerin yaygınlaşmaya başlaması otomasyonun
dinamiklerini değiştirmiş, baş edilmesi gereken yeni zorluklar çıkarmış ve önemini
daha da arttırmıştır. Örneğin Scrum yöntemiyle çalışan ekipler için otomasyon seçime
bağlı olmaktan çıkmış ve neredeyse zorunlu hale gelmiştir [2]. Test otomasyonunun
sürekli teslimat (Continuous Delivery) içindeki kullanımına dair Avusturyalı bir
firmanın deneyimlerini aktaran bir çalışmada yaklaşık 6 sene süren sürekli teslimat
hattı oluşturma sürecinde test otomasyonun önemi vurgulanmaktadır [10]. Test
otomasyonu ve DevOps arasında simbiyotik bir ilişki olduğu söylenebilir.
Finlandiya’daki üç yazılım geliştime organizasyonunda gerçekleştirilen bir vaka
çalışmasında DevOps pratiklerinin de test otomasyonunu geliştirdiği belirlenmiştir
[12]. Aynı çalışmada, sürekli teslimat hattı kurarken ve işletirken dikkat edilmesi
gereken anahtar başarı faktörlerine de yer verilmiştir. Bu faktörlerin başında yönetim
sponsorluğunun alınması, sürekli teslimat hattı için kollektif sorumluluk alınması, test
ortam yönetiminin sağlanması, yazılımın test edilebilirliğinin arttırılması ve test veri
yönetiminin oluşturulması gelmektedir [10].
Bu çalışmada ise test otomasyonunun yazılım geliştirme döngüsündeki klasik
konumlandırmasından farklı bir şekilde kullanılması ele alınarak literatüre katkı
sağlanmıştır. Sözkonusu senaryoda test otomasyonu, bir çok farklı uygulamanın
bütünleşik olarak çalıştığı bir telekomünikasyon iş destek altyapısı üzerinden yapılan
karmaşık servis, tarife ve kampanya tanımlarının canlı ortam testinde kullanılmıştır.
81
Yani buradaki temel motivasyon tek bir ürün veya uygulamanın geliştirilmesi
esnasında test otomasyonu kullanmak değil, eş zamanlı olarak geliştirilen bir çok
entegre uygulamanın canlıya alınması ile bir araya gelmesinden oluşan karmaşık
sürecin içindeki etkileşimlerin sağlığının sürekli kontrol edilmesidir. Böylece hem
elle yapılan işin gerektirdiği efordan kaynaklı verimlilik kayıpları hem de insan
hatalarının yol açtığı risklerin azaltılması amaçlanmaktadır.
3 Endüstriyel Vaka Çalışması
Bu bölümde firmada gerçekleştirilen test otomasyon projesinin kapsamı açıklanarak
bir örnek senaryo ile detaylandırılmıştır. Çalışma, bir teknoloji şirketinin
müşterilerine sunacağı servis, tarife ve kampanyalar ile ilgili tanımlamaların son
kullanıcılara sunum öncesi yapılan doğruluk testlerinin gerçekleştirildiği süreçlerin
otomasyonunu amaçlamaktadır. Projede SahiPro ve Java programlama dili
kullanılmıştır.
Yazılım mühendisliğinde test otomasyonu denildiğinde ilk akla gelen, belirli bir
uygulamanın uçtan uca otomasyonudur. Bu çalışmada ise belirli bir uygulamanın
değil belirli bir servis, tarife ya da kampanyanın doğruluğunu teyit etmek için hali
hazırda uygulanan süreç kapsamında kullanılan tüm uygulamaların otomasyonu
kapsanmaktadır. Şekil 1 de örnek bir kampanya için hazırlanmış test otomasyon
senaryosu akışı gösterilmiştir. Söz konusu test senaryosu 5 farklı uygulama, 12 farklı
ekran üzerinde çalışmaktadır.
Şekil 1. Örnek bir test otomasyon akışı
Şekil 1. deki akışta, öncelikle test sırasında kullanılacak hat uygun duruma
getirilmektedir. Bu adımda hattın daha önce çalıştırılan test senaryolarından kaynaklı
olarak üzerine tanımlanmış özelliklerinin ilk günkü haline getirilmesi sağlanmaktadır
(1). Sonrasında söz konusu kampanya aktivasyonu için ön şart olan hattın A
tarifesinde olma koşulunu sağlamak için ilgili test hattı A tarifesine getirilmektedir.
Bu getirme işlemi birden fazla ekran üzerinde, birden fazla işlemin gerçekleştirilmesi
ile tamamlanır (2). Bir sonraki adımda söz konusu kampanyanın aktivasyonu
kampanya aktivasyon ekranından tanımlanır (3). Kampanya aktivasyonunun başarıyla
82
tamamlandığı, aktivasyon kontrolü ekranından kontrol edilir (4). Kampanya
aktivasyonları her durumda gerçek zamanlı olarak yapılmadığından, ekran üzerinde
belirli bir süre bekleme gibi akışlar uygulanır. Sonrasında kampanya aktivasyonu
kapsamında hat üzerine tanımlanması gereken detay özelliklerin (örneğin 100 dakika,
100 kısa mesaj gibi) verildiği kontrol edilir (5). İlgili kampanyanın aktiflendiğine dair
bilgilendirme kısa mesajı yollandığı kontrol edilir (6). Belirli senaryolarda hat
üzerinden kullanım yapıldığında aktiflenen kampanyanın kullanıldığının da kontrol
edilmesi gerekebilmektedir. Böyle durumlarda son olarak kullanım kontrolleri yapılır
(7). Başarılı bir senaryo sonrası sonuçların raporlanması gerçekleştirilir (8). İnce
çizgiler ile gösterilen akışta, herhangi bir adımda hata alınması durumunda hata
raporlanır ve senaryo tekrar denenmek üzere ilk adıma gider (9).
4 Güçlükler ve Öğrenilen Dersler
Bu bölümde test otomsayon projesinin ilk fazında elde edilen deneyimler, teknoloji ve
tasarım, motivasyon, değişiklik yönetimi ve yazılım yaşam döngüsü başlıkları altında
açıklanacaktır.
4.1 Teknoloji ve Tasarım
Test Otomasyon Senaryolarının Arka Planda Çağırılan Servisler ile Etkileşimi.
Senaryoların el ile test edilmesi sırasında web tabanlı uygulamaların kullanıcı
arayüzlerine bir internet tarayıcısı vasıtası ile girilir ve ekranlarda işlemler yaparak bu
testler gerçeklenir. Bu işlemler sırasında kullanıcı, sisteme ve verilere hakim olduğu
için bazı kararlar verir. Örneğin bir kampanyanın sadece faturalı hatlara tanımlı olup
olmaması bilgisini bilir ve ona göre ekranı kullanır. Ancak test otomasyon yapılırken
sistem bu bilgiyi bilmemektedir. Bu durumlarda arka planda bir başka sisteme bir
arka plan çağrısı yapılarak bu bilgi edinilir ve dönen değere göre de otomasyon
senaryosu ekrandaki akışa karar verir. İşte bu çağırılan servislerin sayısı çoğaldıkça
test otomasyon sisteminin diğer sistemlere olan bağımlılıkları artar. Bu bağımlı
olunan servislerdeki her aksama, test otomasyon senaryolarının aksamasına yol açar
ve sistemi kırılgan ve güvenilmez bir hale getirebilir. Bu arka plan servislerinin doğru
çalışması ve sayısı çok önemlidir. Kırılgan ve ayakta olma zamanı düşük olan
servisler test otomasyon senaryolarına dahil edilmemelidir. Dahil edilmesi zorunlu
olan durumlarda da ilgili servisin sahibi ile servislerin sürekli hazır olması konusunda
mutabakat sağlanmalıdır.
Test Otomasyon Ekran Görüntüsü Alınırken Karşılaşılan Siyah Ekran Sorunu.
Test otomasyon senaryolarının kullanıcıların bilgisayarından değil uzaktan bağlantı
ile Windows tabanlı sunucularda koşması durumunda eğer sunucuya aktif olarak bir
bağlantı bulunmuyorsa, senaryo kapsamında yapılan işlemlerin ekran görüntüsü
alınması sırasında sunucunun aktif bir görüntülü desktop ortamı olmadığı için siyah
ekran görüntüsü alınmaktadır. Burada sunucuya her zaman bağlı bir istemci
83
bulundurmak veya sunucu üzerine özel SanalAğ İşleme (VNC: Virtual Network
Computing) sunucusu yazılımları kurmak gibi alternatif çözümler kullanılmalıdır.
Senaryolarda HTML Komponentlere ID Alanı Dışında Erişim. Web tabanlı
uygulamarın test otomasyonunun yazılması sırasında ekrandaki belirli komponentlere
tıklamak, üzerine gelmek veya bir şekilde bu komponentleri kullanmak
gerekmektedir. Bunu yapabilmek için test otomasyonu kodlarının bu komponentlere
erişmesi gerekmektedir. Burada doğru yöntem bu komponentlere doğrudan ID
alanları üzerinden erişmektir. ID tekil bir alandır ve ilgili komponente erişimde
garantili bir yöntemdir. Erişilmek istenen HTML komponentlere ait ID alanı
uygulama kodlarında tanımlanmamışsa ilk önce otomasyonu yazılacak uygulamanın
kodlarının değiştirilmesi ve erişilecek komponentlere ID tanımlatılması sağlanmalıdır.
Komponentlere, ID alanı dışında etiket veya ekrandaki yakınında bulunan diğer
komponentlerin pozisyon bilgisinden erişilebilir ancak bunlar doğru erişimler
değildir. Çünkü bu bilgilerin hepsi değişime açıktır. İlgili komponentin ekrandaki yeri
değişebilir, veya üzerindeki etiket değiştirilebilir.
Senaryoların Yazımında Kullanılan Teknolojinin Tarayıcı Değiştirme Özelliği.
Otomasyon kapsamında kullanılan uygulamaların sadece belirli tarayıcılar üzerinde
çalışması gerekebilmektedir. Örneğin A uygulaması sadece Chrome tarayıcısında
çalışabilirken B uygulaması ise Firefox tarayıcısını gerektirebilir. Bu durumda test
otomasyon geliştirmelerinin yapıldığı teknolojinin senaryonun ortasında kullanılan
tarayıcıyı değiştirebilme özelliği olması önem kazanmaktadır. Test otomasyon
projelerine başlamadan bu konuya ayrıca dikkat edilmelidir. Bu özelliğin olmaması
durumunda farklı tarayıcı gerektiren uygulamaların olduğu senaryolar ikiye bölünerek
çözülmüştür.
Test Otomasyon Senaryolarında Adımlar Arası Sabit Beklemeler. Test
otomasyon senaryo yazımlarında bazen bir işlemden sonra ekranda bazı
değişikliklerin olması beklenir ki ikinci bir adıma geçilebilsin. Bir kaydetme
işleminden sonra bir veri tabanı tablosu üzerinde oluşan kaydın işlenmesinin
beklenmesi bu duruma örnek olarak verilebilir. Bu gibi durumlarda adımların arasına
sabit t saniye bekleme gibi komutların eklenmesi durumunda otomasyon
senaryolarının süresi uzamaktadır. Senaryolarda sabit bekleme komutları yerine,
işlemin tamamlandığının anlaşılıp senaryoya devam edilmesinin sağlanması senaryo
süresine katkı sağlayacaktır. Kullanılan teknolojilerin wait() metodları değil mümkün
olduğu her durumda waitFor() veya wait($condition) metodları kullanılmalıdır.
SahiPro teknolojisi düşünüldüğü zaman wait(5000) komutu yerine Onayla butonu
görünür olana kadar bekle anlamına gelen wait(5000, _isVisible(_button("Onayla")))
komutu tercih edilebilir.
84
4.2 Yazılım Yaşam Döngüsü ve Otomasyonun Entegrasyonu
Senaryo Analizlerinin Eksik İletilmesi. Otomasyon kapsamında kullanılan
uygulamalarda birçok iş kuralı bulunmaktadır. Bu iş kurallarının bazıları ise çok nadir
olarak oluşan durumlarda ortaya çıkmaktadır. (Örneğin sadece son dört aydır faturası
ödenmemiş bir hat için ekrana bir pencere çıkması gibi). Bu pencere çıkması gibi
nadir durumlar senaryo tariflenirken unutulmakta ve senaryo kodları içine doğal
olarak programcı tarafından eklenmemektedir. Bu durumda canlı ortamda koşulan test
otomasyon senaryolarında bu uç örnekler yaşandığı zaman senaryo başarısız olmakta
ve tekrar kod yazılması gerekmektedir. Bu örneklerin sayısı çoğaldıkça test
otomasyon senaryolarının güvenilirliği azalmakta, sürekli hata alan bir sisteme
dönüşmektedir. Bu durumda da sisteme güven azalmaktadır.
Senaryolar için Test Kapsama Oranının Düşük Olması. Her geliştirme sürecinde
olduğu gibi test otomasyon senaryolarının da geliştirme aşaması bittikten sonra test
edilmesi gerekmektedir. Bu testlerde genelde olağan akışın test edilmesi durumlarında
uç örnekler gözden kaçabilmektedir. Test otomasyon senaryolarının hata aldığı
durumlar genelde canlı ortamda çok nadir rastlanan iş akışlarıdır. Bunların test
aşamasında bulunması için ise ilgili verinin hazırlanması ve ilgili iş akışının detayının
test ekibi tarafından da bilinmesi gerekmektedir. Bu analiz aşaması detay bilgisinin
test ekibi tarafından bilinmediği durumlarda bu nadir görülen iş akışı hataları hep
canlı ortamda çıkmakta ve sisteme olan güven azalmaktadır.
Test Verisi İhtiyacı. Test otomasyon senaryosu kapsamı büyüdükçe senaryoyu
çalıştırabilmek için gerekli test verilerinin hazırlanması da zorlaşmaktadır. Test
otomasyon senaryoları geliştirilirken aynı zamanda test otomasyon senaryolarının
kendi test verilerini oluşturması, gerek motivasyon gerekse de elle hazırlanan test
verilerindeki eksiklikler sebebi ile oluşacak hataların önüne geçebilir.
Test Otomasyonu Yazılacak Uygulamaların Ortam Farklılıkları. Test otomasyon
senaryoları yazımı aşamasında test geliştiricileri bu uygulamaların canlı ortamına
erişememektedir, bu sebeple genelde test ortamlarını kullanmaktadırlar. Ancak bazı
uygulamalarda test ortamlarında çalışan kod ve ekranlar canlı ortamla farklılık
gösterebilmektedir. Bu durumda da yazılan senaryolar canlı ortamda çalıştığında
hatalar ile karşılaşılabilmektedir. Bir uygulamanın test otomasyonu yazılmaya
başlanmadan önce ortam sorunlarının giderilmesi gerekmektedir.
4.3 Test Geliştiricisi ve Kullanıcı Motivasyonu
Test Otomasyon Senaryo Kapsamı. Test otomasyonu yapmaktaki amaçlardan bir
tanesi de insan kaynağı olmadan ilgili yazılımın testinin bilgisayar sistemleri
tarafından belirlenen periyotlarda otomatik olarak yapılmasını sağlamak ve
otomasyon sonucuna göre aksiyon almaktır. Burada başarılı olabilmek ve insan
faktörünü ortadan kaldırabilmek için test otomasyonu senaryolarının test kapsamının
büyük çoğunluğunu kapsaması gerekmektedir. Vakamızda karşılaşılan en büyük
85
sorunlardan bir tanesi proje başlangıcında belirlenen senaryoların tüm servis, tarife ve
kampanyaların sadece belirli bir miktarını karşılamasıdır. Bu durumda bir servisimizi
kullancılarımıza sunmadan önce koşulan test otomasyonu tek başına bir güvence
sunamamakta, bu nedenle el ile otomasyon senaryolarının kapsamadığı kısımların test
edilmesi gerekmektedir. Burada iki farklı test sistematiği kullanımının test yapan
çalışanlar için bir zorluk oluşturduğu görülmüştür. Sadece test otomasyonuna
güvenilmemesi sürekli olarak tüm testlerin aynı zamanda el ile de yapılmasını
gerektirmektedir. Bu durumda da test otomasyon sistemi ve ürettiği raporlar her
zaman çalışanlar için kontrol etmeleri gereken ikinci bir iş olarak kalabilmektedir.
İnsan faktörü olmadan test otomasyonu ile de canlı ortama rahatlıkla servis çıkılması
hedefi gerçeklenememektedir. Test otomasyonu kodlarının en azından bir sistemin
belirli kısımlarını güvenli bir şekilde test ettiği, basit ve tekrarlanan testlerin tamamını
kapsadığı bir ortam sağlanabilirse, kullanıcıların bu kısımları hiç elle test etmemeleri
ve sadece çok zor ve karmaşık senaryolara odaklanmaları kullanıcı motivasyonunu
arttırabilmektedir. Test otomasyonunun aynı zamanda sistemlerin temel ve hiç
değişmeyen kısımlarının testi işini başarıyla yaptığı durumlarda, yazılım test
uzmanları el ile sadece uygulamalara yeni eklenen özellikleri ve en son geliştirmeleri
test ederler, bu da testlerde sıkıcılığın önüne geçerek motivasyonu arttıran bir faktör
olarak öne çıkmaktadır.
Test Otomasyon Senaryolarının Çalışması Sırasında Hata Alması. Elle test
sırasında akışın herhangi bir tanesinde bir sorunla karşılaşıldığında test eden kişi bu
sorunu aşmak için uğraşmakta, başka kişilere sorular sorabilmekte ve yardımlarını
alabilmektedir. Sorun çözüldüğü anda işlemine kaldığı yerden devam etmekte ve o
ana kadar yaptığı işlemler ve tanımladığı veriler boşa gitmemektedir. Uçtan uca bir
test otomasyonunda ise bu tip beklenmedik bir durum ile karşılaşıldığında süreç
tıkanmakta ve senaryo başarısız olarak sonlanmaktadır. Daha sonra başarısızlık sebebi
otomasyon logları incelenerek test geliştirici kişiler tarafından düzeltilmekte ve
senaryo tekrardan koşulmaktadır. Burada senaryo en baştan tekrar başladığı için test
otomasyon ile test edilen süreç elle teste göre daha uzun sürmekte ve test
uzmanlarının aynı iş üzerindeki çalışma saatlerini arttırarak kişinin motivasyonunu
düşürebilmektedir. Bu noktada uçtan uca bir çözüm yerine hata alınana kadar devam
eden bir yapı ve hata alındığı noktada elle teste devam edilmesini sağlayan bir sistem
geliştirilmesi bu sorunun çözümüne yardımcı olacaktır.
4.4 Değişiklik Yönetimi
Test Otomasyon Uygulama Ekranlarının Sık Değişmesi. Test otomasyon
senaryolarının yazılması tıpkı yazılım geliştirme aşamasında kod yazmaya
benzemekte ve benzer zorluklar taşımaktadır. Bu durumda da bir senaryonun
yazılması zaman alabilmektedir. Uygulama ekranlarının çok sık değiştiği ve oturmuş
ekranlar olmadığı durumlarda ise ekrandaki değişiklikleri hemen aynı anda test
otomasyon senaryolarına da yansıtmak gerekmekte aksi takdirde canlı ortamdaki
ekranın versiyonu ile otomasyon senaryosu uyuşmamakta ve hatalı test sonuçları
üretilmektedir. Ek olarak ekrandaki değişiklikleri test otomasyon kodlarına
86
yansıtmanın zorluğu ve zaman alması dışında karşılaştığımız bir başka zorluk ise
ekranların değiştiği bilgisine erişmekte yaşanmıştır. Şekil 1. deki akış üzerinde
anlatıldığı gibi belirli bir servis, tarife veya kampanyanın test edilebilmesi için
şirketteki farklı birimler tarafından geliştirilen bir çok uygulamanın kullanılması
gerekmektedir. Otomasyon senaryoları ise bu birimlerin dışında ayrı bir birim
tarafından yazılmıştır. Burada birimler arası iletişimin önemi öne çıkmaktadır.
İletişimin yanısıra versiyon kontrol sistemlerinin düzenli olarak kontrol edilmesi ile
değişen ekranların önceden belirlenmesi ve test otomasyon ekibine otomatik olarak
iletilmesi gibi ihtiyaçlar olduğu görülmüştür.
5 Sonuçlar ve Gelecek Çalışmaları
Çalışmamızın ilk fazı sonucunda bir çok farklı nedenden dolayı çeşitli zorluklar
yaşanmış ve bu zorlukların neticesinde kazanımlar elde edilmiştir. Bu kapsamda
teknoloji ve tasarım konusunda daha basit bir mimari ve teknoloji kullanımının
çalışmanın başarısını arttıracağı görülmüştür. Bu kararın sonucunda kullanıcılara daha
fazla sorumluluk verilmesi kaçınılmazdır ancak gerçekleştirdiğimiz vaka
çalışmamızda tamamiyle otomasyon yerine belirli noktalarda kullanıcılara inisiyatif
vererek süreç otomasyonunun geliştirilmesinin başarı oranını arttıracağı görülmüştür.
Özellikle senaryonun hata alması durumunda kullanıcının işlemi el ile gerçekleştirip
kaldığı yerden senaryonun devam etmesini sağlamasının çok önemli bir kazanım
olacağı görülmüştür. Buna ek olarak test otomasyon senaryosunun çok iyi analiz
edilmesi gerektiği, sadece ana akışların değil detay akışların da dikkate alınması
gerektiği ortaya çıkmıştır. Benzer şekilde değişiklik yönetiminin iyi yapılamamasının
senaryoların hata almasında bir etken olduğu, bu nedenle kullanılan uygulama
ekranların değişiminin proaktif bir şekilde belirlenip önlemler alınması gerektiği
ortaya çıkmıştır. Bütün bu sebeplerden dolayı test otomasyon senaryolarının
koşulması sırasında yaşanan hataların gerek test geliştiricisi gerekse de kullanıcı
motivasyonunu olumsuz etkilediği de gözlenmiştir.
Bu çalışma kapsamında kazanılan deneyimler çalışmanın bundan sonraki
fazlarında kullanılacaktır. Öncelikli iki senaryo için öğrenilen derslerden yola çıkarak
gerekli iyileştirmeler yapılacak, iyileştirmelerin başarılı olması durumunda diğer
senaryolara da uygulanacaktır.
Kaynaklar
1. Garousi, V., Elberzhager, F. : “Test Automation : Not Just for Test Execution”. IEEE
Software, 34(2), 90-96. (2017)
2. Tyagi, S., Sibal, R., Suri, B. : “Adopting Test Automation on Agile Development Projects:
A Grounded Theory Study of Indian Software Organizations”. In : International Confer-
ence on Agile Software Development (pp. 184-198). Springer, Cham. (2017)
3. Kochhar, P. S., Thung, F., Nagappan, N., Zimmermann, T., Lo, D. : “Understanding the
test automation culture of app developers”. In : Software Testing, Verification and Valida-
tion (ICST), 2015 IEEE 8th International Conference on (pp. 1-10). IEEE. (2015)
87
4. Garousi, V., Coşkunçay, A., Betin-Can, A., Demirörs, O. : “A survey of software engi-
neering practices in Turkey”. Journal of Systems and Software, 108, 148-177. (2015)
5. Kumar, D., Mishra, K. K. : “The Impacts of Test Automation on Software's Cost, Quality
and Time to Market”. Procedia Computer Science, 79, 8-15. (2016)
6. Hoffman, D. : “Cost benefits analysis of test automation”. STAR West, 99. (1999)
7. Ramler, R., Wolfmaier, K. : “Economics perspectives in test automation: balancing auto-
mated and manual testing with opportunity tutar”. In : Proceedings of the 2006 interna-
tional workshop on Automation of software test (pp. 85-91). ACM. (2006)
8. Rodrigues, A., Dias-Neto, A. : “Relevance and Impact of Critical Factors of Success in
Software Test Automation lifecycle: A Survey”. In : Proceedings of the 1st Brazilian
Symposium on Systematic and Automated Software Testing (p. 6). ACM. (2016)
9. Tcholtchev, N., Schneider, M. A., Schieferdecker, I. : “Systematic Analysis of Practical Is-
sues in Test Automation for Communication Based Systems”. In : Software Testing, Veri-
fication and Validation Workshops (ICSTW), 2016 IEEE Ninth International Conference
on (pp. 250-256). IEEE. (2016)
10. Gmeiner, J., Ramler, R., Haslinger, J. : “Automated testing in the continuous delivery
pipeline: A case study of an online company”. In : Software Testing, Verification and Val-
idation Workshops (ICSTW), 2015 IEEE Eighth International Conference on (pp. 1-6).
IEEE. (2015)
11. Alegroth, E., Feldt, R., Olsson, H. H. : “Transitioning manual system test suites to auto-
mated testing: An industrial case study”. In : Software Testing, Verification and Validation
(ICST), 2013 IEEE Sixth International Conference on (pp. 56-65). IEEE. (2013)
12. Riungu-Kalliosaari, L., Mäkinen, S., Lwakatare, L. E., Tiihonen, J., Männistö, T. :
“DevOps Adoption Benefits and Challenges in Practice: A Case Study”. In : Product-
Focused Software Process Improvement: 17th International Conference, PROFES 2016,
Trondheim, Norway, November 22-24, 2016, Proceedings 17 (pp. 590-597). Springer In-
ternational Publishing. (2016)
13. Anika, S. : “Investigation of the use of test automation in software quality assurance in
Norwegian companies and organisations”. (Master's thesis, NTNU). (2016).
14. Özkan, U., Sözer, H. : “Web uygulamaları için model bazlı test süreci otomasyonu”. In :
9th Turkish National Software Engineering Symposium, UYMS 2015. CEUR. (2015)
15. Jones, C. : Software Defect Origins and Removal Methods. (2012)
16. Sheth, T., Singh, S.K. : "Software Test Automation - Approach on evaluating test automa-
tion tools", International Journal of Scientific and Research Publications, Volume 5, Issue
8. (2015)
17. Selanium Test Otomasyon, http://www.seleniumhq.org/. Erişim Haziran.
18. Sahi Test Otomasyon, http://sahipro.com/. Erişim Haziran.
19. UFT Test Otomasyon, https://software.microfocus.com/en-us/software/uft. Erişim
Haziran.
88