Skip to main content

Are you a Tester or a QA Engineer?

When I first started out in the Software QA world, my job title was a Test Analyst, which I disagreed with, we weren't just testing software, in my eyes we were doing far more than that, and still are.I often hear people talk about software testing and QA in the same sentence as much the same thing.

They are not the same thing!!

By QA I mean, as I'm sure you're aware, Quality Assurance. Testing can form a part of that QA as an activity to help ensure quality, but they are not and should never be classified as the same thing.

Testing to me, is the physical act of ensuring that software works correctly, and that tests pass. QA is more around ensuring quality in the product, not just through testing the code, but from discovery, requirements gathering, test case design and test case review.

As a QA we shouldn't just accept requirements as they are written, we shouldn't just accept design documents, we need to provide a quality gate throughout the life of a project. If by testing code we can ensure quality, then testing helps, but it should by no means guarantee or be the only piece of Quality Assurance that anybody does on a project.

A prime example is if you're not questioning requirements, or not questioning designs then you can write test cases against the requirements, against the designs, but the tests themselves whilst they may pass, they're not necessarily delivering much quality to the business, or ensuring quality products.


Comments

  1. Hi, Gareth...

    I'd like to point out a couple of things with which I disagree.

    To me, testing is not "the physical act of ensuring that software works correctly." Nothing can do that. The space of valid inputs is (typically, at least) intractably large; the space of invalid inputs is infinitely large; the potential variation in timing is infinitely large; the set of possible states of programs running concurrently to yours is infinite; the potential variation in sequences is infinite; and the potential sources of error in the test are effectively infinite too.

    At best, testing can suggest (not ensure) that the product CAN work, not that it DOES work, and certainly not that it WILL work. Testing can suggest (but not ensure) that the product doesn't work. In either case, it takes judgement by a skilled human to decide whether the test provides useful information, and it that human who makes the determination how to apply that information. Neither the test nor the testing does that on its own.

    http://www.developsense.com/blog/2014/01/very-short-blog-posts-11-passing-test-cases/

    I would characterize the work of "testing the code,...discovery, requirements gathering, test case design and test case review" as precisely within the scope of the work of a tester. Comparing the code to some document, whether done by human or machine, is something that we call "checking".

    http://www.satisfice.com/blog/archives/856

    Meanwhile, a "quality assurance person" questioning the requirements and questioning the design doesn't make the product better, any more than any investigative reporting makes society better when she investigates agricultural practices or apparent miscarriages of justice.

    http://www.developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business/

    Until someone with authority to make changes makes a change, nothing happens. The product doesn't get better for having been tested. The product gets better for having been testing and fixed, and neither testers nor "quality assurance" people do that.

    ReplyDelete
    Replies
    1. Hey,

      Thanks for commenting.

      Perhaps I should have expanded on "ensuring the software works correctly" to "ensuring the software works as expected against requirements", this to me is what testing is all about, it will as you say, suggest that it CAN work, but also that it DOES work as expected against requirements as expected etc. So like you say, the judgement of a skilled human against documentation (be it COAs against a PBI or requirements in any shape or form) is an essential part of this process.

      I like your thoughts around the whole team being part of QA, and you're right, but as a tester (or even QA) we need to encourage quality within the team (as should everyone), but all too often developers don't think about the bigger picture, and things can get missed. I suppose the key point is to work as a team to deliver quality, however, we as testers need to help ensure that quality is met, through our test cases and through our discussions and communication with others.

      A "QA person" questioning the requirements and questioning the design in my experience does make the product better, but as you say, it depends on who you question the code or question the requirements to and how you do it. The product does get better by having been tested providing results are fed back and acted upon as you say, and as you said in one of your comments on the last post, we provide information to people who can ensure quality.

      So actually, not sure how that contradicts my original post, but I can definitely feel there needs to be a follow up on it. :)

      Thanks again.

      Delete
  2. Hi Gareth,

    I think Mr Bolton was just using your blog to promote his own personal interest rather than providing any real feedback.

    I understand what your saying! Testing is one of the tools to ensure quality not the only one and not the same QA. Testing focuses what's wrong bugs, failures etc QA focusses on how to make the product superior. There is a difference because you can add quality with out testing. QA can start as early as the requirements stage whereas testing has wait until the code has been delivered into an appropriate environment.

    Nice Blog, keep up the good work

    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.