Overview of Module 4

OVERVIEW

This week’s content will focus on the different types of testing including Functional and Non-
Functional test types focusing on the role of the Business Analyst in supporting both test types.
A review of the various Non-Functional test types will assist in understanding this area in greater
detail.

A review of Use Case Testing and Agile Testing using User Stories will also aid in
understanding the differences between Traditional development testing methodologies and agile
testing methodologies.

Learning Objectives
On successfully completing this week's module, you will be able to
 Discuss properties of Functional and Non-Functional Testing
 Review of Use Case Testing and Agile Testing using User Stories

Activity Preview

This week's activities include

 Review the Weekly Schedule
 Reviewing the Course Materials for Module 4.1 and 4.2
 Completing the self-check exercises/questions after each unit to prepare for the
Assignment
 Completing an assignment worth 20% of the final mark

Module 4.1 Testing Types – Continued

Functional Testing
Testing of the system functionality (what the system “does”) as captured in
requirements documentation, specifications, use cases, decision models, etc. For
example: calculates taxes, generates reports, sends email notifications, display
webpages, etc.

Functional testing is a type of software testing that verifies if a system or application

works as expected and meets the specified requirements. It involves testing the
functionality of the system by simulating real-world scenarios and evaluating the results
against expected outcomes. The main objective of functional testing is to validate the
software's behavior, making sure it performs its intended functions correctly, without any
defects or errors. This testing is performed by testing individual functions or features of
the software and evaluating their output, comparing it with the expected results.
Some examples of functional testing include:
 Unit Testing: Testing individual components or units of code to ensure they
function as intended.
 Integration Testing: Testing how different components of the system work
together.
 End-to-end Testing: Testing a complete flow of the system, simulating real-world
scenarios to ensure the system meets the requirements.
 User Acceptance Testing: Testing the software with real users to verify that it
meets their expectations.
 Smoke Testing: Basic testing to check if the critical functions of the software work
properly.
 Regression Testing: Testing to ensure that changes made to the software do not
affect existing functionality.
 System Testing: Testing the software as a whole to verify its compliance with the
specified requirements.

These are just a few examples of functional testing. The specific tests used will depend
on the software being developed and the requirements it must meet.

The Role Of A Business Analyst In Functional Testing

A Business Analyst (BA) plays a crucial role in functional testing by defining and
clarifying the business requirements and ensuring they are met during the testing
process. The BA works closely with the development team, stakeholders and subject
matter experts to understand the system requirements, process flows, and user stories.
They help to create test cases, test plans and ensure that the functional testing covers
all aspects of the system, including edge cases and corner scenarios. In short, the BA
acts as a liaison between the business stakeholders and the testing team to ensure that
the final product meets the business requirements and satisfies the end-user needs.

A QA specialist may seek advice from a Business Analyst when conducting:

 Functional testing. A Business Analyst explains the business logic of the project
and points that are incomprehensible to a tester.
 Regression testing. Based on critical business functions, a Business Analyst
advises which test cases to include in this testing phase.
 Usability testing. For a Business Analyst, it is important that the application is
as convenient as possible and has demand in the market. This will allow the
customer to evaluate the performance of this expert and their foresight. They
also recommend to testers how to improve a particular functionality to increase
the quality and value of software solutions.
 End-to-end testing. To create end-to-end tests, a QA specialist needs to
understand an application, its business logic, and user scenarios. In this case,
the tester will be able to use the important details for each function: the correct
input data, the exact restrictions, the correct sequence of steps, and different
ways to call a function.
 Acceptance testing. A Business Analyst confirms that the product meets the
business requirements.
 Beta testing. IT outsourcing company testers are not involved in this type of
testing. In this case, real users work with the application. A Business Analyst
 observes this process, notes what needs to be improved in the product before its
release, and makes sure that the application is really valuable.

Reference link

Non-functional Testing

Non-functional testing in software development is a type of testing focused on

evaluating a software system's non-functional requirements such as performance,
scalability, reliability, security, compatibility, and usability. Non-functional testing aims to
verify how well the system operates under different conditions and constraints, such as
heavy load or stress, and to ensure that the system meets the specific requirements
that cannot be tested through functional testing.

Testing of system for its non-functional requirements, as captured in requirements

documentation / specifications. What the system “is”; the conditions or constraints under
which the system’s functions must operate.

