4.4. Summary Table of Testing Types

The summary table below categorizes different types of testing based on whether they are functional or non-functional, manual or automated, and when they are typically used.

The summary table serves as a quick reference for QA professionals. It provides a clear breakdown of testing types under two main categories: functional and non-functional, and further classifies them based on whether they are manual or automated. This organization helps testers quickly identify which type of testing is appropriate for their needs based on the context of the project.

Think of this summary table as a menu in a restaurant. Just as a menu lists different types of dishes based on categories (like appetizers, main courses, desserts), the testing types table lays out various testing methodologies based on their functionalities and methodologies, making it easier for testers to pick what they need.

Manual Functional/Non-Functional Testing Use Case: Manual UI, ad-hoc, exploratory testing.

Manual functional testing involves human testers performing tests without the aid of automation tools. This type is especially helpful for user interface (UI) evaluations, ad-hoc scenarios where testing requires flexibility, and exploratory testing where testers can use their intuition to find issues that structured tests might miss. It allows for subjective assessments of usability and design.

Consider this like a chef tasting a dish. A chef will taste and adjust seasonings based on their knowledge and experience rather than following a strict recipe. Similarly, manual functional testing allows testers to use their insight and experience to evaluate the software.

Automated Functional/Non-Functional Testing Use Case: Automated regression or repeated test cases.

Automated functional testing uses scripts and tools to run tests automatically, which is efficient for regression testing and repetitive test cases. This type of testing is highly valuable for tasks that need to be repeated often, such as after every code update, where automated tests can quickly verify that existing functionalities remain intact.

Imagine a factory assembly line where robots perform the same task repeatedly. Just as automation in factories speeds up production and ensures quality, automated testing speeds up the testing process and enhances reliability in software development.

Regression Testing Functional Both When: After updates or bug fixes.

Regression testing is performed to ensure that recent code changes have not adversely affected existing functionality. This testing is crucial during software development because it helps catch any new bugs introduced during updates or fixes. The process usually involves running a suite of tests on the application after changes are made.

Think of regression testing like checking your entire house after making renovations. Just as you would want to make sure that the new painting work hasn’t caused any leaks or issues elsewhere, regression testing checks to ensure that the new code does not disrupt the existing system.

Smoke Testing Functional Both Use Case: Early tests after deployment.

Smoke testing refers to a preliminary test that checks the basic functionality of an application. It aims to identify simple failures that could stop further testing. This is usually done after a new build is deployed to ensure the core functionalities work correctly before proceeding further with more detailed testing.

You can compare smoke testing to turning on a light bulb. When you flip the switch, the first thing you want to check is whether the light turns on—this shows that the basic power supply is working and that you can move on to the next steps, like adjusting the brightness or adding lamps.

Sanity Testing Functional Manual When: Post-fix validation.

Sanity testing is a focused form of testing that checks whether a specific function or bug fix works properly. This differs from regression testing, as it typically does not involve retesting the entire application but is instead aimed at validating specific functionalities that are relevant to the recent changes.

Imagine you fixed a leak under your sink. Sanity testing is akin to running the faucet for a bit to ensure that the repair worked, rather than inspecting every pipe in the house. You’re just checking the relevant area that was supposed to be fixed.

UAT Functional Mostly Manual Use Case: Final business validation.

User Acceptance Testing is a crucial phase where real business users test the system to ensure it meets their needs and requirements. This testing serves as the final validation before the software goes live and is often performed in a real-world environment by the end users.

It's like taking a new car for a test drive before buying it. Potential buyers want to ensure it feels right and meets their expectations before making a significant investment, similarly, business users need to make sure that the software satisfies their operational needs before it’s officially deployed.

Performance Testing Non-Functional Automated Use Case: Load/stress evaluation.

Performance testing evaluates how the application behaves under various conditions of load and stress. This includes different subtypes, such as load testing (validating normal capacity) and stress testing (checking the limits). It is crucial for identifying potential bottlenecks and ensuring a smooth user experience.

Consider performance testing as training for a marathon runner. Just as a runner practices under increasing distances and varying conditions to understand their limits and prepare for race day, performance testing helps the application understand how it will perform under real-world stress and heavy user loads.

--