Versions Compared

Old Version 24

changes.mady.by.user Bram Luyten (Atmire)

Saved on

compared with

New Version 25

changes.mady.by.user Bram Luyten (Atmire)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Explanation for all of the fields.

...

Mandatory fields (per test)

Ref - a short, unique reference that can be used in related JIRA tickets etc. example VIEW1

Category - an indication of the functional group a test belongs to. example VIEWING

Description - a step by step description of how the test should be executed

Expected outcome - the expected result after execution of the description

Test status - status of the last time this was tested. This column should be filled in with following vocabulary:

  • 2014-09-12 : when a date is entered, the functionality was verified. 

  • TEST UNCLEAR: the description of the test doesn't make it clear either what to test, or how a user can test this.

  • FEATURE MISSING: the described functionality couldn't be verified

  • UI PROBLEM: the feature is there and seems to "work", but there is a UI problem (nature of the problem clarified in comments)

  • NON COMPLIANCE: the test fails the expected results

  • DOCUMENTATION: feature seems to work but docs seem to be missing or incomplete

If you are doing a test later in time, you can overwrite the test status that someone had previously entered

Last tester - name of the person who executed the last test. The main goal of including the person here, is to make sure he or she can be contacted for further information about the test

Comments - free text field for additional comments. If the comments of the previous tester are not yet resolved or are still relevant in another way, you can leave them in and add your own comments in the same cell. When doing this, start your comment with your name, so people can see a different person added the next comment

JIRA tickets - links to JIRA tickets that are related to this test. These links should never be removed, so we still have the entire backlog on what has changed to these tests.  

Structure of the test spreadsheets

The spreadsheets are organized into different tabs. Each tab represents a "role" of a user that is able to execute all tests on the tab. The roles who need a higher level of authorization are more on the right. . This means that a role on the right could theoretically also execute all of the tests on the tabs more on the left (but we're not targetting that actively right now).

Requirements for demo.dspace.org installation

...