Software Testing CS448: Dagmawi Lemma

3/1/2022
Software Testing
CS448
Dagmawi Lemma
courses.dag@gmail.com
Dagmawi Lemma ‐ HiLCoE Winter 2022
1
CS448 ‐ Software Testing
Software Testing
CS448
2
1
3/1/2022
2. Testing Fundamentals
Pressman, Roger S Software Engineering: Practitioner’s Approach.
McGraw Hill, New York.
Software Testing
CS448
30
Testing Concepts
• A fault, also called bug or defect, is a design or
coding mistake that may cause abnormal
component behavior.
• An error is a manifestation of a fault during the
execution of the system.
• A failure is a deviation between the specification
of a component and its behavior. A failure is
triggered by one or more errors.
• A correction is a change to a component. The
purpose of a correction is to repair a fault. Note
that a correction can introduce new faults
31
2
3/1/2022
Testing Concepts
• A component is a part of the system that can be
isolated for testing. A component can be an object, a
group of objects, or one or more subsystems.
• A test stub is a partial implementation of components
on which the tested component depends
• A test driver is a partial implementation of a
component that depends on the tested component.
Test stubs and drivers enable components to be
isolated from the rest of the system for testing
32
Testing Concepts
Very simple example
Problem:
• finding volume of cylinder
Solution:
• Product of the height and area of circle (the base)
𝑉𝑜𝑙𝑢𝑚𝑒 ℎ, 𝑟 ℎ 𝐴𝑟𝑒𝑎 𝑟
𝐴𝑟𝑒𝑎 𝑟 𝜋 𝑆𝑞𝑢𝑎𝑟𝑒 𝑟
𝑆𝑞𝑢𝑎𝑟𝑒 𝑟 𝑟 𝑟
If A(r) is completed and selected for testing, then
• Either we have to wait until both V(h,r) and S(r) are completed since
A(r) has no use by itself, or
• V(h,r) and S(r) shall be defined as drive and stub respectively
33
3
3/1/2022
Testing Concepts
Very simple example (continued)
double volume(double h, double r) double square(double r)
{ {
return h x area(r); return r x r;
} }
double area(double r)
{
//this function returns area of a circle with radius r
const double PI = 3.14; //this constant can be global as well
double result = 0; //variable for storing the result
double sq= 0; //variable for storing square of a number
. sq = square (r); //calculating square of a number
result = PI x sq; // calculating area
return result;
}
34
Testing Concepts
• At the analysis stage the focus is on the problem
domain while at the design stage the focus is on the
solution domain
– To provide the solution the system is decomposed into
subsystems and
• each subsystem is defined by the service it provides – hence
cohesively defined;
• the subsystems are coupled;
– Yet from testing perspective,
• Either we have to wait for testing until all the subsystems are
completely implemented – which is not desired
• Or we have to isolate the subsystem, which is completely
implemented, for testing
– However, since the one being isolated is coupled with other subsystems,
then those shall be defined as stab and drive
35
4
3/1/2022
Testing Concepts
Test
Test Drive Test Stub
Component
import Shops.PizzaHouse;
Drive
class Order{
/* this class is one of the classes in the Shops package and it may not be
complete but can be defined partially to invoke a component under test*/
PizzaHouse myFavorite = new PizzaHouse;
Depends on
myFvorite. showshippingprice(myAddress);
//...
}
import ServiceProvders.Courier
class PizzaHouse{
//... Test
Public static void showshippingprice(Location address){ Comp
/*suppose this is the method to be tested, then it
must be completely implemented*/
}
//... Dagmawi Lemma ‐ HiLCoE Winter 2022
36
} CS448 ‐ Software Testing
Testing Concepts
Test
Test Drive Test Stub
Component
import ServiceProvders.Courier
class PizzaHouse{
//...
Public static void showshippingprice(Location address){
/*while completely implemented, still may depend on others*/
Test
} Courier dispatchArranged = new Courier; Comp
//...
priceList=dispatchArranged.getPrice(address);
//... Depends on
}
class Courier{
/* this class is one of the classes in the ServiceProvider package and it
may not be complete but can be defined partially to provide price List*/
priceList getPrice(Location address){
//...; Stub
}
//... CS448 ‐ Software Testing
37
}
5
3/1/2022
Testing Concepts
• Test Case
– It is a set of inputs and expected results that
exercises a component with the purpose of
causing failures and detecting faults
– Selection of test case is dictated by the objective
of the test plan
• For example
– Are we having structural or functional testing
– If we have structural testing, then which coverage metrics is
our focus?
38
Testing Concepts
• Test Case (Continued)
– Scenarios (evaluation scenarios) are primary sources
for test cases
– Also each test case may appear with various scenario
– When a component is tested using test drive, the test
case is used at the test drive
• That is the input is feed through the drive
• The actual result is received at the drive
– And the one who is comparing the actual (measured)
result with the expected result is known as oracle
39
6
3/1/2022
Testing Concepts
• Test Case Life Cycle
– Main idea: test cases as products. Therefore test
cases have a life cycle.
Deleted Deprecated
Create Draft Review Released
Update
40
Testing Concepts
• Test Case Life Cycle (Continued)
– Create: The create phase enters the following information:
• Test case ID
• Requirements IDs
• Title
• Originator group
• Creator
• Test category
– Draft: A test engineer enters the following information:
• Author of a test case
• Test objective
• Environment
• Test steps
• Clean up
• Pass/Fail criteria
• Candidate for automation
• Automation priority
41
7
3/1/2022
Testing Concepts
– Review: Here, the creator is the owner
• The owner invites test engineers and developers to review the test
case
• Ensure that the test case is executable and Pass/Fail criteria are
clearly stated
• Changes may occur
• Once the test case is approved, it is moved to “Released” state.
– Released
• The test case is ready for execution
• Here, the owner is the test organization
• Review the test case for re‐usability
• If there is a need to update the test case, move it to “update”
state.
42
Testing Concepts
– Update
• Strengthen the test case as the system functionality or environment changes
• By executing the test case 2/3 times, one may update the test case to improve
reliability
• One gets an idea about its automation potential
• A major update calls for a review of the test case.
– Deleted: If the test case is not a valid one.
– Deprecated: If a test case is obsolete, move it to this state. A test case
becomes obsolete for several reasons:
• System functionality has changed, but test cases have not been properly
maintained
• Test cases have not been designed with re‐usability in mind
• Test cases have been carried forward due to carelessness; long after their original
justification has disappeared.
43
8
3/1/2022
Testing Concepts
• Testing Phases
– Setup
• Making the test component or SUT ready for testing by facilitating the
prerequisites
• For example,
– to test a login, then the user account must be there first
– to test the component that updates a certain record in the database, the record must
exists first
– Etc.
– Invocation
• Running the test
– Assessment
• Finding/measuring the difference between the expected and observed
behavior
• Done by oracle
– Teardown
• The reverse process of the setup
• For example, if a user account has been created for testing the login, then at
the end of the test that user account has to be removed
44
Creating Test Case: Example
• Test Scenario
– Generic and broad
• E.g. Login Scenario
– the login screen is having option to enter username and
password with submit button and option of forgot password –
– user is able to login with valid username and password ‐ See
more at
– Verify that user is not able to login with invalid username and
password
– validation message gets displayed in case user leaves username
or password field as
– Covers wide range of possibilities
– Derived from the requirement early when defining
requirements of the system
45
9
3/1/2022
(continued)
• Test Case
– Specific
– Each test scenario could result in many test case
Entering Valid
Username and
Password
Login Entering invalid
Username and
Scenario Password
Entering nothing
…
46
(continued)
• Test Data
– Identifying test data is time consuming
– What can we do …
• Have objective and know why you want to test
• What feature/functionality you want to test
Test Scenario Test Case Test Data
Login to an Entering valid Username: Dagmawi
online library username and Password: myPassword
system password
Username: Dagmawi
Password: MyPassword
47
10
3/1/2022
(continued)
• Expected result
– If not documented we cannot tell if the test pass or
fail
– For example a function
double calculateIncomeTax(double salary);
//This could give you some result but how can you tell it is the correct one
Test Scenario Test Case Test Data Expected result
Login to an Entering Username: Dagmawi Login must be

