Qualitätssicherung

[Tom]

Software ist diffiziles Zeug, und der Präfix "Soft" ist nicht umsonst im Wort enthalten. Eine kleine Änderung, durchaus gut gemeint, kann zu dramatischen Konsequenzen führen, weil die ganze Ware plötzlich weich wird. Zudem besteht Software ja nicht nur aus dem Code, den man kompiliert hat, sondern aus Datenbanken, Laufzeitbibliotheken der Entwicklungsumgebung und möglicherweise zig Zusatzlibraries, vom Reportgenerator bis zum Migrationstool. Das Betriebssystem nicht zu vergessen - von Windows gibt es derzeit gut und gerne zwanzig++ Versionen, die noch halbwegs aktuell sind (und auf zwei Milliarden Arten konfiguriert werden können), vernetzt in amorphen Topologien, auf alle möglichen Arten, mit Macs als Clients und Servern, auf denen alles mögliche laufen kann, auch Linux oder sogar, Gott behüte, eine alte Novell-Version, die die Serverplatte vollaufen läßt, weil keiner ein Purge durchführt. Und zwischendrin befinden sich Virenscanner, Backupsysteme, lustige Eingabehilfen, die den Fokus von Eingabefeldern ziehen, und weiß der Geier was noch alles.

In einem anderen Forum (auf das ich jetzt nicht verlinken möchte) läuft gerade eine Art Diskussion darüber, welche Konsequenzen Änderungen haben können, die zwar in einem Fall helfen, dafür aber in hundert anderen, die nichts mit dem Änderungswunsch zu tun haben, zu Fehlern führen . Wir alle - oder zumindest diejenigen von uns, die eine Vielzahl von Endkunden bedienen - kennen das vermutlich (leider). Da schraubt man an einer Funktion herum, damit ein drängender Kunde etwas in der Form bekommt, in der er es haben will, und vergißt, daß diese Funktion ganz zufällig in einem datadriven erzeugten Index benutzt wird, weshalb man den Verweis nicht im Code findet. Oder so ähnlich. Das Update wird im Haus getestet, danach ausgeliefert, und dann macht es tierisch laut KNARZ! - und hundert Kunden stehen verärgert auf der Matte. Gut, einer ist vielleicht glücklich. Während der nächsten Tage ist der Support ausschließlich damit beschäftigt, die Daten der nichtglücklichen Kunden wieder instandzusetzen, weil der falsche Index dazu geführt hat, daß Tabelleninhalte gelöscht wurden. Okay, das ist ein Extremfall und eine Ausnahme, aber Ihr versteht vermutlich, worauf ich hinauswill.

Leider hat man ja, wie eingangs erläutert, nicht die komplette Kontrolle über alle Systematiken. Selbst das Update eines Reportgenerators kann plötzlich alles lahmlegen. Oder es ist ein Compiler-Hotfix geliefert worden, der zur Folge hat, daß ein Control plötzlich ganz anders reagiert, wenn bestimmte - seltene - Zustände eintreten - die leider ausgerechnet in Eurem System gegeben sind.

Wir testen Updates (wir unterscheiden zwischen Hotfixes und Updates - Updates gibt es nur viermal im Jahr, Hotfixes bedarfsweise, aber ohne neue Featuresets, dazwischen) ausgiebig im Haus und geben sie dann einigen Betatestern, aber die Bereitschaft bei Kunden, Betaversionen mit Realdaten zu testen, ist verständlicherweise vergleichsweise gering, weshalb die Tests auch bestenfalls halbherzig ausfallen. Bei Zusatzbibliotheken testen wir die dokumentierten Änderungen auf Herz und Nieren, aber leider wird längst nicht alles dokumentiert.

Wie geht Ihr mit solchen Fragen um? Wie stellt Ihr die Qualität der auszuliefernden Updates sicher, auch im Hinblick auf Drittkomponenten und ähnliches? Wie testet Ihr? Unter welchen Bedingungen? Bis zu welchem Punkt?

[Manfred]

Hi Tom,

das ist natürlich ein extrem heißes Thema. Ich habe es aufgegeben bis in kleinste Detail zu testen, weil es einem Programmierer eh nicht gelingt den DAU zu simulieren. Der Programmierer geht den Weg, der gegangen werden sollte und stellt fest, dass es klappt. Der User geht den Weg, der ihm gerade durch den Kopf geht und dann knallt es ziemlich schnell.
Glücklicherweise gab und gibt es bei mir immer einen oder mehrere Betatester, die sich teilweise echt dumm anstellen können und somit zumindest etliche Fehler finden, die einfach dem logischen Verstand entgegen gehen. Alle anderen Fehler..... warten und hoffen dass nichts passiert.

