[Spieletests] - Werkzeuge und Verfahrenweisen

[Corti]

Dieses Topic soll als Sammlung hilfreicher Werkzeuge und Tipps zum Thema Testen dienen.

Kleine Fehler, wie falsches Clipping auf der Map, oder ein kleiner Rechtschreibfehler kommen immer wieder vor und das nicht zu selten. Um dem Spieleersteller auf den Fehler hinweisen zu können, muss beschrieben werden, wo dieser auftritt. Im Falle eines Rechtschreibfehler müsste man also fast die Textbox abschreiben um die Information mit zu geben, an welcher Stelle der Fehler zu finden ist. Bei Clippingfehlern wäre es eine ungefähre Beschreibung wann und wo und eigentlich ist das zeitaufwändig und nervig.

Angenehmer ist es da, einen Screenshot zu machen. Das geht zwar schneller, ist aber auch nervig wenn man es öfter macht. Drucktaste, einfügen, abspeichern, ihr kennt das. Im besten Falle, sollte das Dokumentieren von Fehlern komfortabel von der Hand gehen. Pragmatische Lösung war für mich ein Programm, dass per Tastendruck Screenshots macht und diese direkt in einern Ordner speichert. Ich möchte euch hier ein solches Programm vorstellen.

Greenshot:
Ist ein freies Open Source Programm. Es gibt einige dutzend Programm die dasselbe können. Dieses hier kann genau was es können muss und hat dabei keine Einschränkungen, Wasserzeichen, erfordert keine Registrierungen und verteilt keine Addware.
Download: getgreenshot.org

Allgemein:
Wichtig ist hier nur die Tastenkombination um das aktive Fenster zu fotografieren.

Abfotografieren:
Ich habe bei mir die Verzögerung zur Aufnahme entfernt.Der Kameraton ist Geschmackssache.

Ausgabe:
Das Ausgabeverzeichnis war bei mir ursprünglich auf Desktop gestellt. Das Bildformat sollte danach gewählt werden, was man mit den Bildern vorhat. Als Betatester, der viele Bilder macht und diese danach verschicken möchte, kann man JPG nehmen. PNG eigent sich dagegen gut, wenn man die Bilder präsentieren möchte, zB im Forum. BMP kann für Testspieler auch Sinn machen, denn BMPs lassen sich von Archivierungsprogrammen sehr gut verkleinern.

Ziele:
Ohne weitere Einstellung würde nach einem Screenshot ein Dialog erscheinen, der abfragt, was mit dem Bild geschehen soll. Zum Spieletesten sollte das Bild aber ohne Rückfrage abgespeichert werden. Sofort speichern zu wählen, ist also sinnvoll.

Screenshots machen beim Spiele mit Gamepad:
Das Programm JoyToKey werden die meisten sicherlich schon kennen. Es übersetzt Gamepad-Aktionen in Tasten-Aktionen um Spiele, die keine oder nur beschränkte Gamepad unterstützung haben mit einem solchen spielen zu können. In JoyToKey kann man auch Tastenkombinationen auf Gamepadtasten belegen. Das Programm ist Shareware, ein Kauf ist aber nicht nötig um es umfassend benutzen zu können.
Download: JoyToKey.net

Diskussion zu Erfahrungen und Tipps zum Testen:
Wenn ihr was testet: wie haltet ihr fest, was euch auffällt?
Wenn ihr etwas testen lasst: Habt ihr Anforderungen wie oder was ihr speziell betestet und kommentiert haben wollt?
Hat einer von euch schonmal mit Fragebögen gearbeitet um Sachen direkt ab zu fragen?

Ich will alles wissen, wie ihr testet oder testen lasst. Welche Werkzeuge ihr benutzt, und genau so was euch beim Testen am meisten stört und nervt.

[Schnorro]

Jo Corti,

dann schildere ich einmal, wie ich bei Betatests vorgehe. Danach gehe ich auf die von dir genannten Vorschläge ein.