online library valid Password: successful
system username myPassword
and
. password
48
(continued)
• Test Steps
– There might be complex steps to be followed in
order to do some task, or there might be strict
sequence of steps to be followed, or …
Test Test Case Test Steps Test Data Expected
Scenario result
Login to Entering 1. Launch Username: Login must be
an online valid application Dagmawi successful
library username 2. Enter username
system and 3. Enter password Password:
password 4. Click the login myPassword
button
.
49
11
3/1/2022
(continued)
• Preconditions
– There are things to be fulfilled before running test
• E.g. Should be connected to the Internet, server must
be up and running, devices are available, etc.
Test Test Case Preconditions Test Steps Test Data Expected
Scenario result
Login to Entering • Library system 1. Launch Username: Login must
an online valid should be application Dagmawi be successful
library username installed 2. Enter
system and • Test computer username Password:
password must be 3. Enter myPasswor
connected to password d
the network 4. Click the login
button
50
(continued)
• Postcondition
– Depending on the requirement, you might have
postcondition, which is what to be fulfilled after the
test is done apart the expected result
– E.g. log file update or entry
Test Test Conditions Test Steps Test Data Expected
Scenario Case Pre Post result
Login to an Entering • Library system Login 1. Launch Username: Login must
online valid should be date and application Dagmawi be successful
library username installed time shall 2. Enter
system and • Test be username Password:
password computer must recorded 3. Enter myPassword
be connected in the log password
. to the network file 4. Click the
login button
51
12
3/1/2022
(continued)
• During test case execution the result must be documented
– Provide a space where the actual result would be required
– Provide a space for indicating whether the test passed or failed
Test Test Conditions Test Steps Test Data Expected

