Types Of Testing

White box Testing:  Tests the structure of the software or software component. It checks what going on inside the software. Also know as clear box Testing, glass box testing or structural testing.

Requires knowledge of internal code structure and good programming skills. It tests paths within a unit and also flow between units during integration of units. WhiteBox Test Design Techniques include

• Line Coverage or Statement Coverage
• Decision Coverage
• Condition Coverage
• Multiple Condition Decision Coverage
• Multiple Condition Coverage

Black box Testing:   Blackbox testing tests functional and non-functional characteristics of the software without referring to the internal code of the software. BlackBox testing doesn’t requires knowledge of internal code/structure of the system/software.It uses external descriptions of the software like SRS(Software Requirements Specification), Software Design Documents to derive the test cases. 
Blackbox Test Design Techniques include:

• Equivalance Partitioning
• Boundary Value Analysis
• State Transition Testing
• Usecase Testing
• Decision Table Testing

Smoke Testing:   Smoke testing is done for the software in order to verify that the software is stable enough for further testing. it has a collection of written tests that are performed on the software prior to being accepted for further testing. 

Smoke testing “touches” all areas of the application without getting too deep, tester looks for answers to basic questions like, “Does the application window opens”, “Can tester launch the software?” etc.

The purpose is to determine whether the application is stable enough so that a more detailed testing can be performed. The test cases can be performed manually or by using an automated tool.

A subset of planned test cases is decided which covers the main functionality of the software, but does not bother with finer software component details. A daily build and smoke test is among industry best practices. Smoke testing is done by testers before accepting a build for further testing.

In software engineering, a smoke test generally consists of a collection of tests that can be applied to a newly created or repaired computer program. Sometimes the tests are performed by the automated system that builds the final software. In this sense a smoke test is the process of validating code changes before the changes are checked into the larger production official source code collection or the main branch of source code.

Functional Testing:   In functional testing basically the testing of the functions of component or system is done. It refers to activities that verify a specific action or function of the code. Functional test tends to answer the questions like “can the user do this” or “does this particular feature work”. This is typically described in a requirements specification or in a functional specification.
The techniques used for functional testing are often specification-based. Testing functionality can be done from two perspective:

• Requirement-based testing: In this type of testing the requirements are prioritized depending on the risk criteria and accordingly the tests are prioritized. This will ensure that the most important and most critical tests are included in the testing effort.
• Business-process-based testing: In this type of testing the scenarios involved in the day-to-day business use of the system are described. It uses the knowledge of the business processes. For example, a personal and payroll system may have the business process along the lines of: someone joins the company, employee is paid on the regular basis and employee finally leaves the company.

Functional Testing: Functional testing is also known as component testing. It tests the functioning of the system or software i.e. What the software does. The functions of the software are described in the functional specification document or requirements specification document. Functional testing considers the specified behavior of the software.

OR

Testing the application against business requirements. Functional testing is done using the functional specifications provided by the client or by using the design specifications like use cases provided by the design team.

Functional Testing covers:

• Unit Testing
• Smoke testing / Sanity testing
• Integration Testing (Top Down, Bottom up Testing)
• Interface & Usability Testing
• System Testing
• Regression Testing
• Pre User Acceptance Testing(Alpha & Beta)
• User Acceptance Testing
• White Box & Black Box Testing
• Globalization & Localization Testing

Non-Functional Testing: Non functional testing tests the characteristics of the software like how fast the response is, or what time does the software takes to perform any operation.

OR

Testing the application against client's and performance requirement. Non-Functioning testing is done based on the requirements and test scenarios defined by the client.

Non-Functional Testing covers:

• Load and Performance Testing
• Ergonomics Testing
• Stress & Volume Testing
• Compatibility & Migration Testing
• Data Conversion Testing
• Security / Penetration Testing
• Operational Readiness Testing
• Reliability testing
• Usability testing
• Installation Testing
• Security Testing (Application Security, Network Security, System Security)

NOTE: Non functionality testing focuses on the software’s performance i.e. How well it works.

Sanity Testing: When there are some minor issues with software and a new build is obtained after fixing the issues then instead of doing complete regression testing a sanity is performed on that build. You can say that sanity testing is a subset of regression testing.

Sanity testing is done after thorough regression testing is over, it is done to make sure that any defect fixes or changes after regression testing does not break the core functionality of the product. It is done towards the end of the product release phase. 

Sanity testing follows narrow and deep approach with detailed testing of some limited features. Sanity testing is like doing some specialized testing which is used to find problems in particular functionality.Sanity testing is done with an intent to verify that end user requirements are met on not.Sanity tests are mostly non scripted.

Regression Testing:  Regression Testing is done to find out the defects that arise due to code changes made in existing code like functional enhancements or configuration changes. The main intent behind regression testing is to ensure that any code changes made for software enhancements or configuration changes has not introduced any new defects in the software. Anytime the changes are made to the existing working code,

"a suite of test cases is executed to ensure that the new changes have not introduced any bugs in the software."

It is necessary to have a regression test suite and execute that suite after every new version of software is available.

Regression test suite is the ideal candidate for automation because it needs to be executed after every new version.

Integration Testing : Integration testing tests integration or interfaces between components, interactions to different parts of the system such as an operating system, file system and hardware or interfaces between systems.

Also after integrating two different components together we do the integration testing. As displayed in the image below when two different modules ‘Module A’ and ‘Module B’ are integrated then the integration testing is done.

Integration testing is done by a specific integration tester or test team. Integration testing follows two  approach known as ‘Top Down’ approach and ‘Bottom Up’ approach as shown in the image below:

Below are the integration testing techniques:

a. Big Bang integration testing:

In Big Bang integration testing all components or modules are integrated simultaneously, after  which everything is tested as a whole. As per the below image all the modules from ‘Module 1′ to ‘Module  6′ are integrated simultaneously then the testing is carried out.

Advantage: Big Bang testing has the advantage that everything is finished before integration testing starts.

Disadvantage: The major disadvantage is that in general it is time consuming and difficult to trace the cause of failures because of this late integration.

b.Top-down integration testing: Testing takes place from top to bottom, following the control flow or architectural structure (e.g. starting from the GUI or main menu). Components or systems are substituted by stubs. Below is the diagram of  ‘Top down Approach’:

Advantages of Top-Down approach:

• The tested product is very consistent because the integration testing is basically performed in an environment that almost similar to that of reality

• Stubs can be written with lesser time because when compared to the drivers then Stubs are simpler to author.

Disadvantages of Top-Down approach:

Basic functionality is tested at the end of cycle

c. Bottom-up integration testing: Testing takes place from the bottom of the control flow upwards. Components or systems are substituted by drivers. Below is the image of ‘Bottom up approach’:

Advantage of Bottom-Up approach:

In this approach development and testing can be done together so that the product or application will be efficient and as per the customer specifications.

Disadvantages of Bottom-Up approach:

We can catch the Key interface defects at the end of cycle

It is required to create the test drivers for modules at all levels except the top control

Incremental Integration testing: Another extreme is that all programmers are integrated one by one, and a test is carried out after each step.The incremental approach has the advantage that the defects are found early in a smaller assembly when it is      relatively easy to detect the cause. A disadvantage is that it can be time-consuming since stubs and drivers have to be developed and used in the test.Within incremental integration testing  a range of possibilities exist, partly depending on the system architecture.