Basic Algorithms

and Application
Development

Module 4
Session 1: Basic Application Development

Learning Objectives
After this session, you will be able to:
• Differentiate between agile and rapid application
development process.
• Discuss the concept of software design and algorithm design.
• Discuss the concept of incident management during algorithm
design and the process flow to resolve a disruption.
1.1 Agile vs. Rapid Application Development

Agile and Rapid Development Process

Agile Development

• Agile is a software development style that prioritises

the delivery of value to customers by utilising
iterative development cycles. It places a high
importance on engaging with customers, being
adaptable, and being able to respond effectively to
changes.
1.1 Agile vs. Rapid Application Development

Agile and Rapid Development Process

Agile Development

• Agile approaches, such as Scrum, Kanban, and

Extreme Programming (XP), prioritise short
development cycles known as "sprints" or
"iterations." Teams collaborate closely with
consumers and stakeholders to collect input and
make incremental adjustments to the product based
on that feedback.
1.1 Agile vs. Rapid Application Development

Agile Development

Phases of Agile Development

• In Agile development, projects progress through

iterative phases that focus on delivering working
software increments. While Agile methodologies like
Scrum and Kanban may have slightly different
terminology or variations, here are the common
phases you'll typically encounter in Agile
development:
•
1.1 Agile vs. Rapid Application Development

Phases of Agile Development

1. Initiation/Discovery

• Visioning: Define the project vision and high-level

goals.

• Product Backlog Creation: Create a prioritised list of

features and requirements, known as the product
backlog.
1.1 Agile vs. Rapid Application Development

Phases of Agile Development

1. Initiation/Discovery

• Team Formation: Assemble a cross-functional Agile

team with the necessary skills for the project.
1.1 Agile vs. Rapid Application Development

Phases of Agile Development

2. Planning

• Release Planning: Determine the scope of the first

iteration or release based on priorities from the
product backlog.

• Iteration Planning: Plan the specific tasks and goals

for the upcoming iteration (sprint).
1.1 Agile vs. Rapid Application Development

Phases of Agile Development

3. Execution

• Sprint Execution: Develop and deliver the planned

features and functionality during the sprint.

• Daily Stand-ups: Conduct daily stand-up meetings

for the team to discuss progress, challenges, and
coordination.
1.1 Agile vs. Rapid Application Development

Phases of Agile Development

4. Review/Demo

• Sprint Review: Showcase the finalised work to

stakeholders and collect feedback.

• Retrospective: Engage in introspection over the

sprint process, discover areas that require
enhancement, and implement modifications for
subsequent sprints.
1.1 Agile vs. Rapid Application Development

Phases of Agile Development

5. Iterative Development

• Repeat: Repeat the planning, execution, review, and

retrospective phases for subsequent iterations
(sprints).

• Incremental Delivery: Continuously deliver working

software increments at the end of each iteration,
adding value to the product with each cycle.
1.1 Agile vs. Rapid Application Development

Phases of Agile Development

6. Closure

• Product Release: Release the product increment to

customers or end-users as part of a larger release or
as a standalone update.

• Project Closure: Review project outcomes,

document lessons learned, and close out the project
as necessary.
1.1 Agile vs. Rapid Application Development

• Throughout these stages, Agile teams prioritise communication, adaptability,

and customer input.

• Agile development's iterative structure enables teams to incrementally

construct and modify products while effectively adapting to changing needs
and market conditions.

• Agile techniques provide structures and processes to support each phase and
assure project success while remaining focused on delivering value to
stakeholders.
1.1 Agile vs. Rapid Application Development

Rapid Application Development (RAD)

• RAD is a development methodology that prioritises rapid prototyping and

iterative development to quickly produce a high-quality system. It aims to
reduce the time taken to develop software by using rapid prototyping and
iterative feedback. RAD typically involves the following key phases:
1.1 Agile vs. Rapid Application Development

Rapid Application Development (RAD)

• Requirements Planning: Gathering and analysing user requirements.