Scenario Case Pre Post result
Login to an Entering • Library system Login 1. Launch Username: Login must
online valid should be date and application Dagmawi be successful
library username installed time shall 2. Enter
system and • Test be username Password:
password computer must recorded 3. Enter myPassword
be connected in the log password
. to the network file 4. Click the
login button
Actual Result Pass Fail

[ ] [ ]
52
Principles
• Testing is a process of executing a program with the intent
of finding an error, hence we need to have a good test case
– A good test case is one that has a high probability of finding an
error (but the error must be new or undiscovered yet)
• A test is said to be successful if it can uncovers an as‐yet‐
undiscovered error
• Before applying methods to design effective test cases, a
software engineer must understand the basic principles
that guide software testing
53
13
3/1/2022
Principles
• All tests should be traceable to customer
requirements
– If a software fails to meet the customer’s
requirements, then it is then the most severe defects
• Testing should be planned as early as possible
– Test planning can begin as soon as the requirements
model is complete (recall the V‐model)
– Detailed definition of test cases can begin as soon as
the design model is solidified
54
Principles
• Traceability
– The Pareto principle (80% of the effects come
from 20% of the causes)
Components with 80% of errors uncovered during testing
20%
80%
55
14
3/1/2022
Principles
• Testing should begin “in the small” and progress
toward testing “in the large.”
– The first tests planned and executed generally focus
on individual components,
• This also minimize the effort required for creating test stub
and test drives
– As testing progresses, focus shifts in an attempt to
find errors in integrated clusters of components and
ultimately in the entire system
–.
Unit Testing Integration Testing System Testing Acceptance Testing
56
Principles
• Exhaustive testing is not possible
– There is no as such “complete testing”
– The number of path permutations for even a moderately
sized program is exceptionally large
– it is impossible
• to execute every combination of paths during testing
– It is possible,
• to adequately cover program logic and to ensure that all
conditions in the component‐level design have been exercised
57
15
3/1/2022
Principles
• Conducting testing by independent third party
– To be most effective, testing should be conducted by an independent third
party
– the software engineer who created the system is not the best person to
conduct all tests for the software
• Developer: understands the system; but will test "gently“ and, is driven
by "delivery“
• Independent Tester: must learn about the system; but will attempt to
break it and, is driven by quality
• .
developer independent tester
58
Testability
• “Testability” occurs as a result of good design. Data
design, architecture, interfaces, and component‐level
detail can either facilitate testing or make it difficult
• Software testability is simply how easily it can be
tested
• Characteristics that lead to testable software
– Operability, Observability, Controllability,
Decomposability, Simplicity, Stability, Understandability
59
16
3/1/2022
Testability
• Operability
– How can we test a program that does not work
anyway?
• The better it works, the more efficiently it can be tested
• Observability
– We must be able to see how the system works
• Distinctness of output for each input
• States of the system
• Errors
• Source code inspection (programmers have eagle‐eye)
60
Testability
• Controllability
– Control over the software  test automation and
optimization
– The better we can control the software, the more the
testing can be automated and optimized
• All possible outputs can be generated through some combination
of input.
• All code is executable through some combination of input.
• Software and hardware states and variables can be controlled
directly by the test engineer.
• Conservative Input and output formats are consistent and
structured.
• Tests can be conveniently specified, automated, and reproduced
61
17
3/1/2022
Testability
• Decomposability
– By controlling the scope of testing, we can more
quickly isolate problems and perform smarter
retesting
• Test Stub, Test Drive, Test Components
– The software system is built from independent
modules
– Software modules can be tested independently
62
Testability
• Simplicity
– The less there is to test, the more quickly we can test
it;
• We can efficiently and effectively observe the behavior of
small components than larger ones
– Functional simplicity (e.g., the feature set is the
minimum necessary to meet requirements)
– Structural simplicity (e.g., architecture is modularized
to limit the propagation of faults)
– Code simplicity (e.g., a coding standard is adopted for
ease of inspection and maintenance)
63
18
3/1/2022
Testability
• Stability
– The fewer the changes, the fewer the disruptions
to testing
• Changes to the software are infrequent.
• Changes to the software are controlled.
• Changes to the software do not invalidate existing tests.
• The software recovers well from failures
64
Testability
• Understandability
– The more (clear) information we have, the smarter we
will test
• Clarity of the requirements helps
• The design is well understood
• Dependencies between internal, external, and shared
components are well understood
• Changes to the design are communicated
• Technical documentation is instantly accessible
• Technical documentation is well organized
• Technical documentation is specific and detailed
• Technical documentation is accurate
65
19
3/1/2022
Testability concerns
• Testability touches upon two areas of concern:
– How easy is it to test the implementation?
– How test‐friendly is the requirement?
• These two concerns are not independent and
need to be considered together. Shall be
studied from requirements side.
66
Testability
• Three basic ways to measure the quality of the
software:
– Executing a test (dynamic test):
• Give input to the test component (perhaps through the test drive),
• Observe and compare the output with the expected result in the test
case
• And the test can be black box or white box
– Run experiments (such as system testing and usability
testing)
– Inspect the code and other artifacts (static testing)
• Usually, we will include all of these activities
in the term testing
67
20
3/1/2022
Testability challenges
• The requirements definition might improve
the testability or not
– Problems might rise due to:
• Volume of tests needed, e.g. response time or
storage capacity.
• Type of event to be tested, e.g. error handling or
safety mechanisms.
• The required state of the system before testing,
e.g. a rare failure state or a certain transaction
history.
68
Testable Requirements
• What do you mean by <requirement>?
This will give us either
a) a testable requirement or
b) a set of testable and non-testable sub-
requirements.
– In case (a) we are finished
– In case (b) we shall refine each non-testable
sub-requirement
69
21
3/1/2022
Testable Requirements (continued)
• First and foremost:

– The customer needs to know what s/he wants
and why s/he wants it
• In some cases it is easier to test if the user actually
has achieved her/his goal than to test that the
system implements the requirement.
– Unfortunately, the “why”-part is usually not
stated as part of a requirement
• Clarifying the business requirements might help
though
70
Testable Requirements (continued)

• The quality of the requirements determine its testability
• To improve the quality or requirements. each requirement

needs to be
– Correct, i.e. without errors
– Complete, i.e. has all possible situations been covered?
– Consistent, i.e. not in disagreement with other requirements
– Clear, i.e. stated in a way that is easy to read and understand –
e.g. using a commonly known notation
– Relevant, i.e. pertinent to the system’s purpose and at the right
level of restrictiveness
– Feasible, i.e. possible to realize. If it is difficult to implement, is
might also be difficult to test
– Traceable, i.e. it must be possible to relate it to one or more
• Software components
• Process steps
71
22
3/1/2022
Correctness
Both the functional and technical description
shall be correctly defined
For example: adding (or missing) a boundary

class that is different from (or unlike) the
business rule
Book
What is wrong with this requirement?
‐Technical or Functional?
create ()
.
Cataloger
72
Completeness
All possible situations must be covered.
“If X then….”, “If Y then….” Must also consider
what will happen “If neither X nor Y…”
Automatic door opener – what is missing?

