the effect of scripts in test
when recording the test, testcomplete automatically creates the sequence of activities recorded during the test, so why do we need the scripts? how does changing scripts affects the course of the t...
Forum Discussion
Your questions is:
"so why do we need the scripts?"
Let me see if I can answer this for you. I am not sure if I am going to give you the answer you want. But here goes.
In my opinion, using Test Complete in a record and playback manner is not using the tool to its fullest potental AND has some drawbacks.
When recording a test, the object that TC records in not recognizable at playback time. By writing some code, I can intelligently handle the acquisition of the correct object. (There may be mechanisms for doing this in keyword testing. I know next to nothing about keyword testing.)
Furthermore, I can make robust tests by designing script routines that can be reusable, test more than one thing... For example, I have a high risk area of the system in which users can perform a set of actions on some selections. I have several procedures
- GetStartingState
- UserPerformsSelection
- UserPerformsAction
- DoComparetoExpectedResults
In each case, the selection, desired action and expected results are all stored in an Excel spreadsheet that drives (see DDT) the tests. I can very quickly create new tests across a wide variety of selections and actions and compare the data to the expected result. When we develop new actions, I can very quickly create new tests to test those actions...
Hope that helps / addresses what you wanted to know.
"so why do we need the scripts?"
Let me see if I can answer this for you. I am not sure if I am going to give you the answer you want. But here goes.
In my opinion, using Test Complete in a record and playback manner is not using the tool to its fullest potental AND has some drawbacks.
When recording a test, the object that TC records in not recognizable at playback time. By writing some code, I can intelligently handle the acquisition of the correct object. (There may be mechanisms for doing this in keyword testing. I know next to nothing about keyword testing.)
Furthermore, I can make robust tests by designing script routines that can be reusable, test more than one thing... For example, I have a high risk area of the system in which users can perform a set of actions on some selections. I have several procedures
- GetStartingState
- UserPerformsSelection
- UserPerformsAction
- DoComparetoExpectedResults
In each case, the selection, desired action and expected results are all stored in an Excel spreadsheet that drives (see DDT) the tests. I can very quickly create new tests across a wide variety of selections and actions and compare the data to the expected result. When we develop new actions, I can very quickly create new tests to test those actions...
Hope that helps / addresses what you wanted to know.
