Changes between Version 24 and Version 25 of BugReportingGuidelines


Ignore:
Timestamp:
02/02/10 20:38:59 (16 years ago)
Author:
Chamindra de Silva
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • BugReportingGuidelines

    v24 v25  
    1616'''Testing Coverage'''
    1717It would be good if the QA team specializes on testing certain modules in the system. More than one person can subscribe for a module and report their test coverage. The TestCases Page helps you with test coverage. Please select an area for testing and add yourself to the page
    18  * TestCases
    19 
    20 '''Test Process'''
    21 
    22 ''Testing UAT''
    23 
    24 UAT is a static version for testing before it gets uploaded to production. Please do the majority of your testing here
    25 
    26  1. Select an area that you will test in TestCases and add your name to it. Pick a module that has not been covered by others.
    27  1. Test the UAT version http://haiti-test.sahanafoundation.org by exploring the various navigation options and actions in the module
    28  1. Add you initials to the respective test case in TestCases. If the action does not exist in the TestCases please add it as well.
    29  1. If you find a bug also check if this bug exists in the production version http://haiti.sahanafoundation.org
    30    * if the bug exists in production mark the version of the bug as haiti-prod
    31    * if the bug does not exist in production mark the version as haiti-uat
    32  1. Check if the bug already exists in the bug tracker by searching for tickets http://trac.sahanapy.org/search or looking at report #9 http://trac.sahanapy.org/report
    33  1. Use the template below to enter the new bug in trac: http://trac.sahanapy.org/newticket
    34 
    35 ''Testing Prod''
    36 
    37 Ideally this testing is done as a result of doing Data Entry - this is the critical path right now as we're still short on data & this is the area which needs to be made more bullet-proof & smooth. Data Entry tasks are being coordinated using this [http://spreadsheets.google.com/ccc?key=0Aq_3OYelM4ZUdHJyc0lUekZLUmEwa3ZSU2dJS3YyWWc&hl=en_GB Google Spreadsheet]
    38 
    39 ''Testing Dev''
     18 * TestCases page is the main page were all testers work off from and handle assignments and coverage
     19 * UAT is a static version for testing before it gets uploaded to production. Please do the majority of your testing here
     20 * Production testing is done as a result of doing Data Entry - this is the critical path right now as we're still short on data & this is the area which needs to be made more bullet-proof & smooth. Data Entry tasks are being coordinated using this [http://spreadsheets.google.com/ccc?key=0Aq_3OYelM4ZUdHJyc0lUekZLUmEwa3ZSU2dJS3YyWWc&hl=en_GB Google Spreadsheet]
    4021 * The Dev environment is updated quite regularly, so don't be surprised to see some effects (RMS especially is changing rapidly)
    4122 * The Dev environment has modules activated which are not in production, so log these bugs as Low priority for now: DVI, Vol
    … …  
    5031 * Bug Supervisors may wish to check the [https://code.launchpad.net/~sahanapy-haiti/sahana/haiti-or Commit Logs] to see if they can see the Bug being fixed.
    5132 * '''Screenshots''' are good for showing the main problem screen if hard to explain, however, if you get a ticket, then simply the ticket ID would be better than a screenshot, as can simply copy/paste to find the relevant ticket)
     33
     34'''Bug Priorities''' (a scale for Haiti specifically)
     35 * Critical - big functionality, stability and data integrity defects in production
     36 * Major - functionality and data integrity defects in UAT only
     37 * Minor - UI, Style, Usability defects in prod and UAT
     38 * Trivial - Data validation defects, Domain defects
    5239
    5340Example: