Jak rozwijać się jako tester - korzystanie z terminala i workflow Gita

Witam w drugiej części mojego artykułu! W pierwszej części opisałam poszczególne etapy nauki mockowania danych aplikacji w kodzie podczas testów manualnych. Ta część dotyczyć będzie z kolei dwóch pierwszych punktów, czyli nauki korzystania z terminala, poznania komend, workflow Gita oraz narzędzia z nim związanego, jakim jest GitLab. Treści zawarte w tym artykule są uniwersalne, ponieważ obydwie rzeczy używane są przy testowaniu każdej platformy mobilnej.

Etap 1 - korzystanie z terminala + komendy

Wiersz poleceń

Pierwszym podstawowym krokiem jest nauczenie się korzystania z narzędzi potrzebnych do zbudowania projektu, ponieważ nie wszystkie posiadają interfejs graficzny. W tym celu warto zacząć od nauki wiersza poleceń.

System macOS dostarcza wraz ze sobą program o nazwie Terminal. Korzystanie z niego może być toporne i niewygodne dla osób początkujących. Istnieje jednak alternatywa w postaci iTerm, będąca odpowiednikiem macOSowego terminala. iTerm posiada wbudowaną funkcjonalność autouzupełnień, podpowiedzi i jest łatwo konfigurowalny, co pozwala dodawać wtyczki ułatwiające pracę. 

Obydwa narzędzia - terminal oraz iTerm - pozwalają na interakcje z narzędziami systemowymi, które są niezbędne do zbudowania projektu oraz do zarządzania repozytorium kodu. Narzędzie to udostępnia interfejs tekstowy do wprowadzania komend, a więc pierwszym kluczowym etapem jest zaznajomienie się z komendami Git. 

Komendy Terminal i Git

Komendy, których na początku należy się nauczyć i będzie się z nich korzystało przez większość czasu, to:

Terminalowe:

• pwd- pokaż obecną lokalizację
• ls- pokaż pliki w obecnej lokalizacji
• cd <nazwa_folderu>- przejdź do folderu o podanej nazwie
• open <nazwa_pliku>- otwórz plik
• cd ..- cofanie się do poprzedniego folderu (poziom niżej)
• mkdir <nazwa_folderu>- utwórz folder

Gitowe:

• git clone <url>- klonowanie repozytorium do folderu
• git fetch- uaktualnienie repozytorium z serwerem
• git pull- pobranie najnowszych zmian z obecnego brancha
• git status- status obecnego brancha, pokazuje dokonane zmiany
• git stash- wycofanie aktualnych zmian i zapisanie ich do katalogu roboczego
• git stash pop- odzyskanie zmian z wersji roboczej
• git clean -fd- usunięcie aktualnych zmian bezpowrotnie
• git checkout <nazwa_brancha>- zmiana brancha (zmiana nie uda się gdy są obecnie jakieś zmiany)

Prostym i praktycznym zadaniem wprowadzającym w świat terminala może być otwieranie jakiegokolwiek pliku znajdującego się na pulpicie za jego pomocą.

Wpisz w konsoli komendy:

1. pwd
2. ls
3. cd <nazwa_folderu>- w tym przypadku nazwą folderu może być “Desktop”
4. znowu warto wpisać “ls”, aby zobaczyć jakie pliki są na desktopie
5. open <nazwa_pliku>- jeżeli nazwa pliku zawiera spacje to musisz, zamiast niej użyć \, czyli wpisujesz np. open dom\ dom.jpg

Rezultat: otwiera się zdjęcie będące na pulpicie.

W trakcie używania iTerm możesz skorzystać z podpowiedzi. Po wpisaniu którejś komendy np. “cd” i wybraniu klawisza tab pokazują się podpowiedzi. Poruszanie się po podpowiedziach w celu ich wybrania wykonywane jest za pomocą taba, a zatwierdza się je enterem.

Alternatywą do korzystania z terminala do Gita, jest wykorzystanie takiego narzędzia jak np. Sourcetree, jednak przy niektórych projektach, umiejętność korzystania z wiersza poleceń też będzie konieczna.