If the door is closed and a person is detected then
send signal Open_Door.
If no person is detected after 10 sec., send signal
Close_Door.
what if the door is closed? How should we express it?
73
23
3/1/2022
Consistency
Consistency is a challenge since we, at least in
the general case, need a complete overview
of all requirements.
In most cases, we can make it by checking all

requirements that are related to the same
event, function or parameter.
Also, if we don’t follow users’ vocabulary we

could end up with inconsistently defined
requirements
74
Clear
This is mainly a question of representation such as choice of
– Diagram notation
– Description language
– Level of details
Who shall understand the requirement?
– Customers
– Developers, including hired-in consultants
– Testers
Simple example:
‘The user shall be able to print the “accounts ledger” for all accounts’
This requirement is perfectly clear for developers who are working in

the banking business.
Other developers might experience some problems.

– hence the term “accounts ledger” shall be clearly defined earlier
specifying this requirement
75
24
3/1/2022
Relevant
Two questions are important:
– Do we really need this requirement? (validate)
– Is it at the right level of strictness? i.e. not too
strict and not too lax. (verify)
76
Feasible
This question is really related to the contract but
we should also consider it here – can we really
do it?
Testers can contribute to the feasibility question by
asking how it should be tested. This will help /
force everybody involved to make the
requirement more clear and thus improve on the
requirement.
Requirements that are difficult to tests are also
usually difficult to implement – mainly because
they are badly defined.
77
25
3/1/2022
Some sound advice
The following set of advices on requirements and
testability are quoted from Ludwig Consulting
Services, LLC.
They are not a definition and not “the final words”
on requirements testability. Instead, they should
be used as a checklist.
That one of the following rules are not obeyed does
not mean that the requirement is wrong. It
should, however, be reviewed for potential
problems.
78
Modifying Phrases
Words and phrases that include:
• as appropriate
• if practical
• as required
• to the extent necessary / practical.
Their meaning
• is subject to interpretation
• make the requirement optional
Phrases like "at a minimum" only ensure the minimum,
while "shall be considered" only requires the
contractor to think about it.
79
26
3/1/2022
Vague Words
Vague words inject confusion. Examples of frequently
used vague verbs are:
• manage
• track
• handle
• flag
Information systems receive, store, calculate, report, and
transmit data. Use words that express what the system
must do.
Requirement: The system shall process ABC data to the
extent necessary to store it in an appropriate form for
future access.
Correction: The system shall edit ABC data.
80
Pronouns With No Reference
Example: It shall be displayed.
When this occurs, the writer is usually relying on
a nearby requirement in the requirements
document for the meaning of "it."
As requirements are assigned for
implementation, they are often reordered and
regrouped, and the defining requirement is no
longer nearby.
81
27
3/1/2022
Passive Voice
Requirements should be written in active voice,
which clearly shows X does or provides Y.
Passive voice: Z shall be calculated.
Active voice: the system shall calculate Z.
82
Negative Requirements
Everything outside the system is what the system
does not do.
Testing would have to continue forever to prove
that the system does not do something.
State what the system does. Substitute an active
verb that expresses what the system must do.
• Change "the system shall not allow X," to "the
system shall prevent Y."
• Use the prefix "un," such as: The system shall
reject unauthorized users.
83
28
3/1/2022
Assumptions and Comparisons
The requirement "the system shall increase
throughput by 15%" sounds testable, but isn't.
The assumption is "over current system
throughput." By comparing to another system,
the meaning of the requirement changes
when the other system changes
84
Assumptions and Comparisons (continued)
An example, sometimes found in requests for
proposals, is:
"The system shall address the future needs of
users."
The writer is probably thinking ahead to after the
contract is awarded. The requirement is
meaningless because whenever it is read, it will
point to the future.
A requirement on change management included in
the project management processes, would make
more sense than making it a requirement for the
system.
85
29
3/1/2022
Indefinite Pronouns
Indefinite pronouns are “stand in” for unnamed people or things,
which makes their meaning subject to interpretation.
Some of these may find their way into requirements:
• All • Everybody
• Another • Everyone
• Any • Everything
• Anybody • Few
• Anything • Many
• Each • Most
• Either • Much
• Every
86
The SDLC (Revisit)
• In engineering, a process is a series of interrelated tasks, which are
needed to develop/construct a certain product.
• These series of tasks, together, transform inputs into a given output
leading to the final output (i.e., the product) or the tasks may
meant to maintain and fix problems in the product.
Problem Requirement
Requirement
Problem Description
Analysis
Elicitation
Testing Testing Testing

