Wer A sagt, muss auch B sagen oder Wie hilfreich sind Testreihen für Produkte?

So, ich hab dir ja eine Antwort versprochen, es hat aber etwas gedauert nun. Ich hab noch meine Bachelor-Arbeit abgeliefert.

Also, zu erst, was hier Angesprochen wurde, ist ein etwas Einseitig, zum Bespiel auch was den Begriff Alpha und Pre-Alpha angeht. Der Begriff Alpha ist schon etwas genauer gefasst, jedoch auch hier ist es nicht so ganz klar was man meint, da man als Entwickler auch was unterschiedliches verstehen kann.

Pre-Alpha und Alpha-Versionen sind meist Entwickler-Versionen, die nicht mal wirklich für die Öffentlichkeit gedacht sind, sondern für Entwickler und entsprechend einem ausgewählten Kreis von Testern Ich habe aktuell in einem größeren Team mit gewirkt und dort wurden alle Versionen bis zur Beta als DEV-YYYYMMDD benannt, bis sie in die Beta-Version überging, die anschließend an angemeldete Kunden verteilt wurde. An dieser DEV-Phase haben neben den Entwicklern nur ausgewählte Kunden und die Qualitätssicherung teilgenommen.

Damit kommen wir zu der Frage: Wie sinnvoll sind Alpha- und Beta-Tests. Die Antwort ist: Es kommt drauf an und wie ernsthaft dieses Testes durchgeführt werden. Alpha-Testes dienen meist aber jedoch weniger der Fehlerbehebung, als der Implementation von Funktionen und wie das Zusammenspiel dieser Funktionen ist. In der Regel werden nur grobe Fehler beseitigt, jedoch auf kleinere kaum Eingegangen, da diese oftmals sich entweder von selbst lösen, weil die Software komplementiert wird, oder eben sich die Behebung eines Fehlers an Stelle A in neune Fehlern äußern könnte, die erst später ersichtlich werden, wenn die Software zusammen wächst.

Damit kommen wir zu einem neuen Punkt und da unterscheidet sich auch die Vorgehensweise in Beta-Versionen. Wir haben die Beta-Version im Team wirklich zur Fehlerbehebung genutzt. Es wurden keine größeren Änderungen an Funktionen vorgenommen oder noch größere Funktionen eingepflegt, sondern es wurden Fehler behoben und ggf. kleinere Anpassungen an Funktionen und der GUI. Die Beta-Version war also bereits von den Funktionen her abgeschlossen. Das ist auch eine übliche Vorgehensweise und steht im Gegensatz zu der von WoltLab oder auch anderen Web-Entwicklern, die auch in der Beta-Phase noch Funktionen einbauen oder mal - das ist eine Eigenart von WoltLab - plötzlich ganze Teile umbauen.

Bei uns hatte die Vorgehensweise den Hintergrund, dass wir ausgewählte Kunden bereits während der Entwicklungsphase mit einbezogen haben und so Feedback bekommen haben und nicht erst - wie zum Beispiel mit WoltLab - mit einer Alpha oder Beta-Phase. Dadurch konnten wir das Feedback von Anfang an mit einbeziehen und den Kunden mit der Beta-Version ein bereits inhaltlich abgeschlossenes Produkt präsentieren, was bei uns sogar sehr wichtig war, da sich danach entsprechend das Geld für das Projekt gerichtet hat.

Es ist und zwar bei uns also in der Entwicklungsphase durchaus sehr sinnvoll Kunden zu haben, die die DEV-Phase begleitet haben, da wir auf ihre Wünsche eingehen konnten, ohne dass wir größere Umbauarbeiten hatten. In einer DEV-Phase ist sowas auch ohne Probleme möglich.

Die Beta-Phase haben wir dann mit dem bereits fertigen Produkt bestritten, dass nun entsprechend getestet werden wollte und auch hier waren wieder Kunden unsere Hauptgruppe und darunter sogar ausgesuchte Kunden, mit denen wir produktive Systeme betrieben haben und das aus sehr gutem Grund.

