“My name is Steven and I am a tester“
I was thinking of which subject to do for my first blog post and the above seemed a good way to start, even thought it might sound like a introduction at a self help group session.
It’s taken from a recent presentation I gave around the subject of what being a tester actually means in a modern software development industry. Using myself as a case study, I wanted to explore whether I can still actually call myself a tester.
When I first started in software development, I didn’t choose testing…it sort of chose me. Originally I wanted to be a developer. I know that I’m not the first person to say that and I won’t be the last. The role I took in the end was a Technical Tester role which pretty much involved running through some basic scripts and doing a bit of investigation in to the code and the backend. In all honesty I got pretty bored so I started looking at automation which I loved as I got to use my development skills.
As I progressed through more senior roles, I started leading teams and having an influence on the way the department and the company itself was run. However every time someone asks me what my job is, I would say that I’m a tester. For the last few years my day to day activities have either involved writing code, PO activities such as maintenance of the backlog and customer interaction or scrum master style duties such as running ceremonies or removing blockers for my teams.
So why do I still say I am a tester? To answer this I looked at different areas to see how I test in them.
By participating and pushing 3 Amigos sessions and looking to push BDD, I’m looking to test out a user story and looking for the scenarios that might have been missed. I actively look to get myself involved in cross functionals and system design meetings where again I’m testing the design of the system itself – both from a functional and a non-functional point of view. During all of these events, I’m testing mainly by questioning…questions, questions, questions – a massive part of a tester’s toolkit.
This is likely to be a more obvious one, but I’m testing both my own code and others’ code every day. Using techniques such as analysing code coverage, TDD, checking cyclomatic complexity and performing static testing I can ensure that I’m making quality checks on the code constantly. The ultimate aim for me when testing code is to provide the best feedback as rapidly as possible.
Processes can sometimes be a dirty word, but even the most lean team has processes of some kind – just not processes for the sake of it. When they exist, they must be tested to ensure they are as efficient and practical as possible. Lessons learnt sessions, sprint reviews and team retrospectives are examples of ways of continuously improving these processes and the way the team works and I always try to be an active member of all these sessions, contributing positively where I can.
To me this is all about mentoring and challenging people – if you are line managing, advocating or mentoring in any way then you should be looking to challenge those people to continuously improve. I always look to do this and to give people the confidence they need to venture outside their comfort zone.
Lastly I think the biggest thing I probably try and test is myself in similar ways to how I look to test others – by pushing myself to do things I’ve not done before and looking to continuously improve.
In all the areas above, I discovered I was using similar skills to examine and hopefully improve the quality:
- Analytical thinking -> The ability to see things from a logical point of view
- Flexibility -> Accepting that things may change and having an ability to adapt to different situations
- Communication -> Knowing how to communicate in the appropriate way for different situations and having the ability to do it effectively
- Innovation -> Always trying to see the bigger picture and finding creative ways of looking at and doing things
“My name is Steven and I always will be a tester“