RG-Banner


PremiumsystemForumVote AllRegeln Kontakt Tools
Willkommen, Gast
Benutzername: Passwort: Angemeldet bleiben:

[How to] Bugtracker Tickets richtig erstellen
(1 Leser) (1) Gast
  • Seite:
  • 1

THEMA: [How to] Bugtracker Tickets richtig erstellen

[How to] Bugtracker Tickets richtig erstellen 07 Okt 2012 22:17 #493265

Da die Anleitung aus dem RG-Wiki leider oftmals nicht wahrgenommen wird und die Tester sowie Developer derzeit einen riesigen Mehraufwand durch unvollständige Tickets haben, hier nochmals eine Anleitung wie ihr den Bugtracker richtig nutzt. Dieser kleine Mehraufwand bei der Erstellung sorgt für eine deutlich schnellere Bearbeitung!

Was ist der Bugtracker
Der Bugtracker dient dem Tracking ("Verfolgen") von Bugs auf Rising Gods. Er wird von den DEVs und Testern als wichtiges Hilfsmittel beim Aufspüren, Katalogisieren und Beheben von Fehlern verwendet, diese sind auf die Mitarbeit der Community angewiesen.

Auf Rising Gods darf jeder Nutzer gefundene Bugs im Bugtracker melden.


Bugs richtig melden
1. Sicherstellen, dass der Bug überhaupt ein Bug ist.
Dazu sollten Seiten wie wowhead, buffed oder wowwiki genutzt werden.
Außerdem sollte stets darauf geachtet werden, dass ihr euch ausführlichst mit den Mechaniken verschiedener Werte oder Fähigkeiten vertraut gemacht habt und diese auch richtig versteht.

2. Oben rechts auf "Anmelden" klicken und mit Forenaccount und -passwort anmelden.
Beachtet bitte, dass es zu Problemen kommen kann, wenn ihr Sonderzeichen im Accountnamen habt!

3. Rechts auf "Rising Gods Liveserver (3.3.5a)" klicken.

4. In das Suchfenster treffende Suchbegriffe eingeben um zu überprüfen, ob der Bug bereits gemeldet ist.
Hierbei ist zu beachten, dass evtl. englischsprachige Wörter genutzt wurden. Beispielsweise solltet ihr bei Jäger auch nach Hunter oder ähnlichem suchen. So werden die meisten doppelten Tickets schon mal verhindert.

5. Falls ihr wirklich nichts gefunden habt, klickt oben links auf den Reiter "neues Ticket"

6. Namensgebung
Die Namensgebung sollte wenn möglich relativ einheitlich sein und mit kurzen Stichpunkten das Problem beschreiben können. Das erleichtert die Ticketsuche erheblich für das Team udn die Community.
Beispiel: [Naxxramas] Razuvious respawnt nach kurzer Zeit
Die Kategorieangabe in eckigen Klammern am Anfang macht das ganze übersichtlicher (z.B. auch "[Quest][Questgebiet][H] NameDerQuest" oder "[Druide] NameDesTalents"; [H] für Horde bzw. [A] für Allianz nur, wenn die Quest nur für eine Fraktion ist).

7. Richtige Kategorie einstellen (falls erkennbar, im Zweifelsfall leer lassen), primär bei Quests wichtig

8. Den Bug möglichst genau beschrieben, das beinhaltet ggf., was man tun muss um den Bug zu reproduzieren bzw. unter welchen Umständen er auftritt.
Es reicht nicht, wenn ihr sagt Quest X ist buggy, da sonst die komplette Quest nachgeprüft werden muss. Folglich wird die Quest in absehbarer Zeit wohl nicht bearbeitet.

9. Schreibform
Beim erstellen neue Tickets sollte stets darauf geachtet werden, dass ihr in Hochdeutsch schreibt und immer die Rechtschreibung sowie Grammatik beachtet.
Wenn die Tester die Tickets nicht verstehen, können diese leider nicht zügig bearbeitet werden.
Bevor ihr das Ticket abspeichert, solltet ihr die Vorschau Funktion verwenden und euch das komplette Tickets noch einmal durchlesen. Ein nachträgliches editieren ist der Übersicht halber nicht möglich!

