Unit 1 (s/w testing)

Introduction to Software Engineering

Software is (1)instructions (computer programs) that when executed provide desired function and
performance,(2) data structures that enable the programs to adequately manipulate information, and (3)
documents that describe the operation and use of the programs.

Software is a program or set of programs containing instructions that provide desired

functionality. And Engineering is the process of designing and building something that
serves a particular purpose and finds a cost-effective solution to problems. Computer
software is the product that software engineers design and build.

Engineering is the application of scientific and practical knowledge to invent, design, build, maintain, and
improve frameworks, processes, etc.

s/w=program+ documentation + operating procedure

operating procedure consist of instruction to setup and use of s/w system and
instruction on how to react to system failure.
Operating procedure consist
a) user manual
b) operational manual
documentation manual consist of
a) analysis/ specification--specification, context diagram, DFD
b) Design---flow chart, ER Diagram
c) Implementation--source code listing, cross ref. listing
d) Testing--test data, test result

A Discipline whose aim is the production of quality software, s/w that is delivered
on time, within budget and that satisfies its requirements.

Software Engineering is a systematic, disciplined, quantifiable study and approach to

the design, development, operation, and maintenance of a software system.

Software Characteristics:-
Therefore, software has characteristics that are considerably different than
those of hardware:

Software is developed or engineered; it is not manufactured in classical

o Software is a logical rather than a physical system element.

paradigm.



  Time and effort for software development are hard to estimate.

o
 Software does not wear out.
 Software construction is human intensive.
 It has discontinuous operational nature.
 Software components should be manufactured in such a way that is can be reused for various
application.

 7. Usability:
 It refers to the extent to which the software can be used with ease. the amount of effort or
 time required to learn how to use the software
 8. Portability:
 A set of attributes that bears on the ability of software to be transferred from one
environment to another, without minimum changes.

What is Testing?
1. Testing is the process of demonstrating that errors are not present.
2. The purpose of testing is to show that a program performs its intended functions correctly.
3. Testing is the process of establishing confidence that a program does what it is supposed to do.
These definitions are incorrect.

A more appropriate definition is:

“Testing is the process of executing a program with the intent of finding errors.”

Testing presents an interesting anomaly for the software engineer. During earlier software engineering
activities, the engineer attempts to build software from an abstract concept to a tangible product. Now
comes testing. The engineer creates a series of test cases that are intended to "demolish" the software that
has been built. In fact, testing is the one step in the software process that could be viewed as destructive
rather than constructive.
testing: The practice of investigating a software / system under test so as to
ensure that it is of the highest quality.
Software testing is a process of identifying the correctness of software by
considering its all attributes (Reliability, Scalability, Portability, Re-usability,
Usability) and evaluating the execution of software components to find the software
bugs or errors or defects.

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)

Why should We Test ?

Although software testing is itself an expensive activity, yet launching of software without testing may
lead to cost potentially much higher than that f testing, specially in systems where human safety is
involved.
In the software life cycle the earlier the errors are discovered and removed, the lower is the cost of their
removal.
Who should Do the Testing ?
o Testing requires the developers to find errors from their software.
o It is difficult for software developer to point out errors from own creations.
o Many organisations have made a distinction between development and testing phase by making
different people responsible for each phase.

What should We Test ?

We should test the program’s responses to every possible input. It means, we should test for all valid and
invalid inputs. Suppose a program requires two 8 bit integers as inputs. Total possible combinations are
28x28. If only one second it required to execute one set of inputs, it may take 18 hours to test all
combinations. Practically, inputs are more than two and size is also more than 8 bits. We have also not
considered invalid inputs where so many combinations are possible. Hence, complete testing is just not
possible, although, we may wish to do so

Testing Objectives
1. Testing is a process of executing a program with the intent of finding an error.
2. A good test case is one that has a high probability of finding an as-yet undiscovered error.
3. A successful test is one that uncovers an as-yet-undiscovered error.

Testing Principles
Before applying methods to design effective test cases, a software engineer must understand the basic
principles that guide software testing.
• All tests should be traceable to customer requirements. As we have seen, the objective of software
testing is to uncover errors. It follows that the most severe defects (from the customer’s point of view) are
those that cause the program to fail to meet its requirements.
• Tests should be planned long before testing begins. Test planning can begin as soon as the
requirements model is complete. Detailed definition of test cases can begin as soon as the design model
has been solidified. Therefore, all tests can be planned and designed before any code has been generated.
• The Pareto principle applies to software testing. Stated simply, the Pareto principle implies that 80
percent of all errors uncovered during testing will likely be traceable to 20 percent of all program
components. The problem, of course, is to isolate these suspect components and to thoroughly test them.
• Testing should begin “in the small” and progress toward testing “in the large.” The first tests
planned and executed generally focus on individual components. As testing progresses, focus shifts in an
attempt to find errors in integrated clusters of components and ultimately in the entire system .
• Exhaustive testing is not possible. The number of path permutations for even a moderately sized
program is exceptionally large . For this reason, it is impossible to execute every combination of paths
during testing. It is possible, however, to adequately cover program logic and to ensure that all conditions
in the component-level design have been exercised.
• To be most effective, testing should be conducted by an independent third party. By most effective,
we mean testing that has the highest probability of finding errors (the primary objective of testing). the
software engineer who created the system is not the best person to conduct all tests for the software.

Why Software Testing is Important?

Software Testing is Important because if there are any bugs or errors in the software,
it can be identified early and can be solved before delivery of the software product.
Properly tested software product ensures reliability, security and high performance
which further results in time saving, cost effectiveness and customer satisfaction.

What is the need of Testing?

Testing is important because software bugs could be expensive or even dangerous.
Software bugs can potentially cause monetary and human loss, and history is full
of such examples.

 In April 2015, Bloomberg terminal in London crashed due to software glitch

