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

  • Guten Abend fleißige Entwickler/Designer, aktive Tester und die, die später das Produkt im Forum haben :D


    Es ist keine Art "Aus-aktuellem-Anlass"-Thread, aber ich bin über einige Meinungen rund um den (Un-)Sinn von Alpha- bzw. Betatests gestolpert und habe mich gefragt, ob man diesen Punkt nicht auf den Labortisch zum näheren Testen packen sollte.


    Rein praktisch kann ich mich selber lediglich als einmalige Betatesterin schimpfen, was also heißt, meine Eindrücke sind begrenzt, subjektiv und ich sehe es aus der Sicht des eher neutralen, neugierigen Nutzers. Wenn ich meine Erwartungshaltung mit dem konkreten Ablauf vergleiche, war meine Vorstellung von einem Betatest zu sicher 60% falsch, vieles war Neuland und ich habe mich später gefragt, wie die Entwickler diesen Wust an Rückmeldungen überhaupt bewältigen können. Dabei geht es ja nicht rein um die Quantität, sondern das Abwägen, die Verifikation und ob wirklich noch Funktionen nachgebessert bzw. nachträglich eingebaut werden.



    Ich möchte jetzt gar nicht groß meine genauen Betatesteindrücke voranstellen, aber nach dem Lesen einiger kritischer Rückmeldungen seitens anderer WBB-Nutzer möchte ich doch gerne mehr erfahren.



    1. Grundsätzlich kann sicher jeder verstehen, warum man Alpha- und Betatests macht und dass Nutzerrückmeldungen hilfreich sein können, aber lässt sich irgendwie "messbar" festhalten, wie hilfreich es wirklich ist? [Hier schaue ich bewusst in die Richtung der Entwickler und wäre interessiert eure Fachmeinungen zu erfahren. :) ]



    2. Wie sinnvoll oder unsinnig sind eigentlich Alphatests, gibt es dazu Meinungen, Erfahrungen, Dinge, die zu bedenken sind?



    3. Wie würde man die vermeintlich idealen Tester ermitteln? Sprich, macht es Sinn eher unterschiedliche Tester zu gewinnen, wendet man sich mehr an Fachleute, nimmt man routinierte Tester oder...?



    4. Was ich nicht einordnen kann, ist, wie "schlimm" ist es, wenn man ein Produkt herausgibt, dann aber in den nächsten Tagen Patches, Updates etc. online stellt? Natürlich erwartet jeder ein perfektes Produkt, aber Software ist nicht ein Paar Socken, Korrekturen erscheinen mir also - subjektiv formuliert - nicht schlimm, aber sendet es doch an potenzielle Kunden die Message, das Produkt scheint nicht 100% fertig gewesen zu sein? [Stichwort Außenwirkung, Erwartungshaltung und ob Nutzer/Kunden unterschiedlich deuten].





    Erst einmal diese Eckfragen als Ausgangspunkt, wir können das Gespräch dann jederzeit weiterführen und willkommen sind natürlich nicht nur die Entwickler/Designer, sondern auch Tester und alle Nutzer, die ja von ihren Eindrücken erzählen können. :)



    Ich spitze nun einmal die Ohren und seid gegrüßt von mir :coffee:

  • Hallo Gabi, schön das man sich wieder liest und ich dir wieder ganz offiziell ganz viel Text entgegenwerfen darf. Ich bin bester Dinge das du ohne mit der Wimper zu zucken eine Menge davon zurück wirfst.


    Aber nun zum Thema:
    1. Direkt Messbar würde ich nicht sagen. Ich würde noch nicht mal sagen, dass man unbedingt eher Fehler findet, wie wenn man selbst alles Testet, nachdem man es Implentiert hat. Hier kommt aber der entscheidende Knackpunkt: Um so Umfangreicher ein Produkt wird, um so mehr Einfluss haben einzelne Implementierungen eventuell einen Einfluss auf andere Ecken eines Produkts. Die alles bis ins Detail zu testen, würde den Testzeitraum der notwendig wäre bis ins unermessliche Sprengen. Man testet dann das, wo man denkt, es könnten vermutlich Probleme entstehen. Auch dann bleiben Dinge aus an die man einfach nicht gedacht hat, keinen Zusammenhang erkannt hat, daher auch nicht nochmal getestet hat. Tester können somit alles Testen, ohne einen Zusammenhang kennen zu müssen. Sie schließen also keine bestimmte stelle ein oder aus. Die meisten Tester, testen das, wofür sie ein Produkt verwenden möchten am meisten. Die anderen Ecken schauen sie sich auch an, aber meist weniger genau, weil das Interesse vielleicht kleiner ist. Auf der anderen Seite bringt das ganze den Vorteil mit, dass man auf so vielen verschiedenen Systemen testen kann, die man selber alle gar nicht hat, also auch nicht darauf testen kann. Fazit: Tester sind gut, ersparen einem Zeit, spielen verschiedene Systeme durch.


    2. Alphatests können aus verschiedenen Aspekten sinnvoll sein. Man kann neue Funktionen präsentieren und ein Feedback einholen, ob diese Funktionen sinn machen und ob sie gut umgesetzt sind (Benutzerfreundlichkeit ist hier ein großer Punkt). Man muss hier aber denke ich schauen, welche Zielgruppe man wie an das ganze heranführt. Erfahrene Administratoren oder Entwickler können eher mal einen Fehler abfangen und damit leben, ihn melden und verursachen damit keinen sehr großen Supportaufwand, was bei dem normalen Anwender nicht der Fall ist. Dieser kann aber eher Feedback über die Benutzerfreundlichkeit und mehr geben. Da muss man einfach schauen was man erreichen will und verschiedene mögliche Wege einschlagen.


    3. Hier kommt es denke ich sehr auf das Produkt an. Je nach dem welche Zielgruppe ein Produkt hat, so ändert sich wahrscheinlich auch die Zielgruppe der möglichen Tester.


    4. Das kommt denke ich immer auf den Fehler an. Akute Fehler, die bei der Installation etwas zerstören oder unbrauchbar machen, sollte natürlich nicht vorkommen. Die nächste Priorität liegt dabei, Fehler zu vermeiden die das Produkt selbst vielleicht unbrauchbar machen. Aber alles weitere wie Schönheitsfehler, Darstellungsfehler oder kleinere Funktionsfehler sind normal. Dieses Problem findet man auch in großen Unternehmen. Manche Fehler fallen eben erst auch nach ewiger Zeit aus, sei es weil die Funktion die betroffen ist, fast nie benutzt wird oder weil einfach viele Bedingungen erfüllt sein müssen, damit das Problem auftritt. Auch Microsoft fixt Fehler in teilweise 5-8 Jahre alten Produkten, die gerade erst aufgefallen sind.


    Das sollte für den Anfang reichen. Du wirst nun genug Input für eine laaaaaaange Antwort haben ;)

  • Hallo @Gabbid,


    rund um den (Un-)Sinn von Alpha- bzw. Betatests gestolpert und habe mich gefragt, ob man diesen Punkt nicht auf den Labortisch zum näheren Testen packen sollte.


    Diese Frage habe ich mir ebenfalls gestellt und so beantwortet:
    Je nach Produkt und Größe des (Entwickler-)Teams könnte es hilfreich sein, solche Tests öffentlich zu machen anstelle eines Labortisch-Tests.
    Dazu liefern viele Nutzer Informationen oder Ideen zur Entwicklung und haben ihre sichtweise zu den Dingen.


    3. Wie würde man die vermeintlich idealen Tester ermitteln? Sprich, macht es Sinn eher unterschiedliche Tester zu gewinnen, wendet man sich mehr an Fachleute, nimmt man routinierte Tester oder...?


    Ich denke, es ist sinnvoll, unterschiedliche Tester einzusetzen.
    JedeR nutzt das Produkt anders, hat eine individuelle Betrachtungsweise und kann somit wertvolle Nutzerrückmeldungen geben.


    Im Fall von Software & Erweiterungen für das Internet z.B. werden z.B. unterschiedliche Browser & verschiedene Webhosts genutzt.
    Die daraus gewonnen Erkenntnisse fließen somit in die Entwicklung ein.


    4. Was ich nicht einordnen kann, ist, wie "schlimm" ist es, wenn man ein Produkt herausgibt, dann aber in den nächsten Tagen Patches, Updates etc. online stellt? Natürlich erwartet jeder ein perfektes Produkt, aber Software ist nicht ein Paar Socken, Korrekturen erscheinen mir also - subjektiv formuliert - nicht schlimm, aber sendet es doch an potenzielle Kunden die Message, das Produkt scheint nicht 100% fertig gewesen zu sein? [Stichwort Außenwirkung, Erwartungshaltung und ob Nutzer/Kunden unterschiedlich deuten].


    Die Patches nach der Veröffentlichung erscheinen mir etwas "ungewohnt", das liegt jedoch vermutlich an mir persönlich, denn die WBB-Welt ist für mich noch relativ neu (ca. 8 Monate) und die Vorgehensweise bzgl. Alpha- & Betatests, Updates & Patches auch.


    Die öffentlichen Alpha- & Betatests ganz besonders.


    :tee:

  • Super, ich wusste doch, es gibt auskunftsfreudige Menschlein und wir können tiefer ins Thema einsteigen, habt also Dank für eure ersten Erklärungen, schnappt euch einen :keks: und sprechen wir gleich weiter. :ahahaha: Wann immer ich euch aber zu sehr ausfrage und penetrant am Ärmel zupfe, sagt es, irgendwann merke ich es auch...denke ich. :D ( [FFW] Patric: Das gilt natürlich nicht für dich, du musst immer Auskunft geben, das stand im Kleingedruckten nach unserer ersten Unterhaltung... :whistling: :D ].



    Ich möchte gerne mit der Rückfrage einsteigen, wie ihr bei einem Plugin die "Größe" ungefähr definiert. Also, wann ist ein Plugin klein/groß, wie ordne ich das hinsichtlich der implementierten Funktionen ein, sicher nicht wirklich quantitativ, oder?


    Nehmen wir als Testbeispiel ein Plugin in der Größenordnung eines CMS, es ist also "groß", ich habe die Funktionen drin, habe als Entwickler das überprüft, was ich selber weiß, wo ich bekannte Tücken vermute/kenne und das Plugin läuft lokal einwandfrei. Im Alphatest teste ich also erst einmal rein die Funktionen und achte auf die Benutzerfreundlichkeit und ob die Funktionen überhaupt sinnvoll erscheinen.


    Da sehe ich nun schon die ersten möglichen Probleme bzw. Fragen:


    1. Ich bin der CMS-Entwickler und wir können unterstellen, dass ich einen Plan hatte und das CMS so gebaut habe, wie ich es sinnvoll und logisch (?) fand. Vermutlich werde ich mir auch Gedanken gemacht haben, welche Funktionen in der Version drin sind, was später kommt usw. Wenn nun meine Tester ankommen und Mitspracherecht hinsichtlich Funktionen haben - torpediere ich da nicht eigentlich schon das Produkt und werfe es im schlimmsten Fall auf die Werkbank zurück, weil meine X Tester alles bemängeln und ändern könnten? Anders formuliert, hole ich mir Input nicht vor dem Alphatest, aber meine Entscheidung selber bleibt dann, die Testermeinungen könnten mich lediglich dazu bringen, dass ich Funktionen in Form einer Dummy-Funktion erst einmal "verstecke", sie später aktiviere?


    2. Kann man normale Tester wirklich auf eine Alphaversion loslassen bzw. können sie überhaupt die Nutzbarkeit ordentlich bewerten? Vom Gefühl her hätte ich gedacht, die Alphatestphase bestreiten rein der Entwickler und Entwicklerkollegen, man nimmt also eindeutig Fachleute, weil die gezielt nach dem technischen Schnickschnack schauen und konkret Tipps geben könnten, das kann der reine Nutzer doch so nicht, ergo bringt es nichts.


    3. Eine vermutlich komische Frage, aber ich stelle sie trotzdem. Könnte man eine Alphatestphase auch rein marketingstechnisch nutzen, um potenziellen Kunden Aktivität und Neuerung zu suggerieren, das der Eindruck entsteht, Fachklientel testet und es geht voran?




    Ich mag die Idee und stoße da in deine Richtung, @EM_Jott, dass man die späteren Nutzer oder auch rein Interessierten an solchen Tests beteiligt. Nur zugleich sage ich dir einmal frei heraus, ich war ziemlich abgeschreckt von der Art und Weise, wie der Test rund um WBB 4 lief. Es ist gut möglich, dass ich einfach zu neu war und nicht wusste, wie das abläuft, aber ich dachte, es läuft "irgendwie" geordnet ab, thematisch abgeheftet und dass man auch die Zeit für detaillierte Gespräche hat, um abzuklopfen, warum was eventuell nicht geht (rein aus Interesse an der Diskussion). Nur, ich war im Grunde nach dem zweiten Tag im Betaforum schon überfordert und habe bei vielen Themen den Faden verloren. Es war einfach hektisch, wimmelte vor zig-fach Posts und dass die WoltLab-Teamies den Überblick behalten haben - Chapeau, sage ich nur. Gut, es ging um eine komplette Software und nicht um ein Plugin, aber war das alles hilfreich, wie viel waren konstruktive Tipps und kann man so eine Masse wirklich zumuten?


    Um es anders zu erfragen, ist das, was wir jetzt bei Betatest sehen, so wirklich inhaltlich und strukturell konstruktiv und hilft?


    Was mich auch beschäftigt und da würde ich nach deiner Einschätzung fragen: Sind Betatests dann wirklich komplett und konstruktiv getestet worden, wenn es so ist wie Patric schrieb, dass die Tester eher danach schauen, wie das Plugin später von ihnen angewendet/eingebunden wird?



    Hier muss ich vielleicht kurz einschieben, warum ich frage und ihr werdet mich vermutlich gleich korrigieren, meine Sicht dürfte falsch sein. Fakt ist, ich gehöre nicht zum Fachpublikum und kann nicht entwickeln, ich habe genau einen Betatest erlebt und meine Vorstellung war in etwa so:
    - Man testet ein Plugin nach bestem Können und Wissen so lange, bis man es förmlich auseinandergenommen hat.
    - Man notiert jede Beobachtung, notiert potenzielle weitere Überlegungen, bespricht sich bei Fragen und Ideen mit den Mittestern, diskutiert offene Punkte in gemeinschaftlicher Runde (Entwickler und Tester).
    - Man behandelt das Plugin so, als gehöre es temporär einem selber, man darf es also nur dann abnicken, wenn man selber glaubt nichts übersehen zu haben.


    Das klingt sicher...pedantisch? Seltsam? Falsch? Ich dachte, so wäre es gemeint, richtig und in diesem Kontext mit weiteren Testern, die das auch so sehen, läuft ein Betatest dann auch zwangsläufig sehr konstruktiv ab. Zum Teil klappte das auch wirklich, ich kann sicher sagen bzw. es ist nicht peinlich zu erwähnen, dass es mit uns beiden beim Test gut lief, Patric, oder? Nur zugleich war das vermutlich nur möglich, weil die Testerrunde überschaubar war oder es einfach ein glücklicher Umstand war, dass wir aufeinandergetroffen sind? Ich weiß es nicht, aber mich irritiert es anzunehmen, dass Betatests nicht grundsätzlich so laufen, warum nicht? :/




    Bei den Testgruppen habt ihr beide gesagt, es käme auf das Produkt an, aber unterschiedliche Tester würden die Testbandbreite und somit etwaige Optimierungschancen vergrößern. Was sagt ihr nun zu dieser Frage:


    Ist es sinniger komplett neue Tester zu wählen, die das Produkt nicht kennen und somit theoretisch wegen der Unbefangenheit alles testen könnten, oder ist es effektiver z.B. Kunden des Produktes zu nehmen, wenn die das Produkt in der Vorgängerversion schon kennen und somit passgenau/er testen können?



    Im Fall von Software & Erweiterungen für das Internet z.B. werden z.B. unterschiedliche Browser & verschiedene Webhosts genutzt.
    Die daraus gewonnen Erkenntnisse fließen somit in die Entwicklung ein.




    Kann ich aus dieser Äußerung schließen, du kennst dich damit näher aus und könntest noch ein wenig detaillierter werden, wenn es keine Umstände macht? Genauer gesagt, was an technischen "Drumherum" würde so ein fachkundiger Tester eigentlich noch testen, kann man das stichwortartig festlegen? Es wird vermutlich keine reale Checkliste geben (?), aber wenn du du dich auskennst und doch einige Aspekte notieren könntest, wäre das interessant zu erfahren, z.B. ich habe da null Hintergrundwissen. :blush:





    Kommen wir zur Wirkung von Patches&Co, ich würde gleich zu deiner Deutung einschwenken:


    Die Patches nach der Veröffentlichung erscheinen mir etwas "ungewohnt", das liegt jedoch vermutlich an mir persönlich, denn die WBB-Welt ist für mich noch relativ neu (ca. 8 Monate) und die Vorgehensweise bzgl. Alpha- & Betatests, Updates & Patches auch.




    Könntest du das bitte ausführen, kennst du es von einer anderen Software eventuell anders, gar besser bzw. ist das "ungewohnte" Empfinden bei dir eher positiv oder negativ besetzt, lässt es sich aufschlüsseln und du magst etwas berichten? :)




    Aber alles weitere wie Schönheitsfehler, Darstellungsfehler oder kleinere Funktionsfehler sind normal. Dieses Problem findet man auch in großen Unternehmen. Manche Fehler fallen eben erst auch nach ewiger Zeit aus, sei es weil die Funktion die betroffen ist, fast nie benutzt wird oder weil einfach viele Bedingungen erfüllt sein müssen, damit das Problem auftritt.




    Gut, das ist nachvollziehbar, aber zugleich hast du hier quasi eine Art Heimvorteil, Patric, du kennst dich in dieser Branche aus und siehst das somit fachlich, rational, entspannt usw., das kann man so sagen? Ich selber gerate nicht in Panik, wenn ich ein Update sehe oder denke "Oh Gott, das Plugin ist schlecht, weg damit!", aber ich tue mich schwer zu beurteilen, wie man so ein Szenario einordnen soll:


    Ist es tendenziell gut/schlecht, wenn ein Unternehmen viele Patches anbringt, regelmäßig und auch den Grund erklärt? Oder vermittelt es dem Nutzer den Eindruck, es wird erst nach und nach am Produkt gearbeitet, ich habe schon einmal die Bezeichnung "Bananaware" gehört, also Software, die beim Kunden reift.


    Du bist Fachkundiger, aber wenn du dich in einen eher unwissenden und potenziellen Kunden hineinversetzt, wie würdest du es sehen?







    .....................


    Hallo Gabi, schön das man sich wieder liest und ich dir wieder ganz offiziell ganz viel Text entgegenwerfen darf. Ich bin bester Dinge das du ohne mit der Wimper zu zucken eine Menge davon zurück wirfst.




    Ein ebensolcher Gruß zurück und wenn das nicht Musik in meinen Ohren ist! 8o :D Ich würde doch das Ende der Welt skandieren, wenn mit der nächsten WBB-Version nur noch Tweet-Längen möglich wären, Konversationen abgeschafft würden, alle Messenger offline gingen und Brieftauben trotz Trainingseinheiten nicht meine 10 KG-Post bewältigen könnten. :D Erst die langen Diskussionen machen das Forum gemütlich und dürfte ich nicht fragen, antworten und schreiben...brrrr, eine quasi-Amputation, das würde ich schon daher nicht überleben, weil ich weiblich bin, wir haben einfach das Plauder-Gen, egal was die Medizin sagt. :D

  • Ich möchte gerne mit der Rückfrage einsteigen, wie ihr bei einem Plugin die "Größe" ungefähr definiert. Also, wann ist ein Plugin klein/groß, wie ordne ich das hinsichtlich der implementierten Funktionen ein, sicher nicht wirklich quantitativ, oder?

    Naja, ein kleines Plugin ist für mich z.B. wenn ich kleinere Funktionen in einer bestehenden Anwendung nachrüste. Größere dann Endanwendungen. Pauschal kann man auch das wieder nicht beantworten. Hier muss man immer ganz klar schauen, was man mit dem Plugin wie beeinflusst und wie viele Abhängigkeiten zu anderen Dingen bestehen.


    1. Ich bin der CMS-Entwickler und wir können unterstellen, dass ich einen Plan hatte und das CMS so gebaut habe, wie ich es sinnvoll und logisch (?) fand. Vermutlich werde ich mir auch Gedanken gemacht haben, welche Funktionen in der Version drin sind, was später kommt usw. Wenn nun meine Tester ankommen und Mitspracherecht hinsichtlich Funktionen haben - torpediere ich da nicht eigentlich schon das Produkt und werfe es im schlimmsten Fall auf die Werkbank zurück, weil meine X Tester alles bemängeln und ändern könnten? Anders formuliert, hole ich mir Input nicht vor dem Alphatest, aber meine Entscheidung selber bleibt dann, die Testermeinungen könnten mich lediglich dazu bringen, dass ich Funktionen in Form einer Dummy-Funktion erst einmal "verstecke", sie später aktiviere?

    Sind wir hier bei einem Alpha oder einem Beta test? Zumindest im Beta test, sollte der Funktionsumfang schon fest stehen und nur noch in Ausnahmefällen sollte daran etwas geändert werden.


    2. Kann man normale Tester wirklich auf eine Alphaversion loslassen bzw. können sie überhaupt die Nutzbarkeit ordentlich bewerten? Vom Gefühl her hätte ich gedacht, die Alphatestphase bestreiten rein der Entwickler und Entwicklerkollegen, man nimmt also eindeutig Fachleute, weil die gezielt nach dem technischen Schnickschnack schauen und konkret Tipps geben könnten, das kann der reine Nutzer doch so nicht, ergo bringt es nichts.

    Jain. WoltLabs Testart kann man hier gut als Beispiel nehmen. Man lässt die Kunden das Ding einfach benutzen ;)


    3. Eine vermutlich komische Frage, aber ich stelle sie trotzdem. Könnte man eine Alphatestphase auch rein marketingstechnisch nutzen, um potenziellen Kunden Aktivität und Neuerung zu suggerieren, das der Eindruck entsteht, Fachklientel testet und es geht voran?

    Kann man... Da spuken mir jetzt zu viele Gedanken im Kopf um sie alle zu notieren ^^


    Gut, es ging um eine komplette Software und nicht um ein Plugin, aber war das alles hilfreich, wie viel waren konstruktive Tipps und kann man so eine Masse wirklich zumuten?

    Masse, kann man. Man muss aber stark aussieben.


    Um es anders zu erfragen, ist das, was wir jetzt bei Betatest sehen, so wirklich inhaltlich und strukturell konstruktiv und hilft?

    Ja.


    Das klingt sicher...pedantisch? Seltsam? Falsch? Ich dachte, so wäre es gemeint, richtig und in diesem Kontext mit weiteren Testern, die das auch so sehen, läuft ein Betatest dann auch zwangsläufig sehr konstruktiv ab. Zum Teil klappte das auch wirklich, ich kann sicher sagen bzw. es ist nicht peinlich zu erwähnen, dass es mit uns beiden beim Test gut lief, Patric, oder? Nur zugleich war das vermutlich nur möglich, weil die Testerrunde überschaubar war oder es einfach ein glücklicher Umstand war, dass wir aufeinandergetroffen sind? Ich weiß es nicht, aber mich irritiert es anzunehmen, dass Betatests nicht grundsätzlich so laufen, warum nicht?

    Ja, wir haben zu einander gefunden (kann ich das so sagen?), aber wie das immer ist, kommt es auf die Menschen an mit denen man zu tun hat. Denn die bestimmen wie der Test läuft.


    Ist es sinniger komplett neue Tester zu wählen, die das Produkt nicht kennen und somit theoretisch wegen der Unbefangenheit alles testen könnten, oder ist es effektiver z.B. Kunden des Produktes zu nehmen, wenn die das Produkt in der Vorgängerversion schon kennen und somit passgenau/er testen können?

    Eine gesunde Mischung ist hier denke ich die beste Wahl :)


    Kann ich aus dieser Äußerung schließen, du kennst dich damit näher aus und könntest noch ein wenig detaillierter werden, wenn es keine Umstände macht? Genauer gesagt, was an technischen "Drumherum" würde so ein fachkundiger Tester eigentlich noch testen, kann man das stichwortartig festlegen? Es wird vermutlich keine reale Checkliste geben (?), aber wenn du du dich auskennst und doch einige Aspekte notieren könntest, wäre das interessant zu erfahren, z.B. ich habe da null Hintergrundwissen.

    Hier geht es weniger darum, das ein Test ganz konkret etwas bestimmtes testet, sondern einfach sein System benutzt. Ich teste zum Beispiel hauptsächlich auf einem Linux Webserver. Ein Tester hat vielleicht einen Windows Webserver. Man will also verschiedenste Umgebungseinflüsse testen.


    Ist es tendenziell gut/schlecht, wenn ein Unternehmen viele Patches anbringt, regelmäßig und auch den Grund erklärt? Oder vermittelt es dem Nutzer den Eindruck, es wird erst nach und nach am Produkt gearbeitet, ich habe schon einmal die Bezeichnung "Bananaware" gehört, also Software, die beim Kunden reift.


    Du bist Fachkundiger, aber wenn du dich in einen eher unwissenden und potenziellen Kunden hineinversetzt, wie würdest du es sehen?

    Software reift immer erst beim Kunden. Wer etwas anderes Behauptet, der hat noch nie umfangreiche Softwareprodukte auf einen großen Markt geworfen. Selbst mit umfangreicher QA ist es nicht möglich alles Fehler abzudecken. Korrekturen kommen immer und das ist auch gut so. Wichtig ist es dem Kunden das ganze so einfach wie möglich zu machen (Updates finden, installieren). Kapitalfehler sollten wie oben erwähnt natürlich nicht mehr auftreten.


    Brieftauben trotz Trainingseinheiten nicht meine 10 KG-Post bewältigen könnten.

    Post? Papier? Versendest du etwa auch noch Faxe? Sowas tut man doch nicht mehr ^^ Und wo du an der Stelle die PN Funktion erwähnst. Habe schon lange keiner mehr von dir bekommen :P

  • Post? Papier? Versendest du etwa auch noch Faxe? Sowas tut man doch nicht mehr Und wo du an der Stelle die PN Funktion erwähnst. Habe schon lange keiner mehr von dir bekommen



    Fall nicht vom Stuhl, ich schreibe sogar gerne handschriftliche Post und finde im Gegenzug Zusammenarbeiten via TeamView noch immer leicht unheimlich. :D Und Post gibt es sowieso nicht, ich komme direkt am Wochenende bei dir auf der Seite vorbei und knüpfe an das Gespräch an. :) Du weißt ja, ich traue einem Entwickler nur so weit, wie ich ihn im Auge behalten kann, alleine kommt ihr sonst auf komische Ideen oder lungert herum und entwickelt "nur" Plugins... :whistling: :D





    Ich nutze es nun einfach aus, dass du zum Fachklientel gehörst und selber entwicklest, also gerne auch ganz ausführlich und von deinen etwaigen Testreihen erzählen kannst, ja? :)




    Hier muss man immer ganz klar schauen, was man mit dem Plugin wie beeinflusst und wie viele Abhängigkeiten zu anderen Dingen bestehen.



    Kann ich also vereinfacht die These aufstellen: Je mehr Abhängigkeiten ein Produkt hat, desto "größer" ist es. Es richtet sich also nicht explizit und nur nach dem reinen "Innenleben", wie viele Funktionen das Produkt zahlenmäßig besitzt?


    Wie "zähle" ich eigentlich grundsätzlich bei einem Produkt sein "Innenleben"? Zähle ich so, dass wirklich jede Funktion inklusive dann auch solchen Dingen wie Berechtigungen ("Kann X sehen/ändern/wiederherstellen...") einzeln zählt, zählt das "Grundinventar" nicht (wenn du eine Sprachdatei öffnest, siehst du doch auch immer die Dinge, die gleich bleiben, also ist das eine Art "Grundgerüst"?) oder...?




    Kommen wir doch bitte noch einmal zur Alpha- und Beta-Unterscheidung zurück, ich denke, ich habe dazu noch Fragen.


    Kannst du mir etwas vereinfacht beschreiben, wie der "Zustand" eines Plugins im Alpha-Stadium aussehen würde?
    Es ist so, es hakt bei mir mental gerade daran, dass ich bisher entweder in der Konzeptphase dabei war, bei einem Betatest war und dann in der Regel eben das fertige Produkt sehe, aber mir nicht 100% sicher bin, wie ein Produkt in der Vorstufe "aussieht". Ich meine damit, es ist schon ein Plugin, man kann es lokal installisieren, es "macht" etwas und das ist nicht....einfach irgendein Codewust, der für mich komplett unverständlich wäre?



    Die Entwickler sagen nach einem Test früher oder später, dass die Version "stabil" läuft, das heißt dann, das Produkt wirft keine Fehlermeldungen mehr, es wird nicht mehr getestet, die Alphaphase ist abgeschlossen und das Produkt wird zu einer Testversion bereitgestellt, die Nutzer auf eigene Verantwortung testen dürfen? Was beinhaltet "stabil" also genau, habt ihr da als Entwickler eine genaue Definition oder denke ich einmal mehr zu pedantisch, gar falsch?




    Jain. WoltLabs Testart kann man hier gut als Beispiel nehmen. Man lässt die Kunden das Ding einfach benutzen



    Wenn du spekulieren solltest bzw. ich rein deine Einschätzung erfragen würde: Wie hoch ist der Nutzen hierbei - deiner Meinung nach - für WoltLab bzw. die beiden Hauptentwickler (also das Duo Alexander Ebert und Marcel Werk), welchen "Mehrwert" hat es für die Nutzer und siehst du dabei auch den schon von mir eingeworfenen Faktor der potenziellen Kundengewinnung und Eigenwerbung?




    Du schriebst, die heutigen Betatest-Abläufe wären in ihrer Form so durchaus richtig und sinnvoll. Wie bewertest du in diesem Kontext dann die Einbeziehung von einer Option wie Github?




    Hier geht es weniger darum, das ein Test ganz konkret etwas bestimmtes testet, sondern einfach sein System benutzt. Ich teste zum Beispiel hauptsächlich auf einem Linux Webserver. Ein Tester hat vielleicht einen Windows Webserver. Man will also verschiedenste Umgebungseinflüsse testen.



    Hier möchte ich nachhaken.
    - Testet man dabei nach einer Systematik hinsichtlich z.B. die meisten Nutzer nutzen Firefox, also testet man das zuerst, danach X usw.?
    - Würde man bei einem Test auch absichtlich kompliziert vorgehen, eine Art "worst case"-Szenario testen?
    - Sollte man zumindest latent (?) im Hinterkopf den späteren Anwender haben, der nicht so versiert ist wie der Entwickler selber?





    Ein Betatest kann ja nicht unendlich lange laufen, setzt man als Entwickler bereits vorab eine Zeitspanne fest, lässt man es "auslaufen" (bis keine Rückmeldungen mehr kommen) oder richtet man sich nach dem eigenen Gefühl bzw. der Erfahrung?




    Man kann Betatests jetzt durchwegs positiv sehen, aber was ist mit diesen Aspekten bzw. Fragen:


    a) Erhöht der Betatest nicht auch den Druck auf den Entwickler, speziell wenn ein Produkt doch nicht den gewünschten Anklang findet?


    b) Erzeugt eine öffentliche Betaphase nicht noch mehr Druck, weil die Anwender das Produkt nun direkt haben möchten?


    c) Stellt die Betaphase nicht eine zusätzlich sehr zeitaufwendige Phase für den Entwickler dar, weil er/sie eigentlich nur noch mit den Rückmeldungen beschäftigt ist, nicht real am Produkt selber oder anderen Dingen arbeiten kann?


    d) Lenke ich mit einer öffentlichen Betatestphase auch unbewusst/unbeabsichtigt die Leute mit krimineller Energie an? Natürlich, wer sich eine illegale Kopie besorgen will, würde das auch tun, wenn das Produkt dann offiziell erhältlich ist, aber steigert ein Betatest diese Machenschaften oder lässt sich das nicht messen/erkennen?




    Ja, wir haben zu einander gefunden (kann ich das so sagen?), aber wie das immer ist, kommt es auf die Menschen an mit denen man zu tun hat. Denn die bestimmen wie der Test läuft.



    Natürlich kann man das so sagen, das war einfach ein positiver Zufall, wie man es nicht erwartet, aber es daher umso interessanter und schöner macht. :) In diesem Kontext würde ich dich gleich noch anstuppsen und fragen, ob du beschreiben kannst, wie du selber bei einem Betatest vorgehst. Hast du mental eine Art Ablauf oder gehst du willkürlich vor? Nutzen dir deine eigenen Erfahrungen etwas oder blendest du das bewusst aus? Wie entscheidest du, was an Ideen in eine Version integriert werden soll/te, was ist Update-Material? Wie läuft es praktisch bei dir ab - du testest, notierst dir nebenher Punkte oder postest direkt bei Github oder denkst erst darüber nach oder...?







    Fragen über Fragen, eigentlich wäre wohl eine Art Entwicklernachwuchs-Projekt keine schlechte Idee - inklusive natürlich einem großen Bereich für alle Newbies und Interessierten. :whistling: :D Tipps, Erfahrungsberichte, man darf ohne Ende Fragen stellen, vielleicht sogar ein paar nette Übungseinheiten und wenn es ganz super läuft, entwickelt man sein erstes kleines Plugin, kann das später stolz herumzeigen! :D Ähm ja, wieder eine meiner Ideen, ich setze sie auf die Liste. :D

  • Kann ich also vereinfacht die These aufstellen: Je mehr Abhängigkeiten ein Produkt hat, desto "größer" ist es. Es richtet sich also nicht explizit und nur nach dem reinen "Innenleben", wie viele Funktionen das Produkt zahlenmäßig besitzt?


    Wie "zähle" ich eigentlich grundsätzlich bei einem Produkt sein "Innenleben"? Zähle ich so, dass wirklich jede Funktion inklusive dann auch solchen Dingen wie Berechtigungen ("Kann X sehen/ändern/wiederherstellen...") einzeln zählt, zählt das "Grundinventar" nicht (wenn du eine Sprachdatei öffnest, siehst du doch auch immer die Dinge, die gleich bleiben, also ist das eine Art "Grundgerüst"?) oder...?

    Also, hier muss ich wohl etwas mehr ausholen: Wichtig sind nicht die Anzahl einfacher Funktionen, sondern eher wie sehr diese auf einander einwirken, also von einander Abhängen. Um so umfangreicher die Verschachtelung wird, desto größer oder schwieriger ist es alle Fehlerfälle zu finden.


    Kannst du mir etwas vereinfacht beschreiben, wie der "Zustand" eines Plugins im Alpha-Stadium aussehen würde?
    Es ist so, es hakt bei mir mental gerade daran, dass ich bisher entweder in der Konzeptphase dabei war, bei einem Betatest war und dann in der Regel eben das fertige Produkt sehe, aber mir nicht 100% sicher bin, wie ein Produkt in der Vorstufe "aussieht". Ich meine damit, es ist schon ein Plugin, man kann es lokal installisieren, es "macht" etwas und das ist nicht....einfach irgendein Codewust, der für mich komplett unverständlich wäre?

    Hier kann ich mich wohl am einfachsten mit einen Wikipedia Link einer umfangreichen Antwort entziehen: http://de.wikipedia.org/wiki/E…_(Software)#Alpha-Version


    Die Entwickler sagen nach einem Test früher oder später, dass die Version "stabil" läuft, das heißt dann, das Produkt wirft keine Fehlermeldungen mehr, es wird nicht mehr getestet, die Alphaphase ist abgeschlossen und das Produkt wird zu einer Testversion bereitgestellt, die Nutzer auf eigene Verantwortung testen dürfen? Was beinhaltet "stabil" also genau, habt ihr da als Entwickler eine genaue Definition oder denke ich einmal mehr zu pedantisch, gar falsch?

    Naja, man wartet hier einfach bis keine Rückmeldungen mehr kommen. Spielt selber etwas rum & kann dann mehr eigentlich auch nicht machen.


    Wenn du spekulieren solltest bzw. ich rein deine Einschätzung erfragen würde: Wie hoch ist der Nutzen hierbei - deiner Meinung nach - für WoltLab bzw. die beiden Hauptentwickler (also das Duo Alexander Ebert und Marcel Werk), welchen "Mehrwert" hat es für die Nutzer und siehst du dabei auch den schon von mir eingeworfenen Faktor der potenziellen Kundengewinnung und Eigenwerbung?

    Der Nutzen ist hoch, gerade bei Dingen wie dem neuen Editor ist ja sehr viel aus dem Feedback eingeflossen. Auch meine Einwürfe wurden an der Stelle aufgenommen und umgesetzt. Gerade beim Editor etc. sind also Benutzer interessant, da sie alle verschiedene Browser verwenden und der Editor eben in diesem Ausgeführt wird. Kundengewinnung und Eigenwerbung kann an der stelle eine Wirkung sein, muss aber nicht. Hier kommt es denke ich auch auf den einzelnen Kunden an.


    Du schriebst, die heutigen Betatest-Abläufe wären in ihrer Form so durchaus richtig und sinnvoll. Wie bewertest du in diesem Kontext dann die Einbeziehung von einer Option wie Github?

    Mh... Kann ich garnich so viel zu sagen. Für mich macht es Sinn, weil ich Funktionen von Git(-Hub) zu nutzen weiß.


    Testet man dabei nach einer Systematik hinsichtlich z.B. die meisten Nutzer nutzen Firefox, also testet man das zuerst, danach X usw.?

    Meist lässt man die Nutzer einfach machen, sie verwenden das was sie sonst auch verwenden. Meistens hat man damit schon mal alle wichtigen abgedeckt.


    Würde man bei einem Test auch absichtlich kompliziert vorgehen, eine Art "worst case"-Szenario testen?

    Hat man - wie in einer großen Firam - hat man ein Testmanagement. Die machen nichts anderes als Testzsenarien entwerfen, die den Testern dann mit auf den Weg gegeben werden. Das kann man auf jeden Fall machen, muss man aber nicht.


    Sollte man zumindest latent (?) im Hinterkopf den späteren Anwender haben, der nicht so versiert ist wie der Entwickler selber?

    Das ist denke schon vor der Entwicklung wichtig, also dem ersten Entwurfsgedanken. Weil der User muss es ja dann auch verwenden.


    Ein Betatest kann ja nicht unendlich lange laufen, setzt man als Entwickler bereits vorab eine Zeitspanne fest, lässt man es "auslaufen" (bis keine Rückmeldungen mehr kommen) oder richtet man sich nach dem eigenen Gefühl bzw. der Erfahrung?

    Siehe oben ;)


    a) Erhöht der Betatest nicht auch den Druck auf den Entwickler, speziell wenn ein Produkt doch nicht den gewünschten Anklang findet?


    Ich mach mir da keinen Druck, aber man sollte den Anklang und die Wünsche eines Nutzers schon im Vorfeld abfangen.


    b) Erzeugt eine öffentliche Betaphase nicht noch mehr Druck, weil die Anwender das Produkt nun direkt haben möchten?

    Da muss man dann einfach sagen: Pech gehabt :P


    c) Stellt die Betaphase nicht eine zusätzlich sehr zeitaufwendige Phase für den Entwickler dar, weil er/sie eigentlich nur noch mit den Rückmeldungen beschäftigt ist, nicht real am Produkt selber oder anderen Dingen arbeiten kann?

    Sie ist aufwendig aber ein wichtiger Bestandteil der Produktreifung.


    d) Lenke ich mit einer öffentlichen Betatestphase auch unbewusst/unbeabsichtigt die Leute mit krimineller Energie an? Natürlich, wer sich eine illegale Kopie besorgen will, würde das auch tun, wenn das Produkt dann offiziell erhältlich ist, aber steigert ein Betatest diese Machenschaften oder lässt sich das nicht messen/erkennen?

    Deswegen sollte man sich die Betatester selbst auswählen und nicht zwingen einen zufälligen Kreis auswählen. Kunden einer Vorversion und bekannte Gesichter sind da eine gute Wahl. Ich persönlich habe in vielen Projekten Zugriff auf Quellcode und Produkte. Ich teste sie auch, aber es käme mir niemals in den Sinn ohne eine Lizenz andere Produkte - somit also Illegal - einzusetzen. Für mich ein NoGo.


    Natürlich kann man das so sagen, das war einfach ein positiver Zufall, wie man es nicht erwartet, aber es daher umso interessanter und schöner macht. In diesem Kontext würde ich dich gleich noch anstuppsen und fragen, ob du beschreiben kannst, wie du selber bei einem Betatest vorgehst. Hast du mental eine Art Ablauf oder gehst du willkürlich vor? Nutzen dir deine eigenen Erfahrungen etwas oder blendest du das bewusst aus? Wie entscheidest du, was an Ideen in eine Version integriert werden soll/te, was ist Update-Material? Wie läuft es praktisch bei dir ab - du testest, notierst dir nebenher Punkte oder postest direkt bei Github oder denkst erst darüber nach oder...?

    Der Ablauf ist denke ich sehr intuitiv. Ich bau erstmal für mich allein und dann schau ich was nun alles kommen könnte. Die Erfahrung fließt hier ganz sicher auch mit ein. Naja, Dinge die einfach nachgerüstet werden können, baue ich meist mit ein. Alles was zur Integration Anpassungen an anderen Stellen benötigt, wird meist mit einer späteren Version kommen. Ich notier mir Punkte, denke sie kurz durch, meist auch wie man sie umsetzten könnte und Poste sie dann.

  • Hallo,


    ist ja ein sehr interessantes Thema :)


    Kann ich aus dieser Äußerung schließen, du kennst dich damit näher aus und könntest noch ein wenig detaillierter werden, wenn es keine Umstände macht? Genauer gesagt, was an technischen "Drumherum" würde so ein fachkundiger Tester eigentlich noch testen, kann man das stichwortartig festlegen? Es wird vermutlich keine reale Checkliste geben (?), aber wenn du du dich auskennst und doch einige Aspekte notieren könntest, wäre das interessant zu erfahren, z.B. ich habe da null Hintergrundwissen.


    Vor einiger Zeit war ich Betatester für ein CMS (Open Source).
    An den Tests waren fachkundige Tester beteiligt und ebenso Nutzerinnen & Nutzer.
    Der Umgang mit unterschiedlichen Testumgebungen liefern interessante Erkenntnisse und können dann vom Entwicklerteam umgesetzt werden.


    Könntest du das bitte ausführen, kennst du es von einer anderen Software eventuell anders, gar besser bzw. ist das "ungewohnte" Empfinden bei dir eher positiv oder negativ besetzt, lässt es sich aufschlüsseln und du magst etwas berichten?


    Den Einsatz der Betaversionen und Release Candidate auf der Hauptseite empfand ich mindestens als fragwürdig, denn diese könnten Fehler enthalten (oder manchmal völlig unerwartet und die Ursache ist unbekannt).
    Bei einer Größe von über 60.000 Mitgliedern ist eine Verwendung bedenklich, finde ich :alien:

  • Servus ihr zwei,


    ich reize mein Fragenkonto einfach aus und frage weiter, mich interessieren die vielen Details. :)



    Vor einiger Zeit war ich Betatester für ein CMS (Open Source).
    An den Tests waren fachkundige Tester beteiligt und ebenso Nutzerinnen & Nutzer.
    Der Umgang mit unterschiedlichen Testumgebungen liefern interessante Erkenntnisse und können dann vom Entwicklerteam umgesetzt werden.




    Wenn ich dich nicht zu sehr in Beschlag nehme, EM_Jott, känntest du noch ein wenig darauf eingehen, was dir der Betatest gebracht hast, siehst du das auch als Lerneffekt oder bist einfach aus Neugier dabei gewesen oder tatsächlich aus dem Grund, dass du das CMS später selber nutzen wolltest?


    Und du selber, wie bist du vorgegangen, hast du quasi einfach losgetestet, hattest eine grobe Testlinie im Kopf und inwieweit spielte (d)eine mögliche Erwartungshaltung eine Rolle? Sprich, du wirst dich vermutlich vorher schon gefragt haben, wie ein CMS für dich sein sollte/müsste, sahst dann das besagte Produkt - vergleicht man dann Vorstellung-Realität, versucht die eigenen Ideen in die Produkt zu bringen oder trennt man streng, darf das Produkt gar nicht zu einer Art "Wünsch-dir-was"Produkt von einem selber machen?




    Den Einsatz der Betaversionen und Release Candidate auf der Hauptseite empfand ich mindestens als fragwürdig, denn diese könnten Fehler enthalten (oder manchmal völlig unerwartet und die Ursache ist unbekannt).




    Diese Punkte finde ich nun interessant, denkst du, man sollte solche Versionen eher den routinierten Personen zum Testen gehben, nicht so den "normalen" Nutzern? Oder gehst du gar einen Schritt weiter und würdest es professioneller (?) finden, wenn gar externe Tester die Produkte auf Herz und Nieren prüfen, die dann für unbedenklich eingestufte finale Version erhalten die Nutzer?


    Man könnte nun sagen, bei RC-Versionen wird ausdrücklich gesagt, sie dürfen nicht in den produktiven Einsatz übernommen werden, trotzdem findet man dann Hilferufe von Leute, die genau das taten. Die einen sagen dann "selber schuld", andere monieren, es wäre nicht ganz verantwortlich von den Herstellern - wie siehst du das?


    Was ist eine Betatestversion eigentlich für dich von der Wahrnehmung her? Siehst du eher den Effekt, dass Kunden eingebunden werden sollen, oder denkst du mehr in Richtung Marketing/Kundenbindung/Kundengenerierung?




    @[FFW]Patric, ich denke, ich habe ein Problem mit der Vorstellung von diesem Punkt:


    Also, hier muss ich wohl etwas mehr ausholen: Wichtig sind nicht die Anzahl einfacher Funktionen, sondern eher wie sehr diese auf einander einwirken, also von einander Abhängen. Um so umfangreicher die Verschachtelung wird, desto größer oder schwieriger ist es alle Fehlerfälle zu finden.



    - Was ist eine "einfache" Funktion?
    - Irgendwie stehe ich auf dem Schlauch, könntest du mir bitte einfach und vielleicht gar anhand eines Beispieles (nimm ruhig ein Plugin von dir, wenn das schneller geht) das mit der "Verschachtelung" erklären? :keks: :blume:




    Patric, danke für den Link zur Alpha-Erklärung, kannst du aber auch gleich sagen, wann eine Pre-Alpha Version sinnvoll wäre, wer so etwas nutzt, nutzen muss (?) oder ist das eher etwas für Unternehmen, um vorab Kaufinteresse zu schüren?




    Übrigens, im Text findet sich auch die Definition für "stabil", es geht dabei nicht um versiegende Fehlerrückmeldungen, sondern bedeutet, dass nichts mehr geändert wird. Es heißt wörtlich:


    Zitat

    Stable (steht) für eine stabile Version, die nicht mehr verändert wird

    http://de.wikipedia.org/wiki/E…_(Software)#Alpha-Version


    Wobei ich mich frage, bezieht sich das auf den Code, die Funktionen, beides oder X? Das geht aus dem Text nicht hervor, weißt du das spontan?




    Hat man - wie in einer großen Firam - hat man ein Testmanagement. Die machen nichts anderes als Testzsenarien entwerfen, die den Testern dann mit auf den Weg gegeben werden. Das kann man auf jeden Fall machen, muss man aber nicht.




    Nun wird es spannend, kannst du das bitte ausführen, mehr erzählen, wie kann ich es mir vorstellen? Was wären das z.B. für Testszenarien, was sind "worst case"-Beispiele, kann man das theoretisch klar beschreiben, gibt es gar eine Liste auf der so etwas steht? Und bezieht es sich mehr auf die Technik, auf den Anwender, beides oder...?






    Was haltet ihr beiden eigentlich in diesem Kontext von Projekten wie dem "Beta Testers Hub" (http://betatestershub.com/)? Startups erhalten Feeback, die Betatester bekommen Einblicke und ewtaige Lizenzen, ein Premiummodell ist angedacht und Werbung bringt es für das Produkt/Unternehmen natürlich auch. Ist so ein Modell einfach der nächste Schritt oder klingt spannender als es real ist?

  • - Was ist eine "einfache" Funktion?
    - Irgendwie stehe ich auf dem Schlauch, könntest du mir bitte einfach und vielleicht gar anhand eines Beispieles (nimm ruhig ein Plugin von dir, wenn das schneller geht) das mit der "Verschachtelung" erklären?


    Nahmen wir hier einfach den Shop von Peter. Du hast ein Produkt, das der Kunde kaufen kann, zu einem festgelegten Preis. Ist erstmal eine einfache - allein stehende - Funktion. Dazu kommt dann jetzt die Funktion eine Steuer angeben zu können. Weil ein einfacher Steuersatz ja langweilig wäre, muss diese ja variabel nach Land automatisch ermittelt werden. Dazu kommt dann noch die Zahlart. Die legt ja eventuell noch Gebühren fest. Mache ich nun einen Fehler in der Implementierung, mit der man ein Produkt anlegt - also auch den Preis angibt - so kann dies dazu führen das dies einen Einfluss auf die Steuerberechnung oder die Gebührenberechnung hat.


    Patric, danke für den Link zur Alpha-Erklärung, kannst du aber auch gleich sagen, wann eine Pre-Alpha Version sinnvoll wäre, wer so etwas nutzt, nutzen muss (?) oder ist das eher etwas für Unternehmen, um vorab Kaufinteresse zu schüren?

    Sowas nutzt keiner, sondern wird nur installiert um zu schauen ob der aktuelle Entwicklungsstand das tut was er soll. Diese Version ist absolut instabil, viele Funktionen funktionieren entweder nicht oder nicht vorhanden etc.


    Wobei ich mich frage, bezieht sich das auf den Code, die Funktionen, beides oder X? das geht aus dem Text nicht hervor, weißt du das spontan?

    Das bezieht sich auf den Funktionsumfang bzw. das Klassendesign im Code (auch API genannt). Heißt in dieser Version werden nur noch Fehler behoben etc.


    Nun wird es spannend, kannst du das bitte ausführen, mehr erzählen, wie kann ich es mir vorstellen? Was wären das z.B. für Testszenarien, was sind "worst case"-Beispiele, kann man das theoretisch klar beschreiben, gibt es gar eine Liste auf der so etwas steht? Und bezieht es sich mehr auf die Technik, auf den Anwender, beides oder...?

    Naja, unsere Entwickler schreiben ein Software, unsere Operator nehmen das Online, sobald die Entwickler meinen es sei soweit. Sollte bis hierhin alles Fehlerfrei verlaufen sein, ist das schon mal gut. Dann gibt es eine Abteilung die sich im Vorfeld schon Gedanken gemacht hat, was ein Kunde wie vielleicht (falsch) machen könnte. Was ein Kunde alles tut und möchte. Darüber werden Testszenarien geschrieben. Dann geht das ganze zur QA und wird dann in Eigeninitiative und anhand der Testszenarien getestet. Diesen Umfang können sich meist aber nur größere Firmen leisten, bei uns sind das ganze Bereiche und eine Vielzahl von Abteilungen.


    Was haltet ihr beiden eigentlich in diesem Kontext von Projekten wie dem "Beta Testers Hub" (betatestershub.com/)? Startups erhalten Feeback, die Betatester bekommen Einblicke und ewtaige Lizenzen, ein Premiummodell ist angedacht und Werbung bringt es für das Produkt/Unternehmen natürlich auch. Ist so ein Modell einfach der nächste Schritt oder klingt spannender als es real ist?

    Kenne das Projekt nicht. Ich stelle mir nur vor das es schwer sein könnte Tester aus der richtigen Zielgruppe zu finden.