1. Prepared By: Asst. Prof. Garima Pathak
UNIT-2 LEVEL OF TESTING
Prepared By: Asst. Prof. Garima Pathak

2. Index Unit testing Integration testing System testing
Acceptance testing - alpha testing, beta testing
Static and dynamic testing
Manual and automation testing

3. Introduction to Levels of Testing
There are different FOUR levels during the process of testing.
1) Unit Testing:
The purpose is to validate that each unit of the software performs as designed.
2) Integration Testing:  
The purpose of this level of testing is to expose faults in the interaction between integrated units.
3) System Testing:
The purpose of this test is to evaluate the system’s compliance with the specified requirements.
4) Acceptance Testing:
The purpose of this test is to evaluate the system’s compliance with the business requirements and assess whether it is acceptable for delivery. There are two sub levels of this level are-Alpha Testing and Beta Testing.

4. Introduction to Levels of Testing
[Figure of Testing Levels]

5. Unit Testing
Unit Testing is a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed.
A unit is the smallest testable part of an application like functions, classes, procedures, interfaces.
METHOD:
Unit Testing is performed by using the White Box Testing method.
When is it performed?
Unit Testing is the first level of testing and is performed prior to Integration Testing.

6. Unit Testing Who performs it?
Unit Testing is normally performed by software developers themselves or their peers. In rare cases it may also be performed by independent software testers.
Need of Unit Testing: There are a number of reasons to do unit testing rather than testing the entire product:
The size of a single module is small enough that we can locate an error fairly easily.
The module is small enough that we can attempt to test it in some demonstrably exhaustive fashion.
Confusing interactions of multiple errors in widely different parts of the software are eliminated.

7. Unit Testing Unit Test Consideration:
The tests that occur as part of unit tests are illustrated schematically in below Figure.
[Figure of Unit Test]

8. Unit Testing
Test cases in unit testing should uncover errors, such as:
Comparison of different data types
Incorrect logical operators or precedence
Expectation of equality when precision error makes equality unlikely
Incorrect comparison of variables
Improper loop termination
Failure to exit when divergent iteration is encountered
Improperly modified loop variables

9. [Figure of Unit Test Environment]
Unit Testing
Unit-test Procedure
The unit-test environment is illustrated in below Figure.
[Figure of Unit Test Environment]

10. Unit Testing
In most applications a driver is nothing more than a “main program” that accepts test-case data, passes such data to the component (to be tested), and prints relevant results.
Stubs serve to replace modules that are subordinate (called by) to the component to be tested.
A stub uses the subordinate module’s interface, may do minimal data manipulation, prints verification of entry, and returns control to the module undergoing testing.
Unit testing is simplified when a component with high cohesion is designed.

11. Unit Testing Unit Testing Tools: Rational Software :
Rational Software by IBM has a unit test feature known as "Rational Test Realtime". The software contains a complete range of testing tools for much more than just unit testing. It is used for Ada, Java, C and C++. It creates unit tests by reverse engineering the software.
JavaScript Assertion Unit-
this Freeware JavaScript unit testing tool can be used on any platform that supports JavaScript.

12. Integration Testing
Integration Testing is a level of software testing where individual units are combined and tested as a group.
METHOD:
Any of Black Box Testing, White Box Testing, and Gray Box Testing methods can be used. Normally, the method depends on your definition of ‘unit’.
When is Integration Testing performed?
Integration Testing is performed after Unit Testing and before System Testing.
Who performs Integration Testing?
Either Developers themselves or independent Testers perform Integration Testing.

13. Integration Testing
Approaches/methodologies/ strategies of Integration Testing:
 Big Bang Approach
 Incremental Approach: which is further divided into following
 Top Down Approach
 Bottom Up Approach
 Sandwich Approach - Combination of Top Down and Bottom Up

