.<\/span><\/p>\nBardzo wa\u017cnym jest zatem, aby\u015b jako klient rozumia\u0142 rzeczywist\u0105 wag\u0119 pojawiaj\u0105cych si\u0119 b\u0142\u0119d\u00f3w i by\u0142 zapoznany z workflow projektowania aplikacji. Wtedy b\u0119dzie on w stanie lepiej nadawa\u0107 odpowiednie priorytety poszczeg\u00f3lnym zadaniom. B\u0119dzie wiedzia\u0142, czy wa\u017cniejszym jest np. dodanie nowej funkcjonalno\u015bci do aplikacji, czy naprawienie pojawiaj\u0105cego si\u0119 b\u0142\u0119du. Dzi\u0119ki temu procesy <\/span>testowania oprogramowania<\/b> i developmentu zostan\u0105 przeprowadzone w p\u0142ynny spos\u00f3b.<\/span><\/p>\nOcena efektywno\u015bci testowania oprogramowania<\/b><\/h3>\n
Do r\u00f3\u017cnic w zdaniach i problem\u00f3w w komunikacji dotycz\u0105cych przeprowadzonych <\/span>test\u00f3w<\/b> dochodzi tak\u017ce w kwestii ich efektywno\u015bci. Je\u017celi dany obszar aplikacji zosta\u0142 sprawdzony przez tester\u00f3w i nie znale\u017ali oni b\u0142\u0119d\u00f3w, mo\u017ce to by\u0107 spowodowane kilkoma rzeczami:<\/span><\/p>\n\n- rzeczywistym brakiem b\u0142\u0119d\u00f3w,<\/span><\/li>\n
- zbyt kr\u00f3tkim czasem po\u015bwi\u0119conym na <\/span>testowanie<\/b>,<\/span><\/li>\n
- brakiem uwzgl\u0119dnienia oczekiwa\u0144 klienta<\/b> w specyfikacji technicznej.<\/span><\/li>\n<\/ul>\n
\u00a0<\/span><\/p>\nCz\u0119stym problemem w pracy mi\u0119dzy klientem a zespo\u0142em tester\u00f3w jest mylne za\u0142o\u017cenie, i\u017c brak zg\u0142aszanych b\u0142\u0119d\u00f3w oznacza brak wykonywania test\u00f3w.<\/b><\/p>\n
\u0179r\u00f3d\u0142em nieporozumie\u0144 mo\u017ce by\u0107 tak\u017ce sytuacja, gdy efektywno\u015b\u0107 test\u00f3w spad\u0142a przez nieodpowiedni\u0105 ilo\u015b\u0107 czasu dobran\u0105 do wykonania zada\u0144. Je\u015bli po szybkich testach klient w\u0142asnor\u0119cznie odkryje niezg\u0142oszony wcze\u015bniej b\u0142\u0105d, nie musi to \u015bwiadczy\u0107 koniecznie o braku kompetencji tester\u00f3w. Je\u015bli niepoprawnie rozplanowany zostanie czas na <\/span>testowanie oprogramowania<\/b>, ucierpi na tym nie tylko jako\u015b\u0107 aplikacji, ale tak\u017ce bud\u017cet przeznaczony na proces developmentu. Zamiast poszukiwania winnych, <\/span>warto upewni\u0107 si\u0119, \u017ce testerzy maj\u0105 zapewnion\u0105 odpowiedni\u0105 ilo\u015b\u0107 godzin do sprawdzenia danych obszar\u00f3w projektu<\/b>.<\/span><\/p>\nKardynalnym b\u0142\u0119dem w komunikacji na poziomie wst\u0119pnej analizy jest brak uwzgl\u0119dnienia wymaga\u0144 klienta w specyfikacji. Bez jasno okre\u015blonych funkcji, kt\u00f3rych klient oczekuje w uko\u0144czonej aplikacji, testerzy nie b\u0119d\u0105 w stanie przeprowadzi\u0107 efektywnych <\/span>test\u00f3w<\/b>. Je\u015bli nie b\u0119d\u0105 wiedzieli jak co\u015b ma dzia\u0142a\u0107 docelowo, nie b\u0119d\u0105 mogli stwierdzi\u0107, \u017ce dzia\u0142a niepoprawnie.<\/span><\/p>\nJak usun\u0105\u0107 problemy w kontaktach z klientem omawiaj\u0105c proces testowania oprogramowania?<\/b><\/h4>\n
Najwa\u017cniejsz\u0105 rol\u0105 w omini\u0119ciu niezrozumie\u0144 pomi\u0119dzy zespo\u0142em testerskim i klientem jest jasno\u015b\u0107 w komunikacji i planowaniu proces\u00f3w zapewnieniu jako\u015bci. Obie strony musz\u0105 okre\u015bli\u0107:<\/span><\/p>\n\n- pe\u0142n\u0105 list\u0119 funkcjonalno\u015bci aplikacji,<\/span><\/li>\n
- czas przeznaczony na wszystkie procesy developmentu (w szczeg\u00f3lno\u015bci okres\u00f3w <\/span>testowania<\/b>),<\/span><\/li>\n
- czas potrzebny do <\/span>przetestowania<\/b> obszar\u00f3w projektu,<\/span><\/li>\n
- zasoby dost\u0119pne do wykonania zada\u0144 testowych,<\/span><\/li>\n
- liczb\u0119 regularnych spotka\u0144 catch-upowych,<\/span><\/li>\n
- charakterystyk\u0119 prac testowych,<\/span><\/li>\n
- specyfik\u0119 technologii u\u017cytych do developmentu projektu (mo\u017cliwo\u015bci i ograniczenia technologiczne).<\/span><\/li>\n<\/ul>\n
\u00a0<\/span><\/p>\nJakiekolwiek zastrze\u017cenia lub odst\u0119pstwa od uzgodnionych norm r\u00f3wnie\u017c powinny by\u0107 om\u00f3wione i uj\u0119te w planie pracy. Dzi\u0119ki temu i ci\u0105g\u0142ej komunikacji, zar\u00f3wno klient jak i zesp\u00f3\u0142 developerski b\u0119d\u0105 wiedzieli czego dok\u0142adnie spodziewa\u0107 si\u0119 od projektu. Takie zabezpieczenia przygotowuj\u0105 r\u00f3wnie\u017c na sytuacj\u0119 pojawienia si\u0119 komplikacji.<\/span><\/p>\nPodzia\u0142 test\u00f3w<\/b><\/h2>\n
To jakie <\/span>testy<\/b> b\u0119d\u0105 wykonywane, zale\u017cy w du\u017cej mierze od poziomu umiej\u0119tno\u015bci tester\u00f3w i od charakterystyki rozwijanego projektu. Sam fakt istnienia wielu rodzaj\u00f3w i typ\u00f3w <\/span>testowania oprogramowania<\/b> w bran\u017cy <\/span>eCommerce<\/b> nie oznacza, \u017ce ka\u017cda strona lub aplikacja b\u0119dzie wymaga\u0142a u\u017cycia wszystkich odmian. Musisz r\u00f3wnie\u017c pami\u0119ta\u0107, \u017ce nie mo\u017cna jednocze\u015bnie stwierdzi\u0107, i\u017c jakie\u015b testy s\u0105 lepsze od innych \u2013 wszystko zale\u017cy od specyfiki dzia\u0142ania projekt\u00f3w. R\u00f3\u017cne rodzaje <\/span>test\u00f3w<\/b> si\u0119 przenikaj\u0105 i nie mo\u017cna zrezygnowa\u0107 z jednego rodzaju, tylko dlatego, \u017ce wykona\u0142o si\u0119 inny typ. Poni\u017cej przedstawili\u015bmy podzia\u0142 typ\u00f3w <\/span>testowania<\/b> ze wzgl\u0119du na <\/span>rodzaj, poziom i typ<\/b>.<\/span><\/p>\nRodzaje test\u00f3w<\/b><\/h3>\n
Najszerszym podzia\u0142em <\/span>test\u00f3w<\/b> jest zr\u00f3\u017cnicowanie ich na <\/span>testy r\u0119czne (manualne) i automatyczne<\/b>. <\/span>Testy automatyczne<\/b> s\u0105 najbardziej op\u0142acalne przy <\/span>testach regresyjnych<\/b>, czyli takich, gdzie testowane s\u0105 wielokrotnie te same funkcje, a procedura <\/span>test\u00f3w<\/b> nie ulega zmianom. Wtedy aby zaoszcz\u0119dzi\u0107 czas mo\u017cna po prostu napisa\u0107 <\/span>test automatyczny<\/b>, kt\u00f3ry wykona te monotonne i powtarzalne dzia\u0142ania za testera.<\/span><\/p>\nSkoro mamy mo\u017cliwo\u015b\u0107 napisania procedur testuj\u0105cych, kt\u00f3re samodzielnie wykonywa\u0142yby prac\u0119 testowe, bez koszt\u00f3w utrzymywania specjalist\u00f3w, dlaczego nie mia\u0142by\u015b aplikowa\u0107 tego rodzaju <\/span>testowania<\/b> do wszystkich obszar\u00f3w? <\/span>Testy automatyczne<\/b> nie s\u0105 efektywne przy sprawdzaniu dzia\u0142ania nowych funkcjonalno\u015bci, przy kt\u00f3rych tester automatyzuj\u0105cy musi wykona\u0107 czynno\u015bci manualne i pozna\u0107 ich specyfik\u0119. Dodatkowo nie jest wskazanym wykonywa\u0107 <\/span>testy automatyczne<\/b>, gdy projektowany produkt nie jest jeszcze stabilny. Nie ma sensu w po\u015bpiesznym wykonywaniu <\/span>test\u00f3w automatycznych<\/b>, je\u015bli nasz projekt eCommerce nie posiada wszystkich zaplanowanych funkcji, kt\u00f3re maj\u0105 by\u0107 sprawdzone. Zatem, do momentu finalizacji produkcji nale\u017cy przeprowadza\u0107 <\/span>testy manualne<\/b>.\u00a0<\/span><\/p>\nPoziomowanie testowania<\/b><\/h3>\n
Testy jednostkowe<\/b> \u2013 wykonywane na najni\u017cszym poziomie aplikacji, czyli kodzie oprogramowania. Ten <\/span>poziom testowania<\/b> jest wykonywany przez samych programist\u00f3w pracuj\u0105cych nad kodem aplikacji lub strony. Polegaj\u0105 na <\/span>testowaniu<\/b> poszczeg\u00f3lnych metod funkcji i klas. Priorytetem jest tu jak najwi\u0119ksze procentowe pokrycie kodu \u017ar\u00f3d\u0142owego przez <\/span>testy jednostkowe<\/b>. Im wi\u0119ksze jest ich pokrycie, tym wcze\u015bniej programi\u015bci mog\u0105 wykry\u0107 b\u0142\u0119dy.\u00a0<\/span><\/p>\nTesty integracyjne<\/b> \u2013 podczas tych test\u00f3w sprawdzane s\u0105 zmiany wykonywane na dw\u00f3ch r\u00f3\u017cnych modu\u0142ach aplikacji, kt\u00f3re mog\u0105 dzia\u0142a\u0107 zale\u017cnie lub niezale\u017cnie od siebie. Do zada\u0144 testera w tym sposobie <\/span>testowania oprogramowania eCommerce<\/b> nale\u017cy sprawdzenie, czy zmiana w jednym module nie ponios\u0142a za sob\u0105 niepo\u017c\u0105danych skutk\u00f3w w funkcjonowaniu drugiego. W skr\u00f3cie, <\/span>testy integracyjne<\/b> sprawdzaj\u0105 funkcjonowanie aplikacji jako ca\u0142o\u015bci i <\/span>testowaniu<\/b> czy wprowadzenie zmian w jednym obszarze nie zaburzy dzia\u0142ania w innych.<\/span><\/p>\nTesty end-to-end<\/b> \u2013 <\/span>testy<\/b> te symuluj\u0105 zachowanie prawdziwego u\u017cytkownika i sprawdzaj\u0105, czy przy dzia\u0142aniach u\u017cytkownika wszystkie funkcje pracuj\u0105 zgodnie ze specyfikacj\u0105 projektow\u0105. Dobrym nawykiem przy wykonywaniu tego typu <\/span>test\u00f3w oprogramowania<\/b> jest przygotowanie scenariuszy dzia\u0142a\u0144 u\u017cytkownika pomagaj\u0105ce kontrolowa\u0107 obszary kt\u00f3re zosta\u0142y ju\u017c poddane sprawdzeniu, okre\u015bla\u0107 liczb\u0119 wymaganych poprawek, jak i r\u00f3wnie\u017c zaznacza\u0107 obszary jeszcze niesprawdzone.<\/span><\/p>\nTesty akceptacyjne<\/b> \u2013 teoretycznie s\u0105 to proste <\/span>testy<\/b>. Chodzi w nich o to, czy sko\u0144czony produkt spe\u0142nia warunki podane w specyfikacji projektowej sporz\u0105dzonej na pocz\u0105tku planowania ca\u0142ego projektu. Mo\u017cna powiedzie\u0107, \u017ce ten rodzaj <\/span>test\u00f3w<\/b> wykonuje zesp\u00f3\u0142 deweloper\u00f3w zesp\u00f3\u0142 z klientem, kt\u00f3ry sprawdza czy zosta\u0142y spe\u0142nione jego oczekiwania techniczne i biznesowe.<\/span><\/p>\nTypy testowania oprogramowania<\/b><\/h3>\n
Testy funkcjonalne <\/b>\u2013 s\u0105 wykonywane w celu sprawdzenia, czy aplikacja spe\u0142nia biznesowe wymagania dotycz\u0105ce kluczowych funkcji. Poprawnie przeprowadzony test funkcjonalny powinien zako\u0144czy\u0107 si\u0119 uzyskaniem warto\u015bci z bazy danych okre\u015blonej w specyfikacji projektowej. Podobnie jak testy integracyjne, odmiana funkcjonalna testuje wiele obszar\u00f3w i modu\u0142\u00f3w aplikacji.\u00a0<\/span><\/p>\nTesty wydajno\u015bci <\/b>\u2013 ich celem jest sprawdzenie jak wydajna jest aplikacja. Podczas tych test\u00f3w testerzy okre\u015blaj\u0105 stabilno\u015b\u0107 i osi\u0105gi produktu, np. czas potrzebny do przetworzenia wysokiej liczby zapyta\u0144. Testy te przydatne s\u0105 szczeg\u00f3lnie wtedy, gdy po aktualizacji aplikacji potrzebne jest sprawdzenie mo\u017cliwych spowolnie\u0144 w dzia\u0142aniu.<\/span><\/p>\nTesty dymne <\/b>\u2013 wykonywane s\u0105 przy wdro\u017ceniu aplikacje na nowe \u015brodowisko. S\u0105 szybkie w realizacji i za zadanie maj\u0105 sprawdzenie dzia\u0142ania podstawowych funkcji i poprawno\u015b\u0107 dzia\u0142ania aplikacji. Wykorzystuje si\u0119 je przy wprowadzeniu kolejnych cz\u0119\u015bci kodu i przed przyst\u0105pieniem do bardziej zaawansowanych test\u00f3w.<\/span><\/p>\nTesty eksploracyjne<\/b> \u2013 s\u0105 to testy manualne, kt\u00f3rych celem jest wykrycie b\u0142\u0119d\u00f3w nieszablonowych, czyli takich, kt\u00f3rych wykrycie za pomoc\u0105 test\u00f3w zautomatyzowanych by si\u0119 nie powiod\u0142o. Jej przebieg powinien by\u0107 z g\u00f3ry okre\u015blony, np. testerzy powinni po\u015bwi\u0119ci\u0107 na ten typ testowania okre\u015blon\u0105 ilo\u015b\u0107 czasu i przetestowa\u0107 tylko jasno sprecyzowany zakres funkcji.\u00a0<\/span><\/p>\nObszary najwi\u0119kszego zagro\u017cenia<\/b><\/h3>\n
Ze wzgl\u0119du na specyfik\u0119 i cel aplikacji <\/span>eCommerce’owej<\/b>, kt\u00f3ra ma umo\u017cliwi\u0107 kupno produktu przez u\u017cytkownika, najwi\u0119ksze zagro\u017cenie dla poprawnego funkcjonowania kryje si\u0119 w \u015bcie\u017cce zakupowej. Dobr\u0105 praktyk\u0105 dla testera b\u0119dzie stworzenie listy funkcjonalno\u015bci, kt\u00f3rych poprawne dzia\u0142anie jest krytyczne z punktu widzenia tego zadania. Sk\u0142adaj\u0105 si\u0119 na ni\u0105 takie funkcje jak: dodawanie przedmiot\u00f3w do koszyka, wy\u015bwietlanie listing\u00f3w i mo\u017cliwo\u015b\u0107 zap\u0142aty. Wa\u017cnym jest, i\u017c przy dodawaniu zmian, czy aktualizowaniu aplikacji w zupe\u0142nie innym obszarze trzeba te\u017c przeprowadzi\u0107 testy integracyjne. Ich zadaniem jest sprawdzenie, czy zmiany te nie odbi\u0142y si\u0119 na funkcjonalno\u015bci \u015bcie\u017cki zakupowej.<\/span><\/p>\nR\u00f3\u017cnice w podej\u015bciu do testowania odmiennych oprogramowa\u0144 w bran\u017cy eCommerce<\/b><\/h2>\n
Opr\u00f3cz r\u00f3\u017cnorodno\u015bci <\/span>metod testowania<\/b>, proces sprawdzania jako\u015bci i usuwania b\u0142\u0119d\u00f3w w bran\u017cy <\/span>eCommerce<\/b> zale\u017cny jest te\u017c od tego w jakiej technologii ma by\u0107 tworzona Twoja aplikacja. W handlu elektronicznym najcz\u0119stszymi odmianami s\u0105 <\/span>aplikacje natywne<\/b> (stworzone z my\u015bl\u0105 o konkretnym systemie operacyjnym) i <\/span>aplikacje progresywne<\/b> (zwane te\u017c aplikacjami webowymi, kt\u00f3re wykorzystuj\u0105 przegl\u0105darki urz\u0105dze\u0144 w celu omini\u0119cia r\u00f3\u017cnic systemowych). Ze wzgl\u0119du na inne przeznaczenie i odmienny proces developmentu wymagaj\u0105 one tak\u017ce r\u00f3\u017cnego podej\u015bcia i technik w zakresie <\/span>testowania oprogramowania<\/b>.<\/span><\/p>\n![\"testerzy](\"https:\/\/global4net.com\/wp-content\/uploads\/2021\/09\/testowanie-oprogramowania-inne-aplikacje.jpeg\")
<\/p>\n
Testowanie natywnych aplikacji<\/b><\/h3>\n
Pierwsz\u0105 rzecz\u0105, na jak\u0105 powiniene\u015b zwr\u00f3ci\u0107 uwag\u0119 przy procesie <\/span>testowania aplikacji<\/b> natywnych jest podzia\u0142 urz\u0105dze\u0144 i platformy systemowe, na kt\u00f3re s\u0105 projektowane. <\/span>Testowanie<\/b> b\u0119dzie przebiega\u0142o odmiennie na smartfonie, a inaczej na tablecie. <\/span>Testowanie oprogramowania<\/b> dla aplikacji natywnych powinno si\u0119 opiera\u0107 o weryfikacj\u0119 procesu ich instalacji. Oznacza to, \u017ce w ramach <\/span>test\u00f3w<\/b> nale\u017cy zainstalowa\u0107 projektowan\u0105 aplikacj\u0119 na dane urz\u0105dzenie. Trzeba zadba\u0107, aby <\/span>testy<\/b> odby\u0142y si\u0119 na ka\u017cdej z docelowych platform. Wi\u0105\u017c\u0119 si\u0119 to z wymogiem posiadania jednostek testowych (smartfon\u00f3w, tablet\u00f3w, itp).<\/span><\/p>\nAlternatyw\u0105 jest u\u017cycie <\/span>emulatora testowego<\/b>, kt\u00f3ry symuluje prac\u0119 mobilnego urz\u0105dzenia. Jednak oszcz\u0119dzanie \u015brodk\u00f3w w tym przypadku, mo\u017ce odnie\u015b\u0107 odwrotne wyniki, gdy\u017c emulatory tego typu nie wykrywaj\u0105 wszystkich b\u0142\u0119d\u00f3w. Zalecane jest <\/span>testowanie oprogramowania<\/b> na prawdziwych urz\u0105dzeniach, ze wzgl\u0119du na \u0142atwo\u015b\u0107 replikacji wykrytych b\u0142\u0119d\u00f3w. Dodatkowymi zaletami <\/span>test\u00f3w<\/b> na rzeczywistych platformach jest wy\u017csza dok\u0142adno\u015b\u0107 i uwzgl\u0119dnienie wi\u0119kszej ilo\u015bci zmiennych (roz\u0142adowuj\u0105cej si\u0119 baterii, powiadomienia push, geolokalizacji).<\/span><\/p>\nIm wi\u0119cej modeli urz\u0105dze\u0144 mobilnych masz dost\u0119pnych, tym dok\u0142adniejsze <\/span>testy aplikacji<\/b> jeste\u015b w stanie przeprowadzi\u0107. Obowi\u0105zkowym minimum przy <\/span>testowaniu aplikacji<\/b> natywnych powinny by\u0107 urz\u0105dzenia z systemami Android i iOS. Tylko wtedy Ty i Twoi testerzy b\u0119dziecie w stanie wykry\u0107 b\u0142\u0119dy dla obu platform systemowych.<\/span><\/p>\nTestowanie aplikacji PWA<\/b><\/h3>\n
Podstawowym podej\u015bciem do <\/span>testowania oprogramowa\u0144<\/b> progresywnych jest weryfikacja regu\u0142, kt\u00f3re dana aplikacja musi spe\u0142nia\u0107.<\/span><\/p>\n\n- responsywno\u015b\u0107<\/b>,<\/span><\/li>\n
- progresywno\u015b\u0107<\/b>,<\/span><\/li>\n
- dzia\u0142anie w trybie offline<\/b>,<\/span><\/li>\n
- “<\/span>instalowalno\u015b\u0107<\/b>‘ i “<\/span>
![\"testowanie](\"https:\/\/global4net.com\/wp-content\/uploads\/2021\/09\/testowanie-stron-ecommerce-komunikacja-klient.jpg\")
<\/p>\n