Exploring Different Software Testing Types and Their Potential Pitfalls

Software testing has become one of the most important components of the software development lifecycle. The understanding is that while developers can create the most iconic software or app, failing to test can easily render it subpar in performance, or dangerous at worst.

Without proper testing, software can have defects and errors that can lead to poor performance, crashes, security vulnerabilities, and other issues that can damage the reputation of the software, the software company that developed it, and even put users' safety and privacy at risk.

Even worse, studies have found that the majority of users will in fact never complain when they are unsatisfied. Only 1 in 26 will complain, the rest will just drop quietly. This statistic is particularly important to take note of because some developers and organizations make the mistake of assuming that users will always raise issues and so it’s all easy because you’ll use the opportunity to fix them. This mindset can kill even the most promising products. 

The market value of software testing was about USD 45 billion in 2022 and is projected to double by 2032, fueled by the emergence of powerful DevOps solutions and the rising adoption of Agile frameworks among other drivers. We’ll continue to witness sustained growth as more organizations come to terms with the significance of testing. 

In this guide, we focus on the major types of software testing. 

What is software testing ?

Software testing is the process of evaluating a software system or application to identify any defects, errors, or bugs that may affect its functionality, usability, and performance.

Why is software testing important?

Flaws in software are costly. The Consortium for Information and Software Quality established that in 2020 alone, US companies lost over $2 trillion due to poor software quality. This is just in the US alone. Now imagine the rest of the world. 

Testing is the only way you can use to ensure that the software functions as intended, is reliable and secure, and meets the user's expectations. Effective testing enables you to identify and isolate bugs and errors in the software code and fix them before the software is released to the market, which can save a lot of time and costs in the long run. 

Specific reasons why testing is important:

• Quality: A thorough test will identify and create the opportunity to eliminate defects, bugs, and vulnerabilities before they reach end-users. This, in turn, leads to a more reliable, efficient, and user-friendly software product that meets the desired functional and non-functional requirements, ultimately resulting in high quality..
• Saves time and cost: Finding and fixing defects early in the software development cycle is less costly than fixing them later in the production cycle.
• Reduces risk: Testing reduces the risk of software failure or malfunction, which can have serious consequences for businesses and users. 
• Compliance: Many industries have strict compliance requirements, and testing is necessary to ensure that the software meets these requirements.

How software testing works

Each test has unique processes from start to end, including the appropriate tools. However, this general approach cuts across most tests. 

1. Test planning: The first step is to define the testing objectives, scope, and approach. The test plan should include the type of testing to be performed, the testing tools and techniques to be used, the schedule, and the resources required.
2. Test design: In this step, software testers design test cases that will be used. Test cases include the expected results and the input data required to achieve those results.
3. Test execution: Testers execute the test cases and record the results. They may use manual testing or automated testing tools.
4. Reporting: The test results are analyzed and reported. All issues identified are documented and reported to the development team for resolution.
5. Closure: Once all the test cases have been executed, all issues fixed, and reported, the testing is declared complete. The testing team provides a summary to the stakeholders.

The main methods of software testing

There are two major methods used in software testing: manual testing and automated testing.

Manual testing

Testers execute test cases manually to detect defects and verify the functionality of the software. It’s all down to human judgment, no automation tools or scripts. As you can expect, this approach requires a significant amount of time and effort, and it can be prone to human error.

When is manual testing recommended?

• In the early stages of development when the product is not yet fully developed. Human testers can explore the software to find defects and issues that may not be caught by automated testing tools.
• When testing requires human intuition. There are certain types of testing that require human intuition, such as exploratory testing and usability testing. These are best done manually because they require the tester to think like an end-user and test the software from their perspective.
• When testing complex scenarios that require a deep understanding of the software, such as testing edge cases and negative scenarios. Human testers can use their experience and expertise to identify and test these scenarios.
• When testing software that has a graphical user interface (GUI). Some elements of GUI are best tested manually because they might require humans to verify that the product looks and functions correctly from a user’s perspective.

Automated testing

Testers use software tools to execute test cases automatically. Automated testing is faster and more efficient than manual testing, and it can be used to test complex software systems with large amounts of data.

When is automated testing recommended?