• User Design: Creating prototypes or mock-ups based on user requirements for
quick feedback.
• Rapid Construction: Developing the software in iterative cycles, focusing on
core functionalities first.
• Cutover: Transitioning the system from development to production, often
involving testing, training, and deployment.
1.1 Agile vs. Rapid Application Development

• Agile emphasises continuous customer collaboration and adaptability through

iterative development cycles, while RAD focuses on rapid prototyping and quick
iterations to accelerate the software development process.

• Both methodologies share common goals of delivering high-quality software

while responding effectively to customer needs and changes in requirements.
1.1 Agile vs. Rapid Application Development

Phases of Rapid Application Development (RAD)

• Rapid Application Development (RAD) is a software development process that

prioritises speed and flexibility while providing software solutions.

• The RAD process typically consists of multiple phases, each focused on fast
prototyping, iterative development, and close engagement with stakeholders.

• Here are the typical phases of RAD:

1.1 Agile vs. Rapid Application Development

Phases of Rapid Application Development (RAD)

1. Requirements Planning

• Collect initial requirements from stakeholders.

• Conduct seminars, interviews, or brainstorming sessions to identify user
requirements and expectations.
• Define the scope of the project and set high-level goals.
1.1 Agile vs. Rapid Application Development

Phases of Rapid Application Development (RAD)

2. User Design

• Create prototypes or mock-ups of the proposed system based on gathered

requirements.
• Use rapid prototyping tools to develop visual representations of user interfaces
and workflows.
• Solicit feedback from users and stakeholders to refine and validate the design
quickly.
1.1 Agile vs. Rapid Application Development

Phases of Rapid Application Development (RAD)

3. Construction

• Develop the software system based on the approved designs and prototypes.
• Use RAD frameworks or development tools to accelerate coding and
implementation.
• Focus on building core functionalities and features that align with user
priorities.
1.1 Agile vs. Rapid Application Development

Phases of Rapid Application Development (RAD)

4. Cutover

• Prepare for the deployment and integration of the developed system into the
production environment.
• Conduct system testing, including unit testing, integration testing, and user
acceptance testing (UAT).
• Address any issues or defects identified during testing and ensure readiness for
deployment.
1.1 Agile vs. Rapid Application Development

Phases of Rapid Application Development (RAD)

5. Deployment

• Deploy the completed system or application to the production environment.

• Coordinate with IT operations teams for installation, configuration, and rollout.
• Provide training and support to end-users and stakeholders as needed for
system adoption.
1.1 Agile vs. Rapid Application Development

Phases of Rapid Application Development (RAD)

6. Feedback and Iteration

• Gather feedback from users and stakeholders’ post-deployment.

• Iterate on the software based on feedback to address usability issues, enhance
features, and make improvements.
• Continue to refine and evolve the system through iterative cycles of
development and feedback.
1.1 Agile vs. Rapid Application Development

• RAD is characterised by its iterative and incremental approach, where rapid

prototyping and feedback loops drive the development process.

• This methodology is well-suited for projects with changing or unclear

requirements, tight timeframes, and a focus on user-centric design.

• By emphasising collaboration, quick iterations, and user involvement, RAD aims

to deliver functional software solutions efficiently while maintaining flexibility
to accommodate evolving needs.
1.1 Agile vs. Rapid Application Development

Principles and Practices

Agile and Rapid Application Development (RAD) has its own principles and
practices:

1. Agile Development

• Iterative and Incremental: Agile emphasises iterative development cycles

where features are developed in small increments, allowing for continuous
feedback and improvement.
1.1 Agile vs. Rapid Application Development

Agile Development

• Adaptive Planning: Plans are flexible and adaptable to changing requirements,

with a focus on delivering value to customers early and frequently.

• Collaborative Approach: Teams work closely together, including stakeholders,

to ensure transparency, communication, and shared understanding of goals.
1.1 Agile vs. Rapid Application Development

Agile Development

• Customer-Centric: Customer feedback is incorporated throughout product

development to suit customer needs and expectations.

• Scrum, Kanban, and XP: Agile frameworks like Scrum, Kanban, and Extreme
Programming (XP) provide specific guidelines and practices for implementing
Agile principles.
1.1 Agile vs. Rapid Application Development

