Fragen und Antworten
Bitte klicken Sie auf die Frage um die Antwort zu sehen.
Funktionen
Kann der Model Tester Preise testen und wenn ja dann wie?
Der Model Tester testet Preise, die auf Variantenkonditionen basieren. Für ein pro Testfall einstellbares Kalkulationsschema werden für alle Variantenkonditionen einer Konfiguration sämtliche relevanten Konditionssätze aller Zugriffe aller Zugriffsfolgen ermittelt und getestet.
Kann der Model Tester selbstständig alle Variationen meines Konfigurationsmodells testen?
Nein, aus zwei Gründen:
-
Für ein Konfigurationsmodell mit 100 einwertigen Merkmalen und 10 möglichen Werten pro Merkmal müssten 10 hoch 100 Varianten geprüft werden. Das sind
10 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
Stück. Bei einer Laufzeit von einer Sekunde pro Testfall müssten Sie auf Ihr Ergebnis lange warten. Nämlich
325 114 440 282 979 608 822 305 451 518 934 665 002 080 732 417 811 069 496 462 754 889 721 181 856 013 316 687 473 990 844
Jahre. Und das ist ungefähr
23 730 981 042 553 256 118 416 456 315 250 705 474 604 433 023 197 888 284 413 339 772 972 349 040 584 913 626
mal so lange wie es unser Universum gibt. - Selbst wenn nicht alle Möglichkeiten geprüft werden - z.B. weil nur Kombinationen bestimmter Merkmale getestet werden sollen - bleibt das Problem, dass für jede einzelne Kombination spezifiziert werden muss, wie das gewünschte Ergebnis aussehen soll. D.h. für jede Kombination von Merkmalswerteingaben müssen Konflikte, vom System gesetzte Werte, Stücklistenauflösung und ggf. Preise vorgegeben werden. Dies halten wir für einen relativ großen Aufwand, der effektiv nur im Einzelfall betrieben werden dürfte. Bitte kontaktieren Sie uns, falls Sie ein solcher Einzelfall sind.
Systeme und Infrastruktur
Benötigt der Model Tester ein eigenes System?
Nein. Der Model Tester läuft im Netweaver ABAP und kann somit auf ein existierendes ERP-System aufgespielt werden. Natürlich kann er aber auch in einem eigenen Netweaver ABAP System laufen.
Ist der Sybit Model Tester gefährlich?
Natürlich nicht.
- Kein Integrationsrisiko: Der Sybit Model Tester ist ein durch SAP zertifiziertes ABAP-Add On.
- Kein Datenrisiko: Der Sybit Model Tester greift ausschließlich lesend auf SAP- und Kundendaten zu.
- Kein Migrationsrisiko: Der Sybit Model Tester ist modifikationsfrei.
- Kein Sicherheitsrisiko: Alle Entwicklungsobjekte liegen in einem eigenen, bei der SAP reservierten Namensraum. Namenskollisionen mit bereits in Ihrem SAP-System vorhandenen Objekten sind daher ausgeschlossen.
Wie viel Aufwand bedeutet die Installation für unsere Administratoren?
Der Installationsaufwand wächst mit der Anzahl der zu testenden Systeme. Für die Installation mit 2 - 3 angebundenen Systemen muss mit ein bis zwei Stunden gerechnet werden.
Allgemeine Fragen zum Testen
Wozu Variantenkonfiguration?
In einer Welt ohne Variantenkonfiguration ist Entwicklung, Produktion und Vertrieb von variantenreichen Produkte nicht nur teuer, sondern gleichermaßen fehleranfällig und langsam. Unzählige Materialstämme müssen redundant gepflegt werden, kleine Produktänderungen verursachen großen Aufwand. Der Vertrieb kann nicht entscheiden, ob eine nicht-vorgesehene Variante verkauft werden darf oder nicht.
Die Variantenkonfiguration löst diese Probleme elegant durch zentrale Modellierung komplexer Zusammenhänge. Die Mehrfachpflege von Materialstämmen entfällt, Änderungen am Produkt werden zentral gepflegt und der Vertrieb weiß verbindlich, welche Varianten verkauft werden dürfen.
Durch die Variantenkonfiguration ist es möglich, die Komplexität einer Produktpalette zu erhöhen und gleichzeitig Kosten zu sparen. Konfigurationsmodelle sind hier in vielen Kernprozessen eingebunden.
Wozu Testen?
Trotz der Komplexität und Wichtigkeit von Konfigurationsmodellen spielt ihre Qualitätskontrolle in vielen Unternehmen eine untergeordnete Rolle. Die folgenden Szenarien sind davon eine direkte Folge:
- Das Konfigurationsmodell ermöglicht fälschlicherweise eine nicht vorgesehene Variante. Dann fällt zusätzlicher Entwicklungsaufwand an, damit die geforderte Variante geliefert werden kann.
- Das Konfigurationsmodell verhindert eine bestimmte Variante, die für den Kunden nützlicher gewesen wäre und gleichzeitig mehr Umsatz generiert hätte.
- Das Konfigurationsmodell erzeugt eine fehlerhafte Stückliste. Dann werden falsche Teile beschafft, was erst in der Montage entdeckt wird. Eine termingerechte Auslieferung ist somit unmöglich.
Die Liste dieser Szenarien kann beliebig verlängert werden. Allen gemeinsam ist ein potenziell großer finanzieller Schaden. Dieses Risiko kann durch systematische Tests zwar nicht ausgeschlossen, aber deutlich minimiert werden.
Was kann Testen leisten und was nicht?
Konfigurationsmodelle sind komplex. Im Maschinen- und Anlagenbau können Konfigurationsmodelle leicht mehrere hundert Freiheitsgrade (d.h. Merkmale) enthalten. Alle möglichen Konfigurationen zu testen ist in einem solchen Szenario keinesfalls möglich. Dies ist jedoch in der Regel auch nicht erforderlich, da die Risiken folgendermaßen reduziert werden können.
- Produktwissen: Das Produktmanagement kennt die Varianten eines konfigurierbaren Produkts, die häufig bestellt werden (sog. Bestseller). Genau diese Varianten müssen vorwiegend getestet werden.
- Modellierungswissen: Der Programmierer des Konfigurationsmodells kennt die kritischen und somit fehleranfälligen Stellen eines Modells. Genau diese Stellen müssen vorwiegend getestet werden.
Werden Produktwissen und Modellierungswissen kombiniert, so lässt sich die Testanzahl signifikant reduzieren. Testen soll also Fehler aufdecken. Es kann nicht die Abwesenheit von Fehlern beweisen. In der Praxis wird die Anzahl der Tests oft zu weit reduziert. Hierdurch entstehen unkalkulierbare Risiken.
Wozu automatisiertes Testen?
Die Hauptgründe für unzureichendes Testen sind darauf zurückzuführen, dass Tests manuell durchgeführt werden:
- Hohe Kosten: Das Testen der Konfigurationsmodelle wird von Produkt- und Modellierungsexperten geleistet oder zumindest vorgegeben. Die für eine gute Modellqualität nötige, große Anzahl an Tests lässt die Testkosten explodieren. Lesen Sie hierzu die Seite zur Kosten-Nutzen-Analyse.
- Unzureichende Qualität: Da manuelles Testen eine ermüdende Tätigkeit ist, schleichen sich Fehler ein. Die Testdurchführung unterliegt keiner Qualitätskontrolle.
- Großer Zeitbedarf: Bei manuellen Tests muss zu jedem Testzeitpunkt jeder Testfall von Hand ins System eingegeben werden. Die Ergebnisbewertung erfolgt per Sichtkontrolle. Dieser Prozess ist nicht nur anstrengend und erfordert hohe Konzentration sondern ist in erster Linie langwierig. Lesen Sie hierzu unsere Seite zu den Markteinführungszeiten. Hier ist Time-to-Market oftmals ein kritischer Faktor.
Automatisiertes Testen beseitigt diese Aspekte gleichzeitig:
- Niedrige Kosten: Beim automatisierten Testen werden Testfälle einmal spezifiziert und dann im System gespeichert. Sie können zu jeder Zeit per Knopfdruck ausgeführt werden. Expertenwissen ist dann nur noch zur Behebung von Fehlern nötig.
- Hohe Qualität: Automatisierten Testen kennt keine Flüchtigkeitsfehler. Testläufe werden im System dokumentiert und können jederzeit nachvollzogen werden.
- Prozessbeschleunigung: Beim automatisierten Testen können sämtliche relevanten Tests über Nacht per Knopfdruck durchgeführt werden. Ein übersichtliches und jederzeit nachvollziehbares Protokoll dokumentiert die Ergebnisse jedes Testlaufs und bildet die Basis zur Behebung etwaiger Fehler.
Welche Testhilfsmittel bietet der SAP Standard?
- Manuelles Testen: In der Transaktion CU50 (Simulation der Variantenkonfiguration) oder in den Transaktionen zur Belegpflege (VA21,...) lassen sich Konfigurationsmodelle händisch testen. Händisch bedeutet, dass die Merkmalswerte bei jedem Testdurchlauf von Hand eingegeben werden müssen. Nach Ausführung des Beziehungswissens muss im Anschluss das Konfigurationsergebnis - d.h. Merkmalswerte, Stücklistenauflösung, Preise, etc. - per Sichtkontrolle auf Korrektheit und Vollständigkeit geprüft werden. Bei Konfigurationsmodellen, deren Beziehungswissen auf lesenden Objektmerkmale beruht, kann die Transaktion CU50 nicht zum Testen verwendet werden.
- Automatisches Testen: Das im SAP-Standard enthaltene Testwerkzeug Catt/eCatt dient zum Testen von Anwendungen im SAP per Scripting oder per Screen-Recorder. Theoretisch bestünde die Möglichkeit, Testfälle in der CU50 mit eCatt aufzuzeichnen und dann vollautomatisch auszuführen. Da diese Testfälle jedoch rein auf der Oberfläche des Konfigurators basieren, können sie nicht an Änderungen des Konfigurationsmodells angepasst werden. Kommt ein neues Merkmal hinzu, müssen sämtliche Testfälle neu aufgezeichnet werden.
Wer sollte Testfälle erstellen?
Grundsätzlich jeder der ein Interesse an Konfigurationsergebnissen hat. Dies beinhaltet in der Regel:
- Modellierer: Modellierer testen die aus Modellierungssicht kritischen Stellen des Konfigurationsmodells.
- Vertriebsmitarbeiter: Vertriebsmitarbeiter testen ob vom System die richtigen Merkmale gesetzt werden.
- Produktmanager: Produktmanager testen ob die Vielfalt der möglichen und unmöglichen Varianten sowie die Preise.
- F&E Abteilung: Die Forschungs- und Entwicklungsabteilung testet ob die baubaren / nicht-baubaren Varianten im Konfigurationsmodell zulässig / unzulässig sind.
Kontakt
Armin Kehl
Tel. +49 (0) 7732 9508-266
Fax +49 (0) 7732 9508-111
sales@sybit.de
Kontaktformular



