Changes between Version 63 and Version 64 of Testing/TestCases


Ignore:
Timestamp:
09/03/10 16:32:05 (14 years ago)
Author:
Fran Boon
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Testing/TestCases

    v63 v64  
     1[[TOC]]
    12[[TOC]]
    23= Test Cases, Coverage and Test Assignments =
     
    67Discussion on Testing should take place on the main -eden [MailingList Mailing List].
    78
     9== Notes for Testers ==
     10We need to agree on ways of working for an effective partnership between Testers & Developers.
     11
    812Please note that Internet Explorer 6 is not supported, so bugs on IE6 should not be reported.
     13
     14 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.
     15
     16 2. 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.
     17
     18Instead, 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".
     19
     20 3. Please do not either expect that by closing a bug report as "fixed" the respective fix does immediately get applied to your testing site.
     21
     22If 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.
     23
     24 4. 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
     25duplicate of a similar report in module YYY, then you should not re-open it with the comment "but this has been seen in XXX".
     26
     27Please 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.
     28
     29 5. 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.
     30
     31Of 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.
     32
     33 6. Please *do* always specify the component you found the issue in, but do *not* set it back if *we* changed your setting.
    934
    1035== High Priority Focuses for testing ==