“Otomasyon Kolay” Zihniyetle Nasıl Başa Çıkılır?

Başlık her şeyi söylüyor. Şirketimizdeki bazı çalışanlar, otomatik testlerin "kolay" olduğuna ve COM ve UI testlerinin paketlerini yazmanın "bir gün sürmesi" gerektiğine inanmaktadır. Buna karşı ne yapılabilir?

Not: Otomasyonun nasıl teşvik edileceğini sormuyorum. Sorun bu değil. Otomatik testler ve süreçler burada sürekli olarak teşvik ediliyor ve talep ediliyor. Sorun şu ki, bazı bireyler otomasyonun "kolay" veya "hızlı" olmadığını anlamıyorlar.

Bir dahaki sefere bir istek aldığınızda otomasyon sürecinin çoğunu zamana bölmeye çalışın. Sanırım metin alanı veya düğmeye basmak için 5 dakika sürdüğünü fark ettiklerinde, ne kadar sürdüğünü fark etmeye başlıyorlar.

Örneğin, belki de bu kadar uzun sürmesi, alanlar arasında karşılıklı bağımlılık getirmeye başlamasıdır: örneğin, yalnızca bu doldurulursa ilerlemelerine izin verin, ancak bu değilse, devam etmeyin.

Onları NEDEN bu kadar uzun sürdüğü konusunda eğitmeye çalışın, ama “öğrenme” süreci boyunca kaybettiğiniz kadar değil.

Rollerimde, özellikle geliştirme projelerinde birçok "x kolay" insanla karşılaştım. Aklımda bunun üç nedeni var:

1) Ne hakkında konuştuklarını gerçekten anlamıyorlar ama onlar gibi konuşmayı çok seviyorlar.

2) Birkaç kitap okudular ve ne hakkında konuştuklarını bildiklerini düşünüyorlar

3) Son olarak insanlar bir bilgisayarın testi hızlı yaptığını, çünkü bilgisayarlar hızlı olduğunu varsaymaktadır.

Bununla mücadele etmenin tek kesin yolu, kullanıcıları düzenli olarak meşgul etmektir, projeler için iletişim stratejileri anahtardır, teknik olmayan kullanıcılara otomatik testlerin giriş ve çıkışlarını açıklamak boşuna olacaktır, ancak onları ilgili süreçlerden haberdar edecektir. yararlı olabilir. Bunu dokümantasyon, atölye çalışmaları veya bir sonraki geçişinizde arkadaşça bir sohbet yoluyla yapabilirsiniz.

Hatta bu "x kolay" insanların en yüksek sesle BA bekliyorum ve sadece bir gün için onları aşağı bölüm davet, ya onlar ne yapacağınız hakkında daha fazla anlayış anlayarak yatar düşünerek "Tanrım neden bahsettiğimi gerçekten bilmiyorum, yanıldığımı düşünüyorum" diye düşünerek.

Yazılım işleri otomatik hale getirme işidir.

Sıkıcı, tekrarlayan ve emek yoğun işleri bizim için kolaylaştırmak için yazılım yazıyoruz. Rapor oluşturmayı, veri toplamayı, başkalarıyla iletişim kurmayı vb. Otomatikleştirmek için yazılım yazıyoruz. Otomatik testler yazmak, diğer yazılımlarımızın beklediğimiz şekilde çalıştığından emin olmak için gerçekten yazılım yazmaktır.

İş arkadaşlarınız yazma yazılımının zor olduğunu ve zaman aldığını anlıyorsa, onlara daha fazla yazılım yazmanın zor ve zaman alması gerektiğini göstermek oldukça kolay olmalıdır. Otomasyonun tüm avantajlarını ücretsiz olarak almak güzel olurdu, ancak her zaman olduğu gibi, faydaları daha sonra almak için işi ön plana çıkarmalıyız.

Eğer bunu anlamıyorlarsa, onlara bunları öğretmek veya özgeçmişinizi parlatmak için çalışmanız gerekir.

Çoğu çalışan zamanlarını şirketin "ön" (müşteri-patron-paydaş-karşı karşıya) bölümünde veya "geri" ("gerçek" işin yapıldığı yerde) geçirir. Bu iki işlev farklıdır, neredeyse zıttır. (Ve her ikisinde de çok az insan çalıştı). Sonuç olarak, iki grup arasında sıklıkla yanlış anlaşılmalar olur.