Principles and Practices

• Adaptive Planning: Plans are flexible and adaptable to changing requirements,

with a focus on delivering value to customers early and frequently.

• Collaborative Approach: Teams work closely together, including stakeholders,

to ensure transparency, communication, and shared understanding of goals.
1.1 Agile vs. Rapid Application Development

2. Rapid Application Development (RAD)

• Prototyping: RAD emphasises quick prototyping and iteration to gather

feedback and refine requirements rapidly.

• User Involvement: Users are actively involved in the design and development
process to ensure the final product meets their needs.
1.1 Agile vs. Rapid Application Development

2. Rapid Application Development (RAD)

• Parallel Development: RAD often involves parallel development activities, such

as developing multiple components simultaneously, to speed up the overall
process.

• Reusable Components: RAD encourages the use of reusable components and

existing software libraries to accelerate development.
1.1 Agile vs. Rapid Application Development

2. Rapid Application Development (RAD)

• Focus on Time to Market: RAD is geared towards rapidly delivering a working

product to market, often prioritising speed over exhaustive documentation.
1.1 Agile vs. Rapid Application Development

Principles and Practices

• Both Agile and RAD share some common goals, such as delivering high-quality
software, adapting to change, and involving stakeholders throughout the
development process.

• However, they differ in their specific approaches and emphasis on speed,

flexibility, and customer involvement.
1.1 Agile vs. Rapid Application Development

Principles and Practices

• Organisations frequently pick between Agile and RAD based on project

complexity, team skills, time restrictions, and customer cooperation
preferences.

• Some projects may incorporate components of both techniques to capitalise on

their respective strengths and customise the approach to unique project
objectives.
1.1 Agile vs. Rapid Application Development

Principles and Practices

• While Agile and RAD have distinct use cases, some projects may benefit from a
combination of both methodologies or hybrid approaches that leverage their
respective strengths.

• Ultimately, the choice of methodology depends on factors such as project

requirements, team expertise, stakeholder collaboration, and project timelines.
1.1 Agile vs. Rapid Application Development

Difference Between Agile and Rapid Application Development (RAD)

Iterative Approach
Agile Development Rapid Application Development (RAD)
Agile development is an iterative strategy in RAD also uses an iterative approach but
which work is broken into tiny, manageable emphasises rapid prototyping and quick
increments known as sprints. Each sprint iterations to gather feedback and refine
usually lasts 1-4 weeks and yields a requirements. RAD iterations are often
potentially shippable product increment. shorter and focus on delivering functional
prototypes or mock-ups early in the
development process.
1.1 Agile vs. Rapid Application Development

Difference Between Agile and Rapid Application Development (RAD)

Customer Involvement
Agile Development Rapid Application Development (RAD)
Agile methodologies prioritise customer RAD also emphasises customer involvement,
collaboration throughout the development but its focus is more on rapid prototyping and
process. Customers are actively involved in user feedback. RAD projects often involve
providing feedback, reviewing product close collaboration with end users to gather
increments, and adjusting priorities based requirements and validate prototypes quickly.
on changing requirements.
1.1 Agile vs. Rapid Application Development

Difference Between Agile and Rapid Application Development (RAD)

Flexibility and Adaptability
Agile Development Rapid Application Development (RAD)
Agile approaches, such as Scrum and RAD is also flexible but may have a more
Kanban, possess a high degree of flexibility defined scope in terms of rapid prototyping
and adaptability when it comes to and iteration cycles. RAD projects aim to
accommodating changing requirements. deliver working prototypes or mock-ups early
Agile teams readily accept and adapt to to validate concepts and requirements before
changes, modifying their priorities in proceeding to full development.
response to client input and developing
business requirements.
1.1 Agile vs. Rapid Application Development

Difference Between Agile and Rapid Application Development (RAD)

