Backup keine große Hilfe

  • Man kann und wird die gesamte Anwendung, also jede Funktion, durchtesten, davon gehe ich jedenfalls aus,

    Das mag deine Wunschvorstellung sein, aber in der Praxis ist das einfach nicht realisierbar. Sonst würde es wahrscheinlich nur alle paar Jahre ein Update geben und selbst dann wäre dieses nicht fehlerfrei. Und mit 1000 QS-Mitarbeitern dürfte sich die Entwicklung einer derartigen Anwendung nicht mehr rechnen. Es gibt einfach zu viele Abhängigkeiten, die sich einfach nicht alle testen lassen. Somit muss man sich auf die wichtigsten Komponenten konzentrieren.

  • Das mag deine Wunschvorstellung sein

    Da habe ich mich vielleicht etwas unklar ausgedrückt, ich schrieb ja explizit dazu "jede Funktion" (daß eine Funktion an sich überhaupt nicht getestet wird, kann ich mir schwerlich vorstellen). Daß es auch innerhalb einer SW (Fehler verursachende) Abhängigkeiten geben kann, ist mir natürlich klar. ;)

  • Man kann und wird die gesamte Anwendung, also jede Funktion, durchtesten, davon gehe ich jedenfalls aus, denn Buhl ist keine kleine Dorfschmiede ...

    Ich sehe das ähnlich wie Du und muss damit Sven leidr widersprechen. Ich würde sogar sagen, man sollte die gesamte Anwendung testen und wenn, wie im Falle von MG, scheinbar derart viele Abhängigkeiten zwischen den einzelnen Funktionen existieren und man sich nie sicher sein kann, dass wenn man an der einen Schraube gedreht hat, eine Andere, vermeintlich nicht betroffene Schraube, plötzlich Probleme macht, dann muss man sogar die gesamte Anwendung testen. Andernfalls erhält man Bananensoftware, die erst beim Kunden reift.


    Darüber hinaus hast du auch ein PreRelease installiert

    Aber ja nur notgedrungen. Jeder rät/empfiehlt es einem ja. Aus welchem Grund? Doch eigentlich, weil man sich von einem Patch einen zuverlässigeren Stand verspricht. Sowohl Billy als auch der Support von Buhl haben mir als allererstes vorgeschlagen die aktuelle Version zu installieren. Und das war nun mal dieses PreRelease.
    Billy trifft keine Schuld. Er ist Forumsmoderator und will nur mit seinen Mitteln helfen. Aber vom Support hätte ich mir eigentlich gewünscht, dass sie zunächst prüfen, ob sie den Fehler in meiner Version reproduziert bekommen. Wenn ja, dann schauen ob der Fehler im PreRelease bereits behoben ist und nur dann die Installation einer Vorabversion empfehlen. Sollte der Fehler auch noch im PreRelease existieren könnte man dieses direkt zum Anlass nehmen den Fehler dort zu fixen oder den Kunden über einen anderen Zeitpunkt der Fehlerbehebung informieren.
    Ich will damit sagen: Es scheint ja schon eine gewisse Erwartung (auch beim Hersteller) zu existieren, dass neuere Versionen ausgereifter sind. Und meine Beobachtung ist, dass hier Theorie und Wirklich auseinanderklaffen.



    Viele Fehler werden aber auch eher durch Zufall entdeckt, weil die Anwendung eben sehr unterschiedlich genutzt wird. So kann es z. B. sein, dass ein Anwender von den Fehlern überhaupt nicht betroffen ist und du eben gleich einmal auf mehrere Fehler triffst.

    Nun ja, Du hast ja selber geschrieben, dass der Fehler bereits bekannt ist - und das in einem PreRelease, dass noch nicht veröffentlicht ist?! So zufällig kann die Entdeckung folglich nicht gewesen sein. Auch das Thema der Abstürze (aus welchen vermeintlichen Gründen auch immer) wird in diesem Forum heiß diskutiert. Damit scheine ich also auch nicht alleine zu sein. Und auch das Thema der online Schnellerfassung wurde zunächst dem Anwender zugeschoben: (Zitat aus: Online-Schnellerfassung-reaktivieren)


    Nein, Du machst etwas unbewußt falsch. Von alleine wird da nichts verloren.

    Billy: Bitte nicht persönlich nehmen. Passt an dieser Stelle gerade nur sehr gut.


    Schnell wurde aber klar, das anderl1969 mit seinem Problem nicht alleine da ist. Haben zufällig mehrere Anwender den gleichen Fehler gemacht wodurch die Online Schnellerfassung auf einmal deaktiviert wurde? Wohl kaum. Ich kann mir folglich nicht vorstellen, dass ich tatsächlich zu den einigen wenigen Anwendern gehöre, die von einem derartigen Pech verfolgt sind. Ich glaube viel mehr, dass viele Anwender von diesem Pech betroffen sind, sich davon aber nur einige wenige wirklich über dieses Forum oder den Support melden. Und daher sollte man als Softwarehersteller sehr sensibel auf Kundenrückmeldungen reagieren und die eigenen, internen Prozesse hinterfragen und Optimierungen anstreben. Vielleicht macht buhl das, ich als Anwender jedenfalls kriege davon bislang nichts mit.


    Wir kommen jedoch immer weiter von meinem eigentlichen Anliegen des Ursprungsbeitrages ab. Und deshalb bin ich entejens sehr dankbar für seinen konstruktiven Vorschlag, der sich wieder direkt mit dem Backup Problem beschäftigt:


    Hast Du die Möglichkeit, MG in genau der Version wie die jetzige auf einem anderen Rechner (oder, falls technisch möglich, in einer virtuellen Umgebung) zu installieren? Das kann Dir Hinweise dazu geben, ob es am Rechner bzw. der darauf installierten Software (eventuell auch schon wieder deinstalliert) liegen könnte.

    Theoretisch habe ich die Möglichkeit. Mal sehen, ob ich das zeitlich eingerichtet bekomme. Dann wäre es aber nicht mehr W7 sondern W10. Ob das dann noch so vergleichbar ist???



    Hast Du eventuell relativ zeitnah, bevor der erste Absturz erfolgte, eine andere Software installiert?

    Nein

  • upps, da gab es ja noch zwei Beiträge während ich meinen letzten Beitrag verfasst haben :)

    Das mag deine Wunschvorstellung sein, aber in der Praxis ist das einfach nicht realisierbar. Sonst würde es wahrscheinlich nur alle paar Jahre ein Update geben und selbst dann wäre dieses nicht fehlerfrei. Und mit 1000 QS-Mitarbeitern dürfte sich die Entwicklung einer derartigen Anwendung nicht mehr rechnen. Es gibt einfach zu viele Abhängigkeiten, die sich einfach nicht alle testen lassen. Somit muss man sich auf die wichtigsten Komponenten konzentrieren.

    Eine vollständige Pfadabdeckung wird man sicherlich nicht erreichen können. Aber durch ein geschicktes Testmanagement kann man mit relativ überschaubarem Aufwand eine große Wirkung erzielen. Und wenn dann die wichtigsten Funktionen durch Automatentests (und da meine ich jetzt keine von Entwicklern geschriebenen Whiteboxtests durch JUnit o.ä.) und weniger wichtige Funktionen durch manuelle Testcases beschrieben sind und durchgeführt werden, dann erreicht man schon eine gute Qualität.
    Und im Zweifel, wenn man den hohen Automatisierungsgrad nicht hat, kann man halt nicht so viele Releases im Jahr verteilen. Dafür dann aber qualitätsgesicherte.

  • jede Funktion

    Die Begrifflichkeit ist sehr dehnbar. Die geht bei mir vom einfachen Öffnen eines Programmbereiches bis hin zum korrekten Editieren oder Anzeigen eines Eintrages an einer bestimmten Stelle.


    man sollte die gesamte Anwendung testen

    Wie bereits geschrieben, ist so etwas aus zeitlichen und finanziellen Gründen einfach nicht machbar. Sonst wäre die Software nicht bezahlbar.

    weil man sich von einem Patch einen zuverlässigeren Stand verspricht.

    Sofern es sich im ein PreRelease handelt, sehe ich das nicht so, vielleicht wird es aber nicht eindeutig kommuniziert. Sicherlich besteht die Möglichkeit das ein bestehendes Problem behoben wird, aber nichtsdestotrotz ist es ein PreRelease, welches immer noch ein höheres Risiko besitzt weitere bzw. andere Fehler zu enthalten. Daher muss man eben abwägen, ob man es installiert oder nicht.

    Sollte der Fehler auch noch im PreRelease existieren könnte man dieses direkt zum Anlass nehmen den Fehler dort zu fixen oder den Kunden über einen anderen Zeitpunkt der Fehlerbehebung informieren.

    Ein PreRelease wird nicht sofort bei Auftreten eines Fehler neu erstellt. Auch hier werden erst alle Rückmeldungen innerhalb eines Zeitraumes ausgewertet und nur bei schwerwiegenden Fehlern sofort reagiert.

  • Die Begrifflichkeit ist sehr dehnbar. Die geht bei mir vom einfachen Öffnen eines Programmbereiches bis hin zum korrekten Editieren oder Anzeigen eines Eintrages an einer bestimmten Stelle.

    Für mich ist das nicht dehnbar, denn jede neue Funktion sollte getestet sein, alles andere würde einem vernünftigen QS widersprechen. Es sollte für jede Funktion Testfälle geben, die auch die Abhängigkeiten der Funktion beinhalten.


    Ich würde Prereleases grundsätzlich nicht auf "produktiven Systemen" einsetzen.


    P.S. Wir sollten das Thema "Funktion testen" nicht weiter ausdehnen, es hat ja nix mit dem Problem zu tun ... ^^

    • Offizieller Beitrag

    Wir kommen jedoch immer weiter von meinem eigentlichen Anliegen des Ursprungsbeitrages ab.

    Das ging schon viel früher los, als diskutiert wurde, warum man Frust hat oder nicht. Deshalb ist das Thema für mich auch durch (hatten wir alles schon x mal).

  • Deshalb ist das Thema für mich auch durch (hatten wir alles schon x mal).

    Das stimmt. Das Thema, wie Buhl testen soll, ist hier im Forum schon zig mal diskutiert wurden. Im Grunde bringt das aber wenig, wobei hier in diesem Thread einige dabei sind, die zumindest etwas besser Bescheid wissen, was das Testen einer Software angeht, da einige Aussagen vollkommen richtig sind. Wie an anderer Stelle erwähnt, arbeite ich genau in diesem Bereich, allerdings teste ich noch komplexere Software als diese hier. Wobei hier auch schon ein ganz netter Funktionsumfang vorhanden ist. Für den Durchschnittsanwender gibt es nach meiner Auffassung Grundregeln zu beachten. Wenn diese eingehalten werden, dann kommt man mit vielen Software klar:


    - Keine PreRelease installieren (es sei denn, man möchte als Vorabtester fungieren und nimmt neue bzw. unendeckte Fehler in Kauf).
    - Ist man von einem Fehler betroffen, dann gibt es sehr oft Workarounds, die man übergangsweise bis zur Fehlerbehbung anwenden kann, ohne immer gleich ein PreRelease (das unter Umständen noch fehleranfälliger ist) zu intallieren (freiwillige Vorabtester ausgenommen). Beim finden eine solchen Workaraund ist der Support oder das Forum ja sehr hilfreich.
    - Das Betriebsystem sollte gut gepflegt werden. Dazu sollte man an dem Rechner, an dem man produktiv ist, nur die nötige Software installieren, die man auch benötigt. Dann sollte auch immer mal wieder der PC bereinigt werden.
    Auch ist es ratsam, Wiederherstellungspunkte zu erstellen, bei dem eine Rechnerkonfiguration gut gelaufen ist, falls mal eine Installation (nicht nur bei MG) schief gelaufen ist.


    Mit diesen wenigen Regeln bin ich mit MG.Net immer zurecht gekommen. Auch am Anfang mit groberen Abstürzen. Die gibt es bei mir aber nicht mehr.


    Und vielleicht noch ein paar Hintergrundinfos zum Testen einer Software:


    Es ist fakt, dass eine Software immer Fehler hat. Die Frage ist nur, wieviele werden im laufenden Betrieb durch die Anwender entdeckt und wie schwerwiegend sie sind. Aus Kostengründen werden vermutlich die Hersteller sich beim Testen immer nur darauf aus sein, das Testen so gestalten, das schwerwiegende Fehler im Betrieb überwiegend nicht auftreten. Die Frage ist, wie viel investiert man in die Tests. Wie ist die Testabdeckung der Software. Eine Gesamtabdeckung dieser Größe wie bei MG bekommt man nie hin.


    Ich habe keine Ahnung wie Buhl ihre Testabteilung aufgebaut hat. Es kommt natürlich darauf an, welche Testverfahren man anwendet und wie die Aufteilung von automatisierten Test und manuellen Tests ist. Immer ein wenig zu kurz kommt (auch hier im Thread) auch, dass man nicht nur einen Funktionstest machen muss, sondern das Fehler auch datenspezifisch auftreten können. Diese Vielfalt/Kombinationen kann der beste Hersteller leider nicht abdecken. Schon gar nicht bei Standardsoftware und bei den Preisen, die bei MG sind.


    Auch gibt es verschiedene grundsätzliche Vorgehen bei der Softwareentwicklung.
    Eine Variante ist z.B. die Software mit dem definierten Funktionsumfang zu entwickeln und dann zu lieferen. Es werden nachfolgend nur noch Fehlerbehebungen oder kleinere unbedeutende Neuereungen entwickelt. Vorteile => die Software wird mit der Zeit immer stabiler und kaum neue Fehler kommen in bestehende Funktionen rein. Nachteil => die Software entwickelt sich kaum weiter, bis wieder eine komplett neue Version aufgesetzt wird. Die Fehlerbehebung kostete aber trotzdem und muss über die Pflegekosten abgedeckt werden.


    Andere Varainte (und ich glaube dass macht Buhl in Zukunft so, wenn ich es richtig mit bekommen habe): Neue Version wird entwickelt. Der Funktionsumfang steht noch nicht fest und es wird offen gelassen, wie sich die Software entwickelt wird. Mit den Updates kommen sowohl Fehlerbehebungen und auch größere Neuerungen. Vorteil => die Software entwickelt sich ständig weiter. Nachteil => manche Neuerungen bringen in Teilen der Software wieder Fehler und eventeull auch unstabieles Verhalten rein. Funktionen, die schon fehlerfrei gelaufen sind, haben plötzlich wieder Probleme.


    Meiner Meinung nach ist das glaube ich, der Kernpunkt dieser Diskussion, warum (öfters Altanwender) einige etwas gefrustet sind. Wenn man aber die Realität anschaut, dann ist die letztere die aktuell gängigere Entwicklungsstrategie. Und es sollte nicht vergessen werden, dass zum Teil die Kunden auch den Druck auf die Softwarehersteller ausüben, damit immer wieder neue Funktionen und Weiterentwicklungen passieren. Früher war das in diesem Tempo nicht der Fall. Ich bin, obwohl ich mich in dieser Materie auskenne, nicht immer bereit auf diese Entwicklungsschnelligkeit aufzuspringen. Das hat auch gewisse Nachteile. Da leidet auch die Qualität zwangsläufig darunter. Das sollte man wissen. Und wenn man das weiß, dann hat man als Anwender auch die Möglichkeit richtig zu reagieren und man sucht sich das raus, was für einen der richtige Weg ist.


    Einen Zweitrechner zum Testen ist nie verkehrt. Nur so kann man erkennen, ob das Betriebssystem/Hardware die Fehlerquellen ist oder die entwprechende Software ein Fehler hat.


    Wenn MG instabil läuft (häufige Abstürze), dann liegt es fast immer an Betriebsytem / Hardware oder verstellten Einstellungen. Und da kann dann nur der Support weiterhelfen, auch wenn diese Art von Probleme ägerlich sind. Das sind aber auch die schwierigsten zu lösen, weil sie so unterschiedliche Ursachen haben können. Wer aber die gewissen Grundregeln beherscht, der wird definitiv weniger Probleme haben. Dazu gehört auch, dass Software, die mit neuen Technologien entwickelt werden, nicht auf 10 oder 15 Jahren alten Rechnern reibungslos oder performant laufen.

  • Deine Tipps bzg. der "Rechnerpflege" sind ja grundlegend erst einmal richtig. Aber man sollte eben auch grundsätzlich darauf hinweisen, dass es, nicht ohne Grund, unterschiedliche berechtigte Nutzerprofile gibt. Gearbeitet werden kann mit einem Userprofil. Nur, und wirklich nur zum Installieren benötigt man Admin-Rechte.
    Dir ist aber auch bewusst, dass gerade die Anwender, die bestimmte Probleme mit MG gemeldet haben, eine Information vom Hersteller Buhl bekommen, dass gemeldete Problem mit dem PreRelease xyz laut Link behoben sind (sein sollen). Da wird der Hersteller bestimmt nicht bewusst das Risiko eingehen, diese Betroffenen Anwender mit weiteren Bugs zu verärgern.
    Grundsätzlich gilt natürlich, wie quasi bei jeder Software, " never touch a running system". Aber auch "große Hersteller" wie MS machen das ja regelmäßig ...


    Falk

  • Deine Tipps bzg. der "Rechnerpflege" sind ja grundlegend erst einmal richtig. Aber man sollte eben auch grundsätzlich darauf hinweisen, dass es, nicht ohne Grund, unterschiedliche berechtigte Nutzerprofile gibt. Gearbeitet werden kann mit einem Userprofil. Nur, und wirklich nur zum Installieren benötigt man Admin-Rechte.

    Das ist mir durchaus bewusst. Die Rechte- und Nutzerprofile habe ich hier nicht eindeutig erwähnt. Das hatte ich aber auch gemeint mit den verschiedenen Einstellungen im Betriebsystem. Vielleicht nicht klar formuliert. Die Profile können ntürlich sehr oft auch die Probleme verursachen, wenn das nicht richtig gemacht wird (hier hatte ich aber noch nie gravierende Probleme gehabt, dass ich zwingend ein PreRelease ziehen musste). Aber ich denke sehr viele arbeiten mit den voreingestellten Standardprofilen. Oder sogar nur mit einem.

  • Eben. Und das hat im Regelfall Adminrechte und damit öffnet man natürlich diverser, unerwünschter SW Tür und Tor. Niemand würde mit einem Unix - basierenden System (AT&T, Linuxe und BSD und, und ... => und ja ich kenne grob den Aufbau des Windows) so (SUDO lässt grüssen) dauerhaft und auch noch mit Netzwerkanbindung arbeiten.


    Falk

  • Wenn MG instabil läuft (häufige Abstürze), dann liegt es fast immer an Betriebsytem / Hardware oder verstellten Einstellungen.

    irgendwie kommt mir das bekannt vor:


    Zitat

    Ich würde meinen PC mal einem Stresstest unterziehen und nicht gleich alles auf die Softwareschmiede abwälzen.