Univera Test Otomasyon Deneyimleri

Söz verdiğimiz gibi Univera test otomasyonu projesi ile ilgili deneyimlerimizi paylaşmaya başlıyoruz.

Alice Harikalar Diyarında kitabında şuna benzer bir sahne vardı: Alice dehşete kapılmış bir şekilde arkasına bakmadan koşuyor. Bir süre sonra arkasındaki tehlike her neyse bir miktar geride kalıyor. Alice ise nefes nefese koşmaya devam ediyor. Birden yol ikiye ayrılıyor, tam kavşakta bir tavşan var. Alice panik içinde, bir nefeste soruyor: “Hey tavşan, hangi taraftan gitmeliyim!”

Tavşan havucundan bir diş koparıyor, ağzında güzelce çiğneyip yutuyor, sonra sakin bir tavırla soruyor: “Sen nereye gitmek istiyorsun ki?”

İşte böyle… Bizim de arkamızdan azgın bir pazar koşuyor. Ama her şey iyi bir planlamayla başlar derler. O hâlde sakin kalıp sormakta fayda var: Biz gerçekten de nereye gitmek istiyoruz?

İşte bizim zirvesine ulaşmak istediğimiz dağ:

Yazılım ve test uzmanları omuz omuza, ele ele, diz dize beraber çalışarak, hataları çözerek değil, hataların oluşmasına izin vermeden ortak ve stabil bir hat üzerinde geliştirme yapıyor.

Ortak hatta yapılan her geliştirme için –evet, main hattına yapılan her checkin için- otomatik versiyon numarası atanıyor ve sorunsuz set oluştuğu test ediliyor. Ardından ünite testi (unit test) otomatik çalışıyor.

Unite testleri 5 dakika içinde tamamlanıyor. Daha sonra son kullanıcı kabul testleri için test otomasyonu çalışıyor. Bu işlem saatler hatta belki 1 gün sürüyor

Ardından fonksiyonel olmayan testler dönüyor: Performans testi, yük testi, güvenlik testi, vs. Tabii onlar da otomatik.

Ve son olarak insana dayalı testler başlıyor: Formların genel görünümü, otomasyona girmeyen testler, genel stabilite kontrolleri, vs.

Tercihan, sonuncusu hariç hepsi insan eli değmeden otomatik çalışıyor. Sonuç: Her hafta bir set, hatta belki daha da sık!

Hedef Everest Dağı’na benziyor değil mi? Gerçekten de öyle, fakat ütopik değil. Zira pazarın bizi doğrudan zorladığı nokta tam da burası. Gün itibarıyla rakiplerimizin önünde olmamız bir teselli kaynağı olamaz. Ağrı Dağı ile yetinmeniz pazarı ilgilendirmiyor: Günü geldiğinde ya Everest’in zirvesinde olacaksınız ya da hiçbir yerde!

Bu güzel dağ manzaralı resme bakarak “test otomasyonu” kapsamında değerlendirilebilecek maddelerin üzerinden şöyle bir geçmekte fayda var:

·         Ünite testi geliştirmeleri, yazılım geliştirme sürecinin bir parçası olarak ilerliyor. Geliştirilen her komponent, sistemin bütününden izole edilerek ünite testinden geçiyor. Böylece kodlanan tüm küçük birimlerin kendi içinde sorunsuz çalıştığından emin olacağız ve her check-in için bozulmadığını tekrar tekrar kontrol edeceğiz.

·         Kullanıcı kabul testleri ise “test otomasyonu” deyince aklımıza ilk gelen testleri oluşturuyor. Yani kullanıcı ara-yüzlerini kullanarak sanki bir kullanıcı gibi sisteme ilgili girdileri verip beklenen çıktıları alıp almadığımızı kontrol ediyoruz.

·         Performans, yük ve güvenlik açıkları testleri gibi “fonksiyonel olmayan testlerin” diğer testlere göre önemsiz olduğunu kim söyleyebilir? Diğer hatalara göre nadir karşılaşılıyor olsak da, meydana çıktığında tüm sistemi ciddi seviyede etkileyebilen, kısa bir süre için bile göz ardı edilmesi mümkün olmayan ölümcül hatalar bunlar.

Ve evet, hepsi ve belki de fazlası otomasyon kapsamına dâhil edilebilir, insan eli değmeden otomatik çalıştırılabilir, çalıştırılmalıdır.

Biraz uzattık ama “test otomasyonu” için adım atarken iki temel taşı yerine oturtmamız gerekiyor: Birincisi test otomasyonunun genel test yaklaşımında (veya toplam kalitede) nerede duracağı, ikincisi test otomasyonun kapsamı; önce kısa orta vade için, sonrasında uzun vade için.

Univera’da bizim başlangıç noktamız kullanıcı kabul testleri otomasyonu oldu.

Başlangıçta bilgi ve tecrübemiz oldukça kısıtlıydı. Test otomasyonunun Türkiye için oldukça yeni bir kavram olduğu ortadaydı. İzmir’de deneyim sahibi olan kişi bulmak imkânsız gibi bir şeydi.

Bu süreçte İstanbul’da test otomasyonu kullanan firmaları ziyaret ettik. Onların tecrübelerinden faydalandık. Konusunda uzman danışmanlarla çalıştık. Ve tabii ki bol bol internet araştırması yaptık.

İlk olarak web uygulamamız için test otomasyonu ürünümüzü seçtik. Tercihimizi “Sahi” den yana kullandık. Bir taraftan da mobil cihazlar için test otomasyonu ihtiyacımızı asla unutmadık.

Test otomasyonu mimari tasarımı ve otomasyon framework’u oluşturma için harcadığımız zamana acımadık. 

Zira başarısız olan projelerin temel sebebinin bu aşamalar için yeterince zaman ayrılmaması, alelacele senaryo kodlamasına geçilmesi olduğunu gayet iyi biliyorduk.

Test otomasyonu araçlarının ekran üstündeki objeleri tanıması gerekiyor. Obje tanımlama işlemi için temel olarak iki farklı metodoloji kullanılıyor. Birinci grup metodolojide genellikle bir agent sayesinde test otomasyon aracı test edilecek platformdaki objelerin değişken bilgilerine, örneğin id bilgisine, ulaşıyor. Daha sonra bu id kullanılarak obje üzerinde istenen işlem yapılıyor, örneğin bu id bir butona aitse, ilgili komutlarla buton tıklanması sağlanıyor.

İkinci grup metodolojide obje id’lerine ulaşılması gerekmiyor. Çünkü otomasyon aracı görüntü tanımlama metoduyla ekranda işlem yapmak istediği alana ulaşıyor. Örneğin “kapat” butonuna tıklanacaksa mouse ile kapat butonun olduğu alan çerçeve içine alınıyor. Böylece “kapat” butonunun bulunduğu bölgenin “fotoğrafı çekilmiş” oluyor. Otomasyon çalışırken ekran üzerinde bu görüntünün bulunduğu bölge bulunuyor ve istenen işlem (örneğin tıklama işlemi) yapılıyor.

Görüntü tanımlama tekniğini kullanan otomasyon araçlarında obje id’si bulmak gibi bir kaygı olmadığı için senaryo kodlama diğerine göre oldukça kolay ve hızlı ilerliyor.   

Mobil otomasyon aracı araştırırken görüntü tanımlama metodu kullanan otomasyon araçlarından bazılarını inceledik. EggPlant bu konuda ticari olarak en tanınmış ürün olarak görünüyordu. Kodlama bilgisi çok az olan hatta hiç olmayan kişiler için bile senaryo yazmayı mümkün hâle getiren kullanışlı bir yapısı var. Bununla beraber fiyatı oldukça yüksek ve bu fiyatın her sene tekrar ödenmesi gerekiyor.

Görüntü tanımlama temelli ürünler arasında alternatif olarak Sikulix adlı ürünü de inceledik. Sikulix MIT’den bir grup yazılımcı tarafından açık kaynak kod olarak geliştirilmiş. Ürünü hakkında çok sayıda olumlu yorumlar bulunuyor.

İncelemelerimiz sırasında Sikulix ile karakter tanımlama konusunda bazı sorunlar yaşadık. Örneğin ekranda 228 olan bir sayı Sikulix tarafından Z28 olarak okundu. Bu gibi sorunlarda açık kaynak kodlara yoğunlaşarak bazı çözümlere ulaşabileceğimizi görüyorduk. Ancak mevcut kaynağımızı kendini kanıtlamış, mümkün olduğu kadar az Ar-Ge çalışması gerektiren bir üründen yana kullanmayı tercih ettik.

Böylece Sikulix ile vedalaştık. Tıpkı ilk aşk gibi, “ayrıldık ama hiç unutmayacağız!”

Devam eden Ar-Ge çalışmalarının ardından Smart Bear firmasının TestComplete ürününü mobil cihazlar için test otomasyon aracı olarak seçtik. Tıpkı Sahi gibi TestComplete ürüne de yukarda açıklanan birinci tür metodolojiyi kullanıyor.

“Sahi” test otomasyonu tecrübesi ile oluşturduğumuz framework yapısını TestComplete mobil platformuna taşımamız bize büyük hız kazandırdı. TestComplete ürününün mobil yanında web ve hatta desktop uygulamalarını da test edebiliyor olması bizi heyecanlandırıyor.

Hele TestComplete ürününün farklı platformdaki testleri tek bir senaryoda yapabiliyor olması, örneğin Android cihazda başlayan bir senaryonun bilgi aktarımından sonra web uygulamasında devam edebiliyor olması şapkamızı havaya uçuruyor.

Bu günlük de bu kadar olsun. Gelecek yazıda Sahi ve TestComplete deneyimlerimiz ve kurduğumuz test otomasyon mimarisi hakkında bilgi vermeye devam edeceğim. 

Sözümüzü Google şirketinin mottolarından biriyle bağlayalım:

“Her yazılımcı test yapacak, her testçi de kodlama yapacak!”

Seyit BALKUV