30 Layers of Testing Enterprise Software

The release of an enterprise grade software can often make or break a company. Critically acclaimed and commercially profitable software/apps go through layers of testing before users get their hands on them. Below is the "Thirty Layer Test Plan for Enterprise Software"
Back to Anoop's Homepage

disaster

Test Focus Typically Done By
Unit Test Arguably the most critical type of testing, unit tests validate individual components, pieces, or modules of the software to ensure they function as expected. The software is only as good as its weakest component! Developers
Integration Testing Evaluating the interaction and integration of multiple software components. The goal is to verify that they work together as expected. Typically takes place after unit testing and before system testing. You might have unit tested the engine, accelerator, and steering. But if you don't do the integration testing, you wouldn't know if your car can really be driven. Developers, Automation
Functional Testing This involves testing the software or application's functionality to ensure it meets the requirements, designs, and specifications. QA, Developers, Automation
Regression Testing Validation that modifications done to a software/app do not affect its existing functionality. Ensures that new changes or additions to the software do not cause unintended consequences, such as bugs, perf degradation, or compatibility issues with existing systems. Automation, QA, Developers
Scale / Load Testing Conducted to evaluate a software system or app's performance under a heavy workload - including a large number of users, network calls, transactions etc. accessing the system simultaneously for a sufficiently prolonged interval of time to identify performance issues on scalability and capacity. Automation, QA/PSR Teams
Stress Testing Different from load testing, the purpose of Stress Testing is to examine the behavior of the application when there is an extreme load that is over the breaking point. Automation, QA/PSR Teams
Spike Testing / Boundary Testing A special case of Stress Test, Spike testing involves “rapidly” increasing the number of users, API calls, or transactions to see how it handles sudden spikes (or dwindles) in usage or resource utilization. Think Amazon on Black Friday or a brokerage service at market open. Automation, QA/PSR Teams
Endurance Testing Focuses on verifying the software's behavior over extended periods of time, such as several days or weeks. The goal of endurance testing is to identify any memory leaks, performance degradation, or other issues that may occur over time. Automation, QA/PSR Teams
Uptime Testing Uptime testing is validating the ability to make a successful connection. It’s typically conducted to identify tangible SLAs of the application and to provide real time status of the availability of the app (or parts of the app) to the users. Automation, QA/PSR Teams
Resilience Testing Focuses on verifying the software's ability to recover from failures and errors, such as system crashes or network outages. The goal of resilience testing is to ensure that the software can continue to operate in the face of unexpected events and maintain data integrity and consistency Automation, QA/PSR Teams
Chaos Testing A technique that involves deliberately introducing controlled chaos/randomness into the software environment to test its resilience and stability. The goal is to identify potential failures or weaknesses in the system and to build robustness into the software. Automation tools / Specialized Chaos Bots
Interruption Testing Testing a software/webapp (or parts of it) on how they behave when there is an interruption of some kind – disconnection of wifi or extremely slow wifi, underlying machine reboot/crash, other high priority apps taking preference in case of mobile apps (like a phone call), inactivity for a prolonged period of time, session timeouts etc. Specialized Chaos Bots
Exploratory Testing This is an informal and dynamic approach to software testing that focuses on discovering new and unexpected scenarios/behaviors in the app. Typically done by testers who have a deep understanding of the software and its use cases, and involves a combination of testing, analysis, and experimentation. This involves testing the software in an unstructured, ad-hoc way, "off the rails" way. QA / Developers / Architects
Penetration Testing Often referred as a pen-test, this is a security exercise where a cyber-security expert attempts to find and exploit vulnerabilities in an app/software. It is a simulated attack intended to identify weak spots in a software/app which attackers could take advantage of. Specialized software security teams
SAST Static Application Security Testing (SAST) is a method of finding security vulnerabilities in software applications without executing the code. Instead, SAST analyzes the source code and configuration files of an application to identify potential security issues. Specialized SAST testing tools
DAST Dynamic Application Security Testing or DAST is type of testing that is performed on a live application. It focuses on discovering security vulnerabilities that exist in the application while it is running. Different from Pen-Testing, DAST is typically performed by a set of automation tools Specialized DAST Automation tools
Dogfooding The formal term for "eating your own dog food," dogfooding is the practice of using an organization's own software products or services just like a customer would. The purpose of dogfooding is to test the software in a real-world environment, identify any issues or problems, and make improvements before it is released to the general public. Crowdsourced at the larger org/company level
Fishfooding Same as dogfooding but for a much earlier stage of the product (PoC, prototype etc.) AND within a smaller team of testers/developers, versus an entire company Crowdsourced at the small team / focused group level
Bait Testing Same as dogfooding, but it involves using a competing software product or service like a customer would, in order to identify its strengths and weaknesses, and to make improvements to their own product. By testing a competing software, organizations intend to identify areas to differentiate themselves, and find ways to offer more value to their customers. Product Owners / Delivery Managers
Accessibility Testing Validating applications for accessibility to those with disabilities, such as vision impairment, hearing disabilities, and other physical or cognitive conditions, and to neurodiverse audience. (Labels, text contrast, alternate texts for images, dynamic font sizes) Customized Automation
Globalization / Localization Testing Making sure the product can be used by people all over the world AND/OR as applicable, making sure the product can be used in a particular language or region. This includes cultural nuances, linguistic limitations (left to right vs right to left etc.), currencies conversions, timezones adaptations etc. Product Owners, QA, Automation.
Compatibility and Interoperability Testing Testing the compatibility of the app/software on various browsers, operating systems, devices, screen resolutions, platforms, network configurations etc. In Interoperability Testing, a software’s capability or the lack thereof to work seamlessly with other software/apps as per the design/intention is validated. QA, Automation
LPAT (Legal and Policy Adherence Testing) Testing the software/app for its adherence to legal and company’s policies. Appropriate copyright messages; usage of correct software licenses; scans for patent/trademark violations; scans for copyright violations of media like images, audio etc.; validating the content for biases or other forms of extremities; cookie and data policy validations etc. Legal + Engineering team, QA, Product owners, Release Management
Finops Testing Arguably the latest kind of software testing, finops (financial operations) testing tests the software/app for its budget and cost constraints for its operation. Examples include cloud service billings for network calls, data storage charges, third party paid software usage, infrastructure costs etc. Devops / QA
Software Exotesting Exotesting (Exo meaning external) of a software or an app is the testing of all elements of using the software/app outside of software/app’s functionalities. This includes testing the installation, deployment, configuration, containerization (docker, VMs etc.), orchestration (e.g. kubernetes) of the software for bugs/issues and facilitate seamless use. Devops QA, QA, Automation
AI Model Threat Testing (Data Poisoning) Specific to software with elements of AI in them (which is more or less all software/apps now), Data Poisoning Testing is making sure the software is resilient to Poisoning Attacks (attacker “polluting” the data on which the model is being trained to tamper with its decision-making), Evasion attacks (trick ML models by providing subtly changed data) or other adversarial attacks. QA, Data Science
Smoke Testing Very simply, smoke tests are rapid regression tests of major functionality. It verifies whether the critical features are working or not, and that there are no showstoppers in the build. Also called confidence testing. Automation, QA
Intuitive Score Test Manually testing the software for “ease of usage” and “intuitiveness of the design”. Typically, a score is assigned by individual testers and the average score is taken for the app. The threshold is separate for “software intended for general public” and “software intended for technical audience”. Intuitive designs, specific goals, unambiguous messages, component placements on the page etc. often result in high scores. QA, Product Owners, General audience
UAT Often the last phase of the software testing process, UAT is performed by a narrow group of intended users right before the software is released to its intended market. A focused group of end users
A/B Testing A form of testing to compare two versions of a software to figure out which performs better. Evaluate the performance, usability, reception etc. of two versions of a feature. QA, Automation (for perf), Product Owners
disaster