Is it normal to have so much red tape in reporting bugs?

Question

My workplace adopted some software several months ago, at the outbreak of COVID-19, to help us conduct our work remotely. The software has been extremely buggy, to the point of slowing down our productivity considerably. I am now bringing 10-15 hours of work home on weekends above previous amounts.

Since I've added so much to my at-home workload, I put much effort into filing bug reports, especially for those most serious bugs. I file bug reports for FOSS projects frequently, and usually the bugs get fixed.

The problem is, this software company requires bugs be reported as a "support ticket" and I get stuck in a seemingly endless quagmire of requests for more and more details. I post highly detailed descriptions: I'm updated, I tried it on multiple platforms, took screenshots, checked with co-workers to confirm they all have the same problem. Still, it seems never enough for the support, they want more and more information. "Try it on this browser". "Try rebooting and see if it still happens." "Make a screen recording for us". "Try it from home instead of on work servers." "Ask someone else to do X, Y, Z, and send us more screenshots..." It never seems to end, and so far they've resolved none of my issues.

I don't work in software development, I'm an educator. Is this at all reasonable that I should be expending so much effort to get serious bugs fixed?

Answer 1

No, it's not reasonable that a non-technical end user is asked to do so much investigation into a bug they've encountered. This sounds to me like you are stuck in a situation where everyone else involved has interests other than making sure the tool enables you to do your work.

If your IT department is not supporting it, it sounds like someone forced them to accept a tool they didn't want to use, and now they are going to stand by and let everyone suffer the consequences of that bad decision. If the software company is making you jump through a lot of hoops when you try to get technical support, it seems to me like they are trying to seem responsive so they can keep getting paid by your employer without actually having to expend any of their own resources to fix your issue.

The only solution to this is to escalate it to your management. Even though I am software developer, when I am trapped in a situation like this, I will simply refuse to jump through any more hoops after I have given them a reasonably detailed report and answered any reasonable follow-up questions. I then escalate the issue every time it impedes my work until it gets solved, I get a work-around, or I feel like someone is trying to get it solved.

Do not be rude, because often the people who are giving you the run-around are also stuck in a situation they have no control over. Just keep adding people to the CC: list until you find someone with the power to unblock you. Any time anyone tries to help me make forward progress, I make sure to let them know I appreciate their effort. Even though the situation is really frustrating, try to presume that the person on the other end of your support request actually wants to help you, but may not have the ability to through no fault of their own.

Answer 2

As an developer with more than 10 years experience in handling/solving support tickets I must say you look like a dream user to me. A (non-technical) user who writes highly detailed descriptions of what's wrong, adds screenshots, is updated, checks with others if they also experience the problem, is hard to find. In a lot of cases otherwise capable and intelligent people seem unable to write a coherent story about exactly what is wrong (and I often managed to solve those problems too).

So if you experience multiple/all times that a support ticket doesn't get solved or no progress is reported on it, I think it's likely they are just stalling you and no actual effort is spent solving your problems. So the only solution seems to be is that someone with authority within your organization steps up.

Answer 3

The software has been extremely buggy, to the point of slowing down our productivity considerably. I am now bringing 10-15 hours of work home on weekends above previous amounts.

The first question I have is are you reporting this to the manager?

Is this at all reasonable that I should be expending so much effort to get serious bugs fixed?

Yes and no. Ultimately it comes down to money. As your employer is paying the money, the company has to assume that it is "working for everyone but you." If you're the only person experiencing the bugs, then yes, them asking for details may make sense for them ask you to try it out on a co-worker's computer to see if the bugs happen. Also cross browser support is tricky and sometimes changing browsers do help. It doesn't hurt to try it out cross browser just to verify as many times certain software will be made for one particular browser.

My thought is you should try the ticket's advice. Say you tried it across browsers, across co-workers, etc and it still doesn't work. I would also bring it up with your manager.

It's not very convincing, at least to me, to come to your manager and say, "I don't like it because they're trying to help me by asking questions." Instead you should state, "Boss, I am having a large amount of issues with this software. I am not able to do X, Y, and Z effectively and it is causing me to work 10-15 additional hours just to make up for the lost time in resolving these issues. I tried to contact the tech support but thus far, my issues are not being resolved. What can I do?"

I would also clarify to your manager that you're having to work weekends just to make up for the lost time you spent trying to resolve these issues. I want to say time is of importance here as well because the more time that goes, the less credibility you have. You already said you had this software for several months and you're only now bringing up the issues. I think you lose credibility when others are using the software to do their full work without losing time with bugs, and you're bringing it up months later. Your manager may reverse this and say that you have to resolve it because others are able to work and he/she hasn't heard of the same issue. You should bring it up as soon as you experience the issue and finding that the tech support is an endless back-and-forth and you're having to work 10-15 hours more. I would have brought it up the first time I uncovered the issue.

