Inspired by this article from @claire.reckless âWhat Does It Mean To Be A Technical Tester?â
What does it mean to you to be a technical software tester? When this topic came up at the Open Space at TestBash Manchester 2017, it was clear to see from the group of people there that technical meant something very different to everyone at the table. We were all software testers (or QAs if you prefer) but our experiences in the industry seemed to have shaped our feeling about this.
There were a few of us in agreement about certain aspects of what it means to be technical such as how knowing how to use proxy tools felt technical to us. Many agreed that you didnât need to know automation to be technical. Many disagreed with this point. It was an interesting session!
Do you agree with Claire? Would you add anything to what she has written?
I read the article, and Iâm probably being a bit thick, but I donât understand why the need for the label. It feels like we have the constant desire to stick labels on certain skills (or groups of skills), when given the width of testing activities across different industries Iâm not convinced of the usefulness of them.
I regard it as a bit of a spectrum, ranging from anything involving a bit of a command line access all the way through to coding. If youâre doing a lot of coding, then perhaps Developer in Test* is a better description of what you do.
Though in some environments, this term really refers to someone who is building test automation infrastructure, APIâs for other testers to use in their scripts and so on.
Itâs a hard one âlabelsâ I agree with you. I know with some your label can make or break your career and I donât believe Heather was trying to put labels on anyone but just trying to gain clarity around âWhat does it mean to be a tech tester?â
Interesting though my CTO who is amazing and ensures our team has the opportunity to work almost pure Agile had some great thoughts about that. She told me to tell anyone who askes what am I within the team⌠I am the Best ME that I can be and thatâs what our team asks of everyone and THAT is how we run our teams.
Isnât she awesome, so I can forget about the pressure of a label and really focus on the work at hand⌠The Blockchain
Itâs an interesting question which makes me wonder what the core component of software QA is considered to be. I think if we understood what the core of testing should be then anything above that would be a skill modifier and depending on the level of technical detail required to do that function, would then tell us what technical tester may be.
Personally, I bridle at the term tester as it feels like a very input-output function. More product and less engineering focused. I love that my title is lead QA engineer. It means that not only am I required to understand basic QA modes of thought, organization, planning, and communication - I am also required to understand computer science as a fundamental practice. Given any software configuration, knowing how networking works, knowing a scripting language and an object-oriented programming language, knowing functional programming techniques, front end and back end technologies, APIs and middleware and presentation layers are all part of the engineering mindset. For me, that is technical testing. I can do manual QA, automation, and even developer pull request reviews in a very technical way. I guess, for me, technical testing is doing any of those things in such a way as to have deep knowledge on a subject so that you can understand the realities of your qa practice and how it may affect any level of the development stack.n
To great extent,I think I agree with Phillipeâs comments above about âtechnicalâ. Itâs about the deep knowledge on a subject. If you do, you should know how to do it. Hence I use a very simple way to judge if someone is âtechnicalâ - If someone is able to actually execute the tests using whatever ways he/she is good at, I personally think he/she is technical. However, the reality is that some people out there always have lots of test theories/test ideas (knowing the WHAT), when it comes to doing it, they just canât do it (ie they know WHAT to do but donât know HOW to do it). Please donât get me wrong, i was not saying the testing theories or testing ideas are bad, they could have brilliant ideas, which is the very important first step of testing. But to me, itâs not called technical. For example, when it comes to performance testing, most people would just use the buzz word âJmeterâ, but then how many of them really understand how to use it to test. Maybe I am wrong, âknowing the HOWâ is what I use to judge if someone is technical or not.
Here I am taking the example of a software tester. A software tester is testing an application and making sure that its functionality is working as expected. If testing is to go through the test cases and verify the positive results then it is not true.
A bug free application is result of not only development, but effective testing performed by an expert QA. I am not saying if there are testers cramming through the test cases without actually knowing the complete work-flow of the applications and technologies embedded to it.
A technical tester is one who always dig through the technical details. It could be browser, it could be database or application server, configuration settings and etc. Once should have basic understanding of the back-end details from technical point of view.
End user query resolution is provided only by a technical person and we call them technical tester or technical expert to be very precise. A software quality assurance services provider always look forward for such testers as assets.
Having understanding of only QA processes and protocol is not enough for testing job. Additional practical knowledge is always very much required. A tester would gain ready-to-go attitude only when they are competent enough to handle any technology thrown on them. It is only possible for a technically sound QA who always learn the How to approach.
Can you clarify your question? I spoke about what makes someone a technical tester in my last paragraph. Was your first question an actual question or a statement?
I would look at this more from the angle of the domain of testing, e.g. SAP, financial services, network protocols, health, security.
Testing by nature is exploratory (irrespective of whether you use automation or not). You experiment with current state of software and analyze whether it meets the customer needs. So, just by being good at human-led checks or machine-led checks, one does not become technical.
The real value of being âtechnicalâ comes from domain knowledge. You might know all about how Scrum works, how to test in general, and all the automation frameworks, but if you donât know how the credit card processing works, you wonât be an effective tester. That knowledge is what I would call as technical.
Having said that, if you donât have that knowledge to start with, then your testing will not be valuable at all, so being âtechnicalâ is not a value-add, but a necessity.
Your credit card processing example is a good illustration, but needs a a little clarification. Do you mean that the tester needs to understand the business processes involved in the end-to-end credit card processing, understand the necessary data flows from front-end EPOS terminal firmware, via data comms protocols to the APIs and actual data processing at both the customerâs and vendorâs banking apps, or are you referring to actual under-the-bonnet code operations in those APIs and apps?