• When testing requires repetitive tasks. Automated tests can be run multiple times without any errors, providing accurate and consistent results.
• When testing large or complex systems that require multiple test cases to be executed quickly. Automated testing tools can perform tests in parallel and provide quick feedback on test results.
• When testing requires frequent updates such as with agile development methodologies. Automated tests can be easily updated and re-executed, ensuring that the software remains functional and bug-free.

Software testing can be functional or non-functional

Whether manual or automated, the nature of software testing can be functional or non-functional. What does this mean?

i). Functional software testing

Focuses on verifying the functional requirements. Functional requirements are the specific features and capabilities that a software or application must have in order to perform its intended functions. These requirements define how the system should behave under certain conditions or inputs and describe what the system should do to produce the expected output.

Functional requirements are often expressed in the form of use cases, which describe how users will interact with the system to accomplish specific tasks. For example, a functional requirement for an e-commerce website might be that customers can add items to their cart, view their cart, and then complete the checkout process.

ii). Non-functional testing

Focuses on verifying the non-functional requirements of the software or application. Non-functional requirements include aspects such as performance, security, scalability, usability, and compatibility.

Non-functional testing helps to validate the software's behavior under different conditions, including heavy load, different operating systems, browsers, and network configurations.

16 Types of software testing

While it’s not possible to cover all the types of software testing that can possibly be conducted, we have narrowed down to the 16 most significant tests that are necessary for a typical software product.

Let’s go!

1. Unit testing

As the name suggests, different units of a software, or modules, are tested in isolation to ensure they are functioning correctly as per the design and specifications. It involves testing the smallest testable parts of the code, such as functions, methods, and classes. Unit tests are typically automated and executed using a testing framework, with results recorded to ensure that the tests pass or fail. 

This test is valuable because, as businesses have come to discover, even a random glitch can bring operations to a halt. Take for example the IT glitch that paralyzed operations at Heathrow Airport in 2020.

To perform this test, you need to write test cases that cover all possible scenarios and edge cases for a specific unit of code, then run the tests to ensure that the code behaves as intended and produces the expected outputs for a given input.

Limitations of unit testing

• Incomplete coverage: Unit testing typically focuses on testing individual units of code in isolation. However, it is possible that the integration between different units may lead to unexpected behavior. Therefore, unit testing alone may not be sufficient to ensure the overall correctness of the system.
• Limited scope: Unit testing is designed to test small units of code, and it may not be possible to test all possible scenarios or edge cases. Therefore, some defects may remain undiscovered until the system is tested as a whole.
• Time and cost: This testing can be time-consuming and expensive, especially when the codebase is large. Writing unit tests for every single piece of code can be an extensive task that requires significant resources, which can slow down the development process.
• False Sense of security: Passing unit tests can provide a false sense of security that the code is working correctly. Unit tests only verify that the code works as expected in the specific scenario that was tested.

2. Integration testing

Sets of individual units, modules or components are combined and tested as a group to verify their functionality as a whole. The primary objective is to ensure that the different modules interact with each other correctly and that the software as a whole functions as intended. 

Integration testing is a critical step in the software development life cycle, particularly used to identify and resolve any defects or issues that may arise when different modules are integrated. 

The thinking behind integration testing is that while solo units might have been tested and found to be functioning well, that may not be the case when they are integrated with others. 

There are several approaches to integration testing, including:

• Big Bang integration: The entire software or application is tested as a single entity. This approach is quick, but it can be difficult to isolate and fix defects.
• Top-Down integration: The highest-level modules or components are tested first, and then the lower-level modules are integrated and tested in stages. This approach is useful when the higher-level modules are more critical to the functionality of the software.
• Bottom-Up integration: Involves testing the lower-level modules first and then gradually integrating higher-level modules. This approach is useful when the lower-level modules are more important.
• Hybrid integration: Combines elements of top-down and bottom-up integration testing, with higher-level modules being tested first, followed by lower-level. 

Limitations of integration testing

• Time-consuming particularly when testing complex software applications.
• A failure in one component can cause issues in other components.
• Can be limited in its ability to detect issues that occur outside the integration points being tested.

3. System testing

System testing evaluates the entire product as a whole. It is usually performed after the completion of the integration testing phase and before the acceptance testing phase.

This type is recommended for critical business processes such as order processing, payment processing, and inventory management. When done correctly, it helps ensure that the system is reliable and performs as expected under different scenarios.

Limitations of system testing