Types of Non-Functional Testing include:

Performance Testing – Performance testing is a type of non-functional testing in

software development that focuses on evaluating the performance and scalability of a
system. The goal of performance testing is to identify bottlenecks, measure the system's
response time, throughput, and resource utilization under various loads, and to evaluate
the system's ability to handle large amounts of data and users. This testing can involve
various techniques, such as load testing, stress testing, and scalability testing, and can
be performed on various components of the system, such as the database, network,
and server. Performance testing is an important aspect of software development, as it
helps to ensure that the system can handle the expected workload and to identify areas
for improvement in terms of performance and scalability.

Testing of the system to establish a baseline for system performance (ex. acceptable
response time, number of concurrent users)
Divided into sub-types:

1) Stress Testing of the system subjects it to reduced resources; what’s the behaviour
under abnormal load changes that are significantly higher than expected.
1. To determine system’s response to a sudden, severe load for a period of
time (ex. 1 hour) and then return to normal
2. Think of seasonal online shopping (ex. Mother’s Day, Black Friday,
Christmas)

2) Load Testing - Load Testing of the system subjects it to heavy loads; does it
maintain the specified quality characteristics under load within the permissible limits
and some exceeding of these limits
1. By simulating multiple users, typically
2. To determine at what point the system ‘blows up’
3. ‘Fix > Blow Up > Fix’ cycle which ideally ends with computing resources
maximized, yet the system retains functionality
Video link

3) Scalability Testing - is a type of non-functional testing in software

development that determines how well a system can handle increasing
load, such as user traffic or data processing. The goal of scalability testing
is to verify that the system can handle the expected growth in usage and
to identify any bottlenecks or limitations that may prevent the system from
meeting future demands. This testing can help to identify and resolve
performance issues early in the development cycle, and to ensure that the
system is able to scale up smoothly and efficiently to meet the changing
needs of the business.

4) Reliability testing - is a type of non-functional testing in software

development that focuses on evaluating the ability of a system to perform
its intended functions correctly and consistently over a specified period of
time. The goal of reliability testing is to identify and quantify the system's
dependability, stability, and resilience, and to ensure that it operates as
expected even under adverse conditions, such as high traffic, power
outages, or hardware failures. This testing is designed to provide
confidence in the system's ability to operate smoothly and to minimize
downtime and data loss. Reliability testing can include various methods
such as stress testing, load testing, and failure testing.

5) Compatibility Testing - is a type of non-functional testing in software

development that verifies that a system works as expected on different
hardware and software platforms, operating systems, and browsers. The
goal of compatibility testing is to ensure that the system can operate
seamlessly on a variety of configurations, and to identify and resolve any
compatibility issues that may arise. This testing can involve evaluating the
system's compatibility with different screen resolutions, browser versions,
and mobile devices, among others. Compatibility testing is important to
ensure that the system is accessible and usable by a wide range of users,
regardless of their device or operating system, and to minimize the risk of
compatibility-related issues in production.

6) Usability Testing - is a type of non-functional testing in software

development that focuses on evaluating the ease of use and user-
friendliness of a system. The goal of usability testing is to ensure that the
system is user-friendly, intuitive, and accessible, and to identify any areas
of improvement in the user interface, navigation, and overall user
experience. This testing typically involves having real users perform tasks
and interact with the system, while observing and recording their behavior,
and collecting their feedback and suggestions. Usability testing can be
conducted at various stages of development, from prototyping to final
release, and is an important aspect of creating software that meets the
needs and expectations of its users.

7) Accessibility Testing - is a type of non-functional testing in software

development that focuses on evaluating the accessibility of a system for
 people with disabilities, such as visual, auditory, motor, and cognitive
impairments. The goal of accessibility testing is to ensure that the system
is usable and accessible to all users, regardless of their abilities. This
testing can involve various techniques, such as manual testing, automated
testing, and code reviews, and can be performed on various components
of the system, such as the user interface, navigation, and content.
Accessibility testing is an important aspect of software development, as it
helps to ensure that the system is inclusive and usable by all users, and to
comply with accessibility regulations and standards, such as the Web
Content Accessibility Guidelines (WCAG).

Video link

8) Security Testing – is a type of non-functional testing in software

