8/2/2019 Basics of software testing part 1
1/23
Software Quality
DEFINITION
Software quality is the degree of conformance to explicit or implicit requirements andexpectations.
Explanation:
Explicit: clearly defined and documented
Implicit: not clearly defined and documented but indirectly suggested
Requirements: business/product/software requirements
Expectations: mainly end-user expectations
Note: Some people tend to accept quality as compliance to only explicit requirements and
not implicit requirements. We tend to think of such people as lazy.
Definition by IEEE
The degree to which a system, component, or process meets specified requirements.
The degree to which a system, component, or process meets customer or user needs
or expectations.
Definition by ISTQB
quality: The degree to which a component, system or process meets specified
requirements and/or user/customer needs and expectations. software quality: The totality of functionality and features of a software product
that bear on its ability to satisfy stated or implied needs.
As with any definition, the definition of software quality is also varied and debatable.
Some even say that quality cannot be defined and some say that it can be defined but only
in a particular context. Some even state confidently that quality is lack of bugs. Whatever
the definition, it is true that quality is something we all aspire to.
Software quality has many dimensions. See Dimensions of Quality.
In order to ensure software quality, we undertake Software Quality Assurance andSoftware Quality Control.
Dimensions of Quality
http://softwaretestingfundamentals.com/dimensions-of-quality/http://softwaretestingfundamentals.com/dimensions-of-quality/http://softwaretestingfundamentals.com/software-quality-assurance/http://softwaretestingfundamentals.com/software-quality-control/http://softwaretestingfundamentals.com/dimensions-of-quality/http://softwaretestingfundamentals.com/software-quality-assurance/http://softwaretestingfundamentals.com/software-quality-control/8/2/2019 Basics of software testing part 1
2/23
Accessibility:The degree to which software can be used comfortably by a widevariety of people, including those who require assistive technologies like screen
magnifiers or voice recognition.
Compatibility:The suitability of software for use in different environments likedifferent Operating Systems, Browsers, etc.
Concurrency:The ability of software to service multiple requests to the sameresources at the same time.
Efficiency:The ability of software to perform well or achieve a result withoutwasted energy, resources, effort, time or money.
Functionality: The ability of software to carry out the functions as specified or
desired.
Installability:The ability of software to be installed inspecified environment. Localizability:The ability of software to be used in different languages, time
zones etc.
Maintainability:The ease with which software can be modified (adding features,enhancing features, fixing bugs, etc)
Performance:The speed at which software performs under a particular load.
Portability:The ability of software to be transferred easily from one location toanother.
Reliability:The ability of software to perform a required function under statedconditions for stated period of time without any errors.
Scalability:The measure of software s ability to increase or decrease inperformance in response to changes in software s processing demands.
Security:The extent of protection of software against unauthorized access,invasion of privacy, theft, loss of data, etc.
Testability:The ability of software to be easily tested. Usability:The degree of software s ease of use.
When someone says This software is of a very high quality., you might want to ask In
which dimension of quality?
Accessibility:The degree to which software can be used comfortably by a widevariety of people, including those who require assistive technologies like screen
magnifiers or voice recognition.
Compatibility:The suitability of software for use in different environments likedifferent Operating Systems, Browsers, etc.
Concurrency:The ability of software to service multiple requests to the sameresources at the same time.
Efficiency:The ability of software to perform well or achieve a result withoutwasted energy, resources, effort, time or money.
Functionality: The ability of software to carry out the functions as specified or
desired.
Installability:The ability of software to be installed inspecified environment. Localizability:The ability of software to be used in different languages, time
zones etc.
8/2/2019 Basics of software testing part 1
3/23
Maintainability:The ease with which software can be modified (adding features,enhancing features, fixing bugs, etc)
Performance:The speed at which software performs under a particular load. Portability:The ability of software to be transferred easily from one location to
another.
Reliability:The ability of software to perform a required function under statedconditions for stated period of time without any errors.
Scalability:The measure of software s ability to increase or decrease inperformance in response to changes in software s processing demands.
Security:The extent of protection of software against unauthorized access,invasion of privacy, theft, loss of data, etc.
Testability:The ability of software to be easily tested. Usability:The degree of software s ease of use.
When someone says This software is of a very high quality., you might want to ask In
which dimension of quality?
Software Quality Assurance
Software Quality Assurance (SQA) is a set of activities for ensuring quality in softwareengineering processes (that ultimately result in quality in software products).
It includes the following activities:
Process definition and implementation
Auditing
Training
The quality management system under which the software system is created is normally
based on one or more of the following models/standards:
CMMI
Six Sigma
ISO 9000
Note: There are many other models/standards for quality management but the ones
mentioned above are the most popular.
Software Quality Assurance encompasses the entire software development life cycle andthe goal is to ensure that the development and/or maintenance processes are continuously
improved to produce products that meet specifications/requirements.
The process ofSoftware Quality Control (SQC) is also governed by Software Quality
Assurance (SQA).
http://softwaretestingfundamentals.com/software-quality-control/http://softwaretestingfundamentals.com/software-quality-control/8/2/2019 Basics of software testing part 1
4/23
SQA is generally shortened to just QA.
Software Quality Control
Software Quality Control (SQC) is a set of activities for ensuring quality in softwareproducts.
It includes the following activities:
Reviews
o Requirement Review
o Design Review
o Code Review
o Deployment Plan Review
o Test Plan Review
o Test Cases Review Testing
o Unit Testing
o Integration Testing
o System Testing
o Acceptance Testing
Software Quality Control is limited to the Review/Testing phases of the Software
Development Life Cycle and the goal is to ensure that the products meetspecifications/requirements.
The process of Software Quality Control (SQC) is governed bySoftware QualityAssurance (SQA). While SQA is oriented towards prevention, SQC is oriented towards
detection.
Note: Some people assume that QC means just Testing and fail to consider Reviews; thisshould be discouraged.
Verification vs Validation
Verification and Validation: Definition, Differences, Details:
The terms Verification and Validation are frequently used in the software testingworld but the meaning of those terms are mostly vague and debatable. You will encounter
(or have encountered) all kinds of usage and interpretations of those terms, and it is our
humble attempt here to distinguish between them as clearly as possible.
Criteria Verification Validation
http://softwaretestingfundamentals.com/software-quality-assurance/http://softwaretestingfundamentals.com/software-quality-assurance/http://softwaretestingfundamentals.com/software-quality-assurance/http://softwaretestingfundamentals.com/software-quality-assurance/http://softwaretestingfundamentals.com/software-quality-assurance/8/2/2019 Basics of software testing part 1
5/23
Definition The process of evaluating work-
products (not the actual final product)
of a development phase to determinewhether they meet the specified
requirements for that phase.
The process of evaluating software
during or at the end of the development
process to determine whether it satisfiesspecified business requirements.
Objective To ensure that the product is being builtaccording to the requirements anddesign specifications. In other words, to
ensure that work products meet their
specified requirements.
To ensure that the product actuallymeets the users needs, and that thespecifications were correct in the first
place. In other words, to demonstrate
that the product fulfills its intended usewhen placed in its intended
environment.
Question Are we building the product right? Are we building the rightproduct?
Evaluation
Items
Plans, Requirement Specs, Design
Specs, Code, Test Cases
The actual product/software.
Activities
Reviews Walkthroughs
Inspections
Testing
It is entirely possible that a product passes when verified but fails when validated. This can
happen when, say, a product is built as per the specifications but the specificationsthemselves fail to address the users needs.
Trust but Verify.
Verify but also Validate.
Software Development Life Cycle
Software Development Life Cycle, or Software Development Process, defines the
steps/stages/phases in the building of software.
There are various kinds of software development models like:
Waterfall model
Spiral model
Iterative and incremental development (like Unified Process and RationalUnified Process)
Agile development (like Extreme Programming and Scrum)
Models are evolving with time and the development life cycle can vary significantly from
one model to the other. It is beyond the scope of this particular article to discuss each
model. However, each model comprises of all or some of the following
phases/activities/tasks.
8/2/2019 Basics of software testing part 1
6/23
SDLC IN SUMMARY
Project Planning
Requirements Development
Estimation
Scheduling Design
Coding Test Build/Deployment
Unit Testing
Integration Testing
User Documentation
System Testing
Acceptance Testing
Production Build/Deployment
Release
Maintenance
SDLC IN DETAIL
Project Planningo Prepare
o Review
o Rework
o Baseline
o Revise [if necessary] >> Review >> Rework >> Baseline
Requirements Development [Business Requirements and Software/Product
Requirements]o Develop
o Review
o Rework
o Baseline
o Revise [if necessary] >> Review >> Rework >> Baseline
Estimation [Size / Effort / Cost]
o
Schedulingo
Designing [ High Level Design and Detail Design]o
Coding
o Code
o Review
o Rework
o Commit
o Recode [if necessary] >> Review >> Rework >> Commit
8/2/2019 Basics of software testing part 1
7/23
Test Builds Preparation/Deployment
o Build/Deployment Plan
Prepare Review
Rework
Baseline Revise [if necessary] >> Review >> Rework >> Baseline
o Build/Deploy
Unit Testingo Test Plan
Prepare
Review Rework
Baseline
Revise [if necessary] >> Review >> Rework >> Baselineo Test Cases/Scripts
Prepare Review
Rework Baseline
Execute
Revise [if necessary] >> Review >> Rework >> Baseline >>Execute
Integration Testingo
User Documentation
o Prepare
o Reviewo Rework
o Baseline
o Revise [if necessary] >> Review >> Rework >> Baseline
System Testing
o
Acceptance Testing [ Internal Acceptance Test and External Acceptance Test]o
Production Build/Deploymento
Release
o Prepareo Review
o Rework
o Release
Maintenanceo Recode [Enhance software / Fix bugs]
o Retest
o Redeploy
8/2/2019 Basics of software testing part 1
8/23
o Rerelease
Notes:
The life cycle mentioned here is NOT set in stone and each phase does not
necessarily have to be implemented in the order mentioned. Though SDLC uses the term Development, it does not focus just on the coding
tasks done by developers but incorporates the tasks of all stakeholders, including
testers.
There may still be many other activities/ tasks which have not been specifically mentionedabove, like Configuration Management. No matter what, it is essential that you clearly
understand the software development life cycle your project is following. One issue that is
widespread in many projects is that software testers are involved much later in the lifecycle, due to which they lack visibility and authority (which ultimately compromises
software quality).
Definition of Test
Being in the software industry, we have to encounter the word TEST many times. Though
we have our own specific meaning of the word TEST, we have collected here some
definitions of the word as provided by various dictionaries and other tidbits. The word
TEST can be a Noun, a Verb or an Adjective but the definitions here are only of the Nounform.
DEFINITION OF TEST
Google Dictionary:
A Test is a deliberate action or experiment to find out how well something works.
Cambridge Advanced Learners Dictionary:
A Test is an act of using something to find out whether it is working correctly or how
effective it is.
The Free Dictionary by Farlex:A Test is a procedure for critical evaluation; a means of determining the presence, quality,
or truth of something.
Meriam Webster:
A Test is a critical examination, observation, or evaluation.
Dictionary.com:
A Test is the means by which the presence, quality, or genuineness of anything isdetermined.
8/2/2019 Basics of software testing part 1
9/23
WordWeb:
A Test is trying something to find out about it.
Longman Dictionary of Contemporary English:
A Test is a process used to discover whether equipment or a product works correctly, or to
discover more about it.
ETYMOLOGY OF TEST
Online Etymology Dictionary:
TEST late 14c., small vessel used in assaying precious metals, from O.Fr. test, from L.testum earthen pot, related to testa piece of burned clay, earthen pot, shell (cf. L.
testudo tortoise) and textere to weave (cf. Lith. tistas vessel made of willow twigs;
see texture). Sense of trial or examination to determine the correctness of something isrecorded from 1594. The verb in this sense is from 1748. The connecting notion is
ascertaining the quality of a metal by melting it in a pot.
SYNONYMS OF TEST:
If the word TEST has been nauseating you because of its being overused, try the following
synonyms:
Analysis
Assessment
Attempt
Check
Confirmation
Evaluation
Examination
Experiment
Inquiry
Inspection
Investigation
http://softwaretestingfundamentals.com/wp-content/uploads/2010/12/test_synonyms.jpg8/2/2019 Basics of software testing part 1
10/23
Scrutiny
Trial
Verification
Software Testing MythsJust as every field has its myths, so does the field of Software Testing. Software testing
myths have arisen primarily due to the following:
Lack of authoritative facts.
Evolving nature of the industry.
General flaws in human logic.
Some of the myths are explained below, along with their related facts:
1. MYTH: Quality Control = Testing.o FACT: Testing is just one component of software quality control. Quality
Control includes other activities such as Reviews.
2. MYTH: The objective of Testing is to ensure a 100% defect- free product.o FACT: The objective of testing is to uncover as many defects as possible.
Identifying all defects and getting rid of them is impossible.
3. MYTH: Testing is easy.o FACT: Testing can be difficult and challenging (sometimes, even more so
than coding).
4. MYTH:Anyone can test.o FACT: Testing is a rigorous discipline and requires many kinds of skills.
5. MYTH: There is no creativity in testing.o FACT: Creativity can be applied when formulating test approaches, when
designing tests, and even when executing tests.
6. MYTH:Automated testing eliminates the need for manual testing.
o FACT: 100% test automation cannot be achieved. Manual Testing, to some
level, is always necessary.7. MYTH: When a defect slips, it is the fault of the Testers.
o FACT: Quality is the responsibility of all members/stakeholders, including
developers, of a project.8. MYTH: Software Testing does not offer opportunities for career growth.
o FACT: Gone are the days when users had to accept whatever product was
dished to them; no matter what the quality. With the abundance ofcompeting software and increasingly demanding users, the need for
software testers to ensure high quality will continue to grow.
Management folk tend to have a special affinity for myths; so it will be your responsibility
as a software tester to convince them that they are wrong. Tip: Put forward your argumentswith relevant examples and numbers to validate your claims.
8/2/2019 Basics of software testing part 1
11/23
Agile Testing
This article on Agile Testing assumes that you already understand Agile softwaredevelopment methodology (Scrum, Extreme Programming, or other flavors of Agile). Also,
it discusses the idea at a high level and does not give you the specifics.
VERY SHORT DEFINITION
Agile testing is a method of software testing that follows the principles of agile software
development.
MANIFESTO FOR AGILE SOFTWARE TESTING
This is adapted from agilemanifesto.org and it might look a little silly to copy everything
from there and just replace the term development with testing but here it is for your
refreshment. You need to however realize that the term development means coding, testingand all other activities that are necessary in building a valuable software.
We are uncovering better ways of testing
software by doing it and helping others do it.Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
AGILE TESTING VALUES EXPLAINED
8/2/2019 Basics of software testing part 1
12/23
Individuals and interactions over processes and tools: This means that flexible
people and communication are valued over rigid processes and tools. However, this
does not mean that agile testing ignores processes and tools. In fact, agile testing isbuilt upon very simple, strong and reasonable processes like the process of
conducting the daily meeting or preparing the daily build. Similarly, agile testing
attempts to leverage tools, especially for test automation, as much as possible.Nevertheless, it needs to be clearly understood that it is the testers who drive those
tools and the output of the tools depend on the testers (not the other way round).
Working software over comprehensive documentation: This means thatfunctional and usable software is valued over comprehensive but unusable
documentation. Though this is more directed to upfront requirement specifications
and design specifications, this can be true for test plans and test cases as well. Our
primary goal is the act of testing itself and not any elaborate documentation merelypointing toward that goal. However, it is always best to have necessary
documentation in place so that the picture is clear and the picture remains with
the team if/when a member leaves.
Customer collaboration over contract negotiation: This means that the client isengaged frequently and closely in touch with the progress of the project (not
through complicated progress reports but through working pieces of software). Thisdoes put some extra burden on the customer who has to collaborate with the team at
regular intervals (instead of just waiting till the end of the contract, hoping that
deliveries will be made as promised). But this frequent engagement ensures that theproject is heading toward the right direction and not toward the building of a frog
when a fish is expected.
Responding to change over following a plan: This means accepting changes as
being natural and responding to them without being afraid of them. It is always niceto have a plan beforehand but it is not very nice to stick to a plan, at whatever the
cost, even when situations have changed. Lets say you write a test case, which is
your plan, assuming a certain requirement. Now, if the requirement changes, you donot lament over the wastage of your time and effort. Instead, you promptly adjust
your test case to validate the changed requirement. And, of course, only a FOOL
would try to run the same old test case on the new software and mark the test asFAIL.
PRINCIPLES BEHIND AGILE MANIFESTO
Behind the Agile Manifesto are the following principles which some agile practitioners
unfortunately fail to understand or implement. We urge you to go through each principle
and digest them thoroughly if you intend to embrace Agile Testing. On the right column,the original principles have been re-written specifically for software testers.
We follow these principles: What it means for Software Testers:
Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
Our highest priority is to satisfy the customer
through early and continuous delivery ofhigh-
quality software.
Welcome changing requirements, even late Welcome changing requirements, even late
8/2/2019 Basics of software testing part 1
13/23
in development. Agile processes harness
change for the customers competitive
advantage.
in testing. Agile processes harness change for
the customers competitive advantage.
Deliver working software frequently, froma couple of weeks to a couple of months,
with a preference to the shorter timescale.
Deliverhigh-quality software frequently, from acouple of weeks to a couple of months, with a
preference to the shorter timescale.Business people and developers must work
together daily throughout the project.
Business people, developers, and testers must
work together daily throughout the project.
Build projects around motivated
individuals. Give them the environment
and support they need, and trust them to getthe job done.
Build test projects around motivated individuals.
Give them the environment and support they
need, and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a
development team is face-to-face
conversation.
The most efficient and effective method of
conveying information to and within a test team
is face-to-face conversation.
Working software is the primary measure
of progress.
Working high-quality software is the primary
measure of progress.
Agile processes promote sustainable
development. The sponsors, developers,and users should be able to maintain a
constant pace indefinitely.
Agile processes promote sustainable
development and testing. The sponsors,developers, testers, and users should be able to
maintain a constant pace indefinitely.
Continuous attention to technicalexcellence and good design enhances
agility.
Continuous attention to technical excellence andgood test design enhances agility.
Simplicitythe art of maximizing the
amount of work not doneis essential.
Simplicitythe art of maximizing the amount of
work not doneis essential.
The best architectures, requirements, anddesigns emerge from self-organizing teams.
The best architectures, requirements, anddesigns emerge fromself-organizing teams.
At regular intervals, the team reflects on
how to become more effective, then tunes
and adjusts its behavior accordingly.
At regular intervals, the test team reflects on
how to become more effective, then tunes and
adjusts its behavior accordingly.
THE RECURRING QUESTION
So what happens to all the traditional software testing methods and artifacts? Do we throw
them away?
THE ANSWER
Naaah! You will still need all those software testing methods and artifacts (but at varying
scales of priority and necessity). You will, however, need to completely throw away thattraditional attitude and embrace the agile attitude.
8/2/2019 Basics of software testing part 1
14/23
Unit Testing
Unit Testing Definition, Analogy, Method, Tasks, Details, Benefits, Tips:
DEFINITION
Unit Testing is a level of the software testing process where individual units/components
of a software/system are tested. The purpose is to validate that each unit of the software
performs as designed.
A unit is the smallest testable part of software. It usually has one or a few inputs and
usually a single output. In procedural programming a unit may be an individual program,
function, procedure, etc. In object-oriented programming, the smallest unit is a method,
which may belong to a base/super class, abstract class or derived/child class. (Some treat amodule of an application as a unit. This is to be discouraged as there will probably be many
individual units within that module.)
Unit testing frameworks, drivers, stubs and mock or fake objects are used to assist in unit
testing.
METHOD
Unit Testing is performed by using the White Box Testing method.
When is it performed?
Unit Testing is the first level of testing and is performed prior toIntegration Testing.
Who performs it?
http://softwaretestingfundamentals.com/white-box-testing/http://softwaretestingfundamentals.com/integration-testing/http://softwaretestingfundamentals.com/integration-testing/http://softwaretestingfundamentals.com/integration-testing/http://softwaretestingfundamentals.com/white-box-testing/http://softwaretestingfundamentals.com/integration-testing/8/2/2019 Basics of software testing part 1
15/23
Unit Testing is normally performed by software developers themselves or their peers. In
rare cases it may also be performed by independent software testers.
TASKS
Unit Test Plano Prepare
o Review
o Rework
o Baseline
Unit Test Cases/Scriptso Prepare
o Review
o Rework
o Baseline
Unit Test
o Perform
BENEFITS
Unit testing increases confidence in changing/maintaining code. If good unit testsare written and if they are run every time any code is changed, the likelihood of any
defects due to the change being promptly caught is very high. If unit testing is not
in place, the most one can do is hope for the best and wait till the test results athigher levels of testing are out. Also, if codes are already made less interdependent
to make unit testing possible, the unintended impact of changes to any code is less.
Codes are more reusable. In order to make unit testing possible, codes need to be
modular. This means that codes are easier to reuse. Development is faster. How? If you do not have unit testing in place, you write
your code and perform that fuzzy developer test (You set some breakpoints, fireup the GUI, provide a few inputs that hopefully hit your code and hope that you are
all set.) In case you have unit testing in place, you write the test, code and run the
tests. Writing tests takes time but the time is compensated by the time it takes to run
the tests. The test runs take very less time: You need not fire up the GUI andprovide all those inputs. And, of course, unit tests are more reliable than developer
tests. Development is faster in the long run too. How? The effort required to find
and fix defects found during unit testing is peanuts in comparison to those foundduring system testing or acceptance testing.
The cost of fixing a defect detected during unit testing is lesser in comparison tothat of defects detected at higher levels. Compare the cost (time, effort, destruction,humiliation) of a defect detected during acceptance testing or say when the software
is live.
Debugging is easy. When a test fails, only the latest changes need to be debugged.
With testing at higher levels, changes made over the span of severaldays/weeks/months need to be debugged.
8/2/2019 Basics of software testing part 1
16/23
Codes are more reliable. Why? I think there is no need to explain this to a sane
person.
TIPS
Find a tool/framework for your language. Do not create test cases for everything: some will be handled by themselves.
Instead, focus on the tests that impact the behavior of the system.
Isolate the development environment from the test environment.
Use test data that is close to that of production.
Before fixing a defect, write a test that exposes the defect. Why? First, you will
later be able to catch the defect if you do not fix it properly. Second, your test suiteis now more comprehensive. Third, you will most probably be too lazy to write the
test after you have already fixed the defect.
Write test cases that are independent of each other. For example if a class depends
on a database, do not write a case that interacts with the database to test the class.
Instead, create an abstract interface around that database connection and implementthat interface with mock object.
Aim at covering all paths through the unit. Pay particular attention to loopconditions.
Make sure you are using a version control system to keep track of your code as well
as your test cases.
In addition to writing cases to verify the behavior, write cases to ensure
performance of the code.
Perform unit tests continuously and frequently.
ONE MORE REASON
Lets say you have a program comprising of two units. The only test you perform is systemtesting. [You skip unit and integration testing.] During testing, you find a bug. Now, how
will you determine the cause of the problem?
Is the bug due to an error in unit 1?
Is the bug due to an error in unit 2? Is the bug due to errors in both units?
Is the bug due to an error in the interface between the units?
Is the bug due to an error in the test or test case?
Unit testing is often neglected but it is, in fact, the most important level of testing.
Definition by ISTQB
unit testing: See component testing.
component testing: The testing of individual software components.
8/2/2019 Basics of software testing part 1
17/23
Integration Testing
Integration Testing Definition, Analogy, Method, Tasks, Details, Approaches, Tips:
DEFINITION
Integration Testing is a level of the software testing process where individual units are
combined and tested as a group.
The purpose of this level of testing is to expose faults in the interaction between integratedunits.
Test drivers and test stubs are used to assist in Integration Testing.
Note: The definition of a unit is debatable and it could mean any of the following:
1. the smallest testable part of a software
2. a module which could consist of many of 13. a component which could consist of many of 2
ANALOGY
During the process of manufacturing a ballpoint pen, the cap, the body, the tail and clip, the
ink cartridge and the ballpoint are produced separately and unit tested separately. When
two or more units are ready, they are assembled and Integration Testing is performed. Forexample, whether the cap fits into the body or not.
METHOD
8/2/2019 Basics of software testing part 1
18/23
Any ofBlack Box Testing,White Box Testing, andGray Box Testing methods can be
used. Normally, the method depends on your definition of unit.
TASKS
Integration Test Plano Prepare
o Review
o Rework
o Baseline
Integration Test Cases/Scriptso Prepare
o Review
o Rework
o Baseline
Integration Test
o Perform
When is Integration Testing performed?
Integration Testing is performed afterUnit Testing and before System Testing.
Who performs Integration Testing?
Either Developers themselves or independent Testers perform Integration Testing.
APPROACHES
Big Bangis an approach to Integration Testing where all or most of the units are
combined together and tested at one go. This approach is taken when the testingteam receives the entire software in a bundle. So what is the difference between Big
Bang Integration Testing and System Testing? Well, the former tests only the
interactions between the units while the latter tests the entire system.
Top Down is an approach to Integration Testing where top level units are tested first
and lower level units are tested step by step after that. This approach is taken when
top down development approach is followed. Test Stubs are needed to simulate
lower level units which may not be available during the initial phases.
Bottom Up is an approach to Integration Testing where bottom level units are tested
first and upper level units step by step after that. This approach is taken whenbottom up development approach is followed. Test Drivers are needed to simulatehigher level units which may not be available during the initial phases.
Sandwich/Hybridis an approach to Integration Testing which is a combination of
Top Down and Bottom Up approaches.
TIPS
http://softwaretestingfundamentals.com/black-box-testing/http://softwaretestingfundamentals.com/black-box-testing/http://softwaretestingfundamentals.com/white-box-testing/http://softwaretestingfundamentals.com/gray-box-testing/http://softwaretestingfundamentals.com/gray-box-testing/http://softwaretestingfundamentals.com/unit-testing/http://softwaretestingfundamentals.com/system-testing/http://softwaretestingfundamentals.com/black-box-testing/http://softwaretestingfundamentals.com/white-box-testing/http://softwaretestingfundamentals.com/gray-box-testing/http://softwaretestingfundamentals.com/unit-testing/http://softwaretestingfundamentals.com/system-testing/8/2/2019 Basics of software testing part 1
19/23
Ensure that you have a proper Detail Design document where interactions between
each unit are clearly defined. In fact, you will not be able to perform Integration
Testing without this information.
Ensure that you have a robust Software Configuration Management system in
place. Or else, you will have a tough time tracking the right version of each unit,
especially if the number of units to be integrated is huge. Make sure that each unit is first unit tested before you start Integration Testing.
As far as possible, automate your tests, especially when you use the Top Down or
Bottom Up approach, since regression testing is important each time you integrate aunit, and manual regression testing can be inefficient.
Definition by ISTQB
integration testing: Testing performed to expose defects in the interfaces and in
the
interactions between integrated components or systems. See also component
integrationtesting, system integration testing.
component integration testing: Testing performed to expose defects in theinterfaces and
interaction between integrated components.
system integration testing: Testing the integration of systems and packages;testing
interfaces to external organizations (e.g. Electronic Data Interchange, Internet).
System Testing
System Testing Definition, Analogy, Method, Tasks, Details:
DEFINITION
System Testing is a level of the software testing process where a complete, integrated
system/software is tested.
The purpose of this test is to evaluate the systems compliance with the specified
requirements.
8/2/2019 Basics of software testing part 1
20/23
ANALOGY
During the process of manufacturing a ballpoint pen, the cap, the body, the tail, the ink
cartridge and the ballpoint are produced separately and unit tested separately. When two or
more units are ready, they are assembled and Integration Testing is performed. When thecomplete pen is integrated, System Testing is performed.
METHOD
Usually,Black Box Testing method is used.
TASKS
System Test Plano Prepare
o Review
o Rework
o Baseline
System Test Cases
o Prepare
o Review
o Rework
o Baseline
System Test
o Perform
When is it performed?
System Testing is performed afterIntegration Testing and beforeAcceptance Testing.
http://softwaretestingfundamentals.com/black-box-testing/http://softwaretestingfundamentals.com/black-box-testing/http://softwaretestingfundamentals.com/integration-testing/http://softwaretestingfundamentals.com/acceptance-testing/http://softwaretestingfundamentals.com/acceptance-testing/http://softwaretestingfundamentals.com/black-box-testing/http://softwaretestingfundamentals.com/integration-testing/http://softwaretestingfundamentals.com/acceptance-testing/8/2/2019 Basics of software testing part 1
21/23
Who performs it?
Normally, independent Testers perform System Testing.
Definition by ISTQB
system testing: The process of testing an integrated system to verify that it meetsspecified
requirements.
Acceptance Testing
Acceptance Testing Definition, Analogy, Method, Tasks, Details:
DEFINITION
Acceptance Testing is a level of the software testing process where a system is tested for
acceptability.
The purpose of this test is to evaluate the systems compliance with the business
requirements and assess whether it is acceptable for delivery.
ANALOGY
During the process of manufacturing a ballpoint pen, the cap, the body, the tail and clip, theink cartridge and the ballpoint are produced separately and unit tested separately. When
two or more units are ready, they are assembled and Integration Testing is performed.
When the complete pen is integrated, System Testing is performed. Once the SystemTesting is complete, Acceptance Testing is performed so as to confirm that the ballpoint
pen is ready to be made available to the end-users.
8/2/2019 Basics of software testing part 1
22/23
METHOD
Usually,Black Box Testing method is used in Acceptance Testing.
Testing does not usually follow a strict procedure and is not scripted but is rather ad-hoc.
TASKS
Acceptance Test Plano Prepare
o Review
o Rework
o Baseline
Acceptance Test Cases/Checklisto Prepare
o Review
o Reworko Baseline
Acceptance Test
o Perform
When is it performed?
Acceptance Testing is performed afterSystem Testing and before making the systemavailable for actual use.
Who performs it?
Internal Acceptance Testing(Also known as Alpha Testing) is performed by
members of the organization that developed the software but who are not directlyinvolved in the project (Development or Testing). Usually, it is the members of
Product Management, Sales and/or Customer Support.
External Acceptance Testingis performed by people who are not employees of theorganization that developed the software.
o Customer Acceptance Testingis performed by the customers of the
organization that developed the software. They are the ones who asked the
organization to develop the software for them. [This is in the case of thesoftware not being owned by the organization that developed it.]
o User Acceptance Testing(Also known as Beta Testing) is performed by theend users of the software. They can be the customers themselves or thecustomers customers.
Definition by ISTQB
acceptance testing: Formal testing with respect to user needs, requirements, and
business processes conducted to determine whether or not a system satisfies the
http://softwaretestingfundamentals.com/black-box-testing/http://softwaretestingfundamentals.com/black-box-testing/http://softwaretestingfundamentals.com/system-testing/http://softwaretestingfundamentals.com/black-box-testing/http://softwaretestingfundamentals.com/system-testing/8/2/2019 Basics of software testing part 1
23/23
acceptance criteria and to enable the user, customers or other authorized entity to
determine whether or not to accept the system.