Ana içeriğe atla

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

Yorumlar

  1. Teşekkürler paylaşımınız için. Çok güzel bir makale olmuş.

    YanıtlaSil
  2. teşekkürler güzel makale olmuş elinize sağlık

    YanıtlaSil
  3. güzel bir çalışma olmuş teşekkürler ellerinize sağlık

    YanıtlaSil

Yorum Gönder

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde (1, 2) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki:
“Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler, Sistem (Proje kapsamını belirtir), Use Caseler ve bunlar arasındaki ilişkiler. Şekil…

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Amaç, diyagramın sadece belirli k…

Cluster ve clustering nedir? Cluster oluşturmanın faydaları nelerdir? (Bölüm I)

Cluster, basit anlamda benzer bir amaç için belirli bir konfigürasyon yapılarak aynı görevi birlikte ya da yedekli çalışmasını sağlayan servistir. Cluster farklı amaçlarla oluşturulabilir fakat son kullanıcı tarafından her zaman tek bir bilgisayar gibi gözükecektir. Bir cluster oluşturmak için en azından iki adet sunucuya ihtiyaç vardır ve bir cluster içindeki her bir sunucu “node” olarak adlandırılır. İhtiyaç olan hizmete göre çeşitli sayıda nodelar bir araya gelerek clusterları oluşturmaktadır. Bir cluster oluşturmak için gerekli sebepler daha fazla performans ihtiyacı, yüksek erişilebilirlik (high availability) ya da her ikisi birlikte olabilir. Şimdi cluster çeşitlerini çok fazla ayrıntıya girmeden biraz daha yakından inceleyelim. Yüksek erişilebilirlik (High-availability) clusterlarıBu tip cluster yapısında öncelik erişilebilirliği arttırmadır. Bunu tek bir sunucunun görevini herhangi bir donanım yada yazılım problemi oluştuğunda diğer bir sunucunun otomatik olarak devralması olara…