23. November 2022

Vergessen Sie das Testen nicht!

Softwaretests sind ein Teil der Softwareentwicklung und gehören zum Qualitätsmanagement. Ziel ist die Verifizierung und Validierung der Software. Bei der Verifizierung wird geprüft, ob die entwickelte Software der Spezifikation entspricht.

 

Laptop mit Symbolen für Qualitätssicherung und Kundenzufriedenheit

Warum testen?

 

  1. Ein Teil der Arbeit geht von den Entwicklern auf die Tester über.
  2. Die Softwareentwicklung wird schneller.
  3. Durch das Beseitigen von Fehlern bleibt die Softwarequalität hoch.
  4. Die Anwendung wird von außen betrachtet. 

Tests prüfen die Qualität der Software und der Produkte, die wir entwickeln. Ein Testautomatisierer soll zum Beispiel die Entwickler entlasten. In manchen Unternehmen gibt es gar keine Testabteilung, dann schreiben nur die Entwickler die Tests. Die Pflege der Tests kostet sie oft viel Zeit, weil sie gleichzeitig Code und Dokumentation pflegen müssen. 

Gestresster Entwickler hält sich vor dem Laptop den Kopf

Tests beschleunigen die Projektarbeit und helfen, das Release der Anwendung zu steuern. Fehler können das Release verzögern – sind sie behoben, geht das Release am Ende des Projekts deutlich schneller. Während des Projekts dienen solche Tests vor allem dem Qualitätsmanagement. 

Manuelle und automatisierte Tests

Tests lassen sich in manuelle und automatisierte einteilen. Wichtig: Das Ziel ist in beiden Fällen dasselbe – Fehler beseitigen. Getestet wird, um die Qualität zu prüfen. Ist eine Anwendung gut getestet, unterscheiden sich manuelle und automatisierte Tests im Endergebnis nicht. Sie unterscheiden sich in der Vorbereitungszeit und in der Dauer. In verschiedenen Projektphasen trifft man häufiger auf unterschiedliche Testarten. Manuelle Tests können sofort beginnen. Ein Entwurf der Anwendung genügt, und schon lassen sich ihre Funktionen prüfen. Das hängt natürlich davon ab, welche Anforderungen an das Testen gestellt werden. Manuelle Tests kommen zum Einsatz, solange es noch keine automatisierten Tests gibt. Automatisierte Tests erfordern Testszenarien, also die Festlegung, was und wie getestet wird. Ein manueller Tester kennt Testszenarien oft aus eigener Erfahrung – er weiß, was und wie zu prüfen ist. Für automatisierte Tests muss ein ganzes Automatisierungsprojekt aufgebaut werden. Das kostet Zeit und ist der Grund, warum sie später starten als manuelle Tests. 

Der Vorteil automatisierter Tests: Sie sind wiederholbar und tun jedes Mal genau dasselbe. Für automatisierte Tests nutzen wir zum Beispiel das Framework WebDriverIO. Es basiert auf Selenium, einem der verbreitetsten Open-Source-Werkzeuge zum Testen von Webanwendungen. Auch Appium baut auf Selenium auf – damit testen wir mobile Anwendungen. 

 

Testarten

Testarten: Performance-, Backend-, End-to-End- und Funktionstests

  • Performance – prüft, ob die Software schnell oder langsam läuft, wie stark sie Hardware und Datenbanken belastet und ob das System an Obergrenzen stößt. Werden solche Grenzen erreicht, geht das Projekt zurück an die Entwickler. Sie optimieren die Anwendung, damit sie schneller läuft oder weniger Hardware braucht, oder ersetzen bei Servern die Hardware durch leistungsstärkere. Solche Tests sind typisch für Projekte mit Systemen etwa für Bestellungen in einem Onlineshop oder für die Prüfung der Belastbarkeit eines Servers, zum Beispiel bei der maximalen Zahl angemeldeter Nutzer oder der maximalen Zahl von Bestellungen in kurzer Zeit in einer Shop-Anwendung. 

  • Backend – das Zusammenspiel von Datenbank und Software. Bei dieser Technik werden die Serverseite oder die Datenbank einer Webanwendung untersucht. Hauptziel von Backend-Tests ist die Prüfung der Datenbank- und Anwendungsschicht. Sie decken Probleme oder Fehler in der Datenbank oder auf der Serverseite auf.
  • E2E – End-to-End-Tests decken den größten Umfang ab. Getestet wird aus Sicht der Endnutzer der Anwendung. Man bekommt die gesamte Anwendung zum Testen und prüft ihre Funktionen. Wie sie intern arbeitet, spielt keine Rolle – es zählt nur das Ergebnis: ob sie funktioniert und ob sie richtig funktioniert. Die Tests sollen sich wie Nutzer verhalten, also in Felder klicken und die Elemente prüfen, auf die Nutzer Zugriff haben.

  • Funktional – eine Art von E2E-Test, bei der einzelne Funktionen aus Sicht der Nutzer geprüft werden. Beispiel: In einer Onlineshop-Anwendung ist eine Funktion das Hinzufügen zum Warenkorb, eine andere das Anzeigen von Produkten. Funktionstests umfassen kleinere Teile der Anwendung als gewöhnliche E2E-Tests – nur einzelne Module. 

