In order for a testcase to be able to function properly, the application under test must be in a stable state when the QA engineer begins to execute test case. This stable state is called the base state. The recovery system is responsible for maintaining the base state in the event the application fails or crashes, either during a testcases execution or between test cases.
Each automated test case is independent; it should perform its own setup, driving the application to the state QA engineer wants to test, executing the testcase, and then returning the application to the base state. The QA team and the testcase should not rely upon the successful or unsuccessful completion of another testcase, and the order in which the testcase is executed should have no bearing on its outcome. If a test case relies on a prior testcase to perform some setup actions, and an error causes the setup to fail or, worse yet, the application to crash, all subsequent tescases will fail because they cannot achieve the state where the test is designed to begin
A test case has a single purpose – a single test case should verify a single aspect of the application under test. When QA team designed automated test case in this manner passes or fails, it's easy to determine for any team member specifically what aspect of the target application is either working or not working. If an automated test case contains more than one objective, many outcomes are possible.
In short the important aspect of test case for automated testing :
- The testcase should always start from a predefined base state and return to the same base state.
- The testcase must be independent from any other test cases.
- The testcase must have only one test objective
1 comment:
does any QA Engineer know how to write script in 4test language to update an Excel spreadsheet using SilkTest?
Post a Comment