Metodyka testów Soflab Test Approach

sie 31, 2022 | Metodyka testów

Testowanie oprogramowania to bardzo istotna część procesu zapewniania jakości – istotna, ale niełatwa. Przypomina trochę budowanie z klocków Lego: gdy mamy instrukcję, a klocki są posortowane, dobranie odpowiednich elementów i skonstruowanie budowli nie przysparza większych trudności. Jednakże budowanie bez instrukcji, z rozsypanych w różnych miejscach klocków, jest już dużym wyzwaniem. Analogicznie jest w przypadku projektu informatycznego, gdy nie wiemy, które elementy z dziedziny zapewniania jakości wybrać i jak je poukładać. Źle to wróży na przyszłość – testy będą prawdopodobnie czasochłonne, a ich przeprowadzenie pociągnie za sobą dodatkowe koszty i, co za tym idzie – stres. Jeżeli jednak dysponujemy właściwymi elementami oraz instrukcją w postaci gotowego i sprawdzonego podejścia do testowania, zadanie staje się dużo prostsze. Taką właśnie instrukcją do przeprowadzania testów i zapewniania jakości projektów jest autorska Metodyka Testów Soflab Test Approach.

Czym jest Soflab Test Approach?

Soflab Test Approach to nasz wypróbowany i niezawodny model postępowania, przystosowany do wszystkich rodzajów projektów, niezależnie od ich wielkości, czy przyjętej metodyki wytwarzania oprogramowania.
Przy opracowywaniu tego podejścia położyliśmy duży nacisk na praktyczne zastosowanie rekomendacji zawartych w normie ISO/IEC/IEEE 29119 „Software and systems engineering — Software testing”. Uwzględniliśmy również wytyczne takich międzynarodowych standardów, jak:

  • Normy ISO dotyczące zarządzania jakością z rodziny 9000 (obecnie 2500x), 90003,
  • IEEE, w tym 829 „Software test documentation”, 1012 „Standard for System and Software Verification and Validation”, 1044 „Standard Classification for Software Anomalies”,
  • International Software Testing Qualifications Board, w tym ISTQB Advanced & Expert Level Syllabus.

Nie poprzestaliśmy jednak na tym – ogromną rolę w tworzeniu naszej metodyki odegrało doświadczenie zespołu Soflab zebrane w toku setek różnorodnych projektów zrealizowanych na przestrzeni kilkunastu lat. Z tego bogatego dorobku wybraliśmy najlepsze praktyki, które sprawdziły się w najtrudniejszych sytuacjach. Przygotowaną tak strategię uzupełniliśmy o wnioski płynące ze współpracy z klientami, uwzględniając ich specyfikę, potrzeby i wymagania. Powstało w ten sposób elastyczne i nowoczesne podejście do zapewniania jakości projektów informatycznych, które stale doskonalimy i dostosowujemy do zmieniających się uwarunkowań.

Jak stosować Soflab Test Approach w praktyce

Aby skutecznie wykorzystać Soflab Test Approach, musimy odpowiedzieć sobie na kilka bardzo ważnych pytań. Przyjmijmy teraz perspektywę klienta i wspólnie prześledźmy kolejne etapy naszej instrukcji.

1. Metodyki zwinne czy Waterfall?

Pierwszy krok to ustalenie, jaka metodyka wytwarzania oprogramowania jest stosowana w danym projekcie. Zazwyczaj jest to jedno z dwóch podejść – Waterfall (kaskadowe) lub Agile (tzw. zwinne). Oczywiście, w stosunku do metodyk zwinnych, których odmian jest wiele, jest to pewne uproszczenie, nie ma jednak znaczenia, z którą implementacją mamy do czynienia – czy będzie to Scrum, Kanban czy też XP, zastosowanie konkretnego typu metodyk zwinnych wpłynie tylko na szczegóły postępowania, nie na ogólne podejście do testów.
Warto wspomnieć, że Agile i Waterfall to nie jedyne możliwości. Jeśli dopiero planujemy zmiany w kierunku większej zwinności w prowadzeniu projektów, ale nie jesteśmy jeszcze gotowi na zastosowanie w pełni podejścia Agile, możliwy jest wybór metodyki hybrydowej Water-Scrum-Fall, łączącej cechy Waterfall i Agile.

2. Jaka jest wielkość planowanego projektu informatycznego?

