Fandom

Scratchpad

Qualitaetssicherung

216,244pages on
this wiki
Add New Page
Discuss this page0 Share

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.

Qualitätssicherung

Qualitätsziele

Nach ISO 9126 (Wikipedia):

Folgende Qualitätsmerkmale werden nach der ISO 9126 Norm berücksichtigt. Die Priorisierungs­reihenfolge wird wie folgt festgelegt:

1.Funktionalität 2.Zuverlässigkeit 3.Benutzbarkeit 4.Änderbarkeit 5.Übertragbarkeit 6.Effizienz

Die Priorisierungsreihenfolge soll keine Aussage über die Qualität der Implementierung der jeweiligen Punkte zu lassen! Alle Punkte werden nach bestem Wissen und Gewissen implementiert. Die Reihenfolge ergibt sich aus technischen Möglichkeiten, die zur Verfügung stehen und Anforderungen an das System.

Funktionalität

Unter Funktionalität wird die Frage behandelt, inwieweit die Software die geforderten Funktionen besitzt. Nachfolgend werden die definierten Anforderungen für das Produkt diskutiert. Angemessenheit: Unter der Angemessenheit einer Software wird die Eignung von Funtionen für spezifizierte Aufgaben, wie z.B. aufgabenorientierte Zusammensetzung von Funktionen aus Teilfunktionen, verstanden. Da das Produkt modular aufgebaut wird, werden wir Funktionen aus Teilfunktionen zusammensetzen. Diese Teilfunktionen werden als Bibliotheken implementiert, was eine leichtere Wartbarkeit ermöglicht und das Testen vereinfacht, da ein Problem in kleinere Teilprobleme geteilt wird. Richtigkeit: Unter Richtigkeit ist die Genauigkeit der gelieferten Ergebnisse oder z.B. die Lieferung der vereinbarten und erwarteten Ergebnisse gemeint. Das Programm muss ausreichend exakte Werte bei Berechnungen wie z.B. einer Note liefern. Die Module sind so entworfen, dass wirklich auch nur die geforderten Informationen in einer ausreichenden Genauigkeit geliefert werden, um den Benutzer nicht mit einer irrelevanten Informationsflut zu überfordern. Interoperabilität: Die Interoperabilität ist die Fähigkeit mit vorhandenen Systemen zusammen zu arbeiten. Da die Applikation auf Browserbasis entwickelt wird, ist ein Maximum an Interoperabilität erzielbar. Der Benutzer benötigt lediglich Standardsoftware, die es auf jedem üblichen PC gibt. Es können sogar Handhelds verwendet werden. Es muss keine spezielle Software angeschafft werden. Sicherheit: Hauptaugenmerk wird bei dem Programm auf die Sicherheit gelegt, da es sich um vertrauliche persönliche Informationen handelt. Unberechtigte Zugriffe werden durch ein Benutzername-Passwort-System unterbunden. Die Datenübertragung geschieht über eine sichere SSL-Verbindung, die den heutigen Standards entspricht. Konformität: Die Konformität ist der Grad, in dem die Software Normen oder Vereinbarungen zur Funktionalität erfüllt. Durch regelmäßige interne Reviews wird sichergestellt, dass die Vereinbarte Funktionalität zu 100% erfüllt wird und dabei die Qualitätsstandards eingehalten werden.

Zuverlässigkeit

