SlideShare a Scribd company logo
Testing and Evaluating
     Software Design and Development
            Chapter 6 summary
Contents
Testing the Software
 Comparison of the Solution with the original Design
  Specification
 Generating relevant Test Data for Complex Solutions
 Levels of Testing
 Live Test Data
 Benchmarking
 Quality Assurance

Reporting on the Testing Process
 Documentation
 Communication
Testing the Software Solution
Testing is carried out to find errors

Software developers must continually ensure that the original specifications
are being met in the software product being developed

Construction of appropriate test data and adequate testing prevents the
occurrence of major problems in the finished program that are expensive to
fix.

Test data must be sufficient to ensure the program is completely operational
and free of logic errors.

Test data must be constructed to test every part of a program, including the
mainline of the program and any modules used by the program.
What should be tested?
Test data should test

   All parts of the program

   Each path of execution - test data should be sufficient to test the
    termination and correct exit of each loop. To test each path in nested If
    statement / CASE structure.

   Boundary conditions - the values of variables or expressions that
    determine the choice of available options to be taken. example


At the very minimum to execution paths should always be tested rather than
boundary conditions. Large programs should be tested using other testing
mechanisms.

Testing should include :Unit testing, program testing and system testing
Unit or Module Testing
Structured programming results in modules, each of which can be tested individually

Subprograms can be tested as a black box where data is entered and results are shown.

In black box testing, only the inputs and outputs are checked. The processes that achieve
these results are ignored.

Subprograms can also be tested as a white box where the algorithm of the subprogram is
understood and each path of execution can be tested appropriately.

White box testing examines all the data paths in a module.

A driver program may be developed to test modules in a program. The driver substitutes for
the main program, calling the subprogram and supplying the necessary values for any
variables.

A driver is a temporary section of code that is created to test an individual procedure or
module by calling it up and executing it.
Program Testing
It is a minimum requirement that the test data tests each logical pathway and program
branch that can be entered.

All modules are called and executed at least once or when expected

This way, the entire program can be completely tested.

Screen elements such as menus and buttons must be tested to ensure they are
functioning correctly.
System Testing
During system testing, the program is tested in a variety of operating environments.


The software may function in the development system or a controlled environment
however, when implemented on the users computer, problems may arise.


The effect of hardware, operating systems and other software may create errors that
have not been previously detected.


System testing is carried out to detect errors at the software / hardware interface,


Carried out by users rather than developers. System tests treat the program as a black
box.
Live Test Data
Live data is real data, used to ensure that a program works under real-life
conditions.


Real data is supplied by the client or can be generated by CASE tools.


Stress testing involves increasing the load on a program in an attempt to make it fail.


Live Test Data should include:

    Larger File Sizes

    Mix of Transaction Types

    Response Times

    Volume data

    Interfaces between Modules

    Comparison with Program Test Data
Live data is used to ensure that the system response times are appropriate. Response times
are dependent on all the system components, together with their interactions with each other
and other processes that may be occurring concurrently. Response times should be tested
on minimum hardware using typical data of different types.

Interface tests will ensure that the correct numbers of parameters are sent to and from the
module and that the format is correct. Interface tests will also detect conflicts between local
and global variables.


A variety of different transaction types and sequences of data entry should be tested with live
data. Module and program testing usually involve testing specific transactions or processes
one at a time. During system testing, transactions occur in random order and checked to see
if any errors arise

Software developers generate test data to test the limits of the system that may not be tested
under normal use. (to ensure the system has scalability)

A program developed to access files should be tested with a range of file types and sizes.
The use of large files will highlight problems associated with data access.
Benchmarking
A benchmark is a standard against which performance of a computer program can be
assessed against expected outcomes and other similar products on the market.

Established programs are often used as a benchmark to indicate the quality and
performance expectations of a new product.

Benchmarks allow users of software products to make informed purchasing decisions
Quality Assurance
Quality Assurance is a set of procedures used to certify that a generated product meets specified
criteria with respect to quality and reliability.

     Correctness - Does it do what it is supposed to do?

     Reliability - Does it do it all of the time?

     Efficiency - Does it do it the best way possible?

     Integrity - Is it secure?

     Maintainability - Can it be understood?

     (CREIM)