Answer 4

Another developer's perspective here - this is symptomatic of a company with poor support systems.

The problem

When I'm developing, I can run the code line by line and see exactly what's going on. If there's an error I can usually see the exact path that was taken to get there. I can see the contents of the database, and for complex issues I can delete irrelevant data or create test data to help isolate the problem.

When I'm trying to track down a problem on a live system, I don't necessarily have the ability to do any of these things. I may not know your exact inputs, or the data it references. If I can make the same issue happen, I can debug it as above. If I don't understand the scenario well enough to recreate the problem we end up with "it works on my machine".

Back when I did support, I didn't even have access to the code. If I hadn't seen the problem before I had a few "hail Mary"s like rebooting, or starting from a clean document, but I'd have to pass the issue onto the developers, who were usually already working to a deadline to get the next version out.

The solution

First of all it sounds like you might be dealing with support department who aren't getting much help from their developers. Ask them if they can recreate the problem from the information you've given them so far.

Second, their developers need better tools. They should be asking you for log files, data exports, etc - things they've put into the system to record its internal state for them. The problem is that most companies don't see the value in these things until they've wasted a lot of time or lost an important customer. Putting in a new feature in order to win a new customer always has priority because it generates revenue.

What you should do

As the others have said, escalate this to your boss. Tell him that you can't continue to work unpaid overtime, and sooner or later your output will suffer. If the rest of your team is having similar problems, that's a big issue for him to take to his boss, or whoever is paying this provider.

Ideally there should be one person in your company with a list of all the issues and the power to change provider if things don't improve. That will cause the provider to devote some developer time to the problems rather than just hoping the support people can keep you quiet.

Answer 5

You mentioned that you are an educator. Don't forget about your most powerful resource. You have a multitude of fellow teachers who are all using the same software and are experiencing the same problems and bugs. Use that to your advantage.

Have your colleagues file bug reports on the same issues. Let them know what sort of screenshots and details to provide since most non-technical people don't have experience with that sort of thing. It's easy for the developer to ignore or downplay your ticket if they think it's user error or a system-specific issue. If they get independent reports of the same problem from 35 different people, all using different machines, then it's a lot harder to ignore. It also helps the developer understand just how many people this issue really impacts. Telling them it impacts the whole school is one thing. Getting bug reports from everyone in the school has considerably more impact. When bug reports start piling up that all come from email addresses from the same domain, management starts to worry that they could lose a customer if they don't get the problem addressed.

From a developer's point of view, it's frequently easier to investigate and fix a bug when it has been reported by multiple people. Everyone has a slightly different way of looking at or explaining things, and having multiple perspectives on a problem is useful.

Now if you weren't an educator, I think ColleenV's answer of escalating through management would be a more appropriate solution. Educators don't typically have that as an option, though, since the management structures are completely different than a corporate environment and IT departments tend not to have the same sort of escalation processes.

Answer 6

TL;DR If the developer can't identify the issue then it doesn't matter how detailed the report is.

I'll explain how things happen in a development firm,

At least 1 of 2 things must happen in order to fix a bug,

1. They must be able to figure out what's causing the issue from the description.
2. They must be able to reproduce the issue (in development machine) from your description.

The chance of the point 1 happening is too low. If they can reproduce the issue then they won't be needing any more details.

Types of Issues

1. Work flow errors - These can happen when the software is used differently from the way it's supposed to be. Almost always these can be fixed by the support team without involving developers.
2. Reproducible errors - These will be fixed by the support team or developers depending on it's accessibility or complexity.
3. Random errors - These are the worse error a developer can encounter, like "Once in a while when I click this it shows an error".

What is a support ticket?

Most of the time developers are not involved in supporting the customer. It's usually handled by a support team. They usually have a good knowledge about working of the software but less in actual development. Their main role is to identify the issue, fix it if possible or handover to developers in a reproducible way.

Support tickets are need to track the progress of an issue. It also help to identify similar or related issues and how long it took to resolve the issue. If the support team or developers are unable to reproduce the issue then it will come back to you for more details.

What I recommend,

1. Try using Ctrl + F5 to clear cache and reload the webpage.
2. Try clearing the local storage and cookies in browser and disable extensions. You may need to search for instructions on doing this.
3. Try to recreate the issue in updated versions Google Chrome or Firefox. Using IE, Edge or outdated browsers are not recommend.
4. Create a step by step instruction to recreate the issue with browser details. Write it as if you are giving this to a new joiner in your company. Don't give out passwords and other secure/private details.
5. If the instructions are long or complex create a video recording. Always create a video if you are reopening an old ticket.
6. If you think it may come back, send the instructions and video to a co-worker without explaining it to him in person. If he can recreate it, you are good to go.

