Budowa aplikacji mobilnych, etap 3: pisanie kodu i testy

Budowa aplikacji mobilnych, etap 3: pisanie kodu i testy

Ten etap budowy aplikacji ma miejsce, gdy projekt interfejsu jest już niemal gotowy. Wtedy zespół może zająć się pisaniem kodu i testami.

Jak wygląda praca nad tworzeniem aplikacji mobilnych? Sprawdź, jak ten proces przebiega i jaką rolę pełni w nim product owner.

Uwaga: Ten artykuł skupia się na trzecim etapie rozwoju aplikacji mobilnych. Sprawdź, co ma miejsce wcześniej – w fazie Product Discovery, podczas spotkania kickoffowego i przy projektowaniu UX/UI.

Podstawowe informacje o budowie aplikacji

Czym są aplikacje mobilne?

Dla wielu osób aplikacja mobilna to tylko program, który mają na swoich smartfonach czy tabletach. Ale jako członek zespołu deweloperskiego musisz przyjąć bardziej techniczną perspektywę.

Większość aplikacji składa się z dwóch głównych elementów: backendu z API i frontendu. Każdy z nich ma inną rolę do odegrania.

Frontend

To, co widzą użytkownicy aplikacji mobilnych i z czym wchodzą w interakcje – to frontend. Cały interfejs z jego przyciskami, grafikami, fontami, kolorami itd. Wszystkie widoczne komponenty tworzą nasi deweloperzy, którzy właśnie na tę część projektu poświęcają najwięcej czasu. Dlatego, kiedy otwierasz aplikację, widzisz pasek wyszukiwania, nawigację, sekcje z różnego rodzaju treściami – już wiesz, komu je zawdzięczasz.

Backend

To bohater, który pozostaje w cieniu – użytkownicy go nie widzą, ale wiele aplikacji nie mogłoby bez niego funkcjonować. Jego główną rolą jest przechowywanie, przetwarzanie i dostarczanie danych.

Jeśli chcesz pozwolić klientom na logowanie, szukanie produktów, składanie zamówień i opłacanie ich, potrzebujesz backendu. Umożliwia on także np. funkcjonowanie live chatu, zbieranie danych analitycznych, wysyłanie powiadomień, dodawanie i usuwanie produktów, pokazywanie rekomendowanych propozycji etc.

Przykład

Szukasz czerwonego swetra w aplikacji eCommerce i wpisujesz frazę “czerwony sweter” w pasku wyszukiwania. Zapytanie trafia do backendu. Tam są przechowywane dane dotyczące wszystkich produktów, które pasują do tej frazy. Backend wysyła te rezultaty do frontendu, żebyś mógł je zobaczyć.

Kiedy jakieś dane nie są przechowywane w backendzie, to oznacza, że frontend nie ma nic do zaprezentowania. Powiedzmy, że oglądasz jakiś sweter i chcesz zobaczyć podobne produkty. Ale backend nie ma o nich żadnych informacji, więc frontend nie może Ci niczego takiego wyświetlić.

Ważnym elementem backendu jest API. Ten skrót oznacza Application Programming Interface. API łączy dwa światy – backend oraz frontend – i umożliwia komunikację pomiędzy nimi. Gdy frontend wysyła do backendu zapytanie, najpierw przechodzi ono przez API, które je przetwarza. To pozwala backendowi je zrozumieć. Dzięki temu może dostarczać pożądane rezultaty.

Developer translates UI project into code

Testy QA w procesie rozwoju aplikacji

Pisanie kodu i testowanie są jak Flip i Flap, Timon i Pumba, Romeo i Julia. Nierozłączne. Wyróżniamy dwa typy testów pomocnych w czasie budowy aplikacji – manualne i automatyczne.

Testy manualne

Gdy jakiś element aplikacji zostaje zaimplementowany bądź edytowany, specjalista od QA testuje go manualnie na różnych urządzeniach mobilnych. W zależności od celu można przeprowadzać różne rodzaje testów.

  • Najczęściej wykonuje się testy funkcjonalne, które mają miejsce po dodaniu nowego elementu do aplikacji.
  • Gdy wykryto błąd i deweloper zgłasza, że został on naprawiony, specjalista od QA przeprowadza retestyregresje.
  • Przed publikacją produktu przeprowadza się testy akceptacyjne.

Aplikacje na iOS i Androida testujemy oddzielnie. Nie ma znaczenia, czy budujesz aplikacje natywne, czy aplikację cross-platformową. Nawet w przypadku rozwiązań  tworzonych we Flutterze testerzy muszą sprawdzić oprogramowanie na dwóch systemach operacyjnych.

Testy automatyczne