Następnym krokiem będzie odpowiedź na pytanie o skalę testowanego projektu. W uproszczeniu można powiedzieć, że wielkość zespołu testowego określamy na podstawie rozmiarów i czasu trwania projektu informatycznego.

Rys 1. Definicje wielkości projektów / Soflab

W małych i średnich projektach prowadzonych kaskadowo (Waterfall) tworzymy autonomiczny zespół testerów, w Agile natomiast tester pracuje w ramach zespołów deweloperskich. Przy dużych projektach zwinnych często powołujemy dodatkowo niezależny, zewnętrzny zespół w celu przeprowadzenia testów specjalistycznych, takich jak testy bezpieczeństwa, wydajności, czy procesów E2E. Powyższa tabela nie uwzględnia metodyki hybrydowej Water-Scrum-Fall, gdyż w podejściu tym testy realizowane są analogicznie jak w Waterfall.

3. Obsada zespołu testerów

Znając metodykę wytwarzania oprogramowania oraz skalę projektu, możemy przejść do ustalenia, kto będzie potrzebny podczas procesu testowego.

Rys 2. Role testowe w metodykach kaskadowych i zwinnych / Soflab

W przypadku małych projektów kaskadowych często zdarza się, że ta sama osoba wykonuje zadania przypisane do różnych ról, na przykład obowiązki Specjalisty Raportowania mogą być wykonywane przez Lidera Testów. Analogicznie w małych projektach realizowanych zwinnie – gdy w zespole deweloperskim jest jedna osoba wykonująca testy, będzie ona pełniła rolę zarówno Analityka testów, jak i Testera.

Przy większych projektach możliwa jest odwrotna sytuacja. Załóżmy, że projekt jest na tyle duży, że wymaga udziału wielu Analityków Testów. Wówczas utworzony zostanie zespół na czele z Głównym Analitykiem Testów, który oprócz koordynowania prac zespołu będzie miał za zadanie zarządzanie zakresem testów całego programu.

4. Implementacja Modelu Procesu Testowego

I tu przechodzimy do podstawowego, wzorcowego Modelu Procesu Testowego, który wygląda następująco:

Model ten może być stosowany w każdym podejściu do wytwarzania oprogramowania, przyjęta metodyka ma jednak wpływ na jego implementację i na to, w jaki sposób mapujemy role na poszczególne procesy testowe. I tak zastosowanie Modelu w podejściu zwinnym może wyglądać następująco:

Natomiast w podejściu Waterfall – w ten sposób:

5. Jakie planujemy poziomy testów?

Następny krok dotyczy tzw. poziomów testów, czyli zaplanowania, od którego poziomu (na jakim etapie procesu wytwarzania oprogramowania) będziemy przeprowadzać testy. Jest to bardzo ważne, ponieważ każdy z tych etapów wymaga innych czynności testowych. W zależności od fazy procesu wytwórczego, testy dzielimy na:

  • Testy modułowe* inaczej zwane testowaniem komponentów
  • Testy Integracyjne modułów i systemów
  • Testy Systemowe
  • Testy Akceptacyjne, zwane też odbiorczymi lub UAT
  • Testy Produkcyjne

*W przypadku Agile dodatkowo uwzględniamy testy jednostkowe, które powinny być wykonywane przez programistów w ramach zespołu deweloperskiego.

Podział ten nie jest ściśle powiązany z metodyką wytwarzania oprogramowania. Należy natomiast wziąć pod uwagę inną zależność – koszty naprawy defektów wykrytych w późniejszych fazach procesu wytwórczego są większe, w związku z czym warto planować testy na jak najwcześniejszym etapie.

6. Jakie typy testów zastosujemy?