Etap 2 - zapoznanie się z zasadami i repozytorium Git

Zasady Git

Następnym etapem naturalnie nasuwającym się jest zapoznanie się z zasadami Gita. Można go sobie zobrazować porównując proces wersjonowania podczas jednego sprintu z np. etapami tworzenia pięter podczas budowy bloku. 

1. Początkiem prac w budynku jest parter. Podczas powstawania aplikacji pierwszym etapem jest wydawanie wprowadzonych zmian w kodzie na branche nazywane FEATURE lub FEAT. Po tej nazwie wiadomo, że jest to wersja w, której są toczone prace nad daną funkcjonalnością. Po jej  ukończeniu jest ona wydawana na developa gdzie jest gotowa do testów.
2. Drugim etapem prac w przedstawionym bloku jest 1 piętro, na którym robione są ostatnie poprawki. Porównać można je do wydawania zmian na branch zwany FIX. Wiadomo wtedy, że na danym branchu  toczy się praca nad naprawą funkcjonalności lub buga. Po zrobieniu poprawki wersja ląduje na developie i jest gotowa do testów.
3. Kolejnym etapem prac jest 2 piętro, które jest gotowe i oddane do sprawdzenia. W procesie wytwarzania oprogramowania miejscem, gdzie wersja ze zbiorem funkcjonalności i poprawek jest gotowa do testów na stagingu jest branch DEVELOP. Gdy jest przetestowana i wynik testów jest pozytywny trafia ona na branch release i jest gotowa do testów na środowisku produkcyjnym.
4. Na obrazku trzecie piętro jest gotowe i odbierane przez inwestorów. W procesie wydawania wersji aplikacji etap ten będzie odzwierciedleniem wersji na produkcji będącej na branchu RELEASE. Gdy dana wersja zawierająca wszystkie nowe funkcjonalności i poprawki przejdzie pozytywnie testy akceptacyjne, jest gotowa do wydania do sklepu. Wersja ta powszechnie nazywa się kandydatem do wydania (ang. Release Candidate). Jednak podczas testów może okazać się, że muszą zostać zrobione poprawki. Wtedy poprawki wydawane są do brancha release, a on jest następnie dołączany do developa. Wersja ostateczna, która została zatwierdzona do wydania, dołączana jest do brancha o nazwie master. Na tym branchu tworzone są finalne wersje aplikacji, które trafiają do sklepów.
5. Z czwartego piętra korzystają ludzie tak jak i korzystają z aplikacji pobranej ze sklepu. Wersja będąca w sklepie znajduje się na branchu MASTER.
6. Ostatnie piętro dotyczy wszelakich napraw w ciągu użytkowania. Gdy aplikacja jest w sklepie i okaże się, że jest krytyczny bug, który uniemożliwia korzystanie z niej, trzeba go jak najszybciej poprawić. Poprawki takiej wersji wydawane są na branch HOTFIX. Po przetestowaniu zazwyczaj z tego brancha dana wersja idzie od razu do sklepu, a dopiero później jest wypuszczana na brancha master w celu zachowania spójności.

Zarządzanie repozytorium Git

Jest kilka platform wykorzystywanych do hostingu repozytorium Git. W tym artykule dla przykładu zostanie użyty GitLab. Dzięki niemu widzimy wiele przydatnych dla testera informacji. Są nimi: postęp prac oraz numery wersji, w których są dane ficzery i fixy będące szczególnie potrzebne do zbudowania wersji lokalnie, aby móc daną wersję przetestować, zanim będzie wydana na środowisko testowe. Poniżej na zdjęciach zaznaczone i opisane są miejsca, gdzie te informacje się znajdują.

Podsumowanie:

Już teraz zapraszam Cię do 3 części, szczególnie gdy interesujesz się platformą iOS. Będzie ona zawierała praktyczne przykłady tego, jak znajomość Gita i wiersza poleceń może wpłynąć na zwiększenie efektywności testowania aplikacji mobilnych oraz jak poruszać się i testować w XCode.