1. Software Testing
Ashima Wadhwa

2. Coding
The coding phase of the software life-cycle is concerned with the development of code that will implement the design.
This code is written is a formal language called a programming language.
Programming languages have evolved over time from sequences of ones and zeros directly interpretable by a computer, through symbolic machine code, assembly languages, and finally to higher-level languages that are more understandable to humans.

3. Software Testing
Software testing is a process used to identify the correctness, completeness and quality of developed computer software.
It is the process of executing a program / application under positive and negative conditions by manual or automated means. It checks for the :-
Specification
Functionality
Performance

4. Observations about Testing
Testing is the process of executing a program with the intention of finding errors.” – Myers
“Testing can show the presence of bugs but never their absence.” - Dijkstra

5. Good Testing Practices
A good test case is one that has a high probability of detecting an undiscovered defect, not one that shows that the program works correctly
It is impossible to test your own program
A necessary part of every test case is a description of the expected result

6. Good Testing Practices
Assign your best people to testing
Ensure that testability is a key objective in your software design
Never alter the program to make testing easier
Testing, like almost every other activity, must start with objectives

7. Good Testing Practices
Write test cases for valid as well as invalid input conditions.
Thoroughly inspect the results of each test
As the number of detected defects in a piece of software increases, the probability of the existence of more undetected defects also increases

8. Why Software Testing ?
Software Testing is important as it may cause mission failure, impact on operational performance and reliability if not done properly.
Effective software testing delivers quality software products satisfying user’s requirements, needs and expectations.

9. What …????
…is an ”ERROR”??
….is a ”Bug”??
….is Fault, Failure ??

10. Bug, Fault & Failure A person makes an Error
That creates a fault in software
That can cause a failure in operation
Error : An error is a human action that produces the incorrect result that results in a fault.
Bug : The presence of error at the time of execution of the software.
Fault : State of software caused by an error.
Failure : Deviation of the software from its expected result. It is an event.

11. Test Plan
The goal of test planning is to establish the list of tasks which, if performed, will identify all of the requirements that have not been met in the software. The main work product is the test plan.
The test plan documents the overall approach to the test. In many ways, the test plan serves as a summary of the test activities that will be performed.
It shows how the tests will be organized, and outlines all of the testers’ needs which must be met in order to properly carry out the test.
The test plan should be inspected by members of the engineering team and senior managers.

12. Test Plan
The test plan keeps track of possible tests that will be run on the system after coding.
The test plan is a document that develops as the project is being developed.
Record tests as they come up
Test error prone parts of software development.
The initial test plan is abstract and the final testplan is concrete.

13. Test Plan
The initial test plan contains high level ideas about testing the system without getting into the details of exact test cases.
The most important test cases come from the requirements of the system.
We have the requirements document. Why not wait till the testing phase to develop test cases?

14. Test Cases
Test cases derived from requirements are system test cases as these test cases are aimed at testing the system as a whole.
When the system is in the design stage, the initial tests can be refined a little.
During the detailed design or coding phase, exact test cases start to materialize.
After coding, the test points are all identified and the entire test plan is exercised on the software.

15. Test Cases
A test case is a description of a specific interaction that a tester will have in order to test a single behavior of the software.
Test cases are very similar to use cases, in that they are step-by-step narratives which define a specific interaction between the user and the software.

16. Test Cases A typical test case is laid out in a table, and includes:
A unique name and number
A requirement which this test case is exercising
Preconditions which describe the state of the software before the test case
Steps that describe the specific steps which make up the interaction
Expected Results which describe the expected state of the software after the test case is executed

17. Advantages of Test Plan
Some advantages of the test plan are
Serves as a guide to testing throughout the development.
We only need to define test points during the testing phase.
Serves as a valuable record of what testing was done.
The entire test plan can be reused if regression testing is done later on.
The test plan itself could have defects just like software!

18. Who Does the Testing?
It depends on the process and the associated stakeholders of the project(s). In the IT industry, large companies have a team with responsibilities to evaluate the developed software in context of the given requirements. Moreover, developers also conduct testing which is called Unit Testing. In most cases, the following professionals are involved in testing a system within their respective capacities:
Software Tester
Software Developer
Project Lead/Manager
End User

19. Who Does the Testing?
Different companies have different designations for people who test the software on the basis of their experience and knowledge such as Software Tester, Software Quality Assurance Engineer, QA Analyst, etc.
It is not possible to test the software at any time during its cycle. The next two sections state when testing should be started and when to end it during the SDLC.

20. Levels Of Testing

21. What Is Unit Testing? Definition
A unit is a module or a small set of modules.
In Java, a unit is a class or interface, or a set of them, e.g.,
An interface and 3 classes that implement it, or
A public class along with its helper classes.
Unit testing is testing of a unit.