Je nachdem welches Format der Entwickler / die Entwicklerin gerne hätte, nutze ich .doc (Word) / .odt (Open Office) / .pdf (Adobe).
Da das pdf aus einem der beiden vorstehenden Dateitypen besteht, gehe ich auch nur auf die ein und da die komplett identisch sind, reicht eine Beschreibung.

1.)
Kurze Einleitung, in der ich meine(n) Auftraggeber(in) grüße und erläutere, wie ich vorgehe und was ihn/sie im Folgenden erwartet. Dies umfasst max. zwei Seiten, eher eine. In dieser Einleitung schildere ich, worauf ich wert lege, welche Fehler ich wie beschreibe. So kann der/die Entwickler(in) direkt die Fehler zuordnen und muss sich nicht erst fragen, in welche Kategorie das gehört.
Momentan nutze ich folgende Kriterien:
- Positionsfehler: Es kann sich um die Position des Helden oder einer Grafik handeln. Beliebtes Beispiel sind die genannten Clipping-Fehler oder andere Dinge, die Fehl am Platz sind.
- Rechtschreibfehler: Egal ob Rechtschreibung, Grammatik oder andere Fehler in Bezug auf das geschriebene Wort.
- Einheitlichkeit: Wenn an einer Stelle etwas beschrieben wird und an einer anderen Stelle die gleiche Sache anders beschrieben wird, dann liegt keine Einheitlichkeit im Spiel vor. Z.B. wird in Tutorials der Spieler nie direkt angesprochen, eher von "man kann dies und dies tun" und später wird auf einmal in die "Du-Form" gewechselst - "Du kannst dies und dies tun"
- Schönheitsfehler: Das sind Dinge, die weder falsch sind noch den Spielfluss beinträchtigen. Hier handelt es sich eher um Dinge, die mich persönlich stören und die ich auch so anspreche. Eine Notwendigkeit, diese zu ändern, besteht nicht.
- Allgemeine(r) Frage / Fehler: Alles was sonst noch so falsch ist und in keine Kategorie passt, kommt hier hinein. Technikfehler, Sinnfehler im Spiel oder andere Dinge.
Wenn ich eine neue Kategorie hinzufüge, erwähne ich sie auch noch einmal in der Einleitung.

2.)
Auflistung der mir aufgefallenen Dinge. Ich nummeriere die genutzten Seiten, gebe jedem Report eine Nummer (sprich wenn ich drei Dateien habe tragen diese die Nummern 1-3) und versehe jeden Eintrag von mir mit einer laufenden Nummer. So kann bei Rückfragen schnell gesagt werden. Report Nr. 2, Seite 5, Fehler Nr. 9. Dann kann ich dazu schnell einen Kommentar abgeben, wenn der/die Entwickler(in) nicht genau weiß, was ich gemeint habe.
Jeder einzelne Punkt ist, wie bereits geschildert, nummeriert. Dann verpasse ich als erstes dem Fall eine Kategorie, die unter Nr. 1 genannt wurde. So ist direkt erkennbar, welcher Fehler folgt. Ist ein Screenshot notwendig, wird dieser dann direkt darunter platziert. Wenn der Screenshot alleine noch nicht ausreicht, wird noch mit einem Stift die entsprechende Stelle gekennzeichnet. Unter dem Screenshot wird dann ein Erläuterungstext geschrieben, der den Sachverhalt schildert. Wie es dazu gekommen ist, wo er auftritt, wie die Lösung aussieht usw... . Je nach Sachverhalt fällt die Erläuterung kürzer oder länger aus.

3.)
Am Ende eines Reports füge ich noch eine Anlage bei. In dieser Liste ich Dinge auf, die möglicherweise öfters auftreten und für die ich keine Screenshots gebrauche. Z.B. eine Aufzählung von wiederkehrenden Dingen. Wird selten benutzt, kommt aber zum Einsatz.

