What 3 things do you wish you had known about QA before starting?
I personally wish that:
You are not always going to be given all the information you need to start, continue, or end a project. For the most part, you’re going to have to either look for the information you need based on similar features or issues in the client’s database, or communicate directly with the development team about what it is you need.
Focus on what the team has been directed to do. In one of the first projects I ever worked on, I was so fixated on writing whatever bug I could find which was great however, I would often find that my bugs were either ignored by the development team or labeled as “Not task related.” Why is that, though? From what I’ve seen, developers have a finite amount of resources to expend (time, energy, etc.), so there are a set of things they assign QA to do that aligns with what they’re currently working on. Doing your own thing is only great when you find a critical issue otherwise, it’s a waste of time.
Look for a mentor (or mentors) at your workplace. A mentor will help accelerate your growth, as they’ve walked the same path you’re on and can help you avoid some of the mistakes they made.
I started in QA 20 years ago so this hopefully would have aged badly . My first role in QA was Test Manager moving from being a dev lead in the same company. So my 3 things:
Not anyone can manage a QA team. When I was thrust into the role as part of a restructure, it was in an organisation that believe a manager was a manager and could manage any team. The team were built of no experienced testers and I didn’t have a clear direction on where we needed to go . When we did recruit an experienced tester, I spent most of my time with them trying to understand more on the rights and wrongs of testing.
You won’t always be viewed as the person responsible for production faults. I was often dragged into finger pointing in meetings focusing on getting it fixed and why QA didn’t find it. Never focusing on the root cause.
This career will change your life. I suppose I wish I’d known it at the time because I thought I’d failed as a dev lead after being moved as part of a restructure. As it turned out, I wanted to learn more and more and took more lead roles, automation roles, manual qa roles to get a better grounding before finally returning to leadership. So with all the bad in the first 2, it gave me an ambition to make things better.
Hey, thanks for sharing Gary. Just to touch on your first point, definitely having someone in a leadership role who has gone through being a tester first and then directing us as the project went along made things so much smoother. Unfortunately, as in your case, you learnt the hard way but either way bad experience is still experience.
The real world is nothing like the ISEB/ISTQB foundation course. This one is a given really, I don’t think I’ve ever done a training course that survives a comparison to the real world! But I guess it ties in with the first and second points from Tatenda, you won’t get all the information and trying to follow good testing principles will face some level of pushback.
You need a thick skin. Again probably already covered by the examples above, but in my experience it’s the testers that get accused of issues, not the developers. They also get it in the neck when things are delayed, and when you do a good job and nothing bad happens, it’s not the testers who get recognised. OK, that last point has improved over the years, but there are still those who think testing is an (un)necessary evil.
When you get to a point in a project or a job when any question is met with ‘speak to the tester, they will know’, then you know you’ve done a good job despite points one and two! If you’re the type of person who can get the information out of people even though it may not exist, and you are strong enough to stand your ground when you know you are right, then eventually people will understand your value. And then you can ask for a pay rise…
Hey Simon. Perhaps you also share this viewpoint but for me taking the ISTQB FL course was a form of self validation that I used as a marker to say that I qualify for testing jobs. Ironically, I am yet to have an interviewer ask me about the ISTQB qualifications. Experience is key for sure.
Three things I wish I had known before starting QA.
Running tests is rarely the goal in itself. The point is that it’s simply a means to improve the quality of the product or system.
Testing isn’t about simply checking if the product behaves as written in the specs. It’s about understanding the logic that’s been implemented and verifying whether it has any flaws. On top of that, you need to check if the product truly meets the customer’s needs.
Collaborating with developers brings huge benefits to both sides, so it’s important to build a culture that encourages smooth collaboration. Some developers may feel uncomfortable when bugs are found (as if they’re being blamed), so you need to foster psychological safety and avoid creating an “us vs. them” atmosphere.
That you absolutely need to look after yourself and think about what’s in your control and what’s outside of your control. At a time I use to get frustrated because I thought that my feedback was not listened to - in fact, it was listened to, there were just other factors involved. For example getting a product out very quickly to market for commercial reasons.
To think about what type of company you want to work for and why. I didn’t have much intentional thought to begin with (bringing up a young family at the time), so simply went from job to job. Research what the company is about in detail and why you might want to work for them. It turns out for me, that innovative companies, those that are smaller without all the red tape suite me better.
That’s a very good point, you need to at least be somewhat socially aware and concious about how you deliver a particular message otherwise it will come off as rude.
Hey Melissa, thanks for sharing I can totally relate to that one. I feel like nothing can actually prepare you or adequately warn you before choosing a wrong company to work for up until you actually make that mistake. Hopefully a fresher can come across this post and avoid this mistake
You are the only person responsible for your personal development. Not your manager. Not your company (It’s great when a company can help with that!)
Our craft and IT industry is always growing. So do not stop learning: new approaches, domains, and tools.
Learn how to communicate your value and results (depending on the audience). Your message for managers, developers, DevOps engineers, and users should be tailored differently. Why? Because all of them have different goals and values.
Let me share my top 3 things I wish I had known about QA before starting:
If naturally, in your everyday life, you always imagine how things could go sideways or how things could be improved, then QA is probably made for you! QA is really about systemizing prevention and continuous improvement.
You’ll have to prove the value QA brings to a company. Make quality “sexy”. So you’ll need to like to: talk to people to understand their priorities, create a big picture vision to align everybody, get your hands dirty into coding, testing, reporting, etc. to actually increase quality.
There so much more than just testing functionalities! It is incredibly rich! You’ll always have something new to do or learn. Because if something is repetitive, you’ll just automate it
Thanks @tatendasakarombe22 for raising this question! And thanks to everyone who replied. This is very helpful for me as I journey through my training.
Been into QA for ~13 years now, so looking back at those years
It’s a lot more meetings then expected! (Sprint, refinement, retro, daily, 3 amigo’s, helping & coaching others, trainings, … )
It’s not developers VS Testers, it’s developers & testers work together.
There is so much bad software out there and you’ll get to see all of it. You’ll wonder how companies can sustain their business with “that” kind of software.
. My first role in QA was Test Manager moving from being a dev lead in the same company. So my 3 things:
