Testing Flashcards
Testing Flashcards
Here’s my collection of flashcards that I’ve been adding on LinkedIn recently.
Test Strategies & Approaches
Test strategies and approaches (or even plans) are different documents. One gives us a path for what we want testing to be whilst the other gives us a view of what testing we’re going to do.
Without being strategic your organisation wont have a route to improve its test offering and without an approach you can’t communicate your intent (leading to adhoc reactions and firefighting).
Testing Objectives
Testing is about sharing information both within your team and the wider audience. That means we have to create and share testing artefacts that can be understood by those we share them with.
Even automated tests may need to be shared to business stakeholders and auditors, so consider how you name them to be meaningful. They should describe the wider workflow and do they share what the outcome should be.
Silence
I saw a post that talked about how people should should be silent in teams. As a tester I say that’s wrong; being told to be silent creates risk in an organisation from a culture and quality perspective.
We should strive for people to not have to feel they should be silent. By asking questions and challenging things we can gain information and make better decisions to make improvements.
The Awesome Power of Speaking Up
Seniority in Testing
To progress as a tester isn’t about more years / experience working on a tool or project, it’s about learning hot to solve issues and advise people. Usually progression is about thinking and talking about testing in wider contexts (organisational or at board level).
One specific type of testing (or tooling) might not give you a wide enough skillset to be able to solve a wider array of testing issues as you go wider. That’s why it’s good for you to have a lot of methods and approaches in your tool belt.
Test Reporting vs. Quality Reporting
I’ve been talking about reporting recently and how 100% test complete doesn’t mean the product is fully tested. Using a test completion pie chart to determine if something is good enough is very risky, especially if you don’t interrogate what that means.
Test reports, like percentage completion, is a project management tool to track timescales and not quality. To understand the quality of something you need to talk about it; what have you seen it do, the good and the bad. That means engaging with the tests and the outcomes of testing.
100% Complete is Not 100% Covered
Implicit vs. Explicit Asks
A lot of testing assumes explicit asks, but I’m sure we’ve all worked on projects where not everything has been asked for directly (non-functionals anyone?)
Implicit asks are those that a company might want but forget to actually document. These constitute a risk because we might have to make assumptions about them and might forget to measure them. Using exploration and benchmarking we can get enough information to start asking “is this right?” and try to make those implicit asks explicit.
Or we can use Triforce (3Amigos) to tease those implicit asks out early.
Callum I want a printable version!
Okie dokes, I’ve got you covered…