Klasyfikacji testów jest wiele. Na tym etapie dobrze jest skupić się na podziale, który uwzględnia testowaną cechę oprogramowania. Patrząc z tej perspektywy, testy dzielimy na funkcjonalne i niefunkcjonalne. Pierwsze sprawdzają, „co system robi”, drugie – odpowiadają na pytanie „jak system działa”. Przy projektowaniu zakresu testów funkcjonalnych w średnich i dużych projektach wykorzystujemy Matrycę Testów[i] i uproszczone podejście Risk Based Testing, jak również korzystamy z różnorodnych, odpowiednio dobranych klasycznych technik projektowania testów, żeby zapewnić niezbędne pokrycie testami. Pamiętajmy jednak, że zanim wybierzemy właściwą technikę, warto upewnić się, czy dysponujemy aktualną dokumentacją, spisanymi wymaganiami oraz harmonogramem testów. W przypadku braku dokumentacji lub konieczności pracy pod presją czasu proponujemy techniki oparte na doświadczeniu, w których stosuje się przykładowo nieformalne testowanie eksploracyjne.
Jeśli natomiast chodzi o testy niefunkcjonalne, przy ich wyborze uwzględniamy specyficzne potrzeby i kontekst klienta. Do najczęściej stosowanych testów niefunkcjonalnych należą testy wydajnościowe, testy bezpieczeństwa, użyteczności i migracji.
To, że poziomy testów nie zależą od przyjętej metodyki wytwarzania oprogramowania nie znaczy jednak, że możemy abstrahować od kontekstu, w jakim są przeprowadzane. Gdy zwinnie realizujemy duży projekt, w który zaangażowani są różni dostawcy oprogramowania, często powołujemy zewnętrzne zespoły testowe niezależne do zespołów deweloperskich. W ramach takiego zespołu realizowane są przykładowo testy systemowe, obejmujące zarówno testy niefunkcjonalne, jak i funkcjonalne całego produktu.
W przypadku małego — np. jednozespołowego projektu – testy niefunkcjonalne będą realizowane przez zespół w ramach DoD(definition of done).

[i] W podejściu zwinnym Matryca Testów ma zastosowanie jedynie dla testów prowadzonych w zespołach specjalistycznych poza zespołami deweloperskimi

7. Znaczenie automatyzacji testów

Kolejny krok, który, zgodnie z naszą instrukcją, należy wykonać, to planowanie automatyzacji testów. O tym, że warto, a nawet trzeba uwzględnić automatyzację testów, nie musimy nikogo przekonywać. Zdarzają się oczywiście sytuacje, w których całościowe koszty automatyzacji są, wbrew wyobrażeniom, większe niż przeprowadzenie testów manualnych – dotyczy to zwłaszcza krótkich, prostych przedsięwzięć. Im jednak większe i bardziej złożone projekty, tym większy zysk z automatyzacji. Warto wspomnieć, że zwłaszcza projekty prowadzone zgodnie z podejściem zwinnym, ze względu na dużą ilość wdrożeń wymagają szerokiego zastosowania testów automatycznych.
Testy regresji to jeden z obszarów, który najczęściej podlega automatyzacji. Ale jest ona bardzo przydatna również w innych sytuacjach, na przykład przy generowaniu danych testowych potrzebnych do testów manualnych, przy przeprowadzaniu testów dymnych, czy też testów interfejsów API dla integracji systemów. Te ostatnie testy zasługują na szczególną uwagę ze względu na światowe tendencje rozwoju narzędzi do automatyzacji. Producenci tych rozwiązań zakładają, że w przyszłości testy API będą stanowić około 75 procent zautomatyzowanych testów i że to na nie położony zostanie największy nacisk.

Jeśli wybraliśmy metodykę Agile, dobrze będzie na tym etapie zastanowić się, jaki chcemy przyjąć schemat organizacyjny dla zespołu obsługującego testy automatyczne. Czy będzie to tester automatyzujący w ramach zespołu deweloperskiego, analityk automatyzacji pracujący w zespole, ale wspierany przez zespół automatyzacji testów, czy może niezależny zewnętrzny zespół testów automatyzacji?

8. Narzędzia do automatyzacji i do zarządzania testami

Przy planowaniu automatyzacji testów musimy brać pod uwagę nie tylko schemat organizacyjny zespołu, ale również technologię i narzędzia, za pomocą których będzie realizowana. Podobnie dla całego procesu testowego potrzebne są narzędzia do zarządzania testami i defektami oraz narzędzia do realizacji testów niefunkcjonalnych, np. wydajnościowych. Być może w naszej działalności korzystamy już z tego typu programów – popularna Jira na przykład jest często używana przez analityków biznesowych do dokumentowania wymagań. Trzeba jednak upewnić się, czy stosowane narzędzie spełnia wszystkie nasze potrzeby i czy nie będzie konieczne na przykład przeprowadzenie dodatkowej konfiguracji lub zainstalowanie dodatku do zarządzania testami.

9. Jak planujemy raportować statusy testów?

