Friday, 15 February 2013

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.

2 comments:

  1. Replies
    1. But my point is that it shouldn't be this way :)

      Sorry, just seen this comment.

      Delete