Was mir persönlich oft hilft und geholfen hat ist einfach nur im Hintergrund stehen bleiben und dem User zusehen, was er macht.

[Jan]

Hallo Tom,

Du sprichst da ein wichtiges und unangenehmes Thema an. Auf einer anderen Webseite habe ich vor kurzem eine Diskussion verfolgt wo jemand eine "Rechnerfarm" anbieten wollte. Mit diversen verschiedenen Rechnerkonfigurationen und verschiedenen Windows-Versionen. Damit man da alles durchtesten kann. Gegen Entgelt natürlich. Aber immer noch billiger, als wenn man all diese Rechner und Betriebssysteme selber bereitstellen müsste.

Auch das Problem "hier ein klein wenig korrigiert, und an dutzenden anderen Orten etwas damit kaputtgemacht" kenne ich. Leider. Ich versuche das zu minimieren, indem ich in letzter Zeit mehr und mehr Anmerkungen in den Code schreibe. Und an besonderen Stellen nicht einfach nur zu schreiben: "Hier passiert das und das". Sondern auch zu schreiben, warum das genau so ist, und warum das nicht geändert werden darf. Damit kann ich solche Fehler nicht ganz aus der Welt schaffen. Aber wenigstens die Wahrscheinlichkeit ein wenig minimieren. Aber das ganze schafft leider wieder ein anderes Problem: Der Code wird manchmal etwas unübersichtlich, wegen all der Kommentare dazwischen.

Ich selber habe aber bislang eher mit einem ganz anderen Problem zu kämpfen gehabt. Alles ist getestet. Und läuft wunderbar. Man liefert aus, und es knallt. Weil nämlich der User ganz andere Angewohnheiten hat, wie man ein Programm bedienen könnte. Auf Arten, die man nie für möglich gehalten hat. Und damit natürlich auch nie abgefangen hat. DAS ist im Moment die größte Befürchtung, die ich habe.

Jan

[Tom]

@Manfred: Auf dieser Seite sind wir - dreimal auf Holz geklopft - ziemlich sicher. Meine Schulungsmitarbeiter sind "vor Ort" und wissen ganz genau, wie der überwiegende Teil unserer Kunden die Software bedient, welche Abläufe es gibt und dergleichen mehr. Tatsächlich werden die meisten Änderungs- und Ergänzungswünsche auf diesem Weg an uns herangetragen. Und ich bin recht sehr davon überzeugt , daß es wenige Stellen gibt, an der man unsere Systeme durch "einfache" Fehlbedienung zum Fehlverhalten oder gar Absturz (wohlmöglich mit Datenverlusten) bringen kann. Natürlich gibt es hier und da jemanden, der mit irgendeiner Drittsoftware in Tabellen herumzustochern versucht, aber dem haben wir auch weitgehend einen Riegel vorgeschoben.

@Jan: Wir haben es tatsächlich mal mit einem solchen Dienstleister versucht, ist aber schon ein paar Jährchen her. Der kann aber bestenfalls feststellen, daß die Software unter bestimmten Bedingungen und Umgebungen zu laufen scheint. Man liefert Testmuster und Benutzungshinweise mit, weil die Mitarbeiter dieser Dienstleister unmöglich von einer so umfangreichen vertikalen Software wissen können, wie sie im Tageseinsatz benutzt wird. Und da stirbt die Ente auch gleich wieder. Das Geld, was man spart, weil man die verschiedenen Topologien nicht nachstellen muß, hat man nicht wirklich gespart.

Ich wollte aber eher grundsätzlich darauf hinaus, wie Ihr mit Änderungen umgeht - eigenen und denjenigen, die Euch quasi "untergeschoben" wurden. Manchmal, ohne daß Ihr davon wißt.

[Martin Altmann]

Hallo Tom,
ich arbeite viel mit bedingter Compilierung bzw. globalen Variablen.
Nicht alle unsere Kunden haben das gleiche Programm - da gibt es durchaus Unterschiede. Da arbeite ich dann mit #ifdef-Anweisungen:

• Der eine will halt Postscheck als Feldbezeichnung und alle anderen bekommen da nur Scheck angezeigt.
• Oder bei einem müssen bestimmte Ausgaben auf Französisch erfolgen, bei allen anderen in Deutsch.