Nachfolgend wird erörtert, ob die Software ein bestimmtes Leistungsniveau unter bestimmten Bedingungen und über einen bestimmten Zeitraum halten kann. Reife: Unter Reife zeichnet sich die geringe Versagenshäufigkeit durch Fehlerzustände aus. Fehlerzustände werden durch ausführliche Use-Case-Planung durch Vorbedingungen auf ein Minimum gesetzt. Fehlertoleranz: Die Fähigkeit, ein spezifiziertes Leistungsniveau bei Software-Fehlern oder Nicht-Einhaltung ihrer spezifizierten Schnittstelle zu bewahren, wird durch eine sorgfältige Planung erreicht. Die Architektur wird so entworfen, dass die Entwickler auf Schnittstellen implementieren. Somit wird jede Komponente schon bei der Entwicklung auf mögliche Schnittstellenprobleme vorbereitet und fängt diese ab. Da ausreichende Integrationstests durchgeführt werden, wird von Anfang an sichergestellt, dass jede Art von möglichen Kommunikationsschwierigkeiten zwischen Modulen abgefangen wird und eine entsprechende Benachrichtigung an den Systembetreiber geschickt wird. Robustheit: Die Robustheit ist die Fähigkeit Fehlbedienungen stand zu halten. Die vom Benutzer möglichen Aktionen werden immer auf den aktuellen Kontext beschränkt. Dadurch wird der Benutzer in seiner Interaktionsmöglichkeit zwar eingeschränkt, dafür stehen ihm aber auch nur die im aktuellen Kontext sinnvollen Funktionen zur Verfügung. Freie Eingaben werden auf Plausibilität geprüft und unter Umständen wird eine Korrektur dieser Werte gefordert. Wiederherstellbarkeit: Dies ist die Fähigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen und die direkt betroffenen Daten wieder zu gewinnen. Die Daten werden auf einem Raid-System gehalten. Es werden durchgehend mit Rollbacks gearbeitet, so dass der vorherige Zustand wieder hergestellt werden kann, falls es zu einem Datenübertragungsproblem kommt. Die Datenbank wird jeden Tag in einem 7-Tage-Zyklus gesichert. Somit stehen auch ältere Daten ausreichend lange als Sicherungskopie bereit. Konformität: Durch regelmäßige Reviews wird der Grad, im dem die Software Normen oder Vereinbarungen zur Zuverlässigkeit erfültl, getestet und somit eine produktübergreifende Konformität sichergestellt.

Benutzbarkeit

In diesem Abschnitt wird der Aufwand, den ein Einsatz der Software von den Benutzern fordert diskutiert. Verständlichkeit: Da sich die Anwendung auf schon bekannte Systeme stützt, wird vom Benutzer kein Spezialwissen gefordert. Eine übersichtliche Menüführung mit den im aktuellen Kontext relevanten Funktionen ermöglichen eine intuitive Benutzung des Systems. Erlernbarkeit: Der Aufwand zum Erlernen der Anwendung ist durch die einfache Menüführung sehr gering. Eine geringe Strukturtiefe und exakte Namensgebung in den Menüs erschließen dem Anwender sofort die zu erwartenden Funktionen. Bedienbarkeit: Der Aufwand für den Benutzer, die Anwendung zu bedienen wird durch eine sorgfältige Use-Case-Planung minimiert. Die Zahl der zu tätigenden Aktionen beträgt im Durchschnitt 3-4. Der Anwender kann also mit minimalem Aufwand alle nötigen Funktionen nutzen. Attraktivität: ? Konformität: Auch hier werden durch regelmäßige Reviews die Normen und Vereinbarungen zur Benutzbarkeit eingehalten und optimiert.

Effizienz

Unter Effizienz wird das Verhältnis zwischen Leistungsniveau der Software und den eingesetzten Betriebsmitteln unter festgelegten Betriebsbedingungen diskutiert. Zeitverhalten: Das Zeitverhalten der Software wird prinzipiell fast ausschließlich durch die Anbindung des Benutzers an das Internet beeinflusst. Es werden Hauptsächlich kleine Datenmengen vom Server zum Benutzerrechner übertragen. Die Verarbeitung auf dem Server ist nicht extrem auslastend, da nur kleine Datenbankabfragen erfolgen. Durch ein gutes Datenbankdesign und durch die Wahl der Datenbank werden an dieser Stelle weitere Optimierungen vorgenommen. Somit bleiben Antwortzeiten des Servers innerhalb der regulären Toleranzen. Verbrauchsverhalten: Das Verbrauchsverhalten beschreibt die Anzahl und Dauer der benötigten Betriebsmittel bei der Erfüllung der Funktionen, Ressourcenverbrauch, wie CPU-Zeit, Festplattenzugriffe etc. Durch ein Raid-System kann das System auch unter hoher Zugriffslast hohe Performanz garantieren. Zudem sind die Server mit Multicore-CPUs ausgestattet und verfügen über ausreichenden Arbeitsspeicher. Die Internetanbindung stellt ein Maximum der Verfügbaren Bandbreite dar, da sie über das Universitätsnetz geschieht. Hier werden bei regelmäßigen Reviews auch Laufzeitverhalten eines ähnlichen Laborsystems getestet. Das System entspricht vom Leistungsniveau her dem Endkundensystem. Daher können realistische Laufzeitmessungen vorgenommen werden.

