YerbatQA – moja historia o budowaniu społeczności QA w organizacji IT

Wstęp

W tym poście chciałem podzielić się z Tobą historią mojej inicjatywy o nazwie YerbatQA. Ma ona na celu budowanie społeczności, wymianę wiedzy i doświadczeń dla QA w firmie, w której pracuję.

W tym wpisie dowiesz się jak wpadłem na ten pomysł, jak podszedłem do jego realizacji i jaki finalnie efekt otrzymałem. Opisuję w szczegółach podejście do ryzyk, metryk, ich zbierania i prezentuje wyniki z ostatniego półrocza (z okresu 19.05.2022 do 05.01.2023), czyli od początku trwania tej inicjatywy.

Znajdziesz tu pomysły:

• jak można podejść do wymiany wiedzy w firmie,
• jak określać cele, ryzyka i przykładowe metryki,
• o czym warto pamiętać – jakie ustalenia odstraszają lub przyciągają słuchaczy,
• na przykładowe tematy – na końcu wpisu prezentuje skróconą listę tematów, które poruszaliśmy na naszych spotkaniach,
• jak można usprawniać procesy w całej firmie i mieć realny wpływ na jej społeczność.

Mam nadzieję, że ten wpis Cię zainspiruje i dostarczy materiały na przemyślenia 🙂

Zapraszam Cię do lektury 😉

Geneza

Przez ostatnie lata pracowałem w pełni zdalnie. Praktycznie cała interakcja z współpracownikami w projekcie i w firmie ograniczała się do rozmów przez różne komunikatory.

Pomimo tej formy, myślę, że całkiem dobrze odnajdywałem się w tych realiach. Poza oficjalnymi rozmowami, od czasu do czasu organizowaliśmy spotkania online przy kawie. Miało to na celu zastąpienie spontanicznych spotkań w kuchni lub właśnie wyjść na kawę w firmie.

Problem

W pewnym momencie zacząłem się zastanawiać nad społecznością QA w firmie. Zrozumiałem wtedy, że powoli zanikają różnego rodzaju spotkania, inicjatywy, a tym samym wymiana wiedzy i doświadczeń.

Zauważyłem również często pojawiające się pytania w kontekście wiedzy i rozwoju QA:

• do kogo udać się z danym problemem?
• jak wyglądają możliwości rozwoju?
• jak zgłaszać potrzeby rozwojowe?

Duże organizacje często posiadają bogatą dokumentację i wiele postów opisujących różne aspekty działania firmy. Jednakże odnalezienie interesujących nas informacji w systemie czasem jest sporym wyzwaniem.

Dodatkowo praca zdalna nie ułatwiała kontaktu pomiędzy ludźmi. Spontaniczne spotkania w kuchni, przy obiadach lub na korytarzach zostały skutecznie ograniczone, a tym samym przepływ informacji, doświadczeń, inspiracji i porad.

Osoby zatrudnione po 2019, które zaczynały pracę w firmie od pracy zdalnej, miały dodatkowe wyzwanie, aby odnaleźć się w tej rzeczywistości.

Lean Coffee?

Z istniejących inicjatyw dla QA w organizacji mieliśmy jeszcze Lean Coffee. Z definicji są to “ustrukturyzowane, lecz pozbawione agendy spotkania. Uczestnicy zbierają się, budują agendę i rozpoczynają rozmowę. Konwersacje są ukierunkowane i produktywne, ponieważ agenda spotkania została wygenerowana demokratycznie. Również nazwa tych spotkań wywodzi się z podejścia Lean, która ma na celu jest eliminowanie strat zasobów, umiejętności ludzi oraz czasu.

W dużym uproszczeniu Lean Coffee w praktyce wygląda w następujący sposób:

• na początku przygotowujemy listę tematów,
• głosujemy na tematy, o których chcemy rozmawiać,
• wybieramy tematy o największej liczbie głosów i rozpoczynamy dyskusję,
• na każdy temat jest limit czasowy (zazwyczaj 15 minut), który można wydłużyć (np. o 7 minut),
• spotkanie trwała między 1h, a 2h.

Zauważyłem pewne problemy związane z implementacją tych spotkań:

• były organizowane nieregularnie i w dużych odstępach czasu – w ostatnich 2 latach odbyły się 3 spotkania,
• zainteresowanie było niewielkie – w spotkaniach uczestniczyło 5-10 osób, z czego tylko 2-3 osoby to byli stali bywalcy,
• głównie bazowanie na starych tematach, które były zaproponowane nawet wiele lat temu, w większości przez osoby, które już dawno temu opuściły firmę,
• często wybierane były tematy, których wszyscy chcieli posłuchać, ale brakowało osób, które mogły się wypowiedzieć szerzej,
• struktura spotkań trochę ograniczała spontaniczność i wymianę informacji,
• brakowało podsumowań, które strukuryzowałyby poruszane tematy.

Czas na nowe

Zastanawiałem się, jak można poprawić interakcje i wymianę wiedzy pomiędzy QA, jednocześnie budując społeczność wewnątrz organizacji. Chciałem też zorganizować coś w odrobinę innej formule niż wspomniane Lean Coffee.

Cele, ryzyka i założenia

Cele

Głównym wysokopoziomowym celem było:

Stworzyć warunki na wymianę wiedzy, doświadczeń i informacji – począwszy od tematów technicznych, przez ogólny rozwój, aż po różne mechanizmy firmy (z czym do kogo, sposoby awansu, możliwości rozwoju, etc.).

