Wikipedia
was down for half an hour today.
I know because I was trying to do some research for work, on deadline, and suddenly got an error page telling me that wikipedia was down.
No, it wasn't a software testing issue; the software worked fine.
Sources within the wikipedia foundation tell me that a fibre optic cable was broken.
This worries me.
You see, what exactly it is that we 'Quality Assurance People' do is negotiable. I see testers as the "
Headlights of the Project" as perhaps described best in Lesson #1 of
Lessons Learned in Software Testing.
But this thing happens.
Someone says "oh, no, the testers don't need to be in the room for this meeting" -- or perhaps they just don't say it at all. The emails fly by with the inconsistencies and half-formed ideas.
Meanwhile we, the testers, sit in our cocoon of an office, surrounded by whatever artifacts we hold dear. Perhaps it is requirements. Perhaps emails; perhaps, if we are really cool, we have this
executable specification, this tool, that produces a greenbar or red bar.
We are told to make sure that document X matches software transformation Y, and, by gosh, we are going to make good and sure that it does!
Meanwhile, the bugs outside of that specific, detailed case fly by.
The software works great, but the cloud services provider loses his internet connection.
The software we are testing works great, but the download link to get it does not.
The software we are testing works great ... once you hav registered it. But
CyberCash went out of business, the warming email that we needed to upgrade to PayPal went to someone who left the company, and, all of a sudden, our checkout system broke.
These are all real problems, problems that software testers can be aware of -- it we define our own role, and don't allow it to be whittled away.
Quality Assurance or Risk Management?
I started this series by examining what we call '
Risk Management'; I wrote:
That offers us a much more expansive definition of testing; it allows us to include ideas like Security Testing, Performance and Reliability within our purview, along with regulatory compliance, schedule risk, usability, and product risk - that “the right thing”, according to the specifications, will fail in the marketplace. We might even have concerns about, say, the marketing plan or sales process.
I stand behind those words.
There are some industries that 'get' risk. The insurance industry, and, to an extend, legalized gambling, are both betting that if you take a risk on an individual with good odds, enough times in a row, you will eventually win the aggregate. Those both take a view of risk that is bell-curved in shape.
Another view of risk is one where incredibly crazy, abnormal, unexpected things happen, and how often or where they happen is unpredictable, so it is best to be prepared.
I suspect if you talk to a firefighter, a police officer, or a ER doctor, all close to retirement, about some of the things they have seen, their perspective on risk will be much more random, hard to predict, and bell-curve-defying.
I want to be careful when I talk about risk -- it is just too easy to portray it as a monster that can be defeated witha a pretty bell-curve. After all, AIG, the biggest carrier in the 2008 housing crisis, had a bunch of holdings, that could only be defeated if a huge percentage of the folded and the housing market sunk.
Then both of those things happened.
When we talk about risk, we are really talking about the unknown, or the future. The thing about the future is that
we don't know. As software testers, we do the best we can with the time we have. As I said in a meeting years ago "Yes, we have risks. That is okay. Every project has risk. What we can do is to
actively manage them, to catch and correct for problems early."
Perhaps that's my favorite reason for supporting the term risk management over quality assurance. Just because we have a chance to actually do it. If we ever have a chance that the (new hire) VP of Finance is going to walk in and tell us he doesn't lik the color, then it will be awfully hard to
assurequality. Risk? Well, I can't eliminate it, but I might be able to help you understand the risk you ar taking and take steps to help reduce it.
Speaking of which, can we talk about the data center a bit?
I know, it's not a software quality issue, that's not really what I do ...
can we talk about my role?
:-)