Örneğin "ön" insanları eğitmenin en iyi yolu, bir ya da birkaçının bir gününü "sırtında" geçirmektir. "Hayatının bir günü" nü tamamlarlarsa, bir günde neler yapılabileceği ve otomatik testlerin yapılmasının neden daha fazla zaman ve çaba gerektirdiği hakkında daha gerçekçi bir fikre sahip olacaklardı. Benzer şekilde, "geri" insanlar "cephede" bir iki gün yararlanabilirler.

"Nasıl Zengin Olunur?" Bölümünde John Paul Getty (zamanının bir kralı) böyle bir “çapraz eğitimi” savundu. Ona göre, ürünün üretildiği montaj hattında zaman geçirmiş olan bir satıcı satış yapmaktan çok daha iyi bir iş çıkarır ve aynı şekilde müşterilerle bir gün geçiren bir mühendis "hata ayıklama" konusunda daha iyi bir iş çıkarırdı.

Sorun şu ki, bazı bireyler otomasyonun "kolay" veya "hızlı" olmadığını anlamıyorlar.

Buradaki öncülünüze katılmıyorum.

Birim testi, entegrasyon testi veya kullanıcı arayüzü testi olsun, otomatik testin büyük bir savunucusuyum. Otomatik testler uygulamak için birçok harika araç vardır.

Otomatik test ile manuel test karşılaştırmasını aşağıdaki örneğe göre karşılaştıralım:

Bir web uygulamasında, bir tarayıcı kullanarak mevcut bir kullanıcının "Parolayı Değiştir" işlevini test edin.

Manuel test :

• Web uygulamasını başlatın
• Tarayıcıyı aç
• Lanet olsun, bir hata var. Neden? Oh, veritabanını başlatmayı unuttum!
• Tamam, web uygulamasını kapat
• Veritabanını başlat
• Web uygulamasını başlatın
• Tarayıcıyı yenile
• Hmm, tekrar test kullanıcılarımızın şifresi neydi?
• Veritabanına göz atma
• Oh, kullanıcı tablosu boş! Yeni bir kullanıcı oluşturmam gerekiyor.
• Web uygulamasına yeni bir kullanıcı kaydedin: Kullanıcı adı, şifre, e-posta adresi girme
• Neden yeni kullanıcımla giriş yapamıyorum? Oh, e-postadaki onay bağlantısını tıklamam gerekiyor!
• Kullanıcıya "test@example.com" gibi bir e-posta verdim. Şimdi veritabanına gidip "aktif" sütununu "Evet" olarak ayarlayalım.
• Oturum aç. Bu sefer işe yarıyor!
• Hmm, tekrar ne test etmek istedim ...?

Kolay? Pek sayılmaz. Bu süreçte birçok olası tuzak var.

Hızlı? Hayır. Manuel çalışma zaman alır.

Şimdi otomatik bir test yazmaya çalışalım :

• Veritabanını ve web sunucusunu otomatik olarak başlatmak için programlama dilimiz için araçlar bulmamız gerekir. Araştırma ve uygulama zaman alır.
• Test başladığında veritabanının temiz durumda olması gerekir. Komut dosyaları oluşturmak zaman alır.
• Testi yazmamız gerekiyor. Bir kullanıcıya ihtiyacımız olduğundan, testimiz için yeni bir tane kaydetmemiz gerekiyor. Zaman alır.
• Son olarak, test etmek istediğimizi yazabiliriz: Kullanıcının şifresini değiştirme. Tarayıcı test aracımızla bu, önceki görevlere kıyasla oldukça hızlı bir şekilde yapılır.

Kolay? Hayır! Testlerimizde araçları araştırmamız, uygulamamız, bazı hataları düzeltmemiz gerekiyordu.

Hızlı? Hayır! Manuel test yapmaktan daha uzun sürer.

Ancak, burada büyük bir fark var: Gelecekteki testler için, sadece testin kendisini , listedeki son mermi noktasını yazmanız gerekir - ki bu karşılaştırılabilir hızlı bir şekilde yapılır. Tüm araştırmalar ve init-scriptlerin daha ileri testler için yapılması gerekmez.

Testi yazdıktan sonra kolayca başlatabilirsiniz. Birkaç saniye içinde (veya veritabanının ve web uygulamasının başlatılması uzun sürüyorsa, birkaç dakika içinde) "Parolayı değiştir" yordamının çalışıp çalışmadığını görürsünüz. Bir hata varsa, düzeltin ve testi tekrar çalıştırın - hatanın düzeltilip giderilmediğini hemen göreceksiniz. Hızlı ve kolay .