• Can be time-consuming and resource-intensive, particularly in large or complex software systems. This can make it difficult to complete testing within the available timeframe or budget.
• Limited fault isolation: System testing may identify issues or defects, but it may not be possible to isolate the root cause of the problem. This can make it difficult to address the underlying issue and may result in recurring problems.
• Dependence on external factors: System testing can be dependent on external factors, such as network connectivity or third-party services. If these factors are not available or functioning correctly during testing, it may be difficult to fully test the software.
• Difficulty in replicating customer environments: System testing may not be able to replicate the diversity of customer environments that the software may be deployed in. This can make it difficult to fully test the software's compatibility with different systems or configurations.
• High cost of testing: System testing can be expensive, particularly in large or complex software systems, where testing may require multiple resources and tools. This can increase the overall cost of development.

4. Black Box testing

The testers examine the behavior of the software without knowledge of its internal workings.

They are only concerned with the inputs and outputs of the system, and not how the system processes the inputs or generates the outputs.

Some of the commonly used techniques in black box testing include equivalence partitioning, boundary value analysis, decision table testing, and state transition testing.

The main advantages of black box testing include the fact that it can be conducted by testers who are not developers or have no programming skills.

Black Box testing limitations

• Dependency on specifications: Black box testing is dependent on the accuracy and completeness of the software's specifications or requirements. If the specifications are incomplete or inaccurate, it may be difficult to conduct thorough testing.
• Limited ability to pinpoint issues: While Black Box testing may reveal issues, it may not be possible to isolate the root cause of the problem, making it challenging to address the underlying issue.
• Testers are not allowed to control or manipulate the software's internal state or data, limiting their ability to test specific scenarios or edge cases.

5. White Box testing

Unlike Black Box testing where the tester has no knowledge of the inner workings, here the tester has knowledge of the internal workings of the system being tested.

What’s tested: the software's internal structure, design, code, and implementation. 

White Box Testing is often performed by developers and engineers during the development process, but it can also be performed by dedicated testers during the testing phase.

Drawbacks of White Box testing

• Limited focus on user requirements: White box testing focuses on the software's internal workings and may not ensure that the software meets the requirements and needs of the end-users.
• Potential for code coverage gaps: White box testing may not cover all parts of the software's code, leading to gaps in code that can result in undetected issues.

6. Alpha testing

Alpha testing is conducted by the software developer or the testing team, before releasing the software to the public or to a larger group of users for beta testing.

The software is tested in a controlled environment and is usually done on a small scale. The results are then used to improve the software before it is released for beta testing or to the public.

Limitations of Alpha testing

• Limited feedback from users: Since only a limited number of users are involved, they may not represent the diverse range of users who will ultimately use the software. This limitation may lead to biased feedback, as alpha testers may have different perspectives or priorities than the general public.
• Limited testing environment: Alpha testing is conducted in a controlled environment, which may not represent the real-world conditions under which the software will be used.

7. Beta testing

You may have come across the word “Beta” appearing at the end of some products’ names. E.g “EasyCRM Beta”. That means the software is more or less done but not officially open for public use. 

Beta testing is conducted by a group of external users, after alpha testing has been completed by the internal testing team. The purpose is to identify any issues or bugs in the software that were not discovered during alpha testing.

The software is normally released to a group of selected users, who are often chosen based on specific criteria such as demographics, expertise, or usage patterns. The users are then asked to use the software under normal conditions and provide feedback on their experience.

Limitations of Beta testing

• May pose legal and ethical risks, as beta testers may have access to sensitive data or information that could be used maliciously. This limitation may result in the need for additional security measures, such as secure testing environments or non-disclosure agreements.
• Public perception of the software may be affected, as beta testers may share their experiences or opinions about the software before it is released to the public. This limitation may result in negative publicity or a decrease in the public's interest in the software.

8. Smoke testing

When you want to have a quick check to verify whether the major functionalities are working correctly after a new build or release, smoke testing is the way to go. The objective is to check if the most important features of the software are working as expected before conducting more detailed testing.

Smoke testing is considered to be a high-level testing activity. The name comes from the idea that if the software passes the initial smoke test, it is less likely to catch fire (i.e., encounter critical issues) during the subsequent testing phases.

If the software passes the smoke test, it is considered to be stable enough to proceed to more detailed testing.

Drawbacks of smoke testing