Ich hab es ja im anderem Thema schon angesprochen, dass die meisten Fehler in der Regel zu zwei Zweitpunkten gefunden werden: Wenn die neue Version in die Beta-Phase geht und wenn das Produkt anschließend auf den Markt kommt. Das hat auch verschiedene Hintergründe. Da ist einer zum Beispiel, dass die erste Beta-Version viele Leute zum Spielen einlädt, aber sie tun eben auch nur das: Spielen. Damit findet man offensichtliche Fehler, jedoch nicht alle. Sie spielen also mit der Software, finden dabei die groben Fehler, jedoch arbeiten sie nicht mit der Software oder haben sie im produktiven Einsatz, damit werden verstecktere Fehler übersehen. Meistens kommen dann diese versteckten Fehler zu Tage, wenn die Software in den produktiven Einsatz geht und damit eben dann, wenn die Version in der Regel zur Final wird.

Aus diesem Grund haben wir uns damals entschlossen, dass wir 3 Großkunden den Umstieg auf die Beta schmackhaft machen, sie haben dafür 50% Rabat bekommen und zwei Entwickler, die ihnen halfen, die Sofware immer auf den aktuellen Stand zu halten. Die ersten Beta-Version hatten wir da bereits hinter uns und damit die gröbsten Fehler beseitigt. Doch haben sich wirklich viele Fehler erst gezeigt, als das Produkt bei den 3 Großkunden produktiv eingesetzt wurde, die unzähligen Beta-Tester die mit der Software nur gespielt haben, haben zwar 3/4 der schwerwiegenden Fehler gefunden, aber gerade mal 1/3 der Fehler im gesamten Projekt in der Beta-Phase. Die restlichen 2/3 wurden mit den Großkunden gefunden, die das System produktiv einsetzten. Meine Erfahrung ist daher auch, dass bei den meisten freiwilligen Testern, nach den ersten Beta-Versionen eine gewisse Müdigkeit einsetzt und auch jetzt hat sich es wieder bei mir gezeigt.

Das liegt einfach daran: Als Entwickler achtet man nicht mehr auf alles, wie auch. Man testet nur das, was man verändert hat, sieht man es geht, geht man weiter. Die einfachen Tester, die nur "spielen" schauen kurz ob es geht, aber dann ist auch gut. Erst der Tester, der es einem tiefen Test unterzieht und das bedeutet in der Regel eben auch alltäglichen Einsatz, merkt, dass da vielleicht ein Fehler ist.

Und damit kommen wir zu einem letzten Punkt, da ich denke, dass das Thema aus meinen Erwiderungen zu Annothek entstanden ist: Heutige Software ist um ein vielfaches Komplexer als früher und gerade die Vielfalt an Computersystemen macht es fast unmöglich, eine Software auf alle möglichen Fehler mit nur einer begrenzten Anzahl an Testern abzuklopfen.

Um es etwas in Zahlen zu gießen: Es gibt aktuell 4 Windows Versionen, die noch mit Support versorgt werden: Vista, 7, 8.0 und 8.1. Wir haben also schon 4 Systeme. Dann nehmen wir mal nur die aktuellen Prozessoren von Intel, sprich Haswell für Consumer. 3 mal Haswell-E für die Enthusiasten + 30 - 40 Modelle für den normalen Consumer. Dazu dann ein Chipsatz für die erste Plattform und mindestens 5 für die Consumer, dann 3 Hersteller für RAM-Bausteine (Wir vereinfachen wieder!) und pro Grafikkarten-Hersteller nur 4 Stück. Dazu eben Festplattenhersteller 2 und für die SSDs mal nur 3, die recht viel selbst fertige. (Samsung, Micron, Intel). Die Rechnung wird vereinfacht: Ich nehme an, jeder hat ne SSD und ne HDD im Rechner.

Jetzt rechnen wir mal aus wie viele Kombinationen es alleine für dien Enthusiasten gibt: 3 * 1 * 3 * 4 * 4 * 2 * 3 = 216 Kombinationen, nur für die Hardware, mit den Betriebssystemen sind wir bei über 600. Bei den Consumergeräten wirds noch schlimmer. 30 * 5 * 3 * 4 * 2 * 3 = 10800 Kombinationen, bei drei Betriebssystemen sind wir bei über 30 000. Und das ist vereinfacht. Schau mal bei Alternate, was du da alles auswählen kannst.