Postawiłem na spotkania online, których zarówno forma jak i struktura będa kształtowały się w trakcie ich trwania.

Plusem spotkań online są:

• ✅możliwość dołączenia bez względu na lokalizację,
• ✅możliwość dołączenia bez względu na stan (praca w dresie lub wcześnie rano bez kawy),
• ✅łatwość organizacji (nie potrzeba sal, rezerwacji, sprzętu, jak komputer w sali etc.).

Minusem natomiast:

• ❌gorszy kontakt z i między uczestnikami,
• ❌problemy techniczne mogą uniemożliwić uczestnictwo,
• ❌każdy z uczestników musi zapewnić sobie sprzęt (co w dobie pracy zdalnej jest niewielkim minusem),
• ❌brak kamer i kontaktu między uczestnikami przekłada się na gorsze przekazywanie informacji.

Całość miała być w założeniu prosta i lekka, dostępna dla każdego, bez względu na doświadczenie i staż pracy. Przy podejmowaniu tej decyzji rozpisałem sobie cele oraz założenia.

Następnie doprecyzowałem akcje, które przybliżą mnie do celu:

• zorganizować systematyczne spotkania, które będa odbywały się przynajmniej raz w miesiącu,
• przygotowywać podsumowanie po każdym ze spotkań, aby również osoby nieobecne mogłyby czerpać pomysły i inspiracje ze spotkań,
• wysyłać zaproszenia, linki do spotkań oraz informacje o spotkaniach na czacie.

Ryzyka

Rozpisałem ryzyka oraz zagrożenia, z jakimi będę musiał się zmierzyć:

• forma może mieć mało wspólnego z podejściem Lean, czyli spotkania mogą generować straty zasobów, głównie czasu,
• godzina, kiedy odbywają się spotkania, może wpłynąć w dużym stopniu na niską frekwencję – tutaj podjąłem ryzyko, aby spotkania zorganizować rano o 08:00, gdy w projektach jeszcze nie ma porannych spotkań (jak np. Daily Scrum)
• brak zainteresowania uczestników, co może przełożyć się na niewielką liczebność grupy, brak chętnych do dyskusji lub brak tematów,
• słaba chemia – spotkania online ograniczają interakcje z oraz między uczestnikami, a przez to całe spotkania mogą wydać się mało interesujące.

Metryki

Również postanowiłem wprowadzić metryki, które wykażą czy przybliżam się do celu i czy pojawią się jakieś zagrożenie.

Na początku założyłem sobie następujące wartości dla metryk:

• w perspektywie kwartału utrzymać średnią liczbę uczestników na poziomie:
  • limit: 8 osób
  • cel: 16 osoby
  • ideał: 32 osoby
• w perspektywie kwartału posiadać grupę X osób, które były na przynajmniej 50% spotkaniach:
  • limit: 6 osób
  • cel: 12 osoby
  • ideał: 24 osoby
• przynajmniej 50% treści (tematów, pomysłów etc.) na spotkaniach pochodzi od uczestników.

Następnie powyższe cele przekułem na konkretne założenia, które zaprezentowałem na pierwszym inauguracyjnym spotkaniu, a później na firmowym czacie zrzeszającym QA. Metryki postanowiłem głównie oprzeć na danych, które są automatycznie generowane po spotkaniach (Microsoft Teams). Tutaj zdecydowałem się zastosować odrobinę automatyzacji i skryptów, które będą mi obliczać wartości poszczególnych metryk. O metrykach i statystykach pisze dokładniej w dalszej części tego posta.

Teraz przejdźmy do konkretnych założeń spotkań, które opracowałem na podstawie wysokopoziomowych celów.

Założenia dla spotkań

Wstępne założenia prezentowały się w następujący sposób:

• realizujemy cykl spotkań – jedno na 2-3 tyg w godzinach porannych (czwartek o 08:00),
• lekkie i krótkie spotkania (30m) przy yerbie🧉 (lub kawie),
• tematy ogólnie związane z jakością i szerokopojętym rozwojem,
• brak sztywnej agendy, a w razie braków tematów, organizator zapewnia tematy do dyskusji,
• podsumowania po spotkaniach będą pojawiały się na moim blogu na shp (firmowym blogu wewnętrznym),
• spotkanie przyjmie nazwę YerbatQA 😉
• po kilku spotkaniach zdecydujemy o dalszych losach inicjatywy,
• będę osobą w pełni odpowiedzialną za organizację, dostarczanie tematów i podsumowania.

Również po głowie chodził mi pomysł na na krótkie wystąpienie Show&Tell (S&T), które byłyby częścią spotkań YerbatQA. Po 6 spotkaniach YerbatQA rozpisałem założenia dla tego typu wystąpień (które w założeniu miały być częścią YerbatQA):

• krótkie, trwające 10-15m,
• dowolny temat związany z rozwojem, z projektami czy własnymi zainteresowaniami,
• osoby chętne na prowadzenie S&T prosiłbym o zgłoszenie się do mnie – wspólnie zaplanujemy dogodny termin i harmonogram. Również z chęcią doradzę w zakresie prezentacji i organizacji wystąpienia,
• jako osoba odpowiedzialna za tę inicjatywę postanowiłem przygotować pierwszy S&T z praktyczną prezentacją testów typu Visual Testing.

