When a developer modifies Etere and releases a new version, the related ticket is left in FIXED status.
In order to ensure the functioning of the updates Etere provides to the customers, fixes have to be tested by Etere support and in this chapter we'll see how to proceed.
Note: Fixed incidents can be found in support website running the quick search default template called "Fixed".
1. Understand what the problem/request was
First of all, you need to know which was the problem to be fixed or the customer request to be implemented. This allows to have a picture of what the behaviour of Etere was before the modification.
At this stage, if you need, it could be useful to reproduce the same issue before installing the new version, in order to understand better what the wrong behaviour was.
2. Understand what has been modified and how
Once you know how Etere was working BEFORE, you have to understand how Etere should work NOW. Read carefully the developer notes, if available, or try to deduce the correction from the description of the issue. Some developers use to write a document and upload it in doma, explaining what the modification is and how does it work.
Note: For these first 2 steps, remember you can always use the online and internal help and search among support incidents as well, to get the information you need.
3. Choose the database and the workstation
Now the situation is clear, you can start to prepare everything for the test.
Choose the database to use, it must be reachable from the test pc and Etere must be already configured properly. For this purpose, there is a common database used and maintained by everyone in support, and each technician has also its own personal database.
The choice of the workstation depends on what do you have to test. If the test involves hardware components, such as an SDI card for example, you have to select a machine with the said hardware installed. Otherwise, you can pick any workstation. Etere support members have also a personal virtual machine, where they can make the needed tests.
Note: It's not recommended to use a database and a pc stored in different locations, you could have issues due to geographical latency. When it's possible, use local db and workstations.
4. Download and install the latest version available
Although it's enough to install the released version or a more recent one, installing always the last one allows to save time, because you don't have to search for the right version and because you may already have the right version for the next fix you're going to test.
This is valid of course for both Etere and Etereweb.
5. Execute system maintenance
It's always good practice to execute system maintenance if the database it's not already up to date, even if the fix doesn't introduce any modification to query and stored procedures. With the latest 35.2 and 36 versions, Etere introduced a new method to execute system maintenance, see the online help chapters 1.3.6.0 Etereweb setup and 59.9.4.0 NEW System maintenance (EtereUpdate.exe) for more information.
6. Potential preliminary configurations
According to what you understood and what you know, before starting the actual test, check if you need to configure something. In some cases, it's useful to reproduce as much as possible the schedule or environment of the customer, to get results the more reliable as possible (generally speaking, the less the variables are, the more reliable are the results).
This is an important step as it might seem the fix doesn't work, but you simply might have skipped or misconfigured something. In this way, you avoid to lose time repeating the test and the devs will make their checks on that matter only when it's really needed (or never, if everything works as expected).
7. Test
Verify if the behaviour you get is what the customer expects or what the developer described.
See below what to do after the test, according to the results.
WHAT TO DO IF THE FIX WORKS
• Ticket under internal code (700, 701, 1647)
In this case, if the internal notes don't say anything different, it's a modification or a fix requested by someone inside Etere (Fabio, support team, a dev...). Close the ticket.
• Ticket under customer code
This means a customer requested the modification or reported the issue which needed a fix. In this case, write by email to the customer, indicating:
- The version to install to get the fix
- If they need to do something before/after the installation to make the modification work
- The modification implemented (optional)
- In some cases it could be useful to provide customers a procedure to test the modification
Write a polite email, saying you're available to assist them if they need. If the customer wants support to perform the upgrade of a workstation (or the whole system, in some cases), the job have to be scheduled.
WHAT TO DO IF THE FIX DOESN'T WORK
If the test hasn't produced the expected results or if you received errors that didn't occurred before, you have to forward the incident to the developer. In order to make the dev's analysis easier, you should write the following in the internal notes, in a schematic but clear way:
• PC or PCs where the test has been done
• Brief setup of the test environment
• SQL server and database used
• Etere\Etereweb versions used
• If system maintenance has been done
• If you tested etereweb, indicate the URL to reach the website and the credentials of the account you used
• What you did and the results you got
• Any observation that you think could be useful
• What you did to analyze the issue experienced
• Questions
Additionally, upload in doma any screenshot, video or file, that could help the developer identifying and analyzing the problem.
All these information could be useful also to another technician of the support team: in case of a further test on the same matter, he will know everything that has been done and what is the test environment used, so that he'll be able to use the same setup and save some time.