Du hast also richtig viele Kombinationen auf denen man testen muss und das nur von der Hardware aus, dazu kommen dann Virenscanner usw. Sowas kannst du mit einer geschlossenen Gruppe an Testern nicht mehr bewältigen, vor allem da in der Software Entwicklung so mancher Fehler rein vom Programm her garnicht da ist, jedoch bei genau einer bestimmten Hardware-Software-Kombination auftritt.

Und ebenso verhält es sich durchaus auch in der Webentwicklung: 3 große Webserver, mehre MySQL-Versionen seit Version 5.1, dazu dann die ganzen Betriebsysteme und PHP-Versionen darüber. Sowas kann man als Firma wie WoltLab unmöglich abdecken und daher kommt die Phase, bei denen weitere Tester gesucht werden müssen und offene Beta-Tests sind dazu die beste Möglichkeit. Nur ist diese auch begrenzt, wie sich ja jetzt wieder zeigte. So wurde die Update-Fähigkeit von WCF2.0 auf 2.1 getestet, aber eben nur von recht wenigen, wodurch Fehler übersehen wurden. Wenn sowas passiert, ist es ärgerlich, jedoch zwangsläufig unvermeidbar, gerade wenn eben keiner mal ein Update auf seinem Live-System gemacht hat, sondern nur in einer kontrollierten Umgebung zuhause.

Also: Ja Alpha- und Beta-Tests bringen was, jedoch nur, wenn die Tester nicht nur mit dem Prodkukt spielen, sondern es auch in einem alltags Einsatz testen.

Ich wusste es doch, schwenkt man subtil ein paar Zaupfähle, finden sich doch noch weitere Stimmen ein und das Gespräch wird wieder ausführlicher. Super, ohne große Vorrede gleich weiter in die Unterhaltung gestürzt:

Zu Beginn Verständnisfragen, einfach um kein etwaiges falsches Bild zu haben:

1. "Qualitätsssicherung" - du meinst spezielle Entwickler, die sich um Templates, Code usw. kümmern oder....?

2. Ich bin mir nicht sicher, ob der von dir beschriebene Ablauf hinsichtlich der Phasen so nicht eigentlich eher bei Exklusivanfertigungen passend/logisch ist, einfach weil man da ja ein klarer Bild von Produkt, Umfang, Kundenwunsch usw. hat. Bei einer Software á la besagtem WBB muss doch die vermeintliche "Masse" zufriedengestellt weren, ohne das faktisch natürlich leisten zu können. Ist das eventuell der Grund dafür, dass dann auch in der Betaphase noch Funktionen geändert oder nachträglich implementiert werden?

3. Das klingt jetzt einfach komisch und ja, es ist mir leicht peinlich so zu fragen, aber ich tue es, einfach weil ich es mir nicht bildlich vorstellen kann, aber wissen möchte.
Du bist also der Entwickler von Produkt X, du weißt, was das Produkt "tun" soll, die Funktionen an sich sind auch klar und nun ist das Produkt also irgendwie in dem Stadium, dass da einfach besagte Pre-Alpha ist. Ok, was genau habe ich dann da aber? Ich habe einfach kein Gefühl dafür, was ich "sehen" würde, also sehe ich nichts im eigentlichen Sinne, nur Codezeilen, Templates und diese API, "läuft" da schon "etwas" und ich kann etwas damit tun oder...?

Ich war noch nie derart live dabei, dass ich wirklich gesehen habe, wie ein Entwickler sozusagen von Null an beginnt zu entwickeln. Bislang weiß ich grob, wie man ein Arbeitsscript erstellt, ich kann @Cr@@gle's Arbeitsscripte "lesen" (wobei er mir das sicher noch vereinfacht zukommen lässt, weil er mein Niveau kennt und weiß, ich würde mich schwer tun, wenn er das auf seinem regulären Niveau verpackt), ich war bei Betatests dabei bzw. durfte selber testen und zufälligerweise konnte ich ja fachlich einiges durch Patric hier aufschnappen, ABER: Ich weiß einfach nicht, wie die Phasen davor sind, ablaufen und was ich da praktisch vor mir sehen würde. Lässt sich das nun irgendwie beschreiben, grob skizzieren, damit ich zumindest nicht komplett verwirrt bin und so gar nichts weiß?