affected more than 300,000 traders on financial markets. It forced the
government to postpone a 3bn pound debt sale.
 Nissan cars recalled over 1 million cars from the market due to software
failure in the airbag sensory detectors. There has been reported two
accident due to this software failure.
 Some of Amazon’s third-party retailers saw their product price is reduced to
1p due to a software glitch. They were left with heavy losses.
 Vulnerability in Windows 10. This bug enables users to escape from security
sandboxes through a flaw in the win32k system.
 In 2015 fighter plane F-35 fell victim to a software bug, making it unable to
detect targets correctly.
 China Airlines Airbus A300 crashed due to a software bug on April 26, 1994,
killing 264 innocents live
 In May of 1996, a software bug caused the bank accounts of 823 customers of
a major U.S. bank to be credited with 920 million US dollars.

What are the benefits of Software Testing?

Here are the benefits of using software testing:

 Cost-Effective: It is one of the important advantages of software testing.

Testing any IT project on time helps you to save your money for the long
 term. In case if the bugs caught in the earlier stage of software testing, it
costs less to fix.
 Security: It is the most vulnerable and sensitive benefit of software testing.
People are looking for trusted products. It helps in removing risks and
problems earlier.
 Product quality: It is an essential requirement of any software product.
Testing ensures a quality product is delivered to customers.
 Customer Satisfaction: The main aim of any product is to give satisfaction
to their customers. UI/UX Testing ensures the best user experience.

Software Quality
 Different people understand different meanings of quality like:
 _ conformance to requirements
 _ fitness for the purpose
 _ level of satisfaction
 quality as “a characteristic or attribute of something.” As an attribute of an item, quality refers to
measurable characteristics—
 things we are able to compare to known standards such as length, color, electrical properties, and
malleability. However, software, largely an intellectual entity, is more challenging to characterize
than physical objects.

 two kinds of quality may be encountered: quality of design and quality of conformance.

 Quality of design refers to the characteristics that designers specify for an item. The grade of
materials, tolerances, and performance specifications all contribute to the quality of design. As
higher-grade materials are used, tighter tolerances and greater levels of performance are specified,
the design quality of a product increases, if the product is manufactured according to
specifications.
 Quality of conformance is the degree to which the design specifications are followed during
manufacturing. Again, the greater the degree of conformance, the higher is the level of quality of
conformance.

 In software development, quality of design encompasses requirements, specifications, and the
design of the system. Quality of conformance is an issue focused
 User satisfaction = compliant product + good quality + delivery within budget and schedule

 Quality control involves the series of inspections, reviews, and tests used throughout the software
process to ensure each work product meets the requirements placed upon it. Quality control
includes a feedback loop to the process that created the work product. The combination of
measurement and feedback allows us to tune the process when the work products created fail to
meet their specifications. This approach views quality control as part of the manufacturing
process.
 Quality control activities may be fully automated, entirely manual, or a combination of automated
tools and human interaction.

 Quality assurance consists of the auditing and reporting functions of management. The goal of
quality assurance is to provide management with the data necessary to be informed about product
quality, thereby gaining insight and confidence that product quality is meeting its goals


Psychological Testing in Software Testing

Software development, including software testing, involves human beings. Therefore, human psychology
has important effect on software testing.
In software testing, psychology plays an extremely important role. It is one of those factors that stay behind
the scene, but has a great impact on the end result. Categorized into three sections, the psychology of
testing enables smooth testing as well as makes the process hassle-free. It is mainly dependent on the
mindset of the developers and testers, as well as the quality of communication between them. Moreover,
the psychology of testing improves mutual understanding among team members and helps them work
towards a common goal.
The three sections of the psychology of testing are:
 The mindset of Developers and Testers.
 Communication in a Constructive Manner.
 Test Independence.

The mindset of Developers and Testers

The software development life cycle is a combination of various activities, which are performed by
different individuals using their expertise and knowledge. It is not an unknown fact that to accomplish the
success, development of software, people with different skills and mindset are required.
Developers synthesize code. They build up things, putting pieces together and figuring out fun and unique
ways of combining those distinct little bits to do wonderful and amazing things.
But Testers are all about analysis. Once it has all been put together, the tester likes to take it apart again,
piece by piece, this time looking for those little corners, edges, and absurdities that hide in those weird and
strange interactions that come from those new and amazing ways of putting pieces together.
Testing and Reviewing the applications are different from analyzing and developing it. While testing or
reviewing a product, testers mainly look for defects or failures in the product. If we are building or
developing applications, we have to work positively to solve the problems during the development process
and to make the product according to the user specification.
So the developer or the analyst may have problems with you as a tester because he thinks that you are
criticizing them.
There’s an element of human psychology called Confirmation bias, which means that most of people find
it difficult to accept information that disagrees with currently held believes.
For example, since developers expect their code to be correct, they have a confirmation bias that makes it
difficult to accept that the code is incorrect.In addition to confirmation bias, other cognitive biases may
make it difficult for people to understand or accept information produced by testing.
So as a result of these psychological factors, some people may perceive testing as a destructive activity,
even though it contributes greatly to project progress and product quality.To try to reduce these
perceptions, information about defects and failures should be communicated in a Constructive Way.
This way, tensions between the testers and the analysts, product owners, designers, and developers can be
reduced. This applies during both static and dynamic testing in which Static Testing is a software testing
technique where the software is tested without executing the code and Dynamic Testing will use the
dynamic behaviour of the code by opening the application and run it.

Communication in a Constructive Manner

Testers and test managers need to have good interpersonal skills to be able to communicate effectively
about the defects, failures, test results, test progress and risks and to build positive relationships among
colleagues. Communication, if done in a polite and respectful manner can help build a strong and reliable
relationship between the team members and help them avoid any misunderstanding.
Finding and reporting defects can be an achievement for the tester but is merely an inconvenience for
programmers, designers, developers, and other stakeholders of the project. As testing can be a destructive
activity, it is important for software testers to report defects and failures as objectively and politely as
possible to avoid hurting and upsetting other members related to the project.
So as testers, there are many ways to communicate collaboratively with developers.
 Start with collaboration rather than battels.
 Remind everyone about their common goal of having better quality systems.
 Emphasize the benefits of testing.
