Changes

Jump to: navigation, search

QA/Triage

661 bytes added, 09:49, 23 July 2006
m
Added bonsai tool link, added build id info/link
# Run the test build. Either make sure you have no other Firefox windows open, or that you have MOZ_NO_REMOTE=1. If you don't, you will actually be running the version of Firefox already in memory. This mistake is common. To ensure you are running the build you think that you are, go to Help -> About.
# Test the build and write down the results. It's common to get confused since you are testing for the absence of a bug, so good notes are important. If the bug occurs, then you know you will have to search back further in time. Otherwise you will need to search forward in time. The optimal algorithm is to test the date exactly between the last known date when the bug didn't occur and the last known date when the bug did occur. Keep dividing by two and you'll find the day.
# In the end, make sure that the bug is marked with the keyword "regression", and add a very clear comment something like: "March 19, 2006 trunk: works, March 20, 2006 trunk: broken".<li>When you have found a regression window within a day, then the actual hour the product was built becomes important. You can give this information with the [http://wiki.mozilla.org/MozillaQualityAssurance:Build_Ids build ID]. Another option is to look at the time when the "firefox.exe" or "thunderbird.exe" was last modified. Then take a larger margin (by the hour) of that time.# An experienced QA can pinpoint the actual checkin with the problem, and assign CC the bug developer who was responsible to the developer who bug. Finding out which checkin was responsiblefor the regression is possible with the [http://bonsai.mozilla.org/cvsqueryform.cgi Bonsai tool]. At the bottom of that page you can add dates ("between ... and ..."). When submitting the form, you get the list of checkins between those dates.
If you are very technical, it is possible to go even further. Some QAs who know
Confirm
486
edits

Navigation menu