Quality Assurance is an interesting career. When you get right down to it, the most bombastic description of what we do in QA is also probably the simplest and most apt: we break stuff. My personal running joke is that our motto should be, “QA: You make it, we break it.” Obviously, there is much more to it than that. There is a lot of careful testing, planning, strategizing, and theorizing. Building tests can be almost as complex as the subject you are testing. But when the planning is all done, and the testing begins, that’s when QA becomes the most fun you can have.
Testing can be pretty thrilling: imagine skipping through the aisles of a store, humming a tune, with a camera in one hand and an awfully large mallet in the other. Once you find what looks to be the most fragile object in the aisle, you take a picture, and hit it as hard as you can with the mallet. If it breaks, take another picture, and let somebody else fix it while you skip on to the next aisle looking for the next thing to break. And although you don’t necessarily need to know exactly why it broke at the time, good QA will not only root out bugs, but also carefully examine, monitor and inform the development process.
There are many ways to test, but the notion that QA Engineers do not necessarily need to worry about exactly how a program works at first, only that it does in fact work, is “black box testing.” Sometimes, it helps when designing a test plan, not to know exactly how the thing you are testing works inside the black box. This may seem counterintuitive on the face of it, but once you consider a testers objectivity, it starts to become clear. When you do not know what the program expects, and only what a user facing a program or website expects it to do, you cannot just feed it the input you know it wants. Instead you are forced to come up with all the possible combinations of input that could be entered, identify the most likely combinations to be entered (correct or not) and try them all. Your input is less biased towards what the program is more likely to happily accept, and the idea is that you simulate what is more likely to actually happen in the wild.
A developer however, knows what sort of input the program expects, knows the “right way” to use the program and will therefore, use it “correctly” to see that it does what it was programmed to do. This is partially because they simply may not have the time to do exhaustive combinatory testing, and partly because once you know the correct way to do something, you are compelled to do it that way. QA exists, in part, to help mitigate that. So it behooves a QA person to face down a new project for the first time with no knowledge at all of what is under the hood. Sometimes!
One of the many reasons why I enjoy being a part of the Pixafy team is that we’re consistently practicing and evolving best practices in every area that we work in. This can mean analyzing even the “tried and true” processes to determine if there are even better ways to accomplish our goals. For instance, during a routine load testing and performance check using automated tools (lots of really big hammers, operating really fast!), I put together and submitted my findings as I normally would, but instead switching to a new task after that, I was asked to “improve it.” Bug fixing and verification necessitates some “under-the-hood” peeking. It’s a rewarding process to be able to strategically test, validate, and help ensure that each and every project achieves Pixafy’s high standards, especially when I get to see what is in the box!
Update: Check out part 2, where I delve into the nitty gritty of the QA process.
Questions or comments? Share them below, or tweet us @Pixafy!