Testkonzept erstellen - Verständnisschwierigkeiten

[Zrebna]

Hi!

Im Rahmen meiner BA-Abschlussarbeit soll ich für ein Unternehmen, bei dem ich die externe BA schreibe, ein Testkonzept aufstellen. Das Unternehmen hat bis dato noch relativ wenig in dieser Richtung (also Software-Testing) und will diesen Bereich nun aufbauen/ausbauen. Ich stehe dazu mit regem Austausch mit meinem betreuenden Professor, möchte aber bzgl. paar Unklarheiten auch vor dem nächsten Treffen mit meinem Professor, hier Fragen stellen – einfach, weil ich hier von einigen Forumsmitgliedern den Input sehr schätze und eine andere Perspektive oft einfach auch nochmal extra hilfreich ist.

Es geht also darum, ein Testkonzept zu erstellen.
Vorab sollen aber Anforderungen an das Testkonzept gestellt werden. So wie ich es verstehe sollen die Anforderungen an mein Testkonzept sollen festlegen was mein Testkonzept ermöglichen/leisten/können soll.

Anforderungen könnten hierbei sowas sein, wie:

• Umfassende Unit Testabdeckung
• Frühzeitige Fehlererkennung, -vermeidung und -vorbeugung
• Automatisierte Tests für jeden Bugfix

Aber auch sowas wie:

• Effizienzorientiertes Prinzip bei Testverfahren
• Integration von Testprozessen in den Entwicklungszyklus

Danach sollen die Bestandteile des Testkonzepts festgelegt werden. Dabei verstehe ich es folgendermaßen:
Die Bestandteile meines Testkonzepts definieren, wie mein Testkonzept die Anforderungen verwirklicht, d.h. die einzelnen Bestandteile meines Testkonzepts stellen demnach Lösungsmöglichkeiten für meine Anforderungen dar, wobei ein Bestandteil eine Lösungsmöglichkeit für eine oder mehrere Anforderungen sein kann.

Bestandteile des Testkonzepts (also Lösungsmöglichkeiten für die Anforderungen) könnten nun sein:

• Statische Codeanalyse (bisher nicht genutzt)
• Vorgaben für Testabdeckung auf Modulebene und Umsetzung von JUnit-Tests
• Automatisierte Testintegration in CI-Prozesse
• Priorisierung von Testfällen
• Wahl von effizienten Testverfahren

Aber möglicherweise auch Aspekte, wie:

• Testplan und Dokumentationsmanagement
• Standardisierung
• Strukturierte Organisation innerhalb des Test-Projektes (dort liegen ein paar wenige Integrationstests)

An dieser Stelle folgender Input von meinem Professor im Rahmen unserer Treffen:

• Das Konzept ist ein theoretisches Konstrukt.
• Ein Prototyp kann unterschiedliche Aspekte adressieren:

-> Er demonstriert gewisse Aspekte des Konzepts praktisch. (Demonstrations-Prototyp)
-> Er evaluiert bestimmte Aspekte. Das ist dann ein Proof of Concept.

Ich kann beide Aspekte eines Prototyps in meiner Arbeit verwenden, sollte das aber trennen.
Letztlich soll mein Testkonzept mithilfe des Prototyps demonstriert oder evaluiert.

Und gerade bei dieser Semantik, was ein Prototyp im Kontext meiner Arbeit sein soll, tue ich mich schwer.
Die Trennung des „Demonstrations-Prototypen“ und des „konzeptuellen Prototypen“ würde ich auf Kapitelebene machen.

Bzgl. dem "Demonstrations-Prototypen", habe ich quasi etwas programmiert sowie zeige auch was mit SonarQube, sodass ich letztlich bestimmte Teile meines Testkonzepts zeigen kann.

Wie geht man aber bzgl. dem „konzeptuellem“ Prototypen vor. Ich kann versuchen, den Nutzen bestimmter Teile meines Testkonzepts durch Fallbeispiele in der Literatur und generell durch „Belege“ in der Literatur zeigen? Wie kann ich Teile meines Testkonzepts evaluieren, oder dafür etwas zu implementieren?

Ansonsten macht mir dieser Satz noch Probleme:
„Letztlich soll mein Testkonzept mithilfe des Prototyps demonstriert oder evaluiert.“

Welcher Prototyp? Ich habe bisher Prototyp immer so verstanden, dass man für ein Endprodukt eine vorläufige Versuchsversion hat – irgendwie was physisches – kann nicht so recht in Worte fassen, wie ich das meine. Aber die Definition eines Prototyps in dieser Arbeit bereitet mir Schwierigkeiten und ich weiß einfach nicht, wie ein Prototyp (demonstrativ und nicht-demonstrativ, also evaluierend) bei meinem Testkonzept bzw. seinen Bestandteilen aussehen soll bzw. was da ein Prototyp sein soll, sein könnte.

