Geschriebene SW testen



  • Du musst die psyhologische Schwelle überwinden, deine eigene SW fehlerhaft aussehen zu lassen.



  • zykosomatik schrieb:

    Du musst die psyhologische Schwelle überwinden, deine eigene SW fehlerhaft aussehen zu lassen.

    Drauf scheißen dass Fehler in der von mir geschriebenen SW sind?



  • Vielleicht meint er auch aus dem Fehler ein Feature zu machen?



  • sdf_fds schrieb:

    +Dann von jemand drittem testen lassen (sofern ein Tester vorhanden ist...)

    Du hast doch geschrieben, dass du in einer Firma als Entwickler arbeitest. Also gibt es auch Tester. Oder ist das eine Einmannfirma?



  • Bashar schrieb:

    sdf_fds schrieb:

    +Dann von jemand drittem testen lassen (sofern ein Tester vorhanden ist...)

    Du hast doch geschrieben, dass du in einer Firma als Entwickler arbeitest. Also gibt es auch Tester. Oder ist das eine Einmannfirma?

    Wir sind ca. 10 Entwickler, leider viel zu wenig Tester.
    Einer der Entwickler arbeitet etwa 50% der Zeit als Tester, und ein Projektleiter testet auch etwa 50% von seiner Zeit. Die anderen Projektleiter testen nur ganz am Ende, vor der Auslieferung, wo es dann meist schon etwas gar spät ist.

    Fein wäre natürlich ein Tester, dem nach der Entwicklung und den eigenen Tests die SW übergibt, der dann drauf los testet, aber das gibts in der Form leider nicht.
    Daher eben mein Wunsch, bereits selber möglichst viele der logischen Fehler zu eliminieren.



  • berniebutt schrieb:

    HighendCoder schrieb:

    Warum schreibt ihr nicht gleich fehlerfreie Software?

    Wenn so so leicht wäre ... :p Ist es aber leider nicht, weil im realen Leben vorhandenes benutzt werden muss - und das ist auch nicht völlig fehlerfrei!

    Eben, schreibt gleich fehlerfreie Software.



  • sdf_fds schrieb:

    Danke für die Antworten.

    Ich teste meine SW meist so, wie es vom Kunden gewünscht ist. Klickt er Taste x, so wird y dargestellt. Das klappt dann auch immer.
    Aber Kunden schaffen es, die SW dann komplett anders zu bedienen, so dass letztlich ein Fehler auftritt. Ich finde es echt schwierig, als Entwickler überhaupt auf solche Ideen zu kommen, wie dämlich man die SW bedienen kann.

    Dann liegt es am falschen Design eurer Software. Software sollte intuitiv zu bedienen sein, damit die Kunden erst gar nicht auf die Idee kommen, sie falsch zu bedienen.



  • sdf_fds schrieb:

    Fein wäre natürlich ein Tester, dem nach der Entwicklung und den eigenen Tests die SW übergibt, der dann drauf los testet, aber das gibts in der Form leider nicht. Daher eben mein Wunsch, bereits selber möglichst viele der logischen Fehler zu eliminieren.

    Richtig, der Entwickler kann vieles und muss alles tun, um höchstmögliche Fehlerfreiheit zu erzielen! Aber wie hier mehrfach gesagt, bleiben immer irgendwelche Fehlerquellen, vor allem in komplexen Systemen (Software, Hardware und Anwender). Fatal, wenn der Entwickler darauf keinen Einfluss hat oder die Fehler selten auftreten.

    Ein Beispiel: Software für eine Walzstrasse im Stahlwerk. Der Entwickler hat seine Programme fehlerfrei geliefert. In den Steuersystemen der Walzen tritt ein Aussetzer oder eine Verzögerung ein. Ergebnis: die Bleche sind 0.1 mm zu dünn oder zu dick. Ein riesiger Schaden, die gewalzten Bleche sind Schrott und der Kunde nimmt diese nicht ab.



  • Na ja, Fehlerfreiheit ist eine Frage der Wirtschaftlichkeit und der Branche. Im Industriebereich ist Fehlerfreiheit extrem wichtig, weil der Schaden sonst riesig wäre. Endkunden verzeihen hingegen deutlich mehr, wenn z.B. bei iTunes der Import nicht klappt, wenn man vorher dies und das gemacht hat oder nach Ausschneiden einer Zeile in Visualstudio diese im Nirvana verschwunden ist, wenn man in der Nähe eine Zeile mit Strg+L löscht...



  • sdf_fds schrieb:

    Ich finde es echt schwierig, als Entwickler überhaupt auf solche Ideen zu kommen, wie dämlich man die SW bedienen kann.

    Wenn man mal von den handwerklichen Umsetzungsmängeln absieht, lassen sich fast alle Softwarefehler darauf zurückführen, dass die SW Situationen ausgesetzt war, an die der Entwickler nicht gedacht hat:

    Unübliche Eingaben,

    Probleme bei Arbeiten mit Massenspeichern,

    Durchschnittswert von 0 Messwerten,

    2 Feiertage, die auf den gleichen Tag fallen,

    zwei Kunden mit gleichem Namen,

    ...

    Gerade hier habe ich meine Zweifel, dass hier Test-Tools helfen. So etwas lässt sich eigentlich nur im Code-Review oder schon bei Requirement Management bekämpfen. Und hier kommt es stark auf das fachliche Know-How und die handwerklichen Fähigkeiten der Beteiligten an.

    Ciao, Allesquatsch



  • Imo kann man auf Fehlerfreiheit sowieso nicht testen. Das einzige was man mit einem Test abbilden kann ist die funktionale Korrektheit für die gegebenen Eingabewerte. So haben mir das jedenfalls die Tester bei uns hier im Haus erklärt. Erscheint mir aber auch logisch. Wenn ein Anwender Murks bei der Bedienung macht, unwissentlich oder wissentlich, oder sich irgendwelche Daten wegen Laufzeiten in Maschinen (sehr schönes Beispiel von oben) verzögern, erweitert sich natürlich der Eingaberaum bis ins unendliche. Das kann dann keiner mehr in einer Zeit x testen ohne das Budget zu sprengen.

    Was jedenfalls derber Mist ist ist wenn ein Programmierer seinen eigenen Module testen soll. Da wird automatisch schon einiges an "Betriebsblindheit" erreicht.
    Code - Reviews sollten sowieso Pflischt sein.

    Wenn man natürlich das Glück hat ein super Spezifikation zu haben, die wirklich 99% der Fehlerfälle von vorne herein abdeckt, ist man natürlich fein raus. Aber die Dinger sind doch eher selten anzutreffen.



  • Nein, man kann weitaus mehr testen. Dann ergibt sich aber sehr schnell ein eigenständiges Projekt ´TEST´, das ein eigenes Budget erfordert, weil viel Manpower, Wissen und oft auch eigenständige Testsoftware erforderlich wird. Die Möglichkeiten manueller Tests sind begrenzt auf das, was vom Entwickler ohnehin gemacht werden sollte.

    Ein solcher Testaufwand hängt allein von der möglichen Schadenshöhe im Fehlerfall und dessen Wahrscheinlichkeit ab. Die Autoren Sneed, Baumgartner, Seidl haben das in ihrem Buch ´Der Systemtest´ sehr gut beschrieben. Auch sie sagen, dass 100% Fehlerfreiheit nicht erzielbar ist.

    Man muss Software-Hardware-Anwender-Dienste als eine komplexe menschgemachte und gesteuerte Maschine begreifen. Dann wird einsichtig: Die Maschine kann nicht jederzeit unter allen Bedingungen vollständig fehlerfrei laufen, weil Menschen eben Fehler machen.

    Ich möchte mich hiermit aus dieser Diskussion verabschieden. 🙂



  • der trick ist, den code so zu strukturieren, dass er sich gut unittesten lässt. das schöne ist, dass der code dadurch auch viel einfacher, verständlicher und lesbarer wird. bedingt halt, dass du so früh wie möglich damit beginnst, auch die tests zu schreiben - im idealfall noch bevor du die implementierung schreibst. dann merkst du nämlich schon bei designen des codes, wenn du gefahr läufst, spagetti-code zu schreiben (klassen mit zu vielen abhängigkeiten, zu lange methoden mit zu vielen parametern, zu große klassen etc).

    ich empfehle das buch Clean Code.


Anmelden zum Antworten