Development Speed
Agile Development Rapid Application Development (RAD)
Agile development focuses on delivering a RAD is designed for rapid development and
working product increment at the end of time-to-market. It emphasises quick
each sprint, promoting a steady pace of iterations, parallel development activities,
development. The emphasis is on and the use of reusable components to
sustainable development practices that accelerate the development process and
ensure continuous progress. deliver functional prototypes or applications
rapidly.
1.1 Agile vs. Rapid Application Development

Difference Between Agile and Rapid Application Development (RAD)

Methodology Frameworks
Agile Development Rapid Application Development (RAD)
Agile methodologies include frameworks like RAD is a broader concept that encompasses
Scrum, Kanban, Extreme Programming (XP), various approaches to rapid development,
and Lean Agile. These frameworks provide prototyping, and iterative delivery. It may not
specific guidelines, roles, ceremonies, and have as rigid a framework as Agile
practices for implementing Agile principles. methodologies but can incorporate Agile
principles along with rapid prototyping
techniques.
1.1 Agile vs. Rapid Application Development

• While both Agile and RAD share a focus on iterative development, customer
involvement, and flexibility, they differ in their specific approaches to iteration
cycles, development speed, and methodology frameworks.

• Agile is known for its structured iterative approach with longer iterations, while
RAD emphasises rapid prototyping and quick iterations to achieve fast time-to-
market.

• Organisations may choose one or a combination of both methodologies based

on project requirements, team capabilities, and business objectives.
Session 2: Software & Algorithm Design Concepts

Learning Objectives
After this session, you will be able to:
• Explain the purpose of executing a test case and recording
outcomes in the assigned template
2.1 Software Design and Incident Management in Algorithm
Design

Software Design

• Software design entails conceptualising and arranging

a software system. It requires deciding how the
software will achieve its aims.

• Software design includes architectural, interface, data,

and component design.
2.1 Software Design and Incident Management in Algorithm
Design

Software Design

• The programme design provides a clear strategy or

blueprint to assist the development team in efficiently
implementing the programme, ensuring that it is
scalable, maintainable, and meets the desired
functionality and user experience.
2.1 Software Design and Incident Management in Algorithm
Design

Software Design

• It combines high-level system structure decisions with

low-level component details to provide a
comprehensive foundation for software development.
2.1 Software Design and Incident Management in Algorithm
Design

Software Design

• Key concepts of software design are:

1. Requirements Analysis

• Assessing user needs and expectations to define software features and

functionalities.
• Vital for ensuring the product solves the targeted challenges and meets user
expectations.
2.1 Software Design and Incident Management in Algorithm
Design

Software Design

2. Architecture System

• Defines the software system's high-level components, linkages, and

interactions.
• Provides a system blueprint to help developers organise and implement
modules.
2.1 Software Design and Incident Management in Algorithm
Design

Software Design

3. Component-Level Design

• Decomposing the system into smaller parts and designing their internal
structures and functions.
• Focused development, easier testing, modular maintenance.
2.1 Software Design and Incident Management in Algorithm
Design

Software Design

4. Designing Interface

• It specifies how components or modules will communicate, including input and

output formats, communication protocols, and user interfaces.
• Keeps system pieces communicating and simplifies user interaction.
2.1 Software Design and Incident Management in Algorithm
Design

Software Design

5. Designing Data

• Designing software data structures and storage techniques for organisation,

access, and management.
• Impacts data storage and retrieval efficiency and system performance.
2.1 Software Design and Incident Management in Algorithm
Design

Software Design

6. Algorithm Design

• Writing step-by-step software procedures or algorithms to solve problems or

complete tasks.
• Directly affects programme efficiency and effectiveness, including processing
speed and resource utilisation.
2.1 Software Design and Incident Management in Algorithm
Design

Software Design

7. Designing UX

• Designing the user interface and experience, including usability, accessibility,

and satisfaction.
• Impacts software adoption and success by affecting user perception and
interaction.
2.1 Software Design and Incident Management in Algorithm
Design

Software Design

8. Testing Validation

• Planning for several testing steps to guarantee software fulfils requirements

and works properly.
• Finds and fixes bugs to ensure programme stability and accuracy.
2.1 Software Design and Incident Management in Algorithm
Design