Przygotowanie uczestników

Jednym ze sposobów na zapewnienie tematów i przygotowanie uczestników jest dodanie obowiązkowego przygotowania do spotkania. Przykładowo można ustalić, że każdy z uczestników przygotuje jakiś temat, który następnie omówi na spotkaniu.

To podejście mogłoby zapewnić różnorodność tematów, większe zaangażowanie i aktywizację uczestników. W teorii to brzmi wspaniale, jednak pojawiają się duże zagrożenia, które zaobserwowałem podczas innych inicjatyw, które wymuszały podobne przygotowanie uczestników. Są wśród nich:

• brak czasu, aby uczestnik przygotował jakiś temat – każdy uczestniczy w jakimś projekcie, a po godzinach nie można od nikogo wymagać przygotowania dodatkowych materiałów,
• brak pomysłu na temat do prezentacji,
• obawa przed krytyką i słabą jakością prezentacji.

Powyższe zagrożenia przekładały się na coraz mniejszą frekwencję, a w rezultacie na zaniechanie danej inicjatywy.

Chciałem, aby każdy mógł dołączyć do tych spotkań, niezależnie od doświadczenia, stażu lub wcześniejszej obecności. Jednym słowem – aby wstęp na spotkania był wolny i aby każdy mógł czerpać wiedzę i inspirację. Dlatego też na razie zrezygnowałem z wymogu, aby każdy uczestnik musiał przygotować jakiś temat na spotkania. Postawiłem tutaj na dobrowolne zgłaszanie tematów i wystąpień.

Założenia w praktyce, czyli jak wyszła realizacja spotkań YerbatQA?

Pierwsze spotkanie odbyło się 19.05.2022, drugie 15.06.2022, a każde kolejne organizowałem już cyklicznie co 2 tygodnie w czwartki o godzinie 08:00. Reasumując, dalsze podsumowanie i weryfikację wcześniejszych założeń zrealizowałem w oparciu o pół roku i 16 spotkań.

Spotkania

W praktyce ogólne założenia spotkań sprawdziły się następująco:

• ✅ realizujemy cykl spotkań – jedno na 2-3 tyg.

  Wynik: spotkania odbywają się cyklicznie co 2 tygodnie w czwartek o 08:00. Dzięki temu wystąpienie spotkań jest przewidywalne i łatwiej zaplanować cały tydzień.

• ❌✅ lekkie i krótkie spotkania (30m) przy kawie.

  Wynik: forma spotkań jest lekka – rozpoczynamy spotkanie, robimy szybką rozgrzewkę i przechodzimy do tematów technicznych/miękkich/projektowych/rozwojowych, a kamerki są opcjonalne. Natomiast limit 30 minut okazał się zbyt optymistyczny, dlatego rozszerzyłem czas trwania spotkań do 45-60 minut.

• ✅ tematy ogólnie związane z jakością i rozwojem i brak sztywnej agendy, a w razie braków tematów, organizator zapewnia tematy do dyskusji.

  Wynik: tylko S&T są zapowiadane wcześniej. Agenda samych spotkań wykluwa się w trakcie ich trwania. Nie odnotowałem problemu z tematami – dyskusje trwają nieprzerwanie przez całą godzinę. Na każde spotkanie mam w zanadrzu kilka tematów, jednakże uczestnicy przychodzą z własnymi wątkami.

• ✅ podsumowania po spotkaniach będą pojawiały się na moim blogu wewnętrznym (w systemie firmy).

  Wynik: każde spotkanie opisuje w krótkim poście na firmowym blogu wewnętrznym – opisuje poruszone tematy i dołączam linki do dodatkowych materiałów. Zbiorczy przykład takiego podsumowania znajdziecie w dalszej części tego wpisu, w sekcji Dodatki.

• ✅ po kilku spotkaniach zdecydujemy o dalszych losach inicjatywy.

  Wynik: inicjatywa się przyjęła, co widać po dość sporej liczbie uczestników, zainteresowaniu spotkaniami oraz po wielu zapytaniach (o dodatkowe materiały, podziękowania, etc.) od uczestników po spotkaniach.

Show&Tell

W praktyce ogólne założenia S&T:

• ❌krótkie – 10-15m.

  Wynik: S&T zajmowały zazwyczaj od 30-45 minut, czyli większośc danego spotkania,

• ✅ dowolny temat związany z rozwojem, zarówno z projektami i własnymi zainteresowaniami.

  Wynik: tutaj na razie tematy bardziej techniczne, ale w przyszłości nie wykluczam tematów bardziej miękkich.

Obecnie zrealizowaliśmy już 3 spotkania z S&T na następujące tematy (więcej o nich w dalszej części tego wpisu, w sekcji Dodatki):

• Visual Testing z praktycznym przykładem w Playwright
• Jak w 5m napisać własną aplikację z REST API i po co taka wiedza testerowi?
• Po co Testerowi/QA znajomość algorytmów? Jak ćwiczyć umiejętności programowania? (na przykładzie Code Kata)

Pojawiło się też kilka tematów, które są w planach (testy wydajności w Locust, własny dashboard z wynikami z Jenkinsa czy sposób realizacji Presale projektów itp.). Termin tych wystąpień będzie mocno zależał od dostępności osób, które zadeklarowały chęć prezentacji danego tematu.

Tematy na spotkania