Änderbarkeit

Die Änderbarkeit beschreibt wie einfach es ist neue Funktionalitäten hinzu zu fügen bzw. Funktionalitäten zu entfernen. Korrektungen, Verbesserungen und Anpassungen müssen leicht zu erfüllen sein. Analysierbarkeit: Eine klar organisierte Programmstruktur ermöglicht eine schnelle Diagnose von Mängeln und Ursachen von Versagen. Ausgehend vom aktuellen Kontext können Fehler durch Diagnosen niedrigerer Abstraktionsebenen gefunden und beseitigt werden. Modifizierbarkeit: Der Aufwand zur Ausführung von Verbesserungen, zur Fehlerbeseitigung oder Anpassungen an Umgebungsänderungen sind durch die Architektur möglichst gering gehalten. Systemspezifische und dadurch von allen Modulen gemeinsam benutzte Komponenten sind in einer Bibliothek festgehalten. Optimierungen stehen somit allen Modulen unmittelbar zur Verfügung. Stabilität: Die Wahrscheinlichkeit des Auftretens von unerwarteter Wirkungen von Änderungen ist nahezu gleich Null. Jede Änderung wird sorgfältig geprüft. Da die Richttlinie eingehalten wird, dass jedes Modul in sich abgeschlossen sein muss, darf es keine Auswirkungen auf andere Module geben. Prüfbarkeit: Der Aufwand zur Prüfung der geänderten Software ist sehr gering, da sich Unit-Tests und Modultests über das gesamte Projekt ziehen. Automatisierte Tests können mit Hilfe eines Testorakels einfach und schnell durchgeführt werden.

Übertragbarkeit

Eine hohe Übertragbarkeit zeichnet sich durch leichte Installation der Umgebung auf neue bzw. andere Systemkonfigurationen aus. Anpassbarkeit: Die Fähigkeit der Software sich an verschiedene Umgebungen anzupassen hängt auf Clientseite prinzipiell nur davon ab, ob für das verwendeten System ein Internetbrowser existiert oder nicht. Um von allen Features profitieren zu können sollte zusätzlich JavaScript aktiviert sein. Auf Serverseite muss eine Plattform verwendet werden, für die die nötigen Komponenten verfügbar sind. Dies wäre zum einen ein Webserver wie Apache, ein Relationales Datenbanksystem nach dem SQL-Standard wie z.B. Postgre und ein Servlet-Container wie Tomcat. Die Hardwarevoraussetzungen sind prinzipiell zweitrangig, sollten aber natürlich hohe Performanz zur Verfügung stellen (siehe oben). Installierbarkeit: Der Aufwand, der nötig ist, um das System in einer festgelegten Umgebung zu installieren ist vergleichsweise etwas höher als das Installieren einer Software für z.B. Windows Systeme. Scriptgesteuert kann Apache als Webserver mit MySQL leicht installiert werden. Diese Kombination ist oft sogar schon in einer Linuxumgebung gleich mitgeliefert. Gleiches gilt auch für den Servlet-Container. Lediglich die Konfigurationsdateien müssen angepasst werden. Das Produkt wird jedoch so entwickelt, dass eine Standardinstallation ausreichen sollte. Koexistenz: Die Fähigkeit der Software neben einer anderen mit ähnlichen oder gleichen Funktionen zu arbeiten ist vorhanden. Die Serverumgebung bei Webapplikationen ist sowieso schon auf Anwendungen ausgelegt, die beiläufig ausführbar sein müssen. Die Basis ist also vorhanden. Bei der Konfiguration muss man lediglich darauf achten, dass Ressourcen wie Ports, IPs oder URLs nicht mehrfach belegt werden. Austauschbarkeit: ? Konformität: Da die geforderten Serversoftwarekomponenten auf allen gängigen Plattformen existieren, ist eine hohe Konformität an Übertragbarkeit erfüllt.


Qualitätssicherungsmaßnahmen

Verantwortlichkeiten

Grundsatz

