AaronKGumbs

As a manager of a team of consultants, I no longer have my own configuration problems anymore, so troubleshooting is a theme that plays into every single working day.

When I started 10+ years ago, seeing an error would fill me with dread, sweat, and stress that I just couldn’t shake, and today I see technical bugs as a little bit of fun to try and solve the unknown! Some will think I’m strange, but everyone has their niche.

My thought process has changed dramatically over the years and it’s not something that you can teach, it’s all experience. I used to panic particularly about the reaction of everyone around me.

• I’m an awful consultant.
• I bet the client/end user is going to be so angry.
• How do I tell people that something is wrong?!
• What if I don’t know how to fix it?

Today it’s entirely different and it’s all about the tech, and here are just a couple of provocative sentences for to consider when troubleshooting technical issues to slow down the pace of thought and to focus on the outcome. I can assure you there is a good explanation!

100% pass rates during testing are terrible.

If test scripts produce a pass rate of 100% then it is very likely that we haven’t considered all of the possible paths that the end user may take, and we might have focussed on the happy path too much.

We want to break things during testing, as it means that they’ll be fixed or known about with recommended workarounds by the time the feature moves to the production environment with real users.

Taking a Power Platform example, when testing a requirement such as ‘Entering data into the Contact Table’, perhaps we should consider:

• What happens if I upload instead of creating from the Form? Are all rules respected?
• What happens if I create the Contact from another record, does the Form behave the same way as it would if I were creating the Contact standalone.
• What if I create many versions of the same Contact to try and confuse the system? Does it change the way that the system behaves in other areas?

These tests may seem extreme, but remember, we can never guarantee that an end user will work in the way that the system is built, which often highlights the result of a potential gap between UI and UX.

There are some fantastic examples out there describing this difference which you can find online. Think of the glass bottle of ketchup that we place on its lid when it’s running out so that we can get every single last drop, and how we used to bang on the bottom of the bottle or use a knife to try and help the flow through the thinner neck at the top. It’s no coincidence that today’s bottles are plastic built and have the lid at the bottom, with a width the same across the entire length of the bottle, as well as a squeezy mechanism to help with flow. These are all features that were created because of user experience rather than user interface.

Another notable example I can also almost guarantee that everyone reading this post has been guilty of – The great corner-cutting mud patches that we find in parks or woodlands where two paths meet at a 90° angle. The paths always look nice, but we are built to try and be efficient, and watching someone follow the path in this case can often look unusual. In our local area we’ve had five new-build estates pop up and they all feature non-linear paths. I wonder why?!

Work out who’s to blame.

Wait what? I thought we were all on the same team here. You’re absolutely right, but there are so many parts to any software delivery that you really do need to identify which supplier of the technology is causing the issue.

One of the most interesting examples I saw of this recently was a scaling issue in a Power App that was being loaded through the Website tab in Teams (for good reason, it had an appended URL!). Out of context, the Power App would render fine with no issues functionality or cosmetically whatsoever, but then it occurred to me that this is a 4-level hierarchy of display settings!

• The person accessing the app is using a desktop monitor with a resolution and scale.
• Teams on the desktop also has its own scaling percentage.
• The Website tab, just like web browsers, is mobile responsive.
• The Power App also has its own scaling and ratios built in as well as orientation.

In this setting, we had control over the Website Tab configuration and the Power App configuration, but we can’t ask end users to use a specific monitor resolution and scale, nor can we change their Teams environment. Rather than ‘fixing’ the perceived issue, we have to work with it, and in this case the ‘fix’ that worked for us was the ‘Lock Aspect Ratio’ setting on the Power App’s Settings so that it rendered in the way that we wanted it to irrespective of other scaling factors that we can’t control.

Final Thought

Bugs will always occur in software delivery, we see it from every single software supplier in the world. So, let’s not be afraid of them and let’s tackle them head on and ask ourselves some thought provoking questions in the process!