Czterech na pięciu kandydatów do kontroli jakości chce nauczyć się pracować z testami automatycznymi. Nie wszystkie firmy są w stanie spełnić takie zachcianki testerów manualnych w godzinach pracy. Wrike prowadził szkołę automatyki dla pracowników i spełnił to pragnienie wielu osób. Uczestniczyłem w tej szkole właśnie jako student kontroli jakości.
Nauczyłem się pracować z Selenium i teraz samodzielnie obsługuję pewną liczbę autotestów, praktycznie bez pomocy z zewnątrz. I na podstawie wyników naszych wspólnych doświadczeń oraz osobistych wniosków spróbuję wyprowadzić sam przepis na najbardziej idealną szkołę automatyki.
Doświadczenia Wrike’a w organizowaniu szkoły
Kiedy stało się jasne, że potrzeba szkoły automatyki, jej organizacja przypadła Stasiowi Davydovowi, kierownikowi technicznemu automatyzacji. Kto inny jak nie on może wyjaśnić, dlaczego wpadli na tę inicjatywę, czy osiągnęli rezultaty i czy żałują poświęconego czasu? Oddajmy mu głos:
— W 2016 roku napisaliśmy nowy framework do autotestów i sprawiliśmy, że pisanie testów stało się łatwe: pojawiły się normalne kroki, struktura stała się znacznie bardziej zrozumiała. Wpadliśmy na pomysł: trzeba zaangażować wszystkich, którzy chcą pisać nowe testy i żeby było łatwiej je zrozumieć, stworzyliśmy cykl wykładów. Wspólnie opracowaliśmy plan tematów, każdy z przyszłych wykładowców wziął jeden dla siebie i przygotował z niego raport.
— Jakie trudności mieli uczniowie?
— Głównie oczywiście architektura. Było wiele pytań dotyczących struktury naszych testów. W odpowiedzi napisano wiele na ten temat i musieliśmy przeprowadzić dodatkowe wykłady, aby wyjaśnić bardziej szczegółowo.
— Czy szkoła się opłaciła?
- Tak, zdecydowanie. Dzięki niej w pisanie testów zaangażowało się mnóstwo osób i średnio w szpitalu wszyscy zaczęli lepiej rozumieć, czym są autotesty, jak się je pisze i jak się uruchamia. Zmniejszyło się również obciążenie inżynierów automatyków: otrzymujemy teraz wielokrotnie mniej próśb o pomoc w analizie testów, ponieważ testerzy i programiści zaczęli sobie z tym radzić sami w niemal wszystkich sytuacjach. Otóż wewnętrznych atutów dla działu jest kilka: zdobyliśmy doświadczenie w prezentacjach i wykładach, dzięki czemu niektórym automatykom udało się już wygłaszać prezentacje na konferencjach, a także otrzymaliśmy potężny zestaw filmów i prezentacji do onboardingu nowicjuszy.
Od siebie dodam, że komunikacja pomiędzy naszymi działami została uproszczona do wręcz śmiesznie prostego poziomu. Na przykład teraz praktycznie nie muszę myśleć o tym, które przypadki i na jakim poziomie atomowości zautomatyzować. Dzięki temu wszyscy zainteresowani w pełni dbają o zasięg testów, który stale rośnie. Nikt nie wymaga od innych niemożliwego.
Ogólnie wpływ na pracę zespołów jest zdecydowanie pozytywny. Być może koledzy czytający ten artykuł również myślą o zrobieniu czegoś podobnego? Wtedy rada będzie prosta: warto, jeśli testy automatyczne są dla Ciebie priorytetem. Następnie porozmawiamy o bardziej złożonym pytaniu: jak to wszystko zorganizować tak poprawnie, jak to możliwe, aby koszty wszystkich stron były minimalne, a wydajność maksymalna.
Wskazówki dotyczące organizacji
Szkoła była przydatna, ale – jak przyznał Staś – pojawiały się pewne trudności, przez co konieczne było organizowanie dodatkowych wykładów. I to właśnie jako student porównywałem siebie w niewiedzy i siebie – teraz sformułowałem następujące kroki, aby stworzyć, moim zdaniem, idealny sposób na nauczenie testerów rozumienia testów automatycznych.
Krok 0. Utwórz słownik
Oczywiście ten krok jest potrzebny nie tylko w przypadku kontroli jakości. Chcę jednak wyraźnie to podkreślić: baza kodu automatyzacji musi być przechowywana w czytelnej formie. Języki programowania – nie tylko Językii od tego momentu możesz rozpocząć nurkowanie.
Oto zrzut ekranu widoku zadań z nazwami elementów. Wyobraźmy sobie, że testujesz widok zadań jako czarną skrzynkę i nigdy w życiu nie widziałeś Selenium. Co robi ten kod?
(Spoiler - zadanie zostaje usunięte przez resztę w imieniu administratora, a potem widzimy, że w strumieniu jest o tym zapis.)
Już sam ten krok zbliża do siebie języki QAA i QA. Zespołom zajmującym się automatyzacją łatwiej jest wyjaśnić wyniki przebiegu; testerzy manualni muszą poświęcać mniej wysiłku na tworzenie przypadków: można je uczynić mniej szczegółowymi. Mimo to wszyscy się rozumieją. Wygrane otrzymaliśmy jeszcze przed rozpoczęciem właściwego szkolenia.
Krok 1. Powtórz frazy
Kontynuujmy paralelę z językiem. Kiedy uczymy się mówić jako dzieci, nie zaczynamy od etymologii i semantyki. Powtarzamy „mama”, „kup zabawkę”, ale nie wchodzimy od razu w praindoeuropejskie korzenie tych słów. I tak właśnie jest: nie ma sensu zagłębiać się w szczegóły techniczne autotestów bez próby napisania czegoś, co działa.
Brzmi to trochę sprzecznie z intuicją, ale działa.
Na pierwszej lekcji warto podać podstawę jak bezpośrednio pisać autotesty. Pomagamy skonfigurować środowisko programistyczne (w moim przypadku Intellij IDEA), wyjaśniamy minimalne zasady językowe niezbędne do napisania kolejnej metody w istniejącej klasie przy użyciu istniejących kroków. Piszemy z nimi jeden lub dwa testy i zadajemy im pracę domową, którą sformatowałbym w ten sposób: gałąź odgałęziona od wzorca, ale usunięto z niej kilka testów. Pozostały jedynie ich opisy. Prosimy testerów o przywrócenie tych testów (oczywiście nie poprzez pokaz różnic).
W rezultacie ten, kto wysłuchał i zrobił wszystko, będzie mógł:
- naucz się pracować z interfejsem środowiska programistycznego: tworzenie gałęzi, skrótów klawiszowych, zatwierdzeń i wypychania;
- opanować podstawy struktury języka i klas: gdzie wstawiać zastrzyki i gdzie importować, po co potrzebne są adnotacje i jakie symbole się tam znajdują oprócz kroków;
- zrozum różnicę pomiędzy działaniem, poczekaj i sprawdź, gdzie czego użyć;
- zwróć uwagę na różnicę między autotestami a kontrolami ręcznymi: w autotestach możesz wyciągnąć tę lub inną procedurę obsługi, zamiast wykonywać czynności za pośrednictwem interfejsu. Na przykład wyślij komentarz bezpośrednio do backendu, zamiast otwierać widok zadań, wybierać dane wejściowe, wpisywać tekst i klikać przycisk Wyślij;
- sformułuj pytania, na które znajdziesz odpowiedź w kolejnym kroku.
Ostatni punkt jest bardzo ważny. Odpowiedzi te można łatwo udzielić wcześniej, ale ważną zasadą nauczania jest to, że odpowiedzi bez sformułowanych pytań nie są zapamiętywane i nie są wykorzystywane, gdy są ostatecznie potrzebne.
Idealnie byłoby, gdyby w tym czasie inżynier automatyk z zespołu QA przydzielił mu zadanie napisania kilku testów w bitwie i pozwolił mu podporządkować się swojemu oddziałowi.
Czego nie dawać:
- bardziej dogłębną wiedzę na temat funkcjonalności środowiska deweloperskiego i samego języka programowania, która będzie potrzebna jedynie przy samodzielnej pracy z oddziałami. Nie zostanie zapamiętane, trzeba będzie to dwa, trzy razy tłumaczyć, ale cenimy czas automatyków, prawda? Przykłady: rozwiązywanie konfliktów, dodawanie plików do gita, tworzenie klas od podstaw, praca z zależnościami;
- wszystko co dotyczy xpath. Poważnie. Trzeba o tym porozmawiać osobno, raz i bardzo skoncentrowanie.
Krok 2. Przyjrzyjmy się bliżej gramatyce
Przypomnijmy sobie zrzut ekranu widoku zadań z kroku #0. Mamy krok o nazwie checkCommentWithTextExists. Nasz tester już rozumie, co robi ten krok, więc możemy zajrzeć do środka i trochę go rozłożyć.
A w środku mamy co następuje:
onCommentBlock(userName).comment(expectedText).should(displayed());Gdzie jest onCommentBlock
onCommonStreamPanel().commentBlock(userName);Teraz uczymy się mówić nie „kup zabawkę”, ale „kup zabawkę w sklepie Detsky Mir, znajdującym się w niebieskiej szafce na trzeciej półce od góry”. Trzeba wyjaśnić, że element wskazujemy sekwencyjnie, z większych elementów (strumień -> blok z komentarzami danej osoby -> ta część tego bloku, w której znajduje się określony tekst).
Nie, to jeszcze nie czas, aby rozmawiać o xpath. Wystarczy krótko wspomnieć, że wszystkie te instrukcje są przez nich opisane i dziedziczenie przechodzi przez nie. Ale musimy porozmawiać o tych wszystkich dopasowujących i kelnerach; odnoszą się one konkretnie do tego etapu i są niezbędne, aby zrozumieć, co się dzieje. Ale nie przeciążaj: Twój uczeń może później samodzielnie uczyć się bardziej złożonych twierdzeń. Najprawdopodobniej powinno wystarczyć, poczekaj do wyświetlenia();, istnieje();, nie();.
Zadanie domowe jest oczywiste: gałąź, w której usunięto zawartość kilku kroków niezbędnych do wykonania określonej liczby testów. Niech testerzy je przywrócą i sprawią, że przebieg znów będzie zielony.
Dodatkowo, jeśli zespół testowy ma w swojej pracy nie tylko nowe funkcje, ale także pewne poprawki błędów, możesz poprosić go o natychmiastowe napisanie testów pod kątem tych błędów i ich wydanie. Najprawdopodobniej wszystkie elementy zostały już opisane, może brakować tylko kilku kroków. To będzie idealny trening.
Krok 3. Pełne zanurzenie
Jak najbardziej kompletny dla testera, który będzie nadal wykonywał swoje bezpośrednie obowiązki. Na koniec musimy porozmawiać o xpath.
Na początek wyjaśnijmy, że wszystkie te onCommentBlock i komentarz są przez nie opisywane.
Razem:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"Kolejność opowieści jest bardzo ważna. Najpierw bierzemy dowolną istniejącą ścieżkę xpath i pokazujemy, że zakładka Elementy zawiera jeden i tylko jeden element. Następnie porozmawiamy o strukturze: kiedy trzeba użyć WebElement i kiedy trzeba utworzyć osobny plik dla nowego elementu. Pozwoli to lepiej zrozumieć dziedziczenie.
Trzeba wyraźnie zaznaczyć, że pojedynczy element to cały widok zadania, zawiera element potomny – cały strumień, który zawiera element potomny – osobny komentarz itp. Elementy podrzędne znajdują się wewnątrz elementów nadrzędnych zarówno na stronie, jak i w strukturze struktury autotestu.
W tym momencie odbiorcy powinni już dobrze zrozumieć, w jaki sposób są dziedziczone i co można wpisać po kropce w onCommentBlock. W tym miejscu wyjaśniamy wszystkie operatory: /, //, ., [] i tak dalej. Do ładunku dodajemy wiedzę dotyczącą użytkowania @class i inne potrzebne rzeczy.
Uczestnicy kursu powinni zrozumieć, jak tłumaczyć xpath w ten sposób. Aby skonsolidować - zgadza się, praca domowa. Usuwamy opisy elementów, pozwalamy przywrócić pracę testów.
Dlaczego ta konkretna ścieżka?
Nie powinniśmy przeciążać osoby skomplikowaną wiedzą, ale trzeba wszystko od razu wyjaśnić, a to jest trudny dylemat. Ta ścieżka pozwoli nam najpierw sprawić, że słuchacze zadają pytania i czegoś nie rozumieją, a dopiero w następnej chwili będą na nie odpowiadać. Jeżeli mówimy o całej architekturze, to do czasu analizy tematu kroków czy xpath najważniejsze ich fragmenty zostaną już zapomniane ze względu na ich niezrozumiałość.
Jednak niektórzy z Was prawdopodobnie będą mogli podzielić się swoimi doświadczeniami na temat tego, jak można jeszcze bardziej zoptymalizować proces. Chętnie przeczytam podobne sugestie w komentarzach!
Źródło: www.habr.com