![\"\"](\"https:\/\/mindsquare.de\/wp-content\/blogs.dir\/37\/files\/Buchgrafik-gross_-29-200x350.png\")
<\/div>E-Book: SAP ABAP- und Fiori-Entwicklungsrichtlinien<\/h3><\/div>
\n\t\t\t\t\tRichtlinien zur Programmierung und Praxistipps zum Thema ABAP-Entwicklung.\t\t\t\t<\/p><\/div><\/div>
Trotz intensiver IT- und Fachbereichstests wird viel Quellcode produktiv gesetzt, der sofort im ersten Live Szenario in die Brüche geht. Schlimmstenfalls werden noch andere abhängige Anwendungen mit in die Versenkung gezogen und zwanzig Minuten nach Go-Live liegt die Prio-Störung auf dem Tisch. Wie konnte das nur passieren? <\/p>\n
Das größte Problem ist der mangelnde Überblick über alle Anwendungen die durch eine Änderung betroffenen sein könnten und die Auswirkungen.
\nInsbesondere „historisch gewachsene Anwendungen“ reagieren sehr empfindlich auf kleine Änderungen, insbesondere wenn diese im Laufe der Zeit tief mit anderen Anwendungen verwachsen sind.
\nWeder die IT, noch ein Fachbereich können 100% aller möglichen Testfälle abdecken. Stattdessen wird meistens die Strategie: „Exploratory Testing“ gewählt – sprich wir drücken alle Knöpfe einmal durch und schauen ob genau der eine fehlerfreie Optimalfall funktioniert. Doch es geht auch anders.<\/p>\n
Richtig gelesen, es ist möglich den gesamten Regressionstest in einem einzigen Klick abzuarbeiten. Die eierlegende Wollmilchsau also.
\nGut, ein wenig Mehraufwand wird nötig sein, schließlich muss ich die Testfälle im Vorfeld einmal definieren.
\nDas ist im Vergleich zu der technischen Sicherheit, dass eine Änderung die Funktionalität einer Anwendung nicht geändert hat, ein kleiner Preis.
\nDesweiteren ist das händische testen nach jeder Änderung nicht nur unvollständig, sondern auch eine zeit- und dementsprechend geldaufwändige Angelegenheit.<\/p>\n
<\/div>