Unit I Notes
Unit I Notes
UNIT I - notes
30 PERIODS
PRACTICAL EXERCISES:30 PERIODS
COURSE OUTCOMES:
CO1: Understand the basic concepts of software testing and the need for software
testing
CO2: Design Test planning and different activities involved in test planning
CO3: Design effective test cases that can uncover critical defects in the application
CO4: Carry out advanced types of testing
CO5: Automate the software testing using Selenium and TestNG
TOTAL:60 PERIODS
TEXTBOOKS
1. Yogesh Singh, “Software Testing”, Cambridge University Press,
2012
2. Unmesh Gundecha, Satya Avasarala, "Selenium
WebDriver 3 Practical Guide" - Second Edition 2018
REFERENCES
1. Glenford J. Myers, Corey Sandler, Tom Badgett, The Art of
Software Testing, 3rd Edition, 2012, John Wiley & Sons, Inc.
2. Ron Patton, Software testing, 2nd Edition, 2006, Sams Publishing
3. Paul C. Jorgensen, Software Testing: A Craftsman’s Approach,
Fourth Edition, 2014, Taylor & Francis Group.
4. Carl Cocchiaro, Selenium Framework Design in Data-Driven
Testing, 2018, Packt Publishing.
5. Elfriede Dustin, Thom Garrett, Bernie Gaurf, Implementing
Automated Software Testing, 2009, Pearson Education, Inc.
6. Satya Avasarala, Selenium WebDriver Practical Guide, 2014, Packt
Publishing.
7. Varun Menon, TestNg Beginner's Guide, 2013, Packt Publishing.
5 2 2 1 3 1 - - - 1 3 2 1 2 1 3
AVg. 2.2 2.2 1.6 2 1.2 - - - 1.2 2 1.6 1.8 2.2 1.8 2.6
CO’s-PO’s & PSO’s MAPPING
1 - low, 2 - medium, 3 - high, ‘-' - no correlation
1.1Introduction
This chapter will discuss the fundamentals of testing, such as why testing is
required, its limitations, airs and purposes, as well as the guiding principles, step-
by-step methods and psychological concerns that testers must: take into mind. You
will be able to explain the fundamentals of testing after reading this chapter.
Software testing is a method for figuring out if the real piece of software
meets requirements and is error-free. It involves running software or system
components manually of automatically in order to evaluate one or more intriguing
characteristics. Finding faults; gaps or unfulfilled requirements in comparison to the
documented specifications is-the aim of software testing.
Some prefer to use the terms white box and black box testing to describe the
concept of software testing. To-put it simply, software testing is the process of
validating an application that is being tested (AUT). In this course, software testing
is explained to the audience and its importance is justified.
1.1.1 What is Software Testing
Software testing is the process of determining if a piece of software is
accurate by taking into account all of its characteristics (reliability, scalability,
portability, Re-usability and usability) and analyzing how its various components
operate in order to detect any bugs, faults or flaws.
Software testing delivers assurance of the software's fitness and offers a
detached viewpoint and purpose of the programmer. It entails testing each
component that makes up the necessary services to see whether or not it satisfies the
set criteria. Additionally, the procedure informs the customer about the software's
caliber.
Manual testing can be further divided into three types of testing, which are as
follows:
White box testing
Black box testing
Gray box testing.
2. Automation testing:
Automation testing is a process of converting any manual test cases into the
test scripts with the help of automation tools or any programming language is
known as automation testing. ‘With the help of automation testing, we can enhance
the speed of our test execution because here, we do not require any human efforts.
We need to write a test script and execute those scripts.
1.2 Black-Box Testing and White-Box Testing
Black box testing (also called functional testing) is testing that ignores the
internal mechanism of a system or component and focuses solely on the outputs
generated in response to selected inputs and execution conditions. White box testing
(also called structural testing and glass box testing) is testing that takes into account
the internal mechanism of a system or component.
1.2.1What is White-Box Testing
There are some techniques which is used for white box testing -
1. Statement coverage: This testing approach involves going over every statement
in the code to make sure that each one has been run at least once. As a result, the
code is checked line by line.
2. Branch coverage: Is a testing approach in which test cases are created to ensure
that each ranch is tested at léast once. This method examines all potential
configurations for the system.
3. Path coverage: Path coverage is a software testing 2pproach that defines and
covers all potential pathways. From system entrance to exit points, pathways are
statements that may ‘be executed. It takes a lot of time.
4. Loop testing: With the help of this technique, loops and values in both
independent and dependent code are examined. Errors often happen at the start and
conclusion of loops. This method included testing loops
Concatenated loops
Simple loops
Nested loops
5. Basis path testing: Using this methodology, control flow diagrams are created
from code and subsequently calculations are made for cyclomatic complexity. For
the purpose of designing the fewest possible test cases, cyclomatic complexity
specifies the quantity of separate routes.
1.2.1.3 Advantages of White Box Testing
1. Complete coverage.
2. Better understanding of the system.
3. Improved code quality.
4. Increase efficiency.
5. Early detection of error.
1. Requirements phase
2. Planning phase
3. Analysis phase
4. Design phase
5. Implementation phase
6. Execution phase
7. Conclusion phase
8. Closure phase
1. Requirement phase: Analyses and research the requirements throughout this
phase of the smaller sub-conditions. STLC: Participate in brainstorming discussions
with other teams to see if the criteria can - Locate and collect the test data.be tested.
The scope of the testing is determined at this step. Inform the team during this -
Identify the test environment and set it up. phase if any feature cannot be tested so
that the mitigation approach may be prepared. - Develop the traceability metrics for
requirements.
2. The planning phase: Is the initial stage of the testing procedure’ in real-world -
Produce metrics for test coverage circumstances. The actions and resources that will
help us achieve the testing goals.
3. Analysis Phase: The "WHAT" to be tested is determined in this STLC step.
Basically, the satisfied before you begin your execution. Execute the test cases and
in the event of after requirements document, product hazards and other test bases
are used to determine the test discrepancy, report the faults. Fill up your traceability
metrics simultaneously to monitor circumstances. The requirement should be able to
be linked back to the test condition.
Testing levels and depth.
The product's complexity.
Project- and product-related risks.
The life cycle of software development is included.
Test administration.
The team's abilities and expertise.
The stakeholder’s accessibility.
7. Conclusion Phase: The exit criteria and reporting are the main topics of this
STLC phase.
We need to try to accurately capture the test circumstances in writing. You may, for
instance, include the test condition "User should be able to make a payment" for an
e-commerce web application. The user should be allowed to make payments
through NEFT, debit cards and credit cards or you might specify it by specifying it.
8. Closure phase: The following tasks are part of the closure activities:
Verify that the test has been completed. Whether all test scenarios are run or
intentionally mitigated. Verify that no faults of severity 1 have been opened.
Hold meetings to discuss lessons leamed and produce a paper detailing
them. (Include what worked well, where changes are needed and what may
be done better.)
5. Coding step: The coding step ‘is started after designing. It is determined on a
programming language that will work best based on the criteria. For coding, there
are certain rules and standards. The final build is enhanced for greater performance
prior to checking it into the repository and the code undergoes several code reviews
to verify its performance.
2. Integration testing: During the architectural design phase, integration test plans
are created. These experiments demonstrate that separate groups may live and
interact with one another.
3. System testing: During the system design phase, plans for system tests are
created. System test plans, in contrast to unit and integration test plans, are created
by the client's business team. System testing makes ensuring that an application
developer's requirements are satisfied.
4. Acceptance testing: The examination of business requirements is connected to
acceptance testing. The software product is tested in a user environment.
Acceptance tests highlight any system compatibility issues that may exist within the
user environment. Additionally, it identifies non-functional issues like load and
performance flaws in the context of actual user interaction.
When to use V - model?
When the requirement is well defined and not ambiguous.
The V-shaped model should be used for small to medium-sized projects
where requirements are clearly defined and fixed.
The V-shaped model should be chosen when sample technical resources are
available with essential technical expertise.
One may question why we need to discuss programme correctness given that
this book is about software testing. There are several causes, some of which are
listed below:
The goal of software testing is to run the potential programme on a set of
input data and determine if it acts according to- specification. Software
testing includes the study of correctness since it is only possible to analyze a
program's behavior if we are aware of what constitutes a proper behavior.
In particular, it leads to making assumptions about the behavior of the
programme at particular points in its execution and then verifying (or
disproving) these assumptions. The same assumptions can be checked at
run-time during testing, providing us with useful information as we attempt
to diagnose the programme or establish its correctness. Therefore, the
abilities we acquire while we attempt to demonstrate the correctness of a
programme assist us to be better/more efficient testers. :
Programme testers and programme providers often make kind remarks about
how testing and proving are complimentary while scrupulously ignoring one
another (and one other methodologies). Complementarity, however, is more
complex than first seems. A testing technique or a proving method is often
rendered useless not by any inherent quality of the approach but father by
being used incorrectly.
system with a high degree of complexity that contains software will be difficult to
attain a specific level of dependability.
Large next-generation aircraft, for instance, will have more than 1 million source
lines of software on board; next-generation air traffic control systems will have
between 1 and 2 million lines; the upcoming international space station will have
more than 2 million lines on board and more than 10 million lines of ground support
software; and a number of significant life-critical defense systems will have more
than 5 million source lines of software. Software complexity has an inverse
relationship with software dependability, but a direct relationship with other
important aspects of programme quality, such as functionality and capacity.
1.8 Failures, Errors and Fault
1. Software failures
Before describing the steps needed to analyses the dependability and safety
of software, it is critical to comprehend what a software failure entail. The
random or wear-related failure behavior. we see in hardware is not present in
software. As long as the same input and computer states are present,
software will always operate in the same manner.
System failures may be brought on by software due to implementation or
design flaws. Wrong assumptions about how a system will operate, such as
the assumption that input A always comes after input B, are a common
source of design mistakes.
Symbols that are unclear, such as ‘g' instead of 'G," are a common source of
implementation mistakes. Software flaws can only result in failures if they
are discovered while being used. Therefore, flaws in commonly used code
will result in failures more often than flaws in seldom used code, albeit both
may be significant. It is especially crucial to examine and verify seldom
used code in applications that are mission- or safety-critical.
2. What is an Error?
Error is a condition that arises when a developer or member of the
development team does not comprehend the concept of a need, and this
‘misunderstanding results in defective code.
Error is the phrase used to describe this circumstance and was mostly
created by the developers. Wrong logic, grammar or loops may produce errors that
affect the end-user experience.
The difference between predicted and actual outcomes is used to compute it.
It arises for a variety of causes, such as application challenges brought on by
design, code or system specification problems.
3. What’s a fault ?
Here, early testing refers to the idea that all testing activities should begin in
4. Defect clustering:
The defect clustering specified that we can identify the quantities of
problems that are associated to a limited number of modules during the
testing procedure: We have a number of explanations for this, including the
possibility of intricate modules, difficult code and more.
According to the pareto principle, which Suggests that we may determine
that approximately, these kinds of software or applications will follow,
roughly? Twenty percent of the modules contain eighty percent of the
complexity. This allows us to locate the ambiguous modules, but it has
limitations if the same tests are. run often since they will not be able to spot
any newly introduced flaws.
5. Pesticide paradox:
This rule said that if the same set of test cases were run again over a given
period of time, the tests would not be able to discover any new problems in
the programme or application.
Reviewing all the test. cases periodically is crucial to overcoming these
pesticide contradictions. Additionally, in order to incorporate many
components of the application or programme, new and different tests must
be created, which aids in the discovery of additional flaws.
6. Testing is context-dependent:
The testing is a context-dependent concept that asserts that a variety of
markets, including "e-commerce websites, business websites and others, are
available. Every application has its own requirements, features and functionality,
therefore there is a clear technique to test both commercial and e-commerce
websites. We will use a variety of testing methodologies, as well as numerous
approaches, techniques and procedures, to examine this sort of application.
As a result, testing is dependent on the application context. Program
Inspections. The idea that testing is context-dependent asserts that a variety of
markets, including e-commerce websites: and other commercial websites, are,
available. Due to the unique requirements, features and functioning of each
application, there is a specific approach to test both commercial and e-commerce
websites. We will use a range of testing techniques, distinct methodologies and
several ways to examine this sort of application. Testing thus relies on the
application context.
Steps of inspection
1. Planning: The planning phase starts when the entry criteria for the inspection
state are ‘met. A moderator verifies that the product entry criteria are met.
2.Overview: In the overview phase, a presentation is given to the inspector with
some background information needed to review the software product properly.
3.Preparation: This is considered an individual activity. In this part of the process,
the inspector collects all the materials needed for inspection, reviews that material
and notes any defects.
4. Meeting: The moderator conducts the meeting. In the meeting, the defects are
collected and reviewed.
5. Rework: The author performs this part of the process in response fo defect
disposition determined at the meeting.
6. Follow-up: In follow-up, the moderator makes the corrections and then compiles
the inspection management and defects summary report.
Characteristics of inspection:
An experienced moderator who is not the author generally directs the
inspection. The task of the moderator is to conduct a document's peer
review.
‘For test-driven development to work, unit tests must first be written that
fail. As soon as the test succeeds, they create code and restructure the
application. TDD often produces a code base that is clear and predictable.
To confirm that the code has no dependencies, each test case is run
separately in an isolated environment. The software developer should utilise
a testing framework to record any failed tests and write criteria to validate
each test case.
The creation of tests for every line of code would be time-consuming for
developers. The code that could influence how the programme being created
behaves should be the focus of the tests that developers write.
Only those properties that are essential to the operation of the unit being
evaluated are included in unit testing.
This enables developers to make modifications to the source code without
worrying about how they could effect the operation of other components or
the programme as a whole right away.
Teams may use integration testing to assess bigger programme components
after every unit in the programme operates as effectively and error- free as
feasible.
Unit tests may be run manually or automatically by developers. An intuitive
document outlining each stage in the process may be developed for those
using a manual technique, however automation testing is the most popular
approach for unit testing.
Automated methods often create test cases using a testing framework. In
addition to presenting a summary of the test cases, these frameworks are
also configured to flag and report any failed test cases.
Unit testing does not identify integration flaws; it just checks data sets and
their functionality.
To test one line of code, more lines of test code may need to be developed,
which might require additional time.
To successfully apply unit testing, developers may need to pick up new
skills, such as how to utilize certain automated software tools.
Process for system testing: The steps for system testing are as follows :
Produce a test case: Produce a test case for the testing pes
Produce test data: Produce the data-that will be put to the test.
Execute test case: Test cases are carried out after the production of the test case
cand the test data.
Defect reporting: System flaws are discovered.
Regression testing: This technique is used to examine the consequences of the
testing procedure's side effects.
Log defects: In this stage, defects are corrected.
Retest: If the first test is unsuccessful, a second test is conducted.
Preventing bugs,
Cost-effective
Product-Quality
Security
13)Differentiate between verification and validation? (U.Q
Nov/Dec 2009)?
Verification Validation
1.Verification is the process 1.
of evaluating software s y s t e m o r Verification is the process of evaluating
component to determine whether the software system or component during
products of a given development phase or at the end of the, the development
satisfy the conditions imposed at the phase satisfies the conditions imposed
start of that phase. at the start of that phase.
2.Verification is usually associated 2.Verification is usually associated
with activities such as inspections and with Traditional execution _based
reviews of the s/w deliverables. testing, i.e. Exercising the code with
testcases.
Manager
Developer/Tester
User/Client
17.Define Error?
An error is mistake or misconception or misunderstanding on the part of a
software developer.
19.Define failures?
A failure is the inability of a software or component to perform its required
functions within specified performance requirements.
Black box testing, the tester is no Knowledge The White box approach focuses on the
of its inner structure (i.e. how it woks) The inner structure of the software to be tested.
tester only has knowledge of what it does Black box approach is usually applied
(Focus only input & output) The White box large size piece of software. White box
approach focuses on the inner structure of the approach is usually applied small size
software to be tested. piece of software.
Black box approach is usually applied large Black box testing sometimes called
size piece of software. White box approach is functional or specification testing. White
usually applied small size piece of software. box sometimes called clear or glass box
Black box testing sometimes called functional testing
or specification testing.
27. What is Program Inspection?
A code inspection is a set of procedures and error-detection techniques for
group code reading. Most discussions of code inspections focus on the procedures,
forms to be filled out.
28.Define coupling?
The coupling is the measure of the degree of interdependence between units.
Two units with high coupling are strongly connected and thus, dependent on each
other.
Part- B & C
1.State and explain Software testing principles?
2.Explain in detail the tester’s role in a software development organization?
3.Explain in detail Black-Box and White-box Testing?
4.Illustrate with an example the following Black-Box testing Techniques.
i)Boundary Value Analysis
ii. Equivalence Partitioning
5.Explain in detail about V-Model of Software Testing?
6.Explain in detail about Software Testing Life cycle?
7.Explain about various stages of Testing?
8.Illustrate with an example the following White-Box testing Techniques?