Kilka słów na temat technicznych umiejętności, które w moim osobistym odczuciu będą przydatne w nadchodzącym roku (i najbliższych kolejnych latach również). Zwizualizowane w postaci ładnej (mam nadzieję) mapy w SVG (skaluje się, bo jest wektorowa!) poniżej. Na githubie jest/będzie angielska wersja posta.

Podstawy

HTML/CSS

Aktualnie aplikacje webowe przejmują wszystkie możliwe platformy. Android, Desktop, iOS, Linux. Powstanie electrona przyśpieszyło ten proces. Visual Studio Code, Etcher, Torrent, Slack – to wszystko aplikacje webowe przeniesione na desktopa. Zrozumienie jak działa HTML/XML + CSS pozwoli Wam na szybsze, lepsze i głębsze testowanie aplikacji.

Powinniście wiedzieć czym jest Shadow DOM, jak strukturyzowany jest HTML 5 i w jaki sposób możemy dzieli strukturyzuje się DOM (pomaga to w pisaniu lokatorów do testów).

CSS/XPATH

Pisanie selektorów to żmudna praca (choć da się je skopiować prosto z przeglądarki). Wiedza czy lepiej w konkretnym przypadku użyć CSS Selectora czy Xpath często eliminuje późniejsze problemy projektowe. Dobrze napisany CSS Selector / Xpath powinien być odporny na najczęstsze zmiany w strukturze DOM. Polecam tutaj dwa ćwiczenia:

JavaScript

Najczęściej używany język programowania we wszechświecie (a już na pewno w aplikacjach webowych). Zrozumienie co dzieje się w DOMie, umiejętności debugowania, pisanie własnych skryptów w konsoli to umiejętności, które pobieżnie warto opanować. I co to do cholery jest ten „this” 😉 Kilka darmowych kursów poniżej.

Cenioną umiejętnością jest zrozumienie jak działa React i Angular (aktualnie najczęściej wybierana bibiloteka JS i najczęściej wybierany framework JS w dużych firmach). Zrozumienie czym są komponenty, jak działa ich odświeżanie w DOMie pozwala ustrukturyzować framework testowy w taki sposób, który zapobiega późniejszym problemom (polecam poczytać o Loadable Component jeżeli używacie Selenium).

Do tego zrozumienie działania Reduxa i umiejętność bawienia się storem prosto z przeglądarki (dzięki Redux DevTools) pozwala nam zahaczyć o początki pentestów.

Umiejętności ogólne

Dziś większość projektów prowadzonych jest w jakimś systemie kontroli wersji. Git jest chyba najbardziej popularnym, a na pewno takim systemem którego warto się uczyć. Dlaczego? Bo zrozumienie działania gita to taka gimnastyka umysłu, która pozwoli Ci zrozumieć wszystkie inne centralne systemu typu SVN czy TFVC.

Protokół HTTP. W dobie architektury klient-serwer (albo mikroserwisów) zrozumienie tego jak komunikują się moduły to obowiązek każdej osoby, która bierze się za testowanie i/lub developerkę. Pozwala to też zrozumieć co dzieje się po stronie klienta, a co po stronie serwera – co znacznie przyśpiesza raportowanie błędów i ich usuwanie.

Terminal nie gryzie. Klikanie jest dość wolne, a nam zależy na maksymalizowaniu czasu w którym myślimy i minimalizowaniu czasu w którym coś robimy. Tylko w ten sposób możemy konkurować z tańszymi „risorsami” zza wielkiej wody. Więcej o tym w części poświęconej bash.

Algorytmy i struktury danych. Temat bardzo ważny (choć pewnie nie wszyscy się ze mną zgodzą) jeżeli tworzymy framework testowy, który w dodatku musi być później miesiącami (lub latami) utrzymywany.

Zostawię tutaj tylko link do posta na freecodecamp, który odeśle Was do odpowiednich materiałów jeżeli jesteście tym zainteresowani.

Tech Skills

Programowanie

C# i Java potraktuję jako jedno. Zrozumienie jednego z tych języków pozwoli Wam przeskoczyć na drugi jeżeli zajdzie taka potrzeba. Dlaczego akurat te dwa języki? Dlatego, że są statycznie typowane i kompilowalne. To pozwala Wam dość łatwo zrozumieć co dzieje się pod spodem.

Maven/Nuget – to repozytoria paczek gotowego kodu w Javie/C#. Zrozumienie tego jak to działa jest dość proste. Dodatkowo warto wiedziec jak samemu takie paczki tworzyć.

