Quality as a tester
Quality Assurance is something that has sparked some interesting views from multiple articles I have written. But with all the feedback I have gotten from the previous articles, it shows me that people have vastly different views on what Quality really means.
One person in particular wrote something that I have great issue with. I am not going to call that person out, or anything because everyone has different opinions which is great for challenging your mindset when it comes to anything.
This person said “As a tester, you don’t do “quality assurance,” since as a tester, you can’t assure quality.”
I don’t believe this statement at all and I will tell you why.
As a tester, you are still testing the function of a feature or software as a whole right? As a tester, you are making sure that the feature works as intended. How is that not assuring quality if the feature does indeed work as intended per the design? I would be fine saying a tester doesn’t COMPLETELY assure quality, but on some levels they do.
For example, let’s say you are testing the functionality of a car door opening. Did the door handle break off? Was it strong enough when force was applied to open it? Does the key work to lock and unlock the automobile? Does the car door actually open and shut with no issues? Does the car door open enough for people of all sizes to get in and out safely? These are just a FEW of the questions I would ask myself when testing something like this. However, aren’t you assuring SOME form of quality by testing functionality? I think you are. Now of course, you will test out better quality when you get to more advanced tests such as collision on the door, materials and so on. But having functionality work as intended and for a purpose- in my eyes, is technically some form of quality. It might not be the highest level of quality checks, but it’s still in its most basic form.
As a tester, I am not saying all you should do is run through test cases to make sure requirements are met. You need to ask yourself “is this useful for myself or customers” and “what is the point of this feature, why are we building this.” A development team can build features all day long, but it doesn’t mean that feature will be used by customers or is even worth developing in the first place. Another person made a comment about how I should keep my thoughts about a particular feature out- but why is that? If you have to click 13 buttons to get to something you need and you find an easier, better visually way to present that, why not bring up the idea? What’s the worst thing that can happen? I have worked on many pieces of software where I have added my “two cents” about functionality or lack of functionality because if software is too hard for your audience, what’s the point of developing it? Isn’t the point of making software to make our lives easier to some degree? Especially if you are marketing to the common user? I am a huge advocate of “easy to use” software for customers. Of course, how do you find out who your audience is? Maybe you should do a survey or ask the customer on “how can we make this software easier for you?”
If software Is too complicated, people shy away from it. No one wants to spend hours setting up software or spending hours understanding how to do the most basic feature. I think as a tester, you should be able to speak up and say “hey, this software just isn’t working in a way that I think would benefit the customer and here is why.”
I think people should speak up more about things like this because if not- how else are you going to find out? Oh, that’s right, by people complaining. Whether you agree with me or not, I think overall, the differences between views in this field vary from one extreme to the other.
Engineering & people leader
7 年Thomas, I'm really enjoying the conversations your article is sparking here!
Quality obsessed and Agile enthusiast professional / Freelance hands-on software testing specialist and test coach / Blogger / Interpreter / Catalan Proofreader / Radio host / Humane Technologist
7 年I agree, Michael Bolton: as a tester, I can undoubtedly advocate quality, but this does not automatically mean I can assure quality. Thank you for stressing this point!
Head of Product at Experian Consumer Services
7 年Once we recognise we all test in our role, just at various stages of the lifecycle, I'd hope those who specialise as test/quality analysts will remove the label of assurance. It begins with everyone owning quality. It ends when a group consider themselves those that assure it. Easy to say, hard to put into practice and follow through till it becomes an org. wide discipline.
I believe I am the person you're referring to. "As a tester, you are making sure that the feature works as intended... aren’t you assuring SOME form of quality by testing functionality? I think you are." No, you are not. You may be examining whether the feature works as intended. Yet to examine something does not change its nature, just as standing on a scale does not make sure you lose weight; just as diagnosing a disease does not cure it; just as discovering problems with the car does not improve anything about its design or manufacture. To be sure, discovering problems is a step towards remedying them, but unless someone does something further, nothing changes and quality has not been assured. When I replied to your original post, I was evaluating it and pointing out problems in it; testing it, as it were. At the time, I left a link to this: https://www.developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business/, which does more of the same with the notion that testers assure quality. I'm not sure that you've read that post. You certainly haven't responded to any of the points in it, so it seems. That is: despite testing your argument, I have been unable to assure the quality of it. This suggests that identifying problems with something (like the idea that testers assure quality) doesn't assure that they will get better, unless something further happens and things change. At the moment, I can't think of better evidence for my point. Cheers, ---Michael B.
Infrastructure Engineer/Hands-on Infrastructure Manager
7 年I'm not the person you mentioned, but to some degree I disagree. And just as a very simplistic example. The car door opened correctly when I opened it, but that does not mean it will open 6 months from now for the customer, or for the cars not in my test set. Automation gets you a larger test set, but are you holding the door handle at every possible angle, or is there some angle that on the third attempt breaks the handle off. That's why I believe you can't assure quality, also you can't test quality into a product.