Android Version 1.1.2 Bug: Profile Fields Still Do Not Work Propertly (vBulletin 3.8)

[Paul M]

the reason i am resistant to reporting bugs is that i feel the problems are not those for customers to solve in the first place. vbulletin QA / Programmers should be finding all of the bugs in my opinion.

You really are clueless. The developers of ANY software will never find all the bugs themselves.

[Trevor Hannant]

[m0rgulvale]

hi paul, not true. i have 5+ years in software eng. and our teams found most of the critical bugs before releases.

take a step back. compare vbulletin mobile suite bugs to bugs of other software you paid for.

which had more bugs?

listen to what the customers are saying.

also just look at the feedback in general for this product... read over the forum boards.. i'm noticing quite a few posts about users frustrated with bugs. not just me

vbulletin QA team needs to be finding these things, not customers

pay us for our time findings bugs if you expect to dump a buggy product on us for us to be testers on

instead of just admitting there are problems here vbulletin just gets defensive it seems


let's do some fault analysis, Trevor..
you called me a broken record.

did you stop for a second to think why i keep repeating the same things? because vbulletin is taking no accountability here about the bugs in my opinion. it just keeps happening that you expect users to do the work that the QA team should be doing

so who is really at fault? me for being upset about a recurring problem that impacts my business? or vbulletin QA/devs?


how i would handle this situation if i was a manager at vbulletin responding to my post:

1) admit there have been some bugs. half of the challenge seems to be admitting there have been some bad bugs.
2) take an action plan to monitor performance. produce a weekly report which highlights:

a) number of code defects per developer
b) number of code defects detected by customers
c) number of code defects detected/prevented by QA/devs

3) produce the weekly metric report to everyone so the performance can be monitored closely
4) give bonuses to vb employees that have the least code defects and most bugs found (performance incentive)
5) give customers account credit of $20 for each valid bug discovered (incentive for customers to take their time (basically money) to be doing the job of what vbulletin employees should be doing )

[worried]

I'm sort of surprised by the attitude of staff here at vBulletin. I'm not taking it to heart so I'm cool with that although that kind of behavior isn't tolerated in my field because it's associated with revenue loss. My field takes feedback from customers (i.e. Press Ganey) to see how they can increase customer satisfaction/revenue.

[Zachery]

I'm sort of surprised by the attitude of staff here at vBulletin. I'm not taking it to heart so I'm cool with that although that kind of behavior isn't tolerated in my field because it's associated with revenue loss. My field takes feedback from customers (i.e. Press Ganey) to see how they can increase customer satisfaction/revenue.

We absolutely take the feedback, we make sure its passed on and up to the right people. The customer however, is not always right. I believe the French have a saying "The Customer is King".

Edit: to go on a bit further.

Some customers say they despise reporting bugs, so much so that they post about it often that they hate reporting bugs. But they also complain that they don't like the bugs they run into and wonder why their bugs are not being fixed. This continues, every day( or two), the same customers post that nothing is being done to fix their bugs.

I don't believe these users represent the whole. But they are a vocal group, so they're noticed more.

Some customers also say that we should catch 100% of the bugs, and fix them before releasing the software. It is not possible to catch 100% of the bugs, nor is it possible for us to not have customers report bugs.

For an example, when we (support staff) go out of our way to report the bug. We have a hard time getting the customers involved in the bug fixing/confirming process. They did not start the bug, they do not always watch the bug, they do not always vote for the bug, they don't always respond to the bug. Then, what happens when the developer who gets assigned to the bug, or the bug scrubber needs more information? They can't reproduce it with the information provided or the environment on hand. So then we have to try to get the customer to go and follow up. Sometimes they do, but not always. A few weeks down the road customer is upset their bug isn't fixed and asks why. We try to explain we needed more information/feedback, customer is not happy that their bug is not progressing toward fixed/confirmed/etc.

It is in your own best interests to report the bugs you come across and/or comment on ones that have already been reported. You're getting your voice out, and heard. This is very very important.

Think of it something like voting. If you are not voting (regardless of who or what wins the vote) you're not helping the system. You're not making your voice heard in a way that provides feedback.

[Trevor Hannant]

let's do some fault analysis, Trevor..
you called me a broken record.

did you stop for a second to think why i keep repeating the same things? because vbulletin is taking no accountability here about the bugs in my opinion. it just keeps happening that you expect users to do the work that the QA team should be doing

so who is really at fault? me for being upset about a recurring problem that impacts my business? or vbulletin QA/devs?

I'm not here to apportion blame, that's not my job. My job is to support users who are having issues. As Zach states above, it's impossible to catch all bugs in QA - how do we account for every possible server setup, every customised setup, every customised installation of vBulletin, every whim and wish of the customer? We can't - it's impossible in the market we operate in.

We have admitted in the past when we've not picked something up in QA and those lessons are being learnt constantly - the QA process goes from strength to strength with each release.

Why do I say broken record - because you constantly post about the same things. How long has it taken you to come up with your posts, check them and then post them. For all the time you've spent doing that, you could have posted a bug report, responded to any feedback from the developer directly and seen it fixed.

4.1.4 was a pretty good release IMO, sure it wasn't 100% perfect but it's how that's addressed that is the key. 4.1.5 is addressing a substantial number of customer raised bugs, particularly in the Editor so related to 4.1.4's issues (248 fixes at this time and growing daily) because people who care about the quality of the product or are affected by issues within the product have taken the time to post in the Tracker instead of constantly repeat themselves in the forum (some have done both!). Their 2 minutes filling in a Bug report is seeing their issues addressed - their constant posting on here isn't.

If you want to see these things fixed, follow their lead and post it in the appropriate place otherwise you'll keep on waiting...

[Paul M]

hi paul, not true. i have 5+ years in software eng. and our teams found most of the critical bugs before releases.

So you have just disproved your own statement. By your own post, you should have found all of them.

[m0rgulvale]

@paul, the point is we found an acceptable amount. i don't think vbulletin is finding an acceptable amount. take a look around you and see the feedback on these forums about the bugs. for example, there used to be a bug that preventing users from registering on the app before. how was that not tested?

again, in my opinion the point is i think there is an abnormally high amount of bugs compared to other software i have paid for.

@paul, i'm not the only one upset. look around you on the forums

thanks