• As this test only verifies basic functionality, developers can have a false sense of security.
• Smoke testing may not be adequately documented, which may make it difficult to reproduce the testing process or identify issues that were encountered during testing. This limitation may result in the need for additional testing or troubleshooting after the software is released to the public.

9. Ad-Hoc testing

The word ad-hoc means something that is created or done for a specific purpose or situation, without being part of a general plan or process. Therefore in the context of software testing, ad-hoc testing is performed without any predefined test cases or test plans. The tester improvises and performs testing in an exploratory manner, focusing on areas of the software that are deemed to be more likely to have problems.

Ad-hoc testing can be performed by both developers and testers, and it can be done manually or with the help of automated tools. The objective of ad-hoc testing is to identify defects, issues, and unexpected behavior that might have been missed during more structured testing.

Ad-hoc testing is cost-effective, as it does not require extensive planning or preparation.

Drawbacks of ad-hoc testing

• Biased results: Ad hoc testing may be influenced by the tester's bias or prior knowledge of the software, leading to inaccurate or incomplete results. This limitation may result in undetected issues in the released software.
• Lack of test repeatability: Ad hoc testing may not be repeatable, which may make it difficult to verify the accuracy of the testing results. This limitation may result in the need for additional testing or troubleshooting after the software is released to the public.

10. Regression testing

Regression testing is performed to verify that changes or updates made to the software have not introduced new challenges. It involves retesting the software, typically using automated test scripts, to ensure that previously working functionality still works as intended after changes have been made.

This is important because software is often updated or modified to add new features or fix defects, and these changes can inadvertently introduce new issues or break previously working functionality.

Drawbacks of regression testing

• Inability to detect new defects: Regression testing is designed to detect defects that have been introduced by changes made to the software. However, it may not detect new defects that have not been introduced by the changes being tested. This can be particularly problematic in complex systems, where new defects may arise due to unexpected interactions between system components.
• As the software evolves, the test cases used for regression testing must also be updated and maintained. This can be time-consuming and require significant effort to ensure that the test cases continue to provide adequate coverage of the system.

11. Performance testing

How well will the software perform in terms of speed, stability, scalability, and responsiveness under various workload conditions? This is the question that performance testing seeks to answer. The objective is to identify and eliminate any bottlenecks or performance issues in the software before it is released to end-users.

Performance testing involves simulating a real-world workload on the software and measuring its performance against predetermined performance criteria. This can include testing it under different load levels, such as peak usage, average usage, and low usage, and testing it with different types of data.

There are several types of performance testing, including:

• Load testing: The software is tested under expected load conditions to ensure that it can handle the anticipated number of users and transactions.
• Stress testing: The software is tested under higher than expected load conditions to determine its breaking point.
• Endurance testing: Testing is done under a sustained load over an extended period of time to ensure that it can maintain performance over a long duration.
• Spike testing: The software is tested under sudden, extreme increases in load to determine how it handles sudden spikes in usage.
• Scalability testing: How well can the software scale up or down to handle changes in workload?

Limitations of performance testing

• Difficulty in predicting user behavior: Performance testing involves simulating user behavior, which is often unpredictable. Users can behave differently based on their geographic location, network conditions, hardware, and software configurations.
• The validity of performance testing results may be limited based on the type of workload that is simulated. Workloads that are simulated in performance testing may not accurately reflect the actual workloads that the software will encounter in the real world. This can lead to inaccurate test results and a false sense of confidence that the software will perform well under actual conditions.

12. Security testing

With the growing cases of cyber threats and attacks at record pace, it’s not difficult to understand why security testing is crucial. Here, the tester is looking to identify and evaluate the presence of any potential vulnerabilities. 

With this test, you can evaluate the software’s defenses against threats such as unauthorized access, dark web threats, and other security threats.

The testing approach can involve various techniques and methodologies, such as vulnerability scanning, penetration testing, security audits, and risk assessments.

Also Read: Penetration Testing vs Vulnerability Testing — What’s the Difference?

Drawbacks of security testing

• May not fully take into account the unique contextual factors that can impact the security of the software. Factors such as user behavior, third-party integrations, and regulatory compliance can all impact the security but may not be fully captured in this testing.
• May not always identify vulnerabilities related to business logic, such as fraud or misuse of functionality. These vulnerabilities can be difficult to detect through traditional security testing methods and require a deeper understanding of the business processes and logic behind the software.

13. Usability testing

Many studies have shown that for every $2 invested in user experience, you can get $100 in ROI. 