Jeder ist für die Ergebnisqualität der ihm zugewiesenen Aufgaben selbst verantwortlich, d.h. er stellt die Review- bzw. Freigabe-Anträge und führt die Korrekturen durch. Arbeiten mehrere Personen am selben QS-Objekt, so ist eine hauptverantwortliche Person zu benennen. Ein Review bzw. eine Freigabekontrolle muss von jemand anderem als dem Autor durch­geführt werden. Bei Tests kann aus Ressourcengründen notfalls der Autor sein eigenes Entwicklungs­ergebnis testen. Die Testüberwachung und die Codefreigaben muss jedoch ein anderer durchführen. QS-Organisation Für die Qualitätssicherung auf der definierten Ebene sind alle Teamitglieder verantwortlich.

QS-Maßnahmen bei Dokumenten

Alle erfolgten elementaren QS-Maßnahmen sind vom Autor in den Dokumentkontrollen zu vermerken, damit sie in das zentrale Dokumentenregister übernommen werden können. Reviews Es wird zwischen internen und externen informellen Reviews unterschieden. Reviews müssen mit Datum und Namen des Reviewers in den Dokumentkontrollen vermerkt werden.

Interne, informelle Reviews

Bei internen, informellen Reviews(intR) sind ausschließlich Entwicklungsmitglieder beteiligt. An jedem Review präsidieren die für das Dokument verantwortlichen Autoren. Die anderen Mitglieder wirken mit. Die Teilnehmer führen sorgfältig Buch über gefundene Fehler.


Versionsführung der Dokumente

Folgende Zählung sollte eingehalten werden:

V0.1

bis zum ersten Review

V0.2

nach Korrekturen, bis zum 2. Review

etc....


V1.0

1. Freigabe

V1.1

bis zum ersten Review nach der 1. Freigabe

V1.2

nach Korrekturen, bis zum 2. Review nach der 1. Freigabe

etc...


V2.0

2. Freigabe

etc...


Die Version ist bei den Einträgen in den Dokumentkontrollen fortzuzählen.


QS-Maßnahmen bei Quellcode und Programmen

Codefreigabe und Auslieferungen

Nach jedem Test ist der Code für den nächsten Test freizugeben. Nach einer Auslieferung darf der Code nur noch im Rahmen von Auftraggeber-Reklamationen geändert werden. Dabei ist zu unterscheiden zwischen Fehler­meldungen und Änderungs­wünschen (Change Requests). Bei wesentlichen Änderungs­wünschen sind die kommerziell für das Projekt Verantwortlichen einzuschalten. Testen Grundsätzlich wird keine Software ausgeliefert, die nicht vorher intern getestet wurde.

Tests und Testdokumente

Für die Studie sind Containertests (CT) vorgesehen. Die Test­ergebnisse werden in Testberichten (Studie) dokumentiert.

Vorgaben für die Testpläne

In den Testplänen sind für jeden Test zu definieren: Testverdikt für einzelne Tests (passed, failed, inconclusive), Problemklassen: F (Fehler), Ä (Änderungswunsch = Change Request), ‘??’ (Klärungsbedarf), - vgl. Tabelle 1: Problem. Vorgaben zu Problemklassifizierung und Problemstatus Jedes beim Testen auftretende Problem muss erfasst, klassifiziert und verfolgt werden. Dazu sind zwei Indikatoren zu verwenden: Problemtyp Problemstatus.

Die folgenden Tabellen geben diese Indikatoren vor.

Tabelle 1: Problemtypen Abkürzung Problemtyp Definition F Fehler (Error) Abweichung von den Vorgaben (Spezifikation in den Konzept­papieren bzw. in den Use Case Definitionen bzw. im Grobdesign) Ä Änderungswunsch (CR, Change Request) Neue Anforderung für eine Änderung / Ergänzung / Verbesse­rung, die in den Vorgaben bisher nicht vorgesehen bzw. nicht vereinbart war ?? Klärungsbedarf (Clarification Issue) Problem, das nicht als Fehler oder Änderungswunsch einstufbar ist und - eventuell auf einem Missverständnis beruht oder - dessen Ursache außerhalb des Testobjekts zu suchen ist

Tabelle 2: Problemstatus Status Definition Bemerkung open Problem erkannt und registriert, aber noch nicht gelöst

closed Problem gelöst und Regressionstest durchgeführt

rejected Problem wird nicht gelöst (Dazu ist unbedingt der Grund anzugeben!) Es kann sich um einen nicht vereinbarten/ nicht akzeptierten Änderungswunsch handeln (kein Bedienfehler).

