Call Girls Wakad Call Me 7737669865 Budget Friendly No Advance Booking
DISE - Software Testing and Quality Management
1. Diploma in Software Engineering
Module VIII: Software Testing and
Quality Management
Rasan Samarasinghe
ESOFT Computer Studies (pvt) Ltd.
No 68/1, Main Street, Pallegama, Embilipitiya.
2. Contents
1. Introduction to Testing
2. Verification and Validation
3. Testing Methods
4. Black Box Testing
5. White Box Testing
6. Testing Strategy
7. Testing Stages
8. Unit Testing
9. Integration Testing
10. Bottom-up Integration
11. Top-Down Integration
12. Validation Testing
13. Alpha Testing
14. Beta Testing
15. System Testing
16. Recovery Testing
17. Security Testing
18. Stress Testing
19. Performance Testing
20. Test Case
21. Debugging
22. Testing, QA and QC
23. Quality Management
24. Quality Planning Process
25. Quality Assurance Process
26. Quality Control Process
3. Introduction to Testing
1. Testing is a process of executing a program with
the intent of finding an error.
2. A good test case is one that has a high
probability of finding an as yet undiscovered
error.
3. A successful test is one that uncovers an as yet
undiscovered error.
4. Verification and Validation
Verification - Set of activities which ensure software
correctly implements a given function.
“Are we building the product right?”
Validation - Set of activities which ensures software
that has been built satisfies customer requirements.
“Are we building the right product?”
6. Black Box Testing
Black box testing is a testing technique that ignores
the internal mechanism of the system and focuses
on the output generated against any inputs of the
system.
7. White Box Testing
White box testing is a testing technique that
investigate the internal logic and structure of the
code in detail.
8. Black Box Testing and White Box Testing Comparison
Black Box Testing White Box Testing
Internal Workings of an application are
not required to be known
Tester has full knowledge of the Internal
workings of the application
Also known as closed box testing, data
driven testing and functional testing
Also known as glass box testing, structural
testing or code based testing
Performed by testers and developers and
also by end users
Normally done by testers and developers
Based on external expectations - Internal
behavior of the application is unknown
Internal workings are fully known and the
tester can design test data accordingly
Least time consuming and exhaustive The most exhaustive and time consuming
type of testing
Not suited to algorithm testing Suited for algorithm testing
Done by trial and error method Data domains and Internal boundaries can
be better tested
11. Unit Testing
• Refers to tests that verify the functionality of a
specific section of code at the function level.
• Performed by the developers before the setup is
handed over to the testing team.
12. Integration Testing
• In integration testing, individual software modules
are combined and tested as a group.
• Integration testing is verifying the interfaces
between components against a software design.
14. Bottom-up Integration
This testing begins with unit testing, followed by
tests of progressively higher-level combinations of
units called modules or builds.
15. Top-Down Integration
This testing, the highest-level modules are tested
first and progressively lower-level modules are
tested after that.
16. Validation Testing
• Validation testing ensure software functions in a
manner that can be reasonably expected by the
customer.
• Like all other testing steps, validation tries to
uncover errors, but the focus is at the requirements
level on things that will be immediately apparent to
the end-user.
17. Alpha Testing
• The alpha test is conducted at the developer's site
by a customer.
• The software is used in a natural setting with the
developer "looking over the shoulder" of the user
and recording errors and usage problems.
• Alpha tests are conducted in a controlled
environment.
18. Beta Testing
• The beta test is conducted at one or more
customer sites by the end-user of the software.
• Unlike alpha testing, the developer is generally
not present.
• The customer records all problems that are
encountered during beta testing and reports
these to the developer at regular intervals.
19. System Testing
System testing validates software once it has been
incorporated into a large computer system.
(hardware, people, information)
20. System Testing
System Testing includes the following tests.
• Recovery Testing
• Security Testing
• Stress Testing
• Performance Testing
All these tests are fallen down into the category
non-functional testing.
21. Recovery Testing
Recovery testing is the activity of testing how well
an application is able to recover from crashes,
hardware failures and other similar problems.
22. Security Testing
Security testing verifies that the protection
mechanism built on the system successfully prevents
unauthorized access to the system.
23. Stress Testing
During stress testing, the system is monitored after
subjecting the system to heavy load, frequency or
volume to ensure that the system can sustain the
stress.
24. Performance Testing
Performance testing is designed to test the runtime
responsiveness, stability and resource usage of
software within the context of an integrated
system.
25. Test Case
Test cases involve the set of steps, conditions and inputs
which can be used while performing the testing tasks.
A. Test Case ID
B. Test Scenario
C. Test Case Description
D. Test Steps
E. Prerequisites
F. Test Data
G. Expected Result
H. Actual Result
I. Comments
26. Test Cases Example
We need to check an input field that can accept
maximum of 10 characters.
Scenario Test Steps Expected Result Actual Outcome
Verify that the
input field that
can accept
maximum of 10
characters
Login to
application and
enter 10
characters
Application
should be able
to accept all 10
characters.
Application
accepts all 10
characters.
Verify that the
input field that
cannot accept
more than 10
characters
Login to
application and
enter 11
characters
Application
should NOT
accept all 11
characters.
Application
accepts all 11
characters.
27. Debugging
• When a test case uncovers an error, debugging is
the process that removes the error.
• Debugging occurs as a consequence of successful
testing.
29. Testing, Quality Assurance and Quality Control
Quality Assurance Quality Control Testing
Activities for ensuring
quality in the
processes that develop
software.
Activities for
ensuring quality in
the software.
Activities which ensure
the identification of
error/defects in the
Software.
Process oriented
activities.
Product oriented
activities.
Product oriented
activities.
Preventive activities. Corrective process. Corrective process.
Everyone is
responsible
QA team is
responsible
QA team is responsible
QA is a managerial tool QC is a subset of
Quality Assurance.
Testing is a subset of
Quality Control.
30. Quality Management
Quality Management includes the processes
required to ensure that the project will satisfy the
needs for which it was undertaken.
Processes:
Quality Planning
Quality Assurance
Quality Control
31. Quality Planning Process
Quality Planning Process identifying which quality
standards are relevant to the project and
determining how to satisfy them.
32. Inputs for Quality Planning Process
• Quality policy - the overall intentions and
direction of an organization with regard to quality
• Scope statement.
• Product description.
• Standards and regulations - Application area
specific standards or regulations that may affect
the project.
• Other process outputs.
33. Tools and Techniques for Quality Planning Process
• Benefit/cost analysis.
• Benchmarking - comparing one's business
processes and performance metrics to best
practices from other companies.
• Flowcharting.
• Design of experiments - analytical technique
which helps identify which variables have the
most influence on the overall outcome.
35. Quality Planning Process Outputs
• Quality management plan - describe how the
project management team will implement its
quality policy.
• Operational definitions - what something is and
how it is measured by the quality control process.
• Checklists - set of required steps has been
performed.
• Inputs to other processes.
36. Quality Assurance Process
Quality Assurance Process evaluating overall project
performance on a regular basis to provide
confidence that the project will satisfy the relevant
quality standards.
37. Inputs for Quality Assurance Process
• Quality management plan.
• Results of quality control measurements -
records of quality control testing and
measurement.
• Operational definitions.
38. Tools and Techniques for Quality Assurance Process
• Quality planning tools and techniques.
• Quality audits - structured review of other quality
management activities.
39. Quality Assurance Process Outputs
• Quality improvement - taking action to increase
the effectiveness and efficiency
40. Quality Control Process
Quality Control Process monitoring specific project
results to determine if they comply with relevant
quality standards and identifying ways to eliminate
causes of unsatisfactory performance.
41. Inputs for Quality Control Process
• Work results - both process results and product
results.
• Quality management plan.
• Operational definitions.
• Checklists.
42. Tools and Techniques for Quality Control Process
• Inspection - activities such as measuring, examining
and testing to determine whether results conform to
requirements.
• Control charts - graphic display of the results of a
process over time.
• Pareto diagrams - histogram, ordered by frequency of
occurrence that shows how many results were
generated by type or category of identified cause.
• Statistical sampling - eg: selecting ten engineering
drawings at random from a list.
• Flowcharting.
• Trend analysis - using mathematical techniques to
forecast future outcomes based on historical results.
44. Quality Control Process Outputs
• Quality improvement.
• Acceptance decisions - items inspected will be
either accepted or rejected.
• Rework - action taken to bring a defective item
into compliance with requirements.
• Completed checklists.
• Process adjustments - immediate corrective or
preventive action
Integration follows the pattern illustrated in Figure 18.7. Components are com-
bined 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. Similarly,
driver D3 for cluster 3 is removed prior to integration with module Mb. Both Ma and
Mb will ultimately be integrated with component Mc, and so forth.
Referring to Figure 18.6, depth-first integration would integrate all components on
a major control path of the structure. Selection of a major path is somewhat arbitrary
and depends on application-specific characteristics. For example, selecting the left-
hand path, components M1, M2 , M5 would be integrated first. Next, M8 or (if neces-
sary for proper functioning of M2) M6 would be integrated. Then, the central and right-
hand control paths are built. Breadth-first integration incorporates all components
directly subordinate at each level, moving across the structure horizontally. From the
figure, components M2, M3, and M4 (a replacement for stub S4) would be integrated
first. The next control level, M5, M6, and so on, follows.
Examples of recovery testing:
While an application is running, suddenly restart the computer, and afterwards check the validness of the application's data integrity.
While an application is receiving data from a network, unplug the connecting cable. After some time, plug the cable back in and analyze the application's ability to continue receiving data from the point at which the network connection disappeared.
Restart the system while a browser has a definite number of sessions. Afterwards, check that the browser is able to recover all of them.
Open Source/Free Security Testing Tools:
FxCop
FindBugs
FlawFinder
Ramp Ascend
Reasons for conducting Stress Testing:
It allows the test team to monitor system performance during failures.
To verify if the system has saved the data before crashing or NOT.
To verify if the system prints meaning error messages while crashing or did it print some random exceptions.
To verify if unexpected failures do not cause security issues.
Stress testing is a software testing activity that determines the robustness of software by testing beyond the limits of normal operation. Stress testing is particularly important for "mission critical" software, but is used for all types of software. Stress tests commonly put a greater emphasis on robustness, availability, and error handling under a heavy load, than on what would be considered correct behavior under normal circumstances.
Performance Testing Tools
Jmeter - http://jmeter.apache.org/
Open STA - http://opensta.org/
Load Runner - http://www.hp.com/
Web Load - http://www.radview.com/
In software engineering, performance testing is in general testing performed to determine how a system performs in terms of responsiveness and stability under a particular workload. It can also serve to investigate, measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage.
Performance testing is a subset of performance engineering, an emerging computer science practice which strives to build performance into the implementation, design and architecture of a system.
Regression testing is the process of testing changes to computer programs to make sure that the older programming still works with the new changes.
Design of experiments.
e.g., automotive de-
signers might wish to determine which combination of suspension and tires will pro-
duce the most desirable ride characteristics at a reasonable cost
Operational definitions it is not enough to say that meeting the planned schedule dates is a measure of
management quality; the project management team must also indicate whether every
activity must start on time, or only finish on time;
The quality planning tools and techniques
described in Section 8.1.2 can be used for quality assurance as well.