Neue Themen als SAP Entwickler
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
So kommen wir nicht weiter. Ich erkläre jetzt nur noch mögliche Missverständnisse. Die Postings werden nur länger und länger und länger.
Ich bleibe dabei: Wenn mir ein Entwickler sagt "die Anwendung funktioniert" möchte ich von ihm wissen, worauf er diese Behauptung stützt. Hat er händisch Testreihen durchgeführt? Die hätte ich gern dokumentiert gesehen. Oder hat er Unit-Tests geschrieben? Die dokumentieren sich selbst.
Ohne Test - kein Transport.
Wie hättest du es denn gemacht? Nach jeder Änderung 200 Formulare durchtesten bis wirklich ALLE Formulare fehlerfrei sind? Und dann kommt noch eine Änderung und du testest wieder 200 verschiedene Permutationen durch?
Oder lieber gar nicht testen und warten, bis der Fachbereich mit lauter falschen Schreiben bei dir vor der Tür steht?
Oh, erstmal überhaupt nur Rentenbescheide an 50 Personen versenden und den anderen gar nichts schicken. Und diese bitte vor dem Eintüten alle nochmal vom Fachbereich auf Fehler prüfen lassen. Und wenn dann alles richtig ist, die nächsten 50.
Und dann ändert sich bei einem der "richtigen" Rentner der Status und der wird falsch?
Kann man wollen, hat aber mit OO nicht viel zu tun. Und ich bin froh, dass ich diesen Quatsch nicht mehr machen muss.
* Ich teste ob alle möglichen verschiedenen Kombinationen von gültigen Importparametern zum jeweils gewünschten Ergebnis führt
* Ich teste, ob ungültige Parameter nicht verarbeitet werden bzw. zum Fehler führen.
Das kann ich auch von Hand machen, muss ich aber jedes Mal mit gleichem Aufwand durchführen. Einen Test schreibe ich einmal.
F8 - dumpt nicht - ab aufs Prod -- so arbeitet man nicht mehr.
Und wenn du eine neue Druckstraße einführst mit neuer Software, stellt man nicht die neue neben die alte und lässt die mal ne Weile parallel laufen, weil du nicht weißt, ob die Daten von SAP aus richtig befüllt werden. Da gibt es einen Stichtag X und ab da müssen alle Schreiben aus der neuen Straße rauskommen.
Ralf
Ich bleibe dabei: Wenn mir ein Entwickler sagt "die Anwendung funktioniert" möchte ich von ihm wissen, worauf er diese Behauptung stützt. Hat er händisch Testreihen durchgeführt? Die hätte ich gern dokumentiert gesehen. Oder hat er Unit-Tests geschrieben? Die dokumentieren sich selbst.
Ohne Test - kein Transport.
Nein, es ist bescheuert, für jeden möglichen Betrag einen Test zu machen. Aber für jeden grundsätzlich unterschiedlichen Beleg. Wir haben das Formular auch nicht für jeden Betrag getestet, sondern für jede mögliche unterschiedliche Kombination von Textbausteinen zum Beispiel.DeathAndPain hat geschrieben: ↑08.09.2024 19:57Du würdest in meinem Beispiel also einen Testfall für jeden nur denkbaren Betrag machen.
Wie hättest du es denn gemacht? Nach jeder Änderung 200 Formulare durchtesten bis wirklich ALLE Formulare fehlerfrei sind? Und dann kommt noch eine Änderung und du testest wieder 200 verschiedene Permutationen durch?
Oder lieber gar nicht testen und warten, bis der Fachbereich mit lauter falschen Schreiben bei dir vor der Tür steht?
Oh, erstmal überhaupt nur Rentenbescheide an 50 Personen versenden und den anderen gar nichts schicken. Und diese bitte vor dem Eintüten alle nochmal vom Fachbereich auf Fehler prüfen lassen. Und wenn dann alles richtig ist, die nächsten 50.
Und dann ändert sich bei einem der "richtigen" Rentner der Status und der wird falsch?
Und doch gibt es immer wieder mal Seiteneffekte. Die Existenz solcher zu bestreiten, ist grotesk.DeathAndPain hat geschrieben: ↑08.09.2024 19:57Einer Klasse, die wiederverwendet wird, sollte es egal sein, von wem.
Und dann hast du genau das Problem wie mit Funktionsbauteinen, dass du eben nicht einen Beleg als Objekt hast, sondern irgendein Coding, das du mit Daten befüttern musst. So kannst du halt nicht in einer Schleife einfach sagen "buch mich", sondern musst in dieser Schleife ständig erstmal die vorgegebenen Werte ändern, weil du den Zustand ja nicht gespeichert hast.DeathAndPain hat geschrieben: ↑08.09.2024 19:57An dieser Stelle zahlen sich dann auch wieder zustandslose Methoden aus
Kann man wollen, hat aber mit OO nicht viel zu tun. Und ich bin froh, dass ich diesen Quatsch nicht mehr machen muss.
Und es sind ja keine theoretischen Tests. Jede Schnittstelle hat Importparameter und ein Ergebnis. Was ich nun mache, ist:DeathAndPain hat geschrieben: ↑08.09.2024 19:57Theoretische Tests zu machen und dann zu beten, dass es im praktischen Alltag genauso gut laufen wird und Deine theoretisch erdachten Testfälle alles abdecken, halte ich für naiv. Das endet so wie diverse Windowsupdates der letzten Zeit...
* Ich teste ob alle möglichen verschiedenen Kombinationen von gültigen Importparametern zum jeweils gewünschten Ergebnis führt
* Ich teste, ob ungültige Parameter nicht verarbeitet werden bzw. zum Fehler führen.
Das kann ich auch von Hand machen, muss ich aber jedes Mal mit gleichem Aufwand durchführen. Einen Test schreibe ich einmal.
F8 - dumpt nicht - ab aufs Prod -- so arbeitet man nicht mehr.
Und wenn du eine neue Druckstraße einführst mit neuer Software, stellt man nicht die neue neben die alte und lässt die mal ne Weile parallel laufen, weil du nicht weißt, ob die Daten von SAP aus richtig befüllt werden. Da gibt es einen Stichtag X und ab da müssen alle Schreiben aus der neuen Straße rauskommen.
Ralf
Zuletzt geändert von ralf.wenzel am 08.09.2024 20:39, insgesamt 1-mal geändert.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Dann muss du den Test anders machen. Natürlich sind das dann keine 100.000 Testfälle. Vermutlich ein Tabelle mit Input 0,01€...1000€ und einem Output 100 €, 864€, 883€,...wärst Du für den Bereich zwischen 0,01 € und 1000 € schon bei 100.000 "Testfällen".
Ich war mal in einem Java-Projekt, da waren Unit-Test auch Standard. Der jenige, der die verantwortet, hat da auch einiges an Logik reingesteckt. Aber, bei zuviel Logik, wird dann wieder die Verständlichkeit vom Test nicht ersichtlich. Aber bei deiner einfachen Tabelle sollte das passen. Und du muss ja nicht alle Werte von 0,01€ ... 1000€ in die Tabelle aufnehmen. Aber wenigstens den Fall der gedumpt ist.
Und was ist, wenn sie nicht funktioniert und du einen Fehler beheben muss? Woher weißt du, dass du nicht 3 neue Fehler einbaust bzw. etwas bisher funktionierendes kaputt machst. Genau auf da funktionierende habe sich alle anderen Verwender verlassen. Ok, bei solchen "popligen" Abfragen mag das reichen. Aber wenn es um komplexe Berechnungen (z.B. Zahlungstermine) geht, wird das echt heftig.Wenn ich an dieser Klasse bzw. Methode etwas machen möchte, dann ist für mich nur maßgeblich, dass dies die Funktionalität ist, die von dieser Methode bereitgestellt wird. Die kann man testen. Entweder sie funktioniert, oder sie funktioniert nicht.
"Sollte" und "dokumentiert" sind die Problem. Viele Entwickler dokumentieren nicht und andere machen auch mal Fehler. Damit hat die Methode nicht das Verhalten, was sie haben "sollte".definiertes (und dokumentiertes) Verhalten haben sollte.
Schön wär's. Vor einigen Jahren wurde der Steuersatz für Zinsen in der Gewerbesteuer von heute auf morgen vom Gericht als ungültig definiert, aber kein neuer Steuersatz festgelegt. 1) Die Komunen haben zunächst nicht mehr verzinst. 2) Dann wurde recht plötzlich der neue Steuersatz von der Politik festgelegt und das rückwirkend. Also musste irgendwie die Software das rückwirkend grade ziehen. Hat ein Kollege von mir gemacht. Leider ohne Unit-Test und es lief ewig im Kreis, weil genau die eine Korrektur zum Fehler führte, weil am Anfang nicht alles berücksichtigt wurde/werden konnte. Glaub mir, Berechnungen in der Gewerbesteuer inkl. Vollverzinsung sind kein Pappenstiel.Der Gesetzgeber räumt immer längere Umstellungszeiträume ein.
Aktuelles Thema "digitaler Gewerbesteuerbescheid" über Elster. Bei der Gewerbesteuer sind für das XML noch nicht mal alle Kriterien fachlich sauber definiert. Soll aber ab 01.01.2025 möglich sein.
Folgende Benutzer bedankten sich beim Autor msfox für den Beitrag:
ralf.wenzel
Oh ja, hatte ich ganz vergessen. Bei Unit-Test gibt es ja Code Coverage. Da sieht man gleich wieviel Quellcode-Zeilen bereits getestet wurden. Ok, das ist nur nicht immer aussagekräftig. Bei den 100.000 Fällen aus dem Beispiel würde sicher immer der gleich Code durchlaufen. Aber wenn man IF, ELSE, CASE, etc. drin hat, machen Unit-Test Sinn um gleich zu sehen, ob wirklich jede Möglichkeit - auch Exceptions etc. durchlaufen wurden. DAS macht ein manueller Tester nicht!Oder hat er Unit-Tests geschrieben? Die dokumentieren sich selbst.
---
Wie testet ihr Formulare (Smartforms?)? Da kommt ja am Ende nur ein OTF raus. Außer, man hat sämlich Logik in der Anwendungsklasse und gibt das dann im Smartforms nur noch aus. Dann kann man die Anwendungs-/Formularklasse anhand der PWB_DATA testen.Wir haben das Formular auch nicht für jeden Betrag getestet,
@msfox
Es ging um DB-Read und du schreibst vom DB-Insert 😄, aber es ist prinzipiell dieselbe Crux: ich will beim DB-Insert eben kein gemocktes Ergebnis sehen, sondern das tatsächliche, d.h. ob die Daten korrekt auf der DB abgelegt wurden. Erst dann bin ich sicher, dass Spaltennamen, Schlüsselwerte, Select-Bedingungen, Datentypen, Domänenwerte, die DB-Verfügbarkeit, die Authentifizierung, eine etwaige DB-Protokollierung, Sperren, YouNameIt... korrekt funktionieren. Prüft das gemockte Ergebnis dies alles? Und das wäre dann lediglich 50-100 % Mehraufwand? Das möchte ich doch mal stark bezweifeln.
DAO? Ich nehme mal an, du meinst eine Entity oder halt irgendein Datenbankobjekt. Deren CRUD-Methoden werden beim Anlegen getestet - spätestens beim 1. Projektlauf. Entweder werden deren Properties korrekt abgelegt und eingelesen oder nicht. Gibt es eine neue Property (Feld, DB-Spalte), wird diese hinzugefügt und getestet, ob diese geschrieben und gelesen wird. Sowas fällt SOFORT auf. Wieso sollte man da den jeweiligen CRUD-Aufruf in irgendeiner aufrufenden Methode während des Testens verhindern bzw. durch gemockte Fake-Daten etwas vortäuschen, was sich vom Live-Betrieb unterscheidet? Das ergibt doch keinen Sinn und auch eine etwaige DB-Schonung wg. zigtausender Testfälle ist hanebüchen, weil genau dafür regelmäßige System- & Mandanten-Kopien gefahren werden.
Und jetzt kommen wir zum kritischen Punkt: Ein Feld fällt weg oder ändert sich (Name, Datentyp, Domänenwerte, blablub...). Wieviele vorbereitete Testfälle und gemockte Ergebnisse müsste man nun anpassen, damit das systemweit gerade gezogen wird? Wie stellt man sicher, dass keiner davon vergessen wird?
Ferner nützen Unit-Tests bei derartigen konkreten DB-Reads oder DB-Inserts auch herzlich wenig bei etwaigen inhaltlichen Fehlern. Deswegen gibt es ja gerade Test- & Q-Systeme: für hinreichend(!) verlässliche Testdaten und die sind, die Realität lehrt es immer wieder, auch nie 100 % sauber. Und nun?
Dazu ein Realitätsschock: ich habe hier Kunden, die wild in ihrem P-System hart auf der Datenbank fehlerhafte Daten korrigieren. Warum? Weil deren Kunde am Telefon nervt und man nicht erst x Tage warten kann, bis irgendwas von einem Ticketsystem mal in einen Planner rutscht, Poker-Planning-Runden durchlaufen hat, "sauber" implementiert und ge-Unit-Testet sowie dokumentiert und abgenommen wurde.
Dann gibt es Projekte, bei denen Monate nach Projektbeginn ein mittelschwerer Rework eines (Groß-)Teils der Implementierung fällig ist, weil sich erst im Laufe des Projekts offenbart, dass grundsätzliche Unstimmigkeiten bestanden haben (räusper... Fachbereich) oder man nach wochenlangem Prototyping auf eine elegantere Lösung stößt. Na Prost Mahlzeit, wenn man da mal eben auch hunderte Testfälle wegwerfen bzw. anpassen kann.
Darüber hinaus verstehe ich immer noch nicht, wieso man es überhaupt vorzieht, hunderte Testfälle für eine Riesenentwicklung aufzubauen und beständig durchzurödeln statt die zugehörige Entwicklung kleinteiliger zu gestalten. Wieso gibt es nur 1 Formular für hunderte unterschiedliche Fälle? Wieso nicht 10 oder 20 Formulare und eine entsprechend überschaubare zugehörige Entwicklung? Wäre das zu einfach?
Also ich gehe davon aus, dass Unit-Tests hier und da ihre Berechtigung haben dürften, nur so wie ihr das schreibt, klingt es so, dass jedwede Software ohne Unit-Tests stümperhaft sei. Ich frage mich, wie wohl meine Kunden reagieren, wenn ich ihnen sage:
"Sorry Leute, um diesen Bug bei der Auftragseingangsverarbeitung sauber zu entfernen, würde es normalerweise reichen, dieses eine 'AND' durch ein 'OR' zu ersetzen, aber ich verfolge nun den Ansatz der 'qualitätssichernden Software'. Daher müssen wir nun erstmal alle Fallkonstellationen aller eingehenden Order-IDocs zusammentragen und in entsprechenden Unit-Tests unterbringen, bevor wir zu manuellen Eingabekonstellationen und deren Unit-Test-Behandlung in der SAPMV45A kommen.
Liebe Grüße, dein freundlicher SAP-Berater 😚"
Es ging um DB-Read und du schreibst vom DB-Insert 😄, aber es ist prinzipiell dieselbe Crux: ich will beim DB-Insert eben kein gemocktes Ergebnis sehen, sondern das tatsächliche, d.h. ob die Daten korrekt auf der DB abgelegt wurden. Erst dann bin ich sicher, dass Spaltennamen, Schlüsselwerte, Select-Bedingungen, Datentypen, Domänenwerte, die DB-Verfügbarkeit, die Authentifizierung, eine etwaige DB-Protokollierung, Sperren, YouNameIt... korrekt funktionieren. Prüft das gemockte Ergebnis dies alles? Und das wäre dann lediglich 50-100 % Mehraufwand? Das möchte ich doch mal stark bezweifeln.
DAO? Ich nehme mal an, du meinst eine Entity oder halt irgendein Datenbankobjekt. Deren CRUD-Methoden werden beim Anlegen getestet - spätestens beim 1. Projektlauf. Entweder werden deren Properties korrekt abgelegt und eingelesen oder nicht. Gibt es eine neue Property (Feld, DB-Spalte), wird diese hinzugefügt und getestet, ob diese geschrieben und gelesen wird. Sowas fällt SOFORT auf. Wieso sollte man da den jeweiligen CRUD-Aufruf in irgendeiner aufrufenden Methode während des Testens verhindern bzw. durch gemockte Fake-Daten etwas vortäuschen, was sich vom Live-Betrieb unterscheidet? Das ergibt doch keinen Sinn und auch eine etwaige DB-Schonung wg. zigtausender Testfälle ist hanebüchen, weil genau dafür regelmäßige System- & Mandanten-Kopien gefahren werden.
Und jetzt kommen wir zum kritischen Punkt: Ein Feld fällt weg oder ändert sich (Name, Datentyp, Domänenwerte, blablub...). Wieviele vorbereitete Testfälle und gemockte Ergebnisse müsste man nun anpassen, damit das systemweit gerade gezogen wird? Wie stellt man sicher, dass keiner davon vergessen wird?
Ferner nützen Unit-Tests bei derartigen konkreten DB-Reads oder DB-Inserts auch herzlich wenig bei etwaigen inhaltlichen Fehlern. Deswegen gibt es ja gerade Test- & Q-Systeme: für hinreichend(!) verlässliche Testdaten und die sind, die Realität lehrt es immer wieder, auch nie 100 % sauber. Und nun?
Dazu ein Realitätsschock: ich habe hier Kunden, die wild in ihrem P-System hart auf der Datenbank fehlerhafte Daten korrigieren. Warum? Weil deren Kunde am Telefon nervt und man nicht erst x Tage warten kann, bis irgendwas von einem Ticketsystem mal in einen Planner rutscht, Poker-Planning-Runden durchlaufen hat, "sauber" implementiert und ge-Unit-Testet sowie dokumentiert und abgenommen wurde.
Dann gibt es Projekte, bei denen Monate nach Projektbeginn ein mittelschwerer Rework eines (Groß-)Teils der Implementierung fällig ist, weil sich erst im Laufe des Projekts offenbart, dass grundsätzliche Unstimmigkeiten bestanden haben (räusper... Fachbereich) oder man nach wochenlangem Prototyping auf eine elegantere Lösung stößt. Na Prost Mahlzeit, wenn man da mal eben auch hunderte Testfälle wegwerfen bzw. anpassen kann.
Darüber hinaus verstehe ich immer noch nicht, wieso man es überhaupt vorzieht, hunderte Testfälle für eine Riesenentwicklung aufzubauen und beständig durchzurödeln statt die zugehörige Entwicklung kleinteiliger zu gestalten. Wieso gibt es nur 1 Formular für hunderte unterschiedliche Fälle? Wieso nicht 10 oder 20 Formulare und eine entsprechend überschaubare zugehörige Entwicklung? Wäre das zu einfach?
Also ich gehe davon aus, dass Unit-Tests hier und da ihre Berechtigung haben dürften, nur so wie ihr das schreibt, klingt es so, dass jedwede Software ohne Unit-Tests stümperhaft sei. Ich frage mich, wie wohl meine Kunden reagieren, wenn ich ihnen sage:
"Sorry Leute, um diesen Bug bei der Auftragseingangsverarbeitung sauber zu entfernen, würde es normalerweise reichen, dieses eine 'AND' durch ein 'OR' zu ersetzen, aber ich verfolge nun den Ansatz der 'qualitätssichernden Software'. Daher müssen wir nun erstmal alle Fallkonstellationen aller eingehenden Order-IDocs zusammentragen und in entsprechenden Unit-Tests unterbringen, bevor wir zu manuellen Eingabekonstellationen und deren Unit-Test-Behandlung in der SAPMV45A kommen.
Liebe Grüße, dein freundlicher SAP-Berater 😚"
Folgende Benutzer bedankten sich beim Autor tar für den Beitrag (Insgesamt 2):
DeathAndPain • black_adept
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Doppelpost, sorry.
Zuletzt geändert von ralf.wenzel am 09.09.2024 08:39, insgesamt 1-mal geändert.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Nein, ich erzeuge XMLs für Inspire.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Nochmal: Es geht nicht darum, die DAO-Schicht (also das INSERT) zu testen, das kann man auch machen, aber das ist ein anderes Thema. Hier geht es darum, die Logik dahinter zu testen, also was mit den Daten gemacht wird, die da gelesen wurden.
Und um DAS zu testen, muss ich sie nicht von der DB lesen. Und wenn ich sie nicht von der DB lese, bin ich systemunabhängig.
Das ist doch so schwer nicht.
Ralf
Und um DAS zu testen, muss ich sie nicht von der DB lesen. Und wenn ich sie nicht von der DB lese, bin ich systemunabhängig.
Das ist doch so schwer nicht.
Nein, zu kompliziert. Weil die Zahl der Fälle ja nicht kleiner wird, wenn man z. B. eine Bestellung einfach in mehrere verschiedene "Bestellungs-Fall-Formulare" aufteilt. Die Fälle werden ja nicht weniger, man hat nur noch mehr Formulare.tar hat geschrieben: ↑09.09.2024 00:56Darüber hinaus verstehe ich immer noch nicht, wieso man es überhaupt vorzieht, hunderte Testfälle für eine Riesenentwicklung aufzubauen und beständig durchzurödeln statt die zugehörige Entwicklung kleinteiliger zu gestalten. Wieso gibt es nur 1 Formular für hunderte unterschiedliche Fälle? Wieso nicht 10 oder 20 Formulare und eine entsprechend überschaubare zugehörige Entwicklung? Wäre das zu einfach?
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Nochmal: Es geht darum, sicherzustellen, dass man mit korrekten Testdaten arbeitet. Wie willst du das tun, wenn du mit eigenen, vorgetäuschten Daten hantierst und so überhaupt nichts von etwaigen Änderungen mitbekommst? Dann funktioniert deine Logik am Ende zwar wunderbar für deine Fake-Daten, aber nicht für die produktiven - spitze 🥳ralf.wenzel hat geschrieben: ↑09.09.2024 08:46Nochmal: Es geht nicht darum, die DAO-Schicht (also das INSERT) zu testen, das kann man auch machen, aber das ist ein anderes Thema. Hier geht es darum, die Logik dahinter zu testen, also was mit den Daten gemacht wird, die da gelesen wurden.
Und um DAS zu testen, muss ich sie nicht von der DB lesen. Und wenn ich sie nicht von der DB lese, bin ich systemunabhängig.
Das ist doch so schwer nicht.
Folgende Benutzer bedankten sich beim Autor tar für den Beitrag:
DeathAndPain
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Du argumentierst: Warum macht man die Abgasuntersuchung auf einem Rollenprüfstand - vielleicht gibt es ja ganz andere Werte auf der Straße?
Der Witz ist: Auf dem Rollenprüfstand sind die Werte verschiedener Autos VERGLEICHBAR. Weil der Rollenprüfstand immer der gleiche ist.
Und darum geht es bei Unit-Tests: Die Rahmenbedingungen vereinheitlichen, damit sich das Programm immer gleich verhält und nicht plötzlich Fehler hochkommen, die keine Programmfehler sind, sondern Datenfehler (im Sinne von "die notwendigen Testdaten sind nicht vorhanden").
Das heißt nicht, dass der Rollenprüfstand der einzige Test ist, aber es ist ein wichtiger Test, der zeigt, dass das Programm funktioniert.
Ralf
Der Witz ist: Auf dem Rollenprüfstand sind die Werte verschiedener Autos VERGLEICHBAR. Weil der Rollenprüfstand immer der gleiche ist.
Und darum geht es bei Unit-Tests: Die Rahmenbedingungen vereinheitlichen, damit sich das Programm immer gleich verhält und nicht plötzlich Fehler hochkommen, die keine Programmfehler sind, sondern Datenfehler (im Sinne von "die notwendigen Testdaten sind nicht vorhanden").
Das heißt nicht, dass der Rollenprüfstand der einzige Test ist, aber es ist ein wichtiger Test, der zeigt, dass das Programm funktioniert.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
@tar und @Ralf: Ihr bewegt euch in verschiedenen Welten. tar hat die Art von Kunden, die ich kenne, Ralf eher solche welche bereit sind für gut (getestete) Software auch zu bezahlen.
@Ralf: Hier mal kurz ein Auszug aus einem Projekt von mir. Ich sollte die Eigenentwicklungen des Kunden grob durchsuchen ob mir da "komische"/"gefährliche" Sachen auffallen. Abgesehen von hart verdrahteten Usernamen und Emailadressen habe ich zig harte Updates auf SAP-Tabellen gefunden - sowohl Kunden ZZ- als auch SAP-Standardfelder. Und die meisten davon habe ich als kritisch eingestuft weil z.B. beim Update auf VBAP und ähnliche Tabellen keine Sperren gesetzt wurden, so dass theoretisch Daten verloren gehen könnten. Ich hatte vorgeschlagen, dass bei denjenigen Tabellen, wo SAP BAPIs anbietet, dass auf ebendiese umgestellt wird inkl. Fehlerbehandlungen wenn z.B. gerade eine Sperre sitzt. Das waren doch einige Stellen, das Budget knapp und man lebt scheinbar seit Jahr(zehnt)en mit dieser Situation und entweder arbeitet man so, dass nie Daten verloren gehen oder man hat sich damit arrangiert und trägt verlorene Daten halt nach, wenn man sie entdeckt.
Ist das so wie ich arbeiten würde: Nein
Ist das betriebswirtschaftlich vertretbar: Vielleicht - das ist irgendwie so wie mit stichprobenhafter Rechnungsprüfung. Manchmal ist es billiger nicht alles perfekt zu haben und Zusatzkosten hinzunehmen als alles auf 100% zu bringen.
Immerhin weiß man dort jetzt woran es liegen könnte, wenn mal was verloren gegangen ist und dass es nicht so ist ,dass die Anwender zu doof sind Daten einzugeben. Vielleicht ringt man sich ja auch noch durch ein paar der Stellen zu entschärfen - aber da ist halt immer das Damoklesschwert des Budgets.
Und diese Situation, lieber Ralf, ist (leider) viel häufiger anzutreffen als du glaubst. Ich sehe ja, dass du solche Projekte scheinbar ablehnst, wenn man dort nicht nach "guten" Methodiken vorgeht - aber auch die Schmuddelkinder haben Fürsorge verdient.
@Ralf: Hier mal kurz ein Auszug aus einem Projekt von mir. Ich sollte die Eigenentwicklungen des Kunden grob durchsuchen ob mir da "komische"/"gefährliche" Sachen auffallen. Abgesehen von hart verdrahteten Usernamen und Emailadressen habe ich zig harte Updates auf SAP-Tabellen gefunden - sowohl Kunden ZZ- als auch SAP-Standardfelder. Und die meisten davon habe ich als kritisch eingestuft weil z.B. beim Update auf VBAP und ähnliche Tabellen keine Sperren gesetzt wurden, so dass theoretisch Daten verloren gehen könnten. Ich hatte vorgeschlagen, dass bei denjenigen Tabellen, wo SAP BAPIs anbietet, dass auf ebendiese umgestellt wird inkl. Fehlerbehandlungen wenn z.B. gerade eine Sperre sitzt. Das waren doch einige Stellen, das Budget knapp und man lebt scheinbar seit Jahr(zehnt)en mit dieser Situation und entweder arbeitet man so, dass nie Daten verloren gehen oder man hat sich damit arrangiert und trägt verlorene Daten halt nach, wenn man sie entdeckt.
Ist das so wie ich arbeiten würde: Nein
Ist das betriebswirtschaftlich vertretbar: Vielleicht - das ist irgendwie so wie mit stichprobenhafter Rechnungsprüfung. Manchmal ist es billiger nicht alles perfekt zu haben und Zusatzkosten hinzunehmen als alles auf 100% zu bringen.
Immerhin weiß man dort jetzt woran es liegen könnte, wenn mal was verloren gegangen ist und dass es nicht so ist ,dass die Anwender zu doof sind Daten einzugeben. Vielleicht ringt man sich ja auch noch durch ein paar der Stellen zu entschärfen - aber da ist halt immer das Damoklesschwert des Budgets.
Und diese Situation, lieber Ralf, ist (leider) viel häufiger anzutreffen als du glaubst. Ich sehe ja, dass du solche Projekte scheinbar ablehnst, wenn man dort nicht nach "guten" Methodiken vorgeht - aber auch die Schmuddelkinder haben Fürsorge verdient.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Wie ich schon schrieb: Ich suche mir das durchaus aus. Ich bin Software-Entwickler und arbeite da, wo ordentlich Software entwickelt wird. Nach Maßstäben, die in anderen Programmiersprachen üblich sind.black_adept hat geschrieben: ↑09.09.2024 11:21@tar und @Ralf: Ihr bewegt euch in verschiedenen Welten. tar hat die Art von Kunden, die ich kenne, Ralf eher solche welche bereit sind für gut (getestete) Software auch zu bezahlen.
Nein. Ungetestete Software ist im unternehmenskritischen Bereich auf keinen Fall vertretbar. Und Ausprobieren ist kein Testen.black_adept hat geschrieben: ↑09.09.2024 11:21Das waren doch einige Stellen, das Budget knapp und man lebt scheinbar seit Jahr(zehnt)en mit dieser Situation und entweder arbeitet man so, dass nie Daten verloren gehen oder man hat sich damit arrangiert und trägt verlorene Daten halt nach, wenn man sie entdeckt.
Ist das so wie ich arbeiten würde: Nein
Ist das betriebswirtschaftlich vertretbar: Vielleicht -
Es mag sein, dass das Leuten reicht, aber in sowas arbeite ich nicht. Ich würde auch als Elektriker (das hab ich wirklich mal gelernt) in einem einsturzgefährdeten Haus die Elektrik ändern.
Es geht ab einem gewissen Punkt nicht mehr um billiger oder teurer. Eine Herz-OP lasse ich auch nicht von dem Arzt machen, der sie billiger anbietet als ein anderer. Und das ist mit dem Unternehmensbeispiel durchaus vergleichbar.black_adept hat geschrieben: ↑09.09.2024 11:21Manchmal ist es billiger nicht alles perfekt zu haben und Zusatzkosten hinzunehmen als alles auf 100% zu bringen.
Wer DAFÜR kein Geld hat, sollte seinen Laden schließen. Der hat auch Firmenwagen ohne TÜV oder baut sich ein Firmengebäude ohne statische Berechnung.black_adept hat geschrieben: ↑09.09.2024 11:21aber da ist halt immer das Damoklesschwert des Budgets.
Nein, sie haben Hilfe verdient. Wenn sie die nicht wollen, dann eben nicht. FÜRSORGE leiste ich nicht, ich leiste Hilfe.black_adept hat geschrieben: ↑09.09.2024 11:21aber auch die Schmuddelkinder haben Fürsorge verdient.
Ich gehe mit meinem Auto (das ich ja nicht habe) auch nicht zu irgendeinem Nachbarn, weil der mir den Motor tauscht für einen Kasten Bier. Ich fahre zu einer Werkstatt, weil ich weiß, dass die das können und ordentlich machen. Kostet halt ein bisschen, aber ich kann ziemlich sicher sein, dass ich weiter mit dem Auto fahren kann als ich es werfen könnte.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Das Lustige ist ja, dass die Software zigtausendfach getestet ist und man (inzwischen) weiß, dass die fehlerhaft bzw. nicht IMMER korrekt arbeitet. Aber das ist scheinbar keine Herz-OP, wo ein Fehler das Ende darstellt sondern eher sowas wie das Finden einer Lösung für ein TSP. Eine "hinreichend gute" Lösung ist akzeptabel.ralf.wenzel hat geschrieben: ↑09.09.2024 11:34Nein. Ungetestete Software ist im unternehmenskritischen Bereich auf keinen Fall vertretbar. Und Ausprobieren ist kein Testen.
Ralf
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain
Nein, das prüft dann der Integrataionstest. Wie auch immer der aussieht...tar hat geschrieben: ↑09.09.2024 00:56Erst dann bin ich sicher, dass Spaltennamen, Schlüsselwerte, Select-Bedingungen, Datentypen, Domänenwerte, die DB-Verfügbarkeit, die Authentifizierung, eine etwaige DB-Protokollierung, Sperren, YouNameIt... korrekt funktionieren. Prüft das gemockte Ergebnis dies alles?[/i]
Primär dienen die Unit-Test dazu, um den eigenen geschriebenen Quellcode zu testen. Darunter fällt dann nicht die Verfügbarkeit, Sperre und Protokolle der Datenbank.
Im Zweifel alle...Wieviele vorbereitete Testfälle und gemockte Ergebnisse müsste man nun anpassen, damit das systemweit gerade gezogen wird?
In dem man sie einfach ausführt. Die, die auf Fehler laufen, müssen untersucht und ggf. angepasst werden.Wie stellt man sicher, dass keiner davon vergessen wird?
Genau und nun! Wenn du mit deinen MOCK-Daten arbeitest, dann sind diese immer gleich, da du sie ja definiert hast. Was in der unsauberen Datenbank ein T-Systems steht, kann dir dann egal sein.Deswegen gibt es ja gerade Test- & Q-Systeme: für hinreichend(!) verlässliche Testdaten und die sind, die Realität lehrt es immer wieder, auch nie 100 % sauber. Und nun?
Was sagt da die Revision dazu, wenn Daten an der Änderungsprotokollierung vorbei angepasst werden. Also in der öffentlich Verwaltung hast du dann echt ein Problem, wenn du nicht nachweisen kannst, warum z.B. irgendwelche Gewerbesteuerdaten falsch waren und es dazu nix an Änderungsbelegen gibt und vor allem, wer es gändert hat. Hart auf der Datenbank zu 99% ein no-Go.ich habe hier Kunden, die wild in ihrem P-System hart auf der Datenbank fehlerhafte Daten korrigieren. Warum? Weil deren Kunde am Telefon nervt
Kommt drauf an :). Bei uns wurden schon tagelang rundungsCents gesucht. Wo ich dann immer ironisch sage, gebt der Gemeinde die paar Cent, bevor ihr sie sucht, was an Beratertagen teurer ist. Das geht natürlich nicht! Die Rechnung muss auf den Cent genau sein.Manchmal ist es billiger nicht alles perfekt zu haben und Zusatzkosten hinzunehmen als alles auf 100% zu bringen.
Muss du doch nicht. Du kannst doch die Daten zu dem Stichtag aus dem System als Testdaten nehmen. Dann sind sie nicht vortäuscht, kommen aber auch nicht von der Datenbank. Naja ok, vielleicht doch, wenn du sie in einen ECatts-DatenContainer packst.Wie willst du das tun, wenn du mit eigenen, vorgetäuschten Daten hantierst und so überhaupt nichts von etwaigen Änderungen mitbekommst?
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Richtig - und das geht auch gar nicht anders, weil unterschiedliche Systeme unterschiedlich eingestellt sind. Insbesondere beim Berechtigungskonzept.
Eines wollte ich ja noch anfügen: Es gibt Fälle, die im System gar nicht abgebildet sind.
Beispiel: Es gibt eine neue Regelung, die besagt, dass Sendungen, die Akkus enthalten, außen einen speziellen Aufkleber vorweisen müssen. Jetzt weißt du, dass du bald Akkus Geräten beilegen willst, die Akkubetrieben sind. Aber die hast du noch nicht im System, weil du die noch nicht hast. Oder weil die nicht auf Lager sind. Was weiß ich?
Wie testest du das? Indem du nicht die DB abfragst, sondern einen Test baust, der SO TUT als wäre das so ein Fall. Weil auf der DB gibt es ein solches Gerät leider noch nicht.
Und so kannst du halt viele Fälle testen, die du KONKRET gar nicht auf dem System hast, die du aber vorhalten musst -- für den Fall, dass jemand im Einkauf auf die Idee kommt, solche Geräte einzukaufen aber natürlich nicht weiß, welche Verpackungsregelungen es gibt. Das weiß möglicherweise nichtmal der Verkauf. Aber die Versandabteilung, die den Aufkleber draufmachen muss, die weiß das und meldet das als Anforderung an die Entwicklung: "Es gibt da eine neue gesetzliche Regelung, bitte sorgt dafür, dass alle Sendungen, die Akkus enthalten, einen solchen Aufkleber vorsehen".
Was glaubst du, wie viele Fälle beim Versorgungsausgleich (Scheidung) wir abbilden können müssen, die wir akut gar nicht auf dem System haben? Jetzt kann man sagen "tja, dann muss man sich den ersten Fall, der vorkommt, halt genau angucken". Das muss der Sachbearbeiter aber wissen, dass er den ersten solchen Fall hat und nicht ein Kollege den schon hatte. Und wenn man zentral in einer Druckstraße druckt ist das "wir gucken uns das mal an" nicht so trivial, weil jeden Tag tausende Briefe rausgehen.
Die weiß das nicht, sonst hätten die das längst abgestellt. Weil das in HÖCHSTEM Maße unseriös ist. Leute, die sowas machen, gehören angezeigt. Und das meine ich wirklich so wie ich das schreibe. Ich kann mir die Daten auf einem Produktivsystem nicht einfach hinbiegen wie ich sie schön finde. Es gibt Buchführungs- und Aufzeichnungspflichten.
Es GIBT Fälle, wo Produktivdaten geändert werden, aber das muss man hinreichend protokollieren.
Kenne ich - SAP Einführung bei einer Kommune, Tagesabschluss, was ich da an Stunden mit den Kassenleiter Cents gesucht habe....msfox hat geschrieben: ↑09.09.2024 14:49Kommt drauf an :). Bei uns wurden schon tagelang rundungsCents gesucht. Wo ich dann immer ironisch sage, gebt der Gemeinde die paar Cent, bevor ihr sie sucht, was an Beratertagen teurer ist. Das geht natürlich nicht! Die Rechnung muss auf den Cent genau sein.
Letztlich landen wir immer wieder bei der Frage: Der Entwickler hat eine Anwendung geschrieben und übergibt die dem Anwender mit dem Hinweis: Funktioniert, bitte abnehmen. Da wäre MEINE erste Frage: Woraus schließt du, dass sie funktioniert? Hast du sie getestet? Wo ist das Testprotokoll, damit ich sehen kann, ob du hinreichend viele Fälle getestet hast?
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Antwort: Getestet und protokolliert an den Testfällen, die im Pflichtenheft dokumentiert wurden.ralf.wenzel hat geschrieben: ↑09.09.2024 15:44Letztlich landen wir immer wieder bei der Frage: Der Entwickler hat eine Anwendung geschrieben und übergibt die dem Anwender mit dem Hinweis: Funktioniert, bitte abnehmen. Da wäre MEINE erste Frage: Woraus schließt du, dass sie funktioniert? Hast du sie getestet? Wo ist das Testprotokoll, damit ich sehen kann, ob du hinreichend viele Fälle getestet hast?
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
tar
Vergleichbare Themen
0
Antw.
Antw.
2218
Views
Views
OO-Themen die in anderen Threads OT sind
von black_adept » 23.08.2018 09:01 • Verfasst in ABAP Objects®
von black_adept » 23.08.2018 09:01 • Verfasst in ABAP Objects®
10
Antw.
Antw.
14927
Views
Views
Suche Videotutorials zu folgenden Themen
von Up4Anything » 02.03.2011 14:01 • Verfasst in Tutorials & Cookbooks
von Up4Anything » 02.03.2011 14:01 • Verfasst in Tutorials & Cookbooks
2
Antw.
Antw.
3366
Views
Views
Aktuelle Themen / Forschungstrends im SAP Bereich
von OnkelSAP » 28.03.2011 12:35 • Verfasst in SAP - Allgemeines
von OnkelSAP » 28.03.2011 12:35 • Verfasst in SAP - Allgemeines
18
Antw.
Antw.
5535
Views
Views
4
Antw.
Antw.
9732
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1137
vor 2 Tagen von DeathAndPain 4 / 1137
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1137
vor 2 Tagen von DeathAndPain 4 / 1137