Software Design

9. Documentation

• Creating detailed software design, architecture, and component

documentation.
• Helps developers, maintainers, and stakeholders understand and improve.
2.1 Software Design and Incident Management in Algorithm
Design

Software Design

10. Flexible and Sustainable

• Making software adaptive and easy to maintain.

• Allows software to adapt to changing needs and be upgraded without
disturbance.
2.1 Software Design and Incident Management in Algorithm
Design

Algorithm Design

• Algorithm design refers to the systematic process of creating a detailed and

well-structured plan or set of rules for solving a specific computational
problem.

• It involves defining a sequence of steps or procedures that, when followed, lead

to the solution of the problem or the completion of a task.
2.1 Software Design and Incident Management in Algorithm
Design

Algorithm Design

• The goal of algorithm design is to develop efficient, correct, and scalable

algorithms that can be implemented in computer programs to solve real-world
problems or perform specific computations.

• This process includes input and output specifications, correctness, efficiency,

scalability, and readability.

• Here are key aspects of the concept:

2.1 Software Design and Incident Management in Algorithm
Design

Algorithm Design

Problem Input and

Efficiency
Definition Output

Designing the algorithm

Clearly understanding
Specifying the format to be efficient in terms
and defining the
and characteristics of of time and space
computational
the input data and complexity, ensuring
problem that the
the expected output optimal use of
algorithm aims to
of the algorithm. computational
solve.
resources.
2.1 Software Design and Incident Management in Algorithm
Design

Algorithm Design

Correctness Scalability Algorithm Construction

Ensuring that the Considering the

Developing a series of
algorithm produces algorithm's ability to
well-defined steps or
the correct output for handle varying input
procedures that,
all possible inputs and sizes without a
when followed, lead
satisfies the significant increase in
to the solution of the
requirements of the resource
problem.
problem. requirements.
2.1 Software Design and Incident Management in Algorithm
Design

Algorithm Design

Optimisation Iteration and Improvement Analysis

Fine-tuning the
Evaluating the
algorithm for better
Iteratively refining algorithm's performance
performance, often
and improving the characteristics, including
considering different
algorithm based on time and space
approaches, data
analysis, testing, and complexity, to
structures, and
feedback.. understand its efficiency
optimisation
in different scenarios.
techniques.
2.1 Software Design and Incident Management in Algorithm
Design

Incident Management

• Incident management is a systematic process designed to identify, respond to,

and resolve unexpected events or disruptions that can impact the normal
functioning of a system, service, or process.

• It involves a series of steps to minimise the impact of incidents, restore normal

operations swiftly, and prevent future occurrences.
2.1 Software Design and Incident Management in Algorithm
Design

Incident Management

• Key elements include incident identification, logging, categorisation,

prioritisation, investigation, resolution, communication, closure, and post-
incident analysis.

• This process is often employed in various fields, with IT service management

being a common context where incident management is applied.
2.1 Software Design and Incident Management in Algorithm
Design

Incident Management

• Incident management in algorithm design involves identifying, addressing, and

overcoming unexpected concerns or challenges.

• Although "incident management" is usually connected with IT service

management, it can also be used to solve algorithm design issues.
2.1 Software Design and Incident Management in Algorithm
Design

Incident Management

Key elements of incident management include:

• Identification: Recognising issues or disruptions.

• Logging: Recording incident details.
• Categorisation: Classifying incidents.
• Prioritisation: Ranking incidents by impact.
2.1 Software Design and Incident Management in Algorithm
Design

Incident Management

• Investigation: Understanding root causes.

• Resolution: Implementing solutions.
• Communication: Keeping stakeholders informed.
• Closure: Confirming resolution and documenting.
• Review: Analysing incidents for improvements.
• Continuous Improvement: Iteratively refining processes.
2.1 Software Design and Incident Management in Algorithm
Design

Incident Management in the Algorithm Design

• In the context of algorithm design, incident management is the act of

discovering, addressing, and resolving unanticipated issues or challenges that
arise during the algorithm's development.

