Comments on: Change should be the ally of quality

By: Robert Kist

Robert Kist — Mon, 02 Feb 2015 07:44:00 +0000

I think the idea that some sort of quality is a foundation for all other quality is not correct, nor is the view that there is something like “product quality” vs “software quality”. If your product is a piece of software, then it’s one and the same. The lack of having a holistic view on quality is exactly what causes the “not my problem” attitude we see so often in development.

And it’s definitely not a management problem. Gathering requirements, forming use cases, and defining test cases based on that clearly falls into the software engineering domain. Hence it’s the responsibility of the dev team.

Although you may be correct that acceptance testing could not have caught MS’ start menu problem. If you get your requirements wrong and test against wrong requirements, then your tests will still show up as “passed”. And that the requirements were wrong clearly showed when the majority of customers complained about the new feature.

By: Rob Galanakis

Rob Galanakis — Sun, 01 Feb 2015 21:23:48 +0000

In reply to robert. Right Jon, nor would any sort of "Acceptance Testing" stop the new start menu. It was *exactly* what MS wanted, I promise you, and it was a total failure of product design. That wasn't a failure of programming or QA. Also, think hard about the implications of *not* changing anything about Windows. MSFT would watch its share dwindle more and more. In the end, these changes will have benefits, and didn't need to have the problems they did, but this is neither here nor there. That is a management failure (one caused largely by Sinofsky himself, by the way!), having nothing to do with construction quality, which is the foundation of product quality.

By: Jon Lauridsen

Jon Lauridsen — Sat, 31 Jan 2015 14:17:09 +0000

But “testers” (whatever exactly that means, I’m not comfortable with its implications of a person just testing) wouldn’t prevent the new start menu. I would not be surprised to hear MS ran user feedback courses to gauge how people reacted, and found it acceptable in achieving whatever goals they were pursuing. Just like they did with the (frequently ridiculed for some reason) Office ribbon. That’s not software quality for testers, it’s.. product quality and alignment to long term goals.

Anyway,
With proper design and automated tests, code really can be changed without introducing a myriad of potential bugs and regressions and the resulting feeling of low confidence. That’s not to say it’s easy to achieve that (certainly I don’t find it easy and frequently fall off the path), but Rob is right, the potential is always there.

By: robert

robert — Thu, 29 Jan 2015 01:21:41 +0000

It’s not just about bugs – change has more side effects than that. Since you mentioned UX, just think what happened with Windows 8’s new start menu. It’s not a bug as such, but it caused serious troubles in a larger system – that of how users interact with their OS. In the view of many users this change reduced the quality of the software. This is where automated tests fall short, and where you have to do acceptance testing.
Especially when it comes to UX, change – and experimentation can affect quality, even if it’s just perceived quality, that has nothing to do with the way a programmer defines bugs related to code.

Still, change is good, and it’s gonna break things. But that’s how things evolve, and that’s how we learn – from breaking stuff ;)