LinQ/Streams – czyli zaczątek programowania funkcyjnego w języku obiektowym. Użycie tych technologii pozwala nam zadawać pytania na obiektach (trochę jak SQL). Dzięki temu możemy przetwarzać kolekcje obiektów wyszukując interesujące nas elementy, które chcemy przetestować.

Reflection – przy pracy nad frameworkiem testowym (lub narzędziem typu Gherkin) raczej później niż prędzej trafimy na refleksje. Moment w którym zaczniemy zastanawiać się jakiego typu jest pole w klasie i jak się do niego dostać, to moment kiedy będziemy musieli tego użyć.

DevOps

DevOps – czyli w rozumieniu testera szybkie dostarczenie aplikacji i feedbacku na temat ostatnich zmian.

Czym różni się CI od CD? Jak często chcemy dostawać raporty z wynikami testów? Co dzieje się z kodem po merge’u do brancha development?

CI – umiejętność konfiguracji testów integracyjnych i pokrycia funkcji biznesowych to podstawa. W moim przypadku czesto musiałem tłumaczyć adminowi jak uruchomić i jak zebrać wyniki takich testów. Dodatkowo wiedza o testach jednostkowe i narzędziach do statycznej analizy kodu mogą się przydać (w końcu celujemy w bycie architektem testów).

CD – czym Continuous Deployment różni się od Continuous Integration to jedno z najczęstszych pytań na rozmowach kwalifikacyjnych. Znajomość procesu pozwoli zaplanować w odpowiednim miejscu testy E2E, testy UAT. W moim przypadku (ponownie) to QA jest odpowiedzialny za popchnięcie aplikacji ze środowiska developerskiego na testowe i dalej na UAT. Dobrze wiedzieć jak działa ten guzik w narzędziu i co dzieje się pod spodem.

Skrypty

Do tego, żeby całe CI/CD działało szybko. Do tego żeby zautomatyzować sobie zrobienie git checkout development | git pull w siedmiu podkatalogach z siedmioma projektami potrzebujemy czegoś więcej niż zwykłej linii komend. Z pomocą przychodzą trzy rozwiązania: bash, Powershell i Python.

Bash – język skryptowy kojarzony mylnie tylko z linuxem. Dzięki git bash (który instaluje się razem z klientem git), możemy z niego korzystać również na Windowsie. Przykład: dodanie tej linijki do pliku .bashrc powoduje że w git bash zadziała nam komenda „brall”, która wydrukuje wszystkie podkatalogi dla katalogu w którym została uruchomiona + aktualny branch gita dla tych katalogów.

1
alias brall='for dir in $(ls -d */);do (cd $dir && echo "$dir [$(git rev-parse --abbrev-ref HEAD)]") ; done'

Powershell – język skryptowy dla Windowsa 10. Jeżeli pracujecie na stacku firmy Microsoft, to często musicie korzystać z takiej automatyzacji. Przykładem skryptu, który napisałem w Powershellu jest pobieranie z Azure Devops artefaktów ostatniego poprawnego builda aplikacji desktopowej + instalowanie aplikacji lokalnie na komputerze. Klikanie, rozpakowanie zipa zawsze trwało 10-15 minut (musiałem robić to codziennie). Skrypt spowodował, że mogłem w międzyczasie pójść zrobić sobie kawę.

Docker i konteneryzacja

Milion środowisk na jednym komputerze. Docker rozwiązuje nam problem różnych wersji bibilotek i frameworków, wersji języków programowania a nawet systemów operacyjnych. Dzięki znajomości dockera możemy lokalnie na naszym komputerze utworzyć całe środowisko testowe (tu jest link do repo z warsztatów o tej tematyce na konferencji Quality Excites 2019).

Testowanie API

Tutaj skoncentruję się na REST API i definicji Open API 3.0 (jako że GraphQL jeszcze nie jest standardem a SOAP już nie jest standardem).

90% aplikacji które są aktualnie tworzone są oparte na bezstanowej komunikacji HTTP (czyli architekturze REST) i mikroserwisach. Pozwala to na szybkie skalowanie w przypadku wykładniczo rosnącej ilości użytkowników. Według mnie świetnym toolem do testowania jest Postman. Pozwala nam czytelnie i przez sensowne GUI tworzyć testy, a następnie puszczać je dzięki aplikacji konsolowej newman. Wstęp do tworzenia frameworka w newmanie jest w kolejnym moim repozytorium (zakładam tam, że testy w Postmanie są już utworzone i zajmuję się ich uruchamianiem w różnych konfiguracjach).

