Szkolenie dla QA
-
Moduł 1: Wstęp
Wstęp -
Wymagania
-
Grupa wsparcia
-
Quality Assurance vs Quality Control
-
Ćwiczenia i zadania domowe
-
Zadanie domowe
-
Zadanie domowe #2
-
Moduł 2: Cechy charakteruWstęp
-
Cierpliwość
-
Dokładność
-
Opanowanie
-
Empatia
-
Asertywność
-
Inne cechy
-
Odpowiedzialność
-
Zadanie domowe
-
Moduł 3: SpecjalizacjeWstęp
-
Informacje na początek
-
Automatyzacja (QAA)
-
Analiza biznesowa
-
Cyberbezpieczeństwo
-
Wydajność
-
Dostępność
-
Zadanie domowe
-
Moduł 4: Podstawy teoriiWstęp
-
SDLC
-
Shift-Left Testing
-
Definicja jakości i testowania
-
Retest vs Regresja
-
Błąd, defekt, usterka, anomalia, incydent, improvement
-
Weryfikacja vs walidacja
-
Białe, czarne i szare skrzynki
-
Testowanie (nie)funkcjonalne
-
RWD
-
Symulator vs emulator
-
Dane testowe (teoria)
-
Moduł 5: Podstawowe narzędzia IKlasy równoważności i wartości graniczne
-
Wstęp
-
Systemy operacyjne
-
Przeglądarki
-
Wtyczki
-
Nagrywanie i zrzuty ekranu
-
Moduł 6: Podstawowe narzędzia IISymulacja maili
-
Browserstack
-
Sizzy
-
Bird Eats Bug
-
Polecane wtyczki
-
Konsola deweloperska
-
Narzędzia Adobe
-
Dane testowe
-
Moduł 7: TestowanieZadanie domowe
-
Wstęp
-
Formularze
-
Moduł 8: Zarządzanie jakością2FA
-
Wstęp
-
Plan testów
-
Testy regresji oraz przypadki
-
Raport końcowy
-
Zgłaszanie defektów
-
Komentarze
-
Moduł 9: Zapewnianie jakościCritical, High czy Low?
-
Wstęp
-
Zanim zaczniemy projekt
-
DoR, DoD
-
Standardy systemu zapewniania jakości
-
Zarządzanie ryzykiem
-
Moduł 10: Cała prawda o ITJakość danych testowych
-
Wstęp
-
Manifest Agile
-
Kanban
-
Scrum
-
Scrum vs Kanban
-
Daily
-
Refinement
-
Demo
-
Jira
-
Confluence
-
PostmanKody HTTP
-
Wstęp
-
Żądania HTTP
-
Nagłówki
-
Metody
-
Instalacja
-
GET
-
Save & New
-
POST & GET dla pojedynczego ID
-
Filtrowanie
-
PUT
-
PATCH & DELETE
-
SQLZadanie domowe
-
Wstęp do baz danych
-
Słów kilka o SQL
-
Instalacja środowiska
-
Adnotacja do narzędzia
-
Komentarze
-
Pobieranie danych
-
Aliasy
-
Sortowanie wyników
-
Eliminowanie duplikatów
-
Filtrowanie danych - część 1
-
Filtrowanie danych - część 2
-
Złożone warunki logiczne
-
Klauzula TOP
-
Operatory arytmetyczne
-
Konkatenacja
-
Grupowanie wierszy - część 1
-
Grupowanie wierszy - część 2
-
Klauzula Having
-
Łączenie tabel
-
Łączenie klauzul
-
Aktualizacja danych
-
Podzapytania zagnieżdżone
-
Jira Query Language
-
Test
-
Ćwiczenia
-
Moduł 11: PortfolioOdpowiedzi do ćwiczeń
-
Wstęp
-
Co umieścić?
-
Gdzie umieścić?
-
ChatGPT w branży QAZadanie domowe
-
Wstęp
-
ChatGPT - zastosowanie branżowe
-
ChatGPT - zastosowanie niebranżowe
-
Ryzyka i pułapki
-
Lepsze prompty
-
Czy AI zastąpi specjalistów IT?
-
Moduł 12: RekrutacjaĆwiczenia praktyczne
-
Wstęp
-
Zadanie domowe #1
-
LinkedIn
-
CV - sposób I
-
CV - sposób II
-
CV - sposób III
-
CV - dobre praktyki - część I
-
CV - dobre praktyki - część II
-
Oferty pracy
-
B2B
-
Rozmowa rekrutacyjna - jak się przygotować
-
Rozmowa rekrutacyjna - jak wygląda
-
Rozmowa rekrutacyjna - przegląd pytań - część I
-
Rozmowa rekrutacyjna - przegląd pytań - część II
-
Rozmowa rekrutacyjna - przegląd pytań - część III
-
Odpowiedzi na wybrane pytania
-
Do biegu, gotowi, start...
-
FAQ
-
Moduł 13: ZakończenieZadanie domowe #2
-
Wstęp
-
Język angielski
-
ISTQB
-
Źródła wiedzy
-
Co dalej?
-
DodatkiCertyfikat
-
Zestaw łamigłówek - część 1
-
Stres i jak sobie z nim radzić
-
Lista TODO
-
Nagranie z Live Calla o dostępności cyfrowej
Zarządzanie ryzykiem
Zarządzanie ryzykiem jest niezbędne, ponieważ pomaga złagodzić wpływ ryzyka na działalność i nadać priorytet działaniom, które mają się ku temu przyczynić. Zagrożenia mogą pojawić się w rutynowych procesach, aktywach biznesowych, stosowanych materiałach/sprzęcie lub produktach/usługach końcowych świadczonych przez firmę. Oprócz tego mogą występować zagrożenia dla środowiska, miejsca pracy, informacji, a także zagrożenia bezpieczeństwa cybernetycznego, zagrożenia dotyczące zgodności lub te finansowe, które mogą w równym stopniu zakłócić działalność biznesową.
Poniżej znajdziesz listę kontrolną, która pomoże Ci porozmawiać o ryzyku, a także ułatwi postawienie pierwszych kroków w kierunku przeprowadzenia audytu zarządzania ryzykiem.
- Strategia oceny ryzyka
Najpierw musisz upewnić się, że Twoja organizacja ma strategię, czyli zestaw procesów identyfikacji zagrożeń. Musi istnieć oddzielny rejestr ryzyka, w którym należy rejestrować szczegóły wszystkich przeprowadzonych działań (np. audytów). Prowadzenie rejestru pomaga również w prowadzeniu szczegółowej ewidencji przewidywalnych i istniejących zagrożeń. W związku z tym możesz zapobiec sytuacjom powodującym ich ponowne wystąpienie w przyszłości.
- Szczegółowe zasady i kontrole wewnętrzne
Aby zarządzanie ryzykiem było skuteczne, potrzebujesz ustalonej polityki zarządzania ryzykiem oraz pewnych szczegółowych kontroli wewnętrznych lub procedur, które pozwolą jej przestrzegać. Dlatego musisz upewnić się, że Twój zespół zarządzający utworzył politykę, która daje wyobrażenie o zakresie i celach zarządzania ryzykiem. Potwierdź również w jaki sposób należy wdrożyć różne kontrole lub procedury zarządzania ryzykiem. Upewnij się, że zespół zarządzający przedstawił je pracownikom (oceniającym ryzyko i kierownikom), którzy byliby odpowiedzialni za eliminację ryzyka. Ponadto musisz określić, jak często polityka powinna być przeglądana i aktualizowana, aby zapewnić, że kontrole mogą zaradzić nowym zagrożeniom.
- Przypisywanie odpowiedzialności
Upewnij się, że ustaliłeś odpowiedzialność za ryzyko i nadałeś uprawnienia dedykowanym członkom do zarządzania nimi. W tym celu należy określić, kto jest właścicielem ryzyka, czyli osoby obsługujące proces, aktywa lub obszar działalności, w którym zidentyfikowano ryzyko. Przypisanie odpowiedzialności pomaga w szybkim zarządzaniu ryzykiem.
- Przydział zasobów
Musisz upewnić się, że zespół zarządzający odpowiednio przydzielił zasoby wymagane do zarządzania ryzykiem. Zasoby, w szerokim ujęciu, oznaczają narzędzia, informacje i osoby wymagane do identyfikacji, oceny, usuwania lub przenoszenia ryzyka. Dlatego należy upewnić się, że metody oceny, narzędzia, informacje, mechanizmy komunikacji, systemy raportowania i wszelkie podmioty zewnętrzne wymagane do zarządzania ryzykiem są gotowe. Należy również upewnić się, że pracownicy odpowiedzialni za radzenie sobie z ryzykiem zostali odpowiednio przeszkoleni.
- Ciągłe doskonalenie kontroli ryzyka
Na koniec musisz potwierdzić, czy różne wdrożone kontrole ryzyka są od czasu do czasu aktualizowane, aby poprawić zarządzanie ryzykiem. Upewnij się, że masz odpowiednie wskaźniki lub metryki do pomiaru wydajności kontroli ryzyka. Jeśli metryki okażą się niewystarczające w porównaniu z zamierzonymi celami wydajności, można zrewidować politykę ryzyka i wdrożone kontrole. Dlatego musisz zapewnić odpowiednią okresową ocenę swojej polityki ryzyka, ram zarządzania, kontroli i środków w celu zidentyfikowania nieefektywności. Pomogłoby to w ciągłym ulepszaniu podejścia do zarządzania ryzykiem.
Jak określić poziom ryzyka, czyli o macierzy ryzyka słów kilka.
Zidentyfikowane ryzyka klasyfikujemy zazwyczaj według dwóch kryteriów. Mowa o prawdopodobieństwie wystąpienia oraz możliwych skutkach. Jedną z technik określenia poziomu, jest właśnie macierz ryzyka, którą wylicza się w prosty sposób:
prawdopodonieństwo * skutek = poziom ryzyka
Funkcjonalności obarczone największym ryzykiem mają najwyższy priorytet, czyli pierwszeństwo we wdrożeniu (lub testowaniu). Te o najniższym priorytecie można wykluczyć z planu działania, chyba że dotyczą one systemów krytycznych lub funkcjonalności obarczonych wysokim ryzykiem (aparatura medyczna, oprogramowanie lotnicze, system kontroli zderzeń, bankowość).
TDD vs BDD
TDD (Test Driven Development) oraz BDD (Behavior Driven Development) to metodyki w procesie opartym na testowanu na podstawie ryzyka.
Test Driven Development polega na odwróconym procesie wytwarzania oprogramowania. Programista najpierw tworzy program sprawdzający kod, który dopiero ma napisać. Dopiero później go pisze. Tak więc najpierw powstanie program, który sprawdzi czy inny program działa zgodnie z oczekiwaniem.
Zaletą tego podejścia jest to, że napisane testy są integralną częścią oprogramowania i mogą być uruchamiane każdorazowo, gdy dokonywane są zmiany w kodzie. Pozwala to na ogromną oszczędność czasu i pieniędzy, ponieważ w przypadku stabilnych wymagań (czyli takich, które raz zdefiniowane nie ulegają częstym zmianom), testy te są powtarzalne i dają nam niemal natychmiast informację na temat stanu aplikacji, zanim jeszcze zaczniemy testy “właściwe” (a więc zaangażujemy zasoby w testowanie, co wiąże się z kosztami).
Behavior Driven Development polega na definiowaniu potencjalnych przypadków użycia aplikacji i opisaniu ich w taki sposób, że mogą potem stanowić jednoznaczną instrukcję dla użytkownika. Wymaga to pewnego usztywnienia w tworzeniu wymagań, ponieważ ograniczeni jesteśmy wtedy narzędziami i językami stosowanymi w tej metodyce (jak np. Cucumber i Gherkin). Tak więc od samego początku osoby zaangażowane w projekt tworzą przypadki testowe, które łatwo potem przekuć w testy automatyczne, ponieważ trzymają się one ściśle określonej składni (potocznie w IT nazywane “podejściem given when then“).