monitor_code

QA Is Not About Code-&-Scripts

The defect

Software testing community has faced a bug now called a feature: we witness code and automation and the shift of priorities towards them in QA processes have some testers cornered now. Basically too much automation is leading to many testers loosing grips on other important things that should have been tested. It is somewhere on a subconscious level today that automation ads value, automation reduces costs, automation reduces time required for testing and improvers ROI and many other goodies are delivered with the automation. It’s literally everywhere!

But we are not testing software for machines, people will be using the end-product and most of them do not really care how great the app is from the technical aspect as long as it serves their needs. However many users pay attention to looks and usability, something no automation tool may test in a decent manner. We are now failing to realize there are places white testers simply should not apply scripts. This is a bug that is in our brains rather than in the software we are testing which means it should be tagged as top priority defect and has to be dealt with ASAP.

What may this bug cause?

We are currently headed into a world where software testers care whether their own code works fine rather than making sure code developers have written is fully operational. This results in such areas as awful color choices, misaligned test and terrible user interfaces in general being overlooked without gaining deserved attention.

Where there’s no place for code?

  • Any decent tester should do what he is supposed to meaning – software testing. Additional responsibilities like code creation and execution may lead testers in a different direction. You don’t want your testers caught is sorting their personal code mess rather than testing the software you are developing. Make sure you are not automating everything just for the sake of it. If you prefer writing code over testing somebody else’s one – consider changing your expertise and becoming a developer.
  • One of the largest motivations for testers that are learning how to code is higher salaries so QA transforms into a chase after dollars. That attitude is unacceptable. So if its money you are concerned with and are motivated to move towards the tip is the same as in the previous bullet – become a programmer.
  • Testers are simply amazing at delivering more value and input inside automated test coverage, however should they be responsible for actually creating all that coverage? I can’t say I think so. Pair testing is great when such things are considered because we have a tester who is working together with a developer in these terms.
  • Automated scripts should really get done in development and not in testing. Separating them would have a huge impact and most of it will be negative to both the code and the project in general. Why would you want two teams following each other for more test coverage?
  • Various tests that have UI and usability as activities. No code, as mentioned above can properly test layouts and color schemes and the functionality of an app in terms of use.

Don’t get this wrong, testers should know how to code for series of reasons one of which is you test something better when you know how it works, however it’s the general orientation that matters when you are web, mobile or desktop testing.


TestFort Blog

About TestFort Blog

TestFort blog is an official blog of TestFort QA Lab company and is dedicated to various QA and software testing issues.


no comments yet

Be the first to comment this post!

Would you like to share your thoughts?

Software testing & QA blog by TestFort © 2017

×