166
edits
QA/Bug Triage Guidelines: Difference between revisions
no edit summary
Paul.oiegas (talk | contribs) (Review and updates) |
Paul.oiegas (talk | contribs) No edit summary |
||
| Line 271: | Line 271: | ||
|- | |- | ||
| Manual regression and manual creation of Pushlog link || When Mozregression tool fails to work (errors when trying to open the builds for test), or when you cannot use it because you need to perform some steps outside the browser before you can test an issue, all you can do is manual regression testing. But in order to help locate the issue you will still need the "Pushlog link" that points to the exact pushes that were made in the specific day when issue appeared. In order to create the pushlog link manually, you will need the next things: | | Manual regression and manual creation of Pushlog link || When Mozregression tool fails to work (errors when trying to open the builds for test), or when you cannot use it because you need to perform some steps outside the browser before you can test an issue, all you can do is manual regression testing. But in order to help locate the issue you will still need the "Pushlog link" that points to the exact pushes that were made in the specific day when issue appeared. In order to create the pushlog link manually, you will need the next things: | ||
1. Latest good build and the first bad build where issue appeared | 1. Latest good build and the first bad build where issue appeared.<br> | ||
2. You will need to either install both the builds (one at the time) or extract them. The most convenient is to extract both the zipped builds. | 2. You will need to either install both the builds (one at the time) or extract them. The most convenient is to extract both the zipped builds.<br> | ||
3. Search in installation folder/build folder for the "application.ini" file (Mac OS path is /Applications/Firefox.app/Contents/MacOS/application.ini) | 3. Search in installation folder/build folder for the "application.ini" file (Mac OS path is /Applications/Firefox.app/Contents/MacOS/application.ini).<br> | ||
4. Open the ".ini" files with a text editor and search for the "SourceStamp" values | 4. Open the ".ini" files with a text editor and search for the "SourceStamp" values.<br> | ||
5. After doing this you will have to use the " http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=good_build_stamp&tochange=bad_build_stamp " link and replace the <good_build_stamp> and <bad_build_stamp> strings with the one obtained from the ini files. | 5. After doing this you will have to use the " http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=good_build_stamp&tochange=bad_build_stamp " link and replace the <good_build_stamp> and <bad_build_stamp> strings with the one obtained from the ini files.<br> | ||
You should verify the link obtained, and if it works and it is related with the period when the issue appeared, you should add it to the comment for the bug where regression was performed. If you have enough experience you could also point in the comment the exact push from the pushlog page that affected the build, and CC the developer that did it (if it's still available) in order to obtain th information faster. For the moment Rayan was doing this for the pushlog links I provided but we can experience this too in the future. | |||
You should verify the link obtained, and if it works and it is related with the period when the issue appeared, you should add it to the comment for the bug where regression was performed. | |||
If you have enough experience you could also point in the comment the exact push from the pushlog page that affected the build, and CC the developer that did it (if it's still available) in order to obtain th information faster. For the moment Rayan was doing this for the pushlog links I provided but we can experience this too in the future. | |||
|- | |- | ||
| Performing quick Regression test by searching in build release notes || In cases when reporter mentions that in a previous version of Firefox his issue was not present and after updating it appeared, you can also do a quick manual regression by searching the problematic build release notes and observe the changes that have been made on it. To better explain this process I will refer to an Issue that I triaged, where the reported problem was an audio malfunction in an html5 game that he an his team develops, that appeared after updating from Firefox 39.0 to 40.0. | | Performing quick Regression test by searching in build release notes || In cases when reporter mentions that in a previous version of Firefox his issue was not present and after updating it appeared, you can also do a quick manual regression by searching the problematic build release notes and observe the changes that have been made on it. To better explain this process I will refer to an Issue that I triaged, where the reported problem was an audio malfunction in an html5 game that he an his team develops, that appeared after updating from Firefox 39.0 to 40.0. | ||
| Line 295: | Line 297: | ||
| How to deal with bugs that are reproducible between the latest official release and the latest Nightly || One of the possibilities when working on the Bug triage task is to encounter bugs that are reproducible between the latest official release and the latest Nightly (for example, the bug is reproducible only on the latest Aurora). In this case we take the following actions: | | How to deal with bugs that are reproducible between the latest official release and the latest Nightly || One of the possibilities when working on the Bug triage task is to encounter bugs that are reproducible between the latest official release and the latest Nightly (for example, the bug is reproducible only on the latest Aurora). In this case we take the following actions: | ||
1. Confirm the bug<br | 1. Confirm the bug.<br> | ||
2. If it's the case: set the right component<br | 2. If it's the case: set the right component.<br> | ||
3. In Bugzilla, edit the tracking flags area: set as affected or unaffected the status-firefox fields for all Firefox versions (official Release, latest Beta, latest Aurora and latest Nightly)<br | 3. In Bugzilla, edit the tracking flags area: set as affected or unaffected the status-firefox fields for all Firefox versions (official Release, latest Beta, latest Aurora and latest Nightly).<br> | ||
4. Knowing the patch that fixed the issue is an asset in getting the fix on the affected Firefox version (the mozregression tool is very helpful - ask the reporter or do it yourself)<br | 4. Knowing the patch that fixed the issue is an asset in getting the fix on the affected Firefox version (the mozregression tool is very helpful - ask the reporter or do it yourself).<br> | ||
|- | |- | ||
| How to simulate bad internet connection on Mac OS || If you encounter and issue where the reporter specifies that he has a slow / bad internet connection, or you think the issue appears only when internet connection is not good enough, you can simulate this kind of environment by using a bandwidth throttling tool. | | How to simulate bad internet connection on Mac OS || If you encounter and issue where the reporter specifies that he has a slow / bad internet connection, or you think the issue appears only when internet connection is not good enough, you can simulate this kind of environment by using a bandwidth throttling tool. | ||