Test Case Standards

Standards to be followed while creating test cases.
1. Test cases can be written in word document because it is easy to do spell check and check the syntax and semantics of the test steps. (It is not mandatory to use to word doc to develop manual test cases)

2. If you are writing the test cases in the excel sheet.
a. Easy to upload the test cases into QC 9.0.
b. Easy to update the test cases, test data and changes can be made in less time.
c. Reduce the rework
d. Utilize the features of excel in writing the test cases.
e. Create/Execute test cases by using QTP tool.
f. Easy to filter the pass/failed test cases to report
g. Easy to insert/update/delete a test step row
h. Easy to insert/update/delete a column

3. Each test case should have unique identified Test case number.

4. Each test case should include Scenario number, test case number and Test case name (S#_TC#_TestName)

  • Test Scenario is closely mapped to a Business Scenario/Business Requirement.
  • For example the difference could be the Test Scenario could also include the negative testing objective. One Test scenario may be mapped or split to many test scripts.
5. Each test case should have defined the Test case description.

6. Each test step should contain Step no and it should mentioned as Step1, Step2…..Stepn

7. Each test step should have description column, in that step description mentioned clearly.

8. Each test step expected result should be mentioned about the standard link names or tabs not the entire page information.
a. Example: If you login to the home page: Expected result will be mentioned about the tabs or name of the home page. Please don’t mention entire home page details. It is not a standard way to write a test case.
b. Similarly for the Client/Server applications also i.e. don’t include the all the information which is available in that specific page.

9. Test Case should be like a check list to make sure that all the requirements/functionality is covered.

10. Test scripts cannot be created / written with screen shots in the Action/expected results column.

11. Test case should be clearly written and understandable.

12. Test case should be followed KISS (Keep it short and simple) model.

13. Each test step to be defined clearly and next sequence step to be closed.
a. Example: If the link is opened in the new browser window make sure it is closed.

14. Each test case should have maximum of 25 steps.
Note: If the application type is transaction based then complete till the functionality ends. But if the application type is information based then it should not be more than 25 steps.

15. Informational application should be covered within the test cases based on the tabs.

16. Avoid writing the test steps to test repeated links.

17. Every Test case should start with the opening of a browser and end with closing of a browser.

Comments

Post a Comment

Popular posts from this blog

Terminal Emulation – QTP Automation Testing

Terminal Emulation – QTP Automation Testing Topics to be covered 1. Basic understanding of the terminal emulator 2. Emulation terminology 3. Configuring the QTP to work with TE application 4. Automation testing methodology Basics of Emulator • Duplicates the functions of one system using a different system, so that second system behaves like a first system. • Computer simulation Example: AS400 and mainframes is a dark green color screen AS400 is introduced in the year of 1988 by IBM, formally renamed as IBM iseries but still called as AS400 is mid range server for the small business and large enterprises. It will work good within distributed network and web based applications for execution it uses OS400 ie operating systems. TN5250 Terminal emulation protocol IBM owned iseries access by TN5250 with WRQ’s reflection, humming bird’s host explorer, Cybele software’s Z scope Express 5250. AS400 is also a Mainframe which are used for large organizations, for critical applic...
Read more

HP QC SQL Queries

Test-lab: SELECT CY_CYCLE AS "Test Set",        TS_NAME AS "Test Script Name",        TC_ACTUAL_TESTER AS "Tester",        TC_STATUS AS "Execution Status",        LEFT(CONVERT(VARCHAR,TC_EXEC_DATE,20),10)  AS "Execution Date" FROM TEST, TESTCYCL, CYCLE WHERE CY_CYCLE_ID = TC_CYCLE_ID AND   TS_TEST_ID = TC_TEST_ID AND CY_CYCLE_ID IN (cycleid) Test-Summary: SELECT CY_CYCLE,        TC_STATUS,        COUNT(TS_NAME) FROM TEST, TESTCYCL, CYCLE WHERE CY_CYCLE_ID = TC_CYCLE_ID AND   TS_TEST_ID = TC_TEST_ID AND CY_CYCLE_ID IN (cycleid) GROUP BY CY_CYCLE, TC_STATUS ORDER BY CY_CYCLE, TC_STATUS Run-rate: SELECT CY_CYCLE,        TC_ACTUAL_TESTER,        TC_STATUS,        L...
Read more

Challenges while executing the test cases for large project

Defects are in Closed status but the test scripts in either Not Completed or Failed or Blocked Status. Based on the conversation with Program Director regarding this, we have followed this method to get more productivity Identify the defects which are closed and find the linked test scripts. Moved those to No Run status by updating the comment section in the test plan>>Run suite. Identified the test scripts which are in the Not completed status for more than two or three days Check the test steps status and if there is an update on those ie more than 50% of the test steps has been executed in that case need to check with the concerned tester for further update. Else move the test script to no run status. Possibility of no action on the test scripts due to concern tester is moved out of the portfolio or left the company or not feeling well or any emergency Defect is in "closed" status, so the test script is moved to "No Run" status t...
Read more