• While the word "incident management" is most frequently linked with IT

service management, it can be used to address unexpected problems during
algorithm creation.
2.1 Software Design and Incident Management in Algorithm
Design

Incident Management in the Algorithm Design

• In the context of algorithm design, incident management is the act of

discovering, addressing, and resolving unanticipated issues or challenges that
arise during the algorithm's development.

• While the word "incident management" is most frequently linked with IT

service management, it can be used to address unexpected problems during
algorithm creation.
2.1 Software Design and Incident Management in Algorithm
Design

Incident Management in the Algorithm Design

• The following shows how incident management is considered in the algorithm

design:

• Identifying unexpected algorithm development

issues including inaccurate outputs,
Issue Identification inefficiencies, or difficulties.
2.1 Software Design and Incident Management in Algorithm
Design

Incident Management in the Algorithm Design

• Recording details regarding discovered

difficulties, including nature, causes, and initial
Logging and Documenting observations. Incident context is better
understood with documentation.
2.1 Software Design and Incident Management in Algorithm
Design

Incident Management in the Algorithm Design

• Analysing the algorithm's logic, data structures,

and implementation to find the problem. This
Analyse and Diagnose phase entails determining why the algorithm
isn't working.
2.1 Software Design and Incident Management in Algorithm
Design

Incident Management in the Algorithm Design

• Implementing solutions to identified

difficulties. To increase efficiency or
Resolving Issues correctness, the algorithm, logic, or data
structures may be modified.
2.1 Software Design and Incident Management in Algorithm
Design

Incident Management in the Algorithm Design

• Testing the changes to confirm they fix the

issues without creating new ones. Validation is
Testing Validation essential to ensure algorithm performance.
2.1 Software Design and Incident Management in Algorithm
Design

Incident Management in the Algorithm Design

• Informing stakeholders about events,

resolution status, and algorithm adjustments.
Communication Effective communication manages
expectations and promotes teamwork.
2.1 Software Design and Incident Management in Algorithm
Design

Incident Management in the Algorithm Design

• Iteratively updating the algorithm based on

feedback, testing results, and incident
Repeated Improvement resolution lessons.
2.1 Software Design and Incident Management in
Algorithm Design

• In conclusion, effective incident management in the context of algorithm design

is paramount for maintaining system integrity, user trust, and overall
functionality.
Session 3: Test Case Execution

Learning Objectives
After this session, you will be able to:
• Explain the purpose of executing a test case and recording
outcomes in the assigned template.
3.1 Test Case Execution and Recording

Introduction to Test Case

• A test case is a detailed set of conditions or

variables, including the specific steps, inputs, and
expected outcomes, designed to determine
whether a particular aspect of a software
application or system functions correctly.

• It serves as a specific scenario to validate that the

software meets its specified requirements and
performs as intended.
3.1 Test Case Execution and Recording

Introduction to Test Case

• Test cases are an integral part of the software

testing process, providing a systematic approach
to verifying the correctness, reliability, and
performance of software under various
conditions.
3.1 Test Case Execution and Recording

Introduction to Test Case

• Test cases are used to systematically verify that

software meets specified requirements,
functions correctly under various conditions, and
detects defects, contributing to quality
assurance, risk mitigation, and the overall
reliability of the software.
3.1 Test Case Execution and Recording

Purpose of Test Case

• The purpose of a test case is to validate that a specific aspect of a software

application functions correctly, adheres to requirements, and meets quality
standards.

• Test cases are designed to systematically identify defects, verify the accuracy of
the software's behaviour, and contribute to overall quality assurance in the
software development process.
3.1 Test Case Execution and Recording

Purpose of Test Case

• Test cases provide essential functions in software development and testing.

1. Verification of Requirements
• Test cases are created according to software requirements to verify that the
software matches the stated functionalities and features.
3.1 Test Case Execution and Recording

Purpose of Test Case

2. Detecting Defects
• Test cases pinpoint software faults by methodically running several scenarios
and verifying if the results align with the expected outcomes.

