My Testing Principles

Going back to one of my first blog posts, I wrote about what I thought testing is and what it means to test. (See: What is Testing?) You will be able to get a fairly good idea of what my principles are but I have never written them down clearly for people to understand my approach to testing software.

The reason for doing this is because I recently appeared on a podcast titled “The Guilty Tester” by Dave Duke, where I discussed how I may be betraying these principles. It was at this point I realised I have never (at least consciously) thought about what my testing principles are.

Test early
As a tester I want to be involved as early as possible with the Product Owner and/or developers to iron out any misleading or confusing requirements to ensure we are all on the same page.
Spread the load
In my team there is one tester (me) and six developers. The flow of work through the team board means the testing column becomes a natural bottleneck for work and as such I believe everyone can get involved in running through some checks of a user story against acceptance criteria. Combining this with my Test Early principle means everyone understands what the risks are with this product and what areas we need to focus on.
Make decisions together
My job as a tester is to present the team with assessments as to how the product behaves under certain circumstances and what level of quality we are currently at. As such I am a big believer in changing the mindset that testers are the ones to “sign off” a user story. We can make these decisions together by looking at the  risks identified and decide whether our product is good enough to ship to our customers
The value of conversation cannot be understated
Talking to people face to face about the work I am doing develops a faster feedback loop which enables us to bring a product to market much quicker. I still document my testing using various note taking methods but I immediately feedback to the development team after I have finished an exploratory testing session. Once a debrief has been completed I will collate my notes and write them up so the team have visibility of what testing has been completed.

These principles are something I try to stick to each day, although, as the podcast explores, this is not always easy. This means I regularly review them and sometimes have to adapt them to the situation I am working in.

Much like developers discuss and agree on coding standards for a team I like to set a testing standard, that demonstrates how I feel testing should operate within our workspace. This is not a dictation of methods and is always open for debate (much like coding standards) but I think it is important to bring the topic of “HOW we test” to the table.

The reception to sharing these principles with my team has been really positive as it helps everyone start to understand the art of testing and also it helps me learn because I can shape them based on our teams way of working and potentially adapt new practices I previously had not considered.

Overall, if you are struggling to get people in your team to understand the role of a tester, write down your Testing Principles (they can be whatever you believe in) and share them with your team. Ask them for feedback/critique. This brings the topic of testing onto everyone’s plate and you never know, people may surprise you.


One thought on “My Testing Principles

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s