I’ve been procrastinating on a blog post I would like to write about some VRTs I made using Puppeteer with Jest, as it ended up being a long hit-and-miss process and I’m not sure which parts I would like to write on. I might even make a few posts on the subject, but I do tend to move from one topic to the next quite quickly so perhaps not.
I decided to write something a bit different in the meantime, just to keep in the habit of updating the blog. Today’s topic is on how I have worked out the next steps in my personal development.
As a QA with no testing mentor/lead, it can be really hard to find what the next thing I should be learning is. I started making a React app, updated my JavaScript knowledge to ES6, researched a few different topics etc etc. But no matter what I learn, I don’t feel any direction – and without direction, it’s hard to stay on the same path for long. Where is the path going? Am I just walking in a big circle, bringing me back to the start without opening any new opportunities or roads?
Assessing the current plan
I looked critically at my learning plans for the first six months of 2019, which boils down to a simple list around which I piled some plans and actions, resources and courses.
For the first time since writing it, I asked myself what direction this list was taking me in. Is this stuff I want to learn because it will be useful to me as a QA, is it stuff I just want to learn out of personal interest, or is it stuff I decided to learn because it’s what the people around me know?
The answer for most of those things is the third. I do want to learn React, I want to make React apps because I think it looks like fun. Jest and CI are there because I’d like to learn more about how to write test suites that are useful and meaningful for my job, and how to add them to the continuous integration tool. Everything else on that list is only there because the developers on my team are learning those things. Without a lead QA, I have been subconsciously comparing and judging my worth as a QA against the knowledge of the other people on my team – people who are not testers and who have different requirements for their work.
After looking at this list, I realised that I could learn everything on it and still be no more proficient as a QA than I was before. In fact, it wouldn’t even make me more proficient as a developer since I’d be better off simply building on the base I already have with CSS/html/JS to make a portfolio of web apps if I wanted to go into development as a career.
I decided to look for tester-specific skills online, and found the easiest way of doing this was to look at the requirements in job adverts. I’ve added a few examples below of what came up on the first page or two of a search for “Lead QA” positions, which would be a step up from my current position as Junior QA (we unofficially ditched the ‘junior’ part after 6 months, but it’s still what it says on the contract so I’ll stick with it because I’m Lawful Good).
Making a new list
Since my first list concentrated on specific skills and tool proficiencies, as opposed to general knowledge, communication skills etc, then I decided to continue along that vein. I am also working with my line manager and the CTO to improve non-technical skills so that I can move away from manual testing, to include QA as an advisory role on the philosophy and implementation of testing from start to finish of projects. I think this is a bit far off though, as I don’t yet have the full weight of knowledge and experience required to back up my requests. This means ideas are easily brushed aside or written over by developers. I like to think my overall goal for 2019 is to become so good at QA that the devs have no choice but to respect and bow to my absolute authority as Quality Overlord.
The first thing I did was make a list of common skills that came up in job ads, neglecting those that seemed specifically unuseful for my company, eg testing software used by Microsoft software houses where we would use alternatives. I still have to be able to justify every part of my personal development against other tasks that need doing at work.
I then split these into three categories:
Understanding Required – I either don’t know half of what is needed, or I know some but have no practical experience of implementing it
Understanding Somewhat Gained – I have enough knowledge to get by at my current level, but need more to progress further
Understanding Gained – I’m confident that I have an acceptable level of understanding
I did this as quickly as I could, going on first instinct and gut feeling because I knew that the longer I thought about anything, the more I would decide I knew nothing at all. Everything would have ended up in the Understanding Required section. Maybe everything should be in there. But it’s not, and that’s fine.
Next, I added three columns graded 1-3 a la risk assessments. The first is Difficulty, ie how complex the subject is or how difficult to implement with regards to the type of projects I work with. Importance is how important this skill or tool would be for my company, based on talks and plans we’ve spoken about in the last year. Lastly, Desire is my own interest in learning a particular topic. I added this because at the end of the day, this is my learning journey and I’ll do what I like – within the bounds of what is required of me.
After this, I needed a way of grading which would show which skills I should work on first. Obviously, things that score highly on Importance and Desire should be up there. I also decided that things with a higher Difficulty rating should be penalised, since every QA article I’ve ever read says to start with the easy tasks and work your way up. Keeping it simple, I came up with the short formula:
Total = Importance + Desire – Difficulty
The whole process took me 30 minutes, and although I’m sure I’ll be making edits and changing tack according to corrections made by my team and managers, this already seems like a much better path than the one I had before.
Ranked, this is what the plan looks like:
I’ll see how this goes for now, and if I change my mind again then you’ll get another post like this about whatever method I decide to use next time! If you have any suggestions or resources you think are useful for mapping a learner journey for QAs then let me know, it’s definitely something I’m missing in my life.
I’m also currently in the process of breaking down how much time I spend on different activities in the work day, so I’ll be looking at that data in a few weeks and I’ll share any interesting (or boring and expected) findings about what my day looks like, as well as info on the tool I’m using.
Undeveloped Bruce 