For example, for the authors, defect information can help them to improve the work products and their
skills.
 For the organization, defects found and fixed during testing will save money, time and reduce overall
risk to product quality.
 Communicate test results and other findings in a neutral, fact focused way without criticizing the
person who created the defected item.
 Write objectives, defect reports and review findings.
 Try to understand how the other person feels and the reasons they may react negatively to the
information.
  Confirm that the other person has understood what has been said.
 Clearly define the right set of test objectives has important psychological implications.
 Most people tend to align their plans and behaviors with the objectives set by the team, management,
and stakeholders. So it’s also important that testers adhere to these objectives with minimum
personnel bias.

Self-testing and Independent testing

Comparison of the mindsets of a tester and a programmer does not mean that a tester cannot be a
programmer, or that a programmer cannot be the tester, although they often are separate roles. In fact,
programmers are the testers. They always test the component which they built.
While testing their own code they find many problems so the programmers, architect, and developers
always test their own code before giving it to anyone. However, we all know that it is difficult to find our
own mistakes. It might be due to some reasons such as,
 “Parental feelings” towards their code
 Focus on the “Positive Paths”
 Work-based on the principle of simplifying of complex scenarios
 Inability to catch small things in big pictures
 Lack of end-to-end & real-user perspective

So, programmers, architects, business analysts depend on others to help test their work. This other person
might be some other developer from the same team or the Testing specialists or professional testers.
Giving applications to the testing specialists or professional testers allows an independent test of the
system.As this type of testing is mainly performed by individuals, who are not related to the project
directly or are from a different organization, they are hired mainly to test the quality as well as the
effectiveness of the developed product. Test independence, therefore, helps developers and other
stakeholders get more accurate test results, which helps them build a better software product, with
innovative and unique features and functionality.

There are several levels of independence in software testing which is listed here from the lowest level of
independence to the highest:

i. Tests by the person who wrote the item.

ii. Tests by another person within the same team, like another programmer.
iii. Tests by the person from some different groups such as an independent test team.
iv. Tests by a person from a different organization or company, such as outsourced testing or certification
by an external body.

To achieve successful testing it’s important for the software engineers to consider the psychological
aspects of testing, as they can interrupt the result of testing and can impact the performance of the end
product. The importance of these technological aspects is similar to any other tool or technique adopted for
the process of testing.The mindset of the team members, the communication between them, and most
importantly the test independence while performing the testing is crucial and needs great consideration.
Therefore, if you want your software testing to be free of any hurdles, do consider the psychological
aspects stated above.

Software Testing Principles

Software testing is a procedure of implementing software or the application to
identify the defects or bugs. For testing an application or software, we need to
follow some principles to make our product defects free, and that also helps the test
engineers to test the software with their effort and time. Here, in this section, we
are going to learn about the seven essential principles of software testing.
Let us see the seven different testing principles, one by one:
o Testing shows the presence of defects
o Exhaustive Testing is not possible
o Early Testing
o Defect Clustering
o Pesticide Paradox
 o Testing is context-dependent
o Absence of errors fallacy

Testing shows the presence of defects

The test engineer will test the application to make sure that the application is bug
or defects free. While doing testing, we can only identify that the application or
software has any errors. The primary purpose of doing testing is to identify the
numbers of unknown bugs with the help of various methods and testing techniques
because the entire test should be traceable to the customer requirement, which
means that to find any defects that might cause the product failure to meet the
client's needs.
By doing testing on any application, we can decrease the number of bugs, which
does not mean that the application is defect-free because sometimes the software
seems to be bug-free while performing multiple types of testing on it. But at the
time of deployment in the production server, if the end-user encounters those bugs
which are not found in the testing process.
.9M
235
Exhaustive Testing is not possible
Sometimes it seems to be very hard to test all the modules and their features with
effective and non- effective combinations of the inputs data throughout the actual
testing process.
Hence, instead of performing the exhaustive testing as it takes boundless
determinations and most of the hard work is unsuccessful. So we can complete this
type of variations according to the importance of the modules because the product
timelines will not permit us to perform such type of testing scenarios.
Early Testing
Here early testing means that all the testing activities should start in the early
stages of the software development life cycle's requirement analysis stage to
identify the defects because if we find the bugs at an early stage, it will be fixed in
the initial stage itself, which may cost us very less as compared to those which are
identified in the future phase of the testing process.
To perform testing, we will require the requirement specification documents;
therefore, if the requirements are defined incorrectly, then it can be fixed directly
rather than fixing them in another stage, which could be the development phase.
Defect clustering
The defect clustering defined that throughout the testing process, we can detect the
numbers of bugs which are correlated to a small number of modules. We have
various reasons for this, such as the modules could be complicated; the coding part
may be complex, and so on.
These types of software or the application will follow the Pareto Principle, which
states that we can identify that approx. Eighty percent of the complication is
present in 20 percent of the modules. With the help of this, we can find the
uncertain modules, but this method has its difficulties if the same tests are
performing regularly, hence the same test will not able to identify the new defects.
Pesticide paradox
This principle defined that if we are executing the same set of test cases again and
again over a particular time, then these kinds of the test will not be able to find the
new bugs in the software or the application. To get over these pesticide paradoxes,
it is very significant to review all the test cases frequently. And the new and
different tests are necessary to be written for the implementation of multiple parts
of the application or the software, which helps us to find more bugs.
Testing is context-dependent
Testing is a context-dependent principle states that we have multiple fields such as
e-commerce websites, commercial websites, and so on are available in the market.
There is a definite way to test the commercial site as well as the e-commerce
websites because every application has its own needs, features, and functionality.
To check this type of application, we will take the help of various kinds of testing,
different technique, approaches, and multiple methods. Therefore, the testing
depends on the context of the application.
Absence of errors fallacy
Once the application is completely tested and there are no bugs identified before
the release, so we can say that the application is 99 percent bug-free. But there is
the chance when the application is tested beside the incorrect requirements,
identified the flaws, and fixed them on a given period would not help as testing is
done on the wrong specification, which does not apply to the client's requirements.
The absence of error fallacy means identifying and fixing the bugs would not help if
the application is impractical and not able to accomplish the client's requirements
and needs.