development that focuses on evaluating the system's resistance to
security threats and vulnerabilities. The goal of security testing is to
identify and assess any potential security risks and to ensure that the
system is protected against unauthorized access, data breaches, and
other security incidents. This testing can involve various methods, such as
penetration testing, threat modeling, and code reviews, to simulate attacks
and evaluate the system's defenses. Security testing is a critical
component of software development, as it helps to ensure the
confidentiality, integrity, and availability of sensitive data and systems, and
to minimize the risk of security incidents in production.

Testing of the system in order to withstand illicit attempts to access data, or

functions that an intruder is not authorized to access.

Examples may include:

 Terminate a session after 3 incorrect passwords.
 Passwords must have one letter, one number, and be longer than 8 characters.
 Users require to change passwords every 6 weeks.

Video link

9) Internationalization testing, - also known as "I18n testing," is a type of

non-functional testing in software development that focuses on evaluating
the ability of a system to support multiple languages and cultural regions.
The goal of internationalization testing is to ensure that the system can be
adapted and localized for use in different countries and regions, without
causing any functional or technical issues. This testing can involve
evaluating the system's handling of different languages, character sets,
date and time formats, currency symbols, and other regional and cultural
differences. Internationalization testing is important to ensure that the
system can be used effectively by a global audience and to minimize the
risk of localization-related issues in production. Examples include:
 What happens if a user opens a file with a hieroglyph name?
 How the interface works if a user switches it from English to French, and vice-
versa.
 Can the application look up data in Korean text?
 10)Localization testing, - also known as "L10n testing," is a type of non-
functional testing in software development that focuses on evaluating the
localization of a system for a specific language or cultural region. The goal
of localization testing is to ensure that the system has been translated and
adapted correctly for use in a specific locale, taking into account cultural
and linguistic differences, such as date and time formats, currency
symbols, and text direction. This testing can involve comparing the
localized system to the original version, and verifying that all elements of
the user interface, help files, and other documentation have been
translated accurately and appropriately. Localization testing is an
important aspect of internationalization testing and is necessary to ensure
that the system can be used effectively by a specific target audience and
to meet the cultural and linguistic needs of a specific region.

Positive Testing

Positive testing is a type of software testing that focuses on verifying that a system
behaves as expected when provided with valid input data. The goal of positive testing is
to ensure that the system functions correctly and provides the correct output for a range
of valid input scenarios. This testing is usually performed by providing valid input data
that falls within the expected range, and then verifying that the system produces the
expected output. Positive testing is an important aspect of software testing, as it helps
to ensure that the system works correctly for normal, everyday use and provides the
expected results for a range of valid input scenarios.

Examines the application in a situation where all activities are carried out strictly as
instructed, with no errors, deviations, incorrect data input, etc.
 If positive test cases end with errors, this is a red flag — the application is not
working properly even under ideal conditions.
 To speed up testing, several positive Test Cases can be combined (e.g., “before
submitting, fill in all form fields with correct values”)

Positive testing determines that your application works as expected. If an error is

encountered during positive testing, the test fails.

Negative Testing

Negative testing is a type of software testing that focuses on verifying that a system
behaves as expected when provided with invalid or unexpected input data. The goal of
negative testing is to identify and prevent any errors or unexpected behavior when the
system is presented with invalid or unexpected input. This testing is usually performed
by providing input data that falls outside the expected range, and then verifying that the
system produces the appropriate error messages, handles the situation gracefully, and
prevents any harm to the system or data. Negative testing is an important aspect of
software testing, as it helps to ensure that the system can handle unexpected input,
prevent data corruption, and provide appropriate error messages for a range of invalid
input scenarios.
Negative testing ensures that your application can handle invalid input or unexpected
user behavior. For example, if a user tries to type a letter in a numeric field, the correct
behavior in this case would be to display the “Incorrect data type, please enter a
number” message.

The purpose of negative testing is to detect such situations and prevent applications
from crashing. Negative testing helps you improve the quality of your application and
find its weak points.

The difference between positive testing and negative testing

Regression Testing

Regression testing is a type of software testing that focuses on verifying that changes to
a system have not introduced new bugs or broken existing functionality. The goal of
regression testing is to ensure that changes to the system, such as bug fixes, updates,
or new features, do not negatively impact existing functionality or introduce new
problems. This testing typically involves re-running a subset of tests that were
previously executed and passed, to verify that the system still behaves as expected.
Regression testing is an important aspect of software testing, as it helps to ensure the
stability and reliability of a system, and to minimize the risk of introducing new problems
with each change to the system.

Testing which verifies that previously working functionality has not been affected by
errors caused by changes in the application or its environment.
 What worked before (yesterday, last build of code, last released version) is still
working (has not regressed)
 Compilation of various tests from overall Test Plan
 Just as important as testing new functionality; indispensable tool in testers’
‘toolbox’

Video link

References
Module 4.2

Use Cases
Use cases are a high-level description of the interactions between a system and its
users to achieve a specific goal. In software development, use cases are used to
describe the functional requirements of a system and to capture the scenarios in which
the system is intended to be used. A use case typically includes a description of the
user, the goal to be achieved, the steps involved in achieving the goal, and any
alternative scenarios that may occur. Use cases are used as a basis for design,
development, testing, and documentation of a system. They provide a clear and concise
representation of the system's functionality and help to ensure that all stakeholders
have a shared understanding of the system's requirements and behavior.

According to BABOK v3:

 Use cases describe the interactions between the primary actor, the solution (i.e.
the system), and any secondary actors needed to achieve the primary actor's
goal.
 A use case describes the possible outcomes of an attempt to accomplish a
particular goal that the solution will support.
 Use cases are usually triggered by the primary actor, but may also be triggered
by another system or by an external event or timer.
 A scenario describes just one way that an actor can accomplish a particular goal.


The video clip discusses how to create use cases.

Use Cases and Testing

Cases are a very common way of defining requirements because of their many
advantages:

 Business stakeholders love Use Cases because they define the system from the
end user's perspective. Like user manuals, use cases describe the steps that
users must perform to achieve their goals.
 Project managers love Use Cases because they can be used to define scope.
Because each Use Case describes a given functionality, a list of Use Cases can
be used to limit the functionality that will be delivered.
 Finally, testers love Use Cases because they make the tester's job much easier.
Use Cases already contain many of the elements that must be included in test
cases, such as preconditions, postconditions and steps, so it is relatively easy to
write test cases based on Use Cases

Disadvantages of Use Cases don't have any disadvantages.

 Use Cases can be overutilized, and are sometimes used to define requirements
that don't lend themselves well to use case specification.
  Because Use Cases emphasize the most common "business as usual"
scenarios, they emphasize how the system should work, as opposed to the ways
in which the system can fail and making the system fail is, of course, one of the
goals of testing.
 Use Cases can be challenging to write correctly. Although Use Case templates
are relatively straightforward, they are often filled out incorrectly, which makes it
hard for the audience of the document, particularly developers and testers, to do
their jobs correctly. Writing Use Cases well takes skill and practice, but it will
have payoffs in terms of reducing the effort required to create test cases.

Tip: If the purpose of the Use Case is to subsequently generate black box test cases,
the Use Case should not describe the inner workings of the system. It should only
describe the user input and the system output.

Use Case Models

If you have previous experience with Use Cases, you may have seen Use Case
Models with stickmen and ovals, such as the one shown in the figure above. In use
case models, the system boundary is represented by a rectangle, each actor is
represented by a stickman, and each use case is represented by an oval.

Use case models are great for defining the system boundary and for understanding the
relationships between use cases. For testing purposes, however, use case models don't
contain enough information to create a test case specification.
Use Case Activity Diagrams

Activity diagrams are a way to illustrate individual use cases so that they can be used
to generate test cases. Activity diagrams with "swim-lanes" are useful for showing the
interaction between a system and various actors. They are also useful for showing use
cases with multiple flows. For example, an activity diagram could show the basic path of
a use case, as well as alternative flows and exceptions.

The figure above is an activity diagram illustrating the ATM use case. The green line
indicates the basic flow, the yellow line indicates the alternative flow, and the red line
shows the exception flow.
Use Case Specifications

Written use case specifications contain much of the information required to create test
cases, although they do not contain specific inputs or outputs, nor do they contain setup
instructions. Here is the information that must be included in a use case specification:

 Use case ID: A unique identifier for the use case. For example, UC-01.
 Use case name: The name of the use case in terms of the user goal, in Verb-
Noun format. For example, Withdraw Cash.
 Use case description: A brief description of the use case. For example, "This
use case describes the steps taken by the account holder to withdraw cash."
 System: The name of the system that is being specified. For example, the ATM
system.
 Primary actor: The actor that initiates the action and that has a goal requiring
the assistance of the system. For example, account holder.
 Secondary actor(s): Any actor that is called upon by the system because it is
needed to satisfy the primary actor's goal. For example, PIN verification sub-
system.
 Preconditions: Conditions that must be in place prior to the start of the use
case. For example, the user has an active account and a valid bank card.
 Postconditions: Conditions that will be in place after the use case if the user
has achieved his or her goals. For example, the ATM has provided cash to the
user.
 Trigger: The action or event that triggers the use case. For example, the account
holder inserts the bank card into the ATM. Note that some use case are triggered
by events, such as "the first day of the month arrives" or "the balance falls below
zero".
 Normal Flow, also known as Basic Path: The simplest steps required for the
primary actor to achieve his or her goal. By convention, the steps are often
numbered. Ideally, the steps should be written in alternating "He Says, She
Says" format, like a dialogue or a screenplay. For example:
o 1. The user inserts the card.
o 2. The system displays the PIN screen.
o 3. The user enters the PIN.
o 4. The system verifies the PIN.
o 5. The system displays the transaction selection screen. The options are:
Withdraw, Deposit, Check Balance.
o 6. The user selects Withdraw and enters an amount.
o 7. The system checks that the user has sufficient funds and provides the
cash.
 Alternative Flows: Alternative ways in which the primary actor can achieve his
or her goal. For example:
o 6a. The user selects Check Balance.
o 6b. The system displays the account balance.
o 6c. The user selects Withdraw and enters an amount.
 Exceptions: Errors that result in the user not achieving his or her goal. For
example:
 o 3b. The user enters an invalid PIN.
o 3c. The system displays a "try again" error message.

Example: Use Case Specification

The final use case specification might look like this:

Identifier: UC-01
Use case name: Withdraw Cash (note the verb-noun syntax)
Use case description: This use case describes the steps taken by the account
holder to withdraw cash.
System: ATM system
Primary actor: Account holder
Secondary actor(s): PIN verification sub-system
Trigger: The account holder inserts the bank card into the ATM
Preconditions: The user has an active account and a valid bank card
Postconditions: The ATM has provided cash to the user
Basic path: 1. The user inserts the card.
2. The system displays the PIN screen.
3. The user enters the PIN.
4. The system verifies the PIN.
5. The system displays the transaction selection
screen. The options are: Withdraw, Deposit,
Check Balance.
6. The user selects Withdraw and enters an
amount.
7. The system checks that the user has sufficient
funds and provides the cash.

Alternative flows:  6a. The user selects Check Balance.

 6b. The system displays the account balance.

 6c. The user selects Withdraw and enters an

amount.

Exception flows:  3b. The user enters an invalid PIN.

 3c. The system displays a "try again" error

message.

Tips For Writing Good Use Cases

To write clear use cases that can be readily transformed into test cases, do the
following:

 Use the active voice, so your reader can tell who is doing what. An example of
the active voice: "The system validates the PIN". An example of the passive
voice with a subject: "The PIN is validated by the system". An example of the
 passive voice without a subject: "The PIN is validated". This final example is the
most confusing, as the reader can't tell who is doing what.
 Use the present tense, as it is more vivid. An example of the present tense: "The
system validates the PIN". An example of the future tense: "The system will
validate the PIN".
 Put the right information into the right slots, so key details doesn't get lost. For
example, don't put a business rule in the use case description.
 Write short sentences, as they are easier to digest.

Generating test cases from use cases

In order to generate test cases from a use cases, do the following:

1. Create one test case per flow. The ATM use case above, for example, would
generate three test cases.
2. For each test case, fill in the preconditions and postconditions from the use case.
Note: if the test case is for an exception flow, then the postconditions will be
different.
3. Fill in the Input Values using the actions performed by the user, but with specific
values. For example, instead of "User enters PIN", state "John Smith enters
1234".
4. Fill in the Expected Results using the actions performed by the system, but with
specific values.
5. Add any necessary setup steps. In the ATM example, this might involve creating
a user named "John Smith" with a given account balance.
6. In the traceability/cross-reference section, list the use case ID.

The video clip discusses use case testing.

Agile Testing

Agile software testing is a testing approach that is based on the principles of Agile
software development and is designed to be flexible, adaptive, and responsive to
changing requirements. It differs from traditional software testing in several keyways:
 Iterative approach: Agile software testing is performed in an iterative manner,
with testing and development activities happening in parallel and being executed
in short sprints or iterations. This approach allows for rapid feedback and enables
teams to quickly identify and resolve issues.
 Collaborative approach: Agile software testing is a collaborative effort between
developers, testers, and stakeholders, with everyone working together to ensure
the quality of the product. This approach allows for better communication and
collaboration and helps to ensure that everyone is on the same page.
 Focus on end-to-end testing: Agile software testing focuses on end-to-end
testing, ensuring that the entire system works together seamlessly. This
approach ensures that the system behaves as expected in real-world scenarios
and helps to identify any issues early in the development process.
 Flexible testing strategies: Agile software testing is flexible and adaptive,
allowing teams to change their testing strategies as needed to keep pace with
the changing requirements and evolving technology.

Traditional software testing, on the other hand, is typically more sequential and rigid,
with testing being performed only after the development process has been completed.
This approach can result in longer development cycles and higher costs and may not be
as effective in identifying and resolving issues early in the development process.

The video clips below discuss agile testing:

Video 1
Video 2

User Stories
User stories are a way of capturing and expressing the requirements of a system from
the perspective of the end user. In Agile software development, user stories are used to
describe the functional requirements of a system in a simple, user-centric way. A user
story typically consists of a brief description of the user, the goal they want to achieve,
and the value that the goal will bring to them.

User stories are used to help teams focus on delivering value to the end user, and to
ensure that the requirements of the system are well understood by everyone involved in
the development process. They provide a simple and concise way to describe the
functionality of the system and to prioritize requirements based on their importance to
the user. User stories are typically small, easy to understand, and can be broken down
into smaller, more manageable tasks that can be implemented in an Agile development
environment.
On projects that use the agile software development methodology, the requirements are
written in the form of user stories. User stories consist of single sentences that take the
form:

As a [user role], I want to [desired functionality] in order to [business value].

An example of a user story for an ATM system would be:

"As an account holder, I want to be able to view my account balance in order to

see how much cash is available".

Test cases in agile projects take the form of acceptance criteria, which are sometimes
called conditions of satisfaction (CoS). Acceptance criteria are written at the same
time as the user story and enable the development team to provide an estimate for the
user story.

Conditions of satisfaction (CoS) are a set of criteria that are used to evaluate the
success of a user story in Agile software development. CoS are a way of defining the
acceptance criteria for a user story and ensuring that the requirements of the story have
been fully met.

Conditions of satisfaction provide a clear and concise definition of what needs to be

done to complete a user story and what constitutes a "done" user story. They help to
ensure that the functional requirements of a system are well understood and that
everyone involved in the development process is working towards the same goal.

Conditions of satisfaction can be used to evaluate the functionality of the system, the
quality of the code, the usability of the user interface, and other non-functional
requirements. They can also be used to evaluate the performance, scalability, and
reliability of the system, and to ensure that the system is accessible and secure.

In short, conditions of satisfaction are a key tool in Agile software development for
ensuring that the requirements of a user story are fully met and that the system meets
the expectations of its users.

An example of an acceptance criterion for the above user story would be:

"I can see my account balance".

Below are the video links:

User Stories
User Stories VS Requirements
References and additional resources

 International Institute of Business Analysis (2015). 10.47 Use Cases and Scenarios. In BABOK
v3: A Guide to the Business Analysis Body of Knowledge (pp. 356-359). Toronto: IIBA.
 Wiegers, Karl. (2012, July 26). The Use Case Technique: An Overview. Modern Analyst.
Retrieved from modernanalyst.com.
 Westfall, L. (2010, December 10). Writing Testable Requirements. CQAA Webinar. Retrieved
from all cqaa.org.
 Berger, B. (n.d.). The Dangers of Use Cases Employed as Test Cases. Test Assured. Retrieved
from testassured.com.
 Donaldson, N. (2012, June 26). User stories part 2: Acceptance criteria. Boost Agile Blog.
Retrieved from boostagile.com.