Bei jedem Test sind Problemmelderegister zu führen, in denen die Problemmeldungen (z.B. nach Eingangsdatum) geordnet aufgenommen und gepflegt werden. Zu jedem Problem soll es folgende Einträge geben: Eingangsdatum Problem-ID Testfall-ID Problem-Kurzbeschreibung Problemklasse (F / Ä / ??) Bearbeitungsvermerke (mit Datum - zu pflegen) Aktueller Status (open / closed / rejected - zu pflegen) Abschlussvermerk (mit Datum) Aufwand (optional). Vorgaben für die Testberichte In den Testberichten ist folgendes zu protokollieren: Problemstatistik nach zwei Gesichtspunkten (aus Bericht im Problemmelderegister): (open, closed, rejected) nach Korrektur. Anzahl der gefundenen Probleme, geordnet nach Problemklassen (F, Ä, ??) und deren Status (open, closed, rejected) nach Korrektur. Beurteilung der Testgüte durch Vergleich der Testergebnisse mit den Fehlererwartungszahlen (FEZ, aus dem Testplan) für Fehler (F). Glossar

Code-Konventionen Richtlinien zur Programmierung. Genauer: Richtlinien zur Wahl von Konstantenbezeichnern, Variablennamen etc. im Code. Da der Code die Grundlage für zukünftige Änderungen darstellt, sollten gemeinsame Richtlinien im gesamten Projekt existieren, damit sich Entwickler (und ganz besonders Entwickler, die schon an anderen Modulen mitgearbeitet haben) schneller zurechtfinden können.

White-Box-Test White-Box-Tests beruhen auf Einblicken in den Code bzw. auf Kenntnissen der inneren Funktionsweise. Hierbei können gezielte Tests zur Funktionsweise ermittelt werden.

Black-Box-Test Black-Box-Tests beruhen auf Eingaben und Ausgaben in Komponenten, wobei die genaue Arbeitsweise innerhalb der Komponente unbekannt ist. Mit Black-Box-Tests kann eine Komponente gegen die Spezifikation geprüft werden.

Implementierung auf Schnittstellen Es werden zunächst nur Schnittstellen bestimmt. Die Gesamtarchitektur wird auf diesen Schnittstellen geplant. Die Entwickler können anschließend die einzelnen Komponenten nach den geforderten Code-Konventionen implementieren.

Regressionstest Ein Test, der nach Änderungen wieder durchgeführt wird, um sicherzustellen, dass der Code immer noch einwandfrei der Spezifikation entspricht. Regressionstests werden automatisiert durchgeführt, da sie bei jeder Iteration gleich sind und außerdem durch die Automatisierung immer die gleichen Abläufe sichergestellt werden.

Testorakel Ein Testorakel stellt eine Menge von Testfällen, die durchgespielt werden müssen. Das zu testende Objekt bekommt dabei als Eingabe nacheinander alle Elemente des Orakels und muss die erwarteten Ergebnisse liefern. Orakel eignen sich hervorragend für immer wiederkehrende Tests.

Handheld Unter Handhelds versteht man elektronische Systeme, die tragbar und besonders klein sind und dabei die übliche Computerfunktionalitäten wie z.B. Terminplaner, Internetbrowser, etc. bieten. Bekannte Vertreter sind z.B. PDAs oder Smartphones.

SSL Secure Sockets Layer ist ein Verschlüsselungsprotokoll für Datenübertragungen im Internet, welches auf asymmetische Verschlüsselungssysteme basiert.

Multicore-CPU Eine Multicore-CPU beeinhaltet mehrere Kerne in einem CPU-Gehäuse. Jeder Core entspricht quasi einer CPU im Klassischen Sinne. Dafür ausgelegte Betriebssysteme können Tasks und Threads nun auf die vorhandenen Cores verteilen und ermöglichen dadurch eine Vervielfachung der Arbeitsleistung, die nahezu der Zahl der Cores entspricht. BRAINSTORMING

Maßnahmen zur Qualitätssicherung Die Applikation wird Modular aufgebaut. Die Komponenten der Module werden auf Schnittstellen implementiert, so dass mehrere Entwickler an einem Modul arbeiten können. Hierzu werden Code-Konventionen über das gesamte Projekt benutzt. Für die Versionsverwaltung wird Subversion benutzt.