CODE Verification:
The development of any software application/product goes through SDLC (Software Development Life
Cycle) where each and every phasis are very important and needs to follow accordingly to develop a
quality software product. Inspection is such an important element which have a great impact on the
software development process.
The software development team not only develops the software application rather during the coding
phase of software development they check for any error in the code of the software which is called code
verification. This code verification actually checks the software code in all aspects and finds out the
errors that exist in the code. Generally, there are two types of code verification techniques available i.e.
1. Dynamic technique – It is performed by executing some test data and the outputs of the program
are monitored to find errors in the software code.
2. Static technique – It is performed by executing the program conceptually and without any data.
Code reading, static analysis, symbolic execution, code inspection, and reviews, etc. are some of
the commonly used static techniques.

Based on the extent of the formality review are classified in to 3 types.

1. Informal review (Peer Review)(first review) - One on one with peers, no agenda or
preparation time Informal reviews do not have the rigor of a formal review. The reviews may not be
planned, or metrics may not be captured to measure review effectiveness. They are typically used to
confirm understanding, test ideas,brainstorm, etc.

2.Code Walkthrough(semi informal review)

Code Walkthrough is a form of peer review in which a programmer leads the review process and the
other team members ask questions and spot possible errors against development standards and other
issues.
  The meeting is usually led by the author of the document under review and attended by other
members of the team.
 Review sessions may be formal or informal.
 Before the walkthrough meeting, the preparation by reviewers and then a review report with a list
of findings.
 The scribe, who is not the author, marks the minutes of meeting and note down all the
defects/issues so that it can be tracked to closure.
 The main purpose of walkthrough is to enable learning about the content of the document under
review to help team members gain an understanding of the content of the document and also to
find defects.
-pre review preparations are not necessary
-reviewers get copy of s/w in advance
-Led by author

-Team includes-2-7 members, here Author=Presenter=programmer, reviewers (must include atleast 1

programmer as reviewer)
-Objective: detect defects and become familiar with the material
-Process/Phases: Presenter presents paper/document, reviewers listen, examine, write comments and ask
question. .

-Input: element/doc to be examined, objectives, standards to be followed.

-Output: defect report

3)Code Inspection (Formal review):

 It is the most formal type of review.
 It is a type of Static testing.
 Its main purpose is to find defects.
 During code inspection documents are prepared and checked thoroughly by the reviewers.
 A separate preparation is carried out to find the defects in product.
 Code inspection in source code before meeting is necessary, which creates consistency.
 Code inspection is based on rules and checklist and makes use of entry and exit criteria.
 Involves peer examination of codes.
 Defects found in code inspection are documented in a logging list or issue log.
 A formal follow up is carried out by the moderator.

Here Meeting is planned in advance, facilitated by a moderator, follows a proper process, participants
come prepared for the meeting. Reviewers are selected based on skill and knowledge.
Inspection:
-Formal, planned and structured meeting
-Pre review preparation is done by all participants
-Roles of all are defined
-Led by moderator
-Team includes: moderator, author, presenter=reader, inspectors=reviewers, recorder
-Objective: to find defects, collect data and communicate important information about the work product
-Process/phases: Planning- selecting people and documents to be reviewed, defining roles, deciding entry
and exit criteria
Kick Off- distributing documents and explaining them to all, checking entry
criteria fulfilled or not
Individual preparation- is done by all members before meeting
Review meeting- includes discussion and logging results (results are documented), taking decisions about
defects
Rework- author fixes the defects
Follow up- metrics (that is measurement of different software attributes) and checking if exit from
meeting/phase criteria is fulfilled

Software Inspection Checklist

Software inspection processes generally call for Checklist simply to provide reviewers with hints and
some recommendations for determining and identifying defects during inspection of software product.
The inspection process should always need to be driven by checklist of some common programming
errors.
An inspection checklist is simply an assurance that specific software product has been inspected. An
inspection checklist should be developed by discussion with some experienced staff and as well as
regularly updated as more experience is gained from inspection process.

Different checklist is also prepared for various programming languages i.e. checklist for source code
are given separately for different source languages. There are some of the items of checklist that are
general and therefore require good deal of human judgment. Some possible checks that can be made
during the inspection process are given below:
1. Data Faults :
 Check Are all of the variables of program initialized before their values are used?
 Has all constant been given name?
 Is there any chance of buffer overflow? Etc.
2. Control Faults :
 Is the condition correct for each conditional statement?
 Is each loop certain to terminate?
 Are compound statements bracketed correctly or not?
3. Input/Output (I/O) Faults :
 Are all of the input variables used or not?
 Are all of the output variables assigned to a value before they are output?
 Can input that are unexpected causes of corruption? Etc.
4. Interface Faults :
 Does all method and functions have the correct number of parameters?
 Do the type of parameters i.e. actual and formal matches?
 Are the parameters present in the correct order?
 Do they have the same model of shared memory structure, if all of the components access
shared memory?
5. Storage Management Faults :
 Have all links been reassigned correctly, if a linked structure is modified?
 Has space been correctly allocated, if dynamic storage is used?
 Does the space get de-allocated explicitly after it is no longer required? Etc.
6. Exception Management Faults :
 Do all possible error conditions been taken into account or consideration?