3. Validation of Functionality
• Test cases verify the software's proper operation under various conditions,
encompassing a broad spectrum of inputs and usage situations.
3.1 Test Case Execution and Recording

Purpose of Test Case

4. Ensuring Correct Behaviour

• Test cases ensure that the programme functions correctly according to design
standards and user expectations.

5. Ensuring Correct Behaviour

• Test cases are essential for regression testing, which involves retesting
previously recognised defects to verify that fresh modifications or additions to
the product do not bring back old problems.
3.1 Test Case Execution and Recording

Purpose of Test Case

6. Quality Assurance
• Test cases help maintain the overall quality, dependability, and resilience of the
application by methodically testing various software components.

7. Documentation
• Test cases function as a record of the anticipated performance of the software.
They offer a precise and comprehensive account of how the software is
expected to function in different scenarios.
3.1 Test Case Execution and Recording

Purpose of Test Case

8. Promoting Cooperation
• Test cases can be distributed among team members, such as developers,
testers, and stakeholders, to establish a shared comprehension of the
anticipated behaviour and acceptance criteria.

9. Risk Reduction
• Test cases, through thorough testing, aid in identifying and reducing potential
risks related to the software's functionality, performance, and security.
3.1 Test Case Execution and Recording

Purpose of Test Case

10. Improving Maintenance

• Test cases help maintain software by systematically verifying that changes or
updates do not harm current functions.
3.1 Test Case Execution and Recording

• Test cases are essential in the software development life cycle to verify that the
software meets defined criteria, operates appropriately, and sustains its quality
throughout its lifespan.

• They are essential components of software testing procedures and play a key
role in developing dependable and top-notch software solutions.
3.1 Test Case Execution and Recording

Executing a Test Case

• Executing a test case, entails actively carrying out the procedures and activities
indicated in a predefined set of instructions to evaluate the behaviour of a
software programme or system.

• This process entails ensuring that the programme works as expected, capturing
actual results, comparing them to anticipated outcomes, and documenting any
differences or faults.
3.1 Test Case Execution and Recording

Executing a Test Case

• The purpose is to systematically check the software's correctness,

dependability, and quality under specific scenarios, thereby contributing to
overall testing and quality assurance activities across the software development
life cycle.

• To execute a test case, you typically follow these steps:

3.1 Test Case Execution and Recording

Executing a Test Case

Understanding the Test Case: Read and understand the test case
thoroughly, including the objective, steps, inputs, and expected
outcomes.

Prepare Test Environment: Set up the necessary environment,

ensuring that the software, hardware, and other components
are configured as specified in the test case.

Verify Preconditions: Confirm that any preconditions

mentioned in the test case are satisfied before executing the
test.
3.1 Test Case Execution and Recording

Executing a Test Case

Execute Test Steps: Perform the actions outlined in the test case
step by step. This may involve interacting with the user interface,
inputting data, or triggering specific functionalities.

Record Actual Results: Document the actual outcomes or

observations as you execute each step of the test case.

Compare with Expected Results: Compare the recorded actual

results with the expected outcomes mentioned in the test case.
Identify any discrepancies.
3.1 Test Case Execution and Recording

Executing a Test Case

Document Defects: If there are differences between actual and expected

results, document them as defects. Include relevant details like steps to
reproduce, environment information, and severity.

Post-Execution Actions: Update the test case if necessary and

communicate the results to the testing team, developers, or
other stakeholders.

Clean Up: If the test involves changes to the system state,

ensure that the system is reverted to its original state or
cleaned up as needed.
3.1 Test Case Execution and Recording

Executing a Test Case

Repeat for Additional Test Cases: If there are more test cases,
repeat the process for each one, ensuring comprehensive
coverage.

Regression Testing: After executing new test cases,

perform regression testing on previously tested
functionalities to ensure that recent changes did not
introduce new issues.
3.1 Test Case Execution and Recording

• Paying close attention to details, following steps correctly, and keeping detailed
records of results are all important parts of running a test case.

• The purpose is to make sure that the software works the way it's supposed to
and meets certain conditions.
3.1 Test Case Execution and Recording

