Menü

Çevik Dünyada Etkili Test Otomasyonu Nasıl Uygulanır?

  • Ana
  • Çevik Test
  • Çevik Dünyada Etkili Test Otomasyonu Nasıl Uygulanır?

how implement efficient test automation agile world

Sorunları Ortadan Kaldırmak Için Enstrümanımızı Deneyin

Agile'da otomasyon çok kritiktir.

Her Sprint'e eklenen ve sunulan birçok özelliği düşünün. Yeni eklenen özelliğin mevcut işlevselliği etkilemediğinden emin olmanın bir yolu olmalı.

Düşük Sprint süresi nedeniyle, Sprint sonunda ürün her artırıldığında tüm kıyafeti uygulamak neredeyse imkansızdır. Otomatik bir test kıyafetine sahip olmak burada kesinlikle daha büyük bir rol oynayacaktır.

Bununla birlikte, otomasyona giriş ve olgunlaşma kesinlikle biraz zaman alacaktır. Otomasyon faaliyetini planlamak ve tasarlamak için ilk yatırım yapmak kesinlikle uzun vadede karşılığını verecektir.

Agile Testing gelişmiş serisinin bu 3. bölümünde, siz projenize otomasyon getirirken deneyimlerime dayanarak göz önünde bulundurmanız gereken birkaç noktadan alıntı yapmaya çalışıyorum.

Ayrıca oku Bölüm 1 ve Bölüm 2 konuyu daha iyi anlamak için önce.

Ne öğreneceksin:

Çevik'te Neler Otomatikleştirilir?

Projelerimize otomasyonu dahil etmeyi planladığımızda, çoğumuz hemen 'Duman Testleri kıyafeti' veya 'regresyon testi kıyafeti' nin en iyisi olması için oy kullanırız. otomasyon adayı . Elbette öyleler, ancak otomasyon testi piramidini düşündüğümüzde, bahsettiğimizin piramidin sadece en üst katmanı olduğu sonucuna varabiliriz.

Yukarıdaki katmanın dışında hala hizmet katmanı ve birim katmanı bu daha önemli.

selenyumda css seçici nasıl yazılır

Öyleyse, Duman testleri ve Regresyon testleri dışında hangi testler otomasyon için iyi aday olabilir?

# 1) Derlemeler ve Dağıtımlar

Geleneksel ortamlarda, haftalık, iki haftada bir veya hatta bazen aylık olabilen önceden tanımlanmış yapılarımız vardır. Bunun nedenlerinden biri, bu dağıtımların zaman almasıdır. Bu yaklaşımla ilgili sorun, hataları düzeltmek veya yeni özellikleri uygulamak için önceden tanımlanmış tarihleri ​​beklememiz gerektiğidir, bu nedenle bir gecikme olur.

İkinci neden ise - test uzmanları testi bitirip hatalar ve kusurlar bulduğunda, programcılar farklı uygulama parçalarına geçtiler ve eski uygulamanın hatalarını çözmekle daha az ilgileniyorlardı. Bu yaklaşım aynı zamanda özelliğin üretimde kullanılabilir hale getirilme süresini de geciktirir.

İnşa etme ve konuşlandırmalar, tekrarlayan ve bazen sıkıcı olan varlıklardır. Ayrıca bir derlemeyi dağıtmak saatler alabilir, bu da testi ve sonunda geri bildirimi geciktirir. Tekrarlayan bir görev olan konuşlandırmalar, otomasyon için iyi bir aday haline gelir.

Ayrıca oku=> Sürüm ve Dağıtım Yönetimi Süreci

Otomatik derleme dağıtımına sahip olmanın avantajlarından bazıları şunlardır:

  • Dağıtım hatası yapma şansı yok (yanlış dosyanın kopyalanması veya dosyanın yanlış konuma kopyalanması gibi insan hataları önlenebilir)
  • Hata / özellikler giderilir düzeltilmez test edilebilir
  • Testçiler test etmek için daha fazla zaman alır
  • Özellik daha kısa sürede üretime geçmeye hazırdır
  • Hızlı geri bildirim

# 2) Birim testleri / Bileşen testleri

Birim katmanını otomatikleştirmenin öneminden daha önce bahsetmiştim. Son eğitimimdeki TDD yaklaşımı .

Bu, piramidin en alt katmanını oluşturur, bu nedenle temelin ve herhangi bir temelin kaya gibi sağlam olması gerekir. Geliştirme ekibi, testin çoğunu bu katmana yerleştirmek için işbirliği yapmalı ve birlikte çalışmalıdır.

# 3) API / Web Hizmeti Testi

Web hizmetleri, iki uygulamanın veri veya bilgileri, temeldeki mimari veya teknolojiyle uğraşmadan, istek ve yanıt açısından değiş tokuş ettiği ortamdır. Daha basit bir ifadeyle - bir talepte bulunmak ve yanıtı onaylamak normalde web hizmetleri testinde yaptığımız şeydir.