Example :
1. Requirement Inspection Checklist :
 Do requirements exhibit a clear distinction among functions and data?
 Do requirements exactly define all the information that is needed to be displayed to users?
 Do requirements address system and user response to all conditions of error?
 Is each of the requirements stated clearly, concisely, and unambiguously?
 Is each of the requirements testable?
  Are there any ambiguous or implied requirements present?
 Are there any conflicting requirements?
 Are there areas that are not addressed in the Software Requirements Specification (SRS) that is
needed to be?
 Are performance requirements like response time, data storage requirements, etc. stated?

Technical review:
 It is less formal review
 It is led by the trained moderator but can also be led by a technical expert
 It is often performed as a peer review without management participation
 Defects are found by the experts (such as architects, designers, key users) who focus on the
content of the document.
 In practice, technical reviews vary from quite informal to very formal
The goals of the technical review are:
1.To ensure that an early stage the technical concepts are used correctly
2.To access the value of technical concepts and alternatives in the product
3. To have consistency in the use and representation of technical concepts
4.To inform participants about the technical content of the document

Bug in Software Testing

What is a bug in software testing?
The Bug is the informal name of defects, which means that software or
application is not working as per the requirement.
In software testing: , a software bug can also be issue, error, fault, or failure. The bug
occurred when developers made any mistake or error while developing the product.
While testing the application or executing the test cases, the test engineer
may not get the expected result as per the requirement. And the bug had
various names in different companies such as error, issues, problem, fault,
and mistake, etc.
Basic terminology of defect
Let see the different terminology of defect:
o Defect
o Bug
o Error
o Issue
o Mistake
o Failure

Terms Description Raised by

Defect When the application is not working as per the Test Engineer
requirement.

Bug Informal name of defect Test Engineer

Error Problem in code leads to the errors. Developer, Automation Tes

Engineer

Issue When the application is not meeting the business Customer

 requirement.

Mista Problem in the document is known as a mistake. --

ke

Failur Lots of defect leads to failure of the software. --

e

Why defect/bug occur?

In software testing, the bug can occur for the following reasons:
o Wrong coding
o Missing coding
o Extra coding
Wrong coding
Wrong coding means improper implementation.
For example: Suppose if we take the Gmail application where we click on
the "Inbox" link, and it navigates to the "Draft" page, this is happening
because of the wrong coding which is done by the developer, that's why it is
a bug.
Missing coding
Here, missing coding means that the developer may not have developed the
code only for that particular feature.
For example: if we take the above example and open the inbox link, we see
that it is not there only, which means the feature is not developed only.
Extra coding
Here, extra coding means that the developers develop the extra features,
which are not required according to the client's requirements.
For example:
Suppose we have one application form wherein the Name field, the First
name, and Last name textbox are needed to develop according to the
client's requirement.
But, the developers also develop the "Middle name" textbox, which is not
needed according to the client's requirements as we can see in the below
image:

If we develop an extra feature that is not needed in the requirement, it leads

to unnecessary extra effort. And it might also happen that adding up the
extra feature affects the other elements too.
Bugs in Software Testing and Cost to Fix
There is no set cost one can ascribe to a software bug. However, the cost of a bug goes
up based on how far down the Software Development Life Cycle the bug is found. Any
bug found in production the code needs to go back to the beginning of the SDLC where
the development cycle can restart.
The figure below illustrates the cost of fixing a bug depending on the SDLC phase it is
identified:

Cost Of A Software Bug Depending On The Different Stages

Now let’s see what is the cost of a software bug, depending on the different stages where it
is detected.
Early Development
Finding the flaw at the stage of the early development of the website or software.
If this is done, then the cost of the software bug will be greatly reduced, going as far as next
to zero. Because flaws are found at the initial stage; hence, the complication is not such a
huge factor here, and the defect can be easily fixed almost immediately.
If the defect is not detected immediately, but by the developer or some other employee at a
later stage.
In this case, the cost of a software bug will increase because the extra effort is put behind it,
and it went out of the developer's grip while it was during development. The moment when
a tester enters the process of testing the cost of a software bug will be counted into it.
Detecting The Cause Of The Bug
This is the place that clearly controls the cost of a software bug, and it keeps elevating as
the complication in the system also increases.
Fixing The Bug After The Software Or Website Is Launched
As more aspects are added to the system, the amount of complication keeps elevating. And
as the complication increases in the system, finding the primary cause for the bug also
increases. Hence a lot of effort goes behind first finding the bug (and how to reproduce it),
then searching for the cause or the roots of the bug, and lastly fixing it is some other level of
work. Due to all of this, the cost of a software bug is also increasing.
Direct and Indirect Cost Of Software Bug
Other than the generic cost of a software bug, there are two types of main costs, namely
direct and indirect costs.
Direct Costs
This includes the money that the management invests as a whole in the development of the
project, including the salary of the employees and developers as well as the quality
assurance work.
Indirect Costs
This can be considered an extra cost which you need to avoid as much as possible. If
testing is conducted, bugs will obviously remain in the system, the complications it will
cause due to its presence will be falling under the indirect costs.
To fix all the problems caused by the bug, the amount of money you will spend will be
considered as nothing but indirect costs. To avoid it, you need to conduct testing
procedures for your project. If the bug is detected in the initial stage or the development
stage, then you can easily save a lot of money and also create a project devoid of any
minor or major problems in it.

ROLE of A S/w Tester:

Software testing is the process of verifying a program or application to ensure that it performs as
expected. It is an important part of the software development life cycle, as it can save teams from costly
fixes. As a software tester, you'll be involved in the quality assurance stage of software
development and deployment. You'll conduct automated and manual tests to ensure the
software created by developers is fit for purpose and any bugs or issues are removed within a
product before it gets deployed to everyday users.
Categorization of Roles in Software Testing :Every organization has its own team structure, but there are a
few positions that need to be filled either by role or responsibility.These are:

1. QA Engineer:
This position generally covers more than testing processes. A software quality assurance engineer
constantly monitors each and every phase of the software development process and makes sure that the
developed software meets quality standards. Additionally, they make sure that the software products work
seamlessly without errors before they are pushed into production.

2. Test Manager
A test manager acts as a project manager. This is a management position within the QA or test team,
which is very common for custom software outsourcing organizations.

3. Test Engineer
This is generally used as an umbrella term to cover many capabilities. It can refer to many engineers
specialized in various testing approaches, such as manual testing, exploratory testing, performance
testing, etc. It is also widely used to infer a testing position that minimally relies on automation.

4. Test Analyst
This is a position that, rather than being more technical, focuses on business problems. Test analysts
ensure the functional readiness of the application is acceptable before it is pushed into production. They
generally design, develop, run, and troubleshoot tests to catch any defects or errors in the code in pre-
production environments.

5. Test Automation Engineer

This is a widely spread position among enterprises representing an engineer who codes (most likely a
developer), but whose sole focus is on automating test processes. These people use testing frameworks
such as Selenium, Cucumber, or others to effectively design and write new test cases. Another great
advantage of test automation engineers is that they are well versed in GUI design and software testing.

Core Functions, Skills, and Responsibilities of Roles in

Software Testing
The software tester’s role in a project is utilized differently in different organizations depending on the
size of the testing team, structure of the team, and specific requirements of the organization.

Software testing job titles or positions are typically called “QA” or “test engineer”, but the technology
they use, the business domain they are in, the expertise they have, or even the type of testing they make
will differ.In the table below, you can review a summary of the core functions, responsibilities, required
overall skills, and knowledge of required tools of some common software testing roles.

Roles Test Manager Test Automation Engineer QA Engineer

- Do the requirement analysis

- Set success and quality for manual tests
Write, run, and monitor the
metrics for product - Estimate, prioritize, plan,
automated test suites for the
- Plan and execute the and coordinate quality
product
software testing process testing activities.
Responsibilities - Design the automated
- Recruit and supervise the - Create detailed and well-
testing processes and create
team structured test plans and test
documentation
- Communicate across cases
- Select and use the tooling
departments - Create status reports and
defect report

- Create the strategy for

- Develop scripts to run - Evaluate and observe the
testing the product
automated tests product manually to make
Core Functions - Manage the testing process
- Design automated tests to sure it doesn’t go to
and workflow within the
streamline the testing process production with any defects
team
- Comprehensive knowledge
about testing strategies - Comprehensive knowledge - Comprehensive knowledge
- Manual and automated about DevOps and agile about manual testing
testing knowledge methodologies methodologies
Required Skills
- Ability to understand and - Coding skills - Ability to understand the
communicate both with the - Analytical skills clients’ requirements
internal team and also with - Problem-solving skills - Data analysis skills
the client
- Automation tools and
frameworks - Test management tools
Tools Management tools
- Observability tools - Debugging tools
- CI/CD tools

What is SDLC?
SDLC is a systematic process for building software that ensures the quality and correctness of the
software built. SDLC process aims to produce high-quality software that meets customer
expectations. The system development should be complete in the pre-defined time frame and
cost. SDLC consists of a detailed plan which explains how to plan, build, and maintain specific
software. Every phase of the SDLC life Cycle has its own process and deliverables that feed into
the next phase. SDLC stands for Software Development Life Cycle and is also referred to as the
Application Development life-cycle.

Here, are prime reasons why SDLC is important for developing a software system.
  It offers a basis for project planning, scheduling, and estimating
 Provides a framework for a standard set of activities and deliverables
 It is a mechanism for project tracking and control
 Increases visibility of project planning to all involved stakeholders of the development
process
 Increased and enhance development speed
 Improved client relations
 Helps you to decrease project risk and project management plan overhead

SDLC Phases
The entire SDLC process divided into the following SDLC steps:

SDLC Phases

 Phase 1: Requirement collection and analysis

 Phase 2: Feasibility study
 Phase 3: Design
 Phase 4: Coding
 Phase 5: Testing
 Phase 6: Installation/Deployment
 Phase 7: Maintenance

Phase 1: Requirement collection and analysis

The requirement is the first stage in the SDLC process. It is conducted by the senior team
members with inputs from all the stakeholders and domain experts in the industry. Planning for
the quality assurance requirements and recognization of the risks involved is also done at this
stage.

This stage gives a clearer picture of the scope of the entire project and the anticipated issues,
opportunities, and directives which triggered the project.

Requirements Gathering stage need teams to get detailed and precise requirements. This helps
companies to finalize the necessary timeline to finish the work of that system.

Phase 2: Feasibility study

Once the requirement analysis phase is completed the next sdlc step is to define and document
software needs. This process conducted with the help of ‘Software Requirement Specification’
document also known as ‘SRS’ document. It includes everything which should be designed and
developed during the project life cycle.

There are mainly five types of feasibilities checks:

 Economic: Can we complete the project within the budget or not?

 Legal: Can we handle this project as cyber law and other regulatory
framework/compliances.
 Operation feasibility: Can we create operations which is expected by the client?
 Technical: Need to check whether the current computer system can support the software
 Schedule: Decide that the project can be completed within the given schedule or not.
Phase 3: Design
In this third phase, the system and software design documents are prepared as per the
requirement specification document. This helps define overall system architecture.

This design phase serves as input for the next phase of the model.There are two kinds of design
documents developed in this phase:

High-Level Design (HLD)

 Brief description and name of each module

 An outline about the functionality of every module
 Interface relationship and dependencies between modules
 Database tables identified along with their key elements
 Complete architecture diagrams along with technology details

Low-Level Design (LLD)

 Functional logic of the modules

 Database tables, which include type and size
 Complete detail of the interface
 Addresses all types of dependency issues
 Listing of error messages
 Complete input and outputs for every module