4.)
Damit ist dann mein Report abgeschlossen und wird in dem gewünschten Format dann weitergeleitet.

So ist mein Report aufgebaut. Hoffe das ist einigermaßen verständlich.
Nun zu deinen angesprochenen Punkte.

Greenshot:
Klingt für mich sehr umständlich. Ich spiele Maker-Games im normalen Vollbildmodus, die Grafiken werden also auch mit dem kleinen Format aufgenommen und verstopfen mein Dokument nicht. Ablauf bei mir: Ich sehe eine Stelle, die falsch ist. Dann drücke ich auf "Druck", tabbe in Word und drücke Strg+V, und schon ist das Bild an Ort und stelle. Die oben, unter Punkt 2.) genannten Dinge einfügen und schon geht es weiter mit dem Spiel. Problematisch kann es nur dann werden, wenn es sich um eine Cutszene handelt, die automatisch läuft. Weiß gerade gar nicht, ob die Sequenz im Maker weiterläuft wenn man tabbt oder ob sie unterbrochen wird. Wenn sie unterbrochen wird, ist meine Lösung in meinen Augen immer noch angenehmer.

Gamepad:
Benutze ich nicht, daher entfällt dieser Punkt.

Sonstiges:
1.)
Wie ich teste habe ich ja bereits geschildert.

2.)
Wenn ich mein Spiel testen lassen wollte, dann würde ich die gleichen Erwartungen an meine Tester haben, die ich selber habe. Alles auf den Kopf stellen und nachforschen. Vielleicht noch in ein paar Kategorien einteilen. Einmal "Alles-Tester", einmal "Speed-Runner", einmal "Normal spielen" usw..., damit man auch erfährt, wie das Balancing ist und wie lang das Spiel normal dauert.

3.)
Fragebögen habe ich noch nie benutzt. Weder ich als Tester noch ich als Entwickler. Würde ich auch nicht drauf zurückgreifen, da ich denke, es würde die Tests einschränken.

4.)
An Programmen nutze ich wirklich nur Open Office um meine Berichte zu schreiben. Jeden Screenshot mit einem Bildbearbeitungsprogramm zu ändern würde viel zu lange dauern.

Hoffe, es ist das, was du in ungefähr hören wolltest

[MagicMaker]

Wenn ihr was testet: wie haltet ihr fest, was euch auffällt?

...

Ich fahre seit Jahren ganz gut damit, Screens in einem großen Bild zu sammeln, bis eine gewisse Menge
(bestimmt sich durch Screengröße) drin ist, danach kommt das nächste. Mein Haupt-Testbereich ist in
Sachen Rechtschreibung/Grammatik, sowie Lesefluss, Formulierung, Ordnung und abgeschnittene Zeichen,
entsprechend kritzel ich dann in den Textboxen herum (was bei RPG2000/2003 leider eher schlecht geht,
weil so klein) und schreib noch eigenes Zeug daneben/drüber/drunter.

Dauert allerdings auch verdammt lange. Wer von mir Dialoge mit vollem Programm durchgeguckt haben will,
die schon in nem Spiel und nicht in einem Dokument sind, kann eine halbe Ewigkeit auf das Ergebnis warten.
Und bei meiner letzten großen Testerei hab ich selber gemerkt, wie unbequem das werden kann. Deswegen
meld ich mich auch nicht zu Sachen an, die mir für mein eigentlich schon zu gründliches Vorgehen bei weitem
zu gering erscheinen, Dark Sword beispielsweise auch (uuund weil mir gerade allgemein nicht nach Testen ist).

Erst einen Haufen Screens zu speichern und nachher zu bearbeiten, wäre theoretisch vielleicht auch schneller,
aber dann habe ich keinerlei Kontexte mehr und krieg nicht mehr zusammen, was da nicht gestimmt hat.

[Davy Jones]