The above instructions won't work if it's a random error. In that case you will just have to give them what they want.

Even after doing all this you still get request for details, then it may be a good time to talk to the manager of your development firm. Please note down the ticket numbers and have lots of “proof” before doing this.

Answer 7

You are filing tickets with a first line support team. Their role is to resolve customer's problems without bothering the expensive development team. They do not have access to make changes to the actual software (they can't fix bugs). Often they can be very effective in their support role - you'd be amazed how many calls these sorts of teams get that really are solved by turning the computer off and on again. They will also be familiar with errors that frequently occur in the application they are supporting, and how they can be fixed or worked around.

But sometimes there will be errors that they are unable to resolve, perhaps because there is a bug in the software that requires a code fix by a developer. At that point their role changes, and instead of fixing your problem, they need to clearly describe it in a way that someone else can fix it. They should be taking your description of the problem and repeating the steps on their own computer until they can see the problem too. They can then pass their description of the problem onto the developers, so they developers can change the software (fix the bug).

If they keep asking for more information, this could be because:

1. The support team do not have the necessary experience to reproduce your issue and describe the bug to a developer, and they are not able to pass the tricky issues on to a more experienced member of staff.
2. The issue is intermittent and hard to reproduce.

Answer 8

When shipping software to a large number of users, especially non-technical ones, there is a dilemma:

• Let the users communicate with developers - allowing less red tape and miscommunications, but at the price of a huge load of what are hand-holding/education support requests rather than bug reports; or
• Let users only file support tickets, for handling by support staff - not developers. This means the developers will not be endlessly swamped with redundant, non-development-related support work.

There is definitely a lot to be said for option 2. Sometimes it's inescapable. What's important, though, is for this not to be a dichotomy: Having a mechanism for "promoting" lay users to those who can file actual bug reports and communicate directly with developers.

So, my suggestion is: Ask your manager to reach out to the software company, to ask them for a channel to the developers, on the promise that it will not be just sent out to everyone, but only for technically capable users who believe they have found proper bugs.

_{@ColleenV suggests, in the comments, that the situation you find yourself in is evidence that the software maker/supporter company is deficient, and is forcing your organization to pay for your time doing essentially QA work for them. So, perhaps it might be possible to replace them altogether. But I'm guessing that would mean a bunch of organizational politics and investment in retraining or what not.}

Answer 9

TLDR: It's not unusual, but you should not accept this.

For a better result in bug solving from their part, you can :

• Inform management
• Quantify the time lost with every bug
• Ask coworkers to report the same bugs.

---

In addition to all of these great answers, which already explain that this should not be acceptable, here are additional context & possible tips, assuming you can't (or won't) switch for another software provider.

Explain how much time you're losing with every bug, both in the bug report and to your management. It's not uncommon for a bug to be labelled as "not important". When you quantify it, it becomes more concrete.

Ask to be updated when your bug is being handled by a developper.

In big companies, bugs are treated by different teams, ranked by level. If a team can't handle the bug, it goes to the upper level. Team 1 is usually "call center": they filter all trivial bugs ("Check your internet connection", etc...). Team 2 knows the product specifications in depth. They can tell you if "it's not a bug, it's a feature", or that this workflow is not supported yet. Team 3 is the tech team, which can actually make changes to the code.

To be treated, the bug has to go all the way to Team 3. Problem is, Team 3 is rarely available, because there is always something else to do: other bugs, new features, a different product, ... A bug often lands in an endless backlog, and, if you're the only one to report it, will never be treated. It's also possible that teams 1 & 2, knowing the endless to-do list their tech team already have, try to never send the bug to them. Hence the endless requests.

Ask coworkers to file the same bugs.

They even can reference your bug ticket number, if they want to avoid all the scrutiny. The more people report a bug, the greater the chance for it to be resolved, or at least, prioritized.

Answer 10

Pretty much usual behavior for the first level tech support when there is (virtually) no next level one.

The product is abandoned.

No one intends to fix the bug.

There are no resources allocated to fixing any bug.

Their only strategy is to return the ball to the user as quickly as possible, in order not to fail their SLA.

They will play the same game with you until you give up. They are paid to do exactly this.

That's how the software is made (and supported!) by a corrupt public procurement process.

I am not sure how the cycle can be broken.

Depending on your workplace politics, the best strategy may be involving the management, your colleagues, your union or simply giving up.

Answer 11

The simple answer is, unfortunately this sort of total incompetence from software/testing teams ... is not unusual.

Unfortunately, you can only take it as it is.

An extreme response would be "Leave the company since they are the epitome of incompetence in support."

At the other extreme, shrug and ignore it.