Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


07.06.2022

Red Hat Enterprise Linux 9

Red Hat zaprezentował system operacyjny Red Hat Enterprise Linux 9 (RHEL 9)...
07.06.2022

Technologiczna piaskownica

Koalicja partnerów KIR, IBM, Chmura Krajowa, PKO Bank Polski, Urząd Komisji Nadzoru...
07.06.2022

Sztuczna inteligencja w...

OVHcloud wprowadziło na rynek AI Notebooks – najnowszy element w ofercie usług...
07.06.2022

Spójna ochrona brzegu sieci

Fortinet zaprezentował FortiOS 7.2 – najnowszą wersję swojego flagowego systemu...
07.06.2022

Zarządzanie transferem

Firma Progress wypuściła nową wersję oprogramowania do zarządzania transferem plików...
07.06.2022

Notebook ekstremalny

Panasonic przedstawił 14-calowy Toughbook 40, notebook do pracy w ekstremalnych...
07.06.2022

Zestaw startowy dla robotyki

Firma AMD przedstawiła najnowszy produkt w portfolio adaptacyjnych modułów SOM...
07.06.2022

Precyzja kadrowania

Najnowsze rozwiązania klasy pro firmy Poly mają sprostać zmieniającym się potrzebom...
07.06.2022

Serwer klasy korporacyjnej

QNAP zaprezentował nowy model serwera NAS, TS-h1886XU-RP R2, który działa na systemie...

Wpływ testów regresji na ochronę danych osobowych

Data publikacji: 06-05-2022 Autor: Charlotta Lendzion

To jedna z kluczowych czynności, jaką powinno się wykonywać, aby zweryfikować stworzone oprogramowanie. Jednak w testach regresji chodzi o coś więcej niż uzyskanie oprogramowania najwyższej jakości. Ważne aby było ono odpowiednio zabezpieczone nie tylko fizycznie, ale również prawnie.

 

Wytwarzanie oprogramowania ma swój cykl życia. Podobnie wygląda sytuacja z samym testowaniem oprogramowania. Proces testów może obejmować przykładowo testy funkcjonalne, białoskrzynkowe, czarnoskrzynkowe, E2E, eksploracyjne, penetracyjne itp. natomiast jednym z istotnych rodzajów testów są testy regresji, nazywane również w niektórych źródłach testami regresywnymi. Ich celem jest przede wszystkim weryfikacja jakości wytworzonego oprogramowania – innymi słowy sprawdzamy, czy wprowadzone modyfikacje, zmiany i komponenty nie naruszyły innych procesów w działającym wcześniej oprogramowaniu.


 W praktyce testy regresji wyglądają tak, że po realizacji testów dotyczących wprowadzenia nowych modułów/rozwiązań realizuje się testy regresji weryfikujące, czy nie doszło do zmian/usterek w kluczowych elementach systemu informatycznego. Należy podkreślić, że testy regresji mogą dotyczyć kilku różnych rodzajów testów, np. obejmować testy regresji obszarów funkcjonalnych, niefunkcjonalnych, nawet kodu źródłowego, penetracyjne są też realizowane m.in. po wgraniu aktualizacji systemu operacyjnego. Zatem zakres ich stosowania jest dość szeroki, ale przede wszystkim trzeba mieć na uwadze, że są one jedną z kluczowych czynności, jaką powinno się wykonywać. Ich kluczowość nie wynika jedynie z tego, że trzeba przetestować oprogramowanie, aby jego jakość była na jak najwyższym poziomie; chodzi też o to, aby oprogramowanie było odpowiednio zabezpieczone nie tylko fizycznie, ale również prawnie i testowane cyklicznie, a nie jedynie incydentalnie.

Test testowi nierówny


Nie ma jednej recepty na idealne testy regresji, gdyż w zależności od wytwarzanego oprogramowania, organizacji, modelu pracy – wykorzystywanej metodyki (zwinna czy waterfallowa), czy chociażby od określonej branży testy regresji mogą być inne i będą się od siebie różnić. Inaczej będziemy podchodzić do testów regresji w małym sklepie internetowym, a inaczej, gdy mamy do czynienia z systemem bankowym czy medycznym, w którym przechowuje się dane wymagające szczególnego rodzaju ochrony.


Gregg Rothermel i Mary J. Harrold w swoim artykule „Analyzing Regression Test Selection Techniques” („IEEE Transactions on Software Engineering” 1996, vol. 22, no. 8) wskazali na istotny fakt, że w zależności od wyboru techniki przeprowadzenia testów regresji wyniki tej regresji będą zupełnie inne. Autorzy zidentyfikowali kategorie, w których techniki selekcji testów regresji mogą być porównywane i oceniane, a mianowicie: inkluzywność, precyzja, wydajność i ogólność. Jest to niewątpliwie istotna informacja i cały czas aktualna. Przeprowadzanie testów regresji powinno się bowiem skupiać nie tylko na wytypowaniu obszarów do przetestowania, ale również na odpowiedniej ocenie, dlaczego dany obszar powinien być przetestowany; należy też ustalić, jakie mają być wyniki testów, jaki ich zakres poprawności będzie dopuszczalny i mierzalny.


