Fundamentals of Software Testing

You might also like

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 29

Fundamentals of

Software Testing
Learning Objectives
• Software Testing
• Goals of Software Testing
• Software Defect and Causes
• Testing Processes
• Creating a Test Plan
What is Software Testing
• the process of executing a program or part of a program with the intention of finding
errors (Glenford Mayers).
• the process of exercising or evaluating a system or system component by manual
or automated means to verify that it satisfies specified requirements (IEEE 83a).
• testing is the process of analysing a system to detect the difference between
existing and required conditions and to evaluate the features of the system.
Common Testing Terms
Debugging
Debugging is a part of the development activity that identifies, analyses, and
removes defects. Debugging is performed by Developers on their piece of code.

Testing
Testing is the activity of identifying defects and is performed by Testers.

Review
A review can be performed on deliverables like documents, code, test plan, and
test cases. While testing can only be done when the executable code is ready,
reviews can be done on different kinds of documents and at all stages of
development.
Goals of Software Testing
Rigorous testing is necessary during software development and
maintenance to:

• Identify defects
• Reduce failures in the operational environment
• Increase quality of the operational system.
• meet contractual or legal requirements
• Meet industry-specific standards, which may specify the type
of techniques that must be used or the percentage of the
software code that must be executed.
Software Defect
A defect is any sort of error in a program which causes the system under test
to do one of the following:

1. Not meet the specified requirements (functional or non-functional)


2. Return an incorrect result
3. Stop execution unexpectedly (system stability is an implicit requirement in
all systems under test)

*The most obvious kind of defect is a system failing to meet requirements.


Causes of Software Defects
• Developer’s mistake
• Design error
• Mistake while porting the application into production
• Poorly documented requirements
• Insufficient Timing
• Complex architecture or code

*However, every mistake does not lead to a defect, neither does every
defect lead to a failure. Sometimes, defects lie dormant within the
software till they are triggered.
Consequences of Software Defects
• System failure
• Waste of resources
• Lost of credibility
• Business loss
Testing Activities
• Planning
• Specification or Designing
• Execution
• Analysing
• Reporting
Testing Activities
Test Planning
Test planning is the initial stage of testing. All testing activities are
planned, which include resource requirements regarding human
resource, training, software, tools, timelines, and risk and mitigations.

Test Specification
In the test specification stage, the test scenarios, test
conditions, and test cases are derived from business
requirements documents. All these artifacts are combined
using traceability, which helps in determining the requirements
coverage achieved during the testing effort.
Testing Activities
Test Execution
During test execution, the tester executes all planned test cases and verifies whether the expected
results match with the actual results. This can be performed manually or automatically using
appropriate tools based on the type of testing.

Test Recording
Test recording is the process where, as a proof of execution, the tester documents all test results as test log.

Test Reporting
Test reports are retrieved either manually or automatically.

Test reports help in understanding the progress in testing made till date or at a frequency defined in
the test plan.

Document Review
Document review is also considered as part of testing. It helps in identifying defects in the early
phases of testing when the executable code is under development.
Test Plan
What is a Test Plan?
A Test Plan refers to a detailed document that catalogues the:
• test strategy,
• objectives,
• schedule,
• estimations,
• deadlines, and
• the resources
required for completing that particular project.

Think of it as a blueprint for running the tests needed to ensure the software
is working properly
Importance of Test Plans
• They help individuals outside the QA teams (developers, business
managers, customer-facing teams) understand exactly how the
website or app will be tested.
• They offer a clear guide for QA engineers to conduct their testing
activities.
• They detail aspects such as test scope, test estimation, strategy, and
so on. Collating all this information into a single document makes it
easier to review by management personnel or to re-use for other
projects.
Components of a Test Plan
• Scope
• Schedule
• Resource Allocation
• Environment
• Tools
Components of a Test Plan
• Defect Management
• Risk Management
• Exit Parameters
Creating a Test Plan
Product Analysis
Product Analysis
This phase should focus on answering the following questions:

Who will use the product?


What is the main purpose of this product?
How does the product work?
What are the software and hardware specifications?

Functions of the Tester:

Interview clients, designers, and developers


Review product and project documentation
Perform a product walkthrough
Design Test Strategy
The Test Strategy document is developed by the test manager and defines the
following:

Project objectives and how to achieve them.


The amount of effort and cost required for testing.
More specifically, the document must detail out:
Specific Areas of Test Strategy

• Scope of Testing
• Type of Testing
• Risks and Issues
• Test Logistics
Defining Objectives
This phase defines the goals and expected results of test execution. Since
all testing intends to identify as many defects as possible, the objects must
include:

A list of all software features:


• functionality,
• GUI, and
• performance standards.

The ideal result or benchmark for every aspect of the software that needs
testing. This is the benchmark to which all actual results will be compared.
Test Criteria

Test Criteria refers to standards or rules governing all activities in a testing


project. The two main test criteria are:

• Suspension Criteria and


• Exit Criteria
Resource Allocation

This phase creates a detailed breakdown of all resources required for


project completion.
Resources include:
• human effort,
• equipment,
• and all infrastructure
required for accurate and comprehensive testing.
Test Environment

The test environment refers to software and hardware setup on which QAs
run their tests. Ideally, test environments should be:

• real devices - to monitor software behaviour in real user conditions.


installed real browsers and operating systems
• Do not compromise use emulators or simulators.
Test Schedule and Estimation
For test estimation, break down the project into smaller tasks and allocate time and effort
required for each.

Then, create a schedule to complete these tasks in the designated time with the specific
amount of effort.

Creating the schedule, however, does require input from multiple perspectives:

Employee availability, number of working days, project deadlines, daily resource availability.
Risks associated with the project which has been evaluated in an earlier stage.
Test Deliveries
Three Forms of Deliveries
A different set of deliverables is required before, during,
and after testing.

• Deliveries before testing


• Deliveries during testing
• Deliveries after testing
Deliveries Before Testing

Documentation on

• Test Plan
• Test Design
Deliveries During Testing

Documentation on

• Test Scripts
• Test Data
• Error and execution logs
Deliveries After Testing

Documentation on

• Test Results
• Defect Reports
• Release Notes
Summary
We addressed the primary objectives of
software testing, probable software defects,
sources of software defects, methods
involved in effective software testing, and
lastly how to construct a test plan.

You might also like