Bazują na skryptach testów, które piszą zwykle deweloperzy lub specjaliści od QA. Popularnym przykładem testów automatycznych są testy jednostkowe. Deweloperzy uruchamiają je po każdej implementacji, żeby zobaczyć, czy wszystko działa jak należy. Zalecamy ich przeprowadzanie w przypadku złożonych projektów, gdy wiele elementów jest do siebie podobnych. Takie testy pozwalają zespołom zaoszczędzić wiele czasu i w pełni skupić się na aspektach, które wymagają indywidualnego spojrzenia (wtedy warto pomyśleć np. o testach eksploracyjnych).

Testy automatyczne można z łatwością przeprowadzić w środowisku CI (np. Bitrise). Inwestycja w takie narzędzie okazuje się opłacalna w dłuższej perspektywie. Zwłaszcza, gdy Twoja aplikacja wymaga częstych zmian i konieczne jest ciągłe sprawdzanie tych samych elementów.

Budowa aplikacji mobilnych w metodyce SCRUM

Popularną metodologią wykorzystywaną przy rozwoju oprogramowania jest agile. W Holdapp korzystamy z dwóch opartych na agile metodyk – Kanbanie i SCRUM-ie. Sprawiają one, że proces staje się bardziej elastyczny i pozwalają nam szybciej dostosowywać się do zmian.

Czytając o zarządzaniu projektami, łatwo natknąć się na taki termin jak sprint, czyli iteracja. Jest on powiązany z metodyką SCRUM. Co należy o nim wiedzieć?

  • Zwykle trwa do dwóch tygodni.
  • Każda iteracja skupia się na rozwoju i testowaniu wybranych elementów aplikacji.
  • Cel sprintu to tzw. definition of done.
  • W każdym sprincie odbywa się kilka spotkań, czyli ceremonii.

Przebieg iteracji w SCRUM-ie

Każda iteracja dzieli się na kilka etapów. To optymalizuje pracę, ułatwia kontrolę postępów i pozwala nam ulepszać nasze działania.

1. Planowanie

To pierwsze spotkanie w sprincie. Podczas planowania zespół omawia cele nadchodzącej iteracji (definition of done). Każdy musi rozumieć, co chce osiągnąć, jak to zrobić i ile czasu powinno to zająć. Rezultatem tego spotkania powinien być zaktualizowany backlog z informacjami o wymaganiach i priorytetach.

2. Daily, czyli codzienne spotkania

Trwają ok. 15 minut. Wtedy każdy mówi, co osiągnął poprzedniego dnia i co będzie robił w ciągu najbliższych godzin. Zespół informuje też o przeszkodach, które spowalniają prace. Kto bierze udział w tych spotkaniach? Zazwyczaj project manager (scrum master), deweloperzy i tester QA.

3. Doskonalenie backlogu 

Ma miejsce w połowie sprintu. Najpierw product owner przygotowuje wstępny backlog z myślą o następnej iteracji. Potem zespół go analizuje i szacuje, ile czasu będzie potrzebował, żeby zrealizować planowane zadania. Celem jest stworzenie ostatecznej wersji backlogu sprintu.

4. Przegląd sprintu 

Moment, kiedy pojawiają się interesariusze. Przegląd sprintu to czas, kiedy deweloperzy pokazują wyniki swojej pracy i prezentują, co zostało zrobione. Mówią też, jakie problemy się pojawiły i jak je rozwiązano. Celem tego spotkania jest również ustalenie, co należy zrobić w następnej kolejności i czy trzeba w związku z tym edytować backlog.

5. Retrospektywa

Na koniec sprintu zespół spotyka się, by porozmawiać o tym, co zostało zrobione dobrze w ostatnim sprincie i co należy poprawić. Uczestnicy ustalają, jakie zmiany chcą wprowadzić w kolejnej iteracji, by usprawnić proces rozwoju aplikacji.

Przygotowania do tworzenia aplikacji mobilnej

Znasz już podstawowe terminy i wiesz, jak zwykle wygląda proces budowy aplikacji. Teraz dowiedz się, jakie zadania deweloperzy muszą wykonać przed napisaniem pierwszej linijki kodu.

Faza 1. Zespół analizuje materiały dostarczone przez klienta (np. plany dotyczące MVP, architekturę informacji, KPI, etc.). Upewnia się, że jego cele są wykonalne. Ten proces obejmuje konsultacje z product ownerem i zespołem odpowiedzialnym za API/backend.

Również w tej fazie team leader tworzy wstępny wykres Gantta lub roadmapę produktu, w zależności od projektu. Należy ustalić, co chcemy osiągnąć, kiedy i jak.