Warto pamiętać, że raz przygotowany zestaw testów nie będzie „ważny” w nieskończoność, innymi słowy systematycznie należy kontrolować/analizować poszczególne scenariusze testów regresji (czy wymagają one modyfikacji, zmian itp.). Głównie dlatego, że system informatyczny się zmienia, ewoluuje, dodawane są nowe komponenty, wprowadzane są testy automatyczne, co może prowadzić do konieczności modyfikowania weryfikacji samych testów regresji nie tylko w celach bezpieczeństwa i jakości, ale również ze względów prawnych.


Nie ulega wątpliwości, że systematycznemu przeglądowi i weryfikacji powinny również być poddawane testy automatyczne – zarówno te dotyczące regresji poszczególnych części systemu, jak i te sprawdzające, czy na środowiskach testowych po każdym „nadpisaniu” poprawnie zostały pobrane wszelkie dane. Przeważnie testy takie odbywają się na początku, kiedy to środowiska są „stawiane”, natomiast po jakimś czasie pozostawia się to do weryfikacji testów automatycznych, a trzeba mieć na uwadze, że te też mogą zawodzić. Podobnie będzie przy wyborze odpowiedniego rozwiązania testów regresji wykorzystujących język SQL, który może powodować pewne błędne wyniki testów.
    
Aspekty prawne


Po wejściu w życie przepisów rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych; dalej: rodo) wzrosło znaczenie testów oprogramowania, co już podkreślałam w innych moich publikacjach (np. „Istota testów oprogramowania w kontekście prawnym”, „IT Professional” 2022, nr 2). Natomiast testy regresji powinny być realizowane nie tylko po wprowadzaniu wszelkich modyfikacji, ale również w celu kontroli systemu informatycznego czy baz danych – jako cykliczne działania według przyjętego harmonogramu. Incydentalnego przeprowadzania testów tylko w sytuacji zmian nie można nazwać cylicznością. To niewątpliwie jedna z najważniejszych czynności, jaka powinna być wykonywana zgodnie z procedurami. Weryfikację proceduralną wykonuje się poprzez sprawdzanie, czy testy te są realizowane zgodnie z procedurami procesu biznesowego i prawnego (ang. verification compliance test flow) oraz czy są realizowane zgodnie z harmonogramem w celu należytej staranności przy ochronie danych osobowych i bezpieczeństwa informacji.

Planowanie w fazie projektowania


Zgodnie z artykułem 24 ust. 1 rodo administrator wdraża odpowiednie środki techniczne i organizacyjne, uwzględniając charakter, zakres, kontekst i cele przetwarzania oraz ryzyko naruszenia praw lub wolności osób fizycznych o różnym prawdopodobieństwie i wadze, aby przetwarzanie odbywało się zgodnie z rozporządzeniem i aby móc to wykazać. Środki te są w razie potrzeby poddawane przeglądom i uaktualniane. Przestrzeganie zasady integralności i poufności, określonej w art. 5 ust. 1 lit. f) rodo, jest obowiązkiem każdego administratora danych. Wdrożenie odpowiednich środków technicznych i organizacyjnych powinno wiązać się nie tylko z przyjęciem i wdrożeniem odpowiednich polityk oraz regulaminów dotyczących testowania, ale również dokonywaniem cyklicznych, regularnych przeglądów tych środków i – jeżeli zachodzi konieczność – ich aktualizacji. Dlatego tak ważne jest, aby już w fazie projektowania uwzględniać odpowiednio zakres i rodzaje testów regresji. W świetle motywu 78 rodo: „Ochrona praw i wolności osób fizycznych w związku z przetwarzaniem danych osobowych wymaga wdrożenia odpowiednich środków technicznych i organizacyjnych, by zapewnić spełnienie wymogów niniejszego rozporządzenia. Aby móc wykazać przestrzeganie niniejszego rozporządzenia, administrator powinien przyjąć wewnętrzne polityki i wdrożyć środki, które są zgodne w szczególności z zasadą uwzględniania ochrony danych w fazie projektowania oraz z zasadą domyślnej ochrony danych. Takie środki mogą polegać m.in. na minimalizacji przetwarzania danych osobowych, jak najszybszej pseudonimizacji danych osobowych (…)”.

 

[...]

 

Autorka jest prawnikiem, właścicielem llegal.pl, stałym mediatorem przy Sądzie Okręgowym w Gdańsku specjalizującym się w mediacjach z zakresu własności intelektualnej. Członkini Stowarzyszenia Praktyków Ochrony Danych SPOD. Autorka książki o odpowiedzialności odszkodowawczej. Audytor wewnętrzny w zakresie bezpieczeństwa informacji oraz systemu zarządzania jakością. Certyfikowany tester oprogramowania ISTQB. Z branżą IT związana od 2012 r. Obecnie w trakcie badań naukowych w ramach pracy doktorskiej z zakresu prawa nowych technologii.

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"