Se4203software Testing New
Se4203software Testing New
UNIT I INTRODUCTION 8
Introduction to software testing – Evolution of Software Testing – Goals of Software Testing - Software
Testing Definitions - Model for Software Testing - Software Testing as a Process - software testing
terminology and methodology – Software Testing Terminology – STLC – Software Testing Methodology –
Verification and Validation
Software Testing
Software Testing is a method to check whether the actual software product matches expected requirements
and to ensure that software product is Defect free. It involves execution of software/system components
using manual or automated tools to evaluate one or more properties of interest. The purpose of software
testing is to identify errors, gaps or missing requirements in contrast to actual requirements.
Some prefer saying Software testing definition as a White Box and Black Box Testing. In simple terms,
Software Testing means the Verification of Application Under Test (AUT). This Software Testing course
introduces testing software to the audience and justifies the importance of software testing.
Software programming has evolved over the decades and consequently, testing, which is an integral part of
software development, has also gone through a series of changes.
It’s all started with programming and debugging phase, when finding errors during debugging was
considered testing. In 1957, testing got an individual identity and was treated as a separate activity from the
debugging process. Till the late ’70s, testing was seen as an exercise to ensure that the software works as
per the specified requirements. It was then extended to find the errors, besides ensuring the proper
functioning of the software. In the ’80s, the testing activity was also considered as a measurement of
quality. With this, it gained more importance and was treated as a clearly defined and managed process of
the software development life cycle. By the mid-’90s, the testing process had its own life cycle.
Evolution Cycle
Testing first ensured that the software works as per the specified end-user requirements (Business
Requirement or Functional Requirement).
Then Testing was used to find the issues/bugs and also ensuring the proper functioning of the software.
Software Testing then became a measurement of quality of Software and also got included in the software
development life cycle.
The testing process then had its own Software Testing life cycle.
Various Software Testing Models emerged in-line
o Waterfall Model.
o V Model.
o Agile Model.
o Spiral Model.
o Iterative Model
These different models or approaches can be used in the process where each model has its own advantages
and disadvantages. So, you must choose a particular model depending on the project deliverables and
complexity of the project.
Agile – Growth of the software development process needed more comprehensive ways of testing. The
incremental and iterative approach employed by agile testing helped in achieving this goal.
Automation – Testing was taken to entirely different level by Automation Testing. Automated testing is a
method in software testing that uses various automation tools to control the execution of tests, so more
time can be saved on repetition tasks and this time can be spent on higher value tasks, such as exploratory
tests. Mainly Automating time-consuming tests, such as regression tests. While you do need spend time
maintaining test scripts overall, you will increase your test coverage and scalability.
Continuous Testing- Continuous Testing is in the trend now and has become important with the concepts
like Continuous Integrationand Continuous Deployment becoming popular. To meet the continuous
integration and delivery needs, we have turned to continuous testing backed by automation. As this is the
time of digital transformation, we need Digital Testing to meet the quality needs of future driven by AI.
Artificial Intelligence (AI): This is the future – collaborative and smart testing. Artificial Intelligence is the
machine’s capability of imitating human behaviour by perceiving, understanding and learning. AI can be
used to help automate and reduce the amount of tedious tasks in development and testing. AI also uses
image recognition techniques to navigate through the application and verify UI objects and elements
visually. AI can also be used to sell more and spend less time on Admin tasks.
1. Immediate Goals: These objectives are the direct outcomes of testing. These objectives may be set at
any time during the SDLC process. Some of these are covered in detail below:
Bug Discovery: This is the immediate goal of software testing to find errors at any stage of software
development. The number of bugs is discovered in the early stage of testing. The primary purpose of
software testing is to detect flaws at any step of the development process. The higher the number of
issues detected at an early stage, the higher the software testing success rate.
Bug Prevention: This is the immediate action of bug discovery, that occurs as a result of bug discovery.
Everyone in the software development team learns how to code from the behavior and analysis of issues
detected, ensuring that bugs are not duplicated in subsequent phases or future projects.
2. Long-Term Goals: These objectives have an impact on product quality in the long run after one cycle
of the SDLC is completed. Some of these are covered in detail below:
Quality: This goal enhances the quality of the software product. Because software is also a product, the
user’s priority is its quality. Superior quality is ensured by thorough testing. Correctness, integrity,
efficiency, and reliability are all aspects that influence quality. To attain quality, you must achieve all of
the above-mentioned quality characteristics.
Customer Satisfaction: This goal verifies the customer’s satisfaction with a developed software product.
The primary purpose of software testing, from the user’s standpoint, is customer satisfaction. Testing
should be extensive and thorough if we want the client and customer to be happy with the software
product.
Reliability: It is a matter of confidence that the software will not fail. In short, reliability means gaining
the confidence of the customers by providing them with a quality product.
Risk Management: Risk is the probability of occurrence of uncertain events in the organization and the
potential loss that could result in negative consequences. Risk management must be done to reduce the
failure of the product and to manage risk in different situations.
3. Post Implemented Goals: After the product is released, these objectives become critical. Some of
these are covered in detail below:
Reduce Maintenance Cost: Post-released errors are costlier to fix and difficult to identify. Because
effective software does not wear out, the maintenance cost of any software product is not the same as the
physical cost. The failure of a software product due to faults is the only expense of maintenance. Because
they are difficult to discover, post-release mistakes always cost more to rectify. As a result, if testing is
done thoroughly and effectively, the risk of failure is lowered, and maintenance costs are reduced as a
result.
Improved Software Testing Process: These goals improve the testing process for future use or software
projects. These goals are known as post-implementation goals. A project’s testing procedure may not be
completely successful, and there may be room for improvement. As a result, the bug history and post-
implementation results can be evaluated to identify stumbling blocks in the current testing process that
can be avoided in future projects.
There are many different types of software tests, each with specific objectives and strategies:
Testing is an integral part of software development life cycle. Various models or approaches are used in the
software development process where each model has its own advantages and disadvantages. Choosing a
particular model depends on the project deliverables and complexity of the project.
Now Let us go through the various software testing models and their benefits:
1. Waterfall Model
This is the most basic software development life cycle process which is followed broadly in the industry.
Here the developers follow a sequence of processes where the processes flow progressively downwards
towards the ultimate goal. It is like a waterfall where there are a number of phases.
These phases have their own unique functions and goals. There are, in fact, four phases – requirement
gathering and analysis phase, software design, programmed implementation and testing, maintenance. All
these four phases come one after another in the given order.
In the first phase all the possible system requirements for developing a particular software are noted and
analyzed. This in turn depends on the software requirement specifications which includes detailed
information about expectations of the end user. Based on this a Requirement Specification.
Document is created which acts an input to the next phase, i.e. software design phase. What needs to be
emphasized here is that once you move into the next phase it won’t be possible to update the requirements.
So you must be very thorough and careful about the end-user requirements.
Advantages
Easy to implement and maintain.
The initial phase of rigorous scrutiny of requirements and systems helps in saving time later in the
developmental phase
The requirement of resources is minimal and testing is done after completion of each phase.
Disadvantages
It is not possible to alter or update requirements
You cannot make changes once you are into the next phase.
Cannot start the next phase until the previous phase is completed
2. V Model
This model is widely recognized as superior to waterfall model. Here the development and test execution
activities are carried on side by side in the downhill and uphill shape. In this model, testing starts at the unit
level and spreads towards integration of the entire system.
So, SDLC is divided into five phases – unit testing, integration testing, regression testing, system testing
and acceptance testing.
Advantages
Easy to use the model since testing activities like planning and test designing are done before coding
Saves time and enhances chances of success.
Defects are mostly found at an early stage and downward flow of defects is generally avoided
Disadvantages
It is a rigid model
Early prototypes of the product are not available since the software is developed during the implementation
phase
If there are changes in the midway, then the test document needs to be updated
3. Agile model
In this SDLC model requirements and solutions evolve through collaboration between various cross
functional teams. This is known as an iterative and incremental model.
Advantages
Ensure customer satisfaction with rapid and continuous development of deliverables.
It is a flexible model as customers, developers and testers continuously interact with each other
Working software can be developed quickly and product can be adapted to changing requirements regularly
Disadvantages
In large and complex software development cases it becomes difficult to assess the effort required at the
beginning of the cycle
Due to continuous interaction with the customer, the project can go off track if the customer is not clear
about the goals
4. Spiral model
It is more like the Agile model, but with more emphasis on risk analysis. It has four phases – planning, risk
analysis, engineering and evaluation. Here gathering of requirements and risk assessment is done at the
base level and every upper spiral builds on it.
Advantages
Risk avoidance chance is enhanced due to the importance on risk analysis.
Its a good model for complex and large systems.
Depending on the changed circumstances additional functionalities can be added later on
Software is produced early in the cycle
Disadvantages
Its a costly model and requires highly specialized expertise in risk analysis
It does not work well in simpler projects
Rational Unified Process
This model also consists of four phases, each of which is organized into a number of separate iterations.
The difference with other models is that each of these iterations must separately satisfy defined criteria
before the next phase is undertaken.
Advantages
With an emphasis on accurate documentation this model is able to resolve risks associated with changing
requirements of the client
Integration takes less time as the process goes on throughout the SDLC.
Disadvantages
The biggest disadvantage is that the team members need to be experts in their niche.
In big projects such continuous integration, it might give rise to confusions
Disadvantages
It requires a strong team of highly capable developers with individual efficacy in identifying business
requirements
It is a module based model, so systems that can be modularized can only be developed in this model
As the cost is high, the model is not suitable for cheaper projects
General Steps of Software Testing Process
These are 11 steps software testing process is an experience based practical approach for solution to test
assignment.
These are explained as following below.
Step-1: Assess Development Plan and Status –
This initiative may be prerequisite to putting together Verification, Validation, and Testing Plan wont to
evaluate implemented software solution. During this step, testers challenge completeness and correctness of
event plan. Based on extensiveness and completeness of Project Plan testers can estimate quantity of
resources they’re going to got to test implemented software solution.
Step-2: Develop the Test Plan –
Forming plan for testing will follow an equivalent pattern as any software planning process. The structure
of all plans should be an equivalent, but content will vary supported degree of risk testers perceive as
related to software being developed.
Step-3: Test Software Requirements –
Incomplete, inaccurate, or inconsistent requirements cause most software failures. The inability to get
requirement right during requirements gathering phase can also increase cost of implementation
significantly. Testers, through verification, must determine that requirements are accurate, complete, and
they do not conflict with another.
Step-4: Test Software Design –
This step tests both external and internal design primarily through verification techniques. The testers are
concerned that planning will achieve objectives of wants, also because design being effective and efficient
on designated hardware.
TERMINOLOGIES
Test Plan
Test Scenarios
Test Cases
Priority
Severity
Verification
Validation
SDLC & STLC
1. Test Plan
A Test Case mentions the detailed inputs, execution conditions, steps to reproduce, test data, the actual &
expected results. Different test cases are designed and noted-down during the Test Case Development
phase of STLC which the testers later refer to, to check the application performance.
Test cases can be broadly classified into Functional & Non-functional or Positive & Negative.
People often get confused amongst – Test Scenarios and Test Cases. Here is a simple example to quickly
comprehend the difference between the two,
Test Case 1: Check results on entering valid User Id & valid Password
Test Case 2: Check results on entering Invalid User ID & valid Password
Test Case 3: Check results on entering valid User ID & Invalid Password
Test Case 4: Check results on entering Invalid User ID & Invalid Password
Test Case 5: Check response when fields are Empty & Login Button is pressed.
Test Scenario is to Test the login functionality whereas Test Cases that are included in this Test Scenario
are,
3. Priority vs Severity
Priority specifies the level of urgency under which the bug needs to get resolved. Whereas severity
illustrates how critical the bug is, it basically describes the magnitude of impact if the bug is not resolved.
There are different levels of priority and severity, which are depicted in the image below,
Verification is a static routine involving checking documents, structure, code, and program. It incorporates
activities involved in creating fantastic programming, including, assessment, structure investigation, and
detail examination. It is a moderate target process.
Validation is assessing the last item to check whether the product meets the clients’ desires and
prerequisites. It is a dynamic tool of approving and testing the real item.
It’s essential for a tester to possess a clear understanding of the process followed to develop the product in
their organization. Similar to SDLC, a proper process is followed to perform software testing which is
called STLC or Software Testing Life Cycle. Let’s catch some more details about these processes.
SDLC vs STLC
SDLC
Software Development Life Cycle (SDLC) explains the journey of Software Development. According to
Wikipedia, SDLC is a process followed for software development. It consists of a detailed strategy
outlining how to develop, maintain, replace, alter and enhance a specific software.
STLC
STLC illustrates a systematic and well-planned testing process which includes different stages to make the
testing process quick, effective and accountable. Unlike SDLC, STLC – software testing life cycle
identifies how test cases will be implemented and how the testing would be conducted successfully.
Now Let’s a brief look at the different phases of SDLC and STLC:
It’s important that a tester must have knowledge of the process followed to develop any product in any IT
company. This process is named as SDLC – software development life cycle. Add on to this, a proper
process is followed to perform software testing i.e STLC – software testing life cycle. Let’s catch some
more details about these processes.
A tester has to perform numerous types of testing in his career. Let’s take a sneak peek at the different
types of software testing out there,
Functional Testing
Functional testing is a type of software testing where the system is tested against some functional
requirements.
Unit Testing
Unit testing consists of the testing of individual modules or components. Its objective is to test each unit of
the software, validate whether the functionality implemented is stable or not and most importantly it should
work as per the design & requirement.It’s the first and foremost step to perform Software testing and is
generally carried out by software developers themselves. Unit Testing builds confidence in changing or
maintaining the codes. Reusability of code also increases.
Integration Testing
Integration Testing is the second step of software testing, where individual modules are combined &
integrated modules are tested. It started after completion of Unit Testing. The objective is to test the defects
to discover while integrating any modules. This type of testing verifies the functionality, performance, and
reliability between the integrated modules.
System Testing
System testing is the testing of complete and integrated software. It ensures that the developed product
meets the specific requirements.System Testing involves the examination of completely integrated
applications incorporating outer peripherals to check how modules interact with each other and with the
framework, all in all.
Sanity Testing
Sanity testing is carried out to quickly evaluate and determine whether functionalities are working as
expected or not. Sanity Testing is also referred to as surface-level-testing.Sanity testing is a type of
Software Testing performed after receiving a software build, with minor changes in code, or functionalities,
to learn that the bugs have been fixed and no further issues are acquainted due with these progressions.The
objective is “not” to verify the new functionality thoroughly but to determine that the developer has applied
some rationality (sanity) while developing the software.
Smoke Testing
Smoke Testing is performed to discover that the critical functionalities of the program are working fine.
The motto of this testing is to check the “stability” of the framework and execute “before” any detailed
functional or regression tests are executed on the application.
Interface Testing
An interface is a medium between two different software systems, whereas interface Testing is a software
testing type which verifies whether the correspondence between two distinctive programming frameworks
is done accurately.
Regression Testing
Regression testing is the type of testing in which QA verifies whether changes made in the old functionality
still works with the newly implemented changes.
Beta/Acceptance Testing:
Beta or User Acceptance testing is carried out by “real users” of the developed product in “real
environment.” A Beta version of the application is released for a limited number of users to gather
feedback on product quality.Beta testing decreases item disappointment hazards and provides an expanded
nature of the product through client approval.It is the final test before delivery product to the clients. Direct
criticism from clients is a noteworthy preferred standpoint of Beta Testing. This testing serves to tests the
item in the client’s environment.
Performance Testing
Performance testing is defined as the type of testing where we ensure proper functionality of our
application under a heavy workload.
Load Testing
Load testing is a sub-classification of Performance Testing. During load testing, we evaluate the behavior
of our application when N number of users simultaneously access it.
Stress Testing
The objective of stress testing is to analyze the response of the system following a failure. In this type of
testing system should give an error message if it is operating under dire conditions. This type of testing tries
to break the system by testing with overwhelming data or resources.
Volume Testing
Volume testing is a sort of Software Testing in which the product is subjected to an enormous volume of
information. This testing is carried out to test system performance by expanding the amount of data in the
database.
Security Testing
Security Testing ensures that our applications are free from any vulnerabilities, dangers, risks that could
cause a major misfortune. It additionally helps in identifying all conceivable security issues in the system
and assist users in fixing these issues through coding.
Compatibility Testing
Compatibility Testing is a sort of Software testing to check whether your product is fit for running on
multiple hardware, different OS, Applications and mobile gadgets. It’s a type of Non-functional testing.
Recovery Testing
Recovery testing is the process of testing how well an application can recoup from accidents, hardware
failures, and other comparable issues. This testing is the constrained disappointment of the product in an
assortment of approaches to confirm that recovery is appropriately performed.
Usability Testing
Usability testing ensures – Usefulness, Discoverability, Accessibility, Usability, and Desirability. The
objective is to see how clients interact with your product and to improve the item dependent on the
outcomes. The main focus of a Usability test is to improve a design.
Compliance Testing :
Compliance testing also referred to as conformance testing, regulation testing, standards testing, is a sort of
testing to decide the consistency of a framework. Most importantly it is the nonfunctional testing procedure
which is done to approve, regardless of whether the framework created satisfies the association’s
recommended guidelines or not. Determining that the development and maintenance process meets the
endorsed procedure.
Localization Testing
Localization testing is a software testing strategy, where the product is checked to guarantee that it carries
on as indicated by the nearby culture or settings.
1. Requirement Analysis
2. Test Planning
3. Test case development
4. Test Environment setup
5. Test Execution
6. Test Cycle closure
Differences between Verification and Validation
Verification is the process of checking that a software achieves its goal without any bugs. It is the process
to ensure whether the product that is developed is right or not. It verifies whether the developed product
fulfills the requirements that we have. Verification is static testing.
Verification means Are we building the product right?
Validation is the process of checking whether the software product is up to the mark or in other words
product has high level requirements. It is the process of checking the validation of product i.e. it checks
what we are developing is the right product. it is validation of actual and expected product. Validation is
the dynamic testing.
Validation means Are we building the right product?
The difference between Verification and Validation is as follow:
Verification Validation
It includes checking documents, design, codes It includes testing and validating the actual
and programs. product.
It does not include the execution of the code. It includes the execution of the code.
Methods used in verification are reviews, Methods used in validation are Black Box Testing,
walkthroughs, inspections and desk-checking. White Box Testing and non-functional testing.
It can find the bugs in the early stage of the It can only find the bugs that could not be found by
development. the verification process.
Note: Since Software Testing is an integral part of any Development Methodology, many companies use
the term Development Methodologies & Testing Methodologies colloquially. Hence Testing
Methodologies could also refer to Waterfall, Agile and other QA models as against the above definition of
Testing Methodologies. Discussion on various testing types does not add value to the readers. Hence, we
will discuss the different development models.
Waterfall model
Iterative development
Agile methodology
Extreme programming
Which Software Methodology to choose?
How to setup software testing methodologies?
Waterfall Model
What is it?
In the waterfall model, software development progress through various phases like Requirements Analysis,
Design etc – sequentially.
In this model, the next phase begins only when the earlier phase is completed.
What Is The Testing Approach?
The first phase in the waterfall model is the requirements phase in which all the project requirements are
completely defined before starting the testing. During this phase, the test team brainstorms the scope of
testing, test strategy and drafts a detailed test plan.
Only once the design of software is complete, the team will move on to execution of the test cases to ensure
that the developed software behaves as it expected.
In this methodology, the testing team proceeds to the next phase only when the previous phase is
completed.
Advantages
This software Engineering model is very simple to plan and manage. Hence, projects, where requirements
are clearly defined and stated beforehand, can be easily tested using a waterfall model.
Disadvantages
In the waterfall model, you can begin with the next phase only once the previous phase is completed.
Hence, this model cannot accommodate unplanned events and uncertainty.
This methodology is not suitable for projects where the requirements change frequently.
Iterative development
What is it?
In this model, a big project is divided into small parts, and each part is subjected to multiple iterations of
the waterfall model. At the end of an iteration, a new module is developed or an existing module is
enhanced. This module is integrated into the software architecture and the entire system is tested all
together
As soon as iteration is completed, the entire system is subjected to testing. Feedback from testing is
immediately available and is incorporated in the next cycle. The testing time required in successive
iteration can be reduced based on the experience gained from past iterations.
Advantages
The main advantage of iterative development is the test feedback is immediately available at the end of
each cycle.
Disadvantages
This model increases communication overheads significantly since, at the end of each cycle, feedback
about deliverables, effort etc must be given.
Agile methodology
What is it?
Traditional software development methodologies work on the premise that software requirements remain
constant throughout the project. But with an increase in complexity, the requirements undergo numerous
changes and continuously evolve. At times, the customer himself is not sure what he wants. Though the
iterative model addresses this issue, it’s still based on the waterfall model.
In Agile methodology, software is developed in incremental, rapid cycles. Interactions amongst customers,
developers and client are emphasized rather than processes and tools. The agile methodology focuses on
responding to change rather than extensive planning.
Incremental testing is used in agile development methods and hence, every release of the project is tested
thoroughly. This ensures that any bugs in the system are fixed before the next release.
Advantages
It is possible to make changes in the project at any time to comply with the requirements.
This incremental testing minimizes risks.
Disadvantages
Constant client interaction means added time pressure on all stakeholders including the client themselves,
software development and test teams.
Extreme programming
What is it?
Extreme programming is a type of agile methodology which beliefs in short development cycles. A project
is divided into simple engineering tasks. Programmers code a simple piece of software and get back to the
customer for feedback. Review points from the customer are incorporated and the developers proceed with
the next task.
Extreme Programming is used in places where customer requirements are constantly changing.
1. Add a Test Case to the test suite to verify the new functionality which is yet to be developed
2. Run all the tests and obviously the new test case added must fail since the functionality is not coded yet
3. Write some code to implement the feature/functionality
4. Run the test suite again. This time, the new test case should pass since the functionally has been coded
Advantages
Customers having a vague software design in mind could use extreme programming
Continuous testing and continuous integration of small releases ensure software code is delivered is of high
quality
Disadvantages
Meetings amongst the software development team and clients add to time requirements.
1 1 6 2000 2-6-2000
2 2 6 2000 3-6-2000
3 15 6 2000 16-6-2000
4 30 6 2000 1-7-2000
6 15 1 2000 16-1-2000
7 15 2 2000 16-2-2000
8 15 11 2000 16-11-2000
9 15 12 2000 16-12-2000
10 15 6 1800 16-6-1800
11 15 6 1801 16-6-1801
12 15 6 2047 16-6-2047
13 15 6 2048 16-6-2048
E1 15 4 2004 16-4-2004
E2 15 4 2003 16-4-2003
E3 15 1 2004 16-1-2004
E4 15 1 2003 16-1-2003
E5 15 2 2004 16-2-2004
E6 15 2 2003 16-2-2003
E7 29 4 2004 30-4-2004
E8 29 4 2003 30-4-2003
E9 29 1 2004 30-1-2004
So from this problem it is clearly seen that equivalence class testing clearly checks for many cases that
boundary value did not considered like that of February which has 28-29 days, leap year which lead to
variation in number of days in February and many more.
Hence the above example proves that equivalence partitioning generates more efficient test cases that
should be considered during risk assessment
State Transition Testing
State Transition Testing is a type of software testing which is performed to check the change in the state
of the application under varying input. The condition of input passed is changed and the change in state is
observed.
State Transition Testing is basically a black box testing technique that is carried out to observe the behavior
of the system or application for different input conditions passed in a sequence. In this type of testing, both
positive and negative input values are provided and the behavior of the system is observed.
State Transition Testing is basically used where different system transitions are needed to be tested.
1. Condition Stubs : The conditions are listed in this first upper left part of the decision table that is used to
determine a particular action or set of actions.
2. Action Stubs : All the possible actions are given in the first lower left portion (i.e, below condition stub) of
the decision table.
3. Condition Entries : In the condition entry, the values are inputted in the upper right portion of the decision
table. In the condition entries part of the table, there are multiple rows and columns which are known as
Rule.
4. Action Entries : In the action entry, every entry has some associated action or set of actions in the lower
right portion of the decision table and these values are called outputs.
Types of Decision Tables :
The decision tables are categorized into two types and these are given below:
1. Limited Entry : In the limited entry decision tables, the condition entries are restricted to binary values.
2. Extended Entry : In the extended entry decision table, the condition entries have more than two values.
The decision tables use multiple conditions where a condition may have many possibilities instead of only
‘true’ and ‘false’ are known as extended entry decision tables.
Applicability of Decision Tables :
The order of rule evaluation has no effect on the resulting action.
The decision tables can be applied easily at the unit level only.
Once a rule is satisfied and the action selected, n another rule needs to be examined.
The restrictions do not eliminate many applications.
Example of Decision Table Based testing :
Below is the decision table of the program for determining the largest amongst three numbers in which its
input is a triple of positive integers (x,y, and z) and values are from the interval [1, 300].
Table 1 : Decision Table of largest amongst three numbers :
Co
R10
R11
R12
R13
R14
R3
R4
R5
R6
R7
R8
R9
ndi
R1
R2
tio
ns
c1:
x>
T
T
=
F
1?
c2:
x
T
T
F
<=
300
?
c3:
y>
T
T
F
=
1?
c4:
x
T
T
F
<=
300
?
c5:
z>
T
F
=
1?
c6:
z
T
F
<=
300
?
c7:
F
x>y
?
c8: T
T
F
F
y>z
?
c9:
T
T
F
F
z>x
?
Rul
128
64
32
16
e
8
1
256
Co
unt
a1 :
Inv
X
alid
X
inp
ut
a2 :
x is
X
larg
est
a3 :
y is
X
larg
est
a4 :
z is
X
larg
est
a5 :
Imp
X
ossi
ble
To represent some impossible combinations of causes or impossible combinations of effects, constraints are
used. The following constraints are used in cause-effect graphs:
1. Exclusive constraint or E-constraint: This constraint exists between causes. It states that either c1 or c2
can be 1, i.e., c1 and c2 cannot be 1 simultaneously.
2. Inclusive constraint or I-constraint: This constraint exists between causes. It states that atleast one of c1,
c2 and c3 must always be 1, i.e., c1, c2 and c3 cannot be 0 simultaneously.
3. One and Only One constraint or O-constraint: This constraint exists between causes. It states that one
and only one of c1 and c2 must be 1.
4. Requires constraint or R-constraint: This constraint exists between causes. It states that for c1 to be 1, c2
must be 1. It is impossible for c1 to be 1 and c2 to be 0.
5. Mask constraint or M-constraint: This constraint exists between effects. It states that if effect e1 is 1, the
effect e2 is forced to be 0.
Error Guessing Technique
The test cases for finding issues in the software are written based on the prior testing experience with
similar applications. So, the scope of the test cases would generally depend upon the kind of testing Test
Analyst was involved in the past. The Error Guessing technique does not follow any specific rules.
For Example, if the Analyst guesses that the login page is error-prone, then the testers will write detailed
test cases concentrating on the login page. Testers can think of a variety of combinations of data to test the
login page.
To design test cases based on the Error Guessing technique, the Analyst can use past experiences to
identify the conditions.
This technique can be used at any level of testing and for testing the common mistakes like:
Divide by zero
Entering blank spaces in the text fields
Pressing the submit button without entering values.
Uploading files exceeding maximum limits.
Null pointer exception.
Invalid parameters
The achievement rate of this technique does mainly depends upon the ability of testers.
The box testing approach of software testing consists of black box testing and white box testing. We are
discussing here white box testing which also known as glass box is testing, structural testing, clear box
testing, open box testing and transparent box testing. It tests internal coding and infrastructure of a
software focus on checking of predefined inputs against expected and desired outputs. It is based on inner
workings of an application and revolves around internal structure testing. In this type of testing
programming skills are required to design test cases. The primary goal of white box testing is to focus on
the flow of inputs and outputs through the software and strengthening the security of the software.
The term 'white box' is used because of the internal perspective of the system. The clear box or white box
or transparent box name denote the ability to see through the software's outer shell into its inner workings.
Developers do white box testing. In this, the developer will test every line of the code of the program. The
developers perform the White-box testing and then send the application or the software to the testing team,
where they will perform the black box testing and verify the application along with the requirements and
identify the bugs and sends it to the developer.
The white box testing contains various tests, which are as follows:
o Path testing
o Loop testing
o Condition testing
o Testing based on the memory perspective
o Test performance of the program
Do – While –
While – Do –
Switch – Case –
Cyclomatic Complexity –
The cyclomatic complexity V(G) is said to be a measure of the logical complexity of a program. It can be
calculated using three different formulae :
1. Formula based on edges and nodes :
V(G) = e - n + 2*P
Where,
e is number of edges,
n is number of vertices,
P is number of connected components.
For example, consider first graph given above,
where, e = 4, n = 4 and p = 1
So,
Cyclomatic complexity V(G)
=4-4+2*1
=2
2. Formula based on Decision Nodes :
V(G) = d + P
where,
d is number of decision nodes,
P is number of connected nodes.
For example, consider first graph given above,
where, d = 1 and p = 1
So,
Cyclomatic Complexity V(G)
=1+1
=2
3. Formula based on Regions :
V(G) = number of regions in the graph
For example, consider first graph given above,
Cyclomatic complexity V(G)
= 1 (for Region 1) + 1 (for Region 2)
=2
Hence, using all the three above formulae, the cyclomatic complexity obtained remains same. All these
three formulae can be used to compute and verify the cyclomatic complexity of the flow graph.
Note –
1. For one function [e.g. Main( ) or Factorial( ) ], only one flow graph is constructed. If in a program, there
are multiple functions, then a separate flow graph is constructed for each one of them. Also, in the
cyclomatic complexity formula, the value of ‘p’ is set depending of the number of graphs present in total.
2. If a decision node has exactly two arrows leaving it, then it is counted as one decision node. However, if
there are more than 2 arrows leaving a decision node, it is computed using this formula :
d=k-1
Here, k is number of arrows leaving the decision node.
Independent Paths :
An independent path in the control flow graph is the one which introduces at least one new edge that has
not been traversed before the path is defined. The cyclomatic complexity gives the number of independent
paths present in a flow graph. This is because the cyclomatic complexity is used as an upper-bound for the
number of tests that should be executed in order to make sure that all the statements in the program have
been executed at least once.
Consider first graph given above here the independent paths would be 2 because number of independent
paths is equal to the cyclomatic complexity.
So, the independent paths in above first given graph :
Path 1:
A -> B
Path 2:
C -> D
Note –
Independent paths are not unique. In other words, if for a graph the cyclomatic complexity comes out be N,
then there is a possibility of obtaining two different sets of paths which are independent in nature.
Design Test Cases :
Finally, after obtaining the independent paths, test cases can be designed where each test case represents
one or more independent paths.
Advantages :
Basis Path Testing can be applicable in the following cases:
1. More Coverage –
Basis path testing provides the best code coverage as it aims to achieve maximum logic coverage instead of
maximum path coverage. This results in an overall thorough testing of the code.
2. Maintenance Testing –
When a software is modified, it is still necessary to test the changes made in the software which as a result,
requires path testing.
3. Unit Testing –
When a developer writes the code, he or she tests the structure of the program or module themselves first.
This is why basis path testing requires enough knowledge about the structure of the code.
4. Integration Testing –
When one module calls other modules, there are high chances of Interface errors. In order to avoid the case
of such errors, path testing is performed to test all the paths on the interfaces of the modules.
5. Testing Effort –
Since the basis path testing technique takes into account the complexity of the software (i.e., program or
module) while computing the cyclomatic complexity, therefore it is intuitive to note that testing effort in
case of basis path testing is directly proportional to the complexity of the software or program.
Let’s convert this control flow graph into a graph matrix. Since the graph has 4 nodes, so the graph matrix
would have a dimension of 4 X 4. Matrix entries will be filled as follows :
(1, 1) will be filled with ‘a’ as an edge exists from node 1 to node 1
(1, 2) will be filled with ‘b’ as an edge exists from node 1 to node 2. It is important to note that (2, 1) will
not be filled as the edge is unidirectional and not bidirectional
(1, 3) will be filled with ‘c’ as edge c exists from node 1 to node 3
(2, 4) will be filled with ‘d’ as edge exists from node 2 to node 4
(3, 4) will be filled with ‘e’ as an edge exists from node 3 to node 4
The graph matrix formed is shown below :
Connection Matrix :
A connection matrix is a matrix defined with edges weight. In simple form, when a connection exists
between two nodes of control flow graph, then the edge weight is 1, otherwise, it is 0. However, 0 is not
usually entered in the matrix cells to reduce the complexity.
For example, if we represent the above control flow graph as a connection matrix, then the result would be :
As we can see, the weight of the edges are simply replaced by 1 and the cells which were empty before are
left as it is, i.e., representing 0.
A connection matrix is used to find the cyclomatic complexity of the control graph.
Although there are three other methods to find the cyclomatic complexity but this method works well too.
Following are the steps to compute the cyclomatic complexity :
1. Count the number of 1s in each row and write it in the end of the row
2. Subtract 1 from this count for each row (Ignore the row if its count is 0)
3. Add the count of each row calculated previously
4. Add 1 to this total count
5. The final sum in Step 4 is the cyclomatic complexity of the control flow graph
Let’s apply these steps to the graph above to compute the cyclomatic complexity.
We can verify this value for cyclomatic complexity using other methods :
Method-1 :
Cyclomatic complexity
=e-n+2*P
Since here,
e=5
n=4
and, P = 1
Therefore, cyclomatic complexity,
=5-4+2*1
=3
Method-2 :
Cyclomatic complexity
=d+P
Here,
d=2
and, P = 1
Therefore, cyclomatic complexity,
=2+1
=3
Method-3:
Cyclomatic complexity
= number of regions in the graph
li
Region 1: bounded by edges b, c, d, and e
Region 2: bounded by edge a (in loop)
Region 3: outside the graph
Therefore, cyclomatic complexity,
=1+1+1
=3
It can be seen that all other methods give the same result. Method1, 2, and 3 have been discussed here in
detail.
Loop Testing is a type of software testing type that is performed to validate the loops. It is one of the type
of Control Structure Testing. Loop testing is a white box testing technique and is used to test loops in the
program.
Objectives of Loop Testing:
The objective of Loop Testing is:
To fix the infinite loop repetition problem.
To know the performance.
To identify the loop initialization problems.
To determine the uninitialized variables.
Types of Loop Testing:
Loop testing is classified on the basis of the types of the loops:
1. Simple Loop Testing:
Testing performed in a simple loop is known as Simple loop testing. Simple loop is basically a normal
“for”, “while” or “do-while” in which a condition is given and loop runs and terminates according to true
and false occurrence of the condition respectively. This type of testing is performed basically to test the
condition of the loop whether the condition is sufficient to terminate loop after some point of time.
Example:
while(condition)
{
statement(s);
}
X 1 2, 3
Y 1 2, 4
A 3, 4 5
Changed Code:
if(a < b)
c = 10;
else
c = 20;
Changed Code:
if(a > b)
c = 10;
else
c = 20;
3. Statement Mutations:
In statement mutations a statement is deleted or it is replaces by some other statement.
Example:
Initial Code:
if(a < b)
c = 10;
else
c = 20;
Changed Code:
if(a < b)
d = 10;
else
d = 20;
Advantages of Mutation Testing:
It brings a good level of error detection in the program.
It discovers ambiguities in the source code.
Disadvantages of Mutation Testing:
It is highly costly and time-consuming.
It is not able for Black Box Testing.
Software Testing | Static Testing
Static Testing is a type of a Software Testing method which is performed to check the defects in software
without actually executing the code of the software application. Whereas in Dynamic Testing checks the
code is executed to detect the defects.
Static testing is performed in early stage of development to avoid errors as it is easier to find sources of
failures and it can be fixed easily. The errors that can’t not be found using Dynamic Testing, can be easily
found by Static Testing.
Static Testing Techniques:
There are mainly two type techniques used in Static Testing:
1. Review:
In static testing review is a process or technique that is performed to find the potential defects in the design
of the software. It is process to detect and remove errors and defects in the different supporting documents
like software requirements specifications. People examine the documents and sorted out errors,
redundancies and ambiguities.
Review is of four types:
Informal:
In informal review the creator of the documents put the contents in front of audience and everyone gives
their opinion and thus defects are identified in the early stage.
Walkthrough:
It is basically performed by experienced person or expert to check the defects so that there might not be
problem further in the development or testing phase.
Peer review:
Peer review means checking documents of one-another to detect and fix the defects. It is basically done in a
team of colleagues.
Inspection:
Inspection is basically the verification of document the higher authority like the verification of software
requirement specifications (SRS).
2. Static Analysis:
Static Analysis includes the evaluation of the code quality that is written by developers. Different tools are
used to do the analysis of the code and comparison of the same with the standard.
It also helps in following identification of following defects:
(a) Unused variables
(b) Dead code
(c) Infinite loops
(d) Variable with undefined value
(e) Wrong syntax
Static Analysis is of three types:
Data Flow:
Data flow is related to the stream processing.
Control Flow:
Control flow is basically how the statements or instructions are executed.
Cyclomatic Complexity:
Cyclomatic complexity is the measurement of the complexity of the program that is basically related to the
number of independent paths in the control flow graph of the program
Regression testing is a black box testing techniques. It is used to authenticate a code change in the software
does not impact the existing functionality of the product. Regression testing is making sure that the product
works fine with new functionality, bug fixes, or any change in the existing feature.
Regression testing is a type of software testing. Test cases are re-executed to check the previous
functionality of the application is working fine, and the new changes have not produced any bugs.
Mainly there are 5 types of Regression testing techniques. Each of the techniques is applicable for different
purposes. Some technique requires fewer resources while some require a lot of resources but that technique
will provide the result with greater details.
The type of technique used in regression testing varies from project to project and from organization to
organization. Some organization prefers to use a particular regression testing technique in all their
projects. The 5 main categories of regression testing methods are:
It is used when no changes are introduced in the current application or software or product specifications.
In this case, we can use the test cases which have already been created to perform the testing.
This technique of regression testing is used in situations when new changes are introduced in the software’s
specification and new test cases need to be designed to perform the desired tests. The progressive
regression testing works very effectively when certain changes are introduced in the software’s
specification and when new test cases are designed.
In this technique, a part of the test cases is taken from the prevailing test cases and used which reduces the
cost and effort involved in designing all the new test cases.
This technique of regression testing is used to analyze the effects of the newly added code which is
introduced in the software to the already existing code in the software. In order to reduce the retesting
efforts and cost involved in selective regression testing, we use a part of the current experiments.
In this technique, a test case is re-executed if any new change is introduced in any module or part of the
software or application like factors, capacities and so on. In selective regression testing, the condition
between the experiment and the elements covered by the program are very difficult to determine.
As the name suggests this technique of regression testing involves reusing all the test cases and also testing
all the possible aspects of the product or software even when a new change is introduced in the software or
not.
This technique is time-consuming and very tedious. This is very expensive as it requires a huge amount of
resources because we test all the aspects of the software and all the tests in the existing test bucked have to
be re-executed.
The retest-all regression testing is not advised to use when only a small change is introduced in the
software or the product.
We have already discussed this in the types of regression testing. The complete regression testing is used
more often when multiple changes are introduced in the software and it is also used in the case when the
changes made in the software affect the root or the core of the software.
This is beneficial as it helps in identifying the unseen problems. After the testing is complete the final
software or the product is provided to the end-users.
UNIT III MANAGING THE TESTING PROCESS 9
Test Management – Software Metrics – Testing Metrics for Monitoring and Controlling the Testing
Process – Efficient Test Suit Management
Test Management :
Test Management is a process where testing activities are managed to ensure high-quality and high-end
testing of software applications. This method consists of tracking, organization, controlling process,
checks the visibility of the testing process in order to deliver a high-quality software application. It
makes sure the software testing process run as expected.
Test Management Process :
It is a software process that manages the start to the end of all software testing act ivities. This
management process provides planning, controlling, tracking, and monitoring facilities throughout the
whole group cycle, these process includes several activities like test case design and test execution, test
planning, etc. It also gives initial plan and discipline specifications to the software testing process.
Responsibilities:
Works in collaboration with test analyst and technical test analyst to select and customizes the
appropriate templates and also establish standards.
Provides all facilities to keep track and control the testing throughout the project.
Gives the clear concept of understanding of the testing activity of the prior upcoming project and also
post ones
Test management process has two main parts of test Management Process:
Planning :
Risk analysis
Test Estimation
Test planning
Execution :
Testing Activity
Issue Management
Test report and evolution
The activity of the test process :
1. Test plan –
Rough sketches are served in order to test plans to convey the process of testing. Gives a clear vision of
the complete testing process.
2. Test design –
Test design affords the implementation process of testing.
3. Test execution –
It shows the actual system result against the expected result during test execution.
4. Exit criteria –
It gives the signal when to stop the test execution process.
5. Test reporting –
Test reporting picturizes the test process and result for the particular testing cycle.
Tools :
Some commonly used tools are listed below-
1. qTest
2. Zephyr
3. Test Collab
4. XQual
5. TestRail
6. Testpad
Advantages :
Reuses current test and compares the results with last trials.
Prevents duplicate issues
Enables conceptual graphical visualization regarding reports
Reports errors via email
Combines easily with automation tools and C
Deals with tests accordingly to the requirements effortlessly
Integrated quickly with slack
Deals test based on cycle and sprints
Disadvantages :
It is not cost-effective
Doesn’t support cloud-based application
No mobile app support
Software Testing Metrics: Definition, Types & Example
Software TestingSoftware & CodingTesting Tools
Software Testing metrics are quantitative steps taken to evaluate the software testing process's quality,
performance, and progress. This helps us to accumulate reliable data about the software testing process and
enhance its efficiency. This will allow developers to make proactive and precise decisions for upcoming
testing procedures.
What is a metric in software testing metrics?
A Metric is a degree to which a system or its components retains a given attribute. Testers don't define a
metric just for the sake of documentation. It serves greater purposes in software testing. For example,
developers can apply a metric to assume the time it takes to develop software. It can also be assigned to
determine the numbers of new features and modifications, etc., added to the software.
Importance of Software Testing Metrics
As mentioned, test metrics are crucial to measuring the quality and performance of the software. With
proper software testing metrics, developers can−
Determine what types of improvements are required to deliver a defect-free, quality software
Make sound decisions about the subsequent testing phases, such as scheduling upcoming projects as well as
estimating the overall cost of those projects
Evaluate the current technology or process and check whether it needs further modifications
Types of software testing metrics
There are three types of software testing metrics−
Process Metrics: Process metrics define the characteristics and execution of a project. These
characteristics are essential to the improvement and maintenance of the process in the SDLC (Software
Development Life Cycle).
Product Metrics: Product metrics define the size, design, performance, quality, and complexity of a
product. By using these characteristics, developers can enhance their software development quality.
Project Metrics: Project Metrics determine the overall quality of a project. It is used to calculate costs,
productivity, defects and estimate the resource and deliverables of a project.
It is incredibly vital to identify the correct testing metrics for the process. Few factors to consider−
Choose your target audiences wisely before preparing the metrics
Define the goal behind designing the metrics
Prepare metrics by considering the specific requirements of the project
Evaluate the financial gain behind each metrics
Pair the metrics with the project lifestyle phase that delivers optimum output
Software testing can be further divided into manual and automated testing.
In manual testing, the test is performed by QA analysts in a step-by-step process. Meanwhile, in automated
testing, tests are executed with the help of test automation frameworks, tools, and software.
Both manual and automated testing has its strength and weakness.
Manual testing is a slow process, but it allows testers to handles complex scenarios.
The most significant advantage of automated testing is that it enables testers to run more testing in less
time, covering a substantial level of permutations, which is nearly impossible to calculate manually.
Types of Manual Test Metrics
Manual Test Metrics are of two types−
Base Metrics
Base metrics are data collected by analysts during test case development and execution. These metrics are
submitted to test leads and project managers by preparing a project status report. It is quantified by using
calculated metrics −
Number of test cases
Number of test cases executed
Calculated Metrics
Calculated metrics are derived using data from base metrics. The test lead gathers these data and converts
them to more meaningful information for tracking the progress of projects at the module level, tester level,
etc.
It comprises a significant part of SDLC and empowers developers to make vital improvements in software.
Most used Metrics
Below are the types of metrics, popularly used by developers and testers
Defect metrics: This metric allows developers to understand the various quality aspects of software,
including functionality, performance, installation stability, usability, compatibility, etc.
Defects finding rate: It is used to identify the pattern of defects during a specific timeframe
Defect severity: It enables the developer to understand how the defect is going to impact the quality of the
software.
Defect cause: It is used to understand the root cause of the defect.
Test Coverage: It defines how many test cases are assigned to the program. This metric ensures the testing
is conducted to its full completion. It further aids in checking the code flow and test functionalities.
Defect fixing time: It determines the amount of time it takes to resolve a defect
Test case efficiency: It tells the efficiency rate of test cases in finding defects
Schedule adherence: Its primary motive is to figure out the time difference between the planned schedule
and the actual time of executing a schedule.
Test Metrics Life Cycle
The life cycle of test metrics consists of four stages−
Analysis: In this stage, developers identify the required metrics and define them.
Communicate: Once metrics are identified, developers have to explain their importance to stakeholders
and the testing team.
Evaluation: This stage includes quantifying and verifying the data. Then testers have to use the data to
calculate the value of the metric.
Report: Once the evaluation process is finished, the development team needs to create a report including a
detailed summary of the conclusion. Then the report is distributed among stakeholders and relevant
representatives. The stakeholders then give their feedback after reading the information carefully.
Test Monitoring and Test Control is basically a management activity. Test Monitoring is a process of
evaluating and providing feedback on the “currently in progress” testing phase. Test Control is an activity
of guiding and taking corrective action based on some metrics or information to improve efficiency and
quality.
What is Test Monitoring?
Test Monitoring in test execution is a process in which the testing activities and testing efforts are
evaluated in order to track current progress of testing activity, finding and tracking test metrics, estimating
the future actions based on the test metrics and providing feedback to the concerned team as well as
stakeholders about current testing process.
What is Test Control?
Test Control in test execution is a process of taking actions based on results of the test monitoring process.
In the test control phase, test activities are prioritized, test schedule is revised, test environment is
reorganized and other changes related to testing activities are made in order to improve the quality and
efficiency of future testing process.
What do we monitor?
Monitoring will allow you to make comparisons between your original plan and your progress so far. You
will be able to implement changes, where necessary, to complete the project successfully.In your project, as
the Test Manager, you should monitor the key parameters as below
How to monitor?
As your project comes to life, keep these questions in mind:
Are you on schedule? If not, how far behind are you, and how can you catch up?
Are you over budget?
Are you still working toward the same project goal?
Are you running low on resources?
Are there warning signs of impending problems?
Is there pressure from management to complete the project sooner?
These are just a few of the questions you should ask yourself as you monitor the progress of your project.
It is important to monitor the progress of the project so you will know if adjustments need to be made to get
it moving back in the right direction. To monitor project progress effectively, you should follow the
following steps
best Practices in Test Monitoring and Control
Follow the standards: One important consideration of project planning is to ensure standardization. It
means that all the project activities must follow the standard process guideline. Standardized processes,
tools, templates, and measurement values make analysis easy, facilitate easy communications, and help the
project team members understand the situation better.
Documentation: What will happen if you do not write down any discussion or decision in a document?
You may forget them and lose many things. You should write down discussions and decisions at the
appropriate place, and establishing a formal documentation procedure for meetings. Such documentation
helps you to resolve issues of miscommunication or misunderstandings among the project team.
Proactivity: Issues occur in all projects. The important thing is that you have to adopt a proactive approach
to solve issues and problems that arise during project execution. Such issues could be budget, scope, time,
quality, and human resources
To get the percentage execution status of the test cases, the following formula can be used: Percentage
test cases executed = (No of test cases executed / Total no of test cases written) x 100
Percentage test cases executed = (No of test cases of test cases written) x 100
Similarly, it is possible to calculate for other parameters also such as test cases that were not executed,
test cases that were passed, test cases that were failed, test cases that were blocked, and so on. Below are
some of the formulas:
1. Test Case Effectiveness: Test Case Effectiveness = (Number of defects detected / Number of test
cases run) x 100
Test Case Effectiveness = (Number of defects detected / Number of test cases run) x 100
2. Passed Test Cases Percentage: Test Cases that Passed Coverage is a metric that indicates the
percentage of test cases that pass. Passed Test Cases Percentage = (Total number of tests ran / Total
number of tests executed) x 100
Passed Test Cases Percentage = (Total number of tests ran / Total executed) x 100
3. Failed Test Cases Percentage: This metric measures the proportion of all failed test cases. Failed
Test Cases Percentage = (Total number of failed test cases / Total number of tests executed) x 100
Failed Test Cases Percentage = (Total number of failed test cases / Total number) x 100
4. Blocked Test Cases Percentage: During the software testing process, this parameter determines the
percentage of test cases that are blocked. Blocked Test Cases Percentage = (Total number of blocked
tests / Total number of tests executed) x 100
Blocked Test Cases Percentage = (Total number of blocked tests / Total number) x 100
5. Fixed Defects Percentage: Using this measure, the team may determine the percentage of defects that
have been fixed. Fixed Defects Percentage = (Total number of flaws fixed / Number of defects
reported) x 100
Fixed Defects Percentage = (Total number of flaws fixed / Number of defects reported) x 100
6. Rework Effort Ratio: This measure helps to determine the rework effort ratio. Rework Effort Ratio =
(Actual rework efforts spent in that phase/ Total actual efforts spent in that phase) x 100
Rework Effort Ratio = (Actual rework efforts spent in that phase/ Total actual efforts spent in that
phase) x 100
7. Accepted Defects Percentage: This measures the percentage of defects that are accepted out of the
total accepted defects. Accepted Defects Percentage = (Defects Accepted as Valid by Dev Team / Total
Defects Reported) x 100
Accepted Defects Percentage = (Defects Accepted as Valid by Dev Team / Total Defects Reported) x
100
8. Defects Deferred Percentage: This measures the percentage of the defects that are deferred for future
release. Defects Deferred Percentage = (Defects deferred for future releases / Total Defects Reported)
x 100
Defects Deferred Percentage = (Defects deferred for future releases / Total Defects Reported) x 100
1 No. of requirements 5
12 Defects fixed 12
Software testing is a continuous process that takes place throughout lifecycle of project. Test cases in an
existing test suite can often be used to test a modified program. However, if the test suite is inadequate for
retesting, new test cases may be developed and added to test suite. Thus, size of test suite groups as
software evolves. Test suite can also be reused later as software evolves. Such test suite, reuse in the form
of regression testing. Running all the test cases, however can require lot of efforts. Thus due to obsolete and
redundant data, size of test suite continues to grow unnecessarily.
Following are the reasons why use need test suite minimization
Release date of product is near.
Limited staff to execute all the test cases.
Limited test equipment’s or unavailability of testing tools.
Advantages of minimization:
Reluctant test cases will be eliminated.
Lowers the cost by reducing test suite to minimal subset.
Reducing size of test suite decreases the overhead of maintenance of test suite and reduces the efforts and
cost required in regression testing.
The tester’s day-to-day activities include:
1. Creating and maintaining release/project cycle/component information.
2. Creating and maintaining the test artifacts specific to each release/cycle for which we have- requirements,
test cases, etc.
3. Establishing traceability and coverage of the test assets.
4. Test execution support – test suite creation, test execution status capture, etc.
5. Metric collection/report-graph generation for analysis.
6. Bug tracking/defect management.
List of Best Test Management Tools in 2022
#1) Zephyr Scale
#2) PractiTest
#3) Zephyr Squad
#4) TestCollab
#5) Requirements and Test Management for Jira (RTM)
#6) XQual
#7) Xray – Cutting Edge Test Management
#8) TestRail
#9) Kualitee
#10) TestFLO for JIRA
The agile Testing methodology has gained a lot of importance and popularity nowadays when it comes
to software testing modern-day software. It is an intelligent way of testing complex software that bears
more efficient end results than traditional testing methods.
This is a complete guide to Agile Testing, explaining all the important aspects related to it.
What is Agile Testing?
Agile Testing Methodology
Agile Testing Life-Cycle
Agile Test Plan
Agile Testing Strategies
Agile Testing Quadrants
Difference Between Agile Testing Vs Waterfall Testing
Advantages of Agile Testing
What is Agile Testing?
Agile testing is an iterative and incremental testing process in which software requirements are gathered
gradually throughout the testing process.
Agile Testing is a part of the Agile Software development process which is carried out with the help of
customer’s involvement. The agile testing process starts at the beginning of the software development
process and there is no integration required between the development and testing processes.
As the development and testing are integrated into this process, it allows early error detection and removal
which results in less development time as well as costs. This also ensures high product quality as errors get
removed in the initial stage itself.
The basic principles on which Agile Testing is conducted are:
Agile testing is a continuous process and it ensures smooth project progress.
Product and business requirements are realized through continuous feedback. Feedback are provided on an
on-going basis.
In Agile Testing, the development team, testing team, and the customers, all are involved in the testing
process.
There is very little documentation required in Agile Testing as all the testers us a reusable checklist instead
of lengthy documents. The main focus is on the test in this process.
The errors are resolved by the testing team as and when they occur, in the same iteration. This results in
simpler and clean code.
Traditional testing is performed after the software is developed. However, agile testing is performed along
with the development process which helps reducing development time
Agile Testing Methodology
The first phase is creating Agile Test Plans. In this phase, all the stakeholders: developers, testers,
customers and users, come together and plan testing schedules.
Daily Scrums
The goals and targets of the day are set at the start of each day. It helps testers realize the status of the
testing.
Release Readiness
In this phase, testers decide which assess which features are completely developed and ready to go live and
which ones need to go back to the previous development phase.
Impact Assessment
This phase is the feedback phase of the life cycle which helps testers set goals for the next life-cycle. The
inputs and feedback are collected from users and stakeholders to perform an impact assessment.
Here are a few guidelines for cases in which Agile may not be the best way to test:
1. When the project scope is crystal clear and very unlikely to change
2. When the project is governed by a single product owner or stakeholder with minimal requirements
3. When the people on your team lack the deep, broad skills necessary to perform Agile testing
4. When the customer insists on using a traditional waterfall approach to testing
Tools are used for test execution, Test data generations, and requirements management.
Tools that help in managing the tests.
Purpose of tool
To automate repetitive tasks and to improve efficiency
Automate activities that require significant resources when done manually
Automate tasks that can’t be executed manually
Increase reliability of testing
Test Management tool- Provides interfaces for test execution, defect logging and managing requirements etc
Requirements Management Tool- Provide interfaces for storing requirements, uniquely identify requirements,
tracing requirements
Configuration Management Tool-For storage and version management of test ware and related software
Review Tools-Helps in review process, check lists, guidelines and are used to store and communicate review
comments.
Static Analysis Tools (D)-Helps both developers and testers find defects prior to dynamic testing
Modeling tools-Helps to validate the models like PDM (Physical Data Model)
Test Design Tool-Used to generate test inputs or executable tests and / or test oracles from requirements,
Test Data Preparation Tool-Manipulate DB, files or data transmissions to set up test data to be used during the
execution of tests
Test Execution Tools-To execute tests automatically, uses scripting languages and parameterization techniques
Test Harness/Unit Frame Work Tools(D)- It facilitates the testing of components or parts of a system by
simulating the environment in which that object will run, provision of mock objects such as stubs, drivers.
Test Comparators-Compares the diff between files, DBs or test results.
Coverage Measurement Tools (D) - Measuring the % of specific types of code structures that have been exercised
Security Testing Tools- To evaluate the security characteristics of a SW like data confidentiality, integrity,
Dynamic Analysis Tool (D)-Find defects which are evident only when the SW is running such as time
Stress Testing/Load Testing/Performance Testing tools- Monitor and report on how a system behaves under a
variety of simulated conditions like load, concurrent users, and relative percentage of transactions
Monitoring Tools- Continuously analyze, verify and report on usage of specific system resources and give
Data Quality Assessment Tool- Data is at the center of some projects such as data conversion/migration projects
Benefits of Tools
Risks of Tools
Assessment of organizational maturity, strengths and weaknesses for an improved test process
supported by tools
It is, basically the fundamental attribute associated with each and every software artifact that enables to
compute amount of effort required in performing testing. Lesser the testability, larger will be the efforts
whereas greater testability ensures minimal efforts.
Controllability: It defines the control over software and hardware behaviour and comp. Testers should be
able to control each module or layers of the software, independently. The better our control, the more
effective will be testing.
Observability: You can't test unless & until you perceive something. You can only test, what is visible to
you. It is related to observation of states and factors affecting the output of the software.
Availability: It defines the availability of the objects or entities, to carry out the testing. This may include
software product evolution at various stages of development, bugs in the software, access to the source
code, etc.
Simplicity : The simplicity makes everything easier to use. Lesser efforts are required in testing the simple
software product. The simplicity of software may depend upon its functional, structural and code
simplicity.
Stability: Lesser the changes, better will be the testing. The software product should be stable enough and
does not require frequent modification in it. It also examines that changes (if any needed), should be
controlled and communicated.
Provides ease to test engineers, to estimate the difficulty, in exploring the defects in the software product.
Decides the scope of automated testing on the software product, based on its controllability.
Increased in testability ensures the easy and early detection of bugs, thereby saves both time and cost.
Calculates, minimizes and control the efforts needed by the testers, to perform testing.
The goal of this article is to walk through the most common types of frameworks used today and the
benefits and disadvantages of each. For QA professionals new to automated testing, or those who need a
quick refresher, this article will provide a high-level overview of each type of framework and how they can
contribute to the success of any automated testing process.
Before diving into the most common types of frameworks and their benefits, let’s clarify what a test
automation framework actually is. A testing framework is a set of guidelines or rules used for creating and
designing test cases. A framework is comprised of a combination of practices and tools that are designed to
help QA professionals test more efficiently.
These guidelines could include coding standards, test-data handling methods, object repositories, processes
for storing test results, or information on how to access external resources.
While these are not mandatory rules and testers can still script or record tests without following them, using
an organized framework typically provides additional benefits that would otherwise be missed out on.
There are six common types of test automation frameworks, each with their own architecture and differing
benefits and disadvantages. When building out a test plan, it’s important to choose the framework that is
right for you.
There is no need to write custom code, so expertise in test automation is not necessary.
This is one of the fastest ways to generate test scripts since they can be easily recorded in a minimal
amount of time.
The test workflow is easier to understand for any party involved in testing since the scripts are laid out in a
sequential manner.
This is also the easiest way to get up and running with automated testing, especially with a new tool. Most
automated testing tools today will provide record-and-playback features, so you also won’t need to plan
extensively with this framework.
Disadvantages:
The scripts developed using this framework aren’t reusable. The data is hardcoded into the test script,
meaning the test cases cannot be re-run with multiple sets and will need to be modified if the data is altered.
Maintenance is considered a hassle because any changes to the application will require a lot of rework. This
model is not particularly scalable as the scope of testing expands.
Modular Based Testing Framework
Implementing a modular framework will require testers to divide the application under test into separate
units, functions, or sections, each of which will be tested in isolation. After breaking down the application
into individual modules, a test script is created for each part and then combined to build larger tests in a
hierarchical fashion. These larger sets of tests will begin to represent various test cases.
A key strategy in using the modular framework is to build an abstraction layer, so that any changes made in
individual sections won’t affect the overarching module.
If any changes are made to the application, only the module and it’s associated individual test script will
needs to be fixed, meaning you won’t have to tinker with the rest of the application and can leave it
untouched.
Creating test cases takes less effort because test scripts for different modules can be reused.
Disadvantages of a Modular Framework:
Data is still hard-coded into the test script since the tests are executed separately, so you can’t use multiple
data sets.
Programming knowledge is required to set up the framework.
Library Architecture Testing Framework
The library architecture framework for automated testing is based on the modular framework, but has some
additional benefits. Instead of dividing the application under test into the various scripts that need to be run,
similar tasks within the scripts are identified and later grouped by function, so the application is ultimately
broken down by common objectives. These functions are kept in a library which can be called upon by the
test scripts whenever needed.
Similar to the modular framework, utilizing this architecture will lead to a high level of modularization,
which makes test maintenance and scalability easier and more cost effective.
This framework has a higher degree of reusability because there is a library of common functions that can
be used by multiple test scripts.
Disadvantages:
Test data is still hard coded into the script. Therefore, any changes to the data will require changes to the
scripts.
Technical expertise is needed to write and analyze the common functions within the test scripts.
Test scripts take more time to develop.
Data-Driven Framework
Using a data-driven framework separates the test data from script logic, meaning testers can store data
externally. Very frequently, testers find themselves in a situation where they need to test the same feature
or function of an application multiple times with different sets of data. In these instances, it’s critical that
the test data not be hard-coded in the script itself, which is what happens with a Linear or Modular-based
testing framework.
Setting up a data-driven test framework will allow the tester to store and pass the input/ output parameters
to test scripts from an external data source, such as Excel Spreadsheets, Text Files, CSV files, SQL Tables,
or ODBC repositories.
The test scripts are connected to the external data source and told to read and populate the necessary data
when needed.
You’ll need a highly-experienced tester who is proficient in various programming languages to properly
utilize this framework design. They will need to identify and format the external data sources and to write
code (create functions) that connect the tests to those external data sources seamlessly.
Setting up a data-driven framework takes a significant amount of time.
Keyword-Driven Framework
In a keyword-driven framework, each function of the application under test is laid out in a table with a
series of instructions in consecutive order for each test that needs to be run. In a similar fashion to the data-
driven framework, the test data and script logic are separated in a keyword-driven framework, but this
approach takes it a step further.
With this approach, keywords are also stored in an external data table (hence the name), making them
independent from the automated testing tool being used to execute the tests. Keywords are the part of a
script representing the various actions being performed to test the GUI of an application. These can be
labeled as simply as ‘click,’ or ‘login,’ or with complex labels like ‘clicklink,’ or ‘verifylink.’
In the table, keywords are stored in a step-by-step fashion with an associated object, or the part of the UI
that the action is being performed on. For this approach to work properly, a shared object repository is
needed to map the objects to their associated actions.
Keyword Table:
Step Number Description Keyword Object Action
Step 1 Click user portal link on homepage clicklink Login Button
Step 2 Enter user name Inputdata Login Username
Step 3 Enter password Inputdata Login password
Step 4 Verify user log in information verifylogin
Step 5 Log in to the application login Submit Button
Once the table has been set up, all the testers have to do is write the code that will prompt the necessary
action based on the keywords. When the test is run, the test data is read and pointed towards the
corresponding keyword which then executes the relevant script.
Disadvantages:
The initial cost of setting up the framework is high. It is time-consuming and complex. The keywords need
to be defined and the object repositories / libraries need to be set up.
You need an employee with good test automation skills.
Keywords can be a hassle to maintain when scaling a test operation. You will need to continue building out
the repositories and keyword tables.
Hybrid Test Automation Framework
As with most testing processes today, automated testing frameworks have started to become integrated and
overlap with one another. As the name suggests, a hybrid framework is a combination of any of the
previously mentioned frameworks set up to leverage the advantages of some and mitigate the weaknesses
of others.
Every application is different, and so should the processes used to test them. As more teams move to an
agile model, setting up a flexible framework for automated testing is crucial. A hybrid framework can be
more easily adapted to get the best test results.
Software typically undergoes many levels of testing, from unit testing to system or acceptance testing.
Typically, in-unit testing, small “units”, or modules of the software, are tested separately with focus on
testing the code of that module. In higher, order testing (e.g, acceptance testing), the entire system (or a
subsystem) is tested with the focus on testing the functionality or external behavior of the system.
As information systems are becoming more complex, the object-oriented paradigm is gaining popularity
because of its benefits in analysis, design, and coding. Conventional testing methods cannot be applied for
testing classes because of problems involved in testing classes, abstract classes, inheritance, dynamic
binding, message, passing, polymorphism, concurrency, etc.
Testing classes is a fundamentally different problem than testing functions. A function (or a procedure) has
a clearly defined input-output behavior, while a class does not have an input-output behavior specification.
We can test a method of a class using approaches for testing functions, but we cannot test the class using
these
approaches.
According to Davis the dependencies occurring in conventional systems are:
Data dependencies between variables
Calling dependencies between modules
Functional dependencies between a module and the variable it computes
Definitional dependencies between a variable and its types.
But in Object-Oriented systems there are following additional dependencies:
Class to class dependencies
Class to method dependencies
Class to message dependencies
Class to variable dependencies
Method to variable dependencies
Method to message dependencies
Method to method dependencies
Issues in Testing Classes:
Additional testing techniques are, therefore, required to test these dependencies. Another issue of interest is
that it is not possible to test the class dynamically, only its instances i.e, objects can be tested. Similarly, the
concept of inheritance opens various issues e.g., if changes are made to a parent class or superclass, in a
larger system of a class it will be difficult to test subclasses individually and isolate the error to one class.
In object-oriented programs, control flow is characterized by message passing among objects, and the
control flow switches from one object to another by inter-object communication. Consequently, there is no
control flow within a class like functions. This lack of sequential control flow within a class requires
different approaches for testing. Furthermore, in a function, arguments passed to the function with global
data determine the path of execution within the procedure. But, in an object, the state associated with the
object also influences the path of execution, and methods of a class can communicate among themselves
through this state because this state is persistent across invocations of methods. Hence, for testing objects,
the state of an object has to play an important role.
Techniques of object-oriented testing are as follows:
1. Fault Based Testing:
This type of checking permits for coming up with test cases supported the consumer specification or the
code or both. It tries to identify possible faults (areas of design or code that may lead to errors.). For all of
these faults, a test case is developed to “flush” the errors out. These tests also force each time of code to be
executed.
This method of testing does not find all types of errors. However, incorrect specification and interface
errors can be missed. These types of errors can be uncovered by function testing in the traditional testing
model. In the object-oriented model, interaction errors can be uncovered by scenario-based testing. This
form of Object oriented-testing can only test against the client’s specifications, so interface errors are still
missed.
2. Class Testing Based on Method Testing:
This approach is the simplest approach to test classes. Each method of the class performs a well defined
cohesive function and can, therefore, be related to unit testing of the traditional testing techniques.
Therefore all the methods of a class can be involved at least once to test the class.
3. Random Testing:
It is supported by developing a random test sequence that tries the minimum variety of operations typical to
the behavior of the categories
4. Partition Testing:
This methodology categorizes the inputs and outputs of a category so as to check them severely. This
minimizes the number of cases that have to be designed.
5. Scenario-based Testing:
It primarily involves capturing the user actions then stimulating them to similar actions throughout the test.
These tests tend to search out interaction form of error.
Usability: While testing usability, the developers face issues with scalability and interactivity. As
different numbers of users will be using the website, it is the responsibility of developers to make a group
for testing the application across different browsers by using different hardware. For example, Whenever
the user browses an online shopping website, several questions may come to his/her mind like, checking
the credibility of the website, testing whether the shipping charges are applicable, etc.
Browser Compatibility: For checking the compatibility of the website to work the same in different
browsers we test the web application to check whether the content that is on the website is being
displayed correctly across all the browsers or not.
Security: Security plays an important role in every website that is available on the internet. As a part of
security, the testers check things like testing the unauthorized access to secure pages should not be
permitted, files that are confined to the users should not be downloadable without the proper access.
Load Issues: We perform this testing to check the behavior of the system under a specific load so that
we can measure some important transactions and the load on the database, the application server, etc. are
also monitored.
Storage and Database: Testing the storage or the database of any web application is also an important
component and we must sure that the database is properly tested. We test things like finding errors while
executing any DB queries, checking the response time of a\the query, testing whether the data retrieved
from the database is correctly shown on the website or not.
Introduction to Selenium
Brief Introduction Selenium IDE
Selenium Integrated Development Environment (IDE) is the simplest framework in the Selenium suite
and is the easiest one to learn. It is a Firefox plugin that you can install as easily as you can with other
plugins. However, because of its simplicity, Selenium IDE should only be used as a prototyping tool. If
you want to create more advanced test cases, you will need to use either Selenium RC or WebDriver.
Brief Introduction Selenium Remote Control (Selenium RC)
Selenium RC was the flagship testing framework of the whole Selenium project for a long time. This is
the first automated web testing tool that allowed users to use a programming language they prefer. As
of version 2.25.0, RC can support the following programming languages:
Java
C#
PHP
Python
Perl
Ruby
Java
C#
PHP
Python
Perl
Ruby
Selenium Grid
Selenium Grid is a tool used together with Selenium RC to run parallel tests across different machines
and different browsers all at the same time. Parallel execution means running multiple tests at once.
Features:
Creating a top-notch web application requires a lot of testing which, if performed manually, can be tedious
and time-consuming. For this reason, many QA teams rely on automation to create fast, efficient, and
reliable test cases for their web applications.
Test automation offloads these routine and repetitive testing tasks from humans to machines. The tests
compare actual outcomes with predicted outcomes. This approach can help find bugs in specific operations
and simple-use cases (e.g. logging in, creating a new account, doing password resets).
By automating web application tests, testers are able to save time and effort on monotonous tasks.
Automated tests can be run continuously or scheduled at intervals. This offloads tester from time-
consuming tasks, and they can focus on exploratory testing or other tests that require a human perspective.
Test automation is the use of software (separate from the software under test) to control the execution of
tests. It lets software robots perform repetitive tasks and emulate end-user interaction with the system
under test, in order to increase the range, depth, and reliability of one’s quality assurance efforts.
Still, automation in not a plug-and-play system requiring no human intervention. Effective automation
requires testers to have a thorough knowledge of the software under test, as well as an “automation first”
mindset.
There are different test cases that you can automate depending on your business objectives.
More components of the life cycle are being automated, but you should choose those that best suit the
capabilities of your testing team.
These are the types of tests that you can automate for web applications:
Functional Testing
Functional testing is used to ensure that functionality of the software work as intended for an end-user.
A single end-user can make the whole system crash in minutes, even after unit, integration, and
performance tests have passed. This usually happens because the user does something the developers did
not expect.
Automating tests ensures that a web application is working as intended. However, functional test
automation cannot fully replace the human perspective. That’s why you should always supplement your
automated test cases with exploratory testing to provide a positive user experience.
If you want to dig deeper into automated functional UI testing, you can get immediate access to this
whitepaper on Functional UI testing: An introduction to codeless test automation.
Regression testing
Regression testing can be described as “repeated functional testing”. It is used to make sure that a
software’s functionality continues to work after parts of it have been modified with new code or
configurations. For instance, when new features are built, regression testing ensures that old features of the
software continue to work as intended.
Automated regression testing uses computer-based tools and techniques to test software that has been
changed or updated.
When regression testing is automated, you can quickly and reliably run through simple scenarios and check
a variety of changes to get fast feedback. This, in turn, frees up time for testers to focus on product
improvements or conduct manual exploration into more unusual cases that require special attention.
To become an expert in automated regression testing, download our whitepaper: How to do regression
testing (faster) in agile teams
Cross-browser testing
Cross-browser testing ensures that your web application is performing as expected across different
browsers, both on desktop and mobile.
Browsers tend to be updated fairly frequently, meaning that by the time you are ready to deploy your
application, it might not work as intended in your target browsers.
Users might have the latest browser version while using an old operating system. By automating cross-
browser testing, you make sure that incompatibilities like the one just mentioned are found even before
they reach an end-user.
Performance testing
Performance testing, such as stress and load testing, ensures that a web application can endure extended
periods of activity or peak user loads. Reaching the necessary stress conditions or load level wouldn’t be
feasible if done manually, therefore automation is key in proving that your application can perform in any
situation.
Before you start automating your web application tests, make sure you draft a test automation strategy to
keep you on track. Things to keep in mind before you start automation are:
Mobile Web application, in fact, is the website opened in the gadget (smartphone or tablet) with the help
of the mobile browser.
Easy development.
Easy access.
Easy update.
Mobile Web App requires no installation.
Native App is the application, which has been developed specifically for one platform (Android, iOS,
Tizen, Windows 10 M0bile, BlackBerry).
Hybrid App is the mix of the Native App and Mobile Web App. It can be defined like mobile website
content exposition in the application format.
Now, we can think about our testing strategy. Let’s consider the main points and challenges we should face
to.
Devices selection
There is no doubt, that the real device is the best decision if you want to test mobile application. Testing on
a real device always gives you the highest accuracy of results.
In fact, this is really not easy to choose the most appropriate device. Anyway, here are some actions you
should do while selecting device for the mobile testing:
Make the analysis to define the most popular and used gadgets in the market.
Choose devices with different OS.
Choose devices with different screen resolutions.
Pay attention to the next factors: compatibility, memory size, connectivity etc.
As it was mentioned before you have lots of advantages for testing mobile apps on the real devices:
As you can see testing on the real devices is the good decision, but also it has some limitations. You should
overcome them to make mobile apps testing process real effective.
Emulators or simulators?
There is no difficult to guess, that they are special tools which emulate/simulate functionality and behavior
of the mobile devices.
“Emulator” and “simulator meanings are often confused. Despite theirs almost similars pronunciation, they
have no equal meaning.
In fact, an emulator is the original device replacement. Though you can run soft and apps on your gadget,
you have no ability to modify them.
The simulator doesn’t replicate device’s hardware, but you have an ability to set up the similar environment
as the original device’s OS.
So, it is better to use mobile simulators to test mobile application. Emulators are more appropriate for the
mobile site testing.
Easy setup.
Fast working.
Helps to verify and explore the behavior of your mobile app.
Cost effective.
Easy availability.
An ability to run mobile devices on multiple systems and networks.
An ability not only to test, but also update and manage apps in the cloud.
Cost effective.
High scalability.
The same script can be run on several devices in parallel.
Some useful cloud-based tools, which can help you to test mobile application: Xamarin Test
Cloud, Perfecto Mobile Continuous Quality Lab, Keynote Mobile Testing. Here you can read more
about mobile testing tools.
Nowadays many specialists support the opinion that manual testing is going to die. Sure, it is not true. Of
course, we can not do without test automation, but there also situations when manual testing is preferable.
As you can see you should make different decisions creating your strategy for the mobile testing. Of
course, there are no univocal answers on them.
The combination of different approaches seems to be the optimal way. For example, you can use simulators
in the earliest stages of your testing process. But is better to use real devices (physical or cloud-based) in
the final stages. Automated testing is preferable for the load and regression testing. But manual mobile
testing tools are better to be used for usability and exploratory testing.
So, let’s start to consider the main stages of the mobile app testing process. They more mostly similar to the
website testing stages. Mostly, but not quite similar. As you have read before, there are some basic
differences between mobile and desktop applications. Therefore, we need to pass some additional stages
and make some additional verifications.
The mobile device is a system, that has not powerful stuffing. So, it can not work as a personal computer.
The mobile application testing in provided on handsets ( Apple, Samsung, Nokia, etc.), while the desktop
app is tested on a central processor.
Mobile devices screens variety, their extensions, and colors. Mobile phone screen size is smaller than
desktop ones.
Making and receiving calls is the main task of the phone, that is why the application should not interfere
with this major function.
A wide variety of specific operating systems and component configurations: Android, iOS, BlackBerry
etc.
Mobile phone OS quickly becomes obsolete. In addition, there is a limit to updating their OS.
Mobile devices use network connections ( 3G, 4G, Wi-Fi), desktop use broadband connection or Wi-Fi.
Mobile devices constantly search the network. That is why you should test the application at different data
rates.
Tools, which are good for the desktop apps testing, are not fully suitable for the mobile application testing.
Mobile applications must support multiple input channels (keyboard, voice, gestures, etc.), multimedia
technologies and other features that increase their usability.