Quality Assurance is not just about testing a product once it has been completed. Its about
periodically performing inspections, reviews and tests on the system being developed.


Quality assurance techniques should be implemented throughout the software development
process.
Alpha & Beta Testing
Alpha Testing
   Testing of the final solution by personnel within the software
    development company prior to the product’s release.
   The client uses the system in a controlled environment and checks to see
    if it meets their requirements.


Beta Testing(Acceptance Testing)
   Testing of the final solution by a limited number of users outside the
    software development company using real world data and conditions.
   The program is given to a number of potential clients who will also report
    to the developers any problems they encounter in the program.
Reporting on the Testing Process
Required Documentation
 A test data table should be created to show the test data to be used
   and the reason why this item of test data was selected.
 Test requirements - What needs to be tested?
 Test plan - How do we implement these tests?
 Test data and expected results - What are the necessary inputs and
   the expected outputs?
 Test results - Do the actual results match the expected results?
 Recommendations - What needs to be done now
A desk-check table is used to document the test data
used and compare the expected output with the actual
output of the algorithm or program.

CASE Tools that aid in the testing process:
 Tools to generate or acquire data to be used during
  testing
 Tools that analyse the source code
 Simulation tools to mimic the roles of hardware or
  other software that interacts with the program
Communication
Independent testers are less likely to approach the program with
preconceptions.

It is essential that the user is provided with the opportunity to evaluate the
solution that has been developed.

Results of the testing provides an opportunity for the users to evaluate and
discuss the functionality of the new system.

Alpha and Beta testing help to provide users with the opportunity to use the
program.

After the customer has approved a program, it can be released to the general
market.
The End
Boundary Conditions
CASEWHERE age is

   <=3: output “Too young for school”
   <=18: output “Could be at school”
   OTHERWISE: output “Too old for school”

ENDCASE

An appropriate set of data could therefore be

                2      3       18     20.
                                                Back
Black box Testing




                    Back
White box Testing




                    Back

More Related Content

PDF
Why use Frontify?
PPTX
Non-destructive Testing
PPT
12 sdd lesson testing and evaluating
PPT
Testing Software Solutions
PPT
Software Testing
PPT
Defect Testing in Software Engineering SE20
PDF
Why use Frontify?
Non-destructive Testing
12 sdd lesson testing and evaluating
Testing Software Solutions
Software Testing
Defect Testing in Software Engineering SE20

Similar to Sdd Testing & Evaluating (20)

DOC
Testing
DOCX
Faq
PPT
Software Engineering Lec 10 -software testing--
PDF
testing.pdf
PDF
SWE-401 - 10. Software Testing Overview
PDF
10. Software testing overview
PPT
Software Testing
PDF
Glossary of Testing Terms and Concepts
PPT
Types of Software Testing
PPTX
Software testing
PPTX
Software Testing
PPT
Testing Presentation
PPTX
Structured system analysis and design
DOC
PPTX
19 Software Testing Techniques presentation file.pptx
PPTX
Software techniques
PDF
Software testing
PPTX
PPSX
Introduction to software testing
PPTX
Software testing introduction
Testing
Faq
Software Engineering Lec 10 -software testing--
testing.pdf
SWE-401 - 10. Software Testing Overview
10. Software testing overview
Software Testing
Glossary of Testing Terms and Concepts
Types of Software Testing
Software testing
Software Testing
Testing Presentation
Structured system analysis and design
19 Software Testing Techniques presentation file.pptx
Software techniques
Software testing
Introduction to software testing
Software testing introduction
Ad

More from mary_ramsay (12)

PDF
Circumference of a Circle
PDF
RWG 5 For Mac Training Guide
PDF
Sdd HSC Summary
PDF
All meta languages
PDF
Sdd metalanguage
PDF
The role of the cpu in the operation
PDF
Sorting & Extracting Data
PDF
SQL Structure Query Language
PDF
URL_universal Resourse Locator
PDF
IPT Assessment Schedule 2012
PDF
IPT HSC Summary
PDF
Normalisation student summary
Circumference of a Circle
RWG 5 For Mac Training Guide
Sdd HSC Summary
All meta languages
Sdd metalanguage
The role of the cpu in the operation
Sorting & Extracting Data
SQL Structure Query Language
URL_universal Resourse Locator
IPT Assessment Schedule 2012
IPT HSC Summary
Normalisation student summary
Ad

