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

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

      Sorry, just seen this comment.

      Delete
  2. Impressive work on the writer’s part.
    resumeyard.com

    ReplyDelete

Post a Comment

Popular posts from this blog

What is a PBI?

After my last post, I had the question of what is a PBI... so I thought i'd write a short blog post about what they are and why they are used.

A PBI is an acronym for Product Backlog Item. It is a description of a piece of work that your SCRUM team will develop and deliver. When you have a list of Product Backlog Items, you then refer to that collective list as a Product Backlog.

The product backlog is often prioritised and yourteam will work through each PBI, and release on a regular schedule... I am however going deep into the world of Agile development, which isn't entirely what this post is about, so I will stop myself now.

A Product Backlog Item is made up of the following:

Title - This is often a one liner that gives the team an idea of what the PBI is about, although it can just be an ID for the item and the team work off of that.

Description - Breaks down the PBI in a bit more detail, and can be written in any style, however I prefer it to be written as follows: 



By writin…

Dealing with Selenium WebDriver Driver.Quit crashes (Where chromedriver.exe is left open)

We recently came across a problem with Selenium not quitting the webdriver and this would then lock a file that was needed on the build server to run the builds.

We were using Driver.Quit() but this sometimes failed and would leave chromedriver.exe running. I looked around and found this was a common issue that many people were having. We (I say we, as we came to the solution through paired programming), came up with the following, that would encapsulate the driver.quit inside a task and if this task takes longer than 10 seconds, then it will clean up any processes started by the current process, in the case of the issue on the build server, it would kill any process started by Nunit.

[AfterTestRun]
        public static void AfterTestRun()
        {
            var nativeDriverQuit = Task.Factory.StartNew(() => Driver.Quit());
            if (!nativeDriverQuit.Wait(TimeSpan.FromSeconds(10)))
            {
                CleanUpProcessByInheritance();
            }
       }

        private s…

Famous Movie Quotes applied to Software Engineering - Jaws

You're gonna need a bigger boat? How can that relate to Engineering?

Firstly, let me ashamedly admit, that I've never seen the whole of Jaws all the way through. It's on my list of films to watch, but whether I get round to it, is another matter!



Anyway, to apply this to engineering, it's almost like "you're gonna need more testers/developers"...

We hear this all too often when trying to push releases out the door, let's throw men at it... However, as we all know, a bigger boat/more men... isn't always the answer, it's not a guarantee of quality, or even a guarantee of getting things done quicker.

If you have a task that will take 2 hours, simply having 2 people work on it doesn't mean that it is halved, in fact often, the time taken to do the task remains at 2 hours, but the maintainability and the knowledge around that area is increased, so it's a price, in my opinion that is often worth paying.