@ -148,7 +148,7 @@ Out of the list of prioritized bugs the development team looks at the bugs start
- Bugs are only assigned by the development team to a version, not by anyone else.
- Bugs are only assigned by the development team to a version, not by anyone else.
- Exception: For releases that contain new features (minor / major releases), QA directly assigns bugs that are related to a new feature to the version the feature is in. That means that fixing them also has a higher precedence than fixing bugs that exist in already released versions. But if such a bug is deemed to be of lesser severity, it can be moved out of the version. It will then be prioritized just like any bug.
- Exception: For releases that contain new features (minor / major releases), QA directly assigns bugs that are related to a new feature to the version the feature is in. That means that fixing them also has a higher precedence than fixing bugs that exist in already released versions. But if such a bug is deemed to be of lesser severity, it can be moved out of the version. It will then be prioritized just like any bug.
- On a general basis, new bugs will not be fixed between the time QA finishes and the release is published. (Generally, requires a re-test by QA.) Otherwise, untested and untried code might be published. Bugfixed deemed inadequate might also not be improved again. This is a risk vs gain assessment that has to be decided on case by case. The same is true for critical bugs discovered after QA.
- On a general basis, new bugs will not be fixed between the time QA finishes and the release is published. (Generally, requires a re-test by QA.) Otherwise, untested and untried code might be published. Bugfixes deemed inadequate might also not be improved again. This is a risk vs gain assessment that has to be decided on case by case. The same is true for critical bugs discovered after QA.
@ -180,4 +180,4 @@ The quality assurance team tests the fixed bugs on a test environment and perfor
<u>Notes:</u>
<u>Notes:</u>
- Ideally, QA takes place continuously. It will have to be completed on a date agreed upon by both QA and development. That date is determined when the upcoming release is planned. It has to take into account the time it requires for the release to be tried out on the community shard which typically amounts to 3 days.
- Ideally, QA takes place continuously. It will have to be completed on a date agreed upon by both QA and development. That date is determined when the upcoming release is planned. It has to take into account the time it requires for the release to be tried out on the community shard which typically amounts to 3 days.
- Bug fixes that are deemed inadequate are set to “Test failed” and remain in the version. Development will pick those up and attempt to fix them before the release. If the time expected is too long, because the release is looming, the fix might be placed back in the “prioritized” list. The code written for the bugfix so far can remain in the codebase if it has no visible effect or already improves the situation in part. In other situations, it might have to be reverted. Ideally, a bug fixed in part should be reflected in an extra ticket to be visible in the release notes.
- Bug fixes that are deemed inadequate are set to “Test failed” and remain in the version. Development will pick those up and attempt to fix them before the release. If the time expected is too long, because the release is looming, the fix might be placed back in the “prioritized” list. The code written for the bugfix so far can remain in the codebase if it has no visible effect or already improves the situation in part. In other situations, it might have to be reverted. Ideally, a bug fixed in part should be reflected in an extra ticket to be visible in the release notes.
RobinWagner
3 years ago
committed by
GitHub