Mit globalen Variablen arbeite ich bei Dingen, die für mehrere nutzbar sein sollen. Z.B. die Versionsnummer! Nicht alle nutzen die letzte Version, aber bestimmte Dinge sollen nur für die nutzbar sein, die auch das letzte Update gekauft haben - da kann ich dann mittels der Versionsnummer prüfen, ob der Menüpunkt auswählbar oder das Feld nutzbar sein soll.

Viele Grüße,
Martin

[Manfred]

Hi Tom,

eine Patentlösung habe ich nicht dafür. Bauen, gucken und evtl. anpassen, wenn es Probleme gibt. Selbst wenn alles neu programmiert wird, wie das bei mir zur Zeit der Fall ist, kann ich auch nur die bekannten Probleme berücksichtigen. Alles andere ergibt sich immer mit der Zeit und der neuen Erfahrung.

Ich weiß ja nicht wie es bei Dir ausieht, aber die Vergangenheit hat gezeigt, dass jedes Programm nach ca. 2-3 Jahren immer ganz anders aussah, als zu Anfang gedacht und geplant.

Was will man da vorbereiten?

Was mir allerdings sehr zur Hilfe kommt ist die OOP. Damit lassen sich schon verdammt gute Sachen bauen.

[AUGE_OHR]

hi,

... möglicherweise zig Zusatzlibraries, vom Reportgenerator

... Selbst das Update eines Reportgenerators kann plötzlich alles lahmlegen.

Ja und es koste ZEIT wenn sowas passiert. Eigendlich bin ich davon ab
3PP Software zu nutzen wo man nicht den Source hat. Zumindest für
die "Produktion" galt das den ansonsten sind solche Tools schon sehr
hilfreicht beim erstellen einer Application.

Was den "DAU" angeht : Logbuch und alles relevante protokollieren !
Ein solcher "DAU" wird dir auf Nachfrage meisten gar keine Antwort
geben (können) was er nun gemacht hat.

gruss by OHR
Jimmy

[Tom]

Hallo, Jimmy.

Ja und es koste ZEIT wenn sowas passiert. Eigendlich bin ich davon ab 3PP Software zu nutzen wo man nicht den Source hat.

Das ist eine Abwägungssache. Wenn ich ein weit verbreitetes, leistungsfähiges und marktstarkes Tool einsetze, dann kann ich davon ausgehen, daß Bugs so gut wie umgehend gefixt werden - und ich muß mich nicht durch fremden Code quälen. Die Erfahrung zeigt auch, daß es so ist. Aber es ging mir ja nicht um diesen Fall. (L&L 13 setze ich, zum Beispiel, noch nicht in auszuliefernden Versionen ein.)

Was den "DAU" angeht : Logbuch und alles relevante protokollieren !

Ein Tip, den ich nur unterschreiben kann. Unsere Applikation protokolliert so gut wie jede datenrelevante Transaktion, und dabei natürlich auch solche, die z.B. die Löschung von Daten betreffen und ähnliche. Es gibt häufig Diskussionen an der Hotline, bei denen der Kunde behauptet, "seit dem letzten Update" (eine sehr beliebte Redewendung) wäre das und das verschwunden/geschehen. In vielen Fällen läßt sich durch das Transaktionsprotokoll dann nachweisen - und zwar in Klarschrift, auch für den Kunden erkennbar -, daß dem nicht so ist, sondern daß jemand, der dazu auch berechtigt war (es gibt ein sehr umfangreiches Rechtesystem), die entsprechende Aktion ausgelöst hat.

Aber es geht mir - siehe oben - ja nicht um Fehler, die Anwender auslösen - das haben wir ziemlich gut im Griff, denke ich. Wobei es generell, und das nur am Rande, nicht darum geht, in einer Supportsituation Schuld zuweisen zu können, sondern den Kunden möglichst umgehend in die Lage zu versetzen, weiterarbeiten zu können.

[Jan]

Wobei es generell, und das nur am Rande, nicht darum geht, in einer Supportsituation Schuld zuweisen zu können, sondern den Kunden möglichst umgehend in die Lage zu versetzen, weiterarbeiten zu können.