Phase 4: Coding
Once the system design phase is over, the next phase is coding. In this phase, developers start
build the entire system by writing code using the chosen programming language. In the coding
phase, tasks are divided into units or modules and assigned to the various developers. It is the
longest phase of the Software Development Life Cycle process.

In this phase, Developer needs to follow certain predefined coding guidelines.

Phase 5: Testing
Once the software is complete, and it is deployed in the testing environment. The testing team
starts testing the functionality of the entire system. This is done to verify that the entire
application works according to the customer requirement.

During this phase, QA and testing team may find some bugs/defects which they communicate to
developers. The development team fixes the bug and send back to QA for a re-test. This process
continues until the software is bug-free, stable, and working according to the business needs of
that system.

Phase 6: Installation/Deployment
Once the software testing phase is over and no bugs or errors left in the system then the final
deployment process starts. Based on the feedback given by the project manager, the final
software is released and checked for deployment issues if any.
Phase 7: Maintenance
Once the system is deployed, and customers start using the developed system, following 3
activities occur

 Bug fixing – bugs are reported because of some scenarios which are not tested at all
 Upgrade – Upgrading the application to the newer versions of the Software
 Enhancement – Adding some new features into the existing software

The main focus of this SDLC phase is to ensure that needs continue to be met and that the system
continues to perform as per the specification mentioned in the first phase.

Software Development Life Cycle Models

A software life cycle model is a descriptive representation of the software development
cycle. SDLC models might have a different approach but the basic phases and activity
remain the same for all the models.

#1) Waterfall Model

Waterfall model is the very first model that is used in SDLC. It is also known as the linear
sequential model.
In this model, the outcome of one phase is the input for the next phase. Development of the
next phase starts only when the previous phase is complete.

 First, Requirement gathering and analysis is done. Once the requirement is freeze then
only the System Design can start. Herein, the SRS document created is the output for
the Requirement phase and it acts as an input for the System Design.
 In System Design Software architecture and Design, documents which act as an input
for the next phase are created i.e. Implementation and coding.
 In the Implementation phase, coding is done and the software developed is the input for
the next phase i.e. testing.
 In the testing phase, the developed code is tested thoroughly to detect the defects in the
software. Defects are logged into the defect tracking tool and are retested once fixed.
Bug logging, Retest, Regression testing goes on until the time the software is in go-live
state.
 In the Deployment phase, the developed code is moved into production after the sign off
is given by the customer.
 Any issues in the production environment are resolved by the developers which come
under maintenance.
 Deliverables of each phase are well defined, and this leads to no complexity and
makes the project easily manageable.

Advantages of the Waterfall Model:

 Simple and easy to understand and use
  Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review
process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.

Disadvantages of Waterfall model:

The major disadvantages of the Waterfall Model are as follows −
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk
and uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't allow identifying any
technological or business bottleneck or challenges early.

 Waterfall model is time-consuming & cannot be used in the short duration projects as
in this model a new phase cannot be started until the ongoing phase is completed.
 Waterfall model cannot be used for the projects which have uncertain requirement or
wherein the requirement keeps on changing as this model expects the requirement
to be clear in the requirement gathering and analysis phase itself and any change in
the later stages would lead to cost higher as the changes would be required in all the
phases.
2 .Prototype Model
The prototype model requires that before carrying out the development of actual software, a
working prototype of the system should be built. A prototype is a toy implementation of the
system. A prototype usually turns out to be a very crude version of the actual system,
possible exhibiting limited functional capabilities, low reliability, and inefficient performance
as compared to actual software. In many instances, the client only has a general view of
what is expected from the software product. In such a scenario where there is an absence of
detailed information regarding the input to the system, the processing needs, and the
output requirement, the prototyping model may be employed.

Steps of Prototype Model

1. Requirement Gathering and Analyst
2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product
Advantage of Prototype Model
1. Reduce the risk of incorrect user requirement
2. Good where requirement are changing/uncommitted
3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is made side by side.

Disadvantage of Prototype Model

1. An unstable/badly implemented prototype often becomes the final product.
2. Require extensive customer collaboration
o Costs customer money
o Needs committed customer
o Difficult to finish if customer withdraw
o May be too customer specific, no broad market
3. Difficult to know how long the project will last.
4. Easy to fall back into the code and fix without proper requirement analysis, design,
customer evaluation, and feedback.
5. Prototyping tools are expensive.
6. Special tools & techniques are required to build a prototype.
7. It is a time-consuming process.

3.Spiral model: The spiral model, originally proposed by Boehm [BOE88], is an

evolutionary software process model that couples the iterative nature of prototyping with the controlled
and systematic aspects of the linear sequential model. It provides the potential for rapid development of
incremental versions of the software. Using the spiral model, software is developed in a series of
incremental releases. It is one of the most important Software Development Life Cycle models,
which provides support for Risk Handling. In its diagrammatic representation, it looks
like a spiral with many loops. The exact number of loops of the spiral is unknown and
can vary from project to project. Each loop of the spiral is called a Phase of the
software development process. The exact number of phases needed to develop the
product can be varied by the project manager depending upon the project risks. As the
project manager dynamically determines the number of phases, so the project manager
has an important role to develop a product using the spiral model.
The Radius of the spiral at any point represents the expenses(cost) of the project so far,
and the angular dimension represents the progress made so far in the current phase.
The below diagram shows the different phases of the Spiral Model:

–
A spiral model phase has 4 sector described below:
1. Planning phase
2. Risk analysis phase
3. Engineering phase
4. Evaluation phase.
Activities which are performed in the spiral model phases are shown below:
Phase
Activities performed Deliverables / Output
Name

Planning -Requirements are studied and gathered. Requirements understanding

- Feasibility study document
- Reviews and walkthroughs to streamline the
requirements Finalized list of requirements.

Risk Requirements are studied and brain storming Document which highlights all the
Analysis sessions are done to identify the potential risks risks and its mitigation plans.

Once the risks are identified , risk mitigation

