.gitignore
grundsätzlich werden nur neue Files ignoriert (Quelle)
rekursives Ignorieren von bestimmten Dateitypen: **/*.js
Mit welcher Revision kam der Bug in die Codebase?
Gehe in entsprechenden Ordner/Datei, wo der Bug drin ist und zeige die Commit-Historie (Git -> show history). Wenn man das nicht weiter eingrenzen kann, mach show history beim root.
Grenze den Bug ein: Wann kann er theoretisch am frühesten in die Codebase gekommen sein und wann am spätestens. Hier dann den mittleren Commit raussuchen und die Revision auschecken (Git -> Checkout Revision XYZ). Der entsprechende Code ist jetzt aktiv. Jetzt ausprobieren, ob der Bug schon auftritt. (Evtl. Cache leeren).
Wenn Bug auftritt, dann zurückspringen und zwar wieder “um die halbe Wegstrecke”. Wenn der Bug nicht auftritt, dann entsprechend vorspringen.
Spätere Revisionen werden aus der Git-History ausgeblendet. Um diese späteren Revisions in der History wieder sichtbar zu machen, gehe im Kontextmenü auf Git -> Branches -> Local Branches -> main -> checkout
Begriffe im Testmanagement
Die verschiedenen Fachbegriffe im Testen werden oft unscharf verwendet/verstanden. Hier mein Versuch der Schärfung.
Testkonzept
Auf englisch heißt Testkontept test plan (Quelle).
Ein grundlegendes und sich über den Lebenszyklus der zu testenden Software kaum änderndes Dokument. Alle weiteren testbezogenen Dokumente orientieren sich am Testkonzept. (Quelle)
Testplan
In englisch heißt der Testplan test schedule (Quelle).
“Der Testplan (…) enthält die zeitliche Planung und gegebenenfalls noch Zuordnungen von Personen zu Arbeitspaketen und Aufgaben.” (Quelle)
Auf den Punkt gebracht steht im Testplan: was und wann getestet werden soll und evtl. wer testen soll.
Testspezifikation
Die Testspezifikation legt fest, was getestet werden soll. Damit ist die Testspezifikation ein Teil des Testplans.
Die Testspezifikation besteht aus Testfällen, die aus den zu testenden Programmfunktionen abgeleitet werden (Quelle)
Testszenario
Ein Testszenario ist etwas, das auf einer hohen Abstraktionsebene beschreibt, was getestet werden soll, z.B. Check the search functionality (scenario 1) oder Check the payments functionality (scenario 2). (Quelle)
Ein Testszenario besteht aus mehreren konkreten Testfällen.