Otomatik testlerin yazılması ilk etapta ne kolay ne de hızlıdır, ancak bunları uygulamak kolaydır.

Ve bu, yatırılan zamanın geri geldiği noktadır.

Genel olarak test etmek kolay değildir ve olmamalıdır. Boeing veya Mercedes, ürünlerini olduğu gibi titizlikle test etmediyse, ya davalar nedeniyle iflas ederler ya da bu tür düşük kaliteli ürünler satmak için işten çıkarlardı. Direksiyon simidinin parçalara düşebileceğini veya düşmeyeceğini bilerek, saatte 70 mil hızla araba sürer misiniz?

Bu insanların kim olduğunu veya nedenlerini anlamadan zihniyetle başa çıkmanın yollarını önermek çok zordur. Çoğu yönetici ve yönetmen maliyetleri düşünür ve üretilene göre değerlendirilir. Bu ölçütleri kullanmak, testlerde zaman harcamalarını haklı göstermelerini zorlaştırır. Bu sizin için durum buysa, bu görevi uzun vadede faydalı olarak sunmanın yollarını bulmanız gerekecektir, ki bu elbette öyle.

Yazılım somut olmadığı için, inşa etmediğimiz sistemlerin etkilerini düşünmeden kurtulabileceğimiz anlamına gelmez. Eminim Amazon otomatik testlere sahiptir ve orada web sitelerinin / hizmetlerinin maliyet sonuçlarının başarısız olduğunu çok iyi bilen insanlar vardır.

2 +2 = 4, herkesin anladığı en basit kodlardan biridir; Ve nasıl kolayca anlaşıldığını görebilirsiniz. Ancak bu onun “kolay” bir denklem olduğu anlamına gelmez. Basit denkleme ulaşmak için gereken soyutlama seviyesi oldukça karmaşıktır. Yazılım ve yazılım test metodolojileri için de aynı şey geçerlidir. Bir parça kod gerektiren soyutlama düzeyi çok iş gerektirir.

İyi bir uygulamanın sınıfları ve nesneleri yeniden kullanmasına yol açtığı doğrudur, ancak eşit olarak, bu duruma ulaşmak için zaman ve çaba harcamak gerekir .

Bu sorunun iki yanı var.

Sizin tarafınızda, iyi bir iş yaptığınızı ve "Otomasyon kolaydır" grubunun ne hakkında konuştuklarını bilmediğini düşünüyor görünüyorsunuz.

Onların tarafında, söylediklerinizden, otomatik testlerin (görüşlerine göre) üretilmesi uzun zaman aldığını görüyorlar.

Bu mesafeden, devam etmek zorunda olduğumuz azıyla kimin “doğru” olduğunu ya da herhangi birinin “doğru” olup olmadığını bilmiyoruz.

Otomasyonla nasıl başa çıkılacağı kolay zihniyet

Onlarla konuş. Dürüst olmak gerekirse, nasıl daha iyi yapılabileceği konusunda fikirlerini isteyin. Onları meşgul edin ve dahil edin. Gerçekten olumlu bir şeyleri olup olmadığını öğrenmenin tek yolu budur. Belki yapmak için bazı değerli katkıları var ve bir kazan / kazan elde edebilirsiniz.

Programlama ve otomatik testin nasıl çalıştığı konusunda gerçek bir fikirleri veya üretkenliği nasıl artıracağına dair gerçekçi fikirleri yoksa, onları olumlu bir şekilde meşgul ettikten sonra, nasıl yapıldığını ve zamanın nereye gittiğini gösterebilirsiniz. Alçakgönüllü ve olumlu olun, onlara katkıları / fikirleri için teşekkür edin. Ne söylediklerini düşünün: belki de önerileri sizin için farklı bir düşünme biçimini tetikler. Eğer öyleyse, onlara geri bildirimde bulunun. Mütevazi ve pozitif olarak bunu bir kazan / kazan da yapabilirsiniz.

Onlarla konuşmadan önce testlerinizi nasıl geliştirdiğinizi, çalıştıracağınızı ve yönettiğinizi düşünün. Hangi çerçeveleri kullanıyorsunuz? Daha iyi olabilecek başkaları var mı? Uyarladığınız "standart" kazan plakası var mı? Testlerin oluşturulması daha otomatik olabilir mi? Seni geride tutan ne?