strategy is planned and finalized

Engineering Actual development and testing if the software Code

takes place in this phase Test cases and test results
Test summary report and defect
report.

Evaluation Customers evaluate the software and provide their Features implemented document
 Phase
Activities performed Deliverables / Output
Name

feedback and approval

Advantages of Spiral Model:

Below are some advantages of the Spiral Model.
1. Risk Handling: The projects with many unknown risks that occur as the
development proceeds, in that case, Spiral Model is the best development model to
follow due to the risk analysis and risk handling at every phase.
2. Good for large projects: It is recommended to use the Spiral Model in large and
complex projects.
3. Flexibility in Requirements: Change requests in the Requirements at later phase
can be incorporated accurately by using this model.
4. Customer Satisfaction: Customer can see the development of the product at the
early phase of the software development and thus, they habituated with the system
by using it before completion of the total product.
Disadvantages of Spiral Model:
Below are some main disadvantages of the spiral model.
1. Complex: The Spiral Model is much more complex than other SDLC models.
2. Expensive: Spiral Model is not suitable for small projects as it is expensive.
3. Too much dependability on Risk Analysis: The successful completion of the
project is very much dependent on Risk Analysis. Without very highly experienced
experts, it is going to be a failure to develop a project using this model.
4. Difficulty in time management: As the number of phases is unknown at the start
of the project, so time estimation is very difficult.
When to use Spiral Model?
o When deliverance is required to be frequent.
o When the project is large
o When requirements are unclear and complex
o When changes may require at any time
o Large and high budget projects

4) Agile Model
Agile Model is a combination of the Iterative and incremental model. This model focuses
more on flexibility while developing a product rather than on the requirement.In Agile, a
product is broken into small incremental builds. It is not developed as a complete product in
one go. Each build increments in terms of features. The next build is built on previous
functionality.

In agile iterations are termed as sprints. Each sprint lasts for2-4 weeks. At the end of each
sprint, the product owner verifies the product and after his approval, it is delivered to the
customer.
Customer feedback is taken for improvement and his suggestions and enhancement are
worked on in the next sprint. Testing is done in each sprint to minimize the risk of any
failures.
Advantages of Agile Model:
 It allows more flexibility to adapt to the changes.
 The new feature can be added easily.
 Customer satisfaction as the feedback and suggestions are taken at every stage.
Disadvantages:
 Lack of documentation.
 Agile needs experienced and highly skilled resources.
 If a customer is not clear about how exactly they want the product to be, then the
project would fail.

What are the differences between the Incremental and Evolutionary Software
Development Process?
In an incremental model, all the requirements are gathered before starting the incremental
development process. In the Software Requirement Specification (SRS) document, the scope is
defined and fixed based on the requirements. The entire development contract will be defined.
However, the minor deviation is possible in the scope but not entirely.
In the evolutionary model, it is not the case. After an overall understanding of the system, the
development team does not really capture all the requirements but starts with some core or riskier
modules. Here the prescribed scope is not defined. Sometimes, the project never converges as the
project manager does not know how much time and effort are required if the company signs this
project or project contract for the first time.
Incremental Model
1. The requirements are clear to the development team.
2. The requirements are split into slices, and one by one, slices are picked based on selection
criteria.
3. The development of each slice goes into multiple iterations for the refinement of functionality,
and in the end, a deliverable product is released.
4. It is called an increment, and in each increment, a deliverable product is given to the user.
5. In this model, requirements do change. But to a certain extend, like the addition and removal
of certain functionalities.
6. The development team knows how much has been completed and how much needs to be
complete soon.
7. Picking criteria for the incremental model: when the requirements are more or less fixed and
clearer to the customer. However, to mitigate risk, the development team involves the
customer for feedback, and after each increment, the product is given to the customer for
feedback. And feedback is incorporated in the subsequent increments to achieve the final
product which satisfies the customer’s requirements.
Evolutionary Model
 1. The requirements are not clear, and it evolves during the development cycle.
2. At the initial stage, based on their understanding of the customer’s requirements, they
developed the core modules and functionalities and delivered them to the customer for
feedback.
3. This is called an iteration. In each iteration, they release a working software after performing
integration and level of testings.
4. The development team does not know how much has been completed and how much needs
to be complete in the near future.
5. Picking criteria for the evolutionary model: when the requirements are not clear.

Application of Evolutionary Model:

1. It is used in large projects where you can easily find modules for incremental implementation.
Evolutionary model is commonly used when the customer wants to start using the core features
instead of waiting for the full software.
2. Evolutionary model is also used in object oriented software development because the system
can be easily portioned into units in terms of objects.

Advantages:
 In evolutionary model, a user gets a chance to experiment partially developed system.
 It reduces the error because the core modules get tested thoroughly.
Disadvantages:
 Sometimes it is hard to divide the problem into several versions that would be acceptable to the
customer which can be incrementally implemented and delivered.
 Evolutionary models are iterative type models.
 They allow to develop more complete versions of the software.

Following are the evolutionary process models.

1. The prototyping model

2. The spiral model

s/w testing TERMINOLOGIES

 Test Plan
 Test Scenarios
 Test Cases
 Priority
 Severity
 Verification
 Validation
 SDLC & STLC

1. Test Plan

As per ISTQB definition,

A test plan is a document outlining the scope, approach, resources, and schedule of the
intended test activities. It identifies amongst others, the test items, the features to be tested,
tasks, person assigned to each task, the test environment, test design techniques, entry and
exit criteria as well as contingency planning.
Simply put – A test plan defines the strategy to be used to test an application and elucidates the
objective, resources used and the information about the test environment. It is a blueprint which
summarizes how the testing activities will proceed for any project.

2.Test Scenarios vs Test Cases

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 Scenario is to Test the login functionality whereas Test Cases that are included in this Test
Scenario .
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.

,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,

4. Verification v/s Validation:

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.

5: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.