Yes, good BA should be able to put herself in user’s shoes but again, it is common there’s no BA at all, let alone a good one.

Involvement of users is a tricky part here. It depends on a type of project. If I build app addressed directly for end-users I’d like to see them involved as soon as possible. If I build system for some corporation I need to satisfy decision-makers in the first place – otherwise I won’t get a contract at all. In the latter case users involvement may (but don’t have to) end in goldplating we’d like to avoid.

On that note, let’s not forget the value of the Business Analyst. BA’s are there to help the users define what they really need. Not to simply document what the user thinks they want. With good Requirements Analysis, we can alleviate many of the other problems that pop up during the testing phase.

This doesn’t change my point of view though. I was a tester myself and my greatest successes at this role were all triggered when I went out of specs. The very same thing I see now. The most painful bugs are find not when our QA folks follow the book, but when they check if something else isn’t screwed by accident. Something which hasn’t been touched in any way for months already.

Yes, it doesn’t come for free but in terms of quality improvement these all were worthy investments. All of issues I think of would hit us very hard once they reached our customers. A couple of them did actually.

Another thing is (lack of) relation between users and specs. In general users aren’t involved in creation of specs and it’s pretty common that most important features from users’ perspective aren’t included or properly described. This may result in users hating your product, even if they’re forced to use it. If you’re out of luck and these are users who are decision-makers they’ll just go away.

After all I’d prefer to have good product late than crappy product on time (at least most of the time). I guess it depends how we define our targets.

Yes, the users will not be sticking to specs. However, the users often are aware of existing defects and are willing to work around them because they have placed a higher priority on the changes being implemented with the current project. Otherwise, the project would not exist. While the defects should be logged (and are probably already logged somewhere), a project resource should be appointed to review all new defects in order to determine which ones will be fixed within the project, and which ones can wait.

So, yes, you are correct. This article was written in defense of scope. Shouldn’t we all be aiming to hit our targets?