{"id":30374,"date":"2021-12-20T07:46:00","date_gmt":"2021-12-20T06:46:00","guid":{"rendered":"https:\/\/nearshore-it.eu\/artykuly\/jak-skutecznie-testowac-aplikacje-mobilne\/"},"modified":"2024-11-07T12:54:44","modified_gmt":"2024-11-07T11:54:44","slug":"jak-skutecznie-testowac-aplikacje-mobilne","status":"publish","type":"post","link":"https:\/\/nearshore-it.eu\/pl\/artykuly\/jak-skutecznie-testowac-aplikacje-mobilne\/","title":{"rendered":"Zwinne testowanie aplikacji mobilnych"},"content":{"rendered":"\n

Tre\u015b\u0107 zaktualizowana 20.12.2021. Konsultacja merytoryczna: Tomasz Nykiel<\/p>\n\n\n\n

\n

<\/p>\n

    \n
  1. 1. Aplikacje mobilne w 2021 roku<\/a><\/li>\n
  2. 2. Sprintem przez projekt?<\/a><\/li>\n
  3. 3. Zwinne podej\u015bcie do testowania aplikacji mobilnych<\/a><\/li>\n
  4. 4. W\u0142a\u015bciciel Produktu w metodologiach zwinnych Agile<\/a><\/li>\n
  5. 5. Zwinny zesp\u00f3\u0142 projektowy<\/a><\/li>\n
  6. 6. Ci\u0105g\u0142e przeprowadzanie test\u00f3w<\/a><\/li>\n
  7. 7. Modele testowania aplikacji<\/a><\/li>\n
  8. 8. Testowanie aplikacji mobilnych na emulatorach<\/a><\/li>\n
  9. 9. Testowanie aplikacji mobilnych na farmie urz\u0105dze\u0144<\/a><\/li>\n
  10. 10. Beta-testy i automatyczne raportowanie b\u0142\u0119d\u00f3w<\/a><\/li>\n
  11. 11. Podsumowanie<\/a><\/li>\n <\/ol>\n<\/div>\n\n\n

    <\/p>\n\n\n\n

    Aplikacje mobilne w 2021 roku<\/h2>\n\n\n\n

    Wed\u0142ug raportu „State of Mobile 2021” nowa, pandemiczna rzeczywisto\u015b\u0107 prze\u0142o\u017cy\u0142a si\u0119 na wi\u0119ksze wykorzystanie urz\u0105dze\u0144 mobilnych, a to z kolei \u2013 na rekordowe wydatki na aplikacje mobilne. U\u017cytkownicy urz\u0105dze\u0144 iOS i Android ch\u0119tniej kupowali aplikacje i gry w App Store oraz Google Play, wydaj\u0105c na nie 35-40%<\/strong> wi\u0119cej ni\u017c w roku poprzednim. Za dynamicznym rozwojem sektora aplikacji mobilnych idzie konieczno\u015b\u0107 szybkiego dostarczania na rynek przetestowanych aplikacji. Jak zatem zadba\u0107 o efektywne testowanie aplikacji mobilnych? Z pomoc\u0105 przychodz\u0105 metodyki zwinne, coraz ch\u0119tniej stosowane w realizacji projekt\u00f3w rozwoju aplikacji.<\/p>\n\n\n\n

    <\/div>\n\n\n
    \n
    \"aplikacje<\/figure>\n<\/div>\n\n\n
    <\/div>\n\n\n\n

    Sprintem przez projekt?<\/h2>\n\n\n\n

    Metodyki zwinne to preferowany spos\u00f3b tworzenia aplikacji mobilnych. Charakterystyczn\u0105 cech\u0105 filozofii Agile jest sprint \u2013 czyli okre\u015blony czas, podczas kt\u00f3rego zesp\u00f3\u0142 wykonuje dany etap prac i dostarcza go do oceny klientowi. Czas trwania sprintu jest ustalany z g\u00f3ry na pocz\u0105tku projektu. Mo\u017ce to by\u0107 okres 2 tygodni i jest sta\u0142y przez ca\u0142\u0105 d\u0142ugo\u015b\u0107 \u017cycia projektu. Na pocz\u0105tku ka\u017cdego sprintu zesp\u00f3\u0142 ustala cele, czyli definiuje, co chce osi\u0105gn\u0105\u0107 podczas kolejnego okresu. Po zako\u0144czeniu sprintu, widz\u0105c post\u0119p prac, mo\u017cna oceni\u0107 stan projektu, zmieni\u0107 priorytety czy nawet zmodyfikowa\u0107 projekt aplikacji (np. dodaj\u0105c nowe funkcjonalno\u015bci). Dzi\u0119ki temu metodyka zwinna pozwala elastycznie podchodzi\u0107 do zmian, a programi\u015bci maj\u0105 zapewnion\u0105 sta\u0142o\u015b\u0107 wymaga\u0144 w czasie trwania sprintu, co pozwala im wydajnie pracowa\u0107. Klient natomiast ma mo\u017cliwo\u015b\u0107 zmiany plan\u00f3w po ka\u017cdym sprincie i bie\u017c\u0105cego dopasowania projektu do ci\u0105gle zmieniaj\u0105cych si\u0119 wymaga\u0144, opinii u\u017cytkownik\u00f3w czy nowych priorytet\u00f3w biznesowych.<\/p>\n\n\n\n

    Zwinne podej\u015bcie do testowania aplikacji mobilnych<\/h2>\n\n\n\n

    Opisane podej\u015bcie dotyczy wszystkich projekt\u00f3w tworzenia oprogramowania, ale jest szczeg\u00f3lnie wa\u017cne w \u015bwiecie testowania aplikacji mobilnych. Obecne platformy dystrybucji (App Store dla iOS, Google Play dla Androida) umo\u017cliwiaj\u0105 publikacj\u0119 aplikacji jeszcze w procesie jej tworzenia i aktualizowanie jej regularnie bez \u017cadnego wysi\u0142ku u\u017cytkownika ko\u0144cowego. To, w po\u0142\u0105czeniu z metodologi\u0105 zwinn\u0105, pozwala opublikowa\u0107 aplikacje mobilne jak najwcze\u015bniej, zebra\u0107 opinie u\u017cytkownik\u00f3w i na tej podstawie ustala\u0107 dalszy plan rozwoju aplikacji, publikuj\u0105c regularnie kolejne funkcjonalno\u015bci. Bazuj\u0105c na opinii ko\u0144cowych u\u017cytkownik\u00f3w, klient ma mo\u017cliwo\u015b\u0107 ustalenia priorytet\u00f3w rozwoju, kt\u00f3re s\u0105 zgodne z rzeczywistymi oczekiwaniami, i p\u0142ynnie zmienia\u0107 oryginaln\u0105 wizj\u0119 produktu na tak\u0105, kt\u00f3ra jest najbardziej atrakcyjna na docelowym rynku.<\/p>\n\n\n\n

    Metodologia zwinna Agile, wraz z modelem cz\u0119stego publikowania aplikacji, pozwala szybciej uzyska\u0107 dopracowany, funkcjonalny produkt.<\/b><\/p>\n\n\n\n

    <\/div>\n\n\n
    \n
    \"Agile<\/figure>\n<\/div>\n\n\n
    <\/div>\n\n\n\n

    W\u0142a\u015bciciel Produktu w metodologiach zwinnych Agile<\/h2>\n\n\n\n

    W\u0142a\u015bciciel Produktu (Product Owner) to osoba odpowiedzialna za definiowanie wymaga\u0144 projektowych. Klient powinien wybra\u0107 do tej roli jedn\u0105 osob\u0119, kt\u00f3ra b\u0119dzie osob\u0105 kontaktow\u0105 dla zespo\u0142u. G\u0142\u00f3wnym zadaniem W\u0142a\u015bciciela Produktu jest wsp\u00f3\u0142praca z zespo\u0142em w celu zamiany wizji produktu w finaln\u0105 aplikacj\u0119. Jest on odpowiedzialny za znajomo\u015b\u0107 oczekiwanych funkcjonalno\u015bci, dopasowanie produktu do docelowego odbiorcy i proces ustalania priorytet\u00f3w na nast\u0119pny sprint. W\u0142a\u015bciciel Produktu nie musi posiada\u0107 wiedzy programistycznej, dobrze jednak, je\u015bli dysponuje informacj\u0105 na temat rynku, podobnych rozwi\u0105za\u0144 i posiada podstawowy poziom wiedzy technicznej. Konieczne jest natomiast, aby W\u0142a\u015bciciel Produktu dysponowa\u0142 wystarczaj\u0105co du\u017c\u0105 ilo\u015bci\u0105 czasu, tak by by\u0107 dost\u0119pnym dla zespo\u0142u przez ca\u0142y czas trwania projektu.<\/p>\n\n\n\n

    <\/div>\n\n\n
    \n
    \"testy<\/figure>\n<\/div>\n\n\n
    <\/div>\n\n\n\n
    <\/div>\n\n\n\n

    Zwinny zesp\u00f3\u0142 projektowy<\/h2>\n\n\n\n

    Zesp\u00f3\u0142 projektowy pracuj\u0105cy zgodnie z filozofi\u0105 Agile jest odpowiedzialny za wykonanie projektu wed\u0142ug wizji W\u0142a\u015bciciela Produktu. W szczeg\u00f3lno\u015bci odpowiada za stworzenie architektury technicznej, zaimplementowanie jej i przetestowanie<\/strong>. Zesp\u00f3\u0142 powinien by\u0107 w ci\u0105g\u0142ym kontakcie z W\u0142a\u015bcicielem Produktu przez ca\u0142y okres produkcji. Na pocz\u0105tku sprintu W\u0142a\u015bciciel Produktu wybiera najwa\u017cniejsze zadania do wykonania, a zesp\u00f3\u0142 jest odpowiedzialny za ocen\u0119, jak du\u017co z tych zada\u0144 jest w stanie wykona\u0107 podczas trwania sprintu. Cz\u0142onkowie zespo\u0142u ustalaj\u0105 szczeg\u00f3\u0142y wymaga\u0144 z W\u0142a\u015bcicielem Produktu przez ca\u0142y okres trwania sprintu. Wyniki pracy programist\u00f3w s\u0105 testowane przez tester\u00f3w (kt\u00f3rzy wchodz\u0105 w sk\u0142ad tego samego zespo\u0142u), po czym odbywa si\u0119 spotkanie \u201eDemo\u201d, na kt\u00f3rym programi\u015bci b\u0105d\u017a testerzy prezentuj\u0105 ca\u0142emu zespo\u0142owi oraz klientowi post\u0119p prac. Zale\u017cnie od wybranego modelu wsp\u00f3\u0142pracy ca\u0142y zesp\u00f3\u0142 (z wyj\u0105tkiem W\u0142a\u015bciciela Produktu) mo\u017ce by\u0107 po stronie dostawcy us\u0142ug lub te\u017c mo\u017ce by\u0107 z\u0142o\u017cony z pracownik\u00f3w zar\u00f3wno klienta, jak i partnera outsourcingowego.<\/strong><\/p>\n\n\n\n

    Skoro ju\u017c wiemy, \u017ce testy oprogramowania to nieod\u0142\u0105czny element metodyk zwinnych Agile, podczas tworzenia aplikacji, skupmy si\u0119 teraz na ich mo\u017cliwo\u015bciach.<\/p>\n\n\n\n

    Ci\u0105g\u0142e przeprowadzanie test\u00f3w<\/h2>\n\n\n\n

    Bior\u0105c pod uwag\u0119 poziom skomplikowania aplikacji tworzonych obecnie, dawny wzorzec testowania, kt\u00f3ry czas na testy przewidywa\u0142 pod koniec cyklu produkcyjnego, jest ju\u017c przestarza\u0142y. Testowanie powinno by\u0107 wykonywane przez ca\u0142y okres produkcji.<\/strong> Ka\u017cda nowa funkcjonalno\u015b\u0107 powinna by\u0107 sprawdzana od razu po jej stworzeniu<\/strong> za pomoc\u0105 test\u00f3w manualnych, a je\u015bli to mo\u017cliwe i wskazane, to dodana do zestawu test\u00f3w automatycznych (aby testy regresji sprawdza\u0142y, czy r\u00f3wnie\u017c w przysz\u0142o\u015bci funkcjonalno\u015b\u0107 b\u0119dzie dzia\u0142a\u0107 niezmiennie, zgodnie z wymaganiami).<\/p>\n\n\n\n

    <\/div>\n\n\n
    \n
    \"testowanie<\/figure>\n<\/div>\n\n\n
    <\/div>\n\n\n\n
    <\/div>\n\n\n\n

    Modele testowania aplikacji<\/h2>\n\n\n\n

    Jak zadba\u0107 o jako\u015b\u0107 rozwijanej aplikacji mobilnej? Zdecydowanie powinni\u015bmy rozwa\u017cy\u0107 takie mo\u017cliwo\u015bci jak: <\/p>\n\n\n\n

    Testy jednostkowe<\/h3>\n\n\n\n

    Testy jednostkowe pomagaj\u0105 zweryfikowa\u0107, czy kolejne zmiany w projekcie nie powoduj\u0105 b\u0142\u0119d\u00f3w w poprzednio wykonanych funkcjonalno\u015bciach. Unit testing to klasyczne podej\u015bcie w programowaniu \u2013 niezale\u017cnie od tego, czy tworzymy aplikacj\u0119 mobiln\u0105, desktopow\u0105 czy webow\u0105 \u2013 w kt\u00f3rym wybrane elementy kodu s\u0105 sprawdzane za pomoc\u0105 osobnych test\u00f3w. Stosowanie test\u00f3w jednostkowych nie jest niezb\u0119dne i niestety cz\u0119sto s\u0105 one pomijane. Niemniej jednak, ich przeprowadzanie jest dobr\u0105 praktyk\u0105 i pozytywnie wp\u0142ywa na jako\u015b\u0107 produktu.<\/p>\n\n\n\n

    Automatyczne testowanie UI<\/h3>\n\n\n\n

    Automatyczne testowanie interfejsu u\u017cytkownika (UI)<\/strong>\u202fto\u202fodpowied\u017a na\u202fwyzwania wi\u0105\u017c\u0105ce si\u0119 z testami jednostkowymi. Zamiast skupia\u0107 si\u0119 na\u202ftestowaniu pojedynczych fragment\u00f3w kodu, testujemy aplikacj\u0119 jako ca\u0142o\u015b\u0107. Wbrew nazwie, ten model testowania nie\u202fs\u0142u\u017cy tylko\u202fdo\u202fsprawdzania interfejsu \u2013 testuje si\u0119 w\u202ften spos\u00f3b ca\u0142\u0105 aplikacj\u0119, tyle \u017ce\u202fz\u202fperspektywy u\u017cytkownika. Zamiast r\u0119cznie wywo\u0142ywa\u0107 fragmenty kodu, testuje si\u0119 efekt interakcji przez\u202fsymulowane zachowania u\u017cytkownika. Mo\u017cna na\u202fprzyk\u0142ad symulowa\u0107 naci\u015bni\u0119cie przycisku w\u202faplikacji i\u202fsprawdzi\u0107, czy\u202fw\u202frezultacie na\u202fekranie pojawi si\u0119 oczekiwany wynik. Ta metoda pozwala na\u202fprzetestowanie ca\u0142o\u015bci aplikacji \u2013 zar\u00f3wno UI, czy\u202fwewn\u0119trznego kodu komunikacji z\u202fweb service\u2019ami, jak i\u202fkodu po\u202fstronie serwera odpowiadaj\u0105cego na\u202fzapytania.<\/p>\n\n\n\n

    Dodatkow\u0105 zalet\u0105 test\u00f3w automatycznych UI jest to, \u017ce o wiele lepiej nadaj\u0105 si\u0119 do testowania b\u0142\u0119d\u00f3w pojawiaj\u0105cych si\u0119 tylko na niekt\u00f3rych modelach, zwi\u0105zanych ze specyficznym zachowaniem aplikacji.<\/strong> Uruchamianie tych samych test\u00f3w na r\u00f3\u017cnych urz\u0105dzeniach pozwala testowa\u0107, czy aplikacja dzia\u0142a poprawnie w szerokim zakresie charakterystyk urz\u0105dze\u0144. Takie testowanie pomaga te\u017c znale\u017a\u0107 nietypowe b\u0142\u0119dy, kt\u00f3re nie zosta\u0142yby wy\u0142apane w trakcie test\u00f3w jednostkowych.<\/p>\n\n\n\n

    Testowanie aplikacji mobilnych na emulatorach<\/h2>\n\n\n\n

    Emulatory to mobilne urz\u0105dzenia wirtualne, kt\u00f3re pozwalaj\u0105 na przeprowadzenie test\u00f3w. Jest to przydatne zw\u0142aszcza w projektach, w kt\u00f3rych pojawia si\u0119 potrzeba zaoszcz\u0119dzenia na zakupie fizycznych urz\u0105dze\u0144. Emulator sprawdzi si\u0119 w przypadku podstawowych test\u00f3w funkcjonalnych. <\/p>\n\n\n\n

    Przeczytaj r\u00f3wnie\u017c inne artyku\u0142y z\u00a0obszaru test\u00f3w i\u00a0Quality Assurance:<\/strong><\/p>\n\n\n\n