Wie wahr. Solche Diskussionen führen meist nur zu Ärger. Vor allem dann, wenn man dem Gegenüber am Telefon beweisen kann, daß er persönlich den Fehler gemacht hat. Wenn das ein anderer Angestellter das war, dann ist das einfacher, dann wird der Betreffenden halt "rund gemacht". Aber wenn der Anrufende selber Schuld ist, dann hinterlässt das bei demjenigen immer ein schlechtes Gefühl. Ich selber hab zwar die Telefonsupport-Schlacht "gewonnen", aber einen der Kunde ist negativ eingestimmt. Wer lässt sich schon gerne sagen, er habe einen Fehler gemacht?

Nur, der Punkt ist ja der: Wenn das Produkt ansonsten sehr gut funktioniert, dann ist die Schwelle, wegen eines "Fehlers" mal eben beim Support anzurufen, gleich viel höher. Dann sucht der User eher bei sich als an dem Programm ("das Programm muckt ja sonst auch, also wird das hier auch wieder so ein Fehler sein"). Daher ist unsere Verantwortung, ein möglichst fehlerfreies Produkt in den Markt zu bringen, aus aus dieser Sicht nur in unserem Interesse.

Aber zu dem Log: Wie macht Ihr das? Jede Eingabe wird protokolliert? JMit User, Arbeitsstation, Modul, und Daten? Das ergibt soch ein unglaubliches Logfile. Oder macht Ihr das nur bei ausgewählten Eingaben?

Jan

[Rolf Ramacher]

Hi Tom,

ein sehr brisantes und interessantes Thema was du gerade ansprichst. Diese Thematik wird sich für mich in ca. 1-2 Jahren so richtig stellen. Wir sind ein 2-Mann-Team. Und ich bin dabei unser System was auf 3 Komponenten basiert auf xbase umzustellen. Mein (Noch)-Chef - "in ca. 1-2 Jahren wenn nix dazwischen kommt werde ich den Laden übernehmmen", hat das ganze mit Clipper entwickelt und mit xbase nicht viel am Hut.

Die Programme sind beim Kunden noch mit Clipper im Einsatz, wobei
das Etikettendruckprogramm (32-bit) ist bei einem Kunden bereits im Einsatz. Die Problematik war das Drucker sehr schwer als Parallel-Anschluss zu kriegen sind und im Programm nur LPT 1-3 einzustellen sind.
Deshalb habe ich dies forciert und auch im Quellcode dokumentiert warum einige Dinge so sind, damit das Programm auch unter 16-Bit laufen kann.

Aber auch hier habe ich trotz intensiven Testen 2 kleinere Dinge übersehen und wurden aber durch den Hinweis vom Kunden schnell geändert. So ganz wird man diverse Dinge nicht direkt immer finden können.

[brandelh]

Hi,

natürlich bin ich bemüht alle Programme fehlerfrei auszuliefern.
Da meine Programme nicht ganz so umfangreich sind wie z.B. TOMs Abrechnungssystem, geht das meistens ganz gut. Hinzu kommt, dass die Hardware bei uns logischerweise recht ähnlich ist.

Dennoch sind Fehler nie auszuschließen.

Was die 'Schuld' angeht, habe ich drei Grundregeln:

1. Ein Programm darf wegen einer Fehlbedienung nicht abstürzen und muss erkennbare Fehler finden.

2. Ein Programm ist kein Hellseher um Fachkräfte zu ersetzen. Die fachliche Richtigkeit muss der Mensch übernehmen (z.B. sind das Kosten oder Einnahmen ? Stimmt die Höhe mit der Rechnung überein ?).

3. Fehler werden behoben, nicht bejammert

Als Selbständiger würde ich noch die Haftung ausschließen/begrenzen.

[Jan]

Hubert,

zwar stimmt das alles, insbesondere Dein Punkt 4. Ohne das kann heute vermutlich kein Softwareentwickler mehr überleben. Aber wenn Dein Programm zu viele Bugs hat, dann hast Du Dir auch ganz schnell Deinen Namen versaut. Die Absicherung ist also sicher Verpflichtung, aber man kann und darf sich darauf niemals ausruhen.

Und zu Deinem Punkt 2: Das hat mich schon Nerven gekostet. Die Hälfte meiner grauen Haare kommt vermutlich genau daher. Und das ist auch das, was ich weiter oben meinte. Man plant alles sauber und genial, aber dann kommt irgendso ein User und macht das ganz anders. Und es knallt. Ich bin deswegen in unserem Warenewirtschaftssystem ständig dabei, soetwas abzufangen. Entweder solche Fehleingaben zu verhindern (z. B. nur bestimmte Wertebereiche zuzulassen), oder Warnmeldungen auszugeben, wenn es etwas unlogisch erscheint.

