Professional Documents
Culture Documents
The process consisting of all life cycle activities, both static and dynamic, concerned with
Planning, Preparation and evaluation of software products and related work products
to determine that they satisfy specified requirements, to demonstrate that they are fit
for purpose and to detect defects.
TESTING PRINCIPLE:-
Defects (bug, faults):- A flaw in a component or system that can cause the
component or the system to fail to perform its required function. A defect
encountered during the execution, may cause a failure to component
or system.
Failure: Deviation of the component or system from its expected delivery, service or
result.
Defects in software , systems or documents may results in failure , but not all do cause
failures.
It is not just defects that give rise to failure. Failures can caused by :
When we think about what might go wrong we have to consider defects and failures
arising from:
The cost of finding and fixing defects rises considerably across the life cycle
If an error is made and consequent defect is detected in the requirements at the
Specification stage , then it is relatively cheap to find and fix and then specification
can be corrected and re-issued.
If the defects detected in the design stage then the design can be corrected and
re-issued with relatively little expenses.
If the defect is introduced in the requirement , specification and it is not detected
Until accepatance testing or even once the system has been implemented then
it will be much more expensive to fix.
Instead of exhaustive testing, we use risks and priorities to focus testing efforts.
Pressures on a project include time and budget as well as pressure to deliver technical
solution that meets customer needs.
Customer and project manager will want to spend an amount on testing the produces
Return on Investments for them.
How much testing is enough is according to level of risk, technical and business Risks related
to product and project
Detect Defects:
Help us understand the risks associated with putting the software into
operational .
Fixing the defects improves the quality of the products. Identifying the
defects has another benefits to improve the development process and
make fewer mistakes in future work.
When can we meet our test objective? (Test principle – Early Testing)
Fousing on defects can helps us plan our tests --- (Testing Principle – Defect clustering)
Main focus of reviews and other static tests is to carry out testing as early as possible
finding and fixing defects are more cheaply and preventing defects from appearing
at later stages of this project. These activites helps us find out about defects earlier
and identify potential clusters.
Debugging : The process of finding , analyzing and removing the causes of failures in
software.
TEST PLANNING
Determine the scope and risks and identify the objectives of testing
Determine the test approach (techniques, test items, coverage,testware) .
Implement the test policy and the test strategy.
Determine the required resources
Schedule test analysis and design tasks,test implementation ,execution and evaluation
Determine the exit criteria
TEST CONTROL
Measure and analyze the results of reviews and testing .
Monitor and document progress,test coverage and exit criteria.
Provide information on testing.
Initiate corrective actions
Make decisions.
IMPLEMENTATION:
Develop and prioritize our test cases.
Create the test suites from the test cases for efficient test execution.
EXECUTION:
Execute the test suites and individual test cases.
Log the outcome of test execution and record the identities and version, test tools and
testwares.
Compare the actual results with expected results
Repeat the activities as a result of action taken for each discrepancy.
PSYCHOLOGY OF TESTING.
We need to be careful when we are reviewing and when we are testing.
Explain that by knowing about this now we can work round it or fix it so the
delivered the system is better for the customer.
Start with collaboration rather than battles. Remind everyone common goal
of better quality system.
CHAPTER 2: TESTING THROUGHOUT THE SOFTWARE LIFE
CYCLE
VALIDATION: To determine whether it meets the user needs ---Is the deliverable
Fit for purpose?.
V-MODEL
Water fall model was one of the earliest models to be designed . It has the
natural timeline where the tasks are executed in a sequential fashion.
Draw backs of this model is difficult to get feedback passed backwards up the
waterfalls and there are difficulties if we need to carry out numerous
iterations for a particular phase.
Component testing
Integration testing
System testing
Acceptance testing
Iterative life cycles
A common feature of iterative approaches is that the delivery is divided into
Increments or builds with each increments adding a new functionality.
Intial increment will contain infrastructure required to support the
build functionali\ty
Test Levels
Component Testing:
Also known as unit, module and program testing, that are separately testable.
Component testing may include testing of functionality and specific non-functional
Characteristics such as resource-behavior (e.g. memory leaks), performance or
Robustess testing as well as structural testing.
Integration Testing:
Integration testing tests interfaces between components, interactions to different
parts of system such as an operating system, file system and hardware or
interfaces between systems.
There may be more than one level of integration testing and it may carried
out on test objects of varying size.
Component integration testing tests the interaction between software components
and after component testing
System integration testing tests the interaction between the different systems and
may be done after system testing.
Top-down approach
Bottom- up approach
Functional incremental.
System Testing:
System testing is concerned with the behavior of the whole system/product as
defined by the scope of a development project or product.
System testing requires a controlled test environment with the regard to amongst
Others things, control of software versions, testware and the test data.
Acceptance Testing:
The goal of acceptance testing is to establish confidence in the system.
Acceptance testing is focuses on validation type of testing, determine whether
the system is fit for purpose. Finding defects should not be the main focus
in acceptance testing.
A Commercial off the Shelf (COTS) software product may be acceptance tested
when it is installed or integrated
Acceptance testing of the usability of a components may be done during the
component testing.
Acceptance testing of a new functional enhancement may come before system
testing.
Test Types:
Testing of function:
Functional testing considers the specified behavior and is often as referred as
Black- box testing.
Function testing can based upon ISO 9216, be done focusing on suitability
Interoperability, security, accuracy and compliance
Business- process- based testing uses knowledge of the business processes, which
describes the scenarios involved in day – to- day business use of the system.
Use cases are a very useful basis for test cases from business perspective.
The ISO 9216 standard defines Six quality characteristics and the subdivision
Regression testing
Testing of a previously tested program following modification to ensure that
defects have not been introduced or uncovered in unchanged areas of the
software as a result of the changes made. It is performed when the software or its
environment is changed.
Maintenance Testing:
Modification of a software product after delivery to correct defects, to improve
performance or other attributes or to adapt the product to the modified
environment .
Modifications:
Include to planned enhancement changes, corrective and emergency changes
and changes of environment(planned O/S or database upgrades, or patches to
newly exposed discovered vulnerabilities of O/S).
Migration:
Operational testing of the new environment, as well as the changed software.
Planned Modification:
Types of Planned Modification:
Perfective modification: - by supplying new functions or enhancing performance.
Adaptive modification :- adapting software to environmental changes such as
new hardware, new systems software or new legislations.
Corrective Modification :- deferrable corrections of defects.
During static testing, software work products are examined manually, or with a
Set of tools, but not executed.
The use of static testing and various advantages of reviews on software products:
Static testing can start early in the life cycle, early feedback on quality
Issues can be established.
By detecting defects at an early stage, rework of costs are most often
relatively low and relatively cheap improvement of software quality
Rework effort substantially reduced, development products figure likely to
increase.
The evaluation by a team has the additional advantage that there
exchage information between the participants.
Static tests contribute to an increased awareness of quality issues.
Planning:
In this phase the entry check is carried out to ensure that the reviewer’s time is
not wasted on a document that is not ready for review.
Kick-off:
The goal of this meeting is to get everybody on the same wavelength regarding
the document under review and to commit to the time that will spent time
on checking the document. The relationships between the documents under
review and the other documents(sources) are explained. Role assignments,
checking rate , the pages to be checked, process changes are discussed in this
meeting.
Preparation:
The individual participants identify defects, questions and comments, according
to their understanding of the document and role . Using checklists in this phase
can make reviews more effective and efficient. A critical success factor for a
thorough preparation is the number of pages checked per hour. By collecting data
and measuring the review process, company-specific criteria for checking rate
and document size can be set.
Review meeting:
This meeting typically consists of following elements:
Logging phase: The focus is on logging as many as defects possible within
a certain timeframe.
Discussion phase: Participants can bring forward their comments and reasoning.
Moderator ensure that all discussed items have an outcome
by the end of this meeting.
Decision phase. : A decision on the document under review has to be made
by participants, based on formal exit criteria.
Types of review:
♦ Walkthrough
♦ Inspection
♦ Technical review
Key characteristics:
♦ It is a documented defect-detection process that involves peers and technical
Experts
♦ It is often performed as peer review without management participation.
♦ Led by trained moderator but possibly also by a technical experts
♦ A Separate preparation is carried out during which product is examined and
defects are found
♦ formal characteristics such as the use of checklists & logging list or issue log optional
Inspection: is the most formal review type. The document under inspection
Is prepared and checked thoroughly by the reviewers before the meeting,
Comparing the work product with its sources and other referenced documents
And using rules and checklists.
Key Characteristics:
Led by a trained moderator
It uses defined roles during the process
It involves peers to examine the product.
Rules and checklists are used during the preparation phase.
A separate preparation carried out during which the product is examined and the
defects found.
The defects found are documented in a logging lists or issue log
A formal follow-up is carried out by the moderator applying exit criteria
Optionally, a causal analysis step is introduced to address process
improvements issues and learn from the defects found
Metrics are gathered and analyzed to optimize the process.
Control flow analysis can also be used indentify unreachable (dead) code.
The summary the value of static analysis is especially for:-
Early detection of defects prior to test execution
Early warning about suspicious aspects of the code, design or requirements
Identification of defects not easily found in dynamic testing
Improved maintainability of code and design engineers work according to
documented standards and rules.
Prevention of defects, provided that engineers are willing to learn from their
errors and continuous improvement is practiced.
Test design technique: A procedure used to derive and or select test cases.
Test Oracle:
A source to determine expected results with the actual results of the software
under test.
IEEE 829 STANDARDS: TEST CASE SPECIFICATION TEMPLATE:
Equivalence – partionining
Boundary Value Analysis
Decision table
State Transisition
Equivalence - Partitioning: A black box testing technique in which test case designed
To execute from the representative of equivalence partition. In principle designed to
Cover each partition atleast once.
Boundary Value Analysis: An Input or output value which is on the edge of the
equivalence partitioning or smallest incremental distance on either side of
the edge.
Decision table: are more focused on business logic and business rules and good way
To deal with combination of things. This technique referred as “cause – effect” table
State Transition testing: In which test case are designed to execute the valid
And invalid state transition, where some aspect of the system can be
described in what is called a “finite state machine”. A finite state machine is often
known as state diagram.
Use case testing: In which the test case are designed to execute user sceneriors
Each use case describes the interactions the actor has with the system in order
to achieve the specific task.
Exploratory testing: a test design technique where the tester actively controls the
design of the tests as those test are performed and uses information gained
while testing to design new and better tests.