4. Wie genau würde man "schwerwiegende Fehler" definieren, wenn das System abstürzt, das Produkt tatsächlich quasi alles zerschießt oder...?

Für mich stellt sich bei Betatests nach wir vor auch die Frage, wie man die jeweilige Logik bemessen soll.
Der Entwickler hatte ja, unterstelle ich, seine logische Konzeption des Produktes, sagen wir also, das Duo Ebert/Werk "weiß", was WBB 4/4.1 sein soll, wie das Endergebnis im Idealfall ausfällt. Sie bauen darauf hin und nun kommt der Betatest. Ihr habt den Betatest zu WBB 4 noch alle im Hinterkopf, oder? Es waren dort ja nicht einmal 99% aller WBB-Kunden und Nutzer aktiv, aber es war trotzdem ein Einmarsch der Tester und Rückmeldungen. Und nun werden zig Rückmeldungen gepostet, von denn wir reproduzierbare und somit eindeutige Fehler/Bugs abziehen. Wir bleiben rein bei den Wortmeldungen, wo es um Abläufe geht, weil Leute etwas so nicht logisch finden.
Für mich stellt sich die Frage, wie selektiere ich nun so, dass ich eine möglichst eindeutige, wiederum nachvollziehbare und zumindest einigermaßen objektive (?) Rückmeldung herausfiltern kann, die die Nutzer-Logik für mich als Entwickler eindeutig besser macht, meine Meinung überstimmt? Woher und wie könnten eben Ebert/Werk entscheiden/bestimmen/abwägen, warum entweder ihre Entwicklerlogik sinnvoller/nötig/"richtig" (?) ist und nicht z.B. unser logisches Gefühl bzw. andersherum auch: Warum wäre dann unsere oder auch eine andere Sicht von einem von uns logischer/besser/"richtiger" als ihre Sicht?
Versteht ihr, wie ich das meine, also dass ich nach einer Art transparenten, definierten bzw. irgendwie strukturalen Lösung suche, die mir eine Entscheidung hinsichtlich logischem Empfinden plausibel machen würde?

Zitat von Teralios

Bei uns hatte die Vorgehensweise den Hintergrund, dass wir ausgewählte Kunden bereits während der Entwicklungsphase mit einbezogen haben und so Feedback bekommen haben und nicht erst - wie zum Beispiel mit WoltLab - mit einer Alpha oder Beta-Phase. Dadurch konnten wir das Feedback von Anfang an mit einbeziehen und den Kunden mit der Beta-Version ein bereits inhaltlich abgeschlossenes Produkt präsentieren, was bei uns sogar sehr wichtig war, da sich danach entsprechend das Geld für das Projekt gerichtet hat.

Wie eingangs angesprochen bzw. gefragt, kann man so aber wirklich bei einem doch großen Produkt wie WBB verfahren? Ich weiß es nicht, stelle es mir nur schwierig vor, wenn ich unterschiedliche Leute heranziehen sollte, die sicher ihre Ideen haben, ihre Version von WBB und wie ich das dann mit meiner vereinen kann.
Würde man es aber doch so machen, wen würde man für solche Rückmeldungen in Betracht ziehen? Wir haben in der WBB-Welt genug Fachleute, also Entwickler, Informatiker, Designer, routinierte Administratoren usw., aber reicht das quasi aus, um auf dem Niveau einer kompletten Software real helfen zu können? Ich spreche keinem die Befähigung ab, weiß Gott nicht, aber ich bin nicht sicher, ob die Kenntnisse der WBB-Fachleute wiederum zu speziell sind, es dann doch nicht so global helfen würde, dass es die komplette Software betrifft? Schauen die Fachleute dann nicht auch eher nach "ihren" Bereichen, sehen das große Ganze unter Umständen nicht? Nur eine Frage, keine These.