Open Api 3.0 – kilka wiodących firm zdecydowało, że czas na wprowadzenie standardu tworzenia API i jego dokumentacji. Tak powstał OAS aktualnie w wersji 3. Narzędziami które wspierają tworzenie tej dokumentacji jest np. Swagger. Umiejętność przekonania programistów do trzymania się tej specki ułatwia życie w późniejszych etapach zarówno im jak i testerom.

SysAdmin, czyli linux Twoim przyjacielem

Instalacja pakietów apt-get, ustawianie mysql, znajomość niezbędnych komend to raczej miły dodatek niż wymaganie. Niemniej pomaga skrócić czas spotkań, dyskusji i ustaleń z sysadminami, więc może warto trochę poświęcić czasu na dokształcenie się w tej dziedzinie.

Mobile Testing

Testowanie mobilek i desktopów (UWP/WPF). Wszystko jest możliwe dzięki Appium, dlatego znalazło się na samej górze. To narzędzie pozwala nam testować zarówno Androida, iOS jak i aplikacje desktopowe na Windowsie. Moim zdaniem to świetny punkt wejścia do testowania mobilek (uczycie się raz i testujecie wszystkie platformy).

Espresso – narzędzie do testowania stricte aplikacji Androida. Według wszelkich opinii z rynku jest dużo szybsze do Appium, dlatego wskazane w przypadku gdy wasza aplikacja nie ma odpowiednika na iOS.

XCTest – jak wyżej, tyle że dla iOS. Wskazane jeżeli nie interesuje Was Android.

Xamarin i WinAppDriver – wrzuciłem to tutaj, bo pomogło mi przygotować kiedyś projekt testowy dla aplikacji rozwijanej na Windowsa, iOS i Android. WinAppDriver jest następcą CodedUI (toola dołączanego do Visual Studio Enterprise), który jest zupełnie opensource. Xamarin jest dość prostym do nauczenia toolem, ale zostawiającym wiele do życzenia pod kątem wydajności i elastyczności 😉

Znajomość rozwiązań chmurowych

Wiekszość rozwiązań które powstają aktualnie to rozwiązania oparte o architekturę chmury. Azure i AWS to najwięksi dostawcy tych usług. Dobre zrozumienie jak działają podstawowe funkcjonalności chmury pozwoli nie tylko dobrać odpowiednie rozwiązanie pod kątem technicznym ale również pod kątem ekonomicznym. W chmurze można zrobić wszystko, na kilka różnych sposobów i kilka różnych kosztów. Dlatego zachęcam do przerobienia materiału przygotowującego do certyfikacji AZ-900 (Azure Fundamentals), a być może i zrobienia tego certyfikatu.

Nie znam odpowiednika tego certyfikatu dla AWS, ale na pewno istnieje. Jeżeli więc Wasza firma stawia na innego dostawcę, śmiało. Jak zrobicie pierwszy cert, drugi będzie tylko formalnością.

Testowanie

Na koniec doszliśmy wreszcie do testowania samego w sobie.

Testy jednostkowe do frameworka testującego aplikację? A i owszem, zdarzyło mi się takowe pisać. Dodatkowo każdy framework oparty na selenium będzie musiał korzystać z biblioteki, która pozwoli nam przynajmniej na tworzenie asercji. NUnit dla C#, jUnit dla Javy, Jest dla JavaScriptu, to najpopularniejsze z narzędzi.

Ciężko tu nie wspomnieć o zdobywającym popularnośc Cypressie, który jest aktualnie jedynym potencjalnym kontrkandydatem dla Selenium (wreszcie dodali wsparcie więcej niż jednej przeglądarki :))

Wartym uwagi jest też tool mabl, choć płatny to w zasadzie niewiele jak na rozwiązanie oparte na sztucznej inteligencji.

Wisienką na torcie niech będzie organizacja uruchamiania testów za pomocą Selenium Grid (lub Zalenium czy Selenoida) oraz prezentacja wyników testów (a jeszcze lepiej możliwość ich uruchamiania w dowolnej chwili jednym kliknięciem) dla biznesu. W drugim przypadku z pomocą może przyjść ciekawe narzędzie od UncleBoba Fitnesse, które pozwala nam stworzyć „Wikipedię z testami i ich wynikami”.


Zapraszam do komentarzy i propozycji zmian roadmapy najlepiej via Twitter albo przez githuba (jak tylko przetłumaczę tekst na angielski)