One of the jobs of Quality Assurance is to find ways to make the software break. Then Project Management decides if it’s a likely or typical enough scenario to concern oneself with. If something ceases to work entirely because someone puts a letter where a number should be and there’s no chance for the user to re-input the correct value, that’s a serious problem. If something doesn’t work because because someone hits the pounds the button five thousand times, not so much a problem. Either way, it’s our job to find ways to make it not work.
At some places QA goes beyond that wherein you need to figure out not only when something doesn’t work, but why it doesn’t. Whether it’s QA’s or Development’s responsibility to figure out the Why’s rather than just the When’s when it comes to things not working varies from company to company. Most of the time that should fall on development since they have access to the code and we don’t, but a developer’s time is considerably more valuable than a QA tech’s time so we’re often expected to gather as much as we can before it gets back on their virtual desk.
An infrequent challenge, though, is when you have something that works but is not supposed to. I’ve spent two days trying to figure out why something is not breaking. It’s sort of like trying to prove a negative. But if it goes unaddressed it may start ceasing to work just as it had ceased to work up until a couple of days ago. If I can figure out why it’s working, then I can figure out why it wasn’t working, and presumably the problem can be fixed, worked around, or dismissed.
All of that is dependent, however, on my ability to figure out why the uncooperative system keeps doing what it is supposed to be doing.
Technician Sensor theory in full effect, huh?
Comment by Webmaster — November 29, 2007 @ 2:14 pm