Ich schätze, ich bin wieder einmal etwas blauäugig hinsichtlich Tests auch an WBB herangegangen, muss ich nun so schonungslos sagen. Wie genau ich zu der Vorstellung kam, kann ich nun nicht einmal sagen, es war....die Annahme eines Laien? Ihr werdet vermutlich schmunzeln oder lachen, aber ich dachte tatsächlich, bevor WBB in die Betaphase kommt, haben sich das irgendwelche externen und speziellen Softwaretester angesehen. Vielleicht dachte ich das, weil @GreXXL im Community Forum Team ist, sich beruflich in ähnlichen Gefilden bewegt, sie also nach dem internen Test das Produkt tatsächlich von Außenstehenden testen lassen. Oder weil ein Unternehmen anders vorgehen muss als vielleicht ein Hobby-Entwickler.
Wie auch immer, ich lag also eindeutig falsch, es ist wirklich so: Die Woltis entwickeln, in der Betaphase bekommt jeder die Möglichkeit zu testen und die Demo näher zu begutachten, danach wird der Feinschliff an WBB angesetzt, fertig, Produkt wird offiziell angeboten. So läuft das tatsächlich ab, das weiß auch jeder Kunde/potenzielle Kunde/jedes Mitglied (außer mir ) und zu keinem Zeitpunkt sehen sich das externe Tester an?

Ich habe noch eine Frage hinsichtlich der "Verteilung" bei möglichen Fehlern, die auftreten können. Der Erfahrung nach, basieren Fehler tendenziell eher darauf, weil der Anwender einen praktischen Fehler macht oder liegt es mehr Produkt, weil das u.a. eben nicht für alle Einsatzbereiche und in jeder Situation genau so getestet worden sein kann?

Mich interessiert auch noch der Punkt "worst case" Szenario und Software. Patric hatte schon berichtet, dass das Unternehmen regelrecht durchspielen und somit potenziell Gefahrsituationen abfangen könn(t)en. Was wären denn solche "worst case"-Szenarieren bei einer Software, kann man das am Beispiel von WBB beschreiben (ich nehme einfach WBB, weil ich das zumindest grob kenne)? Man kann sein Forum "zerschießen", ok, davon habe ich gehört, aber was würde ich mit WBB testen, um das Produkt von Beginn an gegen irgendwelche schlimmen Unfälle zu schützen?
Kann man das grob beschreiben, darf man das sagen oder rangiert so etwas unter interne Betreibsgheimnise? Falls letzteres der Fall ist, ihr das aber doch irgendwie wisst, sagt bitte hier bloß nichts, ok? Nicht, dass es Ärger gibt, ihr einen Rüffel erhaltet und es heißt, ich hätte euch verleitet zu antworten. Wenn es geheim ist, einfach so sagen und gut ist es.

Okaaaay, ich habe doch etwas mehr geschrieben als gedacht, aber wir sind hier ja noch eine Weile beisammen, haben Zeit und können ausführlich reden, richtig? Und ich weiß, dass ich schlimm bin, viel frage und es immer "ausnutze", wenn Leute erzählen, aber meine Güte, ihr dürft mir einfach nichts erzählen...auch wenn ihr müsst, weil ich sonst bettle, jammere oder drohe zickig zu werden.

Zitat von Gabbid

1. "Qualitätsssicherung" - du meinst spezielle Entwickler, die sich um Templates, Code usw. kümmern oder....?

Nein, nicht unbedingt. In der Qualitätssicherung kann sehr viel vorhanden sein. Von einfachstem Benutzer, der das Programm testet und dafür bezahlt wird, über Entwickler, die nicht im Team drin sind und sogar externe Firmen, die man einbezieht und dafür sorge tragen, dass das Programm bestimmten Anforderungen entspricht und diese erfüllt.

Zur Qualitätssicherung gehört das Testen und damit im weitesten Sinn auch ein Beta-Test egal ob geschlossen oder öffentlich. Qualtitätssicherung ist also sowas wie die Testinstanz für das Programm, es sind Tester die ggf. auch Ratschläge erteilen.

Zitat von Gabbid