White-Box-Tests werden über das gesamte Projekt durchgeführt. Als Abbruchkriterium wird hierbei eine Zweigüberdeckung von 100% angestrebt. Dies verhindert unter anderem toten Code und einen lückenfreien Test des Codes.

Black-Box-Tests werden bei allen Komponenten und Modulen eingesetzt, um das jeweilige Modul gegen die Spezifikation zu testen.

Es werden zuerst die Einzelkomponenten entwickelt. Danach finden Komponententests statt. Wenn diese erfolgreich absolviert sind, werden Module aus den Komponenten zusammengebaut. Anschließend finden Integrationstest statt, die gewährleisten, dass die einzelnen Module korrekt funktionieren. Wenn dies der Fall ist werden die Module zum Gesamtsystem zusammengesetzt und anschließend ein Systemintegrationstest durchgeführt. Wenn der Systemintegrationstest bestanden wird, erfolgt der Abnahmetest durch den Auftraggeber. Die Komponententests können noch durch den Entwickler durchgeführt werden. Hier sollten aber auch schon gegenseitige unabhängige Kontrollen durch andere Entwickler stattfinden. Das Testen der Module sollte möglichst nicht durch die Entwickler stattfinden, sondern durch unabhängiges Personal oder sogar durch externe Personen. Gleiches gilt für den Systemintegrationstest. Der Grund ist der, dass die Entwickler weniger bis keine Fehlbedienungen der Applikation tätigen werden oder Fehlverhalten nicht als solche interpretieren könnten. Regressionstests sind natürlich nach jeder Änderung der Komponenten durchzuführen. Hierzu werden die Tests automatisiert mit Hilfe von Testorakeln durchgeführt. Als Vorgehensmodell wählen wir den „Rational Unified Process“. Alle möglichen Benutzeraktionen sind hier in Form von Use-Cases dokumentiert. Interaktionsdiagramme beschreiben auch komplexere Abläufe detailiert, so dass alle nötigen Schritte genau geprüft werden können. Hierbei werden die Interaktionsschritte schon auf das nötigste minimiert, was eine geringere Fehlbedienung bedeutet. Beim Test ist eine Abdeckung von 100% der Use-Cases festgelegt.

Reviews



Konstruktive Maßnahmen Organisatorische Maßnahmen Planung Als Kommunikationsplattform verwenden wir ein Wiki. Alle Beteiligten informieren sich regelmäßig über die Arbeiten der anderen Mitarbeiter. Dadurch werden alle Beteiligten in die Arbeit der anderen Mitarbeiter involviert und es entstehen keine Wissenslücken. Der Wissensstand über das Projekt ist somit bei allen Beteiligten auf dem gleichen Niveau. Es finden regelmäßig interne Reviews statt. Teilnehmer sind ausschließlich Mitglieder des Entwicklerteams. Bei jedem Review präsidieren die für das Dokument verantwortlichen Autoren. Die anderen Mitglieder wirken mit. Richtlinien zur Programmierung zur Dokumentenverwaltung

Technische Maßnahmen Methoden

Werkzeuge Es werden im Rahmen des Rational Unified Process alle Use-Cases in UML Modelliert. Die Versionsverwaltung findet mit Hilfe von Subversion statt. Unit-Tests werden mit Hilfe von JUnit automatisiert durchgeführt.

Bibliotheken Zusätzlich zu den Standardbibliotheken aus dem Java SDK werden modulübergreifende Komponenten in einer eigenen Bibliothek erfasst. Dies stellt einfache Wartbarkeit sicher und reduziert die Fehleranfälligkeit, die durch Redundanzen entstehen können.

Analytische Maßnahmen Analysierende Verfahren Statische Analyse, Formale Verifikation Zur statischen Analyse werden Produktbezogen: Inspektion, Review, Walkthrough Prozessbezogen: Audit

Testende Verfahren Dynamischer Test, Symbolischer Test, Simulation, Schreibtischtest Dynamische Tests werden mit Hilfe von JUnit automatisiert durchgeführt. Somit können Regressionstests schnell und effizient abgeschlossen werden und Änderungen am System optimal sichtbar.

Also on Fandom

Random wikia