Punkt 3 sollte immer für jeden selbstverständlich sein.

Das gehört zwar nicht ganz zu dem von Tom angeschnittenen Thema, aber zu Deinem Punkt 3: In meinem momentanen Projekt haben mein Auftraggeber und ich sowohl in den Vorbemerkungen als auch auf unserem Messestand immer wieder darauf hingewiesen, daß wir für Vorschlage immer offen sind. Denn ich bin auch der Ansicht, ein Programm entwickelt sich an den Bedürfnissen der User. Ich kann mir noch so viele geniale Sachen überlegen. Die User finden immer etwas, was die gener anders, besser, oder ergänzt hätten. Und da kann ich Punkte gut machen, wenn ich das umsetze: Der Kunde fühlt sich ernst genommen, weil ich seine Ideen einbaue. Und alle Kunden sind begeistert von der Praxisnähe der Software. Und solch zufriedene, ernst genommene Kunden werden dann bei wirklichen Fehlern auch nicht gleich mit totalem Frust melden, sondern eher wohlwollend.

Jan

[Rolf Ramacher]

Hi Jan,

deinem letzten Teil kann ich nur absolut zustimmen, daß der Kunde am Programm seine Ideen mit einbringt.

Zu erweitern wäre dies noch so. Bei meiner vorherigen Firma (ein Programm für Versicherungsmakler), war es so das viele Kunden gewisse
Abrechnungsmodule/Spezialverträge usw. hatten, die mit dem Standardprogramm gar nicht abzuwickeln waren.

Da kam ich ins Spiel, um diese Produkte mit dem Standardsystem zu verbinden. Dabei arbeítest du nur im Sinne des Kunden- dafür zahlt der ja auch extra. Wobei hier noch darauf hingewiesen werden muß, das dabei
ein "Pflichtenheft" ein absolutes muß ist. Darin stand wie der ganze Ablauf des Sondermoduls ist, wer was zu tun hat, in welches Feld was einzutragen ist inkl. Mathematik. usw.

Das hat mir bei späteren Reklamationen geholfen. -

[Markus Walter]

Wie geht Ihr mit solchen Fragen um? Wie stellt Ihr die Qualität der auszuliefernden Updates sicher, auch im Hinblick auf Drittkomponenten und ähnliches? Wie testet Ihr? Unter welchen Bedingungen? Bis zu welchem Punkt?

Hallo Tom,

ich kenne die beschriebene Problematik zu genüge (ich verfolge übrigens auch den Thread in dem von dir genannten, aber nicht verlinken Forum, da ich das Produkt ja auch einsetze).

Die genannten Probleme von Drittwerkzeugen, sind im weitesten Sinne auch mit meiner (und wahrscheinlich auch Deiner) eigenen Applikation vergleichbar. Warum sehe ich das so?
Der Entwickler hat keine (naja, wenig) Ahnung, was die Anwender mit der Software anstellen. In meinem Fall (ca. 650 Firmen, etwa 2200 Arbeitsplätze) haben viele Anwender (teilweise auch auf Rat meiner Supportmitarbeiter) Wege gefunden, unsere Software zu "mißbrauchen" um Dinge zu lösen, die vielleicht nicht vorgesehen sind. Wenn nun Änderungen von unserer Seite erfolgen (sowohl Fehlerbeseitigung, als auch Feature-Änderungen) gibt es immer wieder Anwender, die sich darüber beschweren, weil dann deren "workarounds" vielleicht nicht mehr funktionieren.
Ähnlich verhält sich das Problem mit einem Drittanbieter-Werkzeug, ja auch mit dem Entwicklungstool selbst.
Alaska, Roger, Clayton, ... können nicht alle Situationen kennen, nachstellen und testen (selbst wenn sie beliebig viel Zeit und Geld investieren könnten), die wir mit ihren Produkten "produzieren".

Das war das philosophische. Nun zum Praktischen:

Ich setze neue Versionen meiner Drittwerkzeuge (Express, List&Label), aber auch neue Versionen von Xbase (gibt es ja nicht so oft ) nur bei "großen" Updates unserer Software ein (also bei neuen Programmversionen, die auch von meiner Seite umfangreiche Änderungen enthalten und somit auch entsprechend aufwendig - natürlich nie ausreichend - getestet werden müssen). Dazu kommt, dass wir diese Updates zunächst nur einigen wenigen Anwendern zur Verfügung stellen und Erfahrungen sammeln, bevor wir diese auf die breite Maße loslassen. Somit erfolgt quasi der Test der eigenen Änderungen zusammen mit den Änderungen in den Drittwerkzeugen.
Eine bessere, bzw. praktikablere Lösung ist mir bis heute (leider) nicht eingefallen.

