Neden testçiler için bir hackathon düzenledik?

Bu makale bizim gibi test alanında uygun bir uzman seçme sorunuyla karşı karşıya kalanların ilgisini çekecektir.

İşin tuhafı, ülkemizde bilişim şirketlerinin sayısının artmasıyla birlikte yalnızca değerli programcıların sayısı artıyor, test uzmanlarının sayısı artmıyor. Pek çok insan bu mesleğe girmek için can atıyor, ancak pek çoğu bunun anlamını anlamıyor.
Neden testçiler için bir hackathon düzenledik?
Tüm BT şirketleri adına konuşamam ancak KG/KK rolünü kalite uzmanlarımıza atadık. Geliştirme ekibinin bir parçasıdırlar ve araştırmadan yeni bir sürümün yayınlanmasına kadar geliştirmenin tüm aşamalarına katılırlar.

Ekipteki bir test uzmanı, planlama aşamasında bile bir kullanıcı hikayesini kabul etmek için tüm işlevsel ve işlevsel olmayan gereksinimleri düşünmelidir. Programcılar kadar ürünün operasyonel özelliklerini de anlamalı, hatta daha iyi anlamalı ve ekibin planlama aşamasında bile yanlış kararlar vermemesine yardımcı olmalıdır. Test uzmanının, uygulanan işlevselliğin nasıl çalışacağı ve ne gibi tuzaklar olabileceği konusunda net bir anlayışa sahip olması gerekir. Test uzmanlarımız test planlarını ve test senaryolarını kendileri oluşturur ve gerekli tüm test tezgahlarını hazırlar. Maymun tıklayıcısı gibi hazır bir spesifikasyona göre test yapmak bizim seçeneğimiz değil. Ekip içinde çalışarak değerli bir ürünün piyasaya sürülmesine yardımcı olmalı ve bir şeyler ters giderse alarmı zamanında çalmalıdır.

Test kullanıcıları ararken karşılaştığımız şeyler

Birçok özgeçmişin incelenmesi aşamasında, bize uygun deneyime sahip uzmanların olduğu ve ekibimiz için bir test uzmanı seçiminde herhangi bir sorun yaşanmayacağı görülüyordu. Ancak, kişisel toplantılar sırasında, aslında bilgi teknolojisi dünyasından oldukça uzak olan adaylarla giderek daha fazla karşılaştık (örneğin, bir tarayıcı ile bir web sunucusu arasındaki etkileşimin ilkelerini, güvenliğin temellerini, ilişkisel ve ilişkisel olmayan şeyleri anlatamayanlar). ilişkisel veritabanları, sanallaştırma ve konteynerleştirme hakkında hiçbir fikirleri yoktu), ancak aynı zamanda kendilerini Kıdemli QA düzeyinde değerlendirdiler. Onlarca görüşme yaptıktan sonra bölgede bize uygun uzman sayısının yok denecek kadar az olduğu sonucuna vardık.

Daha sonra sizlere o uzun zamandır beklenen kaliteli dövüşçüleri bulmak için hangi adımları attığımızı ve ne gibi hatalara bastığımızı anlatacağım.

Durumu nasıl düzeltmeye çalıştık?

