My spyglass into the code

As a tester you don’t always have access to the code of your application. Sometimes this doesn’t matter, but it can also be very useful. I can’t keep up with the developers writing code, but I do have a tool that allows me to use the code to my advantage.

That tool is the ‘AppMon’ by Dynatrace. This application monitoring tool injects code in the code-base and records all the executed code. This data can then be displayed and searched. As a tester, this provides you with a massive amount of information and a spyglass into the code.

disclaimer: This is not a sales pitch. This is just my appreciation for this tool in form of a blogpost. There might be similar tools out there that do the same.

Detailed monitoring

One of the things that’s monitored are the separate calls that are done. It gives you a stacktrace of all the methods that are called and how long they took. This makes it fancy log that gives too much information for most developers to be useful at first. But once you get to know all the filters, you can find the information you’ve been looking for very fast.

2017-06-02 14_37_07-abezwiv0075.emea.agrogroup.net - Prod - Dynatrace Client

The different calls are recorded under the name ‘purepaths’. They even indicate if they were successful or not. If you encounter a failed database statement or an exception, you’ll be able to spot the bad calls and investigate them.

2017-06-02 14_42_10-abezwiv0075.emea.agrogroup.net - Prod - Dynatrace Client

There’s also a way to visualize the flow of the call. This gives you an indication of how much time was spent on what part of the application and the number of connections you’ve made to other systems.
One of they important things you can take from this diagram is the number of database calls. You wouldn’t want to fetch every row 1-by-1, but in bulk to save time

2017-06-02 14_58_55-abezwiv0075.emea.agrogroup.net - Prod - Dynatrace Client

Another way of finding issues or failed calls is by looking at the ‘errors’ page. This page shows you all the ‘Exceptions’, ‘Log messages’ and other errors. This is a good place to start your investigation of troubles your customers are experiencing.

2017-06-02 14_49_25-Errors Dashboard - Dynatrace Client

Larger scale

Another part you’re monitoring is the application server itself. Everything from CPU Usage to Memory and Disks space. Not only per server but also for the processes of this server.

This is information that is not always available for the developers. In our environment, the servers are maintained and monitored by another team. So our team doesn’t have any clue what the load on the servers is. Only if problems start to rise, they start investigating.
It also allows you to do thread dumps, Memory snapshots, …

Sensors and dashboards

Since this tool gathers so much information about your application, you can add several sensors to warn you about problems that you’re having. for example, an email will be sent out when the diskspace of a certain server is full or when a server starts ‘swapping’ when the RAM is full. On the other hand, this functionality allows non-technical people to go to technical people with questions and proof.

To make all this data visible and usable, you can create dashboards that show you all the information you want. This again ranges from number of active users, to general user happiness to server health.

The user happiness, is measured in a special way. A javascript gets implemented in the front-end and all actions are sent back to Dynatrace. This allows you to see what a user did to come to a certain error or how the application is used.
This is very useful for acceptance testing. The application is still bug prone but key users generally aren’t trained to write down ‘steps to reproduce’. So when a defect does come out, you can go to that particular testing session by that particular user and see what they did to come to that result.

2017-06-06 11_05_23-abezwiv0076.emea.agrogroup.net - Non-prod - Dynatrace Client

With these measurements Dynatrace makes an estimation of general user happiness. Everything goes good, that means you get a 1/1, good job! If one of the last calls failed or took a long time, this might be less. If the last call failed an the session ended, you get a 0/1. Several other things have to be taken into account of course, but it does give you a decent estimation.

Conclusion

I like Dynatrace because it gives me an opportunity to take a look at the code. It allows me to pin-point problems and even find problems that I wouldn’t be able to find before.
It can help developers in their development process and even give them a window to what’s happening on the server itself.
All these measurements can be shown in nice dashboards that can be shown to management and decisions makers.
Recently a new version, version 7.0 came out. I’m very curious to see what new things it brings.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s