[Tom]

Hallo, Markus.

Wir sind im vergangenen Jahr auch zu diesem Paradigma gewechselt. Während es zuvor darum ging, Kundenwünsche möglichst umgehend zu befriedigen und neue Features möglichst rasch flächendeckend zur Verfügung zu stellen, was den Updatezyklus teilweise auf einen Tagesrhythmus eindampfte, veröffentlichen wir Updates mit neuen Featuresets (und auch neuen Drittbibliotheken) inzwischen nur noch exakt vierteljährlich. Zwischendrin gibt es Hotfixes mit unveränderter Bibliothekenbasis. Das Konzept läßt sich nicht immer halten, weil uns zuweilen Gesetzgeber oder andere Erfordernisse einen Strich durch die Rechnung machen, aber prinzipiell durchaus. Das hat sich für unseren Support wohltuend ausgewirkt. Zudem sind Hotfixes auch strukturell anders gestaltet als Updates - letztere nehmen zuweilen umfassende Strukturänderungen am Datenbestand vor und vieles andere mehr, während Hotfixes i.d.R. schlicht Patches der Laufzeitkomponenten darstellen. Wir hoffen, diese Systematik innerhalb dieses Jahres auch unterbrechungsfrei durchhalten zu können.

Major-Updates werden im Haus und mit einer ausgewählten Schar Betatester auf Herz und Nieren geprüft, aber man muß in diesem Zusammenhang ehrlich sein: Kein Kunde weiß, worauf eigentlich genau zu achten ist, und die Bereitschaft, Previews in einer realen Produktionsumgebung einzusetzen, ist verstehbarerweise gering, zumal es um sensible Daten und manchmal lebenssichernde Vorgänge geht (aus der Sicht der Kunden unserer Kunden). Insofern hat das Feedback der Betatester einen geringeren Wert, als es haben könnte und sollte. Ähnlich geht es mir (als Entwickler) aber auch im Umgang mit Drittbibliotheken. Viele Hersteller bieten ja an, Betatests mitzumachen (auch Alaska übrigens), aber ich bin ganz ehrlich: Wenn ich nicht gezwungen werde, mitzumachen, spare ich mir den durchaus monströsen Aufwand. Das ist möglicherweise eine Fehlentscheidung, denn wenn ein Produkt aus der Betaphase heraus ist und ich einen Fehler entdecke, bin ich in einer schlechteren Position, als ich das vorher gewesen wäre, im Betatest. Ich überlege, mich in diesem Bereich intensiver zu betätigen.

Ansonsten wird die Codebasis jedes Releases (ob Hotfix oder Update) ausdokumentiert weggesichert. Wir testen mit Dutzenden Beispieldatenbeständen und auf mehreren verschiedenen Systemen, was die Hardwaretopologie anbetrifft. Im Prinzip müßte man allerdings jede Codeänderung (also auch kleinere Korrekturen, die nicht an Kunden kommuniziert werden) mit ihren etwaigen Auswirkungen dokumentieren und unter möglichst vielen Bedingungen testen. Die Komplexität der Software macht das außerordentlich schwierig.

[brandelh]

Ja die Komplexität ... wenn eine Person nicht mehr ausreicht um das Ganze zu überblicken ...

Bei einer Sitzung (ich war damals noch nicht lange im Betrieb) kamen alte Programme zur Sprache, die angepaßt werden müssten ...

EDV: die Programmiererin die das gemacht hat ist vor 5 Jahren in Rente, der Fachbereich möge doch sagen was man wo braucht.

Fachbereich: der Mitarbeiter der noch wußte was das Programm macht, ist vor 10 Jahren in Rente, seither wird es zwar genutzt, aber was es warum mit den Daten macht weiß keiner mehr.

EDV: aus unserer Dokumentation läßt sich das nicht nachvollziehen ...
(ich vermute es gab keine )

[Markus Walter]

Hallo, Markus.

Major-Updates werden im Haus und mit einer ausgewählten Schar Betatester auf Herz und Nieren geprüft, aber man muß in diesem Zusammenhang ehrlich sein: Kein Kunde weiß, worauf eigentlich genau zu achten ist, und die Bereitschaft, Previews in einer realen Produktionsumgebung einzusetzen, ist verstehbarerweise gering, zumal es um sensible Daten und manchmal lebenssichernde Vorgänge geht (aus der Sicht der Kunden unserer Kunden). Insofern hat das Feedback der Betatester einen geringeren Wert, als es haben könnte und sollte.

