As I enter double figures in years as a Software Tester, I am finding that I am learning more and more about the technical aspects of a project than ever before and I find it very interesting and above all, it is empowering me to make even better and more informed decisions when thinking about my test plan.
There are testers out there in the big wide world that have taken this even further and moved into automation roles and as there is always balance in everything, there are also a lot of software testers out there that are being spoon fed by the developers and just simply, well, test software utilising stacks of test cases.
I have been involved in interviewing software testers before now and I was amazed at how many people put lots of technical abilities on their C.V.’s, but can never back them up and even to the point that when asked a simple question, “How would you test a soft drinks machine?” they all focused on the coinage boundary. Not one said, pull the plug and see if it still works! Not that technical a test at all, but easily missed.
So, how technical does a QA need to be?
The obvious answer to this is to be as technical as the individual can be, which will mean they can then be really proactive adding great value to any team because the more you understand, the more you can see the bigger picture, the more you can see the holes and potential pitfalls and thus test these areas reducing the chance of defects appearing in the live environment. A developer generally works on a smaller proportion of the bigger project whereas a QA will usually work on pretty much all of it.
When another member of the team, (non-technical) was asked a question by a developer after he had finished his technical conversation with fellow developers, he apologised, saying he had switched off when they were talking about “stuff” he didn’t understand.
Now I can understand this person’s point of view to a point, why try and understand something when you don’t need to, but when that understanding empowers someone, even if it is only at a higher level, then why not try and understand? Ask questions. Get to know the unknown. Okay so you don’t know how to code an API for example, or where it sits on a server, but you can get to know what it does and how it fits in with the flow of data. You will get to understand known problems with them and common pitfalls. All this information is integral to becoming better at understanding a project beyond the UI and thus making more informed decisions.
Becoming more technical savvy doesn’t mean you have to go on courses or read a mass of books. In fact, it is quite the opposite. All you need to do is ask questions and ask someone to show you how something works (developers are easily bribed with food or a good coffee). Better still, get them to show you how you can interact with the piece of tech without using the UI. For example using something like Postman for R.E.S.T. Bit by bit, you will find yourself understanding a lot more, asking more involved questions and asking to be shown more and before you know it, you have evolved into a more technical savvy software tester.
Here are a few simple example ideas to get you started:
- Get to know your http error codes
- Install Postman (a chrome extension) and get to know how to use it
- Get to know Visual Studio & Intellij IDEA so you can look at the code and ultimately, the test coverage.
- If you don’t know already, definitely learn enough to understand HTML and CSS
- Install the developers tools on your preferred browser and get to know how much you can learn from it. The console on it’s own will let you know all the errors that have occurred during a test.
The list is by no means exhaustive and is a stepping stone. I am sure there are many, many other recommendations from fellow testers. I would be interested to see these ideas in the comments.