1. Chapter 2: Testing throughout the software life cycle

2. Software Development Models
Testing does not exist in isolation; test activities are related to software development activities.
Different development life cycle models need different approaches to testing.
The way testing is organized must fit the development life cycle or it will fail to deliver its benefits.
Software development life cycle models describe phases of the software development life cycle and the order in which those phases are tested. There are a number of software development models and many companies adopt their own, but all have similar patterns.
Verification is concerned with evaluating a work product, component or system to determine whether it meets the requirements set. In fact, verification focuses on the question 'is the deliverable built according to the specification?‟
Validation is concerned with evaluating a work product, component or system to determine whether it meets the user needs and requirements. Validation focuses on the question 'Is the deliverable fit for purpose, e.g. does it provide a solution to the problem?

3. Software Development Models
The Waterfall Model
The V- Model
The Iterative - Incremental Model
The Agile Model
The scrum Model

4. Software Development Models
The Waterfall Model
Was one of the earliest models to be designed.
It has a natural timeline where tasks are executed in a sequential fashion.
It shows that at first we gather the requirements for the system, then we design the technical details, then we write the code and then we test it.
Drawbacks - Dangers
Testing only happens after coding is completed.
Example
Governmental projects could take 3 years !!
Recommendations
Each development phase must have a corresponding testing phase
Test must start as early as possible .

5. Software Development Models
V-model
Provides guidance that testing needs to begin as early as possible in the life cycle
Shows that testing is not only an execution-based activity.
There are a variety of activities that need to be performed before the end of the coding phase.
Testing activities should be carried out in parallel with development activities
Testers need to work with developers and business analysts so they can perform these activities and tasks and produce a set of test deliverables
The V-model is a model that illustrates how testing activities (verification and validation) can be integrated into each phase of the life cycle.
The V-model, validation testing takes place especially during the early stages, e.g. reviewing the user requirements, and late in the life cycle, e.g. during user acceptance testing

6. Software Development Models
The Iterative Model
the process of establishing requirements, designing, building and testing a system, done as a series of shorter development cycles.
Examples are: prototyping, Rapid Application Development (RAD), Rational Unified Process (RUP) and agile development models
A common feature of iterative approaches is that the delivery is divided into increments or builds with each increment adding new functionality.
The increment produced by iteration may be tested at several levels as part of its development.
An increment, added to others developed previously, forms a growing partial system, which should also be tested.

7. Software Development Models
The Agile Model
Agile SDLC model is a combination of iterative and incremental process models with focus on process adaptability and customer satisfaction by rapid delivery of working software product. Agile Methods break the product into small incremental builds. These builds are provided in iterations.

8. Software Development Models
The Scrum Model
The Scrum model suggests that projects progress via a series of sprints. In keeping with an agile methodology, sprints are time boxed to no more than a month long, most commonly two weeks.

9. Testing within a life cycle model
In summary, whichever life cycle model is being used, there are several characteristics of good testing:
• For every development activity there is a corresponding testing activity.
• Each test level has test objectives specific to that level.
• The analysis and design of tests for a given test level should begin during the corresponding development activity.
• Testers should be involved in reviewing documents as soon as drafts are available in the development cycle.

10. Test Levels Component / Unit Testing Integration Testing
System Testing
Acceptance Testing

11. Test Levels Component testing Test basis: Component requirements
Detailed design
Code
Typical test objects:
Components
Programs
Database modules
Responsibility:
Developers
Stub: A stub is called from the software component to be tested. As shown in the diagram below ‘Stub’ is called by ‘component A’.
Driver: A driver calls the component to be tested. As shown in the diagram below ‘component B’ is called by the ‘Driver’.
Example : Login - Home, User.
Stub : Login is ready / Home , user are not .
Driver : Home , User are ready / login is not

12. Test Levels Integration testing Test basis: Software and system design
Architecture
Workflows
Use cases
Typical test objects:
Sub-systems database implementation
Infrastructure
Interfaces
Example : Testing what will happen if the username & password are valid
Expected Results : User’s home page is displayed with label “Hello User!”
Responsibility:
Developers

13. Test Levels Integration testing Integration Levels :
Component integration testing tests the interactions between software components and is done after component testing
System integration testing tests the interactions between different systems and may be done after system testing.
The greater the scope of integration, the more difficult it becomes to isolate defect to a specific component or system, which may lead to increased risk and additional time for troubleshooting.
Integration Testing Techniques
Top – Down integration
Button – Up integration
Big Bang integration
الانفجار الكونى

14. Test Levels System testing Test basis: Software and system design
Architecture
Workflows
Use cases
Typical test objects:
Sub-systems database implementation
Infrastructure
Interfaces.
Responsibility:
An independent test team often carries out system testing.