Man findet in der Tat in der Regel wenige Anwender, die sich *freiwillig* als Betatester zur Verfügung stellen. Zwangsläufig werden es die ersten, die das Update bekommen *unfreiwillig*

Ähnlich geht es mir (als Entwickler) aber auch im Umgang mit Drittbibliotheken. Viele Hersteller bieten ja an, Betatests mitzumachen (auch Alaska übrigens), aber ich bin ganz ehrlich: Wenn ich nicht gezwungen werde, mitzumachen, spare ich mir den durchaus monströsen Aufwand. Das ist möglicherweise eine Fehlentscheidung, denn wenn ein Produkt aus der Betaphase heraus ist und ich einen Fehler entdecke, bin ich in einer schlechteren Position, als ich das vorher gewesen wäre, im Betatest. Ich überlege, mich in diesem Bereich intensiver zu betätigen.

Das nehme ich mir auch immer wieder vor, aber meist scheitert es aus Zeitgründen. Und dazu kommt, dass es ist wie immer beim Testen: Die Sachen, die man testet funktionieren, es kracht (fast) immer erst beim Realworld-Szenario.

Ansonsten wird die Codebasis jedes Releases (ob Hotfix oder Update) ausdokumentiert weggesichert. Wir testen mit Dutzenden Beispieldatenbeständen und auf mehreren verschiedenen Systemen, was die Hardwaretopologie anbetrifft. Im Prinzip müßte man allerdings jede Codeänderung (also auch kleinere Korrekturen, die nicht an Kunden kommuniziert werden) mit ihren etwaigen Auswirkungen dokumentieren und unter möglichst vielen Bedingungen testen. Die Komplexität der Software macht das außerordentlich schwierig.

Das sehe ich auch so.

Alles nicht so einfach....

[Jan]

Tom hat folgendes geschrieben:

Ansonsten wird die Codebasis jedes Releases (ob Hotfix oder Update) ausdokumentiert weggesichert. Wir testen mit Dutzenden Beispieldatenbeständen und auf mehreren verschiedenen Systemen, was die Hardwaretopologie anbetrifft. Im Prinzip müßte man allerdings jede Codeänderung (also auch kleinere Korrekturen, die nicht an Kunden kommuniziert werden) mit ihren etwaigen Auswirkungen dokumentieren und unter möglichst vielen Bedingungen testen. Die Komplexität der Software macht das außerordentlich schwierig.

Das sehe ich auch so.

Ja, das dokumentieren. Wie oben gesagt, ich versuche das mehr und mehr zu machen (und mache den Code damit dann manchmal etwas unübersichtlicher). Und doch lese ich manchmal "älteren" Code und verstehe nicht mehr, warum ich das damals so gemacht habe. Wieder etwas, wo ich intensiver dokumentieren muß...

Zum Testen von Hotfixes: Wie macht Ihr das? Alaska z. B. sagt ja ganz offen, daß Hotfixes nicht so tiefgehend geprüft werden wie richtige Releases. Ich muß gestehen, daß ich bislang persönlich noch keinen Unterschied in der Qualität bemerkt habe. Aber offiziell ist es bei denen so. Wäre das Beispiel von Alaska in der Praxis mit dem Endanwender ein gangbarer Weg?

@Hubert: Genau das war ja auch das Problem vor 10 Jahren. Viele Millionen Codezeilen in Cobol mussten Jahr-2000-fest gemacht werden. Tausende von pensionierten Cobol-Programmierern wurden aus der Rente geholt. Inkl. der dazu notwendigen Schulungen, um da überhaupt wieder richtig reinzukommen.

Jan

[Markus Walter]

Hi Jan,

ich will und kann die "kleineren" Updates bei uns nicht Hotfix nennen, denn sie sind es nicht. Sie enthalten oft auch Funktionaländerungen/-verbesserungen. Aber eben im kleinen Rahmen (z. B. ohne Änderungen der Datenstruktur).

Uns werden allerdings oft (durch externern Zwang, z. B. Schnittstellen, oder internen Zwang, Stichwort Vertrieb), Funktionaländerungen/-erweiterungen auferlegt, die nicht bis zum nächsten "großen" Update warten können.

