Software Testing Flashcards
1
Q
DIS/DOS?
A
Design Input & Design Output
2
Q
Was ist Zephyr und wofür wird es verwendet?
A
Zephyr ist ein Testmanagement-Tool, das in Jira integriert ist.
Es wird verwendet, um Testfälle zu erstellen, zu verwalten und Testläufe durchzuführen.
3
Q
Wie erstellt man einen Testfall in Zephyr?
A
Man navigiert zum Jira-Projekt, wählt “Mehr” und dann “Testfall hinzufügen”.
Man gibt die Details des Testfalls ein und speichert ihn
4
Q
Wie führt man einen Testlauf in Zephyr durch?
A
Man wählt den Testfall aus, navigiert zu “Testzyklen” und startet einen neuen Zyklus.
Man führt die Tests gemäß den Anweisungen durch und dokumentiert die Ergebnisse.
5
Q
Wie kann man Testergebnisse in Zephyr analysieren?
A
Man navigiert zu den Testzyklen und wählt den gewünschten Zyklus.
Man betrachtet die Testergebnisse und generiert Berichte für die Analyse.
6
Q
Wie integriert man Zephyr mit anderen Tools?
A
Zephyr bietet Integrationen mit verschiedenen CI/CD-Tools und Automatisierungstools.
Man konfiguriert die Integrationen in den Einstellungen von Zephyr.
7
Q
Was ist Cypress und wofür wird es verwendet?
A
Cypress ist ein Frontend-Testwerkzeug für das automatisierte Testen von Webanwendungen.
Es wird verwendet, um End-to-End-Tests in einer realen Browserumgebung durchzuführen
8
Q
Wie installiert man Cypress?
A
Man installiert Cypress über npm mit dem Befehl npm install cypress –save-dev.
Nach der Installation kann man Cypress über das Kommando npx cypress open starten.
9
Q
Wie schreibt man einen einfachen Test in Cypress?
A
Man erstellt eine neue Testdatei im cypress/integration-Verzeichnis.
Man verwendet die describe und it Funktionen, um Testfälle zu definieren und cy.visit zum Navigieren zu einer URL.
10
Q
Wie verwendet man Assertions in Cypress?
A
Assertions in Cypress überprüfen, ob bestimmte Bedingungen im Test erfüllt sind.
Man verwendet Befehle wie expect oder should für Assertions.
11
Q
Wie kann man Cypress mit CI/CD-Pipelines integrieren?
A
Man konfiguriert Cypress in der CI/CD-Pipeline, indem man die notwendigen Schritte in der Konfigurationsdatei der Pipeline definiert.
Cypress Tests werden automatisch ausgeführt, wenn Änderungen gepusht werden.
12
Q
Frontend-Testwerkzeug
A
Ein Werkzeug, das speziell für das Testen der Benutzeroberfläche (Frontend) von Webanwendungen entwickelt wurde.
Beispiel: Cypress wird verwendet, um zu überprüfen, ob ein Anmeldeformular auf einer Webseite korrekt funktioniert, indem es automatisiert Benutzerdaten eingibt und auf den Anmeldebutton klickt.
13
Q
End-to-End-Tests
A
Tests, die den kompletten Ablauf einer Anwendung aus der Sicht des Endnutzers überprüfen.
Beispiel: Ein End-to-End-Test könnte den gesamten Kaufprozess in einem Online-Shop simulieren, von der Produktauswahl bis zur Bestellbestätigung.
14
Q
Assertions
A
Überprüfungen innerhalb eines Tests, die bestätigen, dass das erwartete Verhalten oder der erwartete Zustand einer Anwendung tatsächlich vorliegt.
Beispiel: expect(true).to.be.true ist eine einfache Assertion, die überprüft, ob der Wert true auch tatsächlich true ist.
15
Q
expect oder should
A
Befehle in Cypress, die für Assertions verwendet werden.
Beispiel: cy.get(‘.alert’).should(‘contain’, ‘Login erfolgreich’) überprüft, ob ein Element mit der Klasse .alert den Text ‘Login erfolgreich’ enthält.
16
Q
Testfall
A
Eine spezifische Anforderung oder Bedingung, die überprüft werden muss, um die Funktionalität eines Softwareprodukts zu validieren.
Beispiel: Ein Testfall könnte sein, zu überprüfen, ob ein Nutzer sich mit einer gültigen E-Mail-Adresse und Passwort anmelden kann.
17
Q
Testlauf
A
Die Durchführung von Testfällen, um zu überprüfen, ob die Software die definierten Anforderungen erfüllt.
Beispiel: Ein Tester führt einen Testlauf durch, indem er die Schritte eines Testfalls befolgt und überprüft, ob das erwartete Ergebnis eintritt.
18
Q
Was ist manuelles Testen?
A
19
Q
Was ist automatisiertes Testen?
A
20
Q
Was ist regulatorisches Testen?
A
21
Q
Was ist Validierung und wo macht man es?
A
- Geräte / Produkte validiert man
22
Q
Was ist Verifikation und wo macht man es?
A
- Dokumente wie Design Input (Product Owner) und Design Output (Desinger) werden verifiziert
23
Q
Wie sieht ein einfacher Vorgang aus um mit Cypress ein Benutzerprofil zu überprüfen?
A
24
Q
Wie sieht ein einfacher Vorgang aus um mit Cypress ein Count Up/down zu überprüfen?
A
25
VisioNize® Lab Suite Connectivity
VisioNize Lab Suite ermöglicht die Vernetzung und Fernüberwachung von Laborgeräten. Es unterstützt Geräte von Eppendorf und Drittanbietern, bietet Alarmbenachrichtigungen, Wartungsplanung und Audit-Protokolle. Nutzer können Geräteleistungsdaten einsehen und verwalten, sowohl über mobile Geräte als auch über ein Firmennetzwerk
26
Vorteile der VisioNize Lab Suite
Vorteile der VisioNize Lab Suite
Fernüberwachung: Überwachung der Leistung von Laborgeräten von überall aus
Alarmbenachrichtigungen: Benachrichtigungen bei Gerätealarmen, Fehlern und Änderungen des Gerätestatus
Wartungsplanung: Automatisierung der Wartungsmaßnahmen aller Laborgeräte und Benachrichtigung bei Fälligkeit
Audit-Protokolle: Detaillierte Dokumentation von Geräteleistungsdaten, Nutzereingriffen und Wartungsmaßnahmen
Zugang zu Gerätedaten: Zugriff auf alle relevanten Dokumente, Standardarbeitsanweisungen und Bedienungsanleitungen
Fern-Updates: Neue Verbesserungen sind sofort für alle VisioNize touch enabled Geräte verfügbar
Erhöhte Probensicherheit: Sicherstellung optimaler Bedingungen für das Zellwachstum und Vermeidung von Probenverlust
Verbesserung der Produktivität: Verwaltung wiederkehrender Aufgaben und Planung des Einsatzes von Geräten
Flexibilität: Anpassung der Services an die Bedürfnisse des Labors und Skalierbarkeit der Lösung
Kostenlose Erstnutzung: Möglichkeit, die ersten drei Geräte kostenlos anzubinden und praktische Erfahrungen zu sammeln
27
Nachteile der VisioNize Lab Suite
Nachteile der VisioNize Lab Suite
Die bereitgestellten Quellen enthalten keine spezifischen Informationen über Nachteile der VisioNize Lab Suite. Generell könnten potenzielle Nachteile von digitalen Labormanagement-Systemen jedoch in Bereichen wie Kosten für umfangreichere Nutzung, Abhängigkeit von Internetverbindungen, Datenschutzbedenken und die Notwendigkeit regelmäßiger Updates und Wartung liegen. Ohne spezifische Details aus den Quellen bleibt dies jedoch spekulativ.
28
Erkläre die Testing Pyramide mit deinen Worten wie ist die Reihenfolge und wofür sind die einzelnen Tests?
4 Ebene Unit Tests während der Entwicklung
3 Ebene Component Tests während der Entwicklung
Testet eine einzelne Componente ob z.B theoretisch eine API gefetcht werden kann
2 Ebene Integration Tests während der Entwicklung
Testet die Intergration zwischen mehreren Funktionen bzw Componenten wie z.B das Fetchen
1 Ebene e2e / end to end test
0 Ebene Manuelles Testen
think if you're testing a car. You would want to test the engine on its own (component testing). The individual parts of the engine will also need to be tested i.e fuel injectors (unit testing). Then you want to test how the engine fits into the car model (integration testing)
29
Was ist ein Testbericht und was beinhaltet er im Softwaretesting?
Antwort: Ein Testbericht dokumentiert die Ergebnisse der Testaktivitäten. Er beinhaltet Informationen über durchgeführte Tests, Testergebnisse, gefundene Fehler, Testabdeckung und Bewertungen der Softwarequalität.
30
Was ist eine gute Analogie/Vergleich für Automatisierte Tests?
- Automatisierte Tests sind ähnlich wie Sport machen
- Jeder weiß, dass Sport etwas Gutes für einen selbst ist und einem etwas positives bringt
- So weiß auch jeder Entwickler, dass automatisierte Tests etwas gutes für die Qualität der Software ist
- Aber es ist schwer diese, die ganze Zeit anzuwenden und zu erstellen. Wie beim Sport ist es mit Aufwand und Sorgfalt verbunden. Man braucht Disziplin.
- Dabei helfen viele kleine und leichte automatisierte Tests langfristig sehr viel, ähnlich wie schon kleine Sportübungen regelmäßig viel bringen können
31
Wie funktionieren automatisierte Tests?
- Es gibt eine Funktion für einen bestimmten Testfall
- Diese Funktion wird von einem Skript ausgeführt und auf die eigene App angewandt
- Dort werden dann bestimmte Checks/Vergleiche angewandt, wie UI-Events (Klick, Touch), on ein Element sichtbar ist, ob Farben oder Größen stimmen.
- Auch Abläufe durch eine App wie erst einloggen, dann Profilverändern, in die App navigieren, prüfen ob etwas angezeigt wird oder möglich ist, kann automatisiert als Testfall abgebildet werden
32
Wie würdest du eine Teststrategie für eine ganz einfache App, die CRUD also etwas erstellen, anzeigen, updaten und löschen anbietet, aufbauen wenn noch gar keine Tests existieren?
- Man muss mit einer Strategie herangehen und darf nicht wahllos testen
- Falls es sowas wie Spezifikationsdokumente (Design Output) gab, um die App selbst zu erstellen könnte man sich fachlich an dieser entlang hangeln und von den Themen dort (Profilseite, Hauptseite etc) anfangen diese pro Thema in einen "Testablauf/Testbereich" aufzuteilen, welcher dann viele kleine Tests nur für seinen Bereich in sich hat
- Die Testfälle testen ausschließlich die Funktionalität und sollten möglichst jede Nutzerinteraktion und jedes Feature welches auf jedem Testbereich verfügbar ist abdecken. Damit eine hohe Testabdeckung entsteht und nichts ungetestet bleibt
- Wenn es keine Spezifikation gibt, kann man sie pro Screen oder pro URL der Website entlanghangeln und jeweils Testfälle anlegen.
- Auch visuelle Dinge wie das Layout und Styling kann einzeln getestet werden. So kann man bei Webtechnologien über den DOM auf jedes einzelne Node/Element des Doms via Selektoren wie Klassenselektor, ID-Selektor, HTML-Selektor etc zugreifen. Aus dem Node/Element kann man alle Informationen ablesen, wie Breite, Höhe, Farben, Styling, Events(Klick, Touch, Press) oder auch ob es sichtbar ist.
33
Was ist CRUD?
- Etwas was fast jede App anbietet
- Create (Dinge in der App erstellen und in Datenbank speichern, wie Account erstellen)
- Read (Dinge in der App anzeigen aus Datenbank wie Name anzeigen)
- Update (Dinge in der App aktualisieren und in Datenbank überschreiben wie Nutzername ändern)
- Delete (Dinge in der App löschen und in Datenbank löschen wie Account löschen)
34
Wie kann man Elemente/Nodes aus dem DOM selektieren?
- Mit verschiedenen Selektorn (Klasse, ID, HTML-Tag etc)
- Man hat dann vollen Zugriff auf alle Informationen die der Browser auch dazu hat, um diese anzuzeigen. Also Styling, Sichtbarkeit, gewisse Funktionen können darauf angewandt werden.
35
Wo werden SessionDaten also Infos über eingeloggte User in einer App gespeichert und wo kann man diese testen?
- Oftmals werden der sessionStorage oder localStorage genutzt
- Dort werden auch oft Cookies abgelegt oder JWT-Tokens welche der Beweis für den erfolgreichen Login sind
- Diese kann man via Cypress/Playwright auslesen und gucken ob diese beispielsweise vorhanden sind nachdem ein login geschehen ist. Damit für man die Login-Funktionalität prüfen auf ihre Technik.
- Man könnte auch einfach einen Text in der App via DOM abfragen, wie "Hallo, Nutzer ...". Dann testet man aber eher ob dieser Text nach dem Login angezeigt wird. Und es kann auch einen Bug geben, dass der Text angezeigt wird obwohl keine Session gespeichert wurde. Daher sollte man diesen technischen Login-Test und den Visuellen Login-Test der evtl eine React Component Testet trennen.
36
Welche Vorteile hat automatisiertes Testen gegenüber manuellem Testen?
- Es findet Bugs sehr früh und schnell (In der Pipeline nachdem ein Entwickler neuen Code committed/pusht)
- Es ist kostengünstiger, da Dinge nicht immer wieder erneut per Hand durchgetestet werden müssen (Regressionen)
- Es beschleunigt die Entwicklung da sich weniger Fehler einschleichen die erst später gefunden werden und schon neuer Code auf den fehlerhaften Code aufbaut.
37
Was ist Spezifität in CSS?
* Spezifität beschreibt die Wichtigkeit eines angewandten Stylings in CSS
* Wichtiger Styling überschreiben unwichtigere Stylings
* Wenn man in einer Library z.B. eine .login-button Klasse definiert mit einem styling und in der app auch eine eigener .login-button Klasse erstellt wird kann es zu Styling-Problemen kommen da unerwartet eines von beiden das andere überschreibt
* Dafür gibt es feste Regeln !important überschreibt alles, HTML IDs überschreiben Klassennamen, Klassennamen die später im CSS geladen werden als andere überschreiben die vorherigen (Cascading/Kaskadierend, wie ein Wasserfall CSS = Cascading Style Sheets)
38
Wie kann man Spezifität in CSS sicher handlen, so dass sich nichts überschreibt?
* Entweder man verwendet wirklich einzigartige Klassennamen. Das ist als Library aber schwer weil man keine Kontrolle über die App hat, welche die Library benutzt
* Oder man benutzt BEM (Block Entity Modifier) als CSS Klassennamen Bennenungsverfahren (`.button .button__text .button__text--disabled`
* Oder man benutzt Scoped Modules wo bei jedem Erstellen einer Library/App an alle Klassennamen zufällige Hash-Werte herangehangen werden (.button_i9UzR) und eine app nicht den selben zufälligen Namen erstellen wird
39
Was sind Probleme mit Scoped Modules / Zufälligen Hashwerten die an Klassennamen im CSS rangehängt werden?
* Wenn man als Software-Tester Tests schreibt möchte man oft DOM-Elemente via Klassennamen selektieren.
* Jetzt haben die aber immer zufällige Namen, also gehen die Test nicht mehr verlässlich durch und finden jedesmal ihr richtiges Element
* Man kann mit spezielleren CSS Selektoren dieses Problem umgehen wie mit `[class^="button_"]` Damit wird nur der Anfang welcher nicht zufällig ist als Klassenname gesucht und was dahinter steht kann dann zufällig sein. Trotzdem wird das Element immer gefunden und die Tests gehen
40
Was ist der Unterschied in TypeScript/JavaScript zwischen == und === als Vergleichsoperator? Beispiel 2 == "2" und 2 === "2"
* Mit 2 == "2" kommt true also gleich heraus. Was problematisch sein kann, da eine Zahl 2 nicht das gleiche ist wie der String 2. (Herzschrittmacher)
* Mit 2 === "2" kommt false also nicht gleich heraus. Was korrekt ist. Daher immer === (3 fach) benutzen.
* Warum das mit == so ist, ist historisch so in der Programmiersprache entstanden. JavaScript möchte es für einen immer möglichst gleich machen. Es benutzt coercion (Automatische Umwandlung) Was aber problematisch ist.
41
Wie viele Threads hat JavaScript/TypeScript und was ist ein Thread?
* Ein Thread ist die Möglichkeit, dass ein Programm/App sich auf dem CPU aufteilt und parallel Aufgaben nebeneinander also gleichzeitig abarbeitet/bearbeitet
* TypeScript wird zu JavaScript transpiliert, also übersetzt damit der Browser es versteht und JavaScript kann nur auf einem 1 Thread laufen.
* JavaScript benutzt den EventLoop, in welchem wie in einem Kreis/Rennstrecke für Autos alle Codezeilen/Kommandos in einer Reihe abgearbeitet werden. Dabei kann es kleine Peformanceoptimierungen vornehmen und manche Aufgaben bevorzugen und manche nochmal den EventLoop durchlaufen lassen. So versucht es Threads nachzuahmen, kann aber niemals so stark sein wie echtes gleichzeitiges abarbeiten.
* Allerdings gibt es in JavaScript "ServiceWorker" die teilen eine App in mehrere kleine Apps auf. Dann hat zwar immer noch jede Teilapp einen Thread, aber die einzelnen Apps lassen sich auf verschiedene Threads des CPU laufen lassen und können untereinander Rechenergebnisse/Kommandos nach Priorität umverteilen. Damit kann man so ziemlich das gleiche erreichen wie mehrere Threads es in fast allen Programmiersprachen können. Ist aber schwieriger zu programmieren.
42
Was ist in React eine View, ein Container und eine Component?
* Components sind dumme wiederverwendbare Blöcke. Wie kleine Legosteine. Alle Logik sie die ausführen und alle Daten die sie bekommen um etwas anzuzeigen erhalten sie via Props und werden also wie Marionetten gesteuert.
* Container in React können komplexere Logik beinhalten und sich zu soetwas wie globalen Statemanagement verbinden. (Redux, Zustand etc). Sie kontrollieren anhand ihrer Logik die dummen Components.
* Views sind noch größere Dinge in React, welche mehrere Container beinhalten können. In früherer IT-Sprache würde man Masken/Screens/Pages sagen.
43
Wofür braucht man ein globales StateManagement in Web Frontends/React?
* Immer wenn wir in verschiedenen Components/ganz tiefen Teilbereichen einer App, wie einem Button der aber an vielen Stellen benutzt wird auf die gleichen Daten zugreifen wollen, ist es klug die Variable nur einmal in der App zu haben.
* Ansonsten hat man Probleme, dass man eine Variable hier nicht aktualisiert, die andere Schon oder sie asynchron also nicht gleichzeitig Daten speichern.
* Mit einer zentralen Stelle wo wichtige Daten für die ganze App liegen, wie z.B. den Nutzerdaten eines eingeloggten Nutzers (Name, Rolle im System, username, Profilbild etc) kann man das dann in der ganzen App anzeigen lassen und muss nur eine Stelle updaten/verändern.
44
Welche Technologien gibt es für globales Statemanagement in React?
* React Redux - was von React selber ist und mittels Actions und Observables arbeitet. Observables sind sowas wie Aktionen welche durch die App fließen und von gewissen Zuhörern/Listenern (In Redux heißen die Epics) getriggert werden können. Wichtig ist hier, das es passiv passiert. Also man ruft nicht den Zuhöhrer wie eine Funktion auf, sondern er hört einfach zu und wird dann selber aktiv.
* Zustand - Ist eine kleinere leichtete Variante als Redux. Kann nicht so viel aber hat weniger Code den man schreiben muss.
45
Was ist MQTT als Protokoll?
* MQTT ist ein Protokoll mit dem oftmals IoT-Geräte, also kleine, schwache und günstige Geräte kommunizieren können. Sie verbinden sich zu einem "Broker" die alle Kommunikation wie eine Poststelle abarbeitet und managed. Über diesen können sie wie in WhatsApp Chaträumen miteinander Daten austauschen und Sprechen. Man kann also so ein Backend mit einem Frontend verbinden. Hier gibt es weniger Mechanismen wie Frage/Antwort sachen. Sondern man schickt einfach Daten/Messages raus.
* Andere Alternativen wären REST, welches im Webbereich sehr viel üblicher ist. Da wird mittels HTTP-Requests miteinander geredet. Es gibt ein Frage-Antwort Verfahren und man schickt JSON-Daten hin und her und kann HTTP-Status-Codes als Erfolg/Error schicken. Wie 404 not found etc.
46
Was ist der DOM?
* Document Object Model
* Eine Art Baumstruktur worüber jeder Browser und jede Internetseit aufgebaut ist
* React kann mit einem Virtual Dom (VDom) der quasi eine Kopie als Datei/Objekt davon ist, kleinere Veränderungen, wie nur das Neufärben eines Buttons erkennen und den Baum so viel besser updaten, so dass nicht die gesamte Seite neu lädt, sondern nur der eine Button als Node/Element im DOM.
* Echte DOM Updates im Browser sind teuer und können das Neuladen einer Seite erfordern, was heutzutage nicht mehr die Erwartung von Nutzern ist.
47
Was ist der Unterschied zwischen den CSS Einheiten px und rem?
* px ist eine feste Einheit, es stellt einen Pixel auf dem Bildschirm dar.
* rem ist eine Einheit, welche in bisschen flexibler ist. Sie ist die größe des Buchstabens m auf dem root Element der App und damit auch fest. Kann aber auch an dieser Root-Stelle in der App geändert werden und alles rem skalieren dann gleichmäßig mit. Die gesamte App wird größer. Sowas brauchen Leute mit Behinderung da wird ein Screen-Reader/Extension den Wert erhöhen, damit sie die App besser lesen können. Man sollte lieber rem als em nutzen.
48
Was sind truthy und falsy Werte in JavaScript?
* Es gibt nur 6 falsy Werte in JavaScript, alles andere ist true/truthy
* false
* undefined
* null
* "" (empty string)
* NaN (Not a Number)
* 0 (auch +0 und -0)
49
Was ist der Unterschied zwischen .map und .forEach?
* .map iteriert über Element eines Arrays und erzeugt je nach Logik darin für jedes Element ein neues oder verändertes Element und gibt dieses als neuen Array zurück. Man macht also ein Abbild von etwas und das ist dann danach anders als vorher.
* .forEach geht einfach nur über jedes Element eines Arrays rüber und führt etwas für jedes je nach Logik aus. Wie ein Funktionsaufruf für jedes Element was "Dominic" im Array ist. Es wird kein verändertes Array erzeugt.
50
Warum muss man in C++ mehr auf Speicher achten, als in Webbereiche wie in React?
* C++ wird für extrem schnelle und wichtige Software benutzt die nah an der Hardware ist (Medizingeräte die dich operieren, Industrie, Autos)
* Hier möchte man jedes unnötige Speichern von Daten verhindern und alles so optimal machen wie es möglich ist. Die Geräte haben nur begrenzte Resourcen und auch nur einen CPU/RAM etc zur Verfügung.
* Auch laufen solche Geräte manchmal monatelang oder sogar Jahre ohne sie aus zu machen oder neuzustarten. Bedeutet sie dürfen keine MemoryLeaks haben. (Siehe MemoryLeak Karte)
* Im Webbereich lassen sich oft ganze Rechenzentren hinter eine Website/Webapp hängen. Wenn ein Server ausfällt übernimmt ein anderer. Wenn der CPU voll ist wird mit einem LoadBalancer ein zweiter Server dazugeschaltet. Der Nutzer merkt das alles im Hintergrund nicht. (Die Cloud hat "unendlich Speicher/Ressourcen" auch wenn es natürlich nur eine sehr hohe Zahl ist und auch mal die Apple.de Website down gehen kann)
* Auch schließen fast alle Nutzer sehr schnell und häufig die Webseiten da entstehen kaum MemoryLeaks, die Apps werden qausi immer neugestartet.
51
Was ist ein MemoryLeak, warum ist er wichtig und wie verhindert man diesen?
* MemoryLeaks entstehen wenn eine App lange läuft und nicht korrekt programmiert ist
* Es sammeln sich Daten an, welche eigentlich von Code gar nicht mehr benötigt werden. Diese können dann mit der Zeit immer und immer mehr werden. Bis der CPU/der RAM voll ist und das Programm abstürzen wird oder das gänze Gerät langsam und unbenutzbar wird.
* Dinge wie ein Garbage Collector einer Programmiersprache und sauberes und überlegtes Programmier, aber auch gutes Testen können MemoryLeaks verhindern.
* Garbage Collectoren analysieren während eine App läuft, ob eine Variabkle, Component, DOM-Elemente, Funktionen etc noch gespeichert werden müssen, weil sie nochmal verwendet werden können. Wenn nicht löschen sie diese und machen auf dem Gerät Speicher frei.
52
Was ist REST?
* REpresentational State Transfer (REST) ist die häufigste Art im Web zu kommunizieren
* Man speicht mit HTTP-Requests zwischen einem Client (Web Frontend) und einem Server (Backend) direkt miteinander.
* Man hat HTTP Codes für Erfolge/Errors (404 Not Found)
* Man kann via JSON Daten hin und her senden und so aus dem Backend und der Datenbank Daten erhalten oder diese absenden damit sie gespeichert werden
* Es gibt feste METHODEN die man nutzt wie GET (Antwort ohne Daten erhalten) POST (Daten Senden) PUT (Daten verändern) oder DELETE (Etwas löschen)
* Oftmals hat man feste Routen/Adressen wo man eine Anfrage hinsendet/abfragt wie /users/1 /users/:id /userss/new
53
Warum braucht man verschiedene Datentypen in der Programmierung?
* Wie in der Typisierung ist es wichtig zu wissen, dass nicht falsche Daten in eine Variable/Code landen können
* Deswegen limitiert man Variablen und Funktionen in ihrer Parameter die sie erhalten und dem was sie zurückgeben über Datentypen
* So findet man Fehler schneller schon bevor die App wirklich laufen muss, nämlich im Code Editor schon
54
Was ist SemVer?
* SemVer ist semantiv Versioning
* Eine Art Versionsnummern von Libraries/Apps die man schreibt eine Bedeutung zu geben
* Es besteht aus MAJOR.MINOR.PATCH also Versionsnummer 2.1.3.
* MAJOR sind Hauptversionen und können komplett BREAKING CHANGES also nicht mehr verbindbar zum vorherigen alten Code/Version des Programms sein
* MINOR sind kleine Verbesserungen und neue Features
* PATCH sind Bug fixes und Refactors
55
Was ist funktionales Programmieren und was objektorientiertes?
* Funktionales Programmieren heißt alles ist eine Funktion. Auch eine React Component die nur ein LoginButton ist, ist eine Funktion die den Button für React als JSX Element und damit später als HTML zurückgibt
* Objektorientiertes Programmieren heißt alles ist ein Objekt. Objekte sind quasi lebendige Instanzen einer bestimmten Sache und können eigenes Verhalten (Methoden) eigene Eigenschaften (Variablen) haben. Erst erstellt man Klassen und erzeugt dann so viele Objekt aus diesen, wie man möchte. Sie sind eben nicht nur eine Funktion die einfach nur aufgerufen und direkt ausgeführt wird.
56
Was ist Software Testing?
* Software Testen ist eine Tätigkeit in der man ganz genau auf eine entstandene oder noch entstehende Software schaut und diese überprüft
* Man kann ihre **Korrektheit** und **Vollständigkeit** prüfen. So kann sie falsch funktionieren oder nicht alle nötigen Funktionen haben
* Mit dem Testen kann man die **Qualität** von Software sicherstellen und überprüfen
* Oftmals findet man Bugs/Fehler wlecher ganz verschiedene Ursprünge haben und komplex enstanden sind, manche sind aber auch ganz einfach wie ein Rechtschreibfehler in einem Text
* Man möchte die Fehler finden bevor man die Software an Kunden herausgibt, um das bestmögliche Softwareprodukt zu ermöglichen
57
Welche Vorteile bringt das Testen von Software für das Unternehmen? Nenne diese kurz.
* **Qualitätssicherung** der Software
* **Keine/Wenig Bugs **in der Software
* **Sicherheit einer App/Gerät** wird sichergestellt (Verletzungen, Tod verhindern)
* Testen kann viele Fehler/Denkfehler auf verschiedenen Ebenen aufdecken und abfangen **(V-Modell**)
58
Was sind die zwei großen Kategorien von Softwaretesting?
* **Manuelles Testen** (Per Hand durch eine echte Person) auf einem gewissen Stand einer Software
* **Automatisches Testen** (Per Computer/Pipeline/Skript) was viel häufiger stattfinden kann und Ressourcen spart
59
Was ist **Qualitätskontrolle** (QC) und wie ist sie anders als **Qualitätssicherung** (QS)?
* **Qualitätskontrolle** (Quality Control QC) ist ein produktorientierter Ansatz. Man startet Programme/Apps/Geräte um nach Fehlern und Defekten zu suchen. Auch möchte man sicherstellen das alle Anforderungen der Stakeholder (Produkt Owner, Projektleiter, Endkunden) erfüllt sind. Damit fällt es unter **Validation**.
* Qualitässicherung (Quality Assurance QA) ist ein prozessorientierter Ansatz. Man überprüft also die Abläufe und Verfahren, alle Dokumente/Spezifikationen, die zur Erstellung der App/Gerät gehören. Damit fällg es eher unter **Verifikation**.
60
Welche Arten von Tests gibt es?
* Black-Box-Testing
* White-Box-Testing
* Unit-Testing
* Integration-Testing
* System-Testing
* Akzeptanz-Tests
61
Erkläre Whitebox-Testing
* Man testet ein Stück Software mit genauem Wissen darüber wie es aufgebaut ist und funktioniert
* So kann man den Fehler genau darin finden und verstehen warum er auftritt
62
Erkläre Blackbox-Testing
* Man betrachtet das zu testende Objekt wie eine schwarze Box (Magie) in die man nicht hineinguckt
* Wie etwas funktioniert ist egal, sondern man steckt einfach alles mögliche vorne hinein (Daten in normalen und verrückten Formen) und schaut ob hinten das richtige herauskommt, also ob es wie erwartet damit umgeht
* Es ist ein Mechanismus, auch große komplexe und fachfremde Dinge testen zu können, ohne diese zu verstehen.
63
Was ist Unit-Testing?
* Bei Unit-Tests testet man eine ganz kleine Einheit eines Softwaresystems.
* Meistens nur eine Funktion, wie eine "usernameValidation" Function.
* Man gibt alle möglichen erlaubten und nicht erlaubten Arten von userNames hinein und schaut ob sie mit allen richtig umgeht. Beispielsweise beim Erstellen eines Usernames auf einer Website kann man die einzelne Funktion die das macht testen.
* Man schreibt meist sehr viele Unit-Tests und versucht, das alle "abstrakten" und "generischen" Funktionen, also die man an ganz vielen Stellen in der App verwendet mit Unit-Tests abgetestet sind
* Diese kann man super automatisieren wie mit Vitest oder Jest
* Problematisch ist hier, dass niemals mehrere solcher Hilfsfunktionen in Kombination getestet werden. Es kann sein, dass jede einzelne funktioniert, aber eben sie zusammen unlogisch sind. Dafür braucht man dann Integration, System oder End-2-End Tests.
* Hier ist man ganz nah dran am Fehler und kann diese meist direkt finden/erkennen. Allerdings muss man auch alle möglichen Szenarione und Edge-Cases abtesten.
64
Was ist Integration-Testing?
* Man testet mehrere Teile seiner Software in Integration also im Zusammenspiel
* Damit kann man Fehler erwischen, welche bei einzelnen Unit-Tests nicht aufgefallen wären.
* Das kommt auch näher ran, wie die App dann später wirklich laufen würde. Allerdings ist ein End-2-End Test noch näher an der realen Nutzung der App.
* Man teste hier meist nur **funktional** (also Funktionen/Features) und liest keinen Code durch
* Wird meist direkt automatisiert nach Unit-Tests gemacht
65
Was ist ein End-2-End Test?
* Die App wird vom einem Ende (Backend-Datenbank) bis zum anderen Ende (Nutzer tippt mit Finger auf Bildschirm) durchgetestet
* Es ist quasi, wie als würde man die App einfach nutzen, nur dass man strategische und organisierte Testsfälle anlegt, die jede Funktionalität, auch diese die echte Kunden nur selten benutzen, abdeckt und ausprobiert
* Dabei kann man verschiedene Browser nutzen lassen oder langsam/schnellere Harware simulieren und vieles einstellen
* Lässt sich super automatisieren wie mit Cypress oder Playwright.
* Allerdings findet man hier oftmals die meisten Fehler, aber nicht direkt warum diese entstehen. Da man wie bei einem Uhrwerk einfach nur das Ergebnis sieht, dass etwas falsch liegt. Aber nicht genau weiß warum. Das Wissen über Fehler ist aber auch sehr wichtig.
66
Was ist ein Edge-Case?
* Ein Randfall, etwas was in einer Funktion/App möglich ist, aber man nicht daran denkt
* Analogie/Beispiel: Wenn man sich vorstellt man möchte in der Küche einen Kuchen backen. Man hat alle Zutaten, alle Geräte. Alles müsste gehen. Dann folgt man dem Rezept Schritt für Schritt ganz genau. Doch als der Kuchenteig fertig in der Form ist, findet man heraus, dass die Form zu groß für den Ofen ist und gar nicht reinpasst.
* In der Software ist es meist, dass etwas auch leer/negativ sein kann oder eben einfach unerwartet aber möglich ist.
* Deswegen sollte man im SoftwareTEsting auch immer mit allen Möglichkeiten Edge-Cases suchen. Also auch mal chinesische Zeichen statt normalen eingeben oder -1 oder 0 oder ein leeres Objekt etc. Das System sollte mit allem umgehen können.
* Es ist der "Rand" weil es im normalen Bereich meist für alles geht. Ein Nutzer kann 1-100000 Blogposts erstellen. Aber was ist wenn er seinen einzigen löscht = 0 hat und dann nochmal auf löschen drückt. Crasht dann die App? Solche Fehler sind immer am Rand von dem was man erlaubt.
67
Was ist ein Akzeptanztest?
* Akzeptanztests testen die Features/Funktionalitäten die sich ein Nutzer oder ein Stakeholder wünscht, also spezifiziert sind im Design Input (Product Owner) oder Design Output (Designer).
* Man guckt gar nicht genau auf Code und Ergebnisse sondern eher: Kann ich etwas hinzufügen? JA. Kann ich etwas löschen? Ja. Alle Features einfach durch.
68
Was ist System-Testing?
* Man prüft das ganze System/die App durch ob es den Requirements genügt
* Dafür nutzt man aber nicht wie bei End-2-End Tests einen Browser und klickt/touched herum, sondern man kann die Eingaben eines Nutzers und das ganze Verhalten mocken.
* Man kann also einfach Nachrichten an das Backend/Frontend oder beides schicken, die genau so sind als würde sie ein Nutzer erzeugen aber man macht es ohne Nutzer.
* Man testet hier auch funktional und nicht-funktional (Also Features und liest auch Code durch)
* Wird meist nach Integration-Test gemacht
69
Was ist mocken?
* Das Faken von Daten/Kommunikation
* Man braucht es wenn beispielsweise kein Backend oder Frontend da ist. Dann kann man einfach so tun also hätte jemand jetzt geantwortet oder Daten gesendet.
* Damit kann man Software-Testen oder entwickeln obwohl nicht alles da ist. Oftmals "entwickelt man gegen eine API" und mocked einfach alle deren Anfrange/Daten erstmal bis sie korrekt da ist.
* Mit Mocking kann auch ein Tester ein System prüfen und Dinge darin erzeugen die zwar möglich sind, aber so gerade nicht alleine entstehen. Damit kann man versteckte Fehler finden.
70
Was ist Alpha-Testing und Beta-Testing?
* Alpha-Testing ist es Bugs zu finden BEVOR man die Software release/veröffentlicht. Es ist eine Art von Akzeptanztest, da man mit der Spezifikation testet.
* Beta-Testing ist es das echte Nutzer Bugs in der echten App/Gerät finden. Es ist eine Art Akzeptanztest. Ist etwas nicht wie spezifiziert/gewollt werden die Nutzer es als Bug ansehen.
71
Was ist A / B Testing?
* A / B Testing ist wenn man nicht weiß welches UI bei einem Kunden besser ankommt
* Man hat noch keine Daten/Analysen dazu wie Nutzer einen Screen/View/Maske am besten nutzen wollen und werden (Umsatz erhöhen durch mehr Verkäufe wie auf Adidas Website)
* Dabei erstellt man zwei Versionen seiner App mit verschiedenen UIs und verteilt zufällig 50/50 die A Version an einige und die B Version an andere
* Man benötigt Tools die zur Echtzeit Daten analysieren, wie die Nutzer es jeweils nutzen und was besser angenommen wird
* Aufgrunddessen kann man sich dann für eine Version entscheiden
72
Wie sind die Schritte/Prozess für das manuelle Testen?
1. Verstehen der Anforderungen (Design-Input, Design-Output)
2. Die Test-Fälle schreiben (Login System -> 10 Tests)
3. Die Tests durchführen (Manuell jeden Test Schritt für Schritt durchgehen)
4. Die Ergebnisse und Bugs dokumentieren/erfassen
5. Gute Bug Reports erstellen, die Helfen die Fehler an der richtigen Stelle und richtigen Person schnell zu beheben.
6. Berichte/Reports über die Ergebnisse der Testdurchläufe erstellen und an das Management präsentieren (Diagramme, Tabellen, etc)
73
Was ist ein Testfall / Test Case und warum sollte man es nutzen?
* Ein Testfall / Test Case ist ein Dokument mit einer Regeln an Anweisungen/Schritten für die Durchführung eines Tests
* Es sorgt für eine gute Testabdeckung, da man durch die Regeln alles Features organisiert abtestet
* Es sorgt für eine bessere (Compliance) also dem Gesetzgeber und Zertifikatstellen kann man die Tests zeigen und sie sehen wie viel Mühe und Abdeckung drin steckt
* Es sorgt für weniger Risiken beim Deployen/Erstellen von Releases, weil diese automatisiert und nach Regeln schon durchgetestet sein können
* Es sorgt für höhere Kundenzufriedenheit weil die Produkte bessere Qualität und weniger Bugs haben werden
74
Was ist API-Testing?
* Beim API-Testing testest man nur (via Mocked Anfragen) die Schnittstellen zwischen Softwaresystemen
* Also die Stellen wo sie miteinander sprechen
* Oftmals gibt es hier Edge-Cases die Bugs erzeugen, da nicht beachtet wurde, wie "komisch" ein anderes System antworten/anfragen kann.
* Mit API-Tests kann man Edge-Cases dort abtesten und früh entdecken
* Es gibt meistens API-Dokumentationen die genau festlegen wie Systeme miteinander sprechen dürfen, das kann man abtesten.
75
Was ist der Unterschied zwischen Verifikation und Validierung?
* **Verifikation** ist eine **statische** Analyse man prüft den Code/Dokumente/Spezifikation an sich. Liest es sich durch, überlegt, diskutiert über Besonderheiten und Edge-Cases oder etwas was evtl nicht bedacht wurde.
* **Validierung** ist eine **dynamische** Analyse die auf dem Produkt/App/Gerät passiert. Man führt die App wirklich aus und testet auf dem Produkt.
76
Was ist der Unterschied zwischen einem **Bug**, **Defekt** und **Fehler**?
* Ein **Bug** ist ein Coding Fehler -> App crasht, Nutzer kann app nicht benutzen (Kann vor App ausführen gefunden werden)
* Ein **Defekt** ist ein unerwartes Ergebnis
* Ein **Fehler** ist ein Missverständnis, Miskonzeption/Überlegung eines Softwareentwicklers, Designers oder Product-Owners -> Analogie: User kann andere Nutzer löschen, weil nicht darüber nachgedacht wurde
77
Was sind die Vorteile von manuellem Testing?
* Sie passieren als Validierung auf der echten App/Produkt in dem Produktionszustand/neuester Version
* Die Tester brauchen kein tiefes Verständniss über Programmierung und verschiedene Methoden wie DevTools, Debugging und können mit Testfällen als Regeln direkt starten
* Der Mensch ist immer noch das kritischste Auge. Animationen, Wartezeiten oder kleine Fehler fallen einem Menschen direkt auf (Etwas lädt zu lange), während es ein System einprogrammiert haben muss, was oftmals nicht mal geht.
* Manuelles Testen ist oft hilfreich wenn man nur 1-2 testen will. Danach sollte man automatisieren.
* Manuelles Testen hat kleinere Aufwandskosten die man reinsteckt, weil man keine Automatisierten Tests coden muss, aber das Ergebnis ist langfristig auch weniger wertvoll, als immer wiederholbare automatisierte Tests.
78
Was sind die Nachteile von manuellem Testing?
* Manuelle Tests kosten viel Personalaufwand/Kosten
* Manuelle Tests können nicht direkt wiederholt werden und brauche gute Berichte/Reports am Ende
* Es kann Einschränkungen geben, dass ein Bug das weitere Testen behindert oder ein Tester kann Fehler machen und etwas falsch einschätzen oder nicht testen. Automatisierte Tests, testen verlässlich wie man sie programmiert hat.
* Wenn man etwas ganz oft wieder testen muss, lohnen sich manuelle Tests nicht. Sie testen nur auf einer bestimmten Version.
79
Ist Dokumentation beim manuellen Testen wichtig?
* Ohne Dokumentation beim manuellen Testen kann man den Test auch sein lassen
* Leute wissen nicht wie sie den Fehler finden und beheben können
* Manager wissen nicht wie viele Fehler es gibt und was alles geht
* Tester testen Dinge doppelt und dreifach und übersehen Dinge weil sie keine Organisation/Struktur haben
80
Wann würde man eher manuelles Testen benutzen?
* Kleine Projekte
* Wenn man direkt lostesten muss/soll
* Wenn man Nutzererlebnisse (Ladezeiten, Animationen, Umständlichkeit durch Screen zu navigieren) testen will
81
Was ist exploratives Testen?
* Man untersucht/"explored" einfach die App durch und versucht Verhalten und Dinge zu verstehen
* Es ist weniger Regelbasiert und folgt eher der Mentalität und dem Denken des Testers, um DInge zu entdecken worüber man weniger nachgedacht hat
82
Was ist funktionales Testen?
* Funktionale Tests überprüfen die Funktion einer App/Gerät
* Also kann ich mich einloggen, ausloggen etc
83
Was ist nicht-funktionales Testen?
* Nicht-Funktionale Tests überprüfen andere Aspekte einer App/Gerät
* Also ist es Benutzerfreundlich, ist die Performance gut/schnell, ist es zuverlässig
84
Was sind die Phasen eines Software-Testing-Lifecycles?
1. Analyse Anforderungen (Design-Input, Design-Output)
2. Testplanung (Strategie/Ordnung erstellen, welche Screens testen wir alle durch?)
3. Test Case Entwicklung (Testfälle in Schritten wie ein Rezept aufschreiben wie in Zaphyre)
4. Test Umgebung Einrichten (Habe ich die richtige Softwareversion, richtiges Gerät für den Test?)
5. Testausführung (Alle Testfälle ganz genau Schritt für Schritt durchgehen und auf Details achten)
6. Test Zyklus Beenden (Alle Tests als abgeschlossen betrachtetn und Ergebnisse berichten/Report)
85
Was macht einen guten Software Tester aus?
* Man traut sich auch Dinge "kaputt zu testen" und hat Spaß daran Fehler zu finden
* Man hat hohe Ansprüche an die Qualität des Endproduktes
* Man geht mit Fehlern (Sorgen oft für Konflikte und Ablehnung) diplomatisch um (Nicht sagen, du bist Schuid und hast es kaputt gemacht, das dauert jetzt wieder lange wegen dir, sondern ganz neutral. Hier ist vermutlich ein Fehler.)
* Man hat gute kommunikative Fähigkeiten
* Man kann Situationen und Gründe für Fehler gut einschätzen/debuggen und diese an die richtigen Stellen lenken
86
Was sind Regressionstests?
* Das wiederholte Testen von den gleichen Features/Systemen einer App, um zu gucken ob sich nichts verändert hat
* Manchmal schleichen sich Bugs in Dinge rein, die vorher fehlerfrei und gestet waren
87
Was ist ein **Testrahmen** / **Test-Harnisch**?
* Eine Sammlung von Softwaredaten und Testdaten die man benutzen kann um eine App/Gerät unter verschiedenen Umständen/Umgebungen zu testen
* Z.B. ein Stresstests, dem Gerät hohe Hitze aussetzen, die CPU sehr voll machen und dann testen
* Das macht man meist automatisiert und mit Skripten
* Manche Test-Tools haben solche Dinge integriert
* Manuelle müsste zu viel verändern/Einstellen, so dass es besser automatisiert geht
88
Was ist ein Test-Closure / Test-Abschluss?
* Eine Test-Closure / Test-Abschluss ist ein Dokument was ein Bericht darstellt
* Es zeigt die Ergebnisse aller Tests und gibt Infos über die gefixten Bugs und gefunden Errors (Oft Diagramme)
89
Was ist Positiv-Testen?
* Man schaut ob die App/Gerät so funktioniert wie man es erwarten würde
* Man testet mit Dingen die normal sind und oft auftauchen
* Man hat meist eine ganz begrenzte Anzahl an Dingen die man überprüft (Einloggen, Ausloggen, 1 neuer Blogpost, 2 neue Blogposts etc) und ist dann irgendwann fertig
90
Was ist Negativ-Testen?
* Man versucht aktiv für die App/das Gerät Fehler zu erzeugen
* Man gibt extra unübliche und Edge-Case Daten ein (chinesische Zeichen, superlange Namen, negative Zahlen etc)
* Man ist so kreativ wie möglich, um ungültige Eingaben die zu Fehlern führen, zu erkennen
* Kann auch durch automatisierte Tests geschehen, da muss man diese nur vorher alle überlegen und erstellen
91
Was ist ein kritischer Bug?
* Ein Bug welcher eine Requirement (Design-Input) wie z.B. ausloggen kaputt macht
* Aber auch Bugs welche so schlechtes Nutzererlebnis erzeugen oder das Gerät langsam/unbrauchbar machen, so dass es nicht akzeptabel ist
92
Woher weißt du ob die Version, auf welcher du testet überhaupt sinnvoll und die richtige zum testen ist?
* Ich habe in meiner Teststrategie festgelegt auf welcher Softwareversion und welcher Umgebung ich teste
* Ich überprüfe durch Tools/Mechanismen die evtl Developer bereitstellen, ob die Versionen auch wirklich in der App/dem Gerät gerade drauf sind
* Ich spreche mich mit dem Team ab und erfahre, ob man einen Test verschieben muss weil etwas noch nicht fertig ist oder ob man gewisse Sachen schon vorher testen kann
93
Welche Bugs sind für dich akzeptabel?
* Bugs welche nicht kritisch sind
* Bugs welche wir im Projekt noch gemeinsam so einordnen, dass wir sie entweder später erledigen können oder vernachlässigen
* Beispiel eine Abweichung eines Login-Buttons um einen Pixel nach rechts ist vernachlässigbar, aber wenn der Login nicht geht muss schnell behoben werden
94
Was kann man bei einer React-App alles testen?
* Ob die App Startet
* Ob Localization also Translation für andere Sprachen geht
* Ob Funktionalitäten gehen
* Ob Units/Also Hilfsfunktionen richtig funktionieren
* Ob Seiten/Elemente rendern/angezeigt werden
* End-2-End die ganze App als "Nutzer" durchgehen
* Ob das Styling korrekt ist (Pixel, Abstände, Farben etc)
* Ob es Performance-Probleme gibt (MemoryLeak, Ladezeiten)
* Ob die Requirements erfüllt sind
* Ob Teile des Systems miteinander korrekt funktionieren
* Ob Negativ-Tests wie falsche Eingaben die App crashen lassen oder in Fehlerzustände bringt
95
Was sind Vorteile von Playwright gegenüber Cypress?
* Playwright geht mehr in die Tiefe als Playwright und ist für komplexe und große Apps sinnvoller
* Microsoft steht hinter dem Projekt und sorgt auch finanzielle für viele gut und teure Features
* Es kann im Gegensatz zu Cypress auch Apps testen, welche mehrere Tabs gleichzeitig benötigen, wie eine Messenger wie WhatsApp, welcher durch das Testen nur in einem Tab (Nur der eingeloggte Nutzer) nicht sehr sinnvoll ist.
* Playwright kann nicht nur JavaScript/Typescript sondern kann viele Programmiersprachen wie Java, Python etc testen und damit können entwickler ein Tools über mehrere Sprachen / Projekte als Wissen vertiefen
* Playwright hat die schnellste Performance und ist somit besser für Pipelines
* Es ist nicht ganz so hübsch die Cypress aber hat bessere Funktionen (Recorder für Selektoren/Testbauen etc)
* Man kann den Testrunner, also die Technologie welche die Tests ausführt austauschen, das geht bei Cypress nicht
*
96
Was sind Vorteile von Vite gegenüber Jest?
* Jest ist ein älteres Test-Projekt und hat sich dem neuen JavaScript/TypeScript nicht gut angepasst
* Es hat alles was Jest kann, kann sofort TypeScript testen, hat automatisches Import/Export, alles geht einfach sofort ohne viele Configs und Recherchieren. Man ist schneller damit.
* Es passt sich gut an vite an, was ein bekannte und beliebter Bundler für React Apps ist (Eppendorf benutzt ihn) und wird von den gleichen Leuten entwickelt, damit ist es immer perfekt kompatibel für die vite React App.
*
97
Ist es gut immer und immer wieder die gleichen Tests durchlaufen zu lassen?
* Nein, man ist zu sehr eingenommen alles abgedeckt und eine 100% Testabdeckung zu haben
* Dadurch übersieht man seltene Bugs wie Edge-Cases und Flaky Bugs und ist nicht kreativ genug im Negativ-Testing
* Helfen kann hier ein exploratives Testen und neue Tests entwickeln
98
Was sind Flaky Bugs?
* Bugs welche manchmal auftreten und manchmal nicht, obwohl man die selben Dinge in der App tut
* Das sind die schlimmsten Bugs, weil man sie nicht immer erneut reproduzieren, damit kaum finden und kaum beheben kann
* Sie entstehen meist, weil die modernen Apps aus mehreren Softwareteilen bestehen wie Backend, Frontend, Datenbank und diese asynchron also mit zeitlichen Abstand miteinander sprechen. Sprechen sie mal schneller klappt es, sprechen sie mal langsamer taucht der flaky bug auf.
* Bei sowas muss man sehr gut debuggen und reinschauen. Es hilft hier auch Stresstests zu benutzen, wie den Testrahmen / Test-Harnisch anzupassen und beispielsweise nochmal extrem langsames Internet oder einen vollen CPU mit wenig Power zu simulieren/zu testen. Evtl taucht der Bug nur dann auf.
99
Was sind Race Conditions?
* Race Conditions nennt man es wenn ein Code nur einen Bug/Fehler hat, wenn etwas zeitlich in der falschen Reihenfolge passiert
* Das ist ein flaky Bug, da es manchmal klappt, manchmal nicht, je nachdem wie schnell etwas gerade war.
* Das sind schwere Fehler die man finden und beheben muss.
* Code / Software sollte so sein, dass sie damit umgehen kann, wenn ein Teil oder System mal etwas langsamer ist.
100
Was ist Debuggen?
* Alle Möglichkeiten nutzen um Fehlergründe zu finden
* DevTools
* Code durchlesen
* Redux Store/Zentrales State Management anschauen als in Echzeit die Variablen in einer App
* Props von Components in Echtzeit während die App läuft ansehen
* Console.logs nutzen oder mit Bread-Points arbeiten
101
Was sind Break Points?
* Eine Art im Debugging Stellen im Code zu schreiben wo die App absichtlich anhält und viele internen Werte und Variablen-Daten ausgibt
* Man kann diese dann dort prüfen und danach die App weiter oder bis zum nächsten Break-Point laufen lassen
* Ist besser als console.log zum debuggen zu benutzen :D
102
Was ist ein Top-Down Ansatz beim Testen?
* Das Testen beginnt vom Top (Zusammengesteckte Systeme (wie System-Test, Integrationstest) bis zum Bottom den kleinen Units (Unit-Testing)
103
Was ist der Bottom-Up Ansatz beim Testen?
* Das Testen beginnt vom Bottom den kleinen Units (Unit-Testing) bis zum Top (System-Test, Integrationstest)
104
Was ist Smoke-Testing?
* Bei Smoke-Tests testet / klickt eine App mit allen Funktionalitäten einfach durch
* Es ist oft der **erste Test auf einer neuen Version einer Software**
* Man versurch grob einfach zu schauen, ob alles noch läuft ohne jedes Detail und jede Kombination von Features/Einstellungen durchzugucken
* Ein **grober** und **weiter** Ansatz um die Stabilität zu prüfen
* Hier **dokumentiert** man und kann **Skripte** nutzen
105
Was ist Sanity-Testing?
* Bei Sanity-Tests testes man auf Softwareversionen/Ständen die schon durch Smoke-Tests und Regressionstests erfolgreich durchgelaufen sind und eigentlich gut aussehen. Also **nicht auf neuen Versionen**.
* Ein **detaillierter** und **tiefer** Ansatz in einzelne Funktionalitäten
* Braucht meist **keine Dokumentation** und kann **manuell** ausgeführt werden
106
Was ist statisches Testen?
* Hier wird statisch White-Box Testing gemacht
* Wird meist früh im Testprozess gemacht
* Hier wird **verifiziert** und **Prozesse/Code/Dokumente/Spezifikationen untersucht**
107
Was ist dynamisches Testen?
* Hier wird **Code ausgeführt** (dynamisch)
* Wird später im Testprozess gemacht
* Man **validiert** output gegen erwartete Ergebnisse
108
Woher wissen wir wann wir aufhören können zu testen?
* Man muss die Deadlines des Projektes im Blick behalten. Also wann muss das Produkt vollständig oder final da sein? Hat man alle Personalresourcen also Tester immer zur Verfügung?
* Wann ist das Testbudget aufgebraucht?
* In welchem Zustand sind die Test-Cases? Haben alle definierten und ausgedachten Tests eine 100% Erfolgsrate und bei den Kunden gibt es keine Probleme?
* Ist die Testabdeckung bei einem eigens akzeptierten hohen Wert? (90%+? 100%?)
* Tauchen schon lange keine neuen Bugs mehr auf?
* Wenn wir es so eingeplant haben, dass die Testphase laut dem Projekt beendet sind und alle Parteien damit glücklich sind.
109
Was machst du wenn Software so buggy ist, dass du sie nicht testen kannst?
* In solchen Situationen sollte man am besten die Bugs, welche einem direkt begegenen schon erfassen
* Man kann definieren dass einige Blocks blockierend sind, andere nicht und damit helfen die schweren und blockierenden Bugs schneller zu beseitigen da sie als wichtiger priorisiert und auch erkannt werden. Manchmal haben andere Projektteilnehmer wie Software-Developer aber auch Manager oder Produkt-Owner andere Ansichten auf die Wichtigkeit. Wenn es wirklich wichtig ist, muss man das geschickt vermitteln.
* Wenn sich die Situation evtl auch gewollt aktuell nicht ändert, muss man nicht Däumchen drehen. Man kann anfangen Testfälle zu definieren und die Planung der späteren Tests voranzubringen.
* Man kann auch dafür sorgen, dass alle verstehen warum die Qualität der Software wichtig ist und diese ernster nehmen, so dass der Zustand schnell besser wird.
110
Woher weiß man ob eine Software die Anforderungen erfüllt?
* Dafür muss man am besten nach dem V-Modell genau überlegen welche verschiedenen Ebenen und Perspektiven es gibt
* Die Software sollte die Design-Input Anforderungen und die wichtigsten Design-Output Anforderungen erfüllen
* Die Tests sollten keine schwerwiegenden Bugs aufzeigen oder diese sollten akzeptiert/besprochen sein
* Die Test-Cases sollten soweit wie möglich durchlaufen sein und eine hohe Testabdeckung bereitstellen
* Alle sollten sich sicher fühlen die Software an Kunden in den Markt zu übergeben
* Nutzertests sollten zeigen, dass Nutzern die Software/das Gerät gefallen kann
111
Was sind Nutzertests?
* Man weiß nie wirklich in der Erstellung einer Software, ob diese den Kunden gefällt und das umsetzt was die Hauptkunden möchten
* Daher kann man Nutzertests durchführen und frühe Softwarestände bereits an Testgruppen geben und dort wichtiges Feedback und Rückmeldungen sammeln
* Dadurch kann man bevor alles fertig ist noch wichtige Entscheidungen treffe, Dinge ändern und streichen und das Nutzererlebnis verbessern
* Auch der Produkt-Owner kann falsche Vorstellungen davon haben, im Endeffekt entwickeln wir Software/Geräte damit den Nutzern diese gefallen und sie diese mehr kaufen als die von der Konkurrenz
112
Kann man auch schwerwiegende Bugs akzeptieren?
* Ja, das ist immer eine Gruppenentscheidung.
* Ich als Softwaretester kenne nur meine Perspektive und versuche die der anderen nachzuvollziehen
* Oftmals muss man von mehreren Ebenen (V-Modell) und vielen Ansätzen auf Software und Bugs schauen, um einschätzen zu können, ob man es sofort, später oder gar nicht behebt.
* Manchmal ist ein Bug auch ein Features/ doch gewollt.
113
Wann testest du eher automatisch als manuell?
* Wenn es viele und lange Schritte gibt, das kann ein Skript besser als ein Mensch
* Wenn die Tests in einer Pipeline ausgeführt werden sollen
* Wenn wenig Zeit zum Testen ist
* Wenn es viel Code/Systeme gibt die oft erneut gestestet werden müssen
* Wenn Reports/Bericht nach jedem einzelnen Test erfolgen sollen, das wäre viel manueller Aufwand
114
Kann man einen System-Test zu jeder Zeit machen?
* Nein, für einen echten System-Test müssen alle Teile einer App/Gerät vorhanden sein und ordentlich funktionieren
* System-Tests passieren meist spät und vort den Nutzerakzeptanz-Tests
115
Was sind Best Practises die man beim Testfall-Schreiben befolgen sollte?
* Die Testfälle sollten in einer priorisierten Reihenfolge erstellt werden, die der Projekt-Deadline und dem Projektrisiko folgt.
* Man muss an das Pareto-Prinzip denken (80/20) man kann nicht alles schaffen
* Testfälle mussen kategorisiert und ordentlich aufgeteilt sein (User-Management, Software-Update)
* Tests müssen klein und modular sein, so das man nur eine kleine Sache testet und nicht mehrere Bugs sich vermischen
* Testfälle sollten einfach sein
* Testfälle sollten immer im Kopf behalten, dass man das beste für die Nutzer und Anforderungen/Wünsche der Nutzer erreichen will
* Man sollte ein Test-Tool wie Zaphyre benutzen um Unterstützung zu haben
* Man sollte die Testfälle im Auge behalten mit Tools, um nicht doppelte zu erstellen
116
Warum ist es unmöglich eine Software/ein Gerät zu 100% zu testen und es komplett Bugfrei zu machen?
* Die Welt und große Software ist zu komplex
* Die Definition von Bugs ist schwammig, das eine ist für jemanden ein Bug für jemand anderen vernachlässigbar. Es gibt zu viele Perspektiven und Blickwinkel.
* Wir können nur so gut wie es geht Errors, Dekte und Bugs reduzieren. Die schwerwiegensten am meisten und versuchen, dass die App stabil läuft und sich richtig verhält.
117
Ist automatisches Testen ein Ersatz für manuelles Testen?
* Nein, es ist eine Erweiterung und ein hilfreiches Tool, um dem manuellen Testen Arbeit abzunehmen
* Dinge wie Nicht-Funktionale Tests (Animationen, Performance, Nutzerfreundlichkeit) können nur Menschen testen und wir sind flexibler als Maschinen, denken nicht nur in 0 und 1. Wir erkennen Zusammenhänge und können mehrere Bugs und deren Grund verbinden und bessere Entscheidungen treffen als ein Skript.
118
Was ist regulatorisches Testen / der regulatorische Abnahmetest?
* Ein Test, welcher eine Software/Gerät auf die geltenden Gesetze und Regeln prüft
* Diese werden **verifiziert** also mit bestehenden Dokumentationen/Code/Berichten aus dem Testing etc gepüft
