One of my professors had told me this: “There are book smart people who are highly intelligent about theory; there are practical smart people who are highly intelligent out in the industry. You should train yourself in both so that you understand the theory and can apply them in practice.”
Truth tables can be used for figuring out the branching behavior and making sure that each conditions in the if/then statements are accounted for. It does not necessarily mean that all conditions are accounted for.
In some sense QA is much like art. Design is highly important, such as composition (rule of thirds). Both positive and negative testing in QA just as positive and negative spaces in art is important.
QA is also in my opinion, about risk analysis, risk management and task management. There’s a rule of economics on the work load can be done and distributed, amongst the tests that can be run, etc. etc. If every bug was known in the system, that would be wonderful, however the bugs are the unknown and the QA person’s job is to find them. It’s unknown how many bugs are in the product, nor what bugs can come from the fixes to other bugs. The risk of a customer/end user finding a bug (escaped bug) narrows the more testing is done from the QA end. Even if a good chunk of the bugs are found, if the product has to be released at a given time, developers need time to fix the bugs and make sure that they do not create other bugs. So there may be bugs that end up getting deferred. There’s also tests to run in a given amount of time to try to cover as much as possible. I can’t say that it’s impossible for all bugs to get fixed, but I will say that the likelihood of all bugs to get fixed in a product in time of the release is like the chances of finding a needle in a haystack. The QA person has to figure out which bugs to fight for.
They are in some means a preventative barrier from Tech Support getting overburdened with calls, emails, forum posts, etc. They can help Tech Support by providing more information upfront so Tech Support is ready with answers to customers’ questions.
In terms of the thought process I go through when doing blackbox testing QA, it’s basically mapping out the possibilities of parts of the program in a finite automaton ( http://en.wikipedia.org/wiki/Finite-state_machine ) The more I understand about the product and the details, the more detailed I can go into what states are being pictured into my mind. I’ll have an example of what I am talking about in terms of using finite automatons to model QA states and conditions in another post. This usually helps me paint a picture on how methodical I can get in figuring out how to QA a product.
Other things that help are understanding data structures, modeling structures… specifications, design docs… to help see the flaws early. Pointing out the potential concerns early can help reduce the number of bugs in the system, and cut down on the costs of time lost from engineers having to rethink what they did. It’s better to have things fresh in everyone’s mind to help cut down on time lost.
QA is also about cognitive thinking and how intuitive things are. In some sense this could be subjective or based on culture. Art is also based on culture. Example is RTL languages vs Asian cultures vs Euro cultures vs American culture etc.
In another sense, QA is a scientist. poking and prodding at the product to see how it works. In another sense, a QA person is a reporter, reporting how what why when where to the dev team through a bug report, giving evidence. In another sense, a QA person is a detective, hunting down and narrowing down how something occurs. In another sense, the QA person is a hacker, trying to see if he can break into something not for malicious purposes, but to help strengthen the product.
There’s a lot of disciplines that a QA person has, and the more the person knows, the more context they are aware of, the better the tester they can be.
Someone once said “The more I know… the less I know…” or something to that effect, and that’s definitely true for me.