Jednym z głównych założeń spotkań YerbatQA była wymiana wiedzy i tematy, a dokładniej tematy ogólnie związane z jakością i szerokopojętym rozwojem. Przyglądając się realizacji, na spotkaniach poruszamy zagadnienia techniczne (narzędzia, technologie, podejścia etc.), “miękkie” (procesy, psychologia etc.), związane z projektami, firmą, procesami etc. Zbiorczy zestaw tematów poruszanych na spotkaniach znajdziecie w dalszej części tego wpisu, w sekcji Dodatki.

Myślę, że pojawiające się tematy, dobrze się sprawdzają – potwierdzają to również wyniki ankiet, w których uczestnicy chwalą sobie różnorodność. Uważam, że dzięki temu każdy jest w stanie znaleźć coś ciekawego dla siebie albo zaproponować jakiś temat do dyskusji.

W feedbackach pojawiło się kilka interesujących propozycji tematów, które uwzględnię przy kolejnych spotkaniach 🙂

Podsumowania, a nagrywanie spotkań

Po kilku spotkaniach pojawiły się zapytania dotyczące nagrywania spotkań, dla osób, które nie były w stanie w danym spotkaniu uczestniczyć. Tutaj głosy były podzielone, na osoby, którym ten pomysł się spodobał i osoby, które były temu przeciwne.

Osobiście nie chciałbym nagrywać tych spotkań. Ich podstawowe założeniem były luźne rozmowy, zarówno na tematy techniczne i rozwojowe, ale z własnymi niczym nie skrępowanymi przemyśleniami, coś na zasadzie spotkań w kuchni – nagrywanie ich mogłoby zabić luz i płynność spotkań.

Nagrywanie ich wyglądałoby trochę jak przychodzenie z dyktafonem do kuchni i nagrywanie rozmów dla kolegów. Brzmi sensownie, ale wyobraźmy sobie sytuację, gdy wchodzimy do pomieszczenia, w którym trwają luźne rozmowy, następnie wyciągamy dyktafon i chcemy nagrać konwersację dla nieobecnych.

Myślę, że dyskusje mogłyby ustać, a ludzie rozeszliby się do pracy😉 Albo straciłyby mocno na naturalności i spontaniczności.

Dlatego zdecydowałem się tylko na krótkie podsumowanie w formie pisemnej. Natomiast wystąpienia S&T nagrywam, a następnie umieszczam w poście wraz z dodatkowymi materiałami (kod, linki do repozytoriów lub dokumentacji).

Statystyki

Teraz przyszedł czas na wykresy i tabele z danymi zebranymi ze spotkań 😉

Dla przypomnienia, założyłem sobie następujące wartości metryk:

• w perspektywie kwartału utrzymać średnią liczbę uczestników na poziomie:
  • limit: 8 osób
  • cel: 16 osoby
  • ideał: 32 osoby
• w perspektywie kwartału posiadać grupę X osób, które były na przynajmniej 50% spotkaniach:
  • limit: 6 osób
  • cel: 12 osoby
  • ideał: 24 osoby
• przynajmniej 50% treści (tematów, pomysłów etc.) na spotkaniach pochodzi od uczestników.

Pierwsze 2 wartości metryk (średnia liczba uczestników oraz osoby, które były na przynajmniej 50% spotkań) były łatwe do zmierzenia i określenia. Zbieranie i przetwarzanie danych odbywa w znacznym stopniu automatycznie. Dzięki temu ograniczyłem czas wymagany na te czynności, monotonię oraz możliwości pomyłki w obliczeniach.

Automatyzacja i pomiary

Spotkania mają miejsce na Microsoft Teams. Na kanale po spotkaniu dostępne jest podsumowanie w formie pliku tekstowego z danymi jak czas trwania spotkania, liczba uczestników oraz szczegółowe dane na temat każdego z obecnych. Dane te pobieram, a następnie za pomocą prostego skryptu, który napisałem w Pythonie, przetwarzam je i otrzymuje wyniki zbiorcze ze wszystkich spotkań. Wyniki następnie umieszczam w arkuszu kalkulacyjnym, w którym skonfigurowałem odpowiednie wykresy.

Jeśli chodzi o tematy i aktywność, to tutaj przez całe spotkanie notuje główne wątki, jakie się pojawiają. Przyjąłem tu bardzo prosty sposób pomiaru pochodzenia treści i aktywności:

jeśli temat został zainicjowany przez uczestnika i wywiązała się dyskusja – to go oznaczam, a później obliczam % w stosunku do wszystkich tematów.

Zdawałem sobie sprawę, że jest to niedokładny sposób oraz subiektywny. Jednak na razie przyjąłem go jako good enough.

Dzielenie się wynikami

Informacje o spotkaniu wysyłam na alias mailowy, który obecnie liczy około 130 osób (znacznej większości są to QA). Alias ten związany jest z kanałem/grupą na MS Teams, do którego dobrowolnie może dołączyć każda osoba z organizacji, bez względu na rolę. Grupa ta powstała jakiś czas temu i jeszcze nie wszyscy QA w organizacji zdecydowali się do niej dołączyć.

Harmonogram spotkań oraz liczba uczestników

Harmonogram spotkań oraz liczba uczestników:

Wykres obecności wygląda następująco:

Zawarłem na nim również wartości związane z akceptacją zaproszeń na spotkania.

Dodatkowo:

• na przynajmniej 3 spotkaniach było 28 uczestników,
• na przynajmniej 8 (50%) spotkaniach było 13 uczestników,
• średnia liczba uczestników przypadających na spotkanie – 16.1 (po potraktowaniu 2 pierwszych pomiarów jako błąd gruby – wartość ta wzrasta do 17.8),
• unikalna liczba uczestników – 64.

W dużym zaokrągleniu:

• w spotkaniach średnio bierze udział prawie 15% osób, które są w aliasie mailowym,
• przynajmniej raz na spotkaniach było około 50% osób, które są w aliasie mailowym.

Czas trwania spotkań

Poniższy wykres przedstawia czas trwania poszczególnych spotkań oraz średnią czas uczestnictwa wszystkich osób:

Liczba osób biorących udział w spotkaniach w zależności od liczby tych spotkań

Poniższy wykres przedstawia zależność pomiędzy liczbą spotkań a liczbą osób. Czyli jaka liczba osób bierze udział w spotkaniach w zależności od liczby tych spotkań.

Jak odczytywać ten wykres?

Przykładowo X=8, Y=5 oznacza, że na 8 spotkaniach było 5 osób, natomiast X=1, Y=25 oznacza, że 25 osoby uczestniczyły tylko w jednym spotkaniu.

Statystyki, a postawione cele

Zestawiając statystki z wcześniej postawionymi celami:

• w perspektywie kwartału utrzymać średnią liczbę uczestników na poziomie:
  • cel: 16 osoby
  • wartość aktualna: 16.1 osoby (po potraktowaniu 2 pierwszych pomiarów jako błąd gruby – wartość ta wzrasta do 17.8)
• w perspektywie kwartału posiadać grupę X osób, które były na przynajmniej 50% spotkaniach:
  • cel: 12 osoby
  • wartość aktualna: 13 osób
• przynajmniej 50% treści (tematów, pomysłów etc.) na spotkaniach pochodzi od uczestników
  • wartość aktualna: uśredniając myślę, że będzie to w rejonie 50%

Feedback

W trakcie trwania całego cyklu spotkań zbierałem feedback głównie na zasadzie f2f. Największą jego porcję otrzymałem na spotkaniu #16. Poprosiłem wtedy o feedback i rozesłałem do uczestników ankietę, w której anonimowo mogli wypowiedzieć się co im się najbardziej podoba oraz co by poprawili. Poniżej prezentuje część zebranych, dodatkowo zanonimizowanych odpowiedzi 😉

Co Ci się podoba na spotkaniach?

Bardzo przypadła mi do gustu forma swobodnej dyskusja, możliwość zadawania pytań i poszerzania wiedzy

Wszystkie komentarze:

• spotkania typu S&T i fakt, że są nagrywane,
• podsumowania ze spotkań, które pojawiają się na blogu wewnętrznym,
• dużo różnych i ciekawych tematów, również tych mniej technicznych (np. psychologia, zainteresowania, rozwój etc.),
• możliwość wygadania się i czasem nawet “pomarudzenia” (jako wentyl bezpieczeństwa) 😉
• częstotliwość oraz godzina chyba są optymalne,
• pojawia się sporo bardzo doświadczonych ludzi, którzy dzielą się tym co potrafią i wiedzą,
• swobodnej dyskusja, możliwość zadawania pytań i poszerzania wiedzy,
• możliwość bycia wolnym słuchaczem bez presji wypowiedzi (K: pojawiło się kilka takich odpowiedzi).

Co chciałbyś usprawnić?

Z chęcią bym posłuchała o dzieleniu się wiedzą w postaci show&tell projektowego

Wszystkie komentarze:

• dzielenie się wiedzą w postaci show&tell projektowego (o projekcie, o frameworkach, narzędziach, podejściu do testów etc.),
• eksperymenty z odrobinę późniejsza godziną (K: pojawiło się kilka takich odpowiedzi),
• więcek włączonych kamerek, aby można było rozpoznać osoby na korytarzu w biurze w przyszłości,
• lepsza moderacja i mniejsze dygresyjne odbieganie od tematów.

Jeśli chciałbyś o czymś pogadać – napisz!

Jak działania podjąć w projekcie, w którym klient nie chce płacić za QA

Wszystkie komentarze:

• tematy z zakresu BA lub UX,
• jak wyglądają zasady awansu w organizacji,
• jak wygląda rekrutacja,
• problemy, ale jakiś może konkretniejszy w stylu “jak (nie)poradziliśmy sobie z konfliktem w zespole”,
• nabywanie doświadczenia w projekcie, w którym klient nie chce płacić za QA – jak po 3 miesiącach współpracy pokazać, że warto zapłacić za QA i zostać w projekcie na dłużej? Na czym się skupić w tym czasie?

Akcje

W odpowiedziach pojawiło się słuszne pytanie:

dlaczego ludzie nie przychodzą/nie wracają na spotkania?

Podjąłem decyzję, że spróbuję poeksperymentować z godziną (drobne przesunięcie o 30m), aby zobaczyć czy wpłynie to na obecność.

Dodatkowo zacząłem przykładać większa uwagę do zbieranych i gromadzonych tematów. Skupiam się na aktualnych wydarzeniach w projektach, ze świata lub ciekawych wyzwaniach, z którymi miałem styczność.

