ray scott - agile solutions – leading with test data management - eurostar 2012

Ray Scott, GTAgile a subsidiary of Grid-Tools

Agile Solutions – Leading with Test Data

Management

www.eurostarconferences.com

@esconfs

#esconfs

Insert

speaker

picture

Introductions

• Name: Ray Scott

• Company : Director and Founder of GT Agile

is the consulting division of Grid-Tools, the premier

test data provisioning software vendor

• Experience: CSM & CSP, HP testing tools, IBM

trained midrange developer, Testing Strategy

Methodologist (Leader of Quality at Walt Disney

World, Orlando), Practical Agile implementer (7+

years) and believer in Quality comes first.

Responsibilities

• Govern System Integration providers

• Functional and Non-Functional QA

• Performance

• User Acceptance

• Environments

• Seed and scenario test data

• AGILE principles

Common project concerns

• Multiple silos of development

• Integrated central testing interest

• Data model mismatches

• Versioning

• 2 to 4 week Sprints

• Greenfield and Legacy

• Seed, Functional, Business scenario and Performance

data

• TDD and BDD

• SCRUM, XP, Waterfall

• Time-zones, language, documentation, tools,

POLITICS!

• Test Data Provisioning in an Agile Environment

What is QA?

• Often QA and Testing are assumed the same

• Cannot test quality into a product

• Testing is based on what is known about the product

being developed

• Qualitative versus Quantitative (point of view versus

measurable)

• Adding value is Qualitative

• Determining results is Quantitative

QA – Testing versus Validating

• Validating is a form of

confirmation

• Validating leaves little room for

expansion

• Validating requires little product

knowledge

• Testing is open to the tester’s

interpretation

• Testing has more combinations

• Testing is more reliable with

product knowledge

Agile Principles!

• Satisfy the customer

• Welcome changing

requirements

• Working software

• Frequently work together

• Give them the

environment and support

they need

• Face-to-face

• Working software is the

primary measure of

progress

• Maintain a constant pace

• Technical excellence

• Maximizing the amount of

work not done

• Self-organizing teams

• Tunes and adjusts its

behaviour

Agile Test Data Management

• Agile development has often had limited success due to

development being Agile, whilst the supporting data is

not

• During development, rules and data models often

change. However, data generation to support high

levels of change often cannot keep up

• Traditional data generation methods often takes weeks

but Agile looks for hours

• The issue with AGILE test data management, with

respect to test data is, precisely, the test data itself and

the automation of the regeneration of the data

Agile Test Data Management

• The development of test data management should be

treated the same as a development project or high level

supporting infrastructure

• Similar to the expected participation of Product Owners

and sponsors with product definition and expectations,

support for data quality and data integration

environments should be figured in to data management

• Test data management should be considered as part of

a greater data governance initiative, data migration or

data warehousing project

• Always remember Test Data Provisioning is a key

SERVICE

Tools and Processes

• Tools must serve the process, otherwise the tool will

drive the business

• Don’t expose too many tools to the landscape

• Leveraging the right technology to address data issues

• Change request system must be transparent

• Select tools that can be integrated - Requirements, Test

cases, Automation, Data generation, Versioning,

Reporting…..

• Implement best practices based on strong principles, not

negotiable methods

Testing RISK and Data dependencies • Changing

requirements

• Ambiguous

requirements

• Product knowledge

• Outsourcing

• Change management

• Timeline

• Complexity

• “Happy path”

• Communication

• Issue resolution and

prioritisation

• Unit testing

• Load/Stress synchronised

planning

• Sign off

• Automation

• Project versus Program

• Testing lead by development

Owning the data considerations

• Provisioning tools

• Environment

distribution

• Versioning

• Masking

• Sub-setting

• Generic business rules

• Credit card

• Postal codes

• Customised business rules

• Age selections

• Balances

• Data pooling

• Data inheritance

• Communication

• Metrics (affects on velocity)

• Issue management

Provisioning data

• Definition; “providing or making something

available”

• Data Provisioning

• Operational analytics

• Data extraction, replication and creation

• Operational analytics

• In-depth knowledge of business objects and

modifications to application

• Database modelling

• Query definition and execution

Environments

• Test Driven development requirements

• Continuous Integration

• Smoke/Entrance test criteria

• Functional test cases

• Non-Functional test criteria

• Load/Stress

• Acceptance

• Pre-production

Aligning to an adaptive environment

• Iterative

• Collaborative

• Transparency

• Empirical

• Aggressive to deliver

quality

• Team mind set

• Practice not process

• Innovative

• Accepting

What does it take to transition • Project Managers to Scrum Masters

• Reduce administration and increase facilitation

• Remove blocks and protect from external noise

• Testers MUST become more involved and take more

ownership

• Create new roles when necessary and they provide value

• Test Data Engineer

• Traditional PM for legacy integration

• Building relationships is more valuable than politics

• Get it done attitude over following the process

• Transparency should be rewarded

Leading in an Agile environment

• Get involved in development planning and

execution

• Spearhead Quality initiatives

• Collaborate in all directions

• Own the data

• Inherit best practices

• Monitor improvement

Own the data • Data is the glue that holds a project together

• Data is an asset and an artefact

• Data should be transparent

• How it is built

• Where it lives

• Who are the providers and consumers

• Build a centre of excellence

• Document

• Publish

• Promote

• Inherit all other data sources

Agile test data

• Tester responsibility with data

• Determine usage

• Convert test conditions to data

conditions

• Understand the life cycle of the

requested data

• Ensure versioning/repository

available for recall

• Unambiguous communication

methods

• Build relationship with other data

owners

• Ensure DBA understands your cycle

and request mechanism

• Identify prioritised tested cases with

high profile data

• Smoke test data

• Priority 1 test cases

• Product Owner “Must haves”

• Map data sets to test case

• Database Administrator

• Data remains consistent across the

database

• Data is clearly defined

• Users access data concurrently in a

form that suits their needs

• There is provision for data security

and recovery control (all data is

retrievable in an emergency)

• Mapping conceptual designs for a

planned database

• Refine physical and logical data

models

• Work closely with IT managers,

database programmers and

multimedia specialists

• Consider the back end organisation

of data and front end accessibility

for end users

Strategizing with the business

• Determine the real business requirements

• Build relationship with product owners

• Ensure attendance at planning meetings

• Primarily focus on short term planning

• Buy into the documentation process and add value

with process and tools

• Ensure value of test cases and the supporting data

• Share test case review responsibility

• Confirm data is of value

Value of solid data provisioning

• Create data that is Fit for Purpose

• Aligns to business rules

• Data flow

• Unambiguous communication

• Permits cross functional comprehension

• Defines “Happy path” and boundary testing

• Repeatable with little impact

• Avoid data that cannot be verified

• Measure change request (signs of failure)

Issue resolution management

• Defects when not addressed immediately should be

managed as STORIES in the backlog

• Defect stories to be prioritized by the Product

Owner

• No backlog – No tools, however . . .

• Data requests are stories

• Data provisioning can have major impact to

progress, treat as a story and/or defect request

Next steps

• Invest in an Agile methodology

• Develop a quality driven practice

• Select the right tools for the right job

• Socialize methodology and tool training

• Accept failure as a learning practice

• Invest in people

• Promote innovation and success

Questions ?