How do you prove it's a bug?

Bugs happen, period.
For a bug to be acknowledged and consequently be fixed the most important thing for support is to be able to replicate it in order to scrutinize it.
This can take time and, if they fail to replicate 'your' bug immediately, can be a bit frustrating for the user.
But hang in there, don't forget it's in Kemper's best interest to finally find the bug and iron it out.

I got you. So in the end there's hope they learned something from your case (e.g. not to dismiss a bug report as user error too soon).

My dealings with Kemper support have always been great. Hans replies back within minutes to solve any questions. As a former IT guy myself I try to provide as much info and proof of an issue. I tried everything support asked and even recorded sound samples for them to hear. It was determined very quickly that my Kemper needed to be sent out to repair. Surprised to hear you had issues with support but we are only hearing one side of it.

Quote from FlyingSnowman

My goal is not really to criticize support (although I admit I have been VERY frustrated - anyone would have been). My goal is to understand how you guys "prove" that it's a bug. I've sent video files showing the symptoms. I've sent my backups. What else should I have done?

you did nothing wrong. we have made a mistake.

Sounds like you did everything you could have. Not sure if you did this but there are a lot of intelligent people on this forum. In addition to contacting support, post a thread about the bug with all your info and videos. Maybe other users have experienced the bug and/or could recreate it. This might have moved it along faster.

IMHO the Kemper team should send you some Kemper goodies (picks/shirt/beer)

Quote from FlyingSnowman

I've had a quite frustrating experience with Kemper support about a bug in version 4.0.6. It took me literally months to try and prove that the behavior was indeed a bug (not caused by a beta version!), exchanging emails and wasting my valuable time... They kept on insisting that it was caused by a beta version, that my data was corrupted, that I had to restore an old version (and hence loose all my performances!) etc etc.

Finally, I found the cause of the bug myself (under what circumstances the bug appears) on a standard factory installation of 4.0.6 and only then they accepted my statement.I would like to know if any of you experienced the same? How do you deal with it? How do you prove "you're right" ?

As frustrating as this is I have had this happen a few times, I just give up. I will send my initial experience but after that I can't waste my time. Sorry.

Seems to be a lot of us grizzled veterans of the IT industry have invested in the Kemper. Thats a good thing, I think.

It's down to evidence. Is it either repeatable, or can be it demonstrated. Failing those do you have output from the software itself (crash reports).

If you look at it from the devs perspective then it'll make sense. To fix any bug the developer must be able to figure out what's causing that bug, the exact lines of code or situation in which a piece of code fails. So they need a map of sorts to that buried treasure.

The devs or QA can spend any amount of time hunting around trying to recreate a bug but if they can't find it they're not going to keep hunting forever, they have lots of other things to be doing too. So they triage any bugs coming in, evaluating and prioritizing them. Anything that lacks sufficient detail to allow the devs (or QA) to recreate/locate it, or that smells like user error is going to be sent right back to the guy reporting the bug with an explanation which doesn't mean that's the end of it, but might include that the user needs to clarify, or if they can reproduce it they should send in how to reproduce the bug.

I think that Kemper must get many many bug reports and it is tough for them to sort.

I can say for certain that I have provided repeatable evidence and this was disregarded at least twice.

Quote from Per

It's down to evidence. Is it either repeatable, or can be it demonstrated. Failing those do you have output from the software itself (crash reports).

If you look at it from the devs perspective then it'll make sense. To fix any bug the developer must be able to figure out what's causing that bug, the exact lines of code or situation in which a piece of code fails. So they need a map of sorts to that buried treasure.

The devs or QA can spend any amount of time hunting around trying to recreate a bug but if they can't find it they're not going to keep hunting forever, they have lots of other things to be doing too. So they triage any bugs coming in, evaluating and prioritizing them. Anything that lacks sufficient detail to allow the devs (or QA) to recreate/locate it, or that smells like user error is going to be sent right back to the guy reporting the bug with an explanation which doesn't mean that's the end of it, but might include that the user needs to clarify, or if they can reproduce it they should send in how to reproduce the bug.

@Per I do not think that is the case with this post. Gstring even said they made a mistake, not the user reporting it.

Quote from schreckmusic

@Per I do not think that is the case with this post. Gstring even said they made a mistake, not the user reporting it.

There's plenty of room for error in this stuff, I wouldn't go too harshly on Kemper. The OP said they had to find the cause first before it was accepted, I was just explaining why that might be, what goes on in typical bug-tracking, why you might find a perfectly legitimate bug may not always be accepted by a developer.

Quote from FlyingSnowman

Like I said already in my previous post, normally bugs are avoided as much as possible by doing structured (and mostly but not necessarily automatic) regression testing. There will always be bugs, but there are professional and standard processes to deal with this. A feature that worked before, should still work after implementing a new one. Otherwise it's a regression. Normally, you build test cases and then you test. And again, what bothered me the most, was the attitude, like explained before. I don't want to repeat it, I don't want to blame them more than I already did I'm just saying that the process could be a bit industrialized, like it is usually done in IT. Doesn't have to cost a lot of time, it's a matter of organisation.

I'm sure that Kemper do regression testing. But it only goes so far. Unless your product is exceptionally simple it's almost impossible to test every feature in every situation.

Unit tests and automated testing are just as prone to that, after all they only cover what you think might break, and human testing is only human. Bugs occur, features break, human error exists! To put it another way, if this wasn't the case then Kemper wouldn't be releasing public betas.

Yep, devs team not being able to reproduce an issue is perhaps the most frustrating experience. Basically because it means your issue (provided it's really a flaw in the unit) is not going to be solved until something new happens.

We know, as of today, that the KPA can react differently under different circumstances, and that even loading the same backup can't ensure the same behaviour.
Hardware tolerances I guess, unless the backup is not everything...