Recently I described myself as stagnating as a test engineer. Being a very goal driven person I have found it hard to feel a sense of achievement, without a test (or finishing line) at the end of something. I met Matt Heuser recently and he mentioned (paraphrasing slightly), ‘you can’t learn everything, sometimes you have to accept the things you ARE learning and let the rest go’.
This caused me to re-evaluate the skills I had been learning at work recently. I looked back at the last few months and on top of testing, I had also been; running retrospectives, sprint planning, story break down sessions and the internal testing katas. As well as working with the product owner to flesh out possible solutions to upcoming stories. I realised that I was overlooking all the skills I was learning to be able to do the activities I listed.
What skills are involved?
I then went on to look at these activities further, to breakdown the skills involved in doing them. For example, to run a great retrospective requires idea generation, pre planning, good situational awareness and facilitation skills as well as the ability to capture the relevant takeaways. That is a pretty impressive list and that I am sure is not exhaustive, reading this back I can already think of more, for example time-management, making sure you have enough time to finish the meeting properly is vital.
I might not run a great retrospective yet but my boss, Chris Smith (who runs awesome ones) has been coaching me and providing me feedback on the sessions I have run and pointers towards things to improve for next time. Chris has let me run retrospectives for our team and also attended ones that I have run for test engineers across the company. On one of the first occasions, I planned tasks and activities expecting more people to be there. This meant that the tasks did not work as effectively when some didn’t turn up. Chris recommended rewording the next meeting invite to convey this, so for the next invite I added ‘I will tailor the activities based on the number of attendees , so could people let me know if their ability to attend changes’.On another occasion the activities I chose meant that there were two activities where we were writing post-it notes back to back, so Chris recommended books (Game Storming by Gray,Brown and Macanufo and Agile Retrospectives by Derby and Larsen) to help introduce me to more activities I could try. He also identified times when I missed a body language change or pointed out the positive things I did, like when I actively asked someone who had not said much what their thoughts were.
How do these skills relate to your role?
These skills I mention above might not be technical skills, but technical skills aren’t the only ones which are important for testers to master. Sometimes finding issues is not enough, you have to be able to communicate these issues to others and as long as you are working with others good communication is imperative. As I thought about the skills I was using and learning, I realised that this did relate to becoming a better tester. I have not been stagnating. If you ever feel yourself question how you are progressing and what you are learning, then stop and look at what you do day to day and don’t under estimate what you are learning.