10. Unbedingt Link(s) zu wowhead.com oder db.rising-gods.de in die Beschreibung packen (ggf. zusätzlich wowwiki.com). wowhead.com ist vor allem aufgrund der (englischen) Kommentare oft hilfreich, hat jedoch Zauber, Talente, Gegenstände etc. auf Cataclysm-Stand (das betrifft auch old.wowhead.com). db.rising-gods.de basiert direkt auf der Datenbank die den Liveservern zugrunde liegt und ist damit natürlich auf dem richtigen Stand (neuste Änderungen teilweise ausgenommen). Für Zauber kann manchmal auch openwow.com eine nützliche Quelle sein.

11. Bei Bugs bei denen der Fehler nicht offensichtlich ist möglichst konkrete Beweise liefern (wenn ein Talent nicht wirkt oder ein Zahlenwerte falsch sind sieht man das natürlich, aber ob z.B. der Effekt eines Totems Line of Sight erfordert sieht man an der Skillbeschriebung nicht).

Wichtig: Tickets können nur bestätigt werden wenn die Tester überzeugt sind, dass auch wirklich ein Bug besteht. Dazu sind klare Beweise die belegen, dass die entsprechende Sache auf den Blizzardservern damals anders war, erforderlich. Ein Beweis benötigt nahezu immer einen Link zu zu einer seriösen Quelle, "mein Freund spielt aufm Offi und sagt, dass das so ist" überzeugt niemanden. Auch Aussagen wie "es ist doch logisch/unlogisch das die sich soundso verhalten" bringen nichts. Andere Privatserver sollten als Beweisquelle vermieden werden.

In fast jedem Ticket sollte als Folge der oben genannten Punkte ein oder mehrere Links enthalten sein. Zu jedem Skill oder Talent der mit dem Bug zu tun ist sollte ein Link im Ticket stehen und zu komplexeren Sachen noch Link(s) zu Beweisquellen.

Bilder können entweder als Dateianhang bei der Erstellung des Tickets (bzw. des Posts) direkt im Bugtracker angehängt werden oder auf einem externen Hoster (z.b. Imageshack.us) hochgeladen und dann eingebettet werden (bei ganzen Screenshots bzw. allgemein größeren Bildern verlinken).

Verlinken geht wie folgt:

"Linkname":www.linkadresse.­de

Die Anführungszeichen und der Doppelpunkt gehören dazu. Links die mit http:// oder www. beginnen können auch direkt ohne besondere Form gepostet werden, diese werden dann automatisch umgewandelt. Der Button "Verweis (Link) zu einer Wiki-Seite" erzeugt keinen Link und sollte daher nicht benutzt werden. Verlinkungen zu anderen Tickets können ganz simpel mit #123 (mit entsprechender Nummer des Tickets statt 123) geschrieben werden - dies erzeugt nicht nur automatisch einen Link sondern zeigt auch gleich den Namen sowie Status des verlinkten Tickets im Mouseover-Text an.


Wenn ihr der Meinung seid, dass euer (bzw. überhaupt ein) Ticket zu lange unebstätigt bleibt oder fälschlich abgewiesen wurde solltet ihr im Ticket möglichst genaue Informationen liefern. Wenn alle erforderlichen Informationen (das beinhaltet Beweise) im Ticket (inklusive Posts) stehen und sich trotzdem nichts ändern solltet ihr einen Tester anschrieben (d.h. im Forum eine PM schreiben), möglichst einen/den Tester, der das Ticket abgewiesen oder kommentiert hat.
  • Orgothos
  • OFFLINE
  • Gottheit des Forums
  • der Wahnsinnige
  • Beiträge: 6092


:pinch: Warnung: Spoiler!
Dieses Thema wurde gesperrt.
Folgende Benutzer bedankten sich: duke, Unheld, LordNemesis, Vangogh, Waldschurke, Rite, Alacant, Frostworg, Seppl, Jeanine...

Aw: [How to] Bugtracker Tickets richtig erstellen 18 Feb 2013 21:03 #522453

/update

Bezüglich des Merges aber auch generell ein paar Erweiterungen die bitte zu beachten sind!

Ich habe einen Bug gefunden, der vor dem Merge bereits behoben wurde
Da die alten Tickets leicht zu übersehen sind, da dort bereits der Status live eingetragen wurde, ist es sinnvoll ein neues Ticket dazu zu erstellen. Hierzu bitte die Sufu nutzen.
Allerdings ist hierbei zu beachten, dass ihr auf das alte bereits bearbeitete Ticket verweist.
Das ganze kann bzw. sollte über die Bugtracker Formatierungen geschehen!
Auch über ein kurzes Kommentar könnt ihr zusätzlich anmerken, wenn etwas vor dem Merge bereits ging. Das ganze hilft dem Tester- und Dev- Team die Tickets zu bearbeiten.


