It's important for a tester to know the terminologies and methodologies of testing if he wants to understand the theory of testing technology. He will become a successful tester once he applies these theories to deliver quality products within the time and cost constraints.
That does not mean, however, that theoretical knowledge alone will give a tester an edge. Two other important factors are vital for a tester to be successful: Expertise in the business domain and the architecture on which the software is built.
Expertise in the business domain
Understanding the exact business requirement of the end user is the biggest challenge a tester may face. This will enable him to certify the software before exposing it for client approval. It is vital that the tester understand the business domain on which the application is being developed if he is to understand the specification. Knowing the domain will help the tester break communication barriers, appreciate the business need and relate to the impact of the system in the overall scenario -- even when it is not explicitly stated.
For example, a tester validating a software application in the financial portfolio management business domain must know financial terms such as separate account management, accrued income and mutual fund. Knowledge about the business rules in the domain will help him identify the correlation between different functional modules, which in turn will be beneficial in drafting the test strategy and subsequently the test plan/test case.
The tester need not be the final word as far as the business rules are concerned. But in order for the tester to make an informed decision on how the application should behave under different business situations, he should possess sufficient domain knowledge. This should include knowledge of business processes in a specific context or awareness of generic business. Testers are supposed to represent the end user in terms of what to expect from the product. It is the duty of the tester to grab as much knowledge on the domain as possible. This is certainly a long process, but this will give him an advantage among his peers.
Testing, for most testers, is black box testing without knowing the code base on which the application is built. At least some of them might be exclaiming, "What do I have to do with the architecture of the application!" or "Why should I come to testing if I need to understand all the class and methods; I could have become a developer instead!" For them testing is all about breaking the system by keying in some data in the data entry forms.
However, business applications are becoming more complex, and we cannot rest assured that effective testing can happen just by keying in some data through the user interface. Understanding of the underlying components of the application will help testers plan their testing more effectively so that they can identify hidden errors in the application.
The use of independent third-party tools and loosely connected off-the-shelf products is inevitable in order to implement intricate business requirements. Technology has advanced a lot and multi-tier architecture has become common in the software development arena. If a tester understand the architecture of a system, he will be able to better identify the parts of the application that are bound to break based on the complexity that is built in that part of the code.
Understanding of the architecture and underlying components will help a tester with enhanced defect reporting. He will be able to better explain the issue reported rather than stating simply that he received such-and-such error.
This will also help the tester improve his exploratory testing skills. When he comes across an issue, he will be able to dig in to the details of it, keeping in mind the architectural complexity of the part of the software and isolate the problem.
By understanding the underlying components, the tester will also improve his testing precision. He will be able to segregate the problem innate in an application without going for exhaustive testing.
About the author: Baiju M. is a testing and QA manager at Envestnet Asset Management in India. He has more than 10 years' experience in system analysis, development and testing.