SQAT - HSLU - TEST

SQAT - HSLU - TEST

SQAT - HSLU - TEST


Kartei Details

Karten 21
Sprache Deutsch
Kategorie Informatik
Stufe Universität
Erstellt / Aktualisiert 05.06.2017 / 21.06.2017
Weblink
https://card2brain.ch/box/20170605_sqat_hslu_test
Einbinden
<iframe src="https://card2brain.ch/box/20170605_sqat_hslu_test/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>

Erfolgreiches Testen in der Praxis beinhaltet DREI Dinge: 

  • Tools
  • Prozesse
  • Personal

VModell

Softwaretest

  • Ein Softwaretest prüft und bewertet Software auf Erfüllung der für ihren Einsatz definierten Anforderungen und misst ihre Qualität 

Testen vs. Experimentieren

  • Testen unterscheidet sich vom Experimentieren dadurch, dass beim Testen eine Erwartung gibt die belegt werden soll, während das Ergebnis beim Experimentieren offen ist oder nur vermutet werden kann. 

Rollen im Testen

  • Testmanager – Führung

  • Testarchitekten, Testengineer – Ingenieur

  • Testanalyst 

  • Testdatenverantwortlicher 

  • Tester

Was ist Qualität?

  • Allgemein: Qualität ist das was man erwartet
  • Qualität ist dann erreicht, wenn das Produkt den Anforderungen entspricht
  • In Bereich von Software kann Qualität mit Normen gemessen werden
    Normen geben vor was erwartet wird
  • Getestet wird immer die Qualität einer Software.
  • Um Qualität richtig zu messen muss Qualität zunächst richtig definiert werden. Der Prozess nach ISO 25'000 tut dies nach acht Kategorien:
  • Qualität ist dann erreicht, wenn das Produkt den Anforderungen entspricht. 

ISO 25'000 Qualitäsmerkmale

Der Test-Prozess 4 - Schritte

Analysieren -> Vorbereiten -> Durchführen -> Auswerten

Teststrategie

  • Eine Teststrategie gibt Auskunft, mit welchem Schwerpunkt getestet werden soll
  • Liegt der Fokus auf den Preis und der Durchlaufzeit (wenig Tests, nur oberflächlich)
  • Liegt der Fokus auf der Sicherheit (viele sehr kreative Spezialfälle)
  • Liegt der Fokus auf der Bedienbarkeit (Ergonomie, Aufbau der Menuestrktur)
  • oder auf der Performance (Geschwindigkeit, Wartezeit Verfügbarkeit)

RPI: Risiko Prioritäts-Index

  • Business Relevanz
    Auswirkung bei Fehler, wie schlimm ist ein Fehler (3 am schlimmsten)
  • Auffindbarkeit
    Wie schnell wird ein Fehler entdeckt, offensichtlich (1=leicht erkennbar)
  • Komplexität
    Wie komplex ist die Anforderung und die Lösung dazu? (3=sehr Komplex)

Bug, Change, neue Anforderung 

Welche Fragen sollen mit Hilfe von Kennzahlen beantwortet werden?

  • Was darf es kosten?
  • Sind wir bereit?
  •  Ist es reif?
  • Wagen wir es

Testkonzept

  1. Um was geht es, um was geht es nicht
  2. Wo liegen die Risiken
  3. Wer ist verantwortlich
  4. Wie ist das Vorgehen
    Prozess (Metriken), Artefakten, Quality-Gates
  5. Wie wird auf welcher Stufe getestet
    Umgebung, Testarten, Daten, Methoden
  6. Messbare Kriterien für
    Eintritt, Abbruch, Abnahme, Akzeptanz

Struktur Testkonzept

Einleitung

Testobjekt

Testumfang

Kommunikationswege

Risikobetrachtung

Lieferobjekte

Teststufen & Lieferobjekte

Komponententest/Unit-Tests

Planung

Abnahmetest

Testabbruch

Testaktivitäten

Personal

 

Inhalte für jede Tesstufe 

Testdesigntechniken

Testendkriterien

Testmetriken

Anforderungen an Testaten

Anforderungen an die Testumgebung

Regressionstests und Fehlernachtests

Anforderungen

vollständig, widerspruchsfrei, messbar

Testarten

Welche Vorbereitung benötigt es bis zur Testdurchführung?

  • Infrastruktur
  • Team
  • Daten
  • Automaten
  • Eskalationswege
  • NFA- Tets’s
  • Stufen
  • Szenarien, Test Cases, Test – Fälle

Technische Schuld

  • Beim Schnelle Features implementieren wird oft Architektur und alles rundherum vernachlässigt (Architektur, Refacotring, ...) Dann wächst die technische Schuld. Birgt Risiko dass plötzlich bei einer kleinen Änderung alles zusammenbricht.

 

Fehler ist nicht ein Fehler

  • Fehler unterscheiden sich. Auswirkung wer ist betroffen
  • Fehlerklassen
  • Nach Auswirkung beurteilen. 

 Zeitpunkt der Erstellung Unit Tests

  • Bevor die Unit erstellt wird (TDD)
  • Nachdem die Unit erstellt wurde
  • Vor Refachtroing (nach)
  • Wenn Bugs gefunden wurden
    • Bug reproduzieren mit UnitTest
    • Bug Fixen
  • Wenn technische Schuld zu hoch wird
  • Bevor Task abgeschlossen wird (DoD)