2 things:
1) Understand Chess or more specifically Shogi. ( http://en.wikipedia.org/wiki/Shogi )
2) Watch Sherlock ( http://www.bbc.co.uk/programmes/b018ttws )
So why do I say that?
1) Chess is a strategy game that gets you thinking about the possibilities of steps ahead and the best possible outcome. In QA, you’re trying to search for the worst possible outcome. Shogi is Japanese chess… it has a twist. The pieces that you capture you can place with certain restrictions. Same for the other side of course. This means that you have to account for the interjection of a piece. Same in QA. While Dev is developing, you have think ahead not only in terms of your plan, but also where your attack is going to be focused on. To note: I am not good at the game, my dad had taught me the game, because he thought I was weak in strategy and planning ahead. I am very grateful that he did.
2) Sherlock. Brilliant show. If you watch the first episode, it goes into details of what he pays attention to and deduces. In QA, it’s about paying attention to details on how the app works, and deducing where the bugs may lie to get to them. Now if you can apply that to software, this is what I do. I pay attention to the details of what I am doing as well as what the software is doing. If you know what you’re doing, while you are finding the bugs, you can easily reproduce the issue. If you are randomly testing and then just come across something, chances are you are going to have a harder time figuring out steps to reproduce.
This is not to say that it is limited to these two things. For example, there are much more things in QA in terms of UI and understanding visual appeal of a good interface as well as the usability of an interface. Performance is another factor to take a look at as well. It’s unfortunate, but when there’s other bugs that take priority; performance, ui and usability usually takes the back seat.
Balance… it’s such a hard thing in life.
Filed under: Uncategorized 
