Software Testing

Software Development Life-Cycle

 Idea and Requirements

• Description of the purpose

“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 formalised as Requirements

“These are the functionalities that we are going to implement on our Web Site”
 Specifications

Specification Describes:
• Functionality
• Product design
• Performance requirements
• System architecture
 Design
• Description of the way to reach the purpose – how to made the software
• Specifications
PRD(Product Requirements Design)
BRD (Business Requirements Design)

• Good Specification has following characteristics

– Clarity of details and definitions
– No room for misinterpretation
– Absence of internal/external conflicts
– Completeness
 Design
• Once Specification is approved it should not be changed
• Changes in specification do happen
– Can lead to bugs
– Changes should be negotiated/communicated to Dev and QA

• The sooner QA is involved in Design the better

• QA review Specification
– Specification might have bugs
 Coding/Development
• Realisation of the ideas in the Specification
• Architecture design documents
• Schedule and planning
• Coding standards
• Code version control (Git, Mercurial, SVN)
• Development environments
• Code review
• Unit tests
 Testing and Bug Fixes
• To test a code that changes is a waste of time
• Testing starts once code is in stable state
• Before starting tests, QA ensures
– There is test environment with correct code/build version
– Build is not broken by doing a smoke test

• Bugs are fixed then re-tested

• New functionality testing
• Regression test is done once bugs are fixed
• Acceptance test might be done by customers (UAT)
 Release & Maintenance
Release:
• Whole/part of the product is given to the users
• Package of known files having concrete version
• Release can have new features and bug fixes
• Huge release can have downtime
• In case of production bugs
• Rollback
• Patch/Hotfix
 Release & Maintenance

Maintenance

• Crucial to be able to work on several versions

• Separate different versions in source control
• Bug fixing 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
 SDLC Methods

Waterfall
V-model
Agile
 V vs V

• Verification – did we build the system right

• Validation – did we build the right system
 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
 AGILE
• THE AGILE MANIFESTO
– Individuals and interactions over processes and tools

– Customer collaboration over contract negotiation

– Responding to change over following a plan

 AGILE

• SCRUM
 Specification

User Story
• Sentence format
• End user language - As user I want to be able to achieve X.
• End user needs
• Maintains end user contact
• Cheap to maintain
 Specification

Examples of User stories:

• As a user closing the application, I want to be prompted to save if I have
made any change in my data since the last save.
• As a user, I want to search for my customers by their first and last names.
• As a user, I want to be able to review all send mails.
 Scrum

• Roles • Sprint retrospective

• Daily scrum meeting
• Product owner
• Scrum master • Artefacts
• Team • Product backlog
• Ceremonies • Sprint backlog
• Sprint planning • Burndown charts
• Sprint review/demo
 Product Owner

• Defines the features of the product

• Decides on release date and content
• Responsible for the profitability 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
 Team

• Self organised
• 5-9 full time members
• Cross functional (Devs, QAs , UI Experts, DB)
 Who does what?

• Product owner • Removes impediment

• Facilitates scrum
• What
• When • Team
• Sign off • How
• Vision • How long

• Scrum master • Code

• Test
• Removes noise
 Product Backlog
• The list of functionality and issues
• Managed by Product owner
• Prioritised
• One list for multiple teams on product
• Anyone can add items
• Keep visible
 User Story
• Major building block of Product backlog
• Unit of scope – Who, What, Why
• Describes customer view of value
• High level acceptance criteria
• Story differs from Use case
Story tells only What but not How . The Use case is more detailed.
 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 identified and each item is estimated
– Scrum master does NOT decide for the team

• Team self-organises 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
 Sprint Review
• 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

• Whole team participates

• Product owner(s) signs off 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
 Daily Standup
• Happens everyday at a fixed 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

• Specific issues are resolved offline
Traditional vs. Agile
 Summary
• Ideas can come from anywhere • Bugs are fixed then retested
• Design is describing how to achieve an idea • Regression testing is done before Release
• Once completed design should not change • Release is giving piece of software to users
• In reality it changes
– QA should adapt Test Cases to this change

• Testing should start once code is in stable

state
 Summary

• Agile
• Roles - Product owner, Scrum master, Team, Ancillary roles
• Artefacts – Product backlog, Sprint backlog, Burndown charts
• Ceremonies – Sprint planning, Sprint review, Sprint retrospective, Daily scrum meeting

• Well implemented agile has many benefits

QUESTIONS?