Product
• . Implementation
System Design
Specification
Design and Problem
Specification
Architecture (Analysis
Model)
87
30
3/1/2022
The Water Fall
“Way back when”
• Royce, W. W. (1970, August). Managing the
development of large software systems.
In proceedings of IEEE WESCON (Vol. 26, No. 8).
– essential steps common to all computer program
development
• Analysis and Coding
• System requirement, software requirement, analysis, design,
coding, testing, operation
• Iterative relationship between successive phases
88
Types of Process Model
• Three generic process models (Sommerville
2007)
– The waterfall model
– Evolutionary development
– Component‐based SE
• Or a process model can be linear, incremental,
agile
89
31
3/1/2022
• In principle, the result of each phase in any of the
process model is one ore more documents that
are approved.
– In practice there is no clear cut rather the phases
overlap
– The cost of producing and approving documents as
well as the number of iterations are expensive
• Freezing parts of the development 
• Problems are left for later resolutions
• Ignore the problem
• Solve the problem by programming around (without
documentation)
90
• Waterfall model
– Logically ordered as in SDLC
– It is however practical if the requirements are well
understood and unlikely to change radically during the
process
• But what about the documentation?
– Documentation is often rigorous and bulky
• Other approaches also seems to practice the waterfall
but by considering small portion of the entire system
– Hah! The water fall seems to appear as sub model
– No! the SDLC is reflected rather
91
32
3/1/2022
92
93
33
3/1/2022
• If we still have the sequence of the activities in
RAD, Incremental, Spiral, etc. as in the waterfall,
why do we consider them as different process
model?
– REMARK:
• Process descriptions is more than the sequence of activities:
it may also include principles to be followed and description
about:
– Products
– Roles
– Pre‐ and post‐conditions,
– tools and techniques etc.
94
The Paradigm shift
• Some of the reason why software project fails
– Poorly documented client requirements
• When do we say it is poorly documented?
– Impractical schedule
– Change management problems
– Testing issues
– Overly rigid processes
95
34
3/1/2022
Agile methods
• The overhead cost of software development
could be extensive
– The cost can be in planning, documenting, managing,
etc.
– For small and medium‐sized business systems, the
overhead involved could be large enough and
sometimes dominates the process.
• More time could be spent working on how the system
should be developed rather than on the program
development and testing
– The overhead can be easily justified for heavyweight
systems but not for small and medium‐sized systems
96
Agile methods
• The agile manifesto
http://agilemanifesto.org/iso/en/
97
35
3/1/2022
Agile methods
• Agile manifesto
– Collaboration
– Communication
– Focus on people instead of on the process
– Delivering a working software is a measure of
success
• We need the outcome not how we did the outcome
98
Agile methods
• Long milestones  short ones (sprint)
• Extensive documentation  less
documentation
• Process overhead  product delivery
• Evolved as SD Process and management tool
99
36
3/1/2022
Agile methods
• Principles behind the Agile Manifesto
1. satisfy the customer through early and continuous delivery of valuable
software
2. At anytime in the development process welcome changing requirements
3. Deliver working software frequently, from a couple of weeks to a couple of
months
4. Work together daily throughout the project.
5. Motivate team members
6. Face‐to‐face conversation
7. Measure of progress by the working software
8. Maintain a constant pace between stakeholders
9. Continuous attention to technical excellence and good design enhances
agility.
10. Simplicity‐‐the art of maximizing the amount of work not done‐‐is essential.
11. The best architectures, requirements, and designs emerge from self‐
organizing teams.
12. Reflects on how to become more effective
100
Agile methods
101
37
3/1/2022
Agile methods
• Best practice
– Design a clear, concise user story
– Employ business value prioritization
– Reflect on the project
• To Success
– Define Agile principles best suited for the project
(organization)
– Establish and define a glossary of terms
– Over communicate
102
Agile methods
• The case of SCRUM
– a set of practices used in agile project management that
emphasize daily communication and the flexible reassessment
of plans that are carried out in short, iterative phases of work
– .
103
38
3/1/2022
Scrum
104
Scrum
• Scrum structures product development in
cycles of work called Sprints,
• Sprints are typically 1‐4 weeks in length and
the duration is fixed (if completed or not)
• Scrum emphasizes producing working product
at the end of the Sprint is really “done”; in the
case of software, this means code that is fully
tested and potentially shippable.
105
39
3/1/2022
Scrum
• Requirements
– User story:
• concise, clear descriptions of the functionality in terms
of its value to the end user of the product
“As a (role), I want (feature), so that (benefit).”
– Product backlog (wish list)
• Collection of user stories
• Exists (and evolves) over the lifetime of the project
• Continuously updated by the Product Owner to reflect
changes
106
Scrum
• Primary Roles
– Product owner
– Scrum Master
– Team
107
40
3/1/2022
Scrum
• The process
– Have product backlog
– Prioritized list of what’s required.
• Product Owner is required to make prioritization
decisions (by product owner)
– Sprint planning
• Product Backlog can vary significantly in size; however,
the larger ones will often be broken into smaller pieces
108
Scrum
• The process
– Have product backlog
– Prioritized list of what’s required.
• Product Owner is required to make prioritization decisions
(by product owner)
– Sprint planning
• Facilitated by the Scrum Master
• Product Backlog can vary significantly in size; however, the
larger ones will often be broken into smaller pieces
• Team select items form the product backlog and commit to
complete by the end of the sprint
109
41
3/1/2022
Scrum
• The process (continued)
– Daily scrum meeting
• a short (15 minutes or less) stand‐up meeting that happens
every work day
• team’s opportunity to report to itself on progress and
obstacles
• One by one, each member of the team reports three (and
only three) things to the other members of the team
• No discussion but only reporting. The Scrum Master take
notes and makes sure solutions are delivered
– Sprint Burndown Chart
110
Scrum
111
42
3/1/2022
Scrum
– Sprint review
• the team demos what they’ve built during the Sprint (not
presentation)
– Sprint Retrospective
– Starting the Next Sprint
• Following the Sprint Review Meeting, the Product Owner
takes all the input, as well as all new priorities that have
appeared during the Sprint, and incorporates them into the
Product Backlog; new items are added, and existing ones are
modified, reordered, or deleted. Once this updating of the
Product Backlog is complete, the cycle is ready to begin all
over again, with the next Sprint Planning Meeting.
112
Scrum
– Release Planning
• Sprints continue until the Product Owner decides the
product is almost ready for release
113
43
3/1/2022
Scrum
– Release Planning
• Sprints continue until the Product Owner decides the
product is almost ready for release
114
From Agile to DevOps
Development
Operations
115
44
3/1/2022
From Agile to DevOps
SDLC Agile
• In earlier process models, requirements were
expected to be captured initially in its
Plan complete form from the client/users
– Later it was noted that requirements will change
along the process and the notion of stakeholder
include many participants in addition to those who
owns the system (the client) or the end‐users
• Agile, gives more value to meeting
Code requirements than contract negotiation –
hence changes are welcome
– As the results it is common to constantly adjust
requirements
– changes come not only from the business and
Test stakeholders, but also based on the feedback
collected from the development team
– The development team basically starts reflecting
beyond technical aspect as they learn more about
Review the system they are developing
• Agile Phases are plan, code, test and review
116
What is DevOps?
• DevOps is a Philosophy and Practice
– focused on agility
• So it focuses on collaboration between the client and
development team
– It also focuses on collaboration between the
development team and the operation team
– Practice automation within IT and development
team processes
• Each phase involves tools
117
45
3/1/2022
Phases in DevOps
SDLC DevOps
• In DevOps, requirements are not only
shaped by the client and stakeholders
Plan
and the development team, but also
by feedbacks coming from operations
and monitoring stage.
Code – This means the initial requirements
affect the development, and the
development will affect the
Build operations (how things used to be
done), and the operations will give
Test feedback affecting the requirements.
Release
Deploy
Operation
Monitor
118
Phases in DevOps
• Plan
– At this stage the client and the development team defines the
requirements
– Features of the system to‐be is listed
– User stories (wishlist) is created and recorded
– Product backlog is created
• Code
– Design will be conducted and codes for the designed units are created
• Build
– Units are integrated and are built as one package
• Test
– Testing will be conducted (end‐to‐end) test will be done and units are
tested with black box strategy
119
46
3/1/2022
Phases in DevOps
• Release
– The version of the build and new features will be recorded and
confirmation is given to deploy the build
• Deploy
– The software is packaged after release and deployed to the production
server
• i.e., the software is transferred from the developers’ machine to the client’s
platform
• Operate
– Operation Team does the required configuration at the respective
platform (server) and facilitates the platform (e.g., network)
• Monitor
– Issues will be recorded and assessed for the possible impact on the
end‐user
120
47

Software Testing CS448: Dagmawi Lemma

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Testing CS448: Dagmawi Lemma

Uploaded by

Copyright:

Available Formats

3/1/2022

Create Draft Review Released

Test Scenario Test Case Test Data Expected result

Login to an Entering Username: Dagmawi Login must be

Test Test Conditions Test Steps Test Data Expected

Actual Result Pass Fail

Testable Requirements (continued)

• First and foremost:

Testable Requirements (continued)

• To improve the quality or requirements. each requirement

For example: adding (or missing) a boundary

Automatic door opener – what is missing?

In most cases, we can make it by checking all

Also, if we don’t follow users’ vocabulary we

This requirement is perfectly clear for developers who are working in

Other developers might experience some problems.

Testing Testing Testing

You might also like