wiki:Testing/TestCases

Version 73 (modified by Fran Boon, 10 years ago) ( diff )

--

Test Cases, Coverage and Test Assignments

You can find some manual Test Cases for Eden as a shared Google Spreadsheet here

Test Cases should be automated in Selenium:

Discussion on Testing should take place on the main -eden Mailing List.

Notes for Testers

We need to agree on ways of working for an effective partnership between Testers & Developers.

Please note that Internet Explorer 6 is not supported, so bugs on IE6 should not be reported.

If there is a possibility that the bug could be IE7-only then please do check the issue in Firefox, Chrome & IE8. Then the bug can be logged with either an 'IE7:' prefix or else the details show that the issue is observed cross-browser.

  1. Do not set a due date for bug reports - I don't think that is appropriate, especially when you set it to *today*. The due date field is for developers, not to express your expectations.
  1. Do not expect bugs being solved when your report is being modified for triage - especially not if the developer asks you back for more details.

Instead, be so kind and answer the questions that you get back on your report (=comments in the report) within 2 weeks - otherwise we're unable to do anything else than to close the report as "invalid".

  1. Please do not either expect that by closing a bug report as "fixed" the respective fix does immediately get applied to your testing site.

If a bug report is being closed, you should not immediately re-open it just because the fix has not yet reached your test server. It is very distracting to try to identify bugs that I have actually fixed yesterday - so, please give a minimum delay of 5 days before re-opening a "fixed" report or re-submitting the same issue.

  1. Do not either expect a bug being removed when we're closing it as "duplicate". If we identify and close your report in module XXX as a

duplicate of a similar report in module YYY, then you should not re-open it with the comment "but this has been seen in XXX".

Please do understand that from the architecture of our software it can very well be the same problem which just affects multiple modules - and if we identify it as a duplicate, then that is usually true.

  1. If anyhow possible, please try to check whether your problem has already been reported. We're experiencing up to 10 different reports for one and the same issue, with just different wording, sometimes by the same tester.

Of course we do not expect you to always manage to identify duplicates, but if it is obvious, then you can help us more by avoiding needless extra work.

  1. Please *do* always specify the component you found the issue in, but do *not* set it back if *we* changed your setting.

High Priority Focuses for testing

Production testing is done as a result of doing Data Entry - this is usually the critical path as we're generally short on data & this is the area which needs to be made more bullet-proof & smooth. Data Entry tasks can be coordinated using a Google Spreadsheet, like this one used for Haiti.

Testing Coverage

  • It would be good if members of the QA team specialize on testing certain modules in the system.
  • More than one person can subscribe for a module and report their test coverage.
  • Please select an area for testing and add yourself to the page
Module Tester name / email
Organization Registry
Requests Management
Inventory Management
Shelter Registry
Hospital Management
Human Resource Management
Assets Management
Events & Scenarios
Incident Reporting
Assessments
Disaster Victim Identification
Map

Specific Deployments

Test Edit for Demonstration

  • bullet list emph

BugReportingGuidelines

DeveloperGuidelinesTesting

Note: See TracWiki for help on using the wiki.