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)

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

Introduction • • • Software Development Life Cycle (SDLC) – – From an idea of a

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”

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.

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

Implementation

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

Implementation • • • • • • • Realization of the Architecture & design documents Version

7

Testing

Testing the software starts as soon as there is stable build including required functionalities

  • - Code is ready (i.e. features are implemented)

Testing broken or unfnished code can be a waste of time

Before starting detailed tests, QA ensures

  • - 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

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

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

SDLC Methods

Waterfall

V-model

Agile

  • - Scrum

  • - Kanban

  • - XP

  • - Lean

  • - more ...

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

Waterfall • • • • • • A stage starts after previous one is completed Requires

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.

V-MODEL
V-MODEL

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

Agile THE AGILE MANIFESTO • • • • Individuals and interactions over processes and tools Working

Agile

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

Scrum terms • • • Roles – – – Product owner (PO) Scrum master (SM) Development

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

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

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

Dev Team • Tecm – – – – Pigs Self organised 5-9 full time members Cross

Roles and responsibilities

Product owner

What

When

Sign of

Vision

Scrum master

Team

Removes noise Removes impediment Facilitates scrum Agent of change

How

How long

Code

Test

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

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.

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

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

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

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

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

Agile Essentials

Agile is about people Test-driven development (TDD) Automation Continuous Integration

Continuous Integration & Continuous Delivery 30
Continuous Integration & Continuous Delivery 30

Continuous Integration & Continuous Delivery

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

QUESTIONS?