This project is read-only.

Best Practices for Writing Test Cases for Crystal Test

Specific Descriptions

Do not use terms such as ‘Verify XXX works’ or ‘Verify XXX functions correctly’. Describe what page it’s on, where on the page (if ambiguous), and the functionality expected. A good formula to follow when creating test case descriptions is:
  • On the page, in the dropdown (optional), verify that when a user <action for object> <functionality>
This separates this test case from any other test case where there may be the same object with the same or different functionality and a Crystal Test user will see that it is not a duplicate of some other test case. The Expected Results should reiterate the functionality stated in the description of the test case. If you sort on description, you will then be able to locate duplicates, as well as missing test cases, much easier.
  • On the dashboard, verify then when a user clicks on the arrow on the projects dropdown, a list of projects is displayed.
  • On the functional testing page, verify then when a user clicks on the arrow on the projects dropdown, a list of projects is displayed.


Do not use acronyms. Keep in mind that these test cases may be executed by new employees. To where we may know what an acronym stands for, a new employee would not necessarily know that. If an acronym is commonly used, write out its full text with the acronym in parenthesis.
  • Crystal Test (CT)


Groups must be created in the Crystal Test before you can assign a test case to a group. To see a list of groups that exist for a project or to create a new one, view the AdminGroups page under the Admin tab in the Crystal Test. A test case should be assigned to all existing groups for which it belongs. If the test case introduces new functionality, create a new group and put all test cases for that functionality within that group. When creating a new group, groupTestAbbreviations should be in all caps without spaces or special characters and no more than 20 characters.

  • All test cases belong in the regression group.
  • If a test case is an integral part of the application, it should be included in the smoke test group.
  • All other groups would depend upon the functionality of the test case and where it resides in the site.

Do not create groups based on sprint or release #. ‘TestcasesSprint24’ is not a functionality group. When you put a sprint name in the Sprint field, you will be able to drill down by sprint to find all the test cases for that sprint. There is no need to create a group to do the same thing. Groups should define a specific functionality, application section, page, test run type, etc.
  • Functionality: Authentication
All test cases that involve logging in or other authentication would belong in this group.
  • Application Section: Admin
All test cases that require Admin level permissions to execute would belong to this group
  • Page: Homepage
All test cases that are executed from this page would belong to this group.
  • Test Run Type: Smoke Test
All test cases that are an integral part of the monetization of the application would belong to this group.


Sprints and releases must be created in the Crystal Test before you can upload or assign a test case to it. Please decide on naming conventions for your project's sprints/releases to ensure easy locating and assigning of test cases. A sprint/release name is unique and cannot be used more than once in the system. To see a list of sprints or releases that exist for a project or to create new ones, view the AdminSprints or AdminReleases page in the Crystal Test.
  • Release 1.4
  • Release August 24, 2012
All updates are kept for each test case, so perhaps if we need to look back and find out when functionality changed (perhaps to find when something broke) we can easily do this.

Test Steps

Test steps should be an ordered list. Prerequisites to test steps should be listed in the test step field, not the description field.
Do not include particular environment to test in (such as QA) as these tests are carried out in many environments.
  • No Navigate to the Crystal Test QA site.
  • Yes Navigate to the Crystal Test site.

Expected Results

When filling out ‘Expected Results’ field, do not put the expected results of each test step. Expected results should ONLY include what is expected after ALL the test steps are completed. Technically, each test step could be and probably already is a separate test case. If the tester needs to be aware of a certain state of the application after a step, list it in the steps. This way, the user does not have to continually look at 2 different fields for information on how to execute a test.

Test Case Notes

If a test requires using a certain application or requires certain data to be set up, make sure to include information about how to get this setup or how to use the other application in the test case notes.


Create/Update screenshots for EVERY test case. The only test cases that should not have screenshots are ones where there is no visibility such as backend tasks like verifying a data feed was imported. There should be screenshots for every major point of the test case. Remember, new employees may not know what they are looking for and if it doesn’t exist, how would they know without a screenshot?
You can also link an image URL but do not use URLs for screenshots that require a person to login to view or they will not show up in the Crystal Test.

HIPAA Warning: Never upload an image externally (even to your screencast account) if it contains Personal Health Information (PHI) or Personal Financial Information(PFI)! Take care to black out any PHI or PFI if uploading such images to the Crystal Test.

Snag-it is a great tool for taking screenshots. I recommend updating to the newest version as it will allow you to highlight things on your screenshots and write text etc. Also, Jing/Snagit automatically puts the URL to your image, when you upload it, on your clipboard. If you upload your image to a screencast account, you will need to navigate to this URL, then right click the image and select Copy Shortcut (In Internet Explorer) and then paste the new URL to the TCT or Crystal Test screenshot URL field. This is due to the fact that Jing/Snagit gives you a link to a webpage with the picture embedded. In order for the Crystal Test to show the image it must be a direct link to an image with a file extension of .jpg, .bmp, .gif or .png

Duplicate Test Cases

Before writing a new test case, ALWAYS check to see if one already exists for the same functionality. If so, either update it manually in the Crystal Test or create an update row on a TCT. When updating a test case, do not use text such as “Verify **** has changed…” Instead, just state what the new functionality will be. This is because once something has “changed”, the next time you execute the test case it will no longer have “changed”.
  • No In the footer, verify the copyright statement has changed from 2013 to 2014.
  • Yes In the footer, verify the copyright statement reads, “© 2010-2014 Pixeltrix, LLC. All Rights Reserved.”
Do not create duplicate test cases by building on previous test cases. Also, do not create separate test cases for each browser or environment. As each test case can be executed in many browsers and many environments.
  • No On the sign in page, verify a user is able to log in on the QA server in Firefox.
  • Yes On the sign in page, verify a user is able to log in.

Last edited Apr 4, 2014 at 9:00 PM by jacquelinewalton, version 5