To affirm this even more, Jeff Bezoz has previously said, “We see our customers as invited guests to a party, and we are the hosts. It’s our job every day to make every important aspect of the customer experience a little bit better.” If you make a point of looking at users of your software from this angle, then you can see why this test is critical.

In this test, users are observed as they interact with the software and feedback on their experience captured. Testers typically develop test scenarios and tasks that represent typical user interactions with the system, such as logging in, creating a new account, or completing a purchase.

Some of the methods you can use to conduct usability testing include:

• Expert review: Usability experts will review the software and provide feedback on potential issues.
• Testing with users: Real users interact with the system and provide feedback on their experience.
• A/B testing: Different versions of the product are tested with different user groups to determine which version is more user-friendly.

A key form of usability testing is GUI testing, where the appearance and behavior of various user interface components, such as buttons, menus, icons, input fields, and windows, are tested thoroughly to ensure that they function correctly and meet user expectations. GUI testing can also involve testing the system's response to user interactions, such as mouse clicks, keyboard input, and touch screen gestures. 

A report by Forrester Research found that great UX design has the potential to increase conversion rates by as much as 400%, demonstrating the importance of ensuring that your user experience is always beyond expectation.

Limitations of usability testing

• May not fully consider accessibility requirements for users with disabilities or special needs. This can lead to usability issues for these users being missed during testing.
• Usability testing can be time-consuming and resource-intensive, which can make it difficult to integrate into early stage development processes. This can result in usability issues being identified late in the development process, which can be costly and time-consuming to fix.
• May not fully consider cultural differences that can impact user behavior and preferences. This can lead to usability issues being missed for users from different cultures or regions.

14. Compatibility testing

The primary objective of compatibility testing is to ensure that the software can function as expected on different configurations and environments without major issues. Examples include different types of hardware, operating systems, major browsers, and network environments.

This testing is usually performed during the later stages of the software development life cycle to ensure that it’s ready for release.

Examples of compatibility testing include browser testing and backward testing. In browser testing, the software is checked to ensure it works well with major browsers. In backward compatibility testing, the application is checked to verify that it can work smoothly with previous versions of different environments, taking care of users who might be still using earlier versions of a particular system, for example an operating system.

Limitations of compatibility testing

• Testing all possible combinations is impractical: The number of possible combinations of hardware, software, and network configurations can be enormous, and it is not possible to test all of them. Thus, it is challenging to ensure that the software will work seamlessly in all possible environments.
• Complexities of networked systems: In modern systems, it is not uncommon for software to interact with other software, devices, or applications over a network. The complexity of these networked systems can make it challenging to identify all potential issues that could arise when the software interacts with other systems.
• Continuous evolution of technology: With the continuous evolution of technology, new software, hardware, and network configurations are being introduced regularly. Keeping up with these changes can be a daunting task, and it may be difficult to ensure that the software is compatible with all the latest configurations.

15. Database testing

As you know, databases are part of the backend engine that power everything that users enjoy on the front end. For every single action that a user performs, there is some form of data management happening on the back side of the application.

So, the purpose of this testing is to check and ensure that the databases are working properly and that they will successfully serve data once the software is deployed. 

What is checked? schema, triggers, tables, and more.

Depending on the end goal, developers have two main types of databases to work with: Graph Databases and relational databases. 

Common types of database tests include:

• Data integrity: Verifying the accuracy and consistency of the data stored in the database.
• Database performance: Testing the speed and responsiveness of the database under different loads and conditions.
• Database security: Tests the security features of the database, such as access controls, encryption, and data protection.
• Database migration: Tests the efficiency of the process of migrating data from one database to another.

Limitations of database testing

• Testing databases requires ongoing maintenance and upkeep to ensure that the tests are up-to-date and remain relevant to changes in the database and software.
• Automated database testing tools can be expensive, which can make it difficult for smaller organizations to adopt them.

16. Acceptance testing

Also known as User Acceptance Testing (UAT), this test is important to determine whether a software is ultimately acceptable to the clients and that it meets the business requirements.  

User acceptance testing usually marks the final testing phase of the cycle and is typically performed by end-users, stakeholders, clients,  or business representatives.

The goal is to ensure that the system is aligned with the business requirements and to verify that it meets the acceptance criteria defined by the stakeholders. 

The use cases are designed to simulate real-world scenarios and user behavior.

