This is our strategy as a test team. That’s different from our Product Test Strategy (which is … coming soon!). This strategy talks about what kind of team we are building, what it’s for, and how we are doing it.
1st draft created by DIarmid Mackenzie - 21 April 2020. Comments are welcome. If you want to make edits, please discuss with me first.
Mission & Vision
“Developers build stuff. Testers help them to understand what they have built.”
Mission: To provide the best information we can to the rest of the Safe Paths team (at all levels) about threats to the goals of Safe Paths project.
The best information is (among other things):
Clear
Timely
Explicit about its limitations
Vision: All levels of the Safe Paths organization have good information and understanding of the quality & nature of what they have built (and are building), to inform their decision-making.
Key Pillars
The key pillars of our strategy are:
People
Focus on Value
Connections to other teams
Self-Direction
Support & Feedback
People
We are particularly looking for people with the following attributes. We seek out contributions from those who have these attributes already, and we encourage everyone on the project to develop these attributes
Commitment to the craft of testing
Specific relevant domain or tooling expertise & experience
Curious, inquisitve, open to new ideas
Clear & candid communications
Generous & sipportive community participants
We attract these people to the project, and the test team, though
A clear articulation of the Safe Paths project goals, and the test team’s role within that
Outreach using existing channels in the Test Community, and any other connections we may have
Continuously working to create an environment in which people can do their very best work.
Focus on Value
As far as possible, we try to relate the information, concerns & insights we share with the rest of the Safe Paths team, towards the value that this project is trying to deliver.
This includes providing support for both:
Maximizing the benefits that this project can deliver
Minimizing the harm that this project can do. And we must all be aware that this project is at risk of doing significant more harm than good to individuals and communities. It is our responsibility to support the rest of the organization in ensuring that does not happen.
There are many artefacts that we will use to support our testing: specifications, test plans, UI mock-ups etc. etc. However, we never lose sight of the fact that these artefacts are fallible, and that delivering value to project stakeholders is more important than conformance to any of these artefacts.
Our Quality Map (which everyone is invited to help develop and shape) helps us to stay aligned with this principle.
Connections to Other Teams
We consciously build and develop connections with other teams on the Safe Paths project, so that we can serve them as trusted providers of information about what we are really managing to build and deliver.
Our relationships with the Product and Dev teams are fundamental
However, we also aim to build relationships with folks in Communications, Implementation, and the overall Leadership team.
We build these relationships through
Direct outreach to individuals in these teams, at all levels. We seek to understand how, as Testers, we can best serve & support them in their goals.
The creation and sharing of useful information and models, that can support them in doing their jobs.
We recognize that people from different disciplines and backgrounds may use very different language & terminology from us, and we do our best to reach out the them in terms they understand, rather than expecting them to understand the “language of testing”.
Self-Direction
We are a non-hierarchical self-organizing team. While certain individuals can (and must) take the lead on particular initiatives, there are no structures dictated to the organization.
We may offer suggestions and ideas to people for how they can help us, but these are suggestions, not orders.
Three behaviours are fundamental to this working successfully:
We don’t wait to be told. If we see something that’s not being done, that we believe is important, we tell other people what we are proposing to do, give others a reasonable chance to expresss any thoughts or concerns, and then we do it.
We do what we say we are going to do, If we change our minds later, we tell people so that they can choose to step in and take over.
When we need help and support, we ask for it. Everybody in this team is going to be taking on challenges they have never done before. We all need help and guidance, and asking for it is a sign of strength, not weakness.
As a team, we hold each other to account on all of these behaviours.
Support and Feedback
We are a community, and we can achieve more as a collective than we can as individuals.
As well as a focus on our own work, we look around us for others who may be struggling or in need of support, and offer to help them in whatever way would be useful to them.
Many people are putting in long hours of their own personal time towards this project, as well as continuing to mee their commitments to their work, their family, and their community - not to mention the additional stresses of lockdown, such as social isolation, school closures etc.
Before offering feedback, we always take care to check that the other person is open to hearing some feedback at that point in time,
Public artefacts created by team members are assumed to be open for feedback by default. Where possible, we explaiin to team members how we’d like that feedback - e.g. should they add comments to the document, or should they just go ahead and edit.