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.
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.
Hi, Gareth...
ReplyDeleteI'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.
Hey,
DeleteThanks 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.
Hi Gareth,
ReplyDeleteI 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