14. Integration Testing Big Bang Approach:
In Big Bang integration testing all components or modules are integrated simultaneously, after which everything is tested as a whole.
This approach is generally executed by those developers who follows the ‘Run it and see’ approach.
In this approach individual modules are not integrated until and unless all the modules are ready.
As per the below image all the modules from ‘Module 1′ to ‘Module 6′ are integrated simultaneously then the testing is carried out.

15. [Figure of Big Bang Integration Testing]
Big Bang Approach:
[Figure of Big Bang Integration Testing]

16. Integration Testing Incremental Approach:
The program is constructed and tested in small increments, where errors are easier to isolate and correct; interfaces are more likely to be tested completely; and a systematic test approach may be applied.
This process is carried out by using dummy programs called Stubs and Drivers
Stub: Is called by the Module under Test.
Driver: Calls the Module to be tested.
Incremental approach is further divided into three sub categories:
Top-down Integration
Bottom-up Integration
Sandwich Integration

17. Integration Testing A. Top-down Integration:
Top-down integration testing is an incremental approach to construction of the software architecture. Modules are integrated by moving downward through the control hierarchy.
Top-Down Integration: There are two approaches:
i) Depth-First Integration
ii) Breadth-First Integration
i) Depth-First Integration:
Referring to Figure-E, depth-first integration integrates all components on a major control path of the program structure.

18. [Figure of Top-Down Integration]
Integration Testing
[Figure of Top-Down Integration]

19. Integration Testing
For example, selecting the left-hand path, components M1, M2 , M5 would be integrated first. Next, M8 or (if necessary for proper functioning of M2) M6 would be integrated.
Then, the central and right-hand control paths are built
ii) Breadth-First Integration:
Referring to Figure, incorporates all components directly subordinate at each level, moving across the structure horizontally.
From the figure, components M2, M3, and M4 would be integrated first. The next control level, M5, M6, and so on, follows.

20. Integration Testing Integration Process Steps:
The main control module is used as a test driver and stubs are substituted for all components directly subordinate to the main control module.
Depending on the integration approach selected (i.e., depth or breadth first), subordinate stubs are replaced one at a time with actual components.
Tests are conducted as each component is integrated.
On completion of each set of tests, another stub is replaced with the real component.
Regression testing may be conducted to ensure that new errors have not been introduced.
The process continues from step 2 until the entire program structure is built.

21. Integration Testing B. Bottom-Up Integration:
Bottom-up integration testing, as its name implies, begins construction and testing with atomic modules (i.e., components at the lowest levels in the program structure).
A bottom-up integration strategy may be implemented with the following steps:
1. Low-level components are combined into clusters (sometimes called builds) that perform a specific software subfunction.
2. A driver (a control program for testing) is written to coordinate test case input and output.
3. The cluster is tested.
4. Drivers are removed and clusters are combined moving upward in the program structure.

22. [Figure-Bottom-Up Integration]
Integration Testing
B. Bottom-Up Integration:
[Figure-Bottom-Up Integration]

23. Integration Testing
Integration follows the pattern illustrated in Figure. Components are combined to form clusters 1, 2, and 3.
Each of the clusters is tested using a driver (shown as a dashed block).
Components in clusters 1 and 2 are subordinate to Ma. Drivers D1 and D2 are removed and the clusters are interfaced directly to Ma.
C. Sandwich Integration:
It is an approach to Integration Testing which is a combination of Top Down and Bottom Up approaches. So, it is also called mixed integration testing.
In it, the whole system is divided into three layers, just like a sandwich: the target is in the middle and one layer is above the target and one is below the target.

24. Integration Testing
The top-down approach is used in the layer that is above the target and the bottom-up approach is used in the layer that is below the target.

25. System Testing
System Testing is a level of the software testing where a complete and integrated software is tested.
The purpose of this test is to evaluate the system’s compliance with the specified requirements.
System testing is actually a series of different tests whose sole purpose is to exercise the full computer based system.
METHOD
Black Box Testing method is used. System testing involves the external workings of the software from the user's perspective.
When is it performed?
System Testing is performed after Integration Testing and before Acceptance Testing.
Who performs it?-independent Testers