Damit Tests im Projekt ihren vollen Nutzen bringen, arbeiten Tester mit passenden Werkzeugen. Eine Lösung zur Verwaltung von Testszenarien, Testplänen und Testläufen ist „Kiwi TCMS“. Das Werkzeug speichert alle Testszenarien und ermöglicht neue Testläufe zur Prüfung der Anwendung. In Kiwi lassen sich Fehler melden und dem jeweiligen Testlauf zuordnen. So ist dokumentiert, in welcher Version der Anwendung ein Fehler aufgetreten ist. Die Fehler werden außerdem in „Jira“ erfasst, dort dem Projektmanager gemeldet und einem Entwickler zur Behebung zugewiesen.

 

Testarchitektur

Gemeint ist die Steuerung und Planung des gesamten Anwendungsprojekts – die Phase, in der die Anwendung geplant wird. 

BDD / TDD im Überblick

TDD-Zyklus: fehlschlagenden Test schreiben, Test bestehen lassen, refaktorieren

Quelle: https://www.infolytx.com/development/processes/bdd-tdd/attachment/tdd-bdd/

  • TDD (Test-driven Development, testgetriebene Entwicklung) – Tests entstehen zu Beginn des Projekts, und das Projekt wird so gebaut, dass es sie jederzeit besteht. Zuerst werden Unit-Tests geschrieben, die prüfen, wie die Methoden arbeiten. Erst danach entstehen der Entwurf der Anwendung und die Methoden, die von Anfang an mit Unit-Tests geprüft werden, damit die Anwendung immer korrekt funktioniert – also die richtigen Werte zurückgibt. Die Arbeit der Tester beginnt hier früher, denn das Projekt startet mit der Planung der Tests. Am Anfang eines TDD-Projekts schlagen alle Tests fehl. Je mehr Teile des Projekts entstehen, desto mehr Tests werden bestanden.
  • BDD (Behaviour-driven Development, verhaltensgetriebene Entwicklung) – Entwicklung und Tests auf Basis des Verhaltens der Anwendung, also die verbreiteteren End-to-End-Tests. Getestet wird, nachdem Teile der Anwendung fertig sind.

 

Testen als Dienstleistung

Vereinfacht gesagt: Tester werden Kunden zur Verfügung gestellt, also Outsourcing. Der Kunde muss sich dann nicht um das Team kümmern. Seine eigenen Tester kann er in andere Projekte oder ins Testmanagement verlagern. Für ihn zählt das Ergebnis: ob Fehler gemeldet und ob sie behoben wurden.

Eine weitere Möglichkeit in der Qualitätssicherung ist die Optimierung oder das Refactoring einer Anwendung: Ein Kunde kommt mit seiner Anwendung, weil er die Performance verbessern oder ihre Konsistenz prüfen lassen will. Der Tester prüft dabei, wie die bestehende Anwendung funktioniert, und kann vorschlagen, welche Module verbessert werden sollten. 

Lösungen für das Testen entwickeln: Projekte für automatisierte Tests und Testgeräte. Beispiel: Das IoT-Team baut ein Gerät, um das Produkt eines Kunden zu testen. Das Gerät ist mit automatisierten Tests verbunden, die prüfen, ob das Produkt des Kunden richtig funktioniert. Die automatisierten Tests können Sensorwerte des Geräts auslesen und den Aktor steuern, der die Taste am Produkt drückt.



 

Das könnte Sie auch interessieren:
Der CTO von EMBIQ über Qualitätssicherung
Wie wir IT-Lösungen liefern
Generative KI in der Qualitätssicherung von IoT-Systemen

Angebot oder Beratung anfragen

Verantwortlich für die Verarbeitung Ihrer personenbezogenen Daten ist die EMBIQ sp. z o.o. (Lublin). Wir verarbeiten Ihre Angaben ausschließlich zur Beantwortung Ihrer Anfrage und speichern sie höchstens 24 Monate. Bei Fragen zu Ihren Daten erreichen Sie uns unter info@embiq.com.

Wir sehen uns Ihr Projektkonzept und seinen aktuellen Stand gemeinsam an.

Sie erhalten von uns einen ersten Vorschlag zum Projektumfang sowie eine Zeit- und Kostenschätzung.

Die Beratung ist durch eine Geheimhaltungsvereinbarung (NDA) geschützt.

EMBIQ sp. z o.o., Sitz: Lublin · Anschrift: al. Kraśnicka 27, 20-718 Lublin, Polen · Registergericht: Sąd Rejonowy Lublin-Wschód w Lublinie z siedzibą w Świdniku, VI Wydział Gospodarczy KRS · KRS 0000338852 · NIP 9462590420 · Stammkapital: 75.000,00 PLN