2. Ich bin mir nicht sicher, ob der von dir beschriebene Ablauf hinsichtlich der Phasen so nicht eigentlich eher bei Exklusivanfertigungen passend/logisch ist, einfach weil man da ja ein klarer Bild von Produkt, Umfang, Kundenwunsch usw. hat. Bei einer Software á la besagtem WBB muss doch die vermeintliche "Masse" zufriedengestellt weren, ohne das faktisch natürlich leisten zu können. Ist das eventuell der Grund dafür, dass dann auch in der Betaphase noch Funktionen geändert oder nachträglich implementiert werden?

Das WBB ist ein anderes Stück Software und muss andere Anforderungen erfüllen, zu dem ist der Kundenstamm ein anderer und es findet eine weit bessere Kommunikation mit den Kunden statt.

Eine der größten Schwachpunkte von WoltLab ist und bleibt der mangelnde Kontakt mit Kunden. Wenn du jedoch Kunden wie in dem Projekt hast, in dem ich mit gewirkt habe, werden diese Kunden bereits bei der Konzeption der neuen Software mit einbezogen und auch schon während der Entwicklungsphase. Man entwickelt mit den Großkunden die Software und präsentiert ihnen nicht nach X-Monaten eine neue Version und holt sich erst dann Ratschläge, wenn schon viel Arbeit in Planung und Konzeption von Funktionen geflossen ist, die man dann durch Ratschläge und Wünsche ggf. vollständig neu implementieren müsste.

Ein guter Freund von mir in den USA ist freier Grafiker und Animationstechniker und arbeitet mit seiner Firma für Disney, Warner Brosthers und auch andere Firmen. Wenn neue Entwicklungen bei Autodesk oder Adobe anstehen, werden da potentielle Großkunden und professionelle Kunden mit in die Entwicklung einbezogen - natürlich unter NDA - und zu Funktionen befragt, bevor der große Kundenstamm überhaupt eine Beta-Version zu sehen bekommt. Sowas ist auch notwendig, wenn man sich mal die Mannstunden ansieht, die dort hinter so manchen Funktionen stecken.

Es ist also eher üblich, sofern man entsprechende Kosten bei der Entwicklung hat, Kunden bereits in die Entwicklung mit einzubeziehen, bevor es in eine Testphase geht, auch bei Software, die für viele gedacht ist und nicht exklusiv angefertigt wird. Sowas sparrt in der Regel unnötige Kosten, die entstehen, wenn man als Entwickler wild drauf los entwickelt - egal wie gut die Planung ist - und dabei dann den Kundenstamm aus dem Auge verliert.

Wir haben bei WoltLab aktuell zwei solcher Beispiele, die eben nicht unter Einbeziehung der Kunden entwickelt worden sind, sondern wild drauf los: Gallery und Blog. Beide Lösungen sind zur Zeit weder Fisch noch Fleisch. Hätte man dort in die Entwicklung mal ein paar Kunden eingeladen, hätte man vorher bereits wesentlich besser Planen können und müsste nicht jetzt erst langwierig dran rum schrauben. Die Diskussionen kannst du ja dort nach verfolgen und wie unbefriedigt alle Anforderungen waren.

Zitat von Gabbid

3. Das klingt jetzt einfach komisch und ja, es ist mir leicht peinlich so zu fragen, aber ich tue es, einfach weil ich es mir nicht bildlich vorstellen kann, aber wissen möchte.
Du bist also der Entwickler von Produkt X, du weißt, was das Produkt "tun" soll, die Funktionen an sich sind auch klar und nun ist das Produkt also irgendwie in dem Stadium, dass da einfach besagte Pre-Alpha ist. Ok, was genau habe ich dann da aber? Ich habe einfach kein Gefühl dafür, was ich "sehen" würde, also sehe ich nichts im eigentlichen Sinne, nur Codezeilen, Templates und diese API, "läuft" da schon "etwas" und ich kann etwas damit tun oder...?

