. '''To Software''' '''[[Software|Software]]''' - '''To Software-Assessment - ''' '''[[Software/Assessment|Software/Assessment]]''' . '''To Software Current Tests - ''' '''[[Software/CurrentTest|Software/CurrentTest]]''' - '''To Software Testteam - ''' '''[[Software/TestTeam|Software/TestTeam]]''' . '''To Software Testers Welcome Pack (Intro) - ''' '''[[Software/TestTeam/WelcomePack/DE|Software/TestTeam/WelcomePack/DE]]''' ---- = Software Testers Welcome Pack = = 4. Testing/Reporting - [DE] = Hallo Software-Testers, Nach den ersten Gehversuchen mit dem Testserver und dem Testserver-Management-System kommen wir nun zu dem entscheidendem Element im Software-Testing: '''Dem Reporting'''. Was nuetzt es uns, wenn ihr Software-Testers probiert was das Zeugs haelt, davon aber niemand - insbesondere nicht die Software-Assessors davon etwas mitbekommen ? Wir koennen die Tests wiederholen und wiederholen ohne das wir jemals fertig werden mit dem Testen. Aus diesem Grund ist die Dokumentation der entscheidende Punkt. * Mit welchem Browser arbeitest du ? * Welche Funktion hast du ueber welchen Weg aufgerufen ? * Wurden die Fehler die in einem Bug Report berichtet wurden behoben ? * Oder gibt es jetzt neue Fehler ? Damit die Software-Assessors erfahren, wieviele Leute Tests durchgefuehrt haben, bzw. ueberhaupt Tests durchgefuehrt wurden, und ob die Fehler beseitigt wurden, sind die entscheidende Vorraussetzung, das die Software-Assessors einen Patch weiter pruefen und zu einem Paeckchen schnueren, das zum Produktiv System uebertragen werden muss. Wenn also ein Patch nicht getestet wurde, koennen die Software-Assessors den Patch nicht freigeben. Im Bugs System (Mantis) verbirgt sich die gesamte Historie eines Bugs / Patches, angefangen von der Meldung eines neuen Bugs / Feature Requests, Hinweise ueber moegliche Loesungsansaetze, uebermittelte Patches, Meldungen ueber das Einpflegen in Repositories, Einspielungen auf dem Testserver, zusaetzliche Hinweise zur Beschreibung des Patches, und eben auch die Test Reports. Die Tester Einstiegsseite [[Software/CurrentTest|Software/CurrentTest]] ist daher von zentraler Bedeutung, welche Patches sich auf dem Testserver befinden, die es zu Reporten gilt. Hierzu befindet sich auch zu jedem eingestellten Patch eine Bug # mit einem Link in das Bugs Verwaltungssystem. Startet man nun mit einer Test Sequenz zu einer Bug #, dokumentiert man die Schritte der Tests - Menue Links, Linkaufrufe, Werte die man in Felder eingibt, und ggf. in Kurzform welche Ergebnisse nach einer Operation erhalten werden. Dies kann einmal in Kurzform (Ok, Nicht Ok) sein, oder aber eine ausfuehrliche Auflistung von Ergebnissen. Insbesondere bei Fehlern sind Auflistungen von Ergebnissen mitunter bei der Aufspuerung von weiteren Bugs hilfreich. Ein Report wird durch Hinzufuegen einer Notiz am Ende der Bug Dokumentation generiert. Durch Ausfuellen des Freitext Feldes, hat man als Tester die Freiheit die unterschiedlichsten Informationen in ein Notizfeld unterzubringen. Wichtig ist nur, das auch bei erfolgreicher Pruefung ein Vermerk hinzugefuegt wird: "Standard Test, erfolgreich". Browser, Punktezahl, Flag Status des Testusers, alles was fuer einen bestimmten Patch wirchtig sein koennte, kann hier an Informationen untergebracht werden. Durch eine vollstaendige Dokumentation sind die Software-Assessors in der Lage, ein Review eines Patches erfolgreich durchzufuehren. Andernfalls kann ein Patch nicht freigegeben werden. === Was mache ich, wenn ich einen Fehler gefunden habe ? === . '''Dokumentieren''' Ganz wichtig ist es, zunaechst einmal den Weg aufzuzeigen, der zum Fehlerfall fuehrte, damit eine Ueberpruefung moeglich wird um den Fehler zu reproduzieren. Bei laengeren Wegen, die zu einem Problem fuehren, wird es mitunter schwierig die Anfangsschritte noch genau zu wissen. Aus dem Grund sollte jeder Schritt dokumentiert werden, sobald man einen Schritt ausfuehrt. Handelt es sich bei einem gefundenen Fehler um einen Neuen Fehler, sollte dieser Fehler zunaechst einmal unter diesem Bug Report registriert werden. Spaeterhin, wenn ersichtlich wird, das der gefundene Fehler nichts mit dem eigentlichen Patch in Zusammenhang steht, kann immer noch ein neuer Bug Report generiert werden. === Wo gibt es eine genaue Beschreibung der Patches ? === Mit der Beschreibung der Patches ist das so eine Sache fuer sich. Auf der einen Seite sollten die Sachen moeglichst genau beschrieben werden. Auf der anderen Seite, durch die genauen Beschreibungen fokusieren sich moegliche Tester auf genau das Problem und lassen andere Dinge ausser acht ... Fuer den Einstieg ist das Tester Portal gedacht. * [[https://wiki.cacert.org/Software/CurrentTest]] auf dem die auf dem Testserver aktivierten Tests kurz beschrieben sind. So gut wie ausnahmslos mit einer Bug# mit einem Link versehen, bei dem die Beschreibung des Problems geliefert wird. Beim Patch soll dann das Problem auf der einen oder anderen Art und weise geloest sein. Aufgabe des Testers gilt es das zu ueberpruefen, ob es wirklich so ist. Mit unterschiedlichen Browsern, mit "rumspielen" in den verschiedenen "Ecken" der Software, mit "unterschiedlichen" Werten (beispielsweise Assurance Level) und die Beobachtungen dann unter der jeweiligen Bug# als "Note" vermerken ... egal ob noch Fehler existieren, oder ob das Testen erfolgreich war. Kurzer Text: "ja, kein problem mehr" oder ... "jetzt an anderer stelle ein problem" ... oder "unter der und der bedingung tritt das problem weiterhin auf" ... Als Vergleich dient immer das Produktiv System (sofern man auf die Bereiche Zugriff hat). Es gibt eine Vielzahl an Patches: von "einfach" bis "schwierig". Ein "einfacher" Patch ist ein simpler Austausch einer Webseite die zukuenftig zum Wiki verlinken soll. Oeffnet sich der Wiki Link ? oder landest du immer noch auf dem Testserver (zu sehen am Link in der Browser Zeile) ? Das simpelste Testing ist immer: auf den Produktivserver gehen, schauen was im Bug-Report angegeben ist, ob das Problem nachvollziehbar ist ... wenn ja: ... auf dem Testserver schauen, ob das Problem da auch noch existiert ..... Letztendlich ist der Bug# Report die Dokumentation zum eigentlichen Patch. Teilweise stehen hier auch schon Loesungsansaetze an denen man sich als Tester orientieren kann, was man erwarten sollte ... === Ich kann mir unter dem angegebenen Patch nichts drunter vorstellen === Wende dich an einen anderen Tester des Test Teams oder an den Testteam Teamleader. Sicherlich wird er bei deinen Fragen weiterhelfen koennen. === Kann ich eine Testrunde aussetzen ? === Prinzipiell geht das schon. Wir haben aber nicht so viele Software-Tester das wir auf einzelne Tester verzichten koennten. Wir benoetigen ein aktives Team. === Wann ist eine Testrunde beendet ? === Solange ein Patch noch auf der Einstiegsseite gelistet wird, ist der Patch noch nicht vollkommen durchgetestet. Fuehre Tests durch, reporte dein Ergebnis. Wann ein Patch zuende getestet ist bestimmt das Software-Assessment Team, indem es sich die Ergebnisse der Tests anschaut, entscheidet ob noch weitere Tests notwendig sind oder nicht, und falls ein Patch ausreichend getestet wurde, ob der Patch dann reviewed werden kann. === Wer bestimmt, welche Patches auf den Testserver kommen ? === Auch wieder das Software-Assessment Team. Das waehlt die Patches aus, welche aufgrund ihrer Prioritaet, Qualitaet, oder sonstiger Erfordernisse als naechstes anstehen. <
> Euer<
> Testteam Teamleader<
> <
> == Wie geht es weiter ? == * [[Software/TestTeam/WelcomePack/01-TestersEntryPage/DE|1. Die Einstiegsseite fuer Software Tester]] * [[Software/TestTeam/WelcomePack/02-CreateAccounts/DE|2. Anlegen von Accounts]] * [[Software/TestTeam/WelcomePack/03-WorkingWithTestserverAndMgmtSystem/DE|3. Arbeiten mit dem Testserver und dem Testserver-Management-System]] * [[Software/TestTeam/WelcomePack/04-Reporting/DE|4. Testing/Reporting]] * '''[[Software/CurrentTest|Testen, Reporten, Testen, Reporten, ...]]''' == Software Testteam Welcome Pack == || Software Testteam Welcome Pack || [[Software/TestTeam/WelcomePack|English]] || [[Software/TestTeam/WelcomePack/DE|German]] || ---- . CategorySoftwareAssessment