{"id":29612,"date":"2022-08-03T13:41:35","date_gmt":"2022-08-03T11:41:35","guid":{"rendered":"https:\/\/nearshore-it.eu\/artykuly\/testy-regresji\/"},"modified":"2024-11-07T12:32:10","modified_gmt":"2024-11-07T11:32:10","slug":"testy-regresji","status":"publish","type":"post","link":"https:\/\/nearshore-it.eu\/pl\/artykuly\/testy-regresji\/","title":{"rendered":"Test regresji \u2013 strata czasu czy must have w projekcie?"},"content":{"rendered":"\n
\n

<\/p>\n

    \n
  1. 1. Rozw\u00f3j oprogramowania a testowanie regresyjne<\/a><\/li>\n
  2. 2. Co to s\u0105 testy regresji?<\/a><\/li>\n
  3. 3. Jak cz\u0119sto przeprowadza\u0107 testy regresji?<\/a><\/li>\n
  4. 4. Na jakim poziomie przeprowadza si\u0119 testy regresji?<\/a><\/li>\n
  5. 5. Tworzenie przypadk\u00f3w testowych<\/a><\/li>\n
  6. 6. Wyb\u00f3r przypadk\u00f3w testowych w regresji<\/a><\/li>\n
  7. 7. Co robimy podczas sprawdzania regresji? <\/a><\/li>\n
  8. 8. Regresja a retesty \u2013 jaka jest r\u00f3\u017cnica?<\/a><\/li>\n
  9. 9. W jaki spos\u00f3b wykonujemy testy? Czyli automatyzacja w regresji<\/a><\/li>\n
  10. 10. Testowanie regresji \u2013 korzy\u015bci <\/a><\/li>\n
  11. 11. Podsumowanie <\/a><\/li>\n <\/ol>\n<\/div>\n\n\n

    Rozw\u00f3j oprogramowania a testowanie regresyjne<\/h2>\n\n\n\n

    Wyobra\u017amy sobie, \u017ce mamy ju\u017c dzia\u0142aj\u0105c\u0105 w \u015brodowisku produkcyjnym aplikacj\u0119. Klient jest bardzo zadowolony, poniewa\u017c cieszy si\u0119 ona popularno\u015bci\u0105 w\u015br\u00f3d u\u017cytkownik\u00f3w, i chce doda\u0107 now\u0105 funkcjonalno\u015b\u0107, kt\u00f3ra ma zwi\u0119kszy\u0107 ich zadowolenie oraz spowodowa\u0107 nap\u0142yw nowych. Zesp\u00f3\u0142 projektowy ju\u017c pali si\u0119 do pracy: nowa funkcjonalno\u015b\u0107, nowe zadanie, nowe wyzwanie! Po ustaleniu szczeg\u00f3\u0142\u00f3w developerzy ochoczo zabrali si\u0119 do pracy. Nast\u0119pnie testerzy sprawdzili now\u0105 funkcjonalno\u015b\u0107. Po drobnych poprawkach wszystko dzia\u0142a. Czas wrzuci\u0107 now\u0105 funkcjonalno\u015b\u0107 na produkcj\u0119. Gdy nadszed\u0142 dzie\u0144 wypuszczenia nowej wersji aplikacji, wszyscy byli szcz\u0119\u015bliwi, \u017ce projekt uda\u0142o si\u0119 zrealizowa\u0107 w terminie i zgodnie z wymaganiami.<\/p>\n\n\n\n

    Niestety, szcz\u0119\u015bcie nie trwa\u0142o d\u0142ugo\u2026 Ju\u017c dzie\u0144 p\u00f3\u017aniej serwis zosta\u0142 zasypany zg\u0142oszeniami, \u017ce nie wszystkie dotychczasowe funkcje aplikacji dzia\u0142aj\u0105 prawid\u0142owo. W zespole zdziwienie: przecie\u017c nawet nie ruszali\u015bmy tych funkcjonalno\u015bci, a nowo dodana dzia\u0142a w prawid\u0142owy spos\u00f3b. Co posz\u0142o nie tak?<\/strong><\/p>\n\n\n\n

    Smutne skutki braku test\u00f3w regresji…<\/h3>\n\n\n\n
    \n

    Ot\u00f3\u017c zabrak\u0142o jednego, ale jak\u017ce istotnego elementu w procesie testowania. Nie sprawdzono, czy nowo dodana funkcjonalno\u015b\u0107 nie wp\u0142yn\u0119\u0142a na te, kt\u00f3re ju\u017c w aplikacji istnia\u0142y. <\/strong>Innymi s\u0142owy, nie przeprowadzono test\u00f3w regresji.<\/p>\n\n\n\n

    Brak test\u00f3w regresji spowodowa\u0142, \u017ce aplikacja nie tylko nie zyska\u0142a nowych u\u017cytkownik\u00f3w, ale straci\u0142a te\u017c znaczn\u0105 cz\u0119\u015b\u0107 dotychczasowych. Utraci\u0142a swoj\u0105 wysok\u0105 pozycj\u0119 w rankingach, spad\u0142y zyski, co spowodowa\u0142o spore niezadowolenie klienta.<\/p>\n<\/div><\/div>\n\n\n\n

    Co to s\u0105 testy regresji?<\/h2>\n\n\n\n

    Definicja wed\u0142ug s\u0142ownika ISTQB m\u00f3wi, \u017ce testowanie regresji to: \u201eRodzaj testowania zwi\u0105zanego ze zmianami maj\u0105cy na celu wykrycie, czy defekty zosta\u0142y wprowadzone lub odkryte w niezmienionych obszarach oprogramowania\u201d.<\/em><\/p>\n\n\n\n

    Przedstawiaj\u0105c to w bardziej obrazowy spos\u00f3b: w trakcie test\u00f3w sprawdzamy, czy \u201epodczas k\u0142adzenia tapety w jednym pokoju nie odpad\u0142 nam tynk ze \u015bciany w drugim pokoju”. Wszelkie zmiany w kodzie w jednym miejscu mog\u0105 spowodowa\u0107 zepsucie funkcji w innym,<\/strong> cho\u0107 na pierwszy rzut oka wydaje si\u0119, \u017ce nie s\u0105 one ze sob\u0105 powi\u0105zane. Dlatego tak wa\u017cne jest ponowne przetestowanie oprogramowania po wprowadzonych zmianach.<\/p>\n\n\n\n

    Przeczytaj artyku\u0142: <\/strong>Testowanie oprogramowania \u2013 poznaj \u015bwiat test\u00f3w<\/a><\/p>\n\n\n\n

    Jak cz\u0119sto przeprowadza\u0107 testy regresji?<\/h2>\n\n\n\n

    Widzimy ju\u017c, jak istotne jest, \u017ceby upewni\u0107 si\u0119, czy zmiany nie wp\u0142yn\u0119\u0142y negatywnie na dotychczasowe funkcje, i znale\u017a\u0107 b\u0142\u0119dy odpowiednio wcze\u015bnie. Wprowadzane zmiany mog\u0105 wynika\u0107 z modyfikacji wymaga\u0144 i kodu oprogramowania, dodania nowych funkcjonalno\u015bci czy naprawy usterki, dlatego wa\u017cne jest, aby testy regresji by\u0142y przeprowadzane tak cz\u0119sto, jak wydawana jest nowa wersja oprogramowania.<\/p>\n\n\n\n

    Na jakim poziomie przeprowadza si\u0119 testy regresji?<\/h2>\n\n\n\n
    <\/div>\n\n\n
    \n
    \"piramida<\/figure>\n<\/div>\n\n\n
    <\/div>\n\n\n\n

    Testy regresji s\u0105 niezale\u017cne od poziomu test\u00f3w <\/a>oraz ich rodzaj\u00f3w. Mo\u017cna je przeprowadza\u0107 na poziomie test\u00f3w modu\u0142owych, integracyjnych, systemowych czy te\u017c akceptacyjnych i niezale\u017cnie od tego, czy mamy do czynienia z testami funkcjonalnymi,<\/a> czy niefunkcjonalnymi.<\/a><\/p>\n\n\n\n

    <\/div>\n\n\n\n

    Tworzenie przypadk\u00f3w testowych<\/h2>\n\n\n\n

    Podczas sprawdzania oprogramowania tester tworzy przypadki testowe. Nie wszystkie jednak wejd\u0105 do puli przypadk\u00f3w wykonywanych podczas regresji. Od czego to zale\u017cy? <\/p>\n\n\n\n

    Przede wszystkim od ich ilo\u015bci i czasu, jaki trzeba po\u015bwi\u0119ci\u0107, aby je wykona\u0107. <\/strong>Je\u017celi mamy do czynienia z nierozbudowanym systemem i wykonanie wszystkich przypadk\u00f3w testowych podczas przeprowadzania test\u00f3w regresji nie zajmie zbyt wiele czasu \u2013 to jak najbardziej mo\u017cna je wykona\u0107.<\/p>\n\n\n\n

    Najcz\u0119\u015bciej jednak systemy czy aplikacje s\u0105 mocno rozbudowane i zale\u017cne od innych system\u00f3w. Nie jeste\u015bmy wtedy w stanie u\u017cy\u0107 wszystkich utworzonych przypadk\u00f3w testowych. Czym w takim razie si\u0119 kierowa\u0107 podczas wyboru przypadk\u00f3w, kt\u00f3re powinny si\u0119 znale\u017a\u0107 na li\u015bcie podczas wykonywania test\u00f3w regresji?<\/p>\n\n\n\n

    Wyb\u00f3r przypadk\u00f3w testowych w regresji<\/h2>\n\n\n\n

    Je\u017celi musimy si\u0119 ograniczy\u0107, warto odpowiednio dobra\u0107 zestaw przypadk\u00f3w testowych. Ujmijmy koniecznie te przypadki, kt\u00f3re:<\/p>\n\n\n\n

      \n
    1. Sprawdzaj\u0105 najbardziej krytyczne funkcje <\/strong>\u2013 przede wszystkim nale\u017cy uwzgl\u0119dni\u0107 przypadki testowe, kt\u00f3re weryfikuj\u0105 dzia\u0142anie g\u0142\u00f3wnych funkcji aplikacji albo sprawdzaj\u0105 cz\u0119sto u\u017cywane funkcjonalno\u015bci.<\/li>\n\n\n\n
    2. Powsta\u0142y na bazie defekt\u00f3w <\/strong>\u2013 przypadki testowe, kt\u00f3re powsta\u0142y na bazie zg\u0142oszonych defekt\u00f3w, s\u0105 wa\u017cne.<\/li>\n\n\n\n
    3. Weryfikuj\u0105 podatno\u015b\u0107 na b\u0142\u0119dy <\/strong>\u2013 warto si\u0119 zastanowi\u0107, kt\u00f3ry obszar aplikacji jest najbardziej nara\u017cony na b\u0142\u0119dy po wprowadzonej zmianie, i podczas test\u00f3w regresji wykona\u0107 tak\u017ce przypadki testowe z danego obszaru. <\/li>\n\n\n\n
    4. Sprawdzaj\u0105 now\u0105 funkcjonalno\u015b\u0107 <\/strong>\u2013 nie mo\u017cemy r\u00f3wnie\u017c zapomnie\u0107 o przypadkach testowych, kt\u00f3re sprawdzaj\u0105 nowo dodan\u0105 funkcjonalno\u015b\u0107. <\/li>\n\n\n\n
    5. Wymagaj\u0105 wielu krok\u00f3w <\/strong>\u2013 pami\u0119tajmy te\u017c o z\u0142o\u017conych przypadkach testowych wymagaj\u0105cych wykonania d\u0142u\u017cszej sekwencji czynno\u015bci.<\/li>\n<\/ol>\n\n\n\n

      Odpowiedni priorytet<\/h3>\n\n\n\n

      Wa\u017cne jest r\u00f3wnie\u017c odpowiednie nadanie priorytetu przypadkom testowym. Pomaga to w ich doborze, szczeg\u00f3lnie wtedy, kiedy zakres obszaru test\u00f3w jest du\u017cy, a czasu na ich wykonanie \u2013 ma\u0142o.<\/p>\n\n\n\n

      W takiej sytuacji tester, uwzgl\u0119dniaj\u0105c czas, jaki ma na wykonanie test\u00f3w, wybiera przypadki testowe o najwy\u017cszym priorytecie. Daje nam to pewno\u015b\u0107, \u017ce sprawdzone b\u0119d\u0105 najbardziej krytyczne obszary aplikacji. Pozosta\u0142e przypadki z ni\u017cszym priorytetem, kt\u00f3re nie by\u0142y wykonane w czasie regresji, nale\u017cy umie\u015bci\u0107 w raporcie ko\u0144cowym, odpowiednio je oznaczaj\u0105c jako niewykonane. <\/p>\n\n\n\n

      Jak nadawa\u0107 priorytety przypadkom testowym?<\/h3>\n\n\n\n

      Podczas nadawania priorytet\u00f3w przypadkom testowym nale\u017cy wzi\u0105\u0107 pod uwag\u0119 kilka czynnik\u00f3w:<\/p>\n\n\n\n