Raportowanie statusu testów jest niezwykle istotnym elementem realizacji projektów. Odpowiednio zebrane i zaprezentowane informacje umożliwiają kontrolę istotnych aspektów projektu, a także wspomagają optymalizację procesu testowego.
Zakres i sposób raportowania będą zmieniać się w zależności od rozmiaru i charakteru projektu, zasadniczo jednak powinniśmy podczas planowania uwzględnić:

  • Raport Dzienny Statusu Testów,
  • Raport Tygodniowy Statusu Testów,
  • Raport Końcowy z Testów.

Raporty mogą przyjmować różne formy, ale ich zawartość i wykorzystywane metryki zawsze muszą być dostosowane do bieżących potrzeb projektowych i podporządkowane najważniejszemu celowi, jakim jest dostarczenie dokładnie tych informacji, których – w myśl wcześniejszych uzgodnień – potrzebują adresaci raportów. Dostępnych jest wiele predefiniowanych metryk, które bardzo ułatwiają tworzenie raportów.
Standardowo w raportach dziennych i tygodniowych informujemy o postępach w realizacji testów, zamieszczamy statystyki defektów, omawiamy ryzyka i problemy oraz kluczowe defekty, ukazane w odpowiedniej perspektywie. W metodykach zwinnych, takich jak Scrum, zbieranie uzgodnionych metryk ma poniekąd miejsce w czasie Daily, kiedy tester z zespołu deweloperskiego przekazuje w formie ustnej dane o postępach w pracy, informuje o dalszych planach i sygnalizuje możliwe zagrożenia. Metryki te są następnie analizowane na zamknięcie Sprintu, a w dalszej kolejności stanowią źródło informacji przekazywanych podczas Retrospektywy.
W sytuacji gdy testy realizowane są w zespołach specjalistycznych, konieczne jest zdefiniowanie innego zestawu metryk, niż w przypadku testów realizowanych w ramach zespołów deweloperskich.
Warto pamiętać, że narzędzia wspierające testy mają często wbudowane możliwości automatyzacji raportowania, z których można skorzystać.
Raport Końcowy z Testów, tworzony na zakończenie projektu, umożliwia ocenę jakości testowanego produktu. W metodykach zwinnych powstaje on najczęściej na zakończenie serii iteracji, przed planowanym wdrożeniem nowej, istotnej funkcjonalności. Raport Końcowy powinien także powstać na zakończenie testów realizowanych przez specjalistyczne zespoły w ramach projektu, osobno dla każdego typu testów.
W Raporcie Końcowym uwzględniamy zakres zrealizowanych testów, łącznie z odstępstwami od zaplanowanego zakresu, podsumowanie przebiegu prac, w tym napotkanych trudności oraz podsumowanie wyników testów.

10. Jak udokumentować zrealizowane testy?

W podejściu Agile sprawne i skuteczne działanie oprogramowania ma większe znaczenie niż sporządzenie szczegółowej dokumentacji z przebiegu prac, dlatego też nie znajdują tu zastosowania niektóre formaty wykorzystywane w metodyce kaskadowej (np. Matryca Testów). Warto jednak przemyśleć, jak w metodykach zwinnych ewidencjonować spełnienie kryteriów akceptacji – czy to poprzez tworzenie przypadków testowych, czy w inny sposób – aby uzyskać jednoznaczne potwierdzenie weryfikacji każdego z kryteriów. Od przyjętego podejścia zależy logowanie wykonania testów. To samo dotyczy raportowania defektów i ustalenia, kiedy defekt może być zgłoszony tylko ustnie deweloperowi.

I tak przeszliśmy przez wszystkie etapy naszej instrukcji – od metodyki wytwarzania po dokumentację procesu testowego. Wdrażanie poszczególnych etapów tej instrukcji może – co do szczegółów – przebiegać różnie w różnych sytuacjach, w zależności od indywidualnych uwarunkowań i potrzeb klienta, które są dla nas zawsze priorytetem. W każdym wypadku jednak metodyka Soflab Test Approach dostarcza przejrzystego, uniwersalnego i sprawdzonego modelu postępowania, na którym bez wahania można się oprzeć.

Jeżeli chcesz wdrożyć metodykę testów, czy też uporządkować działania związane z testami prowadzone w Twojej firmie; jeśli chcesz zyskać pewność, że podejście to będzie oparte o światowe normy i najlepsze praktyki; jeśli poszukujesz profesjonalistów, którzy będą służyć Ci pomocą w opracowaniu strategii i realizacji testów, koniecznie skontaktuj się z nami.