Również przygotowałem anonimowa ankietę, która jest cały czas otwarta i każdy może zgłaszać swoje pomysły i usprawnienia.

Podsumowanie

Po zebraniu wszystkich statystyk i feedbacku, nadszedł czas na podsumowanie.

Uważam, że prowadzona przeze mnie inicjatywa okazała się sukcesem i planuję ją kontynuować. Tutaj też pragnę podziękować wszystkim osobom zaangażowanym i uczestniczącym w dyskusjach, bez których sukces nie byłby możliwy.

Dzięki Wam – uczestnikom spotkań udało się umocnić społeczność QA w organizacji. Wspólnie uczestniczymy w naturalnym przepływie informacji, wiedzy i doświadczeń.

Dzięki!🙇‍♂️

Będę dalej monitorował statystyki, aby zobaczyć jakim zainteresowaniem będzie cieszyła się YerbatQA. Wprowadzę też nowe wartości dla metryk, które pozwolą mi lepiej monitorować zainteresowanie.

Również pracuję nad otrzymanym feedbackiem i potencjalnymi usprawnieniami, które uatrakcyjnią inicjatywę YerbatQA 🙂

Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives. – William A. Foster

Tymczasem do usłyszenia w kolejnych postach!
K.

Dodatki

Dodatek 1: Tematy poruszane na spotkaniach YerbatQA

Na końcu chciałem podzielić się z Wami częścią tematów, jakie poruszaliśmy na spotkaniach. Po każdym spotkaniu publikuje posta na wewnętrznym blogu firmowym. W takim wpisie zawarłem podstawowe informacje o spotkaniach wraz z poruszanymi tematami, wnioskami, linkami i wszelkimi dodatkowymi materiałami.

Poniżej zawarłem mega streszczenie z pominięciem tematów, które dotyczą spraw firmowych albo projektowych.

Show&Tell – Jak w 5m napisać własną aplikację z REST API i po co taka wiedza testerowi?

Link do repozytorium z kodem przykładowej aplikacji z REST API:
https://github.com/jaktestowac/js-express-example-app

Aplikacja została zrealizowana w oparciu o:

• node.js – https://nodejs.org/en/
• express – https://www.npmjs.com/package/express oraz http://expressjs.com/

Zalety pisania własnej aplikacji:

• lepsze zrozumienie mechanizmów działania REST API,
• ćwiczenie umiejętności programistycznych,
• wykorzystanie aplikacji do mockowania zapytań/odpowiedzi.

Dobre praktyki i dokumentacja:

• podczas projektowania i testowania REST API należy pamiętać o spójności i zgodności z wymaganiami – tymi globalnymi (rfc2616) oraz tymi lokalnymi, czyli klienta,
• dokumentacja dotycząca HTTP i metod GET, POST etc. – https://www.rfc-editor.org/rfc/rfc2616#section-5.1.1.

Wtyczki pozwalające testować REST API z poziomu VS Code:

• REST Client – https://marketplace.visualstudio.com/items?itemName=humao.rest-client
• Thunder Client – https://www.thunderclient.com/.

Przykładowe wykorzystanie własnej aplikacji REST API:

• Aplikacja jako mock aplikacji na środowisku klienckim. Aplikacja ta nasłuchuje wiadomości na kolejce (RabbitMQ), a następnie wysyła dane na kolejną kolejkę. Bazując na odczytanych danych, mockowała informacje przesyłane dalej, na inną kolejkę.

Show&Tell – Visual Testing z praktycznym przykładem w Playwright

Link do repozytorium z kodem testów z Visual testing:
https://github.com/jaktestowac/playwright-sample-visual-testing

Czym jest Visual testing?

• https://applitools.com/blog/visual-testing/

Visual testing w różnych narzędziach:

• Playwright – https://playwright.dev/docs/test-snapshots
• Cypress – https://docs.cypress.io/guides/tooling/visual-testing

O czym należy pamiętać przy projektowaniu takich testów?

