It usually happens that when someone answers the question “Who makes up a software development team?”, the common reply is: developers, designers and a leader. Those who are familiar with the industry may add an analyst and maybe a product owner.
The list may continue though among the answers one of the most important roles would probably be missing, one that, in my opinion, constitutes a key element for the product to be successful and for it to achieve users’ and product owner’s satisfaction.
Tester, QA, Tester QA, QA Engineer, according to the kind of test they perform: Manual Tester, Automation Tester, Performance Tester, among others. All their denominations relate to the activity they perform: testing.
Currently, we can find different testing resources on the internet since its community has become bigger in the last few years. However, it may be easy to get lost in vast amounts of information and to generate not so accurate interpretations about this role. In this post, I intend to help you understand what Testing is, where its standards come from and its benefits for the industry.
Firstly, Testing has always been present since the origins of computing, initiating with depuration: finding a bug/error within the code is testing. Then it is complemented with software demo, so that a piece of software can be said to comply with the requirements. Then, destructive testing has been introduced, which may sound rude or aggressive to developers, though its purpose is finding errors within the application. After some years, Product and quality Assessment has been added.
Finally, as the latest item on the list of software tests we find testing for prevention, that is running tests to prove a piece of software complies with the requirements, and to detect and prevent flaws.
Having described the history of testing, some of you may still wonder why testing is necessary in software development. When tests on the systems and documentation are run, they contribute to reducing the risk of failure during the functioning of the products. After identifying flaws and solving them, the quality of components and the system are benefitted. Another important purpose for the tests is contributing to contractual or legal requirements together with specific industry standards.
For software testing there are 7 principles that have served for 50 years as guidelines for testers, particularly 3 of them, which are essential for those involved in software development:
- Tests show flaws, not their absence. Even when no flaws have been detected, testing is not a proof of certification. Tests reduce the probability of remaining undetected flaws in the system.
- Thorough tests are impossible. Testing everything (every combination of input and preconditions) is not feasible, except in trivial cases. However, risk analysis, test techniques and priorities must be implemented to focus test efforts.
- Early tests save time and money. Tests must be initiated the earliest possible in the Software Testing Life Cycle. Early tests help reduce or eliminate costly changes.
We now have an idea of what testing is, its objectives and benefits. What comes later is grouping everything that can be subject to testing in certain instances of the Software Development Life Cycle. We can refer to 4 levels:
- Component tests
- Integration tests
- System tests
- Acceptance tests
Running tests at each of those levels has its benefits. Availability to run them will depend on the project characteristics, software maturity and other Project management factors that make each project singular.
Having presented all this information, what testing is, its structures and principles, we can claim that testing is fundamental for a product to be successsful. Not only by proving that its functionalities and components work correctly, but also that its usability and user experience adjust to the final users’ needs, since they are, after all, who have a direct impact on the product popularity and value. Moreover, Testing also contributes to quality and improvement of processes, documents and definition of requirements.