22. Why Unit Testing? Divide-and-conquer approach Split system into units.
Debug unit individually.
Narrow down places where bugs can be.
Don’t want to chase down bugs in other units.

23. How to Do Unit Testing Scaffolding
To do Unit tests, we have to provide replacements for parts of the program that we will omit from the test.
Scaffolding is any code that we write, not as part of the application, but simply to support the process of Unit and Integration testing.
Scaffolding comes in two forms
Drivers
Stubs

24. Scaffolding
Stubs are dummy modules that are always distinguish as "called programs", or you can say that is handle in integration testing (top down approach), it used when sub programs are under construction. Stubs are considered as the dummy modules that always simulate the low level modules.
Drivers are also considered as the form of dummy modules which are always distinguished as "calling programs”, that is handled in bottom up integration testing, it is only used when main programs are under construction.
Drivers are considered as the dummy modules that always simulate the high level modules.

25. Example of Stubs and Drivers is given below:-
For Example we have 3 modules login, home, and user module. Login module is ready and need to test it, but we call functions from home and user (which is not ready). To test at a selective module we write a short dummy piece of a code which simulates home and user, which will return values for Login, this piece of dummy code is always called Stubs and it is used in a top down integration.  
Considering the same Example above: If we have Home and User modules get ready and Login module is not ready, and we need to test Home and User modules Which return values from Login module, So to extract the values from Login module We write a Short Piece of Dummy code for login which returns value for home and user, So these pieces of code is always called Drivers and it is used in Bottom Up Integration

26. What is Unit Testing Concerned with
Functional correctness and completeness
Error handling
Checking input values (parameter)
Correctness of output data (return values)
Optimizing algorithm and performance

27. Traditional testing vs Unit Testing

28. Traditional Testing Test the system as a whole
Individual components rarely tested
Errors go undetected
Isolation of errors difficult to track down

29. Traditional Testing Strategies
Print Statements
Use of Debugger
Debugger Expressions
Test Scripts

30. Unit Testing Each part tested individually
All components tested at least once
Errors picked up earlier
Scope is smaller, easier to fix errors

31. Unit Testing Ideals
Isolatable
Repeatable
Automatable
Easy to Write

32. Why Unit Test? Faster Debugging Faster Development Better Design
Excellent Regression Tool
Reduce Future Cost

33. BENEFITS
Unit testing allows the programmer to refactor code at a later date, and make sure the module still works correctly.
By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.
Unit testing provides a sort of living documentation of the system.
It facilitates change, it simplifies integration, documentation

34. GUIDELINES Keep unit tests small and fast
Ideally the entire test suite should be executed before every code check in. Keeping the tests fast reduce the development turnaround time.
Unit tests should be fully automated and non-interactive
The test suite is normally executed on a regular basis and must be fully automated to be useful. If the results require manual inspection the tests are not proper unit tests.

35. GUIDELINES Make unit tests simple to run Measure the tests
Configure the development environment so that single tests and test suites can be run by a single command or a one button click.
Measure the tests
Apply coverage analysis to the test runs so that it is possible to read the exact execution coverage and investigate which parts of the code is executed and not.

36. GUIDELINES Fix failing tests immediately
Each developer should be responsible for making sure a new test runs successfully upon check in, and that all existing tests runs successfully upon code check in. If a test fails as part of a regular test execution the entire team should drop what they are currently doing and make sure the problem gets fixed.

37. GUIDELINES Keep testing at unit level
Unit testing is about testing classes. There should be one test class per ordinary class and the class behaviour should be tested in isolation. Avoid the temptation to test an entire work-flow using a unit testing framework, as such tests are slow and hard to maintain. Work-flow testing may have its place, but it is not unit testing and it must be set up and executed independently.

38. Unit Testing Techniques:
 Structural, Functional & Error based Techniques Structural Techniques:
 It is a White box testing technique that uses an internal perspective of the system to design test cases based on internal structure. It requires programming skills to identify all paths through the software. The tester chooses test case inputs to exercise paths through the code and determines the appropriate outputs.

39. Major Structural techniques are:
Statement Testing: A test strategy in which each statement of a program is executed at least once. 
Branch Testing: Testing in which all branches in the program source code are tested at least once.
Path Testing: Testing in which all paths in the program source code are tested at least once.
Condition Testing: Condition testing allows the programmer to determine the path through a program by selectively executing code based on the comparison of a value  
Expression Testing: Testing in which the application is tested for different values of Regular Expression.

40. Unit Testing Techniques:
Functional testing techniques: These are Black box testing techniques which tests the functionality of the application.

41. Some of Functional testing techniques
Input domain testing: This testing technique concentrates on size and type of every input object in terms of boundary value analysis and Equivalence class.  
Boundary Value: Boundary value analysis is a  software testing design technique in which tests are designed to include representatives of boundary values.  
Syntax checking: This is a technique which is used to check the Syntax of the application. 
Equivalence Partitioning: This is a software testing technique that divides the input data of a software unit into partition of data from which test cases can be derived