• Architektura całego frameworka i jak wkomponować VT do automatów – czasem można je podłączyć do istniejących testów e2e, a czasem lepiej zrobić osobny test suite.
• Można zastosować soft assertions – czyli asercje, które nie przerywają testu w danej chwili (patrz punkt poniżej o tego typu asercjach).
• Czasem nie warto wszystkiego testować (całej strony – narzędzia do VT pozwalają na tworzenie zrzutów elementów (np. wykresy, tabele, mapy etc).
• Referencyjne zrzuty ekranu zajmują miejsce – projekt i repozytorium może spuchnąć, gdyż domyślnie (i zazwyczaj) zrzuty ekranu są przechowywane jako dane testowe – jeśli masz bardzo dużo danych referencyjnych – Czy potrzebujesz ich wszystkich? Czy potrzebujesz testować wszystkie rozdzielczości? Jak wyglądają wymagania klienta i z czego użytkownicy korzystają najczęściej? Może jest miejsce na optymalizację – tylko dwa widoki full HD + mobile lub zmniejszenie liczby przypadków.
• Podczas porównywania screenów możemy iść w 100% zgodność, albo możemy określić liczbę pikseli, które mogą się różnić – nie ma tu reguły i najlepszego rozwiązania – czasem możemy założyć 1% błędnych pixeli, a czasem potrzebujemy 100% zgodności.
• Czas porównywania zrzutów ekranu zależy od mocy obliczeniowej, rozdzielczości (wielkości obrazu).
• Narzędzia do VT pozwalają na automatyczną aktualizację posiadanych danych referencyjnych (zdecydowanie odradzam robić to ręcznie!).
• Jeśli jest możliwość – wielowątkowość i równoległe uruchamianie testów przyspiesza otrzymanie wyników.
• Pamiętaj – wszystko zależy od kontekstu danego projektu! W jednym projekcie sprawdzi się podejście X, w innym konfiguracja Y dla VT, a w innym testy VT mogą nie mieć sensu.

Show&Tell – Po co Testerowi/QA znajomość algorytmów? Jak ćwiczyć umiejętności programowania? Na przykładzie Code Kata

Polecane serwisy:
https://www.codewars.com/
https://leetcode.com/

Zalety rozwiązywania Code Kata:

• Poprawa umiejętności programowania – Code Kata pozwala ćwiczyć i ulepszać umiejętności programowania poprzez rozwiązywanie różnorodnych zadań i problemów.
• Zwiększenie wiedzy – Code Kata umożliwia zdobywanie nowej wiedzy i umiejętności poprzez uczenie się i stosowanie różnych technik programowania oraz algorytmów.
• Poprawa efektywności – Dzięki regularnemu wykonywaniu Code Kata można poprawić swoją efektywność i szybkość programowania, co przekłada się na lepsze wyniki w pracy zawodowej.
• Zwiększenie pewności siebie – Code Kata pomaga zwiększyć pewność siebie i samodzielność w rozwiązywaniu problemów oraz umożliwia lepsze przygotowanie do rozwiązywania nowych, nieznanych wcześniej zagadnień.
• Zwiększenie zaangażowania – Code Kata to świetny sposób na zwiększenie zaangażowania i motywacji do nauki programowania, ponieważ pozwala na ciągłe doskonalenie swoich umiejętności i osiąganie postępów.

O czym trzeba pamiętać:

• Po stronie użytkownika jest odpowiedzialność za refleksje i pracę nad kodem – zadania można rozwiązać za pomocą nieoptymalnego kodu i tylko z własnej inicjatywy użytkownik popracuje nad jego jakością.
• Warto zapoznać się z serwisami i popracować z web IDE – owe IDE nie posiadają wielu udogodnień (wtyczki, lintery etc), ale pozwalają na lepsze zapoznanie się z kodem, problemem i przyzwyczajają do “niedogodności”.
• Praca i doświadczenie z web IDE może być przydatne podczas rekrutacji, gdzie wymagane jest od nas wykorzystanie własnie różnych web IDE. Wcześniejsze doświadczenie pozwoli nam na większy komfort pracy i mniejszy stres.

Ogólnie o testowaniu

Ogólnie o testowaniu:

• Soft assertions – czyli asercje, które przy błędzie nie przerywają testu od razu, a dopiero na końcu oznaczają go jako zakończony niepowodzeniem – https://practicetestautomation.com/hard-and-soft-assertions/
• Playwright soft assertions – https://playwright.dev/docs/test-assertions#soft-assertions
• Strony do testowania swoich umiejętności w pisaniu testów automatycznych – https://pwicherski.gitbook.io/testowanie-oprogramowania/gdzie-trenowac

Ogólnie ze świata IT

Gry komputerowe i popkultura:

• wywiad z Johnem Carmackiem o programowaniu, pracy, popkulturze (grach, które stworzył John – Doom, Quake itd) – John Carmack: Doom, Quake, VR, AGI, Programming, Video Games, and Rockets | Lex Fridman Podcast #309
• decino – twórca gameplayów i analiz kodu gry Doom – znajduje wiele ciekawych błędów i analizuje różne rozwiązania zawarte w silniku gry – @decino. Jak zaimplementowano zachowanie potworów?
• Jak działa animacja i efekty cząsteczkowe? Jak działa auto aim albo z czego wynika paraliż potworów? Na te tematy znajdziecie odpowiedź w nagraniach z analizą kodu – In-depth informative videos about video game mechanics and challenges.

Certyfikaty:

• Czy warto? To zależy – od celów danej osoby, od potrzeb projektu lub firmy. Podstawowe certyfikaty warto rozważyć, gdyż mogą dać nam bazową wiedzę na dane zagadnienie.
• Warto też zadać sobie pytania – czy zdobytą wiedzę będę w stanie wykorzystać w skończonym czasie?
• Przykłady certyfikatów z zakresu Usług Chmurowych:
  • AZ900
  • AWS foundation

Tematy ogólnorozwojowe

Inteligencja emocjonalna
Adam P., uczestnik spotkania, poruszył temat inteligencji emocjonalnej i istotności rozwoju w tym temacie. W artykule Inteligencja emocjonalna w pracy – dlaczego jest ważna?, w którym znajdziecie podstawowe informacje – czym jest, jakie są korzyści z jej rozwijania i przede wszystkim – jak ją rozwijąc.

Z powyższego artykułu:

Czym jest inteligencja emocjonalna?
W szerokim ujęciu inteligencja emocjonalna to zdolność do rozpoznawania, zarządzania i wykorzystywania własnych emocji oraz emocji innych osób. Oznacza to, że osoby o wysokiej inteligencji emocjonalnej potrafią łatwo rozpoznawać emocje, których same doświadczają i które przeżywają inni. Potrafią też regulować swoje emocje i wykorzystywać je do wykonywania różnych zadań i obowiązków, pomagając przy tym innym osiągnąć to samo.

Dlaczego inteligencja emocjonalna jest ważna?
Trudno przecenić znaczenie inteligencji emocjonalnej w miejscu pracy. Jak wynika z powyższej listy kompetencji, posiadanie którejkolwiek z tych umiejętności pozytywnie wpłynie na karierę zawodową pracowników na każdym poziomie: od lepszej komunikacji, przez większą produktywność, po umiejętności przywódcze.

Co więcej, wraz z postępującą globalizacją wielu firm, inteligencja emocjonalna odgrywa szczególnie istotną rolę w pracy. Wielokulturowe zespoły muszą nauczyć się wzajemnego zrozumienia, wyrażania swoich myśli i opinii oraz dostosowywania się do różnic między sobą.

Pracownicy muszą też radzić sobie w coraz bardziej złożonych stosunkach z klientami, kolegami i współpracownikami z całego świata. W związku z tym posiadanie emocjonalnej zdolności do empatii, zaangażowania i współpracy z osobami z innych grup społecznych poprawi wyniki biznesowe i efektywność pracy w sytuacjach międzykulturowych.

Narzekanie:

• Narzekanie wśród młodych osób z pasją może odebrać radość z pracy i pasję – warto się zastanowić kiedy wypowiadamy jakie słowa.
• Gdy ktoś poczuje się dotknięty narzekaniem to powinno się o tym mówić głośno – można to zrobić publicznie albo 1:1 z daną osobą.
• Trzeba umożliwić ludziom przestrzeń do narzekania i mówienia co ich boli – tu warto zachować jednak zdrowy rozsądek i moderować wątki. Warto się zastanowić co jest przyczyną narzekania, na jaką część tego mamy wpływ i co możemy z tym zrobić.
• Kluczowe jest przekierowanie energii na działanie lub inne wątki, które nas pasjonują.
  Skupić się na konkretach i dotrzeć do przyczyny problemu – wtedy łatwiej będzie znaleźć rozwiązanie.

Feedback:

• Warto przedstawiać dużo konkretów, przykładów sytuacji oraz sposobów naprawy miejsc, gdzie są niedociągnięcia.
• Sposób dawania feedbacku zależy od naszych relacji z danymi osobami i dojrzałości zespołu – gdy mamy dojrzały zespół łatwiej dawać nam bezpośredni feedback, natomiast podczas formowania zespołu musimy zachować formalną formę oceny.
• Polecam How To Reject Negative Feedback From Your Boss, gdzie znajdziecie wiele wskazówek jak podchodzić do feedbacku.

Inne

Dodatkowo na spotkaniach pojawia się wiele innych tematów powiązanych z firmą i jej procesami:

• szkolenia i inne formy rozwojowe (mentoring, kursy, etc.),
• kwestie awansowe i wymagania na danych stanowiskach,
• różne wyzwania projektowe i jak sobie z nimi poradzić,
• narzędzia i technologie używane w projektach – plusy i minusy różnych rozwiązań,
• podejście do testów – wybór strategii, planowanie procesu, patologie i sposoby ich niwelowania,
• i wiele innych.

Dodatek 2: Linki i zasoby

Dodatkowe linki i zasoby uzupełniające zagadnienia z artykułu:

• Lean Coffee – sposób na angażujące spotkania oraz Lean Coffee
• Czytelnia i recenzje książek

Krzysiek Kijas Senior Software Quality Engineer, Tech Lead, Mentor profil na LinkedIn

Z testowaniem i dbaniem o jakość oprogramowania jestem związany od 2011. Dobre podwaliny techniczne i ugruntowanie wiedzy certyfikatami pozwalają mi swobodnie pływać w tym bezkresnym oceanie technologii 😉 Na co dzień zajmuje się różnego rodzaju testami, poczynając od manualnych, eksploracyjnych, aż po tworzenie frameworków i projektowanie ich architektury. Obecnie jako Tech Lead odpowiadam za architekturę automatów w Playwright, procesy, dobre praktyki, testy na różnych poziomach (DB, UT, API, UI), CI/CD, oraz rozwój członków zespołu. Dbam o rozwój oraz potrzeby zespołu i klienta. Od wielu lat aktywnie uczestniczę w konsultacjach przy projektach różnych firm, świadcząc wsparcie m.in. poprzez mentoring, prowadzenie szkoleń oraz optymalizację procesów. Jako architekt testów pomagam zespołom zadbać o wysoką jakość oprogramowania. Moja ekspertyza obejmuje projektowanie i wdrażanie skutecznych strategii testowania, automatyzację, definiowanie wskaźników jakościowych, wdrażanie metryk. Moje zaangażowanie skupia się na doskonaleniu spełniania potrzeb klientów poprzez efektywne mentorowanie zespołów oraz zastosowanie lepiej dopasowanych narzędzi i podejść. Ciągły głód wiedzy i silna potrzeba rozwoju spowodowały, iż razem z Przemkiem stworzyliśmy inicjatywę jaktestowac.pl, która była naturalnym krokiem w mojej ewolucji. Dzięki niej, mogę realizować i rozwijać swoje pasje związane z mentoringiem oraz pomocy innym w zdobywaniu wiedzy. W wolnym czasie z pełnym poświęceniem oddaje się swoim uzależnieniom - treningom siłowym, crossfitowi, literaturze i szeroko pojętej sztuce.