1. Equivalence Partitioning: This technique divides the input data into groups or partitions where the behavior of the software should be the same for all values within a given partition. Test cases are then designed to represent each partition. It’s particularly useful when there are many possible input values, making it impractical to test them all.
2. Boundary Value Analysis: Boundary value analysis focuses on testing values at the edges or boundaries of input partitions. The rationale is that errors often occur at these critical points. Test cases are designed for the minimum and maximum values and values just inside and outside the boundaries.
3. State Transition Testing: State transition testing is typically used for systems with defined states, such as finite state machines. Test cases are designed to cover various state transitions and verify that the software transitions correctly from one state to another.
4. Use Case Testing: Use case testing is based on specific use cases or scenarios that represent how users interact with the software. Test cases are designed to validate that the software behaves correctly in real-world usage situations.
5. Exploratory Testing: Exploratory testing is less structured and more spontaneous than other testing techniques. Testers use their creativity and domain knowledge to explore the software, trying different inputs and actions to uncover defects. While there are no predefined test cases, testers often document their findings during exploratory testing.

1. Early Involvement: Shift-left testing involves testers, quality assurance (QA) professionals, and testing activities from the very beginning of the SDLC. Testers collaborate with developers, business analysts, and other stakeholders right from the requirements and design phases.
2. Automation: Automated testing tools and practices are often a core component of shift-left testing. Test automation allows for the rapid execution of tests, making it feasible to include testing in earlier phases of development without significantly slowing down the process.
3. Continuous Integration and Continuous Delivery (CI/CD): Shift-left testing is closely linked with CI/CD practices. Automated tests are integrated into the CI/CD pipeline, enabling continuous testing of code changes as they are made. This ensures that defects are caught and addressed immediately.
4. Test-Driven Development (TDD): TDD is a development practice where tests are written before the code is implemented. This approach ensures that the code meets the specified requirements and has fewer defects from the outset.
5. Static Code Analysis: Tools for static code analysis are used to scan code for potential issues, such as coding standards violations and security vulnerabilities, before the code is even compiled. This helps in identifying and addressing issues early.
6. Shift-Left Security: In addition to functional testing, shift-left testing also incorporates security testing practices early in the development process. This helps in identifying and mitigating security vulnerabilities as soon as they are introduced.
7. Collaboration: Effective communication and collaboration among development, testing, and other project stakeholders are essential for successful shift-left testing. This ensures that everyone is on the same page regarding quality objectives and testing requirements.

By shifting testing left in the SDLC, organizations can catch defects earlier when they are less expensive to fix, reduce the risk of critical issues going unnoticed until later stages, and ultimately deliver higher-quality software more efficiently

1. Testing Shows the Presence of Defects: The primary purpose of testing is to uncover defects or bugs in the software. It doesn’t prove that the software is error-free, but it identifies issues that need to be addressed.
2. Exhaustive Testing is Impossible: It’s practically impossible to test every possible input and scenario for a complex software system. Instead, testing should be risk-based, focusing on the most critical areas of the software.
3. Early Testing: Testing should start as early as possible in the software development life cycle. Detecting and fixing defects early reduces the cost and effort required to address them.
4. Defect Clustering: In most software systems, a small number of modules or components tend to have the majority of defects. Test efforts should be concentrated on these areas.
5. Pesticide Paradox: If the same set of tests is repeated over and over, it becomes less effective at finding new defects. To combat this, test cases should be regularly reviewed and updated to include new scenarios.
6. Testing is Context-Dependent: Testing strategies, techniques, and objectives should be tailored to the specific context of the project. What works for one project may not work for another.
7. Absence-of-Errors Fallacy: The absence of detected defects doesn’t necessarily mean the software is ready for release. It should also meet the specified requirements and satisfy the user’s needs.