Test Case Template

• A test case template is a predefined document or format that outlines the

structure for documenting information related to the testing of a specific aspect
or functionality of a software application.

• It includes sections for test case ID, objective, preconditions, test steps,
expected outcomes, actual results, status, comments, defects, and other
relevant information, ensuring consistency and clarity in the testing process.
3.1 Test Case Execution and Recording

Test Case Template

3.1 Test Case Execution and Recording

Test Case Template

• Test case templates can vary based on the specific needs of a project, the
testing methodology employed, and the preferences of the testing team or
organisation.

• The template helps testers and quality assurance professionals maintain a

structured and organised approach to testing, contributing to the overall
effectiveness of the software testing process.
3.1 Test Case Execution and Recording

Test Case Template

• A test case template consists of:

1. Test Case ID
• A unique identifier for the test case.
2. Test Case Title
• A concise and descriptive title or name for the test case.
3.1 Test Case Execution and Recording

Test Case Template

3. Objective
• Clearly state the objective or goal of the test case.
4. Preconditions
• List any prerequisites or conditions that must be met before executing the test.
5. Inputs
• Specify the input data, values, or stimuli required for the test.
3.1 Test Case Execution and Recording

Test Case Template

6. Test Steps
• Outline step-by-step instructions for executing the test, including actions to be
performed and expected outcomes.
7. Actual Results
• Document the actual outcomes or observations during the test execution.
8. Status
• Indicate the overall status of the test case (Pass/Fail/Not Executed).
3.1 Test Case Execution and Recording

Test Case Template

9. Comments
• Include any additional comments, notes, or insights related to the test
execution.
10. Defects
• If applicable, document any defects or issues discovered during the test,
including details and severity.
3.1 Test Case Execution and Recording

Test Case Template

11. Test Environment

• Specify the details of the test environment, including hardware, software, and
configuration.
12. Tested By
• Name or identifier of the person who executed the test.
13. Date
• Date of the test execution.
3.1 Test Case Execution and Recording

Test Case Template

Markdown
1. Test Case ID: TC_001
2. Test Case Title: Login Functionality
3. Objective: To verify that users can log in successfully.
4. Preconditions: User account is created.
5. Inputs: Valid username, valid password.
6. Test Steps:
7. - Enter username and password.
8. - Click the "Login" button.
3.1 Test Case Execution and Recording

Test Case Template

Markdown
9. - Verify successful login.
10. Actual Results:
11. - User successfully logged in.
12. Status: Pass
13. Comments: No issues observed during testing.
14. Defects: None
15. Test Environment: Windows 10, Chrome browser.
16. Tested By: Tester123
17. Date: 2024-02-21
3.1 Test Case Execution and Recording

Test Case Template

• This template structure provides a standardised format for documenting test

cases, making it easier to communicate test details, track execution, and
analyse results.

• Adjustments can be made based on specific project requirements and testing

methodologies.
3.1 Test Case Execution and Recording

Recording Outcomes in a Test Case

• Recording outcomes in a test run is essential for documenting results, verifying

software behaviour, identifying defects, communicating testing status,
supporting decision-making, aiding regression testing, enabling continuous
improvement, maintaining an audit trail, and facilitating knowledge transfer.

• When recording outcomes in a test case template:

1. Execute Steps: Follow test case steps as outlined.

3.1 Test Case Execution and Recording

Recording Outcomes in a Test Case

2. Record Results: Document actual outcomes.

3. Compare with Expectations: Check actual results against expected outcomes.
4. Status Indicators: Use status indicators (Pass/Fail) for each step and overall test
case.
5. Comments: Include comments for insights or deviations.
6. Defects: Document defects if actual results differ from expectations
3.1 Test Case Execution and Recording

Recording Outcomes in a Test Case

7. Update Template: Modify the template if the test case needs updating.
8. Save or Submit: Save results for review by the team.
9. Clean Up: Revert the system to its original state if necessary.
10. Repeat: Repeat the process for additional test cases.

• This ensures systematic documentation, analysis, and communication of test

results in the software testing process.