15. Test Levels System testing
Concerned with the behaviour of a whole system/product.
The testing scope shall be clearly addressed in the Master and/or Level Test Plan for that test level.
The test environment should correspond to the final target or production environment as much as possible in order to minimize the risk of environment-specific failures not being found in testing.
May include tests based on:
Business processes.
Use cases.
Other high level text descriptions or models of system behaviour.
Interactions with the operating system, and system resources.
Should investigate functional and non-functional requirements of the system, and data quality characteristics.

16. Test Levels Acceptance testing
When the development organization has performed its system test and has corrected all or most defects, the system will be delivered to the user or customer for acceptance testing.
Test basis:
User requirements.
System requirements.
Use cases.
Business processes.
Risk analysis reports.
Typical test objects:
System, user and operation manuals
System configuration
Responsibility:
Customers or users of a system.
Other stakeholders may be involved as well.

17. Test Levels Acceptance testing
Acceptance testing goal is to establish confidence in the system, part of the system or specific non-functional characteristics, e.g. usability, of the system.
Finding defects is not the main focus in acceptance testing.
Acceptance testing may assess the system's readiness for deployment and use, although it is not necessarily the final level of testing.
Types
Operational Testing
Contract & Regulation Testing
Alpha & Beta Testing
the Alpha testing which is performed at the developing organization’s site but not by the developing team.
the Beta testing, or field-testing, is performed by customers or potential customers at their own locations.
Fig : Alpha & beta

18. Test Types
Functional Testing : function to be performed by the software
Non – Functional Testing : characteristic, such as reliability or usability
Structural Testing : The structure or architecture of the software or system
Change related : i.e. confirming that defects have been fixed (confirmation testing) and looking for unintended changes (regression testing).

19. Test Types Testing of function (functional testing)
The function of a system (or component) is 'what it does'. This is typically described in a requirements specification, a functional specification, or in use cases.
Requirements-based testing uses a specification of the functional requirements for the system as the basis for designing tests.
- We should also prioritize the requirements based on risk criteria; this will ensure that the most important and most critical tests are included in the testing effort.
Business-process-based testing uses knowledge of the business processes. Business processes describe the scenarios involved in the day-to-day business use of the system.
- Use cases are a very useful basis for test cases from a business perspective.
- The techniques used for functional testing are often specification-based
- Test conditions and test cases are derived from the functionality of the component or system.

20. Test Types Testing of function (functional testing) - Types
Smoke Testing
Sanity Testing
Security Testing
Interoperability Testing
Smoke Testing is a kind of Software Testing performed after software build to ascertain that the critical functionalities of the program is working fine
Sanity Testing is done to check the new functionality / bugs have been fixed to be ready for more strong testing (Pre Regression) .
Security testing, investigates the functions (e.g., a firewall) relating to detection of threats, such as viruses, from malicious outsiders
Interoperability Testing is the ability of different information technology systems and software applications to communicate, exchange data, and use the information that has been exchanged.

21. Test Types Non – Functional Testing
A second target for testing is the testing of the quality characteristics, or non-functional attributes of the system.
Performance
The degree to which a system or component accomplishes its
designated functions within given constraints regarding processing
time and throughput rate.
Load
A test type concerned with measuring the behaviour of a component or system with increasing load, e.g. number of parallel users and/or numbers of transactions to determine what load can be handled by the component or system.
Stress
Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements.
Usability
Testing to determine the extent, to which the software product is understood, easy to learn, easy to operate and attractive to the users under specified conditions.

22. Test Types Structural Testing
The third target of testing is the structure of the system or component.
Structural (white-box) testing may be performed at all test levels, although it is true to say that it tends to be mostly applied at component and component integration
Structural testing approaches can also be applied at system, system integration or acceptance testing levels (e.g., to business models or menu structures).
Structural testing may be based on the architecture of the system .
Structural testing is often referred to as 'white-box' because we are interested in what is happening “inside the box” (system code or back end).

23. Test Types Change Related Testing Confirmation testing:
When a test fails and we determine that the cause of the failure is a software defect, the defect is reported, and we can expect a new version of the software that has had the defect fixed. In this case we will need to execute the test again to confirm that the original defect has been successfully removed. This is known as confirmation testing (also known as re-testing).
Regression testing:
The repeated testing of an already tested program, after modification, to discover any defects introduced or uncovered as a result of the change(s).
Regression testing may be performed at all test levels, and includes functional, non-functional and structural testing.

24. Maintenance Testing
Maintenance testing is done on an existing operational system, and is triggered by modifications, migration, or retirement of the software or system.
A) Modifications include:
Planned enhancement changes (e.g., release-based).
Corrective and emergency changes.
Changes of environment, such as planned operating system or database upgrades.
Planned upgrade of Commercial-Off-The-Shelf software (COTS), or patches to correct newly exposed or discovered vulnerabilities of the operating system.
B) Migrations:
Maintenance testing for migration (E.g., from one platform to another) should include operational tests of the new environment as well as of the changed software.
When data from another application will be migrated into the system being maintained.
C) Retirement of a system:
Maintenance testing for the retirement of a system may include the testing of data migration or archiving if long data-retention periods are required.