Web hizmetlerini test etme bu web hizmeti yöntemlerini çağırmak için programlar yazmayı ve döndürdüğü değeri / değerleri doğrulamayı gerektirir. Hizmetleri çeşitli permütasyonlar ve kombinasyonlar için bile test edebiliriz. Tüm test verilerini excel sayfasında bulundurun ve programınız verileri okuyabilir ve test verilerini parametre olarak geçirerek test edilebilir hizmeti arayabilir ve sonuçları doğrulayabilir.

Bu özel test, piramidin orta katmanının bir parçasıdır. Fonksiyonel testlerin çoğu bu katmana itilebilir. Bu katmanda ortaya çıkan kusurları çözmek kolaylaşır ve bunlar, kullanıcı arabirimi kullanılabilir olana kadar ertelenmez.

sabun ve dinlenme üzerine mülakat soruları

# 4) GUI arkasında test etme

GUI'nin arkasındaki testi otomatikleştirmek, gerçek GUI'yi otomatikleştirmekten nispeten daha kolaydır. Diğer bir avantaj, UI değişikliklerinden bağımsız olarak, işlevselliğin bozulmadan kalmasıdır. Bazı UI öğeleri değiştirilse bile, özelliğin işlevselliği değişmez. Bu teknik esas olarak iş mantığı ve kurallarına odaklanır.

Test senaryoları çoğunlukla tablo biçiminde veya bir elektronik tabloda yazılır ve bu tablolardan gelen girdiyi kabul eden ve sonuçları döndüren demirbaşlar / kod parçaları yazılır. Sonuçlar anında oluşturulur ve teknik olmayan paydaşların bu testleri çalıştırması ve beklenen sonuçları alması için harika bir platform sağlar. Bu tekniğe ulaşmak için kullanılan araçlardan biri Fitness .

# 5) İşlevsel olmayan testler

Bu fonksiyonel olmayan test tekniği temelde Yük, Performans ve Stres testini içerir. Piyasada bu testleri otomatikleştirmek için kullanılabilecek çeşitli araçlar vardır.

# 6) Veri Karşılaştırmaları

Testlerimizin çoğu, metin dosyaları, CSV veya excel dosyaları dahil olmak üzere veri dosyalarını karşılaştırmamızı gerektirir.

  • Bu dosyalar veri doğrulaması yapmak için temellerle karşılaştırılabilir
  • Karşılaştırmalar aynı verilerden olabilir ancak farklı bir formatta olabilir. Bu temelde iki farklı kaynaktan oluşturulmuş aynı dosyalardan ikisine sahip olduğumuzda olur.

Bu karşılaştırmalar tekrarlı olabilir, bu nedenle otomatikleştirilebilir.

# 7) Arama

Çok sayıda dosyadan belirli bir varlığı aramak da sıkıcı olabilir ve bu tekrarlayan bir görevse Tanrı bize yardım eder. Bir örnek, günlük dosyalarında arama yapmaktır. Bu aynı zamanda sıkıcı ve tekrarlayan bir görevse, otomatikleştirmeyi düşünmemiz gerekir.

# 8) Tekrarlayan Görevler

Son kullanıcılarla etkileşime girmekle veya onu geliştirmek için hikayeler yazmakla başlayan herhangi bir görev, tekrarlıysa, otomasyonda dikkate alınmalıdır. Otomasyon yapmanın, içinde karmaşık bir araç / teknoloji olması gerektiği anlamına gelmediğini anlamalıyız. Amacı çözmek için basit bir VB makrosu veya Javascript içeren bir Java programı olabilir.

Nereden Başlamalı?

Otomasyona nereden başlayacağınızı söyleyen hiçbir mermi noktaları veya adım adım kılavuz yoktur. Ekip için otomasyonu başlatmak, otomatikleştirmek istediğiniz yönler hakkında beyin fırtınası yapmanızı ve derin düşünceler uygulamanızı gerektirir veya otomasyonun nihai hedefi nedir?

Şununla başlayabilirsiniz:

  • Tekrarlayan görevleri belirleme,
  • Uygulamanın ağrı alanlarının belirlenmesi
  • Test zorluklarını belirleme

Tur projesinde / ekibinde otomasyon yoksa, muhtemelen ünite testlerinin otomatikleştirmek için önce hedeflenebileceği çok katmanlı bir yaklaşıma gidebilirsiniz. Bu size en yüksek ROI'yi verecektir.

Aynı anda, test uzmanları duman testi kıyafeti ve ardından regresyon üzerinde çalışmaya başlayabilir. Ekip becerileri kazandığında ve kendini rahat hissettiğinde, yavaş yavaş diğer tekrarlayan görevleri otomatikleştirmeye doğru ilerleyin.

İhtiyaçlarınızı değerlendirmeden doğrudan yeni bir alet satın almaya başlamayın. Daha önce de söylediğim gibi, basit bir program veya bir makro, tekrar eden bazı görevleri otomatikleştirme amacınızı çözebilir. Bu nedenle, bir araç satın almaya karar vermeden önce POC yapmak ve bu aracın kullanımının etkili olup olmayacağını değerlendirin.

Lütfen aşağıdaki makalelerde otomasyon için doğru test senaryolarının nasıl seçileceğine dair daha fazla ayrıntı ve Otomasyon çabalarını tahmin etme hakkında bazı bilgiler verdiğim bu belgeleri gözden geçirin. manuelden otomasyona kadar test süreci zorlukları ve selenyum otomasyon projesinin test tahmini.

Otomasyon kapsamı ve araç tamamlandıktan sonra, bir sonraki adım çerçeveyi tasarlamaktır.

Çevik'te çerçevenin geliştiğini unutmayın. Önce tüm çerçeveyi tasarlamayı ve sonra uygulamayı HEDEFLEMEYİN. MVP (Minimum Uygulanabilir Ürün) için tasarlayın ve uygulayın ve ardından mevcut çerçeveyi daha fazla özellik içerecek şekilde geliştirin. Otomasyon paketinizin sağlam olmasını istiyorsanız, iyi bir kodlama ve geliştirme uygulaması da uygulamanız gerekir.

Bazı En İyi Uygulamalar

  • Tek seferde% 100 Otomatikleştirmeyi hedeflemeyin. Küçük başla. Unutma ki bu gelişen bir süreç
  • Herhangi bir yazılım geliştirme için takip ettiğiniz Agile uygulamalarını takip edin. Otomasyon ayrıca uygun planlama ve tasarım gerektirir. Otomatikleştirirken teknik borçlarınızı artırmak istemezsiniz
  • Test otomasyon birikiminizi oluşturun. Bu iş yığını, yeni bir özelliğin uygulanmasından mevcut bir özelliğin geliştirilmesine kadar değişebilir. Tanımladığınız öğelere hikaye puanları verin ve buna göre atayın. Bu iş yığını öğelerini Sprint'inize götürün ve bir Kanban panosu kullanarak takip edin
  • Otomasyon öyküleriniz için kabul kriterlerini yazın. Bu kabul kriterleri şunları içerebilir:
    • Test paketinin CI ile entegrasyonu
    • Elbiseyi merkezi bir konuma taşımak
    • Sonuçları e-posta ile gönder
    • Test başarısız olduğunda hata günlük dosyalarını gönderme hükmü
    • Diğer kriterler….
  • Yeni bir aracı değerlendirmek için fazla zaman harcamayın. Yeni araçtan ne istediğinizi içeren öncelikli bir kontrol listesi oluşturabilir ve bunu değerlendirmek için bir zaman çizelgesine karar verebilirsiniz. Sonuçlarınızı öngörülen sürede görmezseniz, bir sonrakine geçin.
  • Neyin otomatikleştirileceğine dair mantıklı bir karar verin. Her otomasyon parçası etkili değildir ve pozitif bir yatırım getirisi sağlamaz. Sadece otomasyon uğruna otomatikleştirmeyin
  • Uygun geliştirme ortamından yararlanın. Kodu bulunduğunuz yerde saklamayın. Kodunuzu saklamak ve günün sonunda kodunuzu kontrol etmeyi alışkanlık haline getirmek için bir havuzunuz olsun
  • Benzer bir şekilde, otomatik testlerinizi merkezi bir konumdan gerçekleştirmeyi deneyin. Kişiyi bağımsız yapın. Ekipten herhangi birinin, komut dosyalarını makinelerinden tetikleyebilmesi ve sonuçların e-posta yoluyla alınması gerekir.

Otomasyona uygulanabilecek Çevik ilkeler nelerdir?