Irgendwie kapiere ich das nicht sehr gut und hoffe hier auf Unterstützung und Hilfe, sodass ich in das nächste Treffen mit meinem Professor mit mehr Verständnis "reingehen" kann.


Lg
Zrebna

 

[Robertop]

Wie geht man aber bzgl. dem „konzeptuellem“ Prototypen vor. Ich kann versuchen, den Nutzen bestimmter Teile meines Testkonzepts durch Fallbeispiele in der Literatur und generell durch „Belege“ in der Literatur zeigen? Wie kann ich Teile meines Testkonzepts evaluieren, oder dafür etwas zu implementieren?

Meinst du hier: "..., ohne was zu implementieren"?

Ganz ohne selbstgemachte Codebeispiele bleibt ja eigentlich nur das Suchen in der Literatur. Da würde ich mir dann vielleicht aber Beispiele von Fällen suchen, wo durch kleine Programmierfehler große Schwierigkeiten aufgetreten sind und dann verdeutlichen, wie ein bestimmter automatischer Test diesen Fehler vor der Auslieferung schon gefunden hätte, oder so. Da könnte man dann vielleicht auch die Unterschiede herausarbeiten zwischen den Szenarien, wenn die Stelle vorher schon mit Tests abgedeckt war, wie der Entwickler durch das Testschreiben den Fehler selber gefunden hätte, oder was passiert wäre, wenn die Stelle zwar keine Tests hatte, aber beim Commit dann aufgefallen wäre, dass die Testabdeckung runter gegangen ist. Dann noch eine Gegenüberstellung der Kosten, die das Korrigieren des Fehlers im Produktionsbetrieb verursacht hat, im Vergleich zu den Kosten, die das Schreiben eines automatisierten Tests verursacht hätte.

Wie genau so ein Prototyp zur Evaluierung aussehen soll, kann ich mir da leider auch schwer vorstellen. Vielleicht eine kleine App mit einem schnell aufgesetzten CI/CD, mit dem man den üblichen Ablauf durchspielen kann?

Was mir aber ehrlich gesagt als aller erstes an deinem Projekt aufgefallen ist, sind die Anforderungen:

Anforderungen könnten hierbei sowas sein, wie:

• Umfassende Unit Testabdeckung
• Frühzeitige Fehlererkennung, -vermeidung und -vorbeugung
• Automatisierte Tests für jeden Bugfix

Aber auch sowas wie:

• Effizienzorientiertes Prinzip bei Testverfahren
• Integration von Testprozessen in den Entwicklungszyklus

Also wenn das für den Professor so in Ordnung ist von der Formulierung, dann kann man das natürlich so lassen und den Spielraum zu seinem Vorteil nutzen, aber ich finde, die sind zu ungenau. Zum Beispiel:

Was heißt zum Beispiel "Umfassende Unit Testabdeckung"? Bedeutet das, dass mindestens 90% Codecoverage erreicht wird, oder dass jede Klasse einen eigene Unittestklasse braucht? Würde eine einzelne Testmethode, die100% Coverage erreicht, die Anforderung erfüllen?

Auch das mit der "frühzeitigen Erkennung"? Wenn er eine Sekunde nach dem Start des Produktivsystems auffällt, ist das nicht theoretisch irgendwie auch frühzeitig? Wäre beim Commit der Änderungen frühzeitig? Oder beim Deploy ins Testsystem?

 

[Zrebna]

Sry, Doppelpost....................................

 

[Zrebna]

Meinst du hier: "..., ohne was zu implementieren"?

Ja, meinte "ohne" - sry, verschrieben xD

Ganz ohne selbstgemachte Codebeispiele bleibt ja eigentlich nur das Suchen in der Literatur. Da würde ich mir dann vielleicht aber Beispiele von Fällen suchen, wo durch kleine Programmierfehler große Schwierigkeiten aufgetreten sind und dann verdeutlichen, wie ein bestimmter automatischer Test diesen Fehler vor der Auslieferung schon gefunden hätte, oder so. Da könnte man dann vielleicht auch die Unterschiede herausarbeiten zwischen den Szenarien, wenn die Stelle vorher schon mit Tests abgedeckt war, wie der Entwickler durch das Testschreiben den Fehler selber gefunden hätte, oder was passiert wäre, wenn die Stelle zwar keine Tests hatte, aber beim Commit dann aufgefallen wäre, dass die Testabdeckung runter gegangen ist. Dann noch eine Gegenüberstellung der Kosten, die das Korrigieren des Fehlers im Produktionsbetrieb verursacht hat, im Vergleich zu den Kosten, die das Schreiben eines automatisierten Tests verursacht hätte.

Wie genau so ein Prototyp zur Evaluierung aussehen soll, kann ich mir da leider auch schwer vorstellen. Vielleicht eine kleine App mit einem schnell aufgesetzten CI/CD, mit dem man den üblichen Ablauf durchspielen kann?