Am einfachsten geht es mit Snagit (Screenshotprogramm), Version 8 oder höher. Hotkey festlegen (bspw. Taste Z), den Ordner festlegen wo die Screenshots gespeichert werden sollen und los gehts.

- Spiel anschmeißen
- Oh, ein Fehler: Taste Z drücken, weiterspielen. Nichts wird unterbrochen.
- Nach dem Zocken werden die Bilder ins Grafikprogramm gezogen und mit dem Tool Text einfügen wird mit kontrastreicher Farbe ins Bild reingeschrieben, was falsch gelaufen ist oder besser gemacht werden kann.
- Wenn der Hintergrund der Screenshots zu obskur ist, um jegliche Schrift zu erkennen, reicht auch ein Textdokument mit Screenshot-Nr. und Beschreibung.
- Alles mit Winrar packen, bei Dropbox hochladen o. per Messenger versenden, fertig.

[Eddy131]

Tatsächlich hab ich bisher noch keinen Spieletest mit Screenshots angereichert.
Noramlerweise läuft das bei mir so ab: auf der linken Hälfte hab ich das Spiel in einem kleinen Fenster geöffnet. Auf der rechten ist Word angedockt. Ich Spiel und sobald mir ein Fehler (jeglicher Fehler, auch Designentscheidungen die ich unglücklich finde) auffällt pausiere ich (bei den meisten Makern bleiben ja sogar die Cutscenes stehen, wenn man das Fenster nicht mehr als aktives Fenster hat. Sehr vorteilhaft) und beschreibe den Fehler so gut ich kann. Bei Textfehlern schreib ich auch schon mal die gesamte Textbox ab und markiere dann die geänderte Stelle (bzw schreibe meine Vorschläge für eine bessere Formulierung hin).
Ich sortiere die Fehler auch nicht nach Themen, sondern bleibe Chronologisch. So finde ich, kann der Entwickler einfach nachvollziehen wann genau der Fehler auftaucht. Ich versuche dabei dann das Spiel in kürzere Abschnitte einzuteilen, falls der Ersteller das nicht selbst schon gemacht hat (Etwa: Intro | Kerker | erster Kampf | Flucht aus Burg | Pfad zum Wald etc.), je nachdem auch, wie viele Fehler immer auftauchen und wie sinnvoll man die Scenen aufteilen kann.
Selbst Menüfehler kommen dann, wenn sie auftauchen. Daher ist ein Teil meines ersten Abschnitts auch immer eine Bewertung/Fehlersuche des Menüs, also alle Items, Fähigkeiten etc. werden auf (Spiel-)Logik und Rechtschreibung überprüft.

Aber ich denke, dass ich bei meinem nächsten Test auf jeden Fall auch Screenshots verwenden werde. Nachdem ich einige andere Testberichte hier im Forum gelesen habe, ist mir der Vorteil davon aufgefallen. Gerade bei längeren Texten mit vielen Fehlern oder auch bei großen Gebieten ist es so einfacher anzuzeigen, wo der Fehler ist. Reine Beschreibungen können da auch in die Irre führen, weil es im Wald viele Bäume gibt und es daher schwierig sein kann genau zu beschreiben, welchen man meint

Gibt es denn auch ein Screenshot-Programm, dass ein inaktives Fenster fotografiert? Damit der Pausenstatus erhalten bleibt (Bei selbstablaufenden Texten sehr nützlich).

Was ich von dem Entwickler erwarte, dessen Spiel ich teste: Es sollte nicht pre-Alpha-Status haben.
Meinen ersten Test habe ich abgebrochen, nachdem ich 5 Seiten Text über Fehler verfasst habe und gerade mal das Intro und 5 Minuten Spielzeit hatte. Und das ist eher noch zu lang geschätzt.
Weil als Tester will ich nicht das Spiel von einem schnell hingeklatschten irgendwas zu einem spielbarem Werk umwandeln, sondern Fehler ausfindig machen, die der Ersteller übersehen hat und meine Meinung aus einer anderen Sicht wiedergeben, damit der Entwickler ein Umfangreicheres Bild seines Spieles hat.
Wenn es bei einem Test nicht um das Gesamtwerk sondern nur um einen Teilaspekt geht - etwa das Kampfsystem - , dann kann der Rest ruhig noch sehr schlecht und irgendwie sein und voller Clipping und Rechtschreibfehler. Die werden dann aber auch nicht beachtet, da es ja nur um das Kampfsystem geht.

