2012 regina tc - 103 quality driven

Amir Barylko - Quality Driven MavenThought Inc.

AMIR BARYLKO

QUALITY DRIVENUSING BDD + TDD


TESTINGWhy Testing?

Unit tests TDD

Integration TestsAcceptance Tests


REALITY CHECK

• It is impossible to gather all the requirements at the beginning of a project.

•Whatever requirements you do gather are guaranteed to change.

•There will always be more to do than time and money will allow.


NO MORE EXCUSES

• It works on my computer!

• It was like that when I got here!

• The previous developer didn’t know XXXX!

•We need a satellite connection in order to run it!

•We can’t reproduce the error!

•We can’t test that!


UNIT TESTING

•Test for a class or method

•No dependencies

•Should use mocking

•Small

•Clear


TDD

•First write a test that fails (RED)

•Write code to make it pass (GREEN)

•Check if code can be improved (REFACTOR)

•Start again until it’s done


BENEFITS OF TDD

•Prove that your code works

•Avoid waste (debugging)

• Increment code quality

•Better design

•Regression tests as byproduct

•Make changes with confidence

•Bring back the joy of coding!


WHEN TDD IS NOT ENOUGH

•Legacy Code

•Refactoring is not viable

•Verify functionality across layers

•Validate feature end to end


INTEGRATION TEST

•More than one class

•Still some parts can be mocked

•Partial functionality of subsystem


ACCEPTANCE TEST

•Black box testing

•Crossing all layers

•Should cover all scenarios

•External subsystems may be mocked


SOFTWARE QUALITYWhat is it?

Low QualityClassic QA


WHAT DOES IT MEAN?

•Better code?

•Faster delivery?

•Less bugs?

•Make sure we deliver the right thing?

•Better Processes?


LOW QUALITY

• Lack of testing

• Lack of communication

• Lack of metrics

• Lack of traceability

•Wrong tools


CLASSIC QA

• Team separated from developments

• Follow scripts or requirements

• Done after the feature is implemented

• May have more than one project in the queue

• Feedback cycle may take weeks

• Manual (no automation)


DOES IT WORK?

•Your opinion here......


A NEW CONCEPTFeature First

BenefitsOutside In Approach

Runnable featuresRoles


FEATURE FIRST

•Write the feature before implementation

•Developers will implement feature using TDD

•QA will validate against feature

•Repeat until all features are done


BENEFITS

•Focus on the feature

•Testing all the way

•Traceability

•Quality every step of the process


OUTSIDE IN APPROACHRed

GreenRefactor

BDD

TDD

Red

GreenRefactor


RUNNABLE FEATURES

•Features describe functionality

•What if we could run them?

•Then features would validate functionality

•Becoming live documentation


ROLES

•Who writes the feature?

•Who implements the feature?

•Who validates the feature?

•What’s the role of QA, PM, etc?


WRITING FEATURESGherkinSyntaxFeatureScenario

Steps


GHERKIN DSL

• Business readable DSL

• Flush out requirements

•Documentation

• Automated testing

• Used by Cucumber, SpecFlow, jBehave


SYNTAX

Feature: Listing movies

As a User

I want to list movies

So I can see the contents of the library

Scenario: Browse available movies

Given I have the following movies

When I go to "Movies"

Then I should see in the listing


FEATURES

• Keyword Feature

• The rest is free text

Feature: Listing movies As a User

I want to list movies

So I can see the contents of the library


SCENARIOS

•Each feature file can have multiple scenarios

•Each scenario can contain multiple steps

•Keywords:

•Given When Then

•And Not But


STEPS

Scenario: Browse available movies

Given I have some movies

When I go to the listing page

Then I should see all the movies


DEMO


QUESTIONS?

2012 regina tc - 103 quality driven

Technology

quality driven

quality driven

quality driven

quality driven

quality driven

quality driven

quality driven

doneamir barylko