--- type: practical --- ## Pyramid ![[Testing Pyramid.png]] ## Negative results - **Error**: Mistake made by a human - **Fault**: A manifestation of an error in software - **Bug and Defect** are basically the same as Fault - **Failure**: Inability of a system or component to perform its required function ## Types of tests ### Functional testing | Fancy Words | Simpler Explanation | Stupid Dumb Word | | ------------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------------- | | Unit Testing | Testing individual components or pieces of code in isolation. | Piece by piece testing | | Integration Testing | Testing the interaction between integrated modules or components to ensure they work together as expected. | Mix and match testing | | System Testing | Testing the entire system as a whole to verify it meets specified requirements. | Whole thing testing | | Acceptance Testing | Testing to determine whether the system meets the business needs and requirements, often performed by the end-users. | Ready or not | | Regression Testing | Re-running tests to ensure that new code changes haven’t broken existing functionality. | Did we break it again? | | Sanity Testing | A quick round of testing to check if a specific function or bug fix works as intended. | Quick check testing | | Smoke Testing | A basic check to ensure the software’s core functionality works and it's stable enough for more in-depth testing. | Is it on fire? | | Usability Testing | Testing how user-friendly and intuitive the software is for the end-user. | Easy of use testing | ### Non-functional testing | Fancy Words | Simpler Explanation | Stupid Dumb Word | | --------------------- | ----------------------------------------------------------------------------------------- | -------------------------- | | Performance Testing | Testing how well the software performs under different conditions. | How fast does it run? | | Load Testing | Testing how the software behaves under expected user load. | How much can it carry? | | Stress Testing | Testing the limits of the software by pushing it beyond normal operational capacity. | When will it break? | | Volume Testing | Testing the software with a large amount of data to see if it handles it well. | How much data can it take? | | Scalability Testing | Testing how well the software scales when the user load or data volume increases. | Can it grow? | | Recovery Testing | Testing the software's ability to recover after a failure or crash. | Can it unfuck itself? | | Compatibility Testing | Testing how well the software works across different environments, platforms, or devices. | Does it work with others? | | Security Testing | Testing how well the software protects against unauthorized access and vulnerabilities. | Can it be broken into? | ## Black box vs White box | Black box | White box | | --------------------------------- | ---------------------- | | Done by tester | Done by devs | | Internal code unknown | Knowledge is required | | Functional testing | Structure testing | | No programming skills necessary | bruh | | Do it break, do it work, is nice? | Do it cover all cases? |