One of the more consistent concerns when deploying a new application revision or making an application change is how to effectively maintain a ZebraTester scenario that has already been created in the past. While there is no “one size fits all” solution to this problem, this article will help outline a few things you can do during and after the scripting process to ensure that your scenario may be primed and best suited to handle future application deliverables/deployments.

If it is possible to track down a change log or a version update reference document, it will help you before you begin updating your scenario to get an idea of what was changed in the application.

Re-Recording:

This would be necessary for a variety of reasons—Generally speaking if the application had a major overhaul (For example: New DATA gets POST’ed to shopping carts, new application variables are defined, or there is a new payment gateway in place) This would require a re-recording of the scenario to ensure application sanity. That is—ensuring variables get set initially and picked up and used on subsequent calls.

Non Re-Recording:

If there are minor changes in the application—For example things like a new stylesheet was added or changed, or new images were added, your scenario can be optimized to ensure these changes will not cause errors in your results.

1. It is a good idea to ease your validation on binary images, css, and assets. This will ensure that if the size of your asset changes, or new css is added, it will not cause soft errors. To do this, first click the magnifying glass in the response verification column.
2. On the HTTP response verification and failure action panel, you can uncheck verify content (which will remove the default size validation on binary assets). You may also wish to uncheck content-type. One thing that frequently happens is mime-types change. Text/Javascript often becomes Application/X-Javascript, etc and this would cause soft errors if left in place.

Other Tips:

• If your scenario uses an input file for data input, it is generally advisable to keep the format the same. This way you can potentially re-use your input list without having to redo your data.

• Use user-input fields with real-time changing when applicable for capturing things that you may need to change or optimize later on. For example, if your analytics currently call for page breaks to have a think time of 15 seconds, you may find out later on that this needs to be updated to 20 seconds. Normally you would have to re-edit your scenario and change this value to 20.

• When defining a new variable, ensure you check the real time box.
• Now when running this scenario from the Apica Load-Test portal you will have a new option to change this value before the load test, and DURING the load test (realtime).