List of techniques:

1.Static testing

2.Dynamic testing

3.Operational testing

Static Techniques: Static techniques of quality control define checking the software product and related artifacts without executing them. It is also termed desk checking/verification /white box testing‘. It may include reviews, walkthroughs, inspection, and audits Here; the work product is reviewed by the reviewer with the help of a checklist, standards, any other artifact, knowledge and experience, in order to locate the defect with respect to the established criteria. Static technique is so named because it involves no execution of code, product, documentation, etc. This technique helps in establishing conformance to requirements view.

Dynamic Testing: Dynamic testing is a validation technique which includes dummy or actual execution of work products to evaluate it with expected behavior. It includes black box testing methodology such as system testing and unit testing. The testing methods evaluate the product with respect to requirements defined, designs created and mark it as pass or fail‘. This technique establishes fitness for use‘view.

Operational techniques: Operational techniques typically include auditing work products and projects to understand whether the processes defined for development /testing are being followed correctly o not, and also whether they are effective or not. It also includes revisiting the defects before and after fixing and analysis. Operational technique may include smoke testing and sanity testing of a work product.

OR

Techniques to find defects are:

a) Quick Attacks: The quick-attacks technique allows you to perform a cursory analysis of a system in a very compressed timeframe. Even without a specification, you know a little bit will probably produce a few bugs. Finally, quick attacks are quick. They can help you to make a rapid assessment. You may not know the requirements, but if your attacks yielded a lot of bugs, the programmers probably aren't thinking about exceptional conditions, and it's also likely that they made mistakes in the main functionality. If your attacks don't yield any defects, you may have some confidence in the general, happy-path functionality

b) Equivalence and Boundary Conditions: Boundaries and equivalence classes give us a technique to reduce an infinite test set into something manageable. They also provide a mechanism for us to show that the requirements are "covered".

c) Common Failure Modes: The heart of this method is to figure out what failures are common for the platform, the project, or the team; then try that test again on this build. If your team is new, or you haven't previously tracked bugs, you can still write down defects that "feel" recurring as they occur and start checking for them.

d) State-Transition Diagrams: Mapping out the application provides a list of immediate, powerful test ideas. Model can be improved by collaborating with the whole team to find "hidden" states transitions that might be known only by the original programmer or specification author. Once you have the map, you can have other people draw their own diagrams, and then compare theirs to yours. The differences in those maps can indicate gaps in the requirements, defects in the software, or at least different expectations among team members.

e) Use Cases and Soap Opera Tests: Use cases and scenarios focus on software in its role to enable a human being to do something. Use cases and scenarios tend to resonate with business customers, and if done as part of the requirement process, they sort of magically generate test cases from the requirements. They make sense and can provide a straightforward set of confirmatory tests. Soap opera tests offer more power, and they can combine many test types into one execution.

f) Code-Based Coverage Models: Imagine that you have a black-box recorder that writes down every single line of code as it executes. Programmers love code coverage. It allows them to attach a number an actual, hard, real number, such as 75% to the performance of their unit tests, and they can challenge themselves to improve the score. Meanwhile, looking at the code that isn't covered also can yield opportunities for improvement and bugs.

g) Regression and High-Volume Test Techniques: People spend a lot of money on regression testing, taking the old test ideas described above and rerunning them over and over. This is generally done with either expensive users or very expensive programmers spending a lot of time writing and later maintaining those automated tests. about the software, so the time spent is also time invested in developing expertise. The skill is relatively easy to learn, and once you've attained some mastery your quick-attack session