42. Unit Testing Techniques:
Error based Techniques: The best person to know the defects in his code is the person who has designed it.

43. Few of the Error based techniques
Fault seeding techniques can be used so that known defects can be put into the code and tested until they are all found.
Mutation Testing: This is done by mutating certain statements in your source code and checking if your test code is able to find the errors. Mutation testing is very expensive to run, especially on very large applications.
Historical Test data: This technique calculates the priority of each test case using historical information from the previous executions of the test case. 

44. Integration Testing
Integration testing is executed to establish whether the components interact with each other consort to the specification or not. Integration testing in large refers to joining all the components resulting in the complete system. It is further performed by the developer or the software Tester or by both. Example- checking that a Payroll system interacts as required with the Human Resource system.

45. Incremental integration testing

46. What is White-Based Software Testing?
What is Software Integration Testing? Testing activities that integrate software components together to form a complete system. To perform a cost-effective software integration, integration test strategy, integration test set are needed. Major testing focuses: - Interfaces between modules (or components) - Integrated functional features - Interacting protocols and messages - System architectures Who perform software integration: Developers and test engineers What do you need?: - Integration strategy - Integration test environment and test suite - Module (or component) specifications - Interface and design documents

47. Software Integration Strategy
What is a software integration strategy? Software test strategy provides the basic strategy and guidelines to test engineers to perform software testing activities in a rational way. Software integration strategy usually refers to --> an integration sequence (or order) to integrate different parts (or components) together. A test model is needed to support the definition of software integration test strategies. Typical test models: control flow graph object-oriented class diagram scenario-based model component-based integration model architecture-based integration model

48. Traditional Software Integration Strategy
There are two groups of software integration strategies: - Non Incremental software integration - Incremental software integration Non Incremental software integration: --> Big band integration approach Incremental software integration: --> Top- down software integration --> Bottom-up software integration --> Sandwich integration

49. Traditional Software Integration Strategy
Non-incremental integration:
- Big Band - combine (or integrate) all parts at once.
Advantages: simple
Disadvantages: - hard to debugging, not easy to isolate errors
- not easy to validate test results
- impossible to form an integrated system

50. Top-down Integration
Idea:-Modules are integrated by moving downward through the control structure.
Modules subordinate to the main control module are incorporated into the system
in either a depth-first or breadth-first manner.
Integration process (five steps):
1. the main control module is used as a test driver, and the stubs
are substituted for all modules directly subordinate to the main
control module.
2. subordinate stubs are replaced one at a time with actual modules.
3. tests are conducted as each module is integrated.
4. On completion of each set of tests, another stub is replaced with
the real module.
5. regression testing may conducted.
Pros and cons top-down integration:
- stub construction cost
- major control function can be tested early.

51. Topic: Software Integration Testing
Top-Down Integration
Main 1 3 2 M1 M2 M3 5 7 4 6 M4 M5 M6 M7 8
Select the integration sequence:
Depth-First
Breadth-First
- Left --> Right
- Right --> Left M8

52. Topic: Software Integration Testing
Top-Down Integration
Integration Order: Breadth-First (Left Order) IS: Integrated System Mi ’: software stub for Module Mi. Step #1: IS = Main + M1 (need: M2’, M3’, M4’ and M5’) Step #2: IS = IS + M2 (need: M4’, M5’, M6’, and M3’) Step #3: IS = IS + M3 (need: M4’, M5’, M6’, and M7’) Step #4: IS = IS + M4 (need: M5’, M6’,and M7’) Step #5: IS = IS + M5 (need: M8’, M6’, and M7’) Step #6: IS = IS + M6 (need: M7’, and M8’) Step #7: IS = IS + M7 (need: M8’) Step #8: IS = IS + M8

53. Bottom-Up Software Integration
Idea:- Modules at the lowest levels are integrated at first, then by moving upward through the control structure.
Integration process (five steps):
1. Low-level modules are combined into clusters that perform a specific software sub-function.
2. A driver is written to coordinate test case input and output.
3. Test cluster is tested.
4. Drivers are removed and clusters are combined moving upward in the program structure.
Pros and cons of bottom-up integration:
- no stubs cost
- need test drivers
- no controllable system until the last step

54. Bottom-Up Integration
Main 7 9 8 M1 M2 M3 6 4 5 3 M4 M5 M6 M7 2 1 M8

55. Object-Oriented Software Integration
There are a number of proposed integration test strategies for object-oriented software. One of them is known as Class Test Order. What is class test order? - It is a class test sequence order for a class library or an OO program.

56. A Class Test Order for Object-Oriented Programs
ButtonList
Sensor AG AS AS AG AS AS AS
Event
Scene
Button AS I AS I
TextButton
ButtonState
World AG I AS AS AS I
Subject
Control I
CanvasRep
Canvas AS I AS AS AS AS
MonoScene
InstructorItr
ControlState AG

57. A Class Test Order for Object-Oriented Programs
ButtonList
Sensor AG AS AS AG AS AS AS
Event
Scene
Button AS I AS I
TextButton
ButtonState
World AG I AS AS AS I
Subject
Control I
CanvasRep
Canvas AS I AS AS AS AS
MonoScene
InstructorItr
ControlState AG

58. A Class Test Order for Object-Oriented Programs3 4
4.1
ButtonList
Sensor AG
3.4 AS AS AG
3.3 AS AS AS
Event
Scene
Button
4.2 AS I
3.1 AS 2 I
TextButton
ButtonState
World AG 3
3.2 I AS AS AS I 1 I 1 2
1.1
Subject
5.2
Control I
CanvasRep
Canvas AS I AS AS AS AS
MonoScene 4
1.2
InstructorItr
ControlState
5.1 5 AG

59. System Testing
After completing Unit and Integration testing through white box testing techniques development team release an .exe build (all integrated module) to perform black box testing.
Usability Testing
Functional Testing
Performance Testing
Security Testing

60. System Testing
System testing is defined as testing the behavior of a system/software as per software requirement specification
Testing the fully integrated applications including external peripherals in order to check how components interact with one another
System testing enables us to test, Verify and validate both the business requirements as well as the applications architecture
The application is tested thoroughly to verify that it meets the technical and functional specifications

61. Entry criteria for system testing
Complete software system should be developed
Unit testing must be completed
Integration testing must be completed
Specifications for the product have been completed
Test scripts and schedules are ready

62. Exit criteria for system testing
Application meets all the document requirements and functionalities
Defects found during system testing should be fixed and closed
All the test cases for the system should be executed
No critical defects should be opened

63. How to write system test cases
The system test cases are written in a similar way as we write in functional test cases.
while creating system test cases we have to follow two points
System test cases must cover the use cases and scenarios
Must validate all types of requirements-UI, Functional, Technical, Non functional, Performance etc..

64. System testing vs. Integration testing
1. From requirement specification
1. From interface specification
2. No visibility of code
2. Visibility of integration structure
3.It is a high level testing
3. It is a low level testing
4. The complete system is configured in a controlled environment
4. Test cases are developed with the express purpose of exercising the interface between components

65. SYSTEM TESTING
The system as a whole is tested to uncover requirement errors.
Verifies that all system elements work properly and that overall system function and performance has been achieved.
Types:
Alpha Testing
Beta Testing
Acceptance Testing
Performance Testing

66. It is performed by a selected group of friendly customers.
Alpha Testing
It is carried out by the test team within the developing organization .
Beta Testing
It is performed by a selected group of friendly customers.
Acceptance Testing
It is performed by the customer to determine whether to accept or reject the delivery of the system.
Performance Testing
It is carried out to check whether the system meets the nonfunctional requirements identified in the SRS document.

67. Acceptance Testing
A formal test conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.
It is the final test action before deploying the software. The goal of acceptance testing is to verify that the software is ready and can be used by the end user to perform the functions for which the software was built.

68. Alpha Testing
The application is tested by the users who are going to use application.
Done at developer’s site under controlled conditions
Under the supervision of the developers.
Testing where user plays a role/user is required: User Acceptance Testing: In this type of testing, the software is handed over to the user in order to find out if the software meets the user expectations and works as it is expected to. Alpha Testing: In this type of testing, the users are invited at the development center where they use the application and the developers note every particular input or action carried out by the user. Any type of abnormal behavior of the system is noted and rectified by the developers. Beta Testing: In this type of testing, the software is distributed as a beta version to the users and users test the application at their sites. As the users explore the software, in case if any exception/defect occurs that is reported to the developers.

69. Beta Testing
This Testing is done before the final release of the software to end-users.
Before the final release of the software is released to users for testing where there will be no controlled conditions and the user here is free enough to do what ever he wants to do on the system to find errors.

70. What is Verification?
Verification is the process to make sure the product satisfies the conditions imposed at the start of the development phase.
to make sure the product behaves the way we want it to.

71. What is Validation?
Validation is the process to make sure the product satisfies the specified requirements at the end of the development phase.
to make sure the product is built as per customer requirements.

72. Difference between Verification And Validation
Verification is to check whether the software conforms to specifications.
It does not involve executing the code.
It is human based checking of documents and files.
Validation is to check whether software meet the customer requirements.
It always involves executing the code.
It is computer based execution of program.

73. Difference between Verification And Validation
Verification is done by development team to provide that the software is as per the specifications
It, generally, comes first-done before validation.
Validation is carried out with the involvement of client and testing team.
It generally follows after verification.

74. Thank You !!