QA/Litmus Redesign/User Work Flows

<< Back to the Design Center

Put here the things that users of litmus (non-administrators) must be able to do. If you've got a workflow but you're not sure what type of user it requires, put it here.

Point of Note Use "test-runner" for user running tests, and use "test-writer" for user writing tests. If the user in mind could be either, use "user" to designate them.

Creating a simple testcase

• Determine if a test case already exists or not
  • Do this via searching for a testcase, if it is not found, allow user to create it.
• when creating a test case the user must provide
  • product
  • title
  • steps
  • expected results

• When a user starts to write a test case, provide an example test case
• Provide examples on how to search for test cases
• At one point (it might still) Litmus had a nifty instructional mode where the UI would be overlaid in yellow detailing what the user should and could do. We should keep that idea for aiding the user to use the product, if/where necessary.

Searching for test cases

• Able to search by product
• Search all products by default
• by tag
• by run date
• by test added date
• by title
• by test ID
• by test case locale

Running Tests

• Ability to hand people URL for specific test runs

• There are generally two types of users running tests:
  • People who want someone to "tell me what to do" for them:
    • You need to have prebuilt test runs that are created for them
    • Descriptions of different test runs should be available
    • Should be able to distinguish between areas of test runs that exercise specific componentry of the product and the ability to select recently created tests for running.
  • The other type of person is the "I want to do x"
    • These people will probably be search oriented to find the test run they want to work on.
    • Ability to search by runs, tags, title, and it should show you all relevant results.

Test Writing

• Easy ability to include specific instructions for common actions. For example, getting the preferences window is a very common action. There should be an editing widget the test-writer places in the test for this so that the test-runner can mouseover the item and will see a pop up dialog that describes how to get to the preferences window on each platform (or perhaps only on their platform?).

Duplicating a test case

• Should have UI for easily writing a related test case
• Ability to copy a related test case, copying over data from another related testcase via a "make copy" button or some such.

Failing Test Workflow

• Ability to quickly and easily make a bug out of the failed test using bugzilla (the bugzilla link should be configurable based on the project settings so that bugzilla starts in the right product instead of the general "new bug" page).

• Test should be able to be associated with more than one bug.