Bazı çok basit ipuçları:

  • İşleri basit tutun. Gerekeni yapın. Otomasyonu gereksiz yere karmaşık hale getiren şeker kaplı uygulama sunduğumuz birçok örnek gördüm. İhtiyaç duyulmayan şeylerden kaçınalım
  • Basit şeyler yapmak, en kolay şeyleri yapmak anlamına gelmez. Bu, otomasyon hedeflerinize ulaşmak için küçük adımlar atmak anlamına gelir. Otomatikleştirmek için basit bir özelliği ele alabilirsiniz, ancak otomasyon uygulamasının karmaşık bir uygulama olduğu ortaya çıkabilir.
  • Tüm ekip yaklaşımını uygulayın . Çevik bir takımda herkesin testçi olduğuna inanıyorum. Otomasyon işini ne sadece testçilerle ne de sadece geliştiricilerle sınırlamayalım. Proje için otomasyonu sağlamak için disiplinlerin her biri birbirinin yerine geçmelidir. Bu yaklaşım, uygulamayla birlikte gelen herhangi bir teknik sorunu çözmek için de etkili olacaktır.
  • Çerçeve Agile'de geliştirildi . Otomasyon parçasını gereksiz yere karmaşık hale getirebilecek çok fazla özellik sağlamaya çalışmayın.
  • Doğru yapmak için zaman ayırın. Teknik borçlardan kaçınmak için doğru şekilde tasarlamak için biraz zaman ayırın
  • Sık sık geri bildirim alın
  • Uygun kodlama standartlarını uygulayın ve uygulayın. Tasarım basit olmalı, OOPS konseptlerini uygulamalı ve testleri birbirinden bağımsız tutmaya çalışmalıdır. Test giysisinin 'sürdürülebilirliği' gibi faktörleri göz önünde bulundurun

Agile'da otomatikleştirme yaparken herhangi bir zorluk görüyor muyum?

Çevik dünyada otomasyon ile birlikte gelir kendi zorlukları :

  • Gerçekten iyi plan yapmalıyız. Uygun test paketi, araç, çerçeve ve yaklaşıma karar vermek, hepsinin uygun bir stratejiye ihtiyacı vardır. Ancak, fazla plan yapmamayı unutmamalıyız. MVP'yi (Minimal Uygulanabilir Ürün) aklınızda bulundurun
  • Hızlı teslim etmek istediğimiz için kod kalitesinden ödün vermek: Otomasyonda da teknik borçların iyi durumda olduğunu unutmamalıyız
  • Ekip çoğu zaman ekipler 'Tüm Ekip Yaklaşımı' nı takip etmez ve otomatikleştirilmiş paketi kodlama ve sürdürme sorumluluğunu test edenlerin sorumluluğuna ekleyen test uzmanları için bırakır.
  • İşlevsel testleri otomatikleştirmek, kullanıcı arayüzünü otomatikleştirmekten daha zordur

Tüm bu zorluklar arasında en kritik zorluk, test uzmanlarının becerilerini yükseltmektir.

Bir takım için otomasyonu yapmak ve sürdürmek, neredeyse programcıların (geliştiricilerin) yaptığı bir programlama (geliştirme) etkinliği gibidir. Yalnızca uygulama değil, aynı zamanda CI'ye otomatik uyumu entegre etmek de önemlidir ve test uzmanlarının yeni beceriler öğrenmesini ve benimsemesini ve yeni araçlar ve teknolojiler öğrenmesini gerektirir.

Agile'a uyan bazı Açık Kaynak Araçları

  • Selenium WebDriver - UI için
  • Selenyum Izgara - Paralel yürütme için
  • Salatalık - BDD için
  • JMeter - Performans testi için
  • SABUN - Web hizmetleri için
  • WireMock - Web servisi mevcut olmadığında web servis testi.
  • Epochs - Mobil için

Meşhur Agile test kadranlarıyla bitireyim:

Çevik test kadranları

Çeyrek 1 TDD yaklaşımı ile otomatikleştirilebilen Birim ve bileşenler testidir.

java dizisine eleman ekle örneği

Çeyrek 2 BDD yaklaşımını uygulayabileceğimiz işlevsellik testinden bahsediyor.

3. Çeyrek manuel test kapsamına sahip tek kadrandır.

Çeyrek 4 temel olarak bazı araçlarla gerçekleştirilebilecek testlerden bahsediyor. Bu, Yük testleri, Stres testleri, Hacim testleri ve Güvenlik testleri ile ilgilenir.

Sonuç

Duman testleri ve Regresyon testleri dışında pek çok otomasyon kapsamı vardır. Bu nedenle, otomasyonu yalnızca bu tür testlerle sınırlandırma kavramından kurtulmalıyız, bu da Agile'deki bir test uzmanının beceri setinin hataları ve kusurları bulmaktan daha fazlasını gerektirdiği anlamına gelir.

Test uzmanlarının daha işbirliğine dayalı olması ve programlama / otomasyon becerilerini geliştirmesi gerekir. Giderek daha fazla test otomatik hale getirilirse, test uzmanlarına kendilerini daha karmaşık ve zorlu görevlerle meşgul etmek için daha fazla zaman verecektir.

Yazar hakkında: Bu makale STH ekip üyesi Shilpa'ya aittir. İnternet reklamcılığı, Yatırım Bankacılığı ve Telekom gibi alanlarda son 10 yıldır yazılım test alanında çalışmaktadır.

Lütfen görüş ve düşüncelerinizi aşağıda paylaşın.

Önerilen Kaynaklar

^