Für diese "großen" Updates haben wir auch keine festen Termine (so wie Tom das macht), sondern diese gehen raus, wenn die festgelegten neuen Funktionen fertig sind (das hat beim letzten Mal 2 Jahre gedauert - um so größer und häufiger waren die "kleinen" Updates dazwischen, weil eben vieles "zwischendurch" gemacht werden sollte/musste, was nicht warten konnte, bis das große Update fertig war. Mit all den negativen Auswirkungen: doppeltes Programmieren der Änderungen, die auch noch in der "alten" Version gemacht werden mussten, doppeltem Testaufwand, ... Aber so läuft's Business...)


Bei den "kleineren" Updates findet ein Test in erster Linie derart statt, dass genau die definierten Änderungen getestet werden. Bei den "großen" Updates ist häufig aufgrund der tieferen Funktionaländerungen ein weiter gefasster Testansatz notwendig.


Grundsätzlich erspare ich mir aber in diesen "kleinen" Updates auch noch neue Versionen meiner Entwicklungswerkzeuge rauszugeben, um wenigstens diese zusätzlichen Probleme zu vermeiden. Aber auch das ging in diesem letzten, längeren Zeitraum nicht. Mit Xbase 1.82 hatte ich Probleme mit DualCore-Rechnern, deswegen musste ich auf 1.9.331 gehen. Damit hatte ich bei manchen Rechnern Probleme mit 100%-Systemlast. Deswegen bin ich auf build 337 gegangen. Damit sind diese Probleme weg, aber neue da...

Aber ich glaube, dass ist alles eine "never ending story"...

[brandelh]

Hi,

wo hast du denn den 1.90.337 her ?

Sind das die Hotfixes oder ist das eine 'Spezialzusammenstellung' für dich ?

[Markus Walter]

wo hast du denn den 1.90.337 her ?

von Alaska, woher sonst...

Sind das die Hotfixes oder ist das eine 'Spezialzusammenstellung' für dich ?

Das sind nicht die Hotfixe, sondern das was als ServiceLevel kommen soll(te). Allerdings datieren die DLLs auf Anfang September 07, den ServiceLevel gibt es aber noch immer nicht. Deshalb gehe ich davon aus, dass dieser eher einen höheren build haben wird.
Bekommen habe ich diesen build, wegen meinem Systemlast-Problem (welches ich ja schon oft lautstark beschrieben habe, z. B. auf der Devcon. Manche können es bestimmt nicht mehr hören... )

[AUGE_OHR]

hi,

Aber zu dem Log: Wie macht Ihr das? Jede Eingabe wird protokolliert? JMit User, Arbeitsstation, Modul, und Daten? Das ergibt soch ein unglaubliches Logfile. Oder macht Ihr das nur bei ausgewählten Eingaben?

JA das Logfile ist täglich die grösste Datei.

Ich logge alles was mit NEW, EDIT, DEL zusammenhängt ausführlich.

Dazu kommen dann evtl. "Break Points" die ich "beobachte" wenn der
User meint das Programm würde sich an der Stelle so und so verhalten.
Nur so komme ich "dahinter" was der "DAU" nun an der Stelle macht
und kann die dann "erweitern" und "absichern".

gruss by OHR
Jimmy

[Koverhage]

Tom,

auch ich verfolge die "andere" Diskussion, muss aber zugeben das ich (aufgrund der Sprache) nicht alles verstehe.

Bei uns läuft es wie folgt:

Wenn ein Kunde ein Update unbedingt braucht, bekommt er das. Dieses haben wir getestet (mehr oder weniger). Wie Du schon sagst, eben auf unserer Hardware was nicht zwangsläufig beim Kunden auch so laufen muss.
Also ist auch der Kunde immer zwangsläufig auch Tester.

Was sich bei uns bewährt hat: Der Ausgangscode ist erstmal für alle Anwender gleich. Über defines werden spezielle Sachen für den jeweiligen Kunden gesteuert. Dies hat ganz klar den Nachteil, das wie für jeden Kunden
einen Programmstand haben und jeder Kunde sein "eigenes Update" bekommen muss.
Hat aber den Vorteil, ich habe bei jedem Kunden die Kontrolle, wann was gemacht wurde und ich kann feste Dinge einbauen, die es dem Kunden schwerer machen, die Software weiterzugeben, etc.

So ca. alle 6 Monate bekommen alle Kunden ein Update.

Bei den eingesetzten externen Tools wird es natürlich schwieriger, grad auch im Hinblick auf die sprachlichen Barrieren.