Time in the Trenches: a #30DaysOfTesting Testability #T9y Entry

Ahhh, today's topic (well, this numbered topic, I'm not actually doing it on the designated day) is one that is near and dear to my heart, too. I think that many are the software testers who have also had some tenure doing tech support in either an official or secondary capacity. As this is another entry in the "30 Days of Testability" challenge, feel free to follow along and try out the day's exercises for yourself :).

What could you learn about your application’s testability from being on call for support? This eBook could help you get the most out of taking support calls.

The answer is "a great deal" and this comes from several years of personal experience. Customer Support engineers have a special kind of testing skill if they have been at it any length of time. It's what I refer to as "forensic testing" and many support engineers treat each call like an active crime scene. The best of them tend to be really quick at getting necessary information and if at all possible, getting to the heart of the matter fast and being able to retrace steps necessary to recreate a problem.

That was a skill that I found very helpful not just in the ability to find and confirm customer reported bugs but to also help me understand the various pain points that customers deal with. Getting into the customer's frame of reference and being able to appreciate the challenges they are facing can quickly help orient our everyday testing efforts. after time, we get a much clearer view of what matters to them.

If your support engineer isn't involved in an active firefight, ask them if they'd mind you shadowing them for a bit and listening in on their calls or working through an active issue. as one who has been both observer and active support personnel, I can assure you that you will learn a great deal regardless of your testing acumen and experience.