26. System Testing Types of System Testing:
There are more than 50 types of System Testing. Below listed types of system testing are large software development company would typically use currently:
Recovery Testing: Recovery testing is done to demonstrate a software solution is reliable, trustworthy and can successfully recoup from possible crashes.
Security Testing: Security testing attempts to verify that protection mechanisms built into a system will, protect it from improper situation.
Stress Testing: Stress testing executes a system in a manner that demands resources in abnormal quantity, frequency, or volume.

27. System Testing
Performance Testing: Performance testing is designed to test the run-time performance of software within the context of an integrated system. Performance testing occurs throughout all steps in the testing process.
Deployment Testing: Deployment testing, sometimes called configuration testing, exercises the software in each environment in which it is to operate.
Usability Testing: Usability testing mainly focuses on the user's ease to use the application, flexibility in handling controls and ability of the system to meet its objectives
Load Testing: Load testing is necessary to know that a software solution will perform under real life loads.

28. Acceptance Testing
Acceptance Testing is a level of the software testing where a system is tested for acceptability.
The purpose of this test is to evaluate the system’s compliance with the business requirements and assess whether it is acceptable for delivery.
When is it performed?
Acceptance Testing is performed after System Testing and before making the system available for actual use.
There are two types of Acceptance Testing:
i) Alpha testing
ii) Beta testing

29. Acceptance Testing
Acceptance Testing is a level of the software testing where a system is tested for acceptability.
The purpose of this test is to evaluate the system’s compliance with the business requirements and assess whether it is acceptable for delivery.
METHOD
Usually, Black Box Testing method is used in Acceptance Testing. The Acceptance testing is “black box” tests, means UAT users doesn’t aware of internal structure of the code, they just specify the input to the system & check whether systems respond with correct result.
When is it performed?
Acceptance Testing is performed after System Testing and before making the system available for actual use.

30. Acceptance Testing i) Alpha Testing:
Alpha testing refers to the system testing carried out by the test team within the development organization.
The alpha test is conducted at the developer’s site by the customer under the project team’s guidance.
Alpha tests are conducted in a controlled environment. It is a simulation of real-life usage.
It has two phases:
In the first phase of alpha testing, the software is tested by in-house developers. They use either debugger software, or hardware-assisted debuggers. The goal is to catch bugs quickly.
In the second phase of alpha testing, the software is handed over to the software QA staff, for additional testing in an environment that is similar to the intended use.

31. Acceptance Testing i) Alpha Testing:
Once the alpha test is complete, the software product is ready for transition to the customer site for implementation and development.
The version of the release on which Alpha testing is perform is called “Alpha Release”.
ii) Beta Testing:
Beta testing is the system testing performed by a selected group of friendly customers.
If the system is com System is installed and all users are asked to use the software in testing mode; this is not live usage. This is called the beta test.
Beta tests are conducted at the customer site in an environment where the software is exposed to a number of users. .

32. Acceptance Testing
Beta testing is also known as Field testing. This is used to get feedback from the market.
Developers are taking actions on all issues reported in beta testing after bug triage & then the software application is ready for the final release. The version release after beta testing is called “Beta Release“.
Developers release either a closed beta or an open beta;
Closed beta versions are released to a select group of individuals for a user
Open betas are from a larger group to the general public and anyone interested.

33. Acceptance Testing

34. Acceptance Testing

35. Static and Dynamic Testing
Static Testing:
Static testing is the testing of the software work products manually, or with a set of tools, but they are not executed.
It starts early in the Life cycle [SDLC-V Model] and so it is done during the verification process.
The fundamental objective of static testing technique is to improve the quality of the software products by finding errors in early stages of software development life cycle.
Following are the main Static Testing techniques used:
1. Informal Reviews- A review not based on a formal (documented) procedure. 2. Walkthrough-A step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content.

