Sie sind auf Seite 1von 32

Software Testing

Software development life-cycle


Overview

• SDLC Phases (Requirements, Design, Implementation, Testing,


Release & Maintenance)
• SDLC Methods (Waterfall, V-Model, Agile Scrum and more)

2
Introduction
• Software Development Life Cycle (SDLC)
– From an idea of a desired software
– To release of the actual software and its
maintenance
• Efectiveness of a company depends on
– How efective SDLC stages are
– How efectively stages interact with each other
• SDLC Models
– Waterfall, V-Model, Agile methods
– Each one has its strengths and weaknesses
– Mixture of them is also an option

3
Requirement analyses

• Everything starts from an idea


• “It would be good to have these functionalities on our Web Site”
• Ideas come from
– Marketing or product management
– Users or customers - Anyone in the company, there is no such thing as a dumb idea
– Competitors
• Ideas (if accepted) are formalized as Requirements
“These are the functionalities that we are going to implement
on our Web Site”

4
Design
Types of Software Specifcation:
- BRD (Business Requirements Document) - high level document, providing list of requirements
which are demanded by the client and should be part of the proposed system.
- SRS (System Requirements Specifcction) - describes entire system fows; contains both
functional (often in the form of use cases) and non-functional requirements
- FRS (Functioncl Requirements Specifcction) - includes detailed information on how
requirements are going to be implemented in the system

Examples for design documentation:


- HLD (High Level Design Document)
- TDD (Technical Design Document)
- DDD (Detailed Design Document)

Documentation formats, types and terminology may vary, depending on each company’s
workfow and processes.

5
Design

• Once Specifcation is approved it should not be changed lightly*


• Changes in specifcation do happen
- Can lead to bugs
- Changes should be negotiated/communicated with the entire team
• The sooner QA is involved in Design, the better
• Testing can begin as soon as requirements are ready, i.e. specifcation
documents undergo some form of review

6
Implementation
• Realization of the
• Architecture & design documents
• Version control (Git, Mercurial, SVN)
• Development environments
• Code review
• Coding standards
• Unit tests

7
Testing
• Testing the software starts as soon as there is stable build including required functionalities
• Testing broken or unfnished code can be a waste of time
• Before starting detailed tests, QA ensures
- Code is ready (i.e. features are implemented)
- Correct software build is deployed on a testing environment
- Build is not broken (by performing a smoke test)
• Bugs are fxed, then re-tested
• Regression test is done to ensure new code changes are not ‘breaking’ old functionality
• Some form of Acceptance test might be done by end users/customers

8
Release

• Whole/part of the product is given to the users


• Package of known fles having concrete version (for example: v2.0.1)
• Release can have new features and bug fxes
• Huge release can have downtime
• Bugs can be found on Production environment after release
• Rollbacks and Patches/Hot-fxes

9
Maintenance

• Crucial to be able to work on several versions


• Bug fxing can occur in several locations
• v1.0 is released, v2.0 is under development, v3.0 is being designed
• Create Test Case for each bug found in production
• Testing strategy should take into careful consideration supported versions

10
SDLC Methods

Waterfall Agile
- Scrum
- Kanban
- XP
- Lean
V-model - more...

11
Waterfall

• A stage starts after previous one is completed


• Requires big initial analysis and planning
• Simple to understand
• Time overrun
• Cost overrun
• Not adaptable to real needs

12
Verifcation vs Validation

Verifcction
The evaluation of whether or not a product, service, or system
complies with a regulation, requirement, specifcation, or imposed
condition. It is often an internal process.

Vclidction
The assurance that a product, service, or system meets the needs of
the customer and other identifed stakeholders. It often involves
acceptance and suitability with external customers.

13
V-MODEL

14
Agile

THE AGILE MANIFESTO

• Individuals and interactions over processes


and tools
• Working software over comprehensive
documentation
• Customer collaboration over contract
negotiation
• Responding to change over following a plan

15
Agile

16
Scrum terms

• Roles
– Product owner (PO)
– Scrum master (SM)
– Development team
• Ceremonies
– Sprint planning
– Sprint review/demo
– Sprint retrospective
– Daily scrum meeting
• Artifacts
– Product backlog
– Sprint backlog
– Burn-down charts

17
Product owner

• Defnes the features of the product


• Decides on release date and content
• Responsible for the proftability of the product (ROI)
• Prioritizes features according to market value
• Adjusts features and priority every iteration
• Accepts or rejects work results

18
Scrum master

• Represents management to the project


• Responsible for enacting Scrum values and practices
• Removes impediments
• Ensures the team is fully functional and productive
• Enables close cooperation across all roles and functions

19
Dev Team
• Tecm
– Pigs
– Self organised
– 5-9 full time members
– Cross functional (Front-end,
Backend, QA, DevOps)

• Ancillcry
– Chicken
– Stakeholder/Managers
– Try to interfere and get things
done

20
Roles and responsibilities

Product owner
– What
– When
– Sign of
– Vision
Scrum master
– Removes noise
– Removes impediment
– Facilitates scrum
– Agent of change
Team
– How
– How long
– Code
– Test

21
Product Backlog

• The list of functionality, technology and issues


• Managed and prioritized by Product owner
• Issues are frst placeholders, later turned into work
• One list for multiple teams on product
• Anyone can add items
• Keep visible

22
User Story

• Created by Business Analyst


• Major building block of Product backlog
• Unit of scope – Who, What, Why
• Describes customer view of value
• High level acceptance criteria
• Story difers from Use case
- Story tells only What but not How. The Use case is more detailed.

Excmple of User Story:


As a user, I want to search for my customers by their frst and last names.

23
Sprint Planning

• Team picks items from product backlog that they can commit to complete
• Sprint backlog is created
- List of tasks necessary to achieve the work
- Task are identifed and each item is estimated
- Scrum master does NOT decide for the team
• Team self-organizes to meet the goal
- Tasks are NOT assigned by manager
• High-level design is considered

24
Sprint Backlog

• List of tasks the team needs to address during the sprint


• Tasks are estimated by the team
• Team members sign up for tasks, they are not assigned
• Estimated work remaining is updated daily
• Only team can change it

25
Daily Stand-up

• Happens everyday at a fxed time


• 15 minutes long stand up meeting
• 3 questions are answered by every team member
- What did I do yesterday?
- What do I plan to do today?
-Do I have some blocker?
• Only one team member can speak at a time
• Specifc issues are resolved ofine

26
Sprint Demo

• Team presents what is done during the sprint


• Typically takes the form of a demo of new features or underlying architecture
• Informal
- 2-hour prep time rule maximum
- No slides
• Whole team participates
• Product owner(s) signs of stories

27
Sprint Retrospective

• Review at what is and is not working for the team


• Issues must be acted upon
• Typically an hour or so
• Done after every sprint
• Whole team participates
- Scrum Master
- Product owner
- Team

28
Agile Essentials

• Agile is about people


• Test-driven development (TDD)
• Automation
• Continuous Integration

29
Continuous Integration & Continuous Delivery
30
Agile Reading

• “Agile Testing” by Lisa Crispin, Janet Gregory


• “Continuous Delivery: Reliable Software Releases through Build,
Test, and Deployment Automation” by Jez Humple, David Farley

31
QUESTIONS?

32

Das könnte Ihnen auch gefallen