A Test Manifesto 2014.03.26

Julio Ramírez

A TEST MANIFESTOat Telefónica Digital

@yebenes

es.linkedin.com/in/julioramirezyebenes

Testers are lesser QUALIFIED

people which delay PRODUCTS

without adding up significant VALUE

I wish I wouldn’t need them so I could hire more

DEVELOPERS

MAKE TESTING USEFUL

Useful to…

the TEAM

the ORGANIZATION

and YOU

WE ARE DEVELOPERS

Automation is a must (LETS make OURselves a FAVOR)

Working build, deploy, test at anytime, anywhere is a

must

Test code is scripting

WE ARE DEVELOPERS

Your code should be as good as any other developer’s

Test code is versioned in GIT with the rest of the product

Reduce complexity by using main code artifacts

TEST AND CODE IS A SHARED RESPOSIBILITY

Get your work reviewed by pull-request or specific calls

1. Test architecture peer review

On relevant updates and every new target release

2. Per pull-request by other project-team members

3. General test suite peer review

On relevant updates and every new target release

4. Test audits

WE TEST SYSTEMATIC, WE TEST PRAGMATIC

Follow data driven & structural testing methodsExploratory is fine, just don’t wanna hear about it…

Follow D.R.Y principle

Refactor and reuse tests (needed for structured testing)

Don’t rewrite unit tests

Orthogonality

Check Robustness (Postel's law)http://en.wikipedia.org/wiki/Robustness_principle

WE DO BDD

Must use BDD artifacts

Should use Gherkin syntaxGherkin serves two purposes – documentation and automated tests. The third is a bonus feature

when it yells in red it’s talking to you, telling you what code you should write.

.features are the spec and development is red-green

WE OWN WHAT WE TEST

We know what we test functionally and technically

We enforce testable architectures

We maintain a test architecture aligned

Look for performance, reliability, scalability, HA, security, …

WE KNOW THE WHOLE PRODUCT BLUEPRINT

WE BUILD MOCKS & DRIVERS

A test architecture is a deconstruction exercise

A B

C

DRIVER C

DRIVER D DRIVER F

MOCK FMOCK D

MOCK C

DRIVER E

MOCK E

WE CLAIM TO TEST INTENSIVE on component…

… fine tune and harden during integration…

…and have a product confidently ready by E2E

WE WORK TO HELPING PRODUCT OWNERS AND

SR MANAGERS MAKE DECISIONS so…

We issue summary reports to that purpose

• We point out precisely what configuration we test (versioning)

• And communicate what we don’t know explicitly

• We summarize information by topics (themes)

• And maintain traceability as an artifact to that purpose

• We point out higher level topics first

• And issue an executive summary always with a recommendation in clear bold

• We don’t work towards justifying what we do

• But we have arguments to support what we say

• We don’t work to raise bugs or cover code. They are an artifact instead.

PROJECT AND PRODUCT CONTROL

Project checkpoints

Regularly with horizontal management

Sync meetings

We will run weekly sync meetings were we will run peer reviews

and exchange best practices

MANAGE YOURSELVES

Own your work

Dev-Lead is not your boss

Teams are expected to run autonomously

Google is your friend (or Bing or Yahoo or …)

Call management for things you cannot solve by yourself

(or management can solve quicker)

Use the team “Skype” chat when looking for help

To make it useful to the TEAM you have to contribute with…

Test Methodologies

Development Skills

Release Engineering

System Engineering

Process Engineering

To be useful to the ORGANIZATION you have to make sure you make it

Manageable

Visible

Shared

Scalable

To be useful to YOU it has to provide you with

Learning

Opportunities

Fun

Thanks to ….

Full Senior Management Trust & Support

Development Training

Test Methodology Training

Mentoring Programs

Coaching and Peering

High Motivation

Julio Ramírez

A TEST MANIFESTOat Telefónica Digital

@yebenes

es.linkedin.com/in/julioramirezyebenes