1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen
  2. Da ist es nun endlich, unser neues Forum. Log dich einfach mit deinen gewohnten Userdaten ein und leg los.

    Change the language

Wann fängt die Qualitätssicherung bei Unbended an?

Dieses Thema im Forum "Allgemeines zu Unbended" wurde erstellt von Mr.B, 17 September 2015.

  1. .... grins... und wie viele sind es konkret jetzt bei Unbended? :happy:

    OK, die Frage ist zwar ernsthaft, aber ich erwarte da jetzt nicht wirklich eine Antwort.
    Außerdem hält mich das grade alles vom zocken ab, aber Skyforge unterstützt 15 Minuten lang "raus und rein" ohne am "Geschehen" zu sterben oder Questverlust (wenn man richtig steht) . Ist das nicht nett bei einem MMO? :D
     
    Zuletzt bearbeitet: 20 September 2015
  2. frentmeister

    frentmeister Administrator Administrator

    Aktuell 13...ist ja kein Geheimnis nur weil einige hier nicht auf der Seite sind....^^

     
    SX255 gefällt das.
  3. Und wieder klingelt bei mir der „Postbote“ … du schon wieder:jawdrop:

    Bei 13 Leuten solltet ihr zumindest auf die „Sacred 1 Teamstärke“ aufstocken und noch jemand
    in´s Boot holen.

    13 ist einfach keine gute Zahl.:eek:

    OK, jemand aus dem Team nehmen wäre natürlich auch eine Überlegung wert :whistle: :angelic: :ROFLMAO:
     
    Zuletzt bearbeitet: 21 September 2015
    Dorimil gefällt das.
  4. und...was ist aus der Ankündigung geworden, daß es in der letzten Woche weitere News hätte geben sollen?:sneaky:

    News vom 13.09. "Weitere Informationen gibt es in der kommenden Woche" :p
     
  5. Wer sowas am Sonntag den 13.9. sagt, wird mit der Präzision der deutsche Sprache konfrontiert :p
    @Dorimil - Bruder im Geiste ;)
    Eigentlich ist Scrum an allem schuld. Da drin wird die Community einfach noch nicht geführt. Da gibt es keine Sprints für die Community – nein, eher Trippelschritte.
    Ähnliches sollte es eben auch für den Bereich „Kontakt zur Community“ geben. Da es den aber offensichtlich noch nicht gibt, sollte er schnellsten eingerichtet werden, weil es sonst mit den Trippelschritten einer Taube einfach so weitergeht und selbst die hartgesottensten User (dazu zähle ich mich) ihr Interesse für das Spiel und die Foren, verlieren werden. :sorry:
    Also nutzt Scrum auch mal für die Community, erweckt die Communiy zu neuem Leben, "bindet" Leser an euch, macht sie alle neugierig, füttert sie, haucht ihnen Leben ein......... oder........ ich geb´s auf :sick:
     
  6. s0nderv0gel

    s0nderv0gel Imperator Moderator

    Die wilde 13 :D (die eigentlich 12 sind, aber ich schätze mal, dass die Devs dennoch zählen können ;))
     
  7. .....grins .... ich zähle auch nur 12.
    Die Dev´s können ja vielleicht noch zählen, aber Frankie?? :ROFLMAO: :giggle:
     
  8. s0nderv0gel

    s0nderv0gel Imperator Moderator

    War eigentlich eine Anspielung auf Jim Knopf, die Dev-Seite hab ich gerade nicht vor Augen.
    Aber BTT:
    Ich denke (und vor allem hoffe), dass es, sobald mal wieder mehr Schwung in die Bude kommt, wieder mehr Kontakt zur Community gibt, nicht nur über das Communityteam. Sehr schön wäre wirklich die Variante, einfach mal ein paar Skizzen oder Gedanken zu äußern, und zu fragen, was man als Ottonormaluser davon hält. Ist ja auch eine Art der Qualitätssicherung :)
     
  9. frentmeister

    frentmeister Administrator Administrator

    Leute, Leute 13 ist die Anzahl der Leute die Entwickeln, wir sind viele, vielleicht nicht Anonymous aber wir sind viele!
     
  10. Ach Frankie, lass dich doch nicht aus der Ruhe bringen. Bist doch unser Bester. :-*[​IMG]
     
  11. frentmeister

    frentmeister Administrator Administrator

    Ne ich bin ja entspannt :)
     
  12. Tiefenentspannt wie @red asunder,? - den ich irgendwie vermisse seit seinem Gig.
     
  13.  
    frentmeister gefällt das.
  14. frentmeister

    frentmeister Administrator Administrator

    @.dAb. Andere Möglichkeit: Tests direkt in den jeweiligen Sprint mit einbeziehen. 2-3 Tage vor Sprintende. Entwickler mit eingebunden, ansonsten schon mal neue Storys beginnen. Wenn das jedoch für die Tests nicht ausreicht, dann wäre das andere System wohl doch besser.

    Davon solte man ja ausgehen, Scrum ohne geplanten Test intern ist ja kein Scrum ;) Nur was nützen dir solche kleineren Test im Sprintrythmus von 2 Wochen wenn du damit intern eh kaum Systeme hast. Für einen großen Umfangreichen Test sollte entsprechend ein geplanter Systemtest eingeplant werden, kannst du im übrigen sogar als eigenständigen Sprint planen(wäre mal was...)

    Muss... Scrum bedeutet ja nicht nur, dass das Team nur entwickelt. In einem Scrumteam muss natürlich auch getestet werden. Wenn man das obige System wählt, müssen natürlich auch die Testfortschritte im Daily besprochen werden.


    Richtig, nur wie gesagt ein großer entscheidenen Input wirst du damit ja nicht erreichen. Scrum bietet ja über die Sprintplanung genügend Freiraum zum Testen, jeder Task wird entsprechend mit einem Test versehen. Und muss entsprechend bis zum nächsten Sprint natürlich abgenommen sein.

    Von Anfang an oder nie. Modultests müssen zeitnah stattfinden. Sinnigerweise zusammen mit einem täglichen Deploy des Programms. Am Ende, vor allem von großen Projekten, ist der Aufwand viel zu groß. Am Ende heißts wahrscheinlich eh, zur Not nehmen wir den eingeplanten Zeitraum für die automatisierten Tests lieber als Buffer für Bugfixes oder Features, die noch schnell reinmüssen.

    Unit und Modultest, ja alles wichtig aber wie so Entwickler sind faules Pack, was dann sich standhaft weigert Unit Test zu schreiben. Die Realität, sieht faktisch so aus das man Entwickler zu ihrem Glück zwingen muss. Die meisten sind eben versnopte Diven und brauchen manchmal einen kräftigen Arschtritt. Ansonsten Sikuli, und weiter Automatisierung natürlich gerne, als Zusatz. Sonst nur klassisch Manuelles! Halte ich persönlich mehr von, da du eben auch immer nur den Code überprüfst und ist der Verhanden, kann es trotzdem falsch sein.

    Jo, wie oben geschrieben. Selbst kleinere Bugs sollten immer zeitnah behoben werden. Am Ende gibts immer wichtigeres zu tun und sie fallen aufgrund der Prio unten runter. Oder andere Bugs sorgen nur für noch weitere Folgefehler.

    Scrum = Freatues vor Bugs, Realität sieht immer anders aus...Zeitdruck! Oft genug erlebt, Features werden reingeprügelt, kleinere Fehler -> trag das mal mit niedriger Prio ein....bla bla
     
  15. s0nderv0gel

    s0nderv0gel Imperator Moderator

    OT: AAAAAAH, DIE FARBEN!

    BTT:
    Danke für die Ausführungen zu Scrum, bin da nicht wirklich bewandert.
     
  16. Dieser Block wirft aber ein schlechtes Licht auf die Entwickler. Schon mal was von Testgetriebener Entwicklung gehöhrt? Erst den Test schreiben, der natürlich fehl schlägt, und dann den Code der getestet werden soll (das klassische Rot, Grün, Rot entwickeln). Wo ist also das Problem? Faulheit? Diven verhalten? Alles ausreden. Ihr wollt eine Idee zum Leben erwecken! Und dann in alte Muster fallen? Von der ersten Bekanntgabe bis jetzt sind eineinhalb Jahre vergangen, Zeit genug aus der Vergangenheit seine Schlüsse gezogen zu haben.
    Ihr habt Erwartungen geweckt, also macht das Richtige daraus. Bitte!
     
  17. frentmeister

    frentmeister Administrator Administrator

    Verwechsel meine 15 Jahre Erfahrung bitte nicht mit aktuellen Erfahrungen oder Projekten, ich rede hier über nichts anderes als Erfahrungen. Du willst hier etwas unterstellen was gar nicht Sinn des Post ist, kann man auf jede einzelne Firma beziehen. Wir diskutieren hier nur über Projekte, die gelaufen sind oder entsprechende Erfahrungen. Sollte man sich aber denken! Also wenigstens auf diesen Block, dann gibt es ja noch die Diskussion wie es laufen könnte :)

    Aktuelle Planungen, beziehe ich natürlich NICHT auf diesen Post, das läuft anders!

    Oder muss ich jetzt bei jedem Post reinschreiben -> ES HAT NICHTS MIT UNBENDED ZU TUN...weil dann verlinke ich nur noch meinen Blog hier als Antwort ;)

    Also, scheinbar hast du aber nie in der Entwicklung gearbeitet, wie oft die Sätze gefallen sind "Och ne muss ich wirklich hier einen Unit Test schreiben", endlose Diskussionen und nein nicht nur bei Ascaron. Und soll ich dir was verraten, da gab es das sogar!

    Ascaron hat "Scheiß viele" Fehler gemacht, aber nicht alles war schlimm.... :)

    Wir können aber gerne mal über Automatisierung diskutieren, könnte interessant werden.

    Dazu empfehle ich folgende Lektüre und gebe zu bedenken ich schreibe jeden Tag diverse Testfälle in Selenium, in Verbindung mit Sikuli. Bin also nicht abgeneigt dazu zu Automatisieren ;)

    http://www.gamedevportal.com/2015/08/24/sikuli-tricks-tipps-und-tutorials/
    http://www.gamedevportal.com/2015/0...ker-automatisch-hand-in-hand-teil-1-selenium/
    http://www.gamedevportal.com/2014/06/26/tutorial-testen-mit-selenium/
    http://www.gamedevportal.com/2015/02/06/testautomatisierung-mit-sikuli/
     
    Zuletzt von einem Moderator bearbeitet: 23 September 2015
  18. Bei uns ist es Pflicht die Dinger zu schreiben. Gehört zu jeder User Story dazu. Werden dann auch jede Nacht auf jeder neuen Version ausgeführt. So kann man manche Fehler sehr zeitnah entdecken. Vor Scrum gabs das aber auch nicht wirklich. Haben wir mit Scrum nun auch fest eingeführt.

    Hier mal ein kleiner Einblick wie das bei uns mit dem Test läuft:
    1) Entwicklertest: Nach Beendigung eines Tasks durch den Code-Reviewer, außerdem nächtliche Unittests
    2) Userstorytest: Nach Beendigung einer User Story, heißt es muss auch Testfälle dazu geben
    3) Sprinttest: Am Ende eines Sprints im Gesamtsystem, auch Teilregression
    4) Releasetest: Am Ende des Projektes, eigener Sprint
     
  19. frentmeister

    frentmeister Administrator Administrator

    Bei uns nicht anders, inkl. einem sehr guten Sprintmeeting ende des Sprints mit zeigen was gelaufen ist.
     
  20. Jo, Review und Retro müssen ja sein.