Last year we were challenged to build an agile test team to work in different products and technologies for 8 distributed teams from 3 to 7 people. We had to break with legacy assumptions on how testing should be enacted while keeping company policies. And most of all, we had to make sure everyone is enabled to do the best possible job. Enabling a team is about motivation, trust and simplifying decision making processes. The test team as a whole has to scale and fit for multiple scenarios and projects. Every team member had a different background and needs so no policies would really apply to all. Or worst, we would be spending time twisting the rules to fit each case. First, we decided to coordinate as a guild. Second, we issued this Test Manifest as a declaration of purpose and discipline.

1. Julio Ramírez
A TEST MANIFESTO
at Telefónica Digital
@yebenes
es.linkedin.com/in/julioramirezyebenes

2. 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

3. MAKE TESTING USEFUL

4. Useful to…
the TEAM
the ORGANIZATION
and YOU

6. 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

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

8. 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

9. WE TEST SYSTEMATIC, WE TEST PRAGMATIC
Follow data driven & structural testing methods
Exploratory 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

10. WE DO BDD
Must use BDD artifacts
Should use Gherkin syntax
Gherkin 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

11. 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, …

12. WE KNOW THE WHOLE PRODUCT BLUEPRINT

13. 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

14. WE CLAIM TO TEST INTENSIVE on component…
… fine tune and harden during integration…
…and have a product confidently ready by E2E

15. 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.

17. 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

18. 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

20. To make it useful to the TEAM you have to contribute with…
Test Methodologies
Development Skills
Release Engineering
System Engineering
Process Engineering

21. To be useful to the ORGANIZATION you have to make sure you make it
Manageable
Visible
Shared
Scalable

22. To be useful to YOU it has to provide you with
Learning
Opportunities
Fun

23. Thanks to ….
Full Senior Management Trust & Support
Development Training
Test Methodology Training
Mentoring Programs
Coaching and Peering
High Motivation

25. Julio Ramírez
A TEST MANIFESTO
at Telefónica Digital
@yebenes
es.linkedin.com/in/julioramirezyebenes