Software Quality Engineering Lecture 2

Testing concepts issues and techniques

Build Vs Release
In the context of software development, a build is a version of the software
that has been compiled and is ready for testing or deployment. A release, on
the other hand, is a version of the software that has been formally
distributed to users. Both are part of the continuous integration and
continuous deployment process.

In general, the process of building software involves creating a build, which is

then tested and debugged. Once the build has been tested and is deemed to
be of sufficient quality, it can be released to users. The process of releasing
software typically involves additional activities such as creating release
notes, performing final testing and quality assurance, and communicating
the release to users.

A “build” is given by dev team to the test team. A “release” is formal release
of the product to its customers.

A build when tested and certified by the test team is given to the customers
as “release”. A “build” can be rejected by test team if any of the tests fail or
it does not meet certain requirements. One release can have several builds
associated with it.

Software Testing
Software testing is a critical part of the software development lifecycle,
ensuring that software products meet quality standards and function as
expected.
Requirement analysis
Objective: In this phase, the testing team reviews the requirements
documents (such as Functional Specifications, Business Requirements, or
User Stories) to understand what the software is supposed to do.

Deliverables: Test requirements document, test objectives, risk analysis.

Test Planning
Objective: This phase involves planning the overall testing strategy,
resources, timeline, and scope.

Deliverables: Test Plan, resource allocation, test schedules, risk

mitigation plan.

Test Case Development

Objective: In this phase, detailed test cases and test scripts are created
based on the requirements and design documentation.

Deliverables: Test cases, test scripts, test data, test scenario

documentation.

Environmental setup
Objective: This phase focuses on setting up the necessary test
environment to execute the tests. Set up the hardware, software, and
network configurations required for testing.

Deliverables: Test environment setup, environment validation report.

Test Execution
Objective: In this phase, the test cases are executed based on the test
plan and the test design.

Deliverables: Test execution report, defect reports, logs of executed test

cases, and progress reports.

Test Cycle Closure

Objective: This phase involves closing out the testing process after all
tests are executed, defects are resolved, and the product is ready for
release.

Deliverables: Test closure report, test summary report, final defect

report, archived test artifacts.

Testing Strategy
• Test strategy is a high-level plan consisting of principles that guide the
overall software testing process. It provides a structured approach to the
entire QA team, guiding them toward achieving testing objectives in the
most efficient way.

• The test strategy document is a well-written document that outlines the

precise methodology and goals of the testing project. It is an important
document for QA teams and is based on actual business requirements.
The test strategy document addresses all your questions about what you
want to achieve and how you plan to do it in the project.

• A test strategy refers to an organization-level document describing the

testing approach, also known as what the testing team needs to achieve
and how they can achieve it. Instead of outlining project-specific testing
needs, this document presents some common testing principles for all
projects.

Need a Test Strategy? Why!

• Guides the testing effort by providing focus, clarity, and effective risk
management.
 • Ensures efficiency, effectiveness, and adherence to standards in testing
practices.

• Promotes better collaboration between members of the QA team.

• Ensures that all members are aligned on the overall vision of the project.

• Acts as reference for resource planning and allocation for optimal

utilization.

• Allows you to track progress more efficiently.

TEST STRATEGY TEST PLAN

Provides a high-level approach, Specifies detailed instructions,

PURPOSE objectives, and scope of testing procedures, and specific tests to
for a software project be conducted
Detailed test objectives, test
Testing approach, test levels,
FOCUS cases, test data, and expected
types, and techniques
results
Testing team members, test
Stakeholders, project managers,
AUDIENCE leads, testers, and stakeholders
senior testing team members
involved in testing

Entire testing effort across the Specific phase, feature, or

SCOPE
project component of the software
Highly detailed, specifying test
LEVEL OF
Less detailed and more abstract scenarios, cases, scripts, and
DETAIL
data
Allows flexibility in
FLEXIBILIT Relatively rigid and less prone to
accommodating changes in
Y changes during the testing phase
project requirements
Evolves throughout the testing
LONGEVIT Remains relatively stable
process, incorporating feedback
Y throughout the project lifecycle
and adjustments

Test Approaches
• A test approach is a way of working for designing and executing tests.
There are two groups of test approaches: experience-based testing and
 coverage-based testing. The test approach is the approach that someone
takes when creating test cases.

• A test approach is the implementation of the test strategy in a software

project that defines how testers will carry out software testing, along with
throwing light on strategy and execution to carry out different tasks. The
testing approach also refers to the testing techniques, tools, strategies,
and methodologies for testing any software product.

• Testers can easily outline objectives, the scope of testing, and expected
results through a testing approach.

There are several different types of test approaches and strategies,

including:

• Proactive and Reactive

• Manual and Automated

• Black-box, White-box and Grey-box

• Scripted and Unscripted

• Static and Dynamic

Black-box testing: Black-box testing is a test approach where the tester

has no knowledge of the internal workings of the software being tested. The
tester only interacts with the software's input and output.

White-box testing: White-box testing is a test approach where the

tester has detailed knowledge of the internal workings of the software being
tested. The tester uses this knowledge to design and execute tests that
examine the internal structure of the software.

Gray-box testing: Gray-box testing is a test approach that combines

elements of both black-box and white-box testing. The tester has some
knowledge of the internal workings of the software being tested, but not full
knowledge.

Functional testing: Functional testing is a test approach that focuses

on verifying that the software functions as intended. This involves testing
individual functions or features of the software to ensure that they meet the
required specifications.

Non-functional testing: Non-functional testing is a test approach that

focuses on verifying the performance, reliability, security, and other non-
functional aspects of the software. This includes testing factors such as load
capacity, response times, and security vulnerabilities.

Automated testing: Automated testing is a test approach that involves

using tools and scripts to execute tests automatically. This can help to reduce
the time and effort required for testing and improve the consistency of test
results.

Manual testing: Manual testing is a test approach where the tester

manually executes tests on the software being tested. This involves using a
range of techniques, such as exploratory testing, to identify and report issues
with the software.

Agile testing: Agile testing is a test approach that is designed to be used

in an agile software development environment. This involves iterative
testing, with testing occurring throughout the software development
lifecycle.

Scripted and Unscripted

Scripted testing involves

detailed test scripts with
specific steps, whereas
unscripted testing
provides testers with
flexibility and the freedom
to choose their
approaches.
Scripted and Unscripted

Scripted Testing Unscripted Testing

Testers have the flexibility to choose

The software is tested using a
any approach they deem appropriate
traditional and structured approach.
for testing the software.
Testers rely on prior knowledge and
Testers draw on their expertise and
research expertise for testing
knowledge during the testing process.
purposes
Solid documentation is a necessary Unscripted testing does not require
component of scripted testing. specific documentation.

Test scripts are written and followed There is no need for the preparation
during the testing process. of test scripts in unscripted testing.

Extensive planning is required for Advance planning is not necessarily

scripted testing. required for unscripted testing.

The software is compared to the

Software is compared to predefined
tester's mental model or
requirements and standards.
expectations.

Scripted testing allows for Less extensive reproducibility in

reproducibility of results. unscripted testing.
 Unscripted testing generally takes
This testing process often takes a
less time compared to scripted
significant amount of time.
testing.

Proactive and Reactive Test Approach

SQA vs. SQC