My team and I want to use the testcase recorder more.
However, there is one problem we have encountered: it is not possible to change tables in one test case.
This limits us to recording very small steps of a single process.
When we want to create a case for an entire demo scenario, this takes a lot of time.
Would it be possible to include the changing of tables as an separate 'Test step'?
Open
Testcase recorder: change of table
+5Hi Kevin,
You aren't the first one to ask for this feature, so I expect many votes!
The reason this hasn't been released with the initial version of the test engine and test case recorder is that there was no reason to identify the different documents. Switching from the initial document to a new document wouldn't be difficult, but there would be no way to switch back between the varous opened documents as there was no mechanism in place to differentiate the opened documents.
With process flows, this was eventually solved by providing a document ID that can be stored as a process variable and used later in a process action to return to the document. We'd need a similiar system in place for the test recorder and test engine.
In the meanwhile, I would recommend creating a test suite for tests of processes that span multiple menu items. This would indeed mean recording one menu item at a time.
You aren't the first one to ask for this feature, so I expect many votes!
The reason this hasn't been released with the initial version of the test engine and test case recorder is that there was no reason to identify the different documents. Switching from the initial document to a new document wouldn't be difficult, but there would be no way to switch back between the varous opened documents as there was no mechanism in place to differentiate the opened documents.
With process flows, this was eventually solved by providing a document ID that can be stored as a process variable and used later in a process action to return to the document. We'd need a similiar system in place for the test recorder and test engine.
In the meanwhile, I would recommend creating a test suite for tests of processes that span multiple menu items. This would indeed mean recording one menu item at a time.
+5Hey Kevin,
It seems to me that you are using this feature for another goal than solely testing a complete application.
If you write test cases or record them, it is good practice to test small steps because this is more maintainable. Then the limit becomes a tool to guide you into testing small steps.
I wonder what dedicated testers will think about this idea.
It seems to me that you are using this feature for another goal than solely testing a complete application.
If you write test cases or record them, it is good practice to test small steps because this is more maintainable. Then the limit becomes a tool to guide you into testing small steps.
I wonder what dedicated testers will think about this idea.
- Rookie
- 1 reply
Hi Kevin,
I like to respond to your idea and its replies. As a dedicated tester I have encountered this same obstacle in setting up my process regression test cases. We now have to set several test cases in the right order, for them to be run as one process. This is far from ideal.
What I believe would be a good solution is to be able to make 'test case building blocks'. These blocks consist of a test case (with it's steps and checks in a specific table) that can be added to a test case as a test step. Building blocks are maintained in one single place, but can than be added to multiple test cases.
For example: There are 3 test case building blocks, A, B, and C. These blocks are used as follows:
This enables you to reuse test cases, reduce maintaince, increase flexibility and test a full process of multiple tables with one single test case, without making them too big.
I like to respond to your idea and its replies. As a dedicated tester I have encountered this same obstacle in setting up my process regression test cases. We now have to set several test cases in the right order, for them to be run as one process. This is far from ideal.
What I believe would be a good solution is to be able to make 'test case building blocks'. These blocks consist of a test case (with it's steps and checks in a specific table) that can be added to a test case as a test step. Building blocks are maintained in one single place, but can than be added to multiple test cases.
For example: There are 3 test case building blocks, A, B, and C. These blocks are used as follows:
- Test case 1: Building block A + Building block B + Extra test steps
- Test case 2: Building block A + Buidling block C + Extra test steps
This enables you to reuse test cases, reduce maintaince, increase flexibility and test a full process of multiple tables with one single test case, without making them too big.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.