As you might have guessed from my name, I hail from Italy, although I am partly of Argentinean descent. I was born in 1990 and have since lived in a small town at a stone's throw from the Adriatic Sea. I have never had to travel long distances to enjoy summer at the beach, a luxury some people would probably kill to have.
I've developed a keen interest in computers since my wee years of childhood. I was three or four years when my brother was gifted an Amiga and I sure got addicted, to the point that, according to my family, that's primarily how I taught myself to read.
A child's perspective of the world is something that we'd like to savior again from time to time, as it's an amplifier of feelings and sensations we can't even reproduce anymore. That was the case with computer games for me: they were magic.
In high school, I attended a school that had none of these subjects and almost no mathematics, and programming was unheard of. Today, I'm a computer engineer reclaiming my original fascination as a child. Later in life, I've developed other interests: playing the piano, composing, a passion for history and languages.
In short, I excel in flexibility and adaptation. Whether it is innate or thanks to my early interest in computers, I am always eager to learn something new rather than to specialize - breadth before depth is my motto. Knowing a little of everything may not be good for very specific tasks, but it sure yields a synergy bonus, because you can relate concepts from very different subjects. In fact, I apply that skill every day as QA leader, soft- and hard-coder, reflecting my nature.
As QA leader, I coordinate testers in what, when and how to test. Testing is a fundamental part of any software engineering process. I make sure that only once a task undergoes QA supervision and is greenlighted that it be stamped as DONE. Such early prevention may to some be tedious, boring and it may appear unnecessary, but it's like many other preventative measures; it might be a minor annoyance, but you don't realize what life-saver it is until you don't have it anymore.
What does it take to be a prolific QA tester? Essentially, it is attention to detail - the devil is in the details and bugs aren't any different. The will to destroy your own game, or others' games, if you prefer. Not destroy as in shatter your software in small bits and pieces (hah... bits... get it... okay), but as in exploiting every function the game offers. If you've ever had that “gotcha” feeling when discovering an exploit that the developer hadn't foreseen, then get a magnifying glass and hop onto QA! Your future will be bright!
With a passion for pushing every game to its limits, all you need then is the ability to communicate the flaws. Detecting bugs is only half the work but you still need to report them for others to squish them. Therefore, the ability to write descriptive and detailed reports is also essential.
With that said, how do we roll in practice? In our development process, each meaningful activity is a task. Each task goes through five sequential phases: first is "To Do", where the task's attributes are outlined and the task assigned to someone. Then comes "In progress": the assignee has begun working on it. Once they thinks the task is completed, it's submitted to "To verify". There, someone from QA brings the task to "Verifying in progress". We test the task and then two things can happen. Either the tester is not satisfied with this iteration of the task and sends it back to "To Do", much to the joy of the assignee, or he deems it fit to go into the "Done" box and that task is then labeled Done.
This means that QA holds a great responsibility. It's up to us to control progress. Everyone else in the team works under the assumption that a task that is labeled Done by QA is indeed done and working as intended.
With a programmer background, I also see the gap between the muffled worlds of university and reality. Code is never experimental, functions are always class room utopian, code classes have ideal names and attributes. In the real world, where your average project is 20 times the size of whatever you saw in your programming classes, is can be quite a humbling experience. It's easy to get bewildered out there, so just remember that small steps are the way to go.
Hope you got an idea of who I am and what I do. Have a nice day!
This summarizes this week’s Design Table. Next week, our topic will be about Virtual Interface. If you would like to send in a question or write us feedback on today’s session, you can either do it via Twitter, Facebook or email and will try to make them part of the next series!
