Kalite güvencesine başvuran beş kişiden dördü otomatik testlerle nasıl çalışılacağını öğrenmek istiyor. Manuel test uzmanlarının bu tür isteklerini mesai saatleri içinde her şirket yerine getiremeyebilir. Wrike, çalışanlar için bir otomasyon okulu düzenledi ve birçok kişinin bu arzusunu gerçekleştirdi. Bu okula tam olarak QA öğrencisi olarak katıldım.
Selenium ile nasıl çalışılacağını öğrendim ve artık neredeyse hiç dışarıdan yardım almadan belirli sayıda otomatik testi bağımsız olarak destekliyorum. Ve ortak deneyimlerimizin sonuçlarına ve kişisel sonuçlarıma dayanarak, en ideal otomasyon okulunun formülünü çıkarmaya çalışacağım.
Wrike'ın okul düzenleme deneyimi
Bir otomasyon okuluna olan ihtiyaç netleştiğinde organizasyonu otomasyonun teknik lideri Stas Davydov'a düştü. Neden bu girişimi ortaya attıklarını, sonuç alıp almadıklarını, harcanan zamandan pişmanlık duyup duymadıklarını ondan başka kim açıklayabilir? Ona söz verelim:
— 2016 yılında otomatik testler için yeni bir çerçeve yazdık ve bunu test yazmayı kolaylaştıracak şekilde yaptık: normal adımlar ortaya çıktı, yapı çok daha anlaşılır hale geldi. Bir fikir ortaya attık: Yeni testler yazmak isteyen herkesi dahil etmeliyiz ve anlaşılmasını kolaylaştırmak için bir dizi ders hazırladık. Toplu olarak bir konu planı hazırladık, gelecekteki öğretim elemanlarının her biri kendine bir konu planı aldı ve bunun hakkında bir rapor hazırladı.
— Öğrenciler ne gibi zorluklarla karşılaştılar?
— Esas olarak elbette mimari. Testlerimizin yapısıyla ilgili birçok soru vardı. Geri bildirimde bu konu hakkında çok şey yazıldı ve daha ayrıntılı olarak açıklamak için ek dersler vermek zorunda kaldık.
— Okul işe yaradı mı?
- Evet kesinlikle. Onun sayesinde pek çok kişi test yazmaya dahil oldu ve ortalama olarak hastanede herkes otomatik testlerin ne olduğunu, nasıl yazıldığını ve nasıl başlatıldığını daha iyi anlamaya başladı. Otomasyon mühendislerinin üzerindeki yük de azaldı: Test uzmanları ve geliştiriciler neredeyse her durumda bu durumla kendileri başa çıkmaya başladıkları için artık testleri analiz etme konusunda çok daha az yardım talebi alıyoruz. Bölüm için birçok dahili avantaj var: Bazı otomasyon mühendislerinin konferanslarda sunum yapmayı başardığı sunumlar ve derslerde deneyim kazandık ve ayrıca yeni gelenler için güçlü bir dizi video ve sunum aldık.
Kendi adıma, departmanlarımız arasındaki iletişimin tamamen gülünç derecede kolay bir seviyeye basitleştirildiğini ekleyeceğim. Örneğin, artık pratikte hangi vakaları ve hangi atomiklik düzeyinde otomatikleştireceğimi düşünmeme gerek yok. Sonuç olarak, ilgili tüm taraflar sürekli büyüyen test kapsamıyla tam olarak ilgileniyorlar. Kimse başkasından imkansızı istemez.
Genel olarak ekiplerin çalışmaları üzerindeki etkisi kesinlikle olumludur. Belki bu makaleyi okuyan meslektaşlarınız da benzer bir şey yapmayı düşünüyorlardır? O zaman tavsiye basit olacaktır: Otomatik testler sizin için bir öncelikse buna değer. Daha sonra, daha karmaşık bir soru hakkında konuşacağız: Tüm tarafların maliyetleri minimum ve çıktı maksimum olacak şekilde tüm bunların mümkün olduğunca doğru bir şekilde nasıl organize edileceği.
Düzenlemeye yönelik ipuçları
Okul faydalıydı, ancak Stas'ın da itiraf ettiği gibi bazı zorluklar vardı ve bu nedenle ek dersler düzenlemek gerekiyordu. Ve yeni bir öğrenciyken, cehaletimdeki kendimi ve kendimi karşılaştırdığımda, bana göre test uzmanlarına otomatik testleri anlamalarını öğretmenin ideal yolunu oluşturmak için aşağıdaki adımları formüle ettim.
Adım 0. Bir sözlük oluşturun
Elbette bu adım sadece kalite güvencesi için gerekli değil. Ancak şunu açıkça belirtmek istiyorum: Otomasyon kod tabanı okunabilir bir biçimde tutulmalıdır. Programlama dilleri - en azından dillerve bundan sonra dalışınıza başlayabilirsiniz.
İşte öğelerin adlarını içeren bir görev görünümünün ekran görüntüsü. Görev görünümünü bir kara kutu olarak test ettiğinizi ve Selenium'u hayatınızda hiç görmediğinizi hayal edelim. Bu kod ne işe yarar?
(Spoiler - yönetici adına rest yoluyla görev siliniyor ve ardından akışta bunun kaydının olduğunu görüyoruz.)
Bu adım tek başına QAA ve QA dillerini birbirine yaklaştırıyor. Otomasyon ekiplerinin bir çalıştırmanın sonuçlarını açıklaması daha kolaydır; manuel test uzmanlarının vaka oluşturmak için daha az çaba harcaması gerekir: vakalar daha az ayrıntılı hale getirilebilir. Yine de herkes birbirini anlıyor. Kazançlarımızı asıl eğitim başlamadan önce bile aldık.
1. Adım. İfadeleri tekrarlayın
Dil konusunda paralelliğe devam edelim. Çocukken konuşmayı öğrenirken etimoloji ve anlambilimden yola çıkmayız. “Anne”, “bir oyuncak al” ifadesini tekrarlıyoruz, ancak bu kelimelerin hemen Proto-Hint-Avrupa köklerine girmiyoruz. İşte burada: İşe yarayan bir şey yazmaya çalışmadan otomatik testlerin nasıl çalıştığının teknik özelliklerinin derinliklerine dalmanın hiçbir anlamı yok.
Biraz mantığa aykırı geliyor ama işe yarıyor.
İlk derste otomatik testlerin doğrudan nasıl yazılacağına dair temel vermekte fayda var. Geliştirme ortamının (benim durumumda Intellij IDEA) kurulmasına yardımcı oluyoruz, mevcut adımları kullanarak mevcut bir sınıfta başka bir yöntem yazmak için gerekli olan minimum dil kurallarını açıklıyoruz. Onlarla bir veya iki test yazıyoruz ve onlara ödev veriyoruz, bunu şu şekilde biçimlendireceğim: ana daldan ayrılan bir dal, ancak ondan birkaç test kaldırıldı. Sadece açıklamaları kaldı. Testçilerden bu testleri geri yüklemelerini istiyoruz (tabii ki show diff aracılığıyla değil).
Sonuç olarak, dinleyen ve her şeyi yapan kişi şunları yapabilecektir:
- geliştirme ortamı arayüzüyle çalışmayı öğrenin: dallar, kısayol tuşları, taahhütler ve itmeler oluşturma;
- dilin ve sınıfların yapısının temelleri konusunda uzmanlaşın: enjeksiyonların nereye ekleneceği ve nereye içe aktarılacağı, ek açıklamalara neden ihtiyaç duyulduğu ve adımların yanı sıra burada ne tür sembollerin bulunduğu;
- eylem, bekle ve kontrol et, neyin nerede kullanılacağı arasındaki farkı anlayın;
- Otomatik testler ile manuel kontroller arasındaki farka dikkat edin: Otomatik testlerde, arayüz aracılığıyla eylemler gerçekleştirmek yerine bir veya başka bir işleyiciyi çekebilirsiniz. Örneğin, bir görev görünümünü açmak, girişi seçmek, metni yazmak ve Gönder düğmesine tıklamak yerine doğrudan arka uca bir yorum gönderin;
- Bir sonraki adımda cevaplanacak soruları formüle edin.
Son nokta çok önemli. Bu cevaplar kolaylıkla önceden verilebilir, ancak formüle edilmemiş sorular olmadan verilen cevapların hatırlanmaması ve en sonunda ihtiyaç duyulduğunda kullanılmaması önemli bir öğretim ilkesidir.
Bu sırada QA ekibinden bir otomasyon mühendisinin ona savaşta birkaç test yazma görevi vermesi ve şubesine alt taahhütte bulunmasına izin vermesi ideal olurdu.
Ne verilmemeli:
- yalnızca şubelerle bağımsız olarak çalışırken gerekli olacak, geliştirme ortamının ve programlama dilinin işlevselliği hakkında daha derinlemesine bilgi. Hatırlanmayacak, iki üç kere anlatmak zorunda kalacaksınız ama biz otomasyon mühendislerinin zamanına değer veriyoruz değil mi? Örnekler: çakışmaları çözme, git'e dosya ekleme, sıfırdan sınıflar oluşturma, bağımlılıklarla çalışma;
- xpath ile ilgili her şey. Cidden. Bunu ayrı ayrı, bir kez ve çok konsantre bir şekilde konuşmanız gerekiyor.
Adım 2. Dilbilgisine daha yakından bakmak
0. adımdaki görev görünümü ekran görüntüsünü hatırlayalım. checkCommentWithTextExists adında bir adımımız var. Testçimiz bu adımın ne yaptığını zaten anlıyor ve adımın içine bakıp onu biraz ayrıştırabiliriz.
Ve içeride aşağıdakiler var:
onCommentBlock(userName).comment(expectedText).should(displayed());onCommentBlock nerede
onCommonStreamPanel().commentBlock(userName);Artık "oyuncak al" demeyi değil, "üstten üçüncü raftaki mavi dolapta bulunan Detsky Mir mağazasından oyuncak al" demeyi öğreniyoruz. Daha büyük öğelerden (akış -> belirli bir kişiden gelen yorumları içeren blok -> bu bloğun belirtilen metnin bulunduğu kısmı) bir öğeye sırayla işaret ettiğimizi açıklamak gerekir.
Hayır, hala xpath hakkında konuşmanın zamanı değil. Tüm bu talimatların kendileri tarafından anlatıldığını ve mirasın onlardan geçtiğini kısaca belirtin. Ancak tüm bu eşleştiriciler ve garsonlar hakkında konuşmamız gerekiyor; bunlar özellikle bu adımla ilgilidir ve olup biteni anlamak için gereklidir. Ancak aşırı yükleme yapmayın: öğrenciniz daha sonra daha karmaşık iddiaları kendi başına inceleyebilir. Büyük olasılıkla, waitUntil, display();, asset();, not(); yeterli olmalıdır.
Ödevi açıktır: belirli sayıda test için gerekli olan çeşitli adımların içeriğinin kaldırıldığı bir dal. Test uzmanlarının bunları geri yüklemesine ve çalışmanın yeniden yeşil hale gelmesine izin verin.
Ek olarak, test ekibinin çalışmalarında sadece yeni özellikler değil, aynı zamanda bazı hata düzeltmeleri de varsa, kendisinden bu hatalara yönelik testleri hemen yazmasını ve yayınlamasını isteyebilirsiniz. Büyük olasılıkla, tüm unsurlar zaten açıklanmıştır; yalnızca birkaç adım eksik olabilir. Bu mükemmel bir egzersiz olacak.
Adım 3. Tam daldırma
Doğrudan görevlerini yerine getirmeye devam edecek bir test uzmanı için mümkün olduğu kadar eksiksiz. Son olarak xpath’tan bahsetmemiz gerekiyor.
Öncelikle tüm bu onCommentBlock ve yorumların onlar tarafından tanımlandığını açıkça belirtelim.
Toplam:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"Hikâyenin sırası çok önemlidir. Öncelikle mevcut herhangi bir xpath'i alıyoruz ve elementler sekmesinin nasıl tek bir element içerdiğini gösteriyoruz. Daha sonra yapıdan bahsedeceğiz: WebElement'i ne zaman kullanmanız gerektiğinde ve yeni bir öğe için ayrı bir dosya oluşturmanız gerektiğinde. Bu, mirası daha iyi anlamanızı sağlayacaktır.
Tek bir öğenin görev görünümünün tamamı olduğu, bir alt öğe içerdiği - bir alt öğe içeren akışın tamamı - ayrı bir yorum vb. olduğu açıkça belirtilmelidir. Alt öğeler, hem sayfada hem de otomatik test çerçevesinin yapısında ana öğelerin içindedir.
Bu noktada izleyicinin nasıl miras alındığını ve onCommentBlock'ta noktadan sonra nelerin girilebileceğini iyice anlamış olması gerekir. Bu noktada tüm operatörleri açıklıyoruz: /, //, ., [] vb. Kullanımla ilgili bilgileri yüke ekliyoruz @class ve diğer gerekli şeyler.
Öğrenciler xpath'i bu şekilde nasıl çevireceklerini anlamalıdır. Birleştirmek için - bu doğru, ev ödevi. Öğelerin açıklamalarını sileriz, testlerin çalışmasını geri yüklemelerine izin veririz.
Neden bu özel yol?
Bir kişiye karmaşık bilgilerle aşırı yüklenmemeliyiz, ancak her şeyi bir kerede açıklamalıyız ve bu zor bir ikilemdir. Bu yol, dinleyicilerin önce soru sormasını, bir şeyi anlamamasını, hemen ardından cevap vermesini sağlayacak. Mimarinin tamamı hakkında konuşursak, adımlar veya xpath konusu analiz edildiğinde, bunun en önemli kısımları anlaşılmazlıkları nedeniyle çoktan unutulmuş olacaktır.
Ancak bazılarınız muhtemelen sürecin nasıl daha da optimize edilebileceğine dair deneyimlerinizi paylaşabilecektir. Yorumlarda benzer önerileri okumaktan mutluluk duyacağım!
Kaynak: habr.com