Hazır uzman bulmaktan kendimizi tükettikten sonra yakındaki bölgeleri hedeflemeye başladık:

  1. Pek çok "bırak" insanı arasından güçlü uzmanlar geliştirebileceğimiz kişileri belirlemek için değerlendirme uygulamalarını uygulamaya çalıştık.

    Yaklaşık olarak aynı bilgi düzeyine sahip bir grup potansiyel adaydan görevleri tamamlamalarını istedik. Düşünce süreçlerini gözlemleyerek en umut verici adayı belirlemeye çalıştık.

    Özellikle dikkati, teknolojinin yeteneklerini ve çok kültürlülüğün özelliklerini anlama becerisini test etmek için görevler bulduk:

    Neden testçiler için bir hackathon düzenledik?
    Neden testçiler için bir hackathon düzenledik?

  2. Mevcut kontenjan içerisinde meslek anlayışının sınırlarını genişletmek amacıyla test uzmanlarıyla buluşmalar gerçekleştirdik.

    Size her biri hakkında biraz bilgi vereceğim.

    Ufa Yazılım Kalite Güvence ve Test Buluşması #1, mesleğe önem verenleri bir araya getirmek ve aynı zamanda halkın onlara iletmek istediklerimizle ilgilenip ilgilenmeyeceğini anlamak için yaptığımız ilk girişimdir. Temel olarak raporlarımız, testçi olmaya karar verdiyseniz nereden başlamanın daha iyi olacağıyla ilgiliydi. Yeni başlayanların gözlerini açmasına ve testlere bir yetişkin gibi bakmasına yardımcı olun. Acemi testçilerin mesleğe katılmak için atması gereken adımları konuştuk. Kalitenin ne olduğu ve gerçek koşullarda buna nasıl ulaşılacağı hakkında. Ayrıca otomatik test nedir ve nerede kullanılması daha uygundur.

    Neden testçiler için bir hackathon düzenledik?

    Daha sonra 1-2 ay arayla iki buluşma daha yaptık. Zaten iki kat daha fazla katılımcı vardı. “Ufa Yazılım Kalite Güvencesi ve Test Buluşması #2”de konuyu daha da derinlemesine inceledik. Hata takip sistemlerinden, UI/UX testlerinden bahsettiler, Docker ve Ansible'a değindiler, ayrıca geliştirici ile testçi arasındaki olası anlaşmazlıklardan ve bunları çözmenin yollarından bahsettiler.

    Üçüncü toplantımız, "Ufa Yazılım Kalite Güvencesi ve Test Buluşması #3" dolaylı olarak test uzmanlarının çalışmalarıyla ilgiliydi ancak programcılara teknik ve organizasyonel görevlerini zamanında hatırlatmak açısından faydalıydı: yük testi, e2e testi, otomatik testte Selenyum, web uygulaması güvenlik açıkları .

    Bunca zamandır etkinliklerimizde yayınlarda normal ışık ve sesin nasıl oluşturulacağını öğreniyorduk:

    → Testte ilk adımlar – Ufa Yazılım Kalite Güvencesi ve Test Buluşması #1
    → UI/UX testi – Ufa Yazılım Kalite Güvencesi ve Test Buluşması #2
    → Güvenlik testi, yük testi ve otomatik test – Ufa QA ve Test Buluşması #3

  3. Ve sonunda testçiler için bir hackathon düzenlemeye karar verdik

Testçiler için hackathon'u nasıl hazırladık ve gerçekleştirdik?

Başlangıç ​​​​olarak bunun ne tür bir "canavar" olduğunu ve genellikle nasıl yapıldığını anlamaya çalıştık. Anlaşıldığı üzere, Rusya Federasyonu'nda bu tür etkinlikler pek fazla yapılmadı ve fikirleri ödünç alacak hiçbir yer yok. İkincisi, ilk bakışta şüpheli görünen bir olaya hemen çok fazla kaynak yatırmak istemedim. Bu nedenle, tüm QA çalışma döngüsü için değil, bireysel aşamalar için kısa mini hackathonlar yapmaya karar verdik.

Başlıca baş ağrımız, yerel test uzmanlarının net test haritaları oluşturma konusundaki pratik eksikliğidir. Uygulama öncesi kullanıcı hikayelerini araştırmaya ve işlevsel ve işlevsel olmayan gereksinimler, UI/UX, güvenlik, iş yükleri ve yoğun yüklere ilişkin geliştiriciler için açık olan kabul kriterleri oluşturmaya zaman harcamazlar. Bu nedenle, ilk kez işlerinin en ilginç ve yaratıcı kısmını - proje öncesi araştırma sırasında analiz ve gereksinimlerin oluşturulması - gözden geçirmeye karar verdik.