Faza 2. Jeśli niezbędne są zmiany w MVP, deweloperzy edytują projekt. Ich następnym zadaniem jest wybór najlepszych rozwiązań technologicznych oraz ustalenie, jakie są ryzyka i kluczowe elementy projektu. Wybierają też odpowiednie narzędzia.

Faza 3. Kiedy ostateczna wersja MVP zostaje zaakceptowana, modyfikujemy roadmapę, by odzwierciedlała aktualny zakres projektu.

Faza 4. Project manager przygotowuje historyjki użytkownika (tzw. user stories), które objaśniają, co użytkownik chce osiągnąć. Pomaga to deweloperom zrozumieć przeznaczenie każdego elementu, jaki muszą zaimplementować.

W międzyczasie UI designer pracuje nad makietą aplikacji, a później tworzy ostateczny projekt interfejsu użytkownika. Klient musi go zaakceptować zanim rozpocznie się pisanie kodu.

Faza 5. Pierwszy szkic backlogu jest gotowy. Informuje on zespół, jakie zadania należy wykonać i jaki mają priorytet.

Programowanie i testowanie krok po kroku

Kiedy wszystko jest gotowe, deweloperzy mogą skupić się na programowaniu. Jak zazwyczaj przebiega ten proces?

  1. Project manager dodaje zadanie do tablicy na Jirze.
  2. Deweloper tworzy wymagany element aplikacji.
  3. Deweloper otwiera merge request, żeby poinformować innych członków zespołu o zmianach w kodzie.
  4. Kod jest sprawdzany w środowisku CI (np. Bitrise albo Jira). Proces ten obejmuje m.in. analizę statyczną kodu, testy jednostkowe i integracyjne. Narzędzia CI sprawdzają również formatowanie i weryfikują, czy kod jest zgodny z wymogami.
  5. Inny deweloper przeprowadza code review i rekomenduje zmiany, gdy okazuje się to konieczne. Czym jest code review? Kiedy jeden specjalista kończy zadanie, ktoś inny sprawdza jego kod. Przygląda się jego logice i architekturze, weryfikuje też, czy spełnia on wymagania i stara się wykryć błędy. Upewnia się również, że kod jest czytelny, łatwy do zrozumienia i niezbyt długi.
  6. Deweloper scala kod.
  7. Projekt zostaje przeniesiony do głównej gałęzi (ang. branch), co daje testerom dostęp do aplikacji.
  8. Buildy trafiają do testów.
  9. Testerzy QA sprawdzają aplikację i zgłaszają błędy. Proces ten się powtarza aż do momentu, gdy wszystkie elementy aplikacji są utworzone i zweryfikowane. W międzyczasie pod koniec każdego miesiąca project manager wysyła klientowi raport. Informuje on, jakie zadania zostały ukończone i ile czasu to zajęło.
  10. Klient poddaje produkt ocenie i akceptuje go lub sugeruje zmiany.
  11. Po wyrażeniu zgody rozpoczyna się procedura publikacji aplikacji.
  12. Deweloperzy uruchamiają build w środowisku CI.
  13. Kod przechodzi dalsze testy wewnętrzne i zewnętrzne (w przypadku aplikacji iOS ten proces odbywa się za pośrednictwem platformy TestFlight).
  14. Aplikacja jest ostatecznie sprawdzana przez Apple App Store i Google Play Store. Gdy zostaje zaakceptowana, produkt staje się dostępny w sklepach.

Każdy projekt jest unikalny, dlatego tworzenie aplikacji mobilnych nie zawsze odbywa się w taki sam sposób. Przykładowo czasem UX designer odgrywa większą rolę na etapie programowania. W innych przypadkach publikacje nie są regularne. Ma to wpływ na przebieg prac.

Kolejny krok to publikacja produktu w sklepach. Wymaga to zaangażowania różnych osób z zespołu klienta, takich jak copywriterzy, prawnicy czy graficy. Zapoznaj się z naszymi poradami dotyczącymi dodawania aplikacji do Google Play Store i Apple App Store, żeby lepiej się do tego przygotować.

Justyna Zielonka

Content Marketing Manager

Dowiedz się więcej

Wycena projektu

Opowiedz nam o swoim projekcie i napisz, jak możemy Ci pomóc.

Dlaczego warto rozwijać z nami projekty?

Logo Mobile Trends Awards

Mobile Trends Awards 2021

Wygrana w kategorii
ŻYCIE CODZIENNE

Nagroda Legalnych Bukmacherów

Nagroda Legalnych Bukmacherów 2019

Najlepsza aplikacja mobilna

Mobile Trends Awards logo

Mobile Trends Awards 2020

Nominacja w kategorii
SPORT I REKREACJA

22

opinii klientów

Clutch logo