Ich sprach von einem Projekt, dass in dem Fall nicht nur aus einer Web-Komponente bestand, für die ich verantwortlich war. Das Projekt bestand aus 5 Software-Paketen. In der Dev-Phase wurden in dem Fall die einzelnen Komponenten entwickelt und jede der einzelnen Komponenten hat durchaus auch was sichtbares Produziert. Bei mir war es zum Beispiel die Suchmaske, die Anzeige von Suchergebnissen und die Führung der Benutzer. Bei Gruppe A war die Software zur Verwaltung von Datensätzen zu sehen und wieder andere hatten die Aufgabe Dubletten zu filtern und auch das konnte man sehen und Testen. Durch das aufteilen in verschiedene Module/Komponenten, konnten wir diese einzeln entwickeln und auch den Kunden vorführen und entsprechend auch separate Testgruppe organisieren. Während ich mich eher mit Designern, UI-Experten und dem einfachen Benutzer rumschlagen musste während des Projekts, waren es bei einem Kollegen die Anwender der Firmen, die die Software verwalten sollten. Für die Server-Struktur und dortige Betreuung konnte man wiederum die Administratoren der Firmen als Tester und Berater gewinnen.

In den ersten DEV-Builds hatten wir also zig Bestandteile, die einzeln entwickelt wurden und einzeln betreut wurden. Als dann die Komponenten fertig waren, sind diese zusammen gewachsen und wurden auch entsprechend zusammen gebaut. Auch durchaus eine übliche Art Software zu entwickeln.

Wichtig war und ist jedoch gewesen, dass die Beta-Phase erst bestritten wurde, als die Software Feature-Complete war. Die Beta-Phase war zum Testen der ganzen Software-Suite gedacht, nicht um dann erst Kundenfeedback zu bekommen, was man denn besser machen kann. Bei der Software wäre das im übrigen auch Fatal gewesen. Gerade oder auch weil die Software im ganzen doch ein Stück komplexer als das WCF und WBB zusammen ist.

Zitat von Gabbid

4. Wie genau würde man "schwerwiegende Fehler" definieren, wenn das System abstürzt, das Produkt tatsächlich quasi alles zerschießt oder...?

Da kommt es drauf an. Schwerwiegende Fehler würde ich in unserem Fall die Fehler nennen, die die Funktionsweise des Systems vollständig oder fast vollständig verhindern. Dazu können auch Abstürze gehören, aber auch zum Beispiel - jetzt im Fall des WBB - das ein Beitrag nicht gespeichert wird. Das Anhänge nicht geladen werden. Eben offensichtliche Mängel die einem - entschuldigt die Wortwahl - mit beiden Arschbacken ins Gesicht springen und schreien: "HEY SCHAU MAL HIER BIN ICH!" Der oft besagte Wink mit dem Zaunpfahl.

Ein Fehler, der ein System vollständig zerschießt würde ich im übrigen nicht mehr als schwerwiegender Fehler bezeichnen, sondern als GAU/SuperGAU und diese Fehler haben oftmals leider die Angewohnheit frei nach Murphy aufzutreten: Alles was schief gehen kann geht schief. Und dabei springen sie einem noch nicht mal wirklich beim Testen mit beiden Arschbacken ins Gesicht, sondern zeigen sich gerne und oftmals nur in ziemlich exotischen Zusammenstellungen.

Natürlich muss man hier wieder aufpassen, wie man selbst die Fehler klassifiziert. Hier findest du einen kleineren Ratgeber dazu: http://www.bitkom.org/files/do…fuer_Software_haftung.pdf

Wir selbst hatten im Projekt 4 Arten von Fehler:

1. Kritische Fehler: Fehler die die Datenkonsistenz gefährden, das System als ganzes oder die Sicherheit. Selten auch Fehler die zu einem Absturz führten. Oft mals waren diese Fehler jedoch nicht einfach zu finden.
2. Schwerwiegende Fehler: Fehler die zum Absturz des Programmes führten oder die Funktionsweise vollständig oder zum größten Teil verhinderten. Die sind einem meist recht schnell aufgefallen. Waren aber weder für Daten noch das System gefährlich, nur eben sehr offensichtlich.
3. Fehler: Alles, was Funktionen beeinträchtigt. Oftmals schwerer zu finden, aber führen nicht zum Absturz oder gefährden die Daten.
4. Leichte Fehler: Unschönheiten, die aber nicht die Software und deren Funktionsweise beeinträchtigen.

Entsprechend wurden die Fehler auch behoben und auch entsprechend war es oft schwer. Kritische Fehler haben oftmals ds meiste Kopfzerbrechen bereitet, während schwerwiegende Fehler meist doch eher einfachere Natur waren. Fehler hingegen waren meist wieder schwerer zu Beseitigen als schwerwiegende Fehler.