Potansiyel katılımcı sayısını tahmin ettik ve MVP sürümleri için en az 5 birikime, 5 ürüne ve ürün sahibi olarak hareket edecek, iş ihtiyaçlarını deşifre edecek ve kısıtlamalar konusunda karar verecek 5 kişiye ihtiyacımız olduğuna karar verdik.

İşte elimizdekiler: hackathon için birikmiş işler.

Ana fikir, katılımcıların günlük çalışmalarından mümkün olduğu kadar uzak konular bulmak ve onlara yaratıcı bir hayal gücü alanı sağlamaktı.

Neden testçiler için bir hackathon düzenledik?

Neden testçiler için bir hackathon düzenledik?

Hangi hataları yaptık ve neyi daha iyi yapabiliriz?

Satış görevlilerinin ve alt düzey yöneticilerin işe alınması alanında çok popüler olan değerlendirme uygulamalarının kullanılması büyük miktarda çaba gerektirdi, ancak her katılımcıya yeterince dikkat etmemize ve yeteneklerini değerlendirmemize izin vermedi. Genel olarak, bu seçim seçeneği şirketin olumsuz bir imajını yaratır, çünkü pek çok insan yetersiz geri bildirim alır ve daha sonra kendilerinde ve başkalarında işverenin zulmünün etkisini yaratır (BT topluluklarında iletişim çok gelişmiştir). Sonuç olarak, elimizde kelimenin tam anlamıyla çok uzak bir geleceğe sahip iki potansiyel aday kaldı.

Buluşmalar iyi bir şeydir. Geniş bir detaylandırma temeli oluşturulur ve katılımcıların genel seviyesi artar. Şirket pazarda giderek daha tanınır hale geliyor. Ancak bu tür girişimlerin emek yoğunluğu az değildir. Buluşmaların yılda yaklaşık 700-800 adam-saat süreceğini açıkça anlamalısınız.

Test hackathon'una gelince. Bu tür etkinlikler henüz sıkıcı hale gelmedi çünkü geliştiricilere yönelik hackathonların aksine çok daha az sıklıkta yapılıyorlar. Bu fikrin avantajı, rahat bir şekilde büyük miktarda pratik bilgi alışverişinde bulunabilmeniz ve her katılımcının seviyesini oldukça doğru bir şekilde belirleyebilmenizdir.

Etkinliğin sonuçlarını analiz ettiğimizde pek çok hata yaptığımızı fark ettik:

  1. En affedilmez hata 4-5 saatin bize yeteceğine inanmaktı. Sonuç olarak, birikimlere yalnızca giriş ve alışma neredeyse 2 saat sürdü.
    Başlangıç ​​aşamasında ürün sahipleriyle çalışmak ve konu alanına dalmak da aynı süreyi aldı. Dolayısıyla kalan süre, test haritalarının kapsamlı bir şekilde geliştirilmesi için açıkça yeterli değildi.
  2. Zaten gece olduğundan her haritayla ilgili ayrıntılı geri bildirim için yeterli zaman ve enerji yoktu. Bu nedenle, bu bölümde açıkça başarısız olduk, ancak başlangıçta hackathonun en değerlisi olmayı amaçlamıştık.
  3. Gelişim kalitesini, tüm katılımcıların basit bir oyu ile değerlendirmeye karar verdik ve her takıma en yüksek kalitede çalışma için verebilecekleri 3 oy ayırdık. Belki bir jüri düzenlemek daha iyi olur.

Neyi başardın?

Sorunumuzu kısmen çözdük ve artık 4 geliştirme ekibinin arkasını koruyan 4 cesur, yakışıklı adam bizim için çalışıyor. Potansiyel güçlü adaylardan oluşan önemli bir havuz ve şehrin kalite güvence topluluğunun seviyesindeki somut değişiklikler henüz fark edilmedi. Ancak bazı ilerlemeler var ve bu sevinmekten başka bir şey olamaz.

Kaynak: habr.com

Yorum ekle