Lecture 21

1
LECTURE 21
2
MORE ON TESTING
Bottom up testing
• Each component at lower
hierarchy is tested
individually and then the
components that rely upon
these components are
tested.
• Top level components are the
most important, yet tested
last using this strategy.
• In Bottom-up approach, the
Components 2 and 3 are
replaced by drivers while
testing components 4,5,6,7.
They are generally more
complex than stubs.
3
Testing - Top Down Approach
• Top-down integration testing is an
integration testing technique used in
order to simulate the behaviour of
the lower-level modules that are not
yet integrated.
• Stubs are the modules that act as
temporary replacement for a called
module and give the same output
as that of the actual product.
• The replacement for the 'called'
modules is known as 'Stubs' and is
also used when the software needs
to interact with an external system.
4
More on Black Box Testing
• Black-box testing is a method of software testing that
examines the functionality of an application based on the
specifications.
• Also known as Specifications based testing.
• Independent Testing Team usually performs this type of
testing during the software testing life cycle.
• This method of test can be applied to each and every
level of software testing such as unit, integration, system
and acceptance testing.
5
White Box Testing
• White box testing is a testing
technique, that examines the
program structure and derives test
data from the program logic/code.
The other names of glass box
testing are clear box testing, open
box testing, logic driven testing or
path driven testing or structural
testing.
• Advantages of White Box Testing:
• Forces test developer to reason
carefully about implementation.
• Reveals errors in "hidden" code.
• Spots the Dead Code or other issues
with respect to best programming
practices.
• Disadvantages of White Box
Testing:
• Expensive as one has to spend both
time and money to perform white box
testing.
• Every possibility that few lines of code
are missed accidentally.
• In-depth knowledge about the
programming language is necessary
to perform white box testing.
6
What is Scrum?
• Scrum is one of the leading agile software development
processes
• Agile framework for completing complex projects.
• Originally was formalized for software development
projects, but it works well for any complex, innovative
scope of work.
7
Scrum
• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that
•
•
•
•
•
wish list, a sprint backlog, and decides how to implement those pieces.
The team has a certain amount of time — a sprint (usually two to four
weeks) — to complete its work, but it meets each day to assess its
progress (daily Scrum).
Along the way, the ScrumMaster keeps the team focused on its goal.
At the end of the sprint, the work should be potentially shippable: ready
to hand to a customer, put on a store shelf, or show to a stakeholder.
The sprint ends with a sprint review and retrospective.
As the next sprint begins, the team chooses another chunk of the product
backlog and begins working again
• See more at: https://www.scrumalliance.org/why-
scrum#sthash.YMka9Jws.dpuf
8
www.scrumalliance.org/whyscrum#sthash.YMka9Jws.dpuf
9
Role of Scrum Master
• A scrum master is the facilitator for a product development
team that uses scrum, a rugby analogy for a development
methodology that allows a team to self-organize and
make changes quickly.
• The scrum master manages the process for how
information is exchanged.
1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way
10
Responsibilities of Scrum Master
1. Helping the team to reach consensus for what can be
achieved during a specific period of time.
2. Helping the team to reach consensus during the daily
scrum.
3. Helping the team to stay focused and follow the agreedupon rules for daily scrums.
4. Removing obstacles that are impeding the team's
progress.
5. Protecting the team from outside distractions.
11
• http://www.mountaingoatsoftware.com/presentations/an-
introduction-to-scrum
12
Systems development
• Project
• Teamwork
• Planning
• Status
• Outcome
– Product
• Solution
– (system)
– … and its use
• Functionality
• Participants
– Roles
•
•
•
•
Management
Analysts
SMEs
…
• Process
– Methodology
– Phases
• Work products
– Models
13
System Development Methodology
Formal and precise process
• Driving principles and a set of related techniques
• Activities, methods, practices
• E.g. to evaluate the costs and benefits of different solutions
• Organized into a series of phases
• Set of defined deliverables
• A corresponding set of tools
• Serving various participants and their needs
• Project management tools
• Modelling tools
• Development management tools
14
Requirements against a “good” methodology
• Overall philosophy
• Provides guidelines
• Able to lead development on time and on budget
• Within appropriate time limit and acceptable costs
• Corresponding project is “manageable“
• Progress can be can be reviewed at each stage
• Defines outcomes (deliverables, workproducts)
• Documentation - w/ traceability
• Requirements
• Decisions
• Test results (against those requirements)
• Code
• Training schema
15
Typical Systems Development phases
• Initiation (problem formulation and project feasibility)
• Analysis (requirements definition)
• Feasibility analysis (decisions)
• Design (high-level and low-level)
• Construction (development , coding, implementation)
• Verification (testing)
• Implementation (deployment)
• Maintenance (support), improvements
16
Systems Development Life Cycle
• SDLC is a disciplined approach to systems
development
• aimed at facilitating and making more reliable the
development of new information systems
• It consists in breaking down the process in a
number of well-defined stages and sub-stages
• those sub-stages can, in turn, be broken down in
small tasks which take one person a few days to
carry out
17
Cross Life Cycle Activities
• Project Management
Who, when
• Feasibility Analysis - risk management
• Most importantly after the requirements collection stage
• Quality Assurance
• Continuous process
• System usability, verification, validation, user satisfaction
• Documentation and Presentations
• Traceability
• Fact-Finding
• Mainly associated with requirements collection