Zitat von Gabbid

Wie eingangs angesprochen bzw. gefragt, kann man so aber wirklich bei einem doch großen Produkt wie WBB verfahren? Ich weiß es nicht, stelle es mir nur schwierig vor, wenn ich unterschiedliche Leute heranziehen sollte, die sicher ihre Ideen haben, ihre Version von WBB und wie ich das dann mit meiner vereinen kann.

Das WBB ist als Produkt, ebenso XenForo und sogar das IP.B, sogar eher recht klein von der Funktionsweise her und sogar regelrecht überschaubar. Das soll jetzt keine Herabwürdigung sein, doch wirklich groß sind diese Produkte nicht.

Jedoch müsste gerade WoltLab so verfahren, wie die nähere Vergangenheit gezeigt hat. Auch hier wieder auf das Blog verwiesen und auf die Gallery, die oftmals weder die Ansprüche von Gruppe A noch Gruppe B erfüllen konnten, sondern regelrecht an den Benutzern vorbei entwickelt wurden.

Zitat von Gabbid

Würde man es aber doch so machen, wen würde man für solche Rückmeldungen in Betracht ziehen? Wir haben in der WBB-Welt genug Fachleute, also Entwickler, Informatiker, Designer, routinierte Administratoren usw., aber reicht das quasi aus, um auf dem Niveau einer kompletten Software real helfen zu können? Ich spreche keinem die Befähigung ab, weiß Gott nicht, aber ich bin nicht sicher, ob die Kenntnisse der WBB-Fachleute wiederum zu speziell sind, es dann doch nicht so global helfen würde, dass es die komplette Software betrifft? Schauen die Fachleute dann nicht auch eher nach "ihren" Bereichen, sehen das große Ganze unter Umständen nicht? Nur eine Frage, keine These.

Das ist die Frage und sie ist nicht einfach zu beantworten, da es drauf ankommt, um was es geht. Braucht man also Informatiker, Designer oder routinierte Administratoren? Ja und nein.

Ich nehme wieder mal das Blog: Muss ich beim Blog Administratoren befragen, welche Funktionen das Blog haben muss? Nur sofern die Administratoren auch selbst aktive Blogger sind und ein Blog entsprechend mit Inhalt befüllen, tun sie das nicht, sondern betreuen es nur, kannst du die auch weg lassen.

Brauch ich Entwickler, um den Funktionsumfang fest zulegen? Auch nur dann, wenn sie selbst Schreiben und aktiv sowas nutzen. Geht man also von Funktionen aus, ist es besser Blogger zu befragen, diese müssen jedoch weder Zwangsläufig Administratoren ein, noch Entwickler oder Designer.

Gehen wir an die GUI: Brauch ich dafür zwingend einen Designer? Auch, jedoch nicht nur. GUI-Testes muss man auch mit einfachen Nutzern durchführen, die entsprechend mit der GUI zurecht kommen müssen. Ich brauch dafür aber sicher keine Administratoren oder Entwickler.

Geht es um Sicherheit, dann brauch ich wiederum keine einfachen Nutzer, sondern spezielle Informatiker, die sich damit gut auskennen.

Man sieht daran: Diese Frage ist nicht mit einer richtigen und umfassenden Antwort zu beantworten, sondern es kommt drauf an!

Sollte man als Entwickler bereits während der Entwicklungsphase jedoch bestimmte Nutzergruppen direkt mit einbeziehen? Auf jeden Fall, da man sich so oft mals unnötige Arbeit und Nacharbeit sparrt und oftmals die Kunden wesentlich eher zufrieden stellt, als es beim Blog zur Zeit der Fall ist. Ich hätte zum Beispiel es schon toll gefunden, wenn WoltLab mal bei mir und anderen angefragt hätte, was uns fehlt, wie wir uns es vorstellen. Den den größten Kritikpunkt hat WoltLab nicht in Angriff genommen des Blogs: Diese absolut ekelhafte Startseite. Ich bin nicht umsonst von einige gefragt worden, wie ich es geschafft habe, dass man bei mir auf der EntryListPage als erstes landet.