Limitations of acceptance testing

• Limited user representation: Acceptance testing typically involves a small sample size of users, which may not fully represent the diversity of actual users. This can lead to issues that only affect certain user groups being missed during testing.
• May not fully incorporate exploratory testing, which involves testing the software in an unstructured manner to uncover unexpected issues. This can lead to issues being missed that may not be apparent in a structured testing environment.

Common software testing tools

• Selenium: An open-source testing tool that is mainly used for functional and regression testing. It can automate web-based applications and is compatible with various programming languages like Java, Python, C#, and more.
• Apache JMeter: An open-source performance testing tool that is mainly used for load testing, and stress testing of web applications. It can simulate a large number of users to test the performance of the application under different conditions.
• Appium: Open-source mobile testing tool that is mainly used for functional testing of mobile applications. It can automate both Android and iOS applications and supports various programming languages.
• Postman: An API testing tool that is mainly used for testing of APIs that can test REST, SOAP, and other HTTP-based APIsI. Check out this article for REST vs SOAP APIs, and this on best practices for API security. 
• TestComplete: Mainly used for GUI testing of desktop, web, and mobile applications. It can automate tests in various programming languages like Python, JavaScript, and more.
• LoadRunner: A performance testing tool by OpenText that is mainly used for load testing and stress testing of web and mobile applications.

Common mistakes to avoid in software testing

It’s certainly not possible to rule out mistakes completely. But with more care, you can avoid most of the mistakes that are likely to crop up during software testing.

Watch out for these common mistakes:

1. Lack of documentation

Testing documentation is essential for keeping track of test cases, results, and any issues that arise during testing. Failure to maintain proper documentation can result in lost or incomplete testing data, making it difficult to reproduce issues and identify their root cause.

2. Insufficient test data

Testing data should be representative of real-world scenarios and use cases. Otherwise you’ll encounter missed bugs or issues that may only be discovered after the software is deployed.

3. Poor communication and collaboration

Testing should involve effective communication and collaboration between different teams, such as developers, testers, and stakeholders. Without this, you will end up with missed deadlines, and inconsistent testing results.

4. Overreliance on automation

While automation can be valuable for improving efficiency and reducing human error, it is not a complete substitute for manual testing. Automated tests are only as good as the scripts that are written to execute them, and they may not always catch all of the issues that a human tester would notice..

5. Testing without a scope

In the absence of an elaborate scope, it can be difficult to determine what needs to be tested and what doesn't. This can lead to wasted time and resources, as well as missed defects that could have been caught if the testing scope had been more defined. Always start with a clear scope that outlines what is to be tested, what is not to be tested, and the objectives of each test.

6. Blaming developers

While developers may be responsible for creating the code, it is important to remember that defects are a natural part of the software development process. Instead of blaming developers, testers should work with them to identify the root cause of the defect and work towards a solution. Aim to build a strong relationship between developers and testers.

7. Temptation to ignore risks

Sometimes, testers may be tempted to ignore risks or defects that are identified during testing. This can be due to a variety of reasons, such as a desire to meet a deadline, a belief that the risk is low or by giving in to pressure from colleagues who want to conclude the project. However, ignoring risks can lead to serious consequences. This normally happens towards the end of testing, where everyone feels that you have done enough already and any seemingly small parts can be ignored. Unfortunately, those “small” parts can drown the entire project that you’ve already worked so hard to bring to life. 

Key Takeaway

The cost of deploying and waiting to fix errors can spiral out of control very quickly. 

On average, developers spend up to 20% of their time trying to fix errors that would have been found and fixed earlier. 

The average salary of a developer in the US, for example, is about $120,000, of which 20% translates to $24,000 per developer. This is how much you could lose annually if you don’t get software testing done at the right time. 

We encourage early and continuous testing by all means. It’s much easier to find and fix errors when developers are still writing code. It’s also much more cost-effective to be constantly testing even when the software is working well.  Never wait for an emergency to trigger action. And even when emergency strikes, because it often may, you will be far much better prepared. Continuous testing puts you on your toes and up to date with the latest trends in testing including technology and approaches, putting you in a better position to respond to sudden failures. 

Do you have to conduct every possible test? Advisable but not mandatory. The point is to focus on tests with the greatest impact for the product and users. Of course some tests such as security are increasingly becoming a must, so is usability and acceptability.