Recently uploaded (20)

PDF
Review of recent advances in non-invasive hemoglobin estimation
PDF
Building Integrated photovoltaic BIPV_UPV.pdf
PPTX
Programs and apps: productivity, graphics, security and other tools
PDF
Advanced methodologies resolving dimensionality complications for autism neur...
PPT
“AI and Expert System Decision Support & Business Intelligence Systems”
PDF
Agricultural_Statistics_at_a_Glance_2022_0.pdf
PDF
How UI/UX Design Impacts User Retention in Mobile Apps.pdf
PPT
Teaching material agriculture food technology
PDF
Approach and Philosophy of On baking technology
PDF
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
PDF
MIND Revenue Release Quarter 2 2025 Press Release
PDF
Diabetes mellitus diagnosis method based random forest with bat algorithm
PDF
Mobile App Security Testing_ A Comprehensive Guide.pdf
PDF
Empathic Computing: Creating Shared Understanding
PPTX
Detection-First SIEM: Rule Types, Dashboards, and Threat-Informed Strategy
PDF
Reach Out and Touch Someone: Haptics and Empathic Computing
PPTX
Digital-Transformation-Roadmap-for-Companies.pptx
PDF
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
PDF
Spectral efficient network and resource selection model in 5G networks
PDF
Encapsulation theory and applications.pdf
Review of recent advances in non-invasive hemoglobin estimation
Building Integrated photovoltaic BIPV_UPV.pdf
Programs and apps: productivity, graphics, security and other tools
Advanced methodologies resolving dimensionality complications for autism neur...
“AI and Expert System Decision Support & Business Intelligence Systems”
Agricultural_Statistics_at_a_Glance_2022_0.pdf
How UI/UX Design Impacts User Retention in Mobile Apps.pdf
Teaching material agriculture food technology
Approach and Philosophy of On baking technology
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
MIND Revenue Release Quarter 2 2025 Press Release
Diabetes mellitus diagnosis method based random forest with bat algorithm
Mobile App Security Testing_ A Comprehensive Guide.pdf
Empathic Computing: Creating Shared Understanding
Detection-First SIEM: Rule Types, Dashboards, and Threat-Informed Strategy
Reach Out and Touch Someone: Haptics and Empathic Computing
Digital-Transformation-Roadmap-for-Companies.pptx
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
Spectral efficient network and resource selection model in 5G networks
Encapsulation theory and applications.pdf