Was mir aber ehrlich gesagt als aller erstes an deinem Projekt aufgefallen ist, sind die Anforderungen:

Also wenn das für den Professor so in Ordnung ist von der Formulierung, dann kann man das natürlich so lassen und den Spielraum zu seinem Vorteil nutzen, aber ich finde, die sind zu ungenau. Zum Beispiel:

Was heißt zum Beispiel "Umfassende Unit Testabdeckung"? Bedeutet das, dass mindestens 90% Codecoverage erreicht wird, oder dass jede Klasse einen eigene Unittestklasse braucht? Würde eine einzelne Testmethode, die100% Coverage erreicht, die Anforderung erfüllen?

Im Fließtext ist es dann genau definiert:
1. Jede Klasse braucht einen Unit-Test.
-> Wie nennt man hier die Metrik - siehe diesen Thread von mir, weil ich da eh Schwierigkeiten habe zu verstehen, welche Metrik ich hier brauche:

https://www.java-forum.org/thema/fragen-zu-testabdeckungs-metriken.203642/

2. Bzgl. Coverage-Metriken soll gelten:
80% Zweigabdeckung und 100% Anweisungsbadeckung.

Auch das mit der "frühzeitigen Erkennung"? Wenn er eine Sekunde nach dem Start des Produktivsystems auffällt, ist das nicht theoretisch irgendwie auch frühzeitig? Wäre beim Commit der Änderungen frühzeitig? Oder beim Deploy ins Testsystem?

Da gehts eher um Fehlervorbeugung-vermeidung und das zielt auf statische Codeanalyse ab.
Also konkret: "Frühzeitig" heißt hier, noch vor dem Kompilieren und Ausführen des Programms.
Steht dann auch im Fließtext.


Danke schon einmal für den Input.

 

[KonradN]

1. Jede Klasse braucht einen Unit-Test.

Ich finde diese Formulierung schlecht. Was wird denn damit gemeint? Doch in erster Linie, dass das Interface nach außen getestet wurde. Und das würde dann am ehesten der Metrik "Methods" entsprechen. Da kannst Du erkennen, ob die Klasse wirklich Tests hat.

Aber streng genommen ist es ja, dass es zu jeder Klasse einen Unit Test gibt. Das wäre also schon erfüllt, wenn es zu jeder Klasse einen Test gibt, der lediglich versucht die Klasse zu laden. Also dahinter verbirgt sich nicht einmal, dass es zur Klasse Abc noch eine AbcTests geben muss oder so.

Daher kann ich hier deine Probleme nachvollziehen. Unter dem Strich hilft Dir da nur, die Anforderungen zu hinterfragen. Wer hat die aufgestellt? Der soll es erläutern, was da im Detail gemeint ist.

 

[Zrebna]

Die Anforderungen habe ich schon selber erstellt und die sind einigermaßen ok für den Professor.

Bei dieser Anforderung ist halt dein Punkt einfach untergegangen oder implizit angenommen worden.

Wenn ich dich da richtig verstehe, dann wäre die Anforderung besser, wenn man schreiben würde:
"Zu jeder Methode ist eine Test-Methode erforderlich".
Oder ich schreibe im Fließtext ausdrücklich dazu, dass bei jeder Unit-Test-Klasse jede Methode der zu testenden Klasse zu testen ist.

 

[KonradN]

Hast Du mal geschaut, was für eine Beschreibung der jeweiligen Metriken bei dem verwendeten Tool du findest? Wenn Du dich danach richtest, dann vermeidest Du Fehler. Wenn Du also eine eigene Beschreibung frei heraus erstellst und dann die "Methods" Metrik eines Tools verwendest, dann besteht die Möglichkeit, dass da jemand drauf schaut und dann weicht deine Beschreibung inhaltlich von der des Tools ab.

Natürlich nicht 1:1 verwenden aber halt den Inhalt anschauen um da sicher zu gehen, dass Du etwas passenden hast.

Aber es wäre dann eine Aussage ähnlich wie denen, die Du schon hattest meine ich. Du forderst dann halt eine Coverage von Methods von mindestens xx%. Das ist dann ggf. 100% oder Du definierst Ausnahmen wie z.B. Entities mit Gettern und Settern.

Evtl. einfach ein Beispiel:
Wenn du forderst, dass jede Methode einer Klasse eigenständig getestet sein muss (Also Abc.method erfordert AbcTests.testMethod), dann kann es sein, dass Methods 100% des Tools nicht ganz passend sind. Denn die Methode Abc.method wird vermutlich schon als getestet gelten, sobald sie im Rahmen irgend eines Tests aufgerufen wurde.

Hier führt also kein Weg drumherum: Du musst die Metriken, die Dein Tool erstellt, im Detail verstehen um dann passende Anforderungen zu formulieren. Und ich fürchte, dass ich da nicht tief genug drin stecke um da wirklich hilfreich zu sein.