So, meine Gedanken dazu, wie ich bewerte und was ich von Entwicklern erwarte, deren Werke ich bewerten soll

[Yenzear]

Wenn ihr was testet: wie haltet ihr fest, was euch auffällt?

...

Ich mache einen Screenshot, kopiere diesen in eine rtf. Datei und schreibe etwas dazu

Wenn ihr etwas testen lasst: Habt ihr Anforderungen wie oder was ihr speziell betestet und kommentiert haben wollt?

...

Das kommt auf die Art des Tests an. Bei einem normalen Test des gesamten Programms lasse ich mir alles auflisten was aufgefallen ist. Wenn es nur eine spezielle Funktion ist, die ich testen lassen will wie ob ein Picturemenü flüssig läuft, dann will ich nur dazu Feedback.

Hat einer von euch schonmal mit Fragebögen gearbeitet um Sachen direkt ab zu fragen?

...

Ich noch nie. Es gab maximal rückfragen an die Tester falls mir deren ausführungen nicht ganz klar sind etc.

Ich will alles wissen, wie ihr testet oder testen lasst. Welche Werkzeuge ihr benutzt, und genau so was euch beim Testen am meisten stört und nervt.

...

Ich teste wie gesagt, indem ich das Spiel "spiele". Dabei suche ich allerdings intensiver nach Fehlern wie Begehbarkeitsfehlern als wenn ich einfach nur normal Spiele. Festgestellte Mängel werden von mir mittels Screenshot festgehalten und in einem rtf.Dokument mit einem Kommentar versehen. So ein Dokument kann schon mal 50MB groß werden, vielleicht nicht die ressourcenschonendste Methode ^^"
Nerven tut mich meistens nur, wenn ich ein gutes Spiel teste, ich es nicht einfach nur gechillt zocken und genießen kann, sondern das Ganze in Arbeit ausartet ^^"

[Kelven]

Wenn ihr was testet: wie haltet ihr fest, was euch auffällt?
Ich halte alles stichpunktartig in einer Textdatei fest. Die ausführliche Version gibt es dann per PM, es sei denn es wird ein anderes Format gewünscht.

Wenn ihr etwas testen lasst: Habt ihr Anforderungen wie oder was ihr speziell betestet und kommentiert haben wollt?
Nein, das überlass ich den Testern. Gut, in Textform sollte der Bericht schon sein, Videos würde ich nicht akzeptieren.

Hat einer von euch schonmal mit Fragebögen gearbeitet um Sachen direkt ab zu fragen?
Noch nie.

Ich will alles wissen, wie ihr testet oder testen lasst. Welche Werkzeuge ihr benutzt, und genau so was euch beim Testen am meisten stört und nervt.
Wie schon oben gesagt sind meine Anforderungen nicht besonders spektakulär. Ich erwarte eigentlich nur, dass der Tester Bescheid sagt, wenn er nicht rechtzeitig fertig wird (was leider einige nicht tun) und dass er das Spiel wirklich spielt (ist schon passiert, dass einer meinte, er hätte ein 10-Stunden-Spiel in einer Stunde durchgespielt). Als Tester erwarte ich, dass der Entwickler sein Spiel zumindest einmal komplett durchgespielt hat. Ich hab schon Spiele getestet, die mehr Bugs als Klendathu hatten. Ist schon ziemlich doof, wenn man auf einer Map nachschaut, warum ein Teleport nicht funktioniert, um festzustellen, dass nicht mal ein Event da ist. ^^"