Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Commitment to the craft of testing

  • Specific relevant domain or tooling expertise & experience

  • Curious, inquisitveinquisitive, open to new ideas

  • Clear & candid communications

  • Generous & sipportive supportive community participants

We attract these people to the project, and the test team, though

...

  • 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 artifacts 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 artifacts are fallible, and that delivering value to project stakeholders is more important than conformance to any of these artefactsartifacts.

Our Quality Map (which everyone is invited to help develop and shape) helps us to stay aligned with this principle.

...

We may offer suggestions and ideas to people for how they can help us, but these are suggestions, not orders.

Three behaviours behaviors 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 express 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 behavioursbehaviors.

Diversity of Approaches

In the Software Testing community, there are a wide range of different ideas about how to approach testing, and some of these differences can lead to heated, long-running and seemingly irresolvable debates.

...

  • Manual scripted testing (or “checking”), measuring the product against a tightly defined set of expectations.

  • Testing that follows a plan, derived from key product documents such as Requirements and Specifications

  • Exploratory Testing, which may be tightly focussed focused in a given area, or de-focussed focused and holistic.

  • Technical testing, using software tools (whether 3rd party or homegrown) to deeply explore the product (e.g. Security Scans, HVAT)

  • Developing, running and maintaining suites of Automated Tests (or “checks” if you prefer)

  • Testing in Production.

The one shared pricciple principle that we hope that all testers will try their best to align with is the “Focus on Value” principle described above.

...

As well as the open GitHub repo (including all our bugs, past & present), this Confluence space is also publicly visible, and open to public comments (although only project members can edit content).

Over time, we expect to do more to increase the visibility of, and engagement with, these public spaces, to build a strong community of interest outside the project, to complement the efforts of those wokring working inside.

Working in public may creates additional challenges, but the light that it shines on our work will be invaluable in holding us to the highest of standards on the work we do.

...

Many people are putting in long hours of their own personal time towards this project, as well as continuing to mee meet 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 artifacts created by team members are assumed to be open for feedback by default. Where possible, we explaiin explain 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.?