Skip to main content

Is QA looked down upon as part of the Development lifecycle?

Having been involved in QA for over 5 years now (where does the time go?), I've felt it's time to start documenting my thoughts on life as a Test Engineer/QA Analyst/Test Analyst etc.

I've been in a number of different companies, and through no fault of my own, I've felt I have had to earn developers respect as a QA no matter what company I have worked for.

Let me start with an example, I had been in testing approximately 2 years, when I joined a hedge fund, where simple bugs can cost millions of pounds. I arrived into work one morning and a developer grabbed me, he said to me that he'd put some code live the night before and needed me to test it.... Yep, that's right, I needed to test something after it had gone live!? At first I couldn't believe what he was asking me to do, but being relatively new to testing, and probably not confident enough, I tested it and sure enough it worked fine. When i mentioned it to my senior, he was horrified (and rightly so, as I would be now had something similar happened), nothing actually came about of it, but it sticks with me, as how developers expect QA to just do what they say when they want. Whilst this also highlights a total lack of any release management, it does show a lack of respect for QA, with a thought process (and i'm paraphrasing here) of "QA isn't important, I'll just put this live"....

Obviously had this happened now in my career I would have raised this as a major lack of respect from the developer, and a massive mistake that they should have been reprimanded for.

Whilst I've not encountered anything close to that incident in other companies, there is definitely a lack of respect from some developers and even from the business for new starters especially, and even for people who have been at the company for a long time.

What can a QA do to counter that?

One thing that I find helps is working closely with the developers, and not agreeing to everything they say. Too often, I see QAs just blindly agreeing with developers because they don't understand the complexities of the development work. Developers love to be challenged, they love to have little arguments, so I find this definitely helps.

Also learn to speak dev talk, learn about the acronyms and the technologies they use, if you can talk to them about their code, they are more likely to respect your opinions on how things should be tested and why.

Another thing that can be done is to get the developers to test, get them understand the hardships of what it is that we do, as all too often developers think testing is easy and is a given, when in reality we know that when testing something from the ground up, it's a lot more than just pointing and clicking at stuff!

Everywhere I have worked, I like to think I have gained the respect from developers and the business for the work I do. I have also been lucky enough to work with developers who are happy to help, and tend to appreciate the importance of QA (I like to think I have played a part in that!)

 I think the problem lies in that there are a lot of QA who view QA as easy, and don't become involved in technical decisions, and sit back and let the developers tell them what they need to do, this can be through a lack of motivation or even from becoming too friendly with the developers, whatever the reason, it doesn't help earn their respect.

I suppose to summarise, respect is not something that is given freely in any walk of life, so it is rightly so that respect should be earned from developers and the business, and until they start having good experiences with QA then unfortunately it will always be an uphill battle from the start, one however, I feel that any good QA can overcome.

Comments

Post a Comment

Popular posts from this blog

Testers: Be more like a Super-Villain!

Who doesn't love a Super Hero? Talk to my son, and he'll tell you how much he loves them, talk to many adults and they'll say the same! Deep down, we all love to be the Super Hero, we all want to save the day! However, I want to talk about the flip side of Super Heroes, the Super Villains... I often play Imaginext with my son, and I (unfortunately?) am nearly always the Super Villain! Be it Lex Luthor, Joker, Two Face, Mr Freeze or The Riddler! These are all great characters and great Super Villains, but why would I want to write about Super Villains? A while ago where I worked, we had a few Super Heroes, people who would be able to come in and "fix" things that had broken and help deliver projects on time. We then shifted, we decided to do away with the Super Hero culture and try and prevent from being in that position in the first place, whilst we didn't go as far as wanting to hire Super Villains, it's definitely a story that has stuck with me and t...

Value in QA Courses/Qualifications?

I have in the past questioned the value in getting certifications/going on courses for the sake of getting a certificate in testing. Whilst I do still question the worth of such an issue, I have recently read some articles which has shown me there is more value in these courses/certificates than I previously gave them credit for. The main positive that I can think of, upon completing a course like an ISEB Foundation, is that it ensures that testers are on the same page when it comes to communicating. A bug is a bug, or if I'm speaking to someone about Integration testing, they know exactly what I am talking about and won't get confused. I think in ensuring that everybody is on the same page when it comes to discussing testing issues/testing activities, it helps in gaining respect and confidence from other teams and other team members, as we are all singing from the same hymn sheet.  It isn't just about communication in the term of words however, it is impor...

Measuring QA Key Skills and Competencies

I have been thinking about how I can help encourage self improvement within my team, as I understand it, everyone wants to improve, it's just that often there are a number of things that hold people back. I believe one of these things that hold people back are around identifying skills that they are perhaps weak in or that they could/should improve on. So I thought about how I can help tackle that problem. One solution that I want to try with people is to identify the key skills for a QA, what key skills should every QA have, or at least what key skills make up a good QA? If I can identify these then I can start helping people identify if they are lacking in an area. Sure there is a competency matrix that we have, but it has things like "An excellent understanding of XXX", it's often very difficult to quantify what an excellent understanding actually is. So I sat down and came up with the following key skills: OOP Test Documentation Manual Testing Automated...