36. Static and Dynamic Testing
3. Technical Reviews- A peer group discussion activity that focuses on achieving consensus on the technical 4. Inspection-A type of peer review that relies on visual examination of documents to detect defects, eg., violation of development standards and non-conformance to higherlevel documentation. The most formal review technique and therefore always based on a documented procedure. 5. Static Code Analysis- The code written by developers are analysed (usually by tools) for structural defects that may lead to defects.

37. Static and Dynamic Testing
This testing technique needs computer for testing.
It is done during Validation process.
The software is tested by executing it on computer.
Example of this Dynamic Testing Technique: testing, integration, system testing, acceptance testing
Validation, the dynamic testing part is more hands on and happens on the product itself and not on an artifact or a representation of the product. A much formal process of test case/condition identification, coverage considerations, execution and defect reporting all mark the dynamic testing methods.

38. Static and Dynamic Testing

39. Static and Dynamic Testing

40. Manual and Automation Testing
Manual Testing:
In Manual Testing , Testers manually execute test cases without using any automation tools. Manual testing is the most primitive of all testing types and helps find bugs in the software system.
Manual Testing does not require knowledge of any testing tool. One of the  Software Testing Fundamental is "100% Automation is not possible". This makes Manual Testing imperative. 
Manual Testing Types:
In general any type of software testing type can be executed both manually as well using an automation tool.

41. Manual and Automation Testing
Manual Testing Types:
Unit Testing
This initial stage in testing normally carried out by the developer who wrote the code and sometimes by a peer using the white box testing technique.
Integration Testing
This stage is carried out in two modes, as a complete package or as an increment to the earlier package. Most of the time black box testing technique is used. However, sometimes a combination of Black and White box testing is also used in this stage.

42. Manual and Automation Testing
Manual Testing Types:
System Testing
In this stage the software is tested from all possible dimensions for all intended purposes and platforms. In this stage Black box testing technique is normally used.
User Acceptance Testing
This testing stage carried out in order to get customer sign-off of finished product. A 'pass' in this stage also ensures that the customer has accepted the software and is ready for their use.

43. Manual and Automation Testing
Automation Testing means using an automation tool to execute your test case suite.   The automation software can also enter test data into the System Under Test ,  compare  expected and actual  results and generate detailed test  reports.
Testers write test scripts and test cases using the automation tool and then group into test suites.

44. Manual and Automation Testing
Why Automated Testing?
 Automated testing is important due to following reasons: 
Manual Testing of all work flows, all fields , all negative scenarios is time and cost consuming
It is difficult to test for multi lingual sites manually
Automation does not require Human intervention. You can run automated test unattended (overnight)
Automation increases  speed of test execution
Automation helps increase  Test Coverage
Manual Testing can become boring and hence error prone.

45. Manual and Automation Testing
Which Test Cases to Auotomate?
Test cases to be automated can be selected using the following criterion to increase the automation ROI
High Risk - Business Critical test cases
Test cases that are executed repeatedly
Test Cases that are very tedious or difficult to perform manually
Test Cases which are time consuming
Automation Process:
Test tool selection: Test Tool selection largely depends on the technology the Application Under Test is built on. For instance QTP does not support Informatica.  So QTP cannot be used for testing Informatica applications. It's a good idea to conduct Proof of Concept of Tool on AUT

46. Manual and Automation Testing
Automation Process:
Define the scope of Automation: Scope of automation is the area of your Application Under Test which will be automated. 
Planning, design and development: During this phase you create  Automation strategy & plan.
Test execution: Automation Scripts are executed during this phase. The scripts need input test data before there are set to run. Once executed they provide detailed test reports.

47. Manual and Automation Testing
Criteria for Tool Selection: For automating any application, the following parameters should be considered.
Data driven capabilities
Debugging and logging capabilities
Platform independence
Extensibility & Customizability
Notifications
Version control friendly
Support unattended test runs

48. Manual and Automation Testing

49. Manual and Automation Testing

50. Thank You