QA/Test

From The Document Foundation Wiki
< QA
Jump to: navigation, search

Automatic Messages

Target

Description: target refers to the version(s) where a commit which fixes the problem can be expected to be seen.

Example: (target: 4.2.0.0) – this means that a commit which fixes the problem was committed to the 4.2.0.0, and therefore if a user or QA member tests 4.2.0.0 they should not see the bug any longer.

Use: Generally “target” is automatically entered when a developer commits a patch specifically to fix a bug reported on the bug tracker. Users, QA and Developer should generally not manually enter “target” into whiteboard, the only exception is when the automatic system did not tag the bug and a developer or QA member knows the exact commit which fixed the bug and what version of LibreOffice will see the patch. In these cases a QA member can mark a bug as “target:x.x.x.x” where x.x.x.x is the version(s) of LibreOffice where the commit was pushed to.

BSA

Description: BSA refers to “Bug Submission Assistant” and when in the whiteboard means that the bug was submitted through our bug submission assistant. For more information about BSA click here.

Use: Always entered automatically, no need to ever manually put BSA into whiteboard.

PossibleRegression

Description: PossibleRegression is entered when a user has stated that the bug was not present in a previous release of LibreOffice and therefore it's a regression. The point of this status is so that QA can confirm that there is a regression and do the follow up steps needed for regressions (bibisect, etc . . .)

Use: PossibleRegression is entered automatically when a user enters a previous version in BSA where the bug was not present. PossibleRegression can be manually entered by a user when they are reporting directly to the bug tracker (ie. Not through BSA) if they believe that the bug is a regression – if they do this they should write in the bug description when the bug was not present.


No Longer In Use

Accessibility

Description: Replaced by a11y – see description there.

Use: No longer used. Replaced by a11y.

bibisected35older

Description: Was used to indicate that the bug was present before the bibisect35 package.

Use: No longer used. Replaced by a new version field “PreBibisect.” If a bug is present before the earliest bibisect commit – set the version to “PreBibisect” and leave a comment explaining the change. For more information about bibisect see LINK

here.

bibisected35

Description: Replaced by “bibisected”. Was used in the past to say that the bug was bibisected with the bibisect35 package. This package is now incorporated into the bibisect 43all package. For information about bibisect see LINK

here.

Use: No longer used. Replaced by “bibisected”.

bibisected36

Description: Replaced by “bibisected”. Was used in the past to say that the bug was bibisected with the bibisect36 package. This package is now incorporated into the bibisect 43all package. For information about bibisect see here.


Use: No longer used. Replaced by “bibisected”.

bibisected35newer

Description: Was used in the past to say that a regression was introduced after the bibisect35 package.

Use: No longer used.

bibisected36older

Description: Was used to indicate that the bug was present before the bibisect36 package.

Use: No longer used. Replaced by a new version field “PreBibisect.” If a bug is present before the earliest bibisect commit – set the version to “PreBibisect” and leave a comment explaining the change. For more information about bibisect see here.

bibisected40

Description: Replaced by “bibisected”. Was used in the past to say that the bug was bibisected with the bibisect40 package. This package is now incorporated into the bibisect 43all package. For information about bibisect see here.


Use: No longer used. Replaced by “bibisected”.

bibisected40newer

Description: Was used in the past to say that a regression was introduced after the bibisect40 package.

Use: No longer used.

bibisected40older

Description: Was used to indicate that the bug was present before the bibisect40 package.

Use: No longer used. Replaced by a new version field “PreBibisect.” If a bug is present before the earliest bibisect commit – set the version to “PreBibisect” and leave a comment explaining the change. For more information about bibisect see here.

Currently In Use

a11y

Description: Used when the bug report is about an accessibility issue. Accessibility refers to bugs and enhancements which affect individuals with special needs. Applicable for both enhancement requests and bug reports.

Use: Manually entered by someone who knows about accessibility problems. These are specific to bugs which would affect the way that individuals with special needs interact with LibreOffice – generally not appropriate if it is just a request to make something easier for everyone.

bibisected

Description: Used for letting developers know that the bug has been bibisected. For more information on bibisect see LINK

here.

Use: Should be manually entered by the person attaching the bibisect details after bibisecting a bug.

EasyHack

Description: Used to denote a bug which has been determined to be a good start for a new developer on the project.

Use: Developers should be the only ones to use this whiteboard status. Developers add this status after they provide code pointers to fix the bug.

NoRepro:VERSION:OS

Description: Used when you are unable to reproduce the bug but are not comfortable closing the bug as LINK

WORKSFORME. Includes information about what version was used and the operating system of the tester.

Example(s): NoRepro:4.1.3.2:Ubuntu, NoRepro:4.1.3.2:Windows7, NoRepro:4.2.0.1:OSX

Use: Generally used when the testing environment is different than the testing environment of the bug reporter so closing the bug as WORKSFORME status is less applicable. Used mostly by QA members and developers.

Confirmed:VERSION:OS

Description: Can be used to say that the bug was confirmed on a particular OS and using a particular version of LibreOffice.

Example(s):

Confirmed:4.1.3.2:Ubuntu
Confirmed:4.1.3.2:Windows7
Confirmed:4.2.0.1:OSX

Use: Not frequently used but can be used when wanting to add more information to a confirmed bug. Should always include “Confirmed:” and then version and OS (see examples above).

BibisectedNewer

Description: Used in cases where a bug has been confirmed to be a regression but the regression occurred after the last commit in the latest bibisect package.

Use: If a regression is confirmed on master or on a recent daily build then it's likely going to be too new to be bibisected. QA should still try to bibisect the bug just in case the bad commit is within the bibisect range.

BibisectRequest

Description: Used to let us know that a bibisect is needed.

Use: All confirmed regressions after 3.5.0 should have a BibisectRequest whiteboard status unless the bug is specific to Windows (which should be confirmed prior to removing a BibisectRequest). Many bugs that affect Windows will also affect Linux and OSX so they can be bibisected successfully.

ConfirmedRegression

Description: Is used if a bug is confirmed to be a regression.

Use: If a bug is confirmed to be a regression then a user, QA, or developer can put ConfirmedRegression into the whiteboard. If this is done the individual should also put in the comments what version worked (and is confirmed to have worked) and what version does not.

DifficultyBeginner

Description: Developers add this to easy hacks (see EasyHacks whiteboard status) to indicate that not only is the bug an easy hack, it is “really easy” and can be done by individuals who have beginner skills in computer science.

Use: Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.

DifficultyEasy

Description: Developers add this to easy hacks (see EasyHacks whiteboard status) to indicate that the bug is fairly easy but not quite easy enough for beginners.

Use: Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.

DifficultyInteresting

Description: Developers add this to easy hacks (see EasyHacks whiteboard status) to indicate that while the bug is considered to be an easy hack by our experts, it could be quite challenging for a new developer on the project. Generally people who tackle these should be relatively comfortable with programming generally.

Use: Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.

NeedsSOFTWARE