Sdd Testing & Evaluating

  • 1. Testing and Evaluating Software Design and Development Chapter 6 summary
  • 2. Contents Testing the Software  Comparison of the Solution with the original Design Specification  Generating relevant Test Data for Complex Solutions  Levels of Testing  Live Test Data  Benchmarking  Quality Assurance Reporting on the Testing Process  Documentation  Communication
  • 3. Testing the Software Solution Testing is carried out to find errors Software developers must continually ensure that the original specifications are being met in the software product being developed Construction of appropriate test data and adequate testing prevents the occurrence of major problems in the finished program that are expensive to fix. Test data must be sufficient to ensure the program is completely operational and free of logic errors. Test data must be constructed to test every part of a program, including the mainline of the program and any modules used by the program.
  • 4. What should be tested? Test data should test  All parts of the program  Each path of execution - test data should be sufficient to test the termination and correct exit of each loop. To test each path in nested If statement / CASE structure.  Boundary conditions - the values of variables or expressions that determine the choice of available options to be taken. example At the very minimum to execution paths should always be tested rather than boundary conditions. Large programs should be tested using other testing mechanisms. Testing should include :Unit testing, program testing and system testing
  • 5. Unit or Module Testing Structured programming results in modules, each of which can be tested individually Subprograms can be tested as a black box where data is entered and results are shown. In black box testing, only the inputs and outputs are checked. The processes that achieve these results are ignored. Subprograms can also be tested as a white box where the algorithm of the subprogram is understood and each path of execution can be tested appropriately. White box testing examines all the data paths in a module. A driver program may be developed to test modules in a program. The driver substitutes for the main program, calling the subprogram and supplying the necessary values for any variables. A driver is a temporary section of code that is created to test an individual procedure or module by calling it up and executing it.
  • 6. Program Testing It is a minimum requirement that the test data tests each logical pathway and program branch that can be entered. All modules are called and executed at least once or when expected This way, the entire program can be completely tested. Screen elements such as menus and buttons must be tested to ensure they are functioning correctly.
  • 7. System Testing During system testing, the program is tested in a variety of operating environments. The software may function in the development system or a controlled environment however, when implemented on the users computer, problems may arise. The effect of hardware, operating systems and other software may create errors that have not been previously detected. System testing is carried out to detect errors at the software / hardware interface, Carried out by users rather than developers. System tests treat the program as a black box.
  • 8. Live Test Data Live data is real data, used to ensure that a program works under real-life conditions. Real data is supplied by the client or can be generated by CASE tools. Stress testing involves increasing the load on a program in an attempt to make it fail. Live Test Data should include:  Larger File Sizes  Mix of Transaction Types  Response Times  Volume data  Interfaces between Modules  Comparison with Program Test Data
  • 9. Live data is used to ensure that the system response times are appropriate. Response times are dependent on all the system components, together with their interactions with each other and other processes that may be occurring concurrently. Response times should be tested on minimum hardware using typical data of different types. Interface tests will ensure that the correct numbers of parameters are sent to and from the module and that the format is correct. Interface tests will also detect conflicts between local and global variables. A variety of different transaction types and sequences of data entry should be tested with live data. Module and program testing usually involve testing specific transactions or processes one at a time. During system testing, transactions occur in random order and checked to see if any errors arise Software developers generate test data to test the limits of the system that may not be tested under normal use. (to ensure the system has scalability) A program developed to access files should be tested with a range of file types and sizes. The use of large files will highlight problems associated with data access.
  • 10. Benchmarking A benchmark is a standard against which performance of a computer program can be assessed against expected outcomes and other similar products on the market. Established programs are often used as a benchmark to indicate the quality and performance expectations of a new product. Benchmarks allow users of software products to make informed purchasing decisions
  • 11. Quality Assurance Quality Assurance is a set of procedures used to certify that a generated product meets specified criteria with respect to quality and reliability. Correctness - Does it do what it is supposed to do? Reliability - Does it do it all of the time? Efficiency - Does it do it the best way possible? Integrity - Is it secure? Maintainability - Can it be understood? (CREIM) Quality Assurance is not just about testing a product once it has been completed. Its about periodically performing inspections, reviews and tests on the system being developed. Quality assurance techniques should be implemented throughout the software development process.
  • 12. Alpha & Beta Testing Alpha Testing  Testing of the final solution by personnel within the software development company prior to the product’s release.  The client uses the system in a controlled environment and checks to see if it meets their requirements. Beta Testing(Acceptance Testing)  Testing of the final solution by a limited number of users outside the software development company using real world data and conditions.  The program is given to a number of potential clients who will also report to the developers any problems they encounter in the program.
  • 13. Reporting on the Testing Process Required Documentation  A test data table should be created to show the test data to be used and the reason why this item of test data was selected.  Test requirements - What needs to be tested?  Test plan - How do we implement these tests?  Test data and expected results - What are the necessary inputs and the expected outputs?  Test results - Do the actual results match the expected results?  Recommendations - What needs to be done now
  • 14. A desk-check table is used to document the test data used and compare the expected output with the actual output of the algorithm or program. CASE Tools that aid in the testing process:  Tools to generate or acquire data to be used during testing  Tools that analyse the source code  Simulation tools to mimic the roles of hardware or other software that interacts with the program
  • 15. Communication Independent testers are less likely to approach the program with preconceptions. It is essential that the user is provided with the opportunity to evaluate the solution that has been developed. Results of the testing provides an opportunity for the users to evaluate and discuss the functionality of the new system. Alpha and Beta testing help to provide users with the opportunity to use the program. After the customer has approved a program, it can be released to the general market.
  • 17. Boundary Conditions CASEWHERE age is <=3: output “Too young for school” <=18: output “Could be at school” OTHERWISE: output “Too old for school” ENDCASE An appropriate set of data could therefore be 2 3 18 20. Back