(Guest blog by Testing The Waterhouse)
Firstly, let me introduce myself, my name is Gareth (author of Testing The Waterhouse), I’m a Senior QA Engineer and started working in QA the same time as Richard for the same company. I got into QA for similar reasons to Rich, I’d graduated and was finding it hard to get a job so ended up working for a small consultancy firm as a QA analyst.
When Richard got in touch with me a couple of weeks ago about guest blogging on his blog, I wasn’t really sure what to write about, seeing as he used to be a tester, but has moved into the DevOps world. I started reading The Phoenix Project, so I could try and gain an idea of what his new world is like, unfortunately, I’m only half way through, so didn’t really want to write a blog post about that…
I then thought, why not write about the things that he might not have liked (or at least I don’t like) about working in QA, and what might have led to him leaving the world of QA and moving to a shiny new DevOps world.
Firstly, I dislike that QA is seen as a subordinate to development, it’s very rarely seen as equal, and more often than not (and I have mentioned it on my blog here) it’s looked down upon as part of the Software Development Lifecycle.
Secondly, in some places, and luckily not where I am currently, it’s not very technical. It’s seen as a means to an end and the QA get involved with manual testing and just that, they are asked to come up with test cases and execute them, and that is it. I love getting my hands dirty with some code and analyzing bugs/issues that I find.
Thirdly, when systems are so interlinked it makes it extremely difficult to test, one change in one area of a system can have an undesired impact on other systems that nobody knew about, and then this makes it into production. There’s only so much time and only so much QA that can be done, and more often than not it’s the QA that gets squeezed at the end of a project.
Fourthly it’s the blame game. When bugs make it into production, there is always someone who points the finger at the tester, you should have tested this, you should have tested that, often I just think to myself, you are more than welcome to come and do my job, but then i don’t tell you how to do yours when you make mistakes, so please don’t do it to mine. Bugs will make it into production, I once gave an interview and I asked what was the biggest bug that had made it’s way into production, and what did you learn from it, his response was “None, I’ve never let a bug into production…” to which I just thought to myself:
Finally, it’s the lack of good QAs that are around, I feel that we’re fighting an uphill battle to improve the perception of QA in IT, yet when bad QAs get hired, it sets us back unfortunately.
So, with all the above in mind, it’s easy to see why someone might leave QA and go onto pastures new, however, why do some people (like myself) choose to stay in QA and actually enjoy it?
One of the main reasons I stay in QA is that every project is so different, you get the chance to talk to the business, you get opportunities to write code when doing automated tests, you get opportunities to pair with developers and learn new things all the time.
I also enjoy finding problems and analyzing what the issue is as best I can and then liaising with developers about my findings. If I can’t figure out the problem, it’s nice to sit with the developers if I have time to go through the findings with them, or at the very least ask them what the issue is/was.
I’ve stayed in QA because it has been good to me and I still enjoy the day to day challenges it brings, I am sure that when I reach as high as I can go in QA then I will look to move on to possible another field, what that field is, I couldn’t tell you now!
Rich (in my eyes) was a good QA, and it’s no surprise that he’s moved onto what he sees as better things, as I never really felt his heart was in it, but for myself right now however, I’m more than happy within QA and the day to day challenges, learning new ways to test systems and helping other QAs become better QAs.