Polecamy również

Jak zaprojektować optymalny dashboard?

Właściwie przygotowane Dashboardy to klucz do efektywnego zarządzania testami w dużych projektach IT

Jak zaprojektować optymalny dashboard? Na co warto zwrócić szczególną uwagę, aby narzędzia, które zbudujemy były skuteczne, dostarczały wartościowych informacji i przyczyniały się do zwiększenia efektywności projektu? Odpowiedzi na te i wiele innych pytań znajdują się w poniższym artykule.

generowanie danych testowych

Poznaj sposoby generowania danych testowych na przykładzie dostępnych narzędzi

Na etapie projektowania testów jednym z kluczowych zadań jest przygotowanie przypadków testowych bazujących na kryteriach akceptacji określonych w dokumentacji. Aby poprawnie przejść wszystkie przygotowane przypadki, często potrzebujemy określonych zasobów, w tym danych testowych.

Soflab Technology – największa polska firma „pure-play” w obszarze Quality Assurance

W tym roku odbyła się już 31. edycja badania Computerworld TOP200, które jest najważniejszym raportem na temat kondycji polskiego rynku teleinformatycznego. W zestawieniu znajdują się kluczowi dostawcy w branży ICT, pośród których wysoko uplasowało się Soflab Technology.

Różne rodzaje i charakterystyka środowisk nieprodukcyjnych

W dzisiejszym dynamicznym świecie technologii oprogramowania, tworzenie oraz utrzymanie wysokiej jakości aplikacji i systemu jest kluczową kwestią dla firm. W tym celu niezbędne jest posiadanie różnych rodzajów środowisk nieprodukcyjnych, które umożliwią deweloperom, testerom i innym specjalistom, pracę nad aplikacjami w bezpiecznym i kontrolowanym otoczeniu.

Prawne aspekty przetwarzania danych wrażliwych w systemach informatycznych i chmurze obliczeniowej

Wraz z rozwojem nowych technologii pojawiają się również nowe wyzwania w zakresie przetwarzania danych osobowych w postaci cyfrowej. Wymusza to także konieczność wypracowania nowych regulacji prawnych, które należycie zabezpieczą dane osobowe przetwarzane przez różne podmioty w infrastrukturze informatycznej (instytucje, organizacje, przedsiębiorstwa).

zmiany-w-sylabusie-istqb

Nowy sylabus ISTQB® Certified Tester Foundation Level – zmiany u podstaw

Nowa wersja sylabusa nie jest jedynie aktualizacją, tudzież wymieszaniem treści istniejących już w sylabusach Foundation i Agile, ale kompletnym przemodelowaniem integrującym niezmienne podstawy testowania z najnowszymi elementami zwinnymi, dodatkowo wzbogaconym o aktualne trendy pozwalające lepiej przygotować się do „testowania przyszłości”.

ChatGPT kłamie jak z nut czyli halucynacje AI

Szukałem tłumaczenia dosyć starej ale specjalistycznej książki na język polski. Postanowiłem skorzystać z ChatGPT, żeby ułatwić sobie te poszukiwania. I jaki jest rezultat? No coż… wniosek jest prosty, jak ChatGPT nie zna odpowiedzi, to ją sobie wymyśli, ale kłamie tak sprawnie, że na początku można mu nawet uwierzyć.

generowanie danych testowych

Poznaj sposoby generowania danych testowych na przykładzie dostępnych narzędzi

Na etapie projektowania testów jednym z kluczowych zadań jest przygotowanie przypadków testowych bazujących na kryteriach akceptacji określonych w dokumentacji. Aby poprawnie przejść wszystkie przygotowane przypadki, często potrzebujemy określonych zasobów, w tym danych testowych.

Soflab Technology – największa polska firma „pure-play” w obszarze Quality Assurance

W tym roku odbyła się już 31. edycja badania Computerworld TOP200, które jest najważniejszym raportem na temat kondycji polskiego rynku teleinformatycznego. W zestawieniu znajdują się kluczowi dostawcy w branży ICT, pośród których wysoko uplasowało się Soflab Technology.

Różne rodzaje i charakterystyka środowisk nieprodukcyjnych

W dzisiejszym dynamicznym świecie technologii oprogramowania, tworzenie oraz utrzymanie wysokiej jakości aplikacji i systemu jest kluczową kwestią dla firm. W tym celu niezbędne jest posiadanie różnych rodzajów środowisk nieprodukcyjnych, które umożliwią deweloperom, testerom i innym specjalistom, pracę nad aplikacjami w bezpiecznym i kontrolowanym otoczeniu.

Prawne aspekty przetwarzania danych wrażliwych w systemach informatycznych i chmurze obliczeniowej

Wraz z rozwojem nowych technologii pojawiają się również nowe wyzwania w zakresie przetwarzania danych osobowych w postaci cyfrowej. Wymusza to także konieczność wypracowania nowych regulacji prawnych, które należycie zabezpieczą dane osobowe przetwarzane przez różne podmioty w infrastrukturze informatycznej (instytucje, organizacje, przedsiębiorstwa).

zmiany-w-sylabusie-istqb

Nowy sylabus ISTQB® Certified Tester Foundation Level – zmiany u podstaw

Nowa wersja sylabusa nie jest jedynie aktualizacją, tudzież wymieszaniem treści istniejących już w sylabusach Foundation i Agile, ale kompletnym przemodelowaniem integrującym niezmienne podstawy testowania z najnowszymi elementami zwinnymi, dodatkowo wzbogaconym o aktualne trendy pozwalające lepiej przygotować się do „testowania przyszłości”.

ChatGPT kłamie jak z nut czyli halucynacje AI

Szukałem tłumaczenia dosyć starej ale specjalistycznej książki na język polski. Postanowiłem skorzystać z ChatGPT, żeby ułatwić sobie te poszukiwania. I jaki jest rezultat? No coż… wniosek jest prosty, jak ChatGPT nie zna odpowiedzi, to ją sobie wymyśli, ale kłamie tak sprawnie, że na początku można mu nawet uwierzyć.

Soflab Technology – największa polska firma „pure-play” w obszarze Quality Assurance

W tym roku odbyła się już 31. edycja badania Computerworld TOP200, które jest najważniejszym raportem na temat kondycji polskiego rynku teleinformatycznego. W zestawieniu znajdują się kluczowi dostawcy w branży ICT, pośród których wysoko uplasowało się Soflab Technology.

Różne rodzaje i charakterystyka środowisk nieprodukcyjnych

W dzisiejszym dynamicznym świecie technologii oprogramowania, tworzenie oraz utrzymanie wysokiej jakości aplikacji i systemu jest kluczową kwestią dla firm. W tym celu niezbędne jest posiadanie różnych rodzajów środowisk nieprodukcyjnych, które umożliwią deweloperom, testerom i innym specjalistom, pracę nad aplikacjami w bezpiecznym i kontrolowanym otoczeniu.

Prawne aspekty przetwarzania danych wrażliwych w systemach informatycznych i chmurze obliczeniowej

Wraz z rozwojem nowych technologii pojawiają się również nowe wyzwania w zakresie przetwarzania danych osobowych w postaci cyfrowej. Wymusza to także konieczność wypracowania nowych regulacji prawnych, które należycie zabezpieczą dane osobowe przetwarzane przez różne podmioty w infrastrukturze informatycznej (instytucje, organizacje, przedsiębiorstwa).

zmiany-w-sylabusie-istqb

Nowy sylabus ISTQB® Certified Tester Foundation Level – zmiany u podstaw

Nowa wersja sylabusa nie jest jedynie aktualizacją, tudzież wymieszaniem treści istniejących już w sylabusach Foundation i Agile, ale kompletnym przemodelowaniem integrującym niezmienne podstawy testowania z najnowszymi elementami zwinnymi, dodatkowo wzbogaconym o aktualne trendy pozwalające lepiej przygotować się do „testowania przyszłości”.

ChatGPT kłamie jak z nut czyli halucynacje AI

Szukałem tłumaczenia dosyć starej ale specjalistycznej książki na język polski. Postanowiłem skorzystać z ChatGPT, żeby ułatwić sobie te poszukiwania. I jaki jest rezultat? No coż… wniosek jest prosty, jak ChatGPT nie zna odpowiedzi, to ją sobie wymyśli, ale kłamie tak sprawnie, że na początku można mu nawet uwierzyć.

Różne rodzaje i charakterystyka środowisk nieprodukcyjnych