Kurze Erklärung wie die Tester die Wichtigkeit eures Tickets bestimmen

Priorität
Niedrig
Es handelt sich um rein visuelle Bugs, die vernachlässigt werden können.
z.B. Boss sollte rot leuchten sobald er enraged
Hoch
Bugs, welche eine deutliche Veränderung der vorgesehenen Spielmechanik bewirken und z.B. einen Bosskampf stark vereinfachen oder erschweren
z.B. Boss castet spell nur alle 45 Sec statt alle 15 Sec
Dringend
Bugs, welche eine sehr schwerwiegende Veränderung der vorgesehenen Spielmechanik bewirken und z.B. einen Bosskampf extrem vereinfachen oder erschweren
z.B. Der Boss spellt in Phase 2 nicht
Sofort
Alles Bugs, die massiv ausgenutzt werden können
z.B. Item-Verdoppeln, Freeloot bei Raidbossen, DMG-Stacking bei Spielern, Bosse, die nicht spellen
Normal
Alles übrige


ID's dem Ticket beifügen
Damit Tester und Dev's mehr Zeit dazu haben, das zu machen wofür sie hier bei RG "arbeiten" denkt bitte immer an die ID's von NPC's, Spells oder Quests.
Die ID ist normalerweise die Zahl hinter dem wowhead bzw. buffed Link.
wowhead schrieb:

Hier ist also die ID des Items 1934. Mit dieser ID kann das Team ganz einfach weitere Schritte einleiten. Fehlt diese ID geht nur unnötige Zeit zur Recherche drauf.


Des weiteren gilt immer noch, bitte nutzt das Forum nicht als Bugtracker, es sei denn es gibt einen Thread in dem das Team explizit darum bittet dies zu tun.
  • Orgothos
  • OFFLINE
  • Gottheit des Forums
  • der Wahnsinnige
  • Beiträge: 6092


:pinch: Warnung: Spoiler!
Dieses Thema wurde gesperrt.
Folgende Benutzer bedankten sich: FreakerBust, Eruption, Waldschurke, Frostworg, Seppl, Bremner, Tester-Avon, Soneji

Aw: [How to] Bugtracker Tickets richtig erstellen 26 Aug 2013 16:08 #558936

Auf Wunsch eines Dev's nochmals der Hinweis zur besten Vorgehensweise, wenn ein Bugfix nicht funktioniert wie er soll:
:pinch: Warnung: Spoiler!

Ähnlich wie bei dem Beispiel zum Merge (siehe Spoiler), sollte so auch vorgegangen werden, wenn ein Fix nach einem Serverupdate nicht so funktioniert wie er soll.
Da das Ticket durch das aufspielen auf "Live" gesetzt wird, werden weitere Kommentare zu dem Ticket mit dem Hinweis, dass das ganze weiterhin nicht funktioniert leider oftmals nicht oder erst sehr spät (z.B. nach einem Hinweis im Forum) vom Team wahrgenommen.
Um das ganze zu verhindern, sollte ein neues Ticket erstellt werden! Den Text des alten Tickets müsst ihr nicht komplett übernehmen, ein kleiner Hinweis, dass Bug Y aus Grund Y immer noch nicht funktioniert und die Verlinkung zum Ursprünglichen Ticket durch eineBugtracker Formatierung reichen hier vollkommen aus.
Leider wird dadurch diese Vorgehensweise der Bugtracker extrem vollgemüllt, allerdings wird bereits über eine alternative Lösung nachgedacht.


Des weiteren erneut der Hinweis, dass ein push zu Tickets unnötig ist, solange es nicht in einem Serverupdate explizit erwähnt wurde bzw. sich der Status geändert hat.
Es sei denn, das Problem hat sich durch mysteriöse Art und weise von selbst behoben und das Ticket wird somit überflüssig oder ihr habt etwas zu ergänzen.
  • Orgothos
  • OFFLINE
  • Gottheit des Forums
  • der Wahnsinnige
  • Beiträge: 6092


:pinch: Warnung: Spoiler!
Letzte Änderung: 26 Aug 2013 16:10 von Orgothos.
Dieses Thema wurde gesperrt.

Aw: [How to] Bugtracker Tickets richtig erstellen 15 Okt 2015 14:18 #636627