W dzisiejszym dynamicznym świecie technologii oprogramowania, tworzenie oraz utrzymanie wysokiej jakości aplikacji i systemu jest kluczową kwestią dla firm. W tym celu niezbędne jest posiadanie różnych rodzajów środowisk nieprodukcyjnych, które umożliwią deweloperom, testerom i innym specjalistom, pracę nad aplikacjami w bezpiecznym i kontrolowanym otoczeniu.

Prawne aspekty przetwarzania danych wrażliwych w systemach informatycznych i chmurze obliczeniowej

Wraz z rozwojem nowych technologii pojawiają się również nowe wyzwania w zakresie przetwarzania danych osobowych w postaci cyfrowej. Wymusza to także konieczność wypracowania nowych regulacji prawnych, które należycie zabezpieczą dane osobowe przetwarzane przez różne podmioty w infrastrukturze informatycznej (instytucje, organizacje, przedsiębiorstwa).

zmiany-w-sylabusie-istqb

Nowy sylabus ISTQB® Certified Tester Foundation Level – zmiany u podstaw

Nowa wersja sylabusa nie jest jedynie aktualizacją, tudzież wymieszaniem treści istniejących już w sylabusach Foundation i Agile, ale kompletnym przemodelowaniem integrującym niezmienne podstawy testowania z najnowszymi elementami zwinnymi, dodatkowo wzbogaconym o aktualne trendy pozwalające lepiej przygotować się do „testowania przyszłości”.

ChatGPT kłamie jak z nut czyli halucynacje AI

Szukałem tłumaczenia dosyć starej ale specjalistycznej książki na język polski. Postanowiłem skorzystać z ChatGPT, żeby ułatwić sobie te poszukiwania. I jaki jest rezultat? No coż… wniosek jest prosty, jak ChatGPT nie zna odpowiedzi, to ją sobie wymyśli, ale kłamie tak sprawnie, że na początku można mu nawet uwierzyć.

Prawne aspekty przetwarzania danych wrażliwych w systemach informatycznych i chmurze obliczeniowej

Wraz z rozwojem nowych technologii pojawiają się również nowe wyzwania w zakresie przetwarzania danych osobowych w postaci cyfrowej. Wymusza to także konieczność wypracowania nowych regulacji prawnych, które należycie zabezpieczą dane osobowe przetwarzane przez różne podmioty w infrastrukturze informatycznej (instytucje, organizacje, przedsiębiorstwa).

zmiany-w-sylabusie-istqb

Nowy sylabus ISTQB® Certified Tester Foundation Level – zmiany u podstaw

Nowa wersja sylabusa nie jest jedynie aktualizacją, tudzież wymieszaniem treści istniejących już w sylabusach Foundation i Agile, ale kompletnym przemodelowaniem integrującym niezmienne podstawy testowania z najnowszymi elementami zwinnymi, dodatkowo wzbogaconym o aktualne trendy pozwalające lepiej przygotować się do „testowania przyszłości”.

ChatGPT kłamie jak z nut czyli halucynacje AI

Szukałem tłumaczenia dosyć starej ale specjalistycznej książki na język polski. Postanowiłem skorzystać z ChatGPT, żeby ułatwić sobie te poszukiwania. I jaki jest rezultat? No coż… wniosek jest prosty, jak ChatGPT nie zna odpowiedzi, to ją sobie wymyśli, ale kłamie tak sprawnie, że na początku można mu nawet uwierzyć.

zmiany-w-sylabusie-istqb

Nowy sylabus ISTQB® Certified Tester Foundation Level – zmiany u podstaw

Nowa wersja sylabusa nie jest jedynie aktualizacją, tudzież wymieszaniem treści istniejących już w sylabusach Foundation i Agile, ale kompletnym przemodelowaniem integrującym niezmienne podstawy testowania z najnowszymi elementami zwinnymi, dodatkowo wzbogaconym o aktualne trendy pozwalające lepiej przygotować się do „testowania przyszłości”.

ChatGPT kłamie jak z nut czyli halucynacje AI

Szukałem tłumaczenia dosyć starej ale specjalistycznej książki na język polski. Postanowiłem skorzystać z ChatGPT, żeby ułatwić sobie te poszukiwania. I jaki jest rezultat? No coż… wniosek jest prosty, jak ChatGPT nie zna odpowiedzi, to ją sobie wymyśli, ale kłamie tak sprawnie, że na początku można mu nawet uwierzyć.