Da es in letzter Zeit einige Updates und Umstrukturierungen bei der Bearbeitung von Tickets in Bugtracker gab, hier noch einmal die wichtigsten Punkte bevor ein Ticket erstellt werden sollte (insofern jemand diesen Thread hier VOR der Anleitung im Bugtracker selbst findet.)

Ein neues Ticket für den +3.3.5 WotlK-Live-Server+ kannst du hier erstellen:
>>> redmine.rising-gods.de/projects/live/issues/new <<<
Ein neues Ticket für den 2.4.3 TBC-Live-Server kannst du hier erstellen:
>>> redmine.rising-gods.de/projects/b2b-live-2-4-3/issues/new <<<
(Beachtet bitte, dass Tickets nur in diesen Projekten kontrolliert werden.)

Hier ein paar kleine Hinweise zur Erstellung deines Bugtrackertickets:

1. Bemüht euch um eine *neutrale Berichterstattung* ohne jegliche Emotionen.
2. Bitte nutzt die Suchfunktion (i.imgur.com/WZIAKDk.png) vorab, damit ein Bug nicht doppelt gemeldet wird.
(z.B.: redmine.rising-gods.de/projects/live/sea...sues=1&q=Saronit
3. Ordne deinen Fehler der entsprechenden Kategorie zu (Kreaturen, Quests, Zauber, Items, etc.)
4. Bitte poste immer Links von de.wowhead.com oder db.rising-gods.de von der Kreatur/Item/Zauber etc. in dein Ticket, damit wir es schneller bearbeiten können (Beispiel: Zu wenige Kobaltvorkommen vorhanden - hier der Link de.wowhead.com/object=189978)
Erst wenn alle Links angegeben wurden wird das Ticket bearbeitet.

5. Fügt genaue Umstände (Positionsangaben/Zeitangaben) hinzu. (Beispiel: Lord Marrowgar wirkte am 26.04.2015 in seiner zweiten Phase keinen Knochensturm)
6. Versuche bereits vorab herauszufinden ob es entsprechende Quellen zu dem Fehler gibt, die im Notfall deinen Fall unterstützen und andere Aussagen widerlegen können. Eine Quelle wird bei allen Fehlern, insbesondere bei PvP relevanten Fehlern, benötigt. Die meisten Informationen bieten hierbei:
wowhead.com/
wowwiki.com/
forums.elitistjerks.com
youtube.com/
7. Bitte meldet immer nur jeweils einen Fehler pro Ticket.
8. Tickets behandeln nur Fehler der serverseitigen Kommunikation (keine Client/Support-fehler).
9. Bitte unterlasst unnötige Kommentare wie "/push", "funktioniert noch immer nicht" oder ähnliches.


Kategorien:
Neu:
-Es wurde ein Fehler gemeldet, dieser muss aber noch überprüft werden. Insofern ihr zusätzliche *nützliche* Informationen habt könnt ihr diese dem Ticket jederzeit hinzufügen. Erst wenn alle IDs angegeben wurden, der Fehler als solches erkannt wurde, alle Quellen angegeben wurden und reproduziert werden kann, erfolgt die Bestätigung des Tickets.

Bestätigt:
-Der Fehler wurde begutachtet und als solcher identifiziert. Ein Developer wird sich im Rahmen seiner Fähigkeiten damit zeitnah befassen.

Testbereit:
-Der Bug wurde auf dem für Spieler unzugänglichen Testserver gefixt und muss dort kontrolliert werden. Dieser Fix wird auf dem Spielserver *nicht funktionieren*.

Ready:
-Der Fix funktioniert soweit und wird mit dem nächsten Serverupdate (www.rising-gods.de/forum/95-serverupdates.html) auf dem Liveserver aufgespielt sein. Dieser Fix wird auf dem Spielserver noch *nicht* funktionieren.

Live:
-Der Bug wurde erfolgreich behoben und befindet sich auf dem Spielserver. Sollte der Fehler weiterhin bestehen sollte ein *neues Ticket* erstellt werden. Anmerkungen in dem alten abgewiesenen oder live genommenen Ticket werden ignoriert.

Abgewiesen:
-Der Bug wurde nicht als solcher identifiziert oder ist ein Duplikat oder das Ticket enthält nicht genügend Informationen (siehe "Hinweise zur Erstellung deines Bugtrackertickets") zur weiteren Bearbeitung. Solltest du dennoch der Meinung sein, dass
etwas nicht richtig funktiniert sollte unter der obrigen Anleitung eine *neues Ticket* erstellt werden.

Solltest du einmal nicht wissen, in welche Sparte dein Ticket gehört, kannst du gerne jederzeit einen Tester oder Developer per Forumnachricht fragen.
  • Rushor
  • OFFLINE
  • Ehemaliges Teammitglied
  • Gather all the points
  • Beiträge: 836
Support me on Patreon: www.patreon.com/rushor
rushor.sexy powered by 1337
Dieses Thema wurde gesperrt.
Folgende Benutzer bedankten sich: Hirstkopf

Aw: [How to] Bugtracker Tickets richtig erstellen 08 Jan 2016 07:58 #643434

Nochmal ein Beispiel, wie ein Ticket im Idealfall aussehen sollte:

baccenfutter schrieb:


Ich sehe gleich mehrere Verhalten, die offensichtlich fehlerhaft sind - also mehr als nur nicht blizz-like, sondern so richtig amtlich buggy. Ich poste alle Bugs in einem Ticket, weil es die *selben* NPCs in der *selben* Zone sind, die man aufgrund der *selben* Quest toeten geht, und weil beide Bugs aller Vermutung nach in einem Change gefixt werden koennen/sollten/muessten. Das scheinen ein paar DB-Fehler (falsche Positionierung auf der Map)_und einige Script-Bugs zu sein (Aggro ohne Casting).

* Alle Bugs treten auf im Holzfaellerlager des Kriegshymnenklans in Eschental.
* Die betroffenen NPCs sind db.rising-gods.de/?npc=11656 und *Spaeher der Horde*
* Ich wurde da von einer Quest aus Waldeslied_hingeschickt.

* db.rising-gods.de/?maps=331:865464869481...28875532887500883514

*Probleme*:
1. Stale NPC ohne KI
2. NPC "Fluchtverhalten" fuehrt unter bestimmten Umstaenden zu: Kein AGGRO, anschliessend zu In-Fight-Bug
3. Falsch positionierte NPCs
4. Spieler kriegt Aggro, wird aber nicht angegriffen

----

1. Stale NPC
Manchmal spawnt einer der genannten NPCs, ohne dass sein Scripted-Behaviour startet. Er steht dann einfach dumm in der Gegend herum. Manchmal kann es vorkommen, dass auf der selben Position zwei solcher NPCs spawnen. Greift man einen der beiden an, kriegt der zweite erst Aggro, wenn er schaden nimmt. Solange er keinen Schaden nimmt, steht er einfach weiter herum, egal wie dicht sich der Kamp neben ihm abspielt.

----

2. Defektes Fluchtverhalten
Die genannten NPCs haben ein Fluchtverhalten _(Beispiel Kampflog: Peon des Kriegshymnenklans versucht zu flüchten!)_ Manchmal zu Beginn des Kampfes, manchmal bei ~10% HP laufen sie los, um Verstaerkung zu holen. Fluechten sie zu Beginn des Kampfes, laufen sie oft planlos umher, waehrend sie mit der Axt fleissig weiter in der Luft rum hacken. Greift man den NPC jetzt nicht weiter an, kann es vorkommen, dass weder der fluechtende NPC, noch irgendwelche anderen "alarmierten" NPCs Aggro auf den Spieler bekommen; der Spieler wird anschliessend von einem In-Fight-Bug getroffen. Waehrend all dessen laufen die Mobs auch gerne unter den Boden und somit ausserhalb des Aktionsbereichs des Spielers.

----

3. Falsch positionierte NPCs
Manche NPCs sind falsch positoiniert. Z.B. sie hacken fleissig mit der Axt auf die Wiese oder stehen mit Axt am Baumstump und machen genau gar nichts.

----

4. Aggro ohne Angriff
Manche NPC kriegen Aggro auf den Spieler, beginnen aber nicht zu casten.

----

baccenfutter.crew.c-base.org/wow.ogv
baccenfutter.crew.c-base.org/wow1.ogv
baccenfutter.crew.c-base.org/wow2.ogv


redmine.rising-gods.de/issues/17032
  • Rushor
  • OFFLINE
  • Ehemaliges Teammitglied
  • Gather all the points
  • Beiträge: 836
Support me on Patreon: www.patreon.com/rushor
rushor.sexy powered by 1337
Dieses Thema wurde gesperrt.
  • Seite:
  • 1
Ladezeit der Seite: 0.32 Sekunden
legal notice