On: being “technical” in a QA profession

Categories Testing

milling_machine

The process of leaving Software Quality Assurance Engineer (QAE) position behind after 3 years of climbing the “hill” from junior QAE to lead QAE, does not leave you with a shortage of things to reflect on. One of the rare ones worth sharing is the idea that striving for technical competency in QA profession (whether it is required or not) is important from at least two perspectives – company’s and the person’s. In this post I will present a personal position on the matter w/o trying to be objective and / or not giving statistical reasoning / evidence (a.k.a 7 out of 10 QA people described as technical get “the job”). I will touch upon how being technical relates to 7 fundamental principles of testing and provide a list of bugs / improvements that could have been discovered latter or never w/o technical competency from QA.

First, let me mention that when talking to my colleagues from DEV, OPS, QA, Business sides about this very question I got mixed reactions: (i) some attribute “being technical” to personal styles and tastes of each individual i.e. “it depends on the person”, (ii) some emphasize context dependence in testing (anyone familiar with the 7 fundamental principles of testing will know where this argument comes from) i.e. “it depends on where you work”.

I will try to be more general in my thinking as I firmly believe that those two groups are missing the point and will try to state that “independently on where you work (i) and your personal tastes (ii) technical understanding will give benefits as long as it is software quality assurance”. From this standpoint most of the ideas will apply to what is commonly referred to as “business people”, management or any other “department” in software development where technical competence is more of a “good-to-have” rather than “a-must-have”.

Second, the definition of “technical”. I will use the one provided by Joel Montvelisky in his blog post. In short, a person who can dabble in code/configuration files write scripts/tools needed to complete a task and understands the technology stack used to provide the service to the end user. Understanding of the technological side of the project – in contrast to QA specific skills like knowing what is boundary value analysis with equivalence partitioning, risk based test case prioritization, or manual test time minimization through testcase sampling and prioritization. I will contrast a technical QA to a QA that tests from “the users perspective” or only performs “functional testing”.

 

Let me outline the reasons as a list structure, giving explanations for each item in it as we go.

  • Helping others. One of the most important things you will do at work is helping others. Developers often help QA’s with technical questions – be sure to help developers by being technical as well, eliminate the asymmetric relationship, give back. Identify the system component that is broken, do the superficial debugging and analysis. This will save their time. This will engage you in a conversation. This will build a cross-functional team.
  • Respect for technical competency in IT collectives. If one agrees to the benefit of being well respected in an IT field (and most HR people admit that respect is very important) one almost has to agree that technical competency is vital. IT collectives (teams, companies) in aggregate and many individuals independently seem to give almost disproportionate amounts of respect to people that are technical. And since “respect by default” seems to be largely more of an ideal, rather than a reality it will have to be earned.
  • It leaves an impression in the interview. Having been interviewed more than 30 times and having interviewed around 20 people I saw that technical understanding and technical literacy leaves an impression. The more you have it when you don’t need it – the bigger the impression. Can you explain why pre-sorting a list or an array can be beneficial in a search problem?
  • If one gets the satisfaction from discovering bugs deep in the infrastructure, then one should agree on the importance of being technical. What if you worked for a web-hosting company and your company charged by bandwidth consumption? What if you discovered that the packet size was calculated incorrectly losing the company about 5% of profits? Knowing TCPdump would help you here a lot. So would being technical and diving deep.
  • Bug propagation from the “depth” to the surface. Only technical understanding can help you know where the bug arose from.
  • Brainstorming in your team? Then be technical. Increased understanding in both the “how” and the “why” of the product that you are building will help you during meetings when you try to come up with new ideas and solutions.
  • Compartmentalization is artificial… when it matters, at least. As a QA person you will have opportunities where you can improve design, where you can troubleshoot or even fix a problem in the day-to-day work environment – from granting DB access to a DBA (yep, actually happened to me 3 times) to proposing a code level solution to a problem. This is because where real, important, burning issues arise anyone who has a (or the) solution will almost certainly be allowed either to implement it or to participate in the implementation. Hence compartmentalization (QA, DEV, OPS – it will not matter which department the idea will come from) is artificial and hence being technical is muy importante.
  • Working in startups? – technical competency is a MUST. Startups require “wearing different hats” more often than not. Be prepared.
  • Agile testing. When testing is done following the principle of “test as early as possible” QA people will work in parallel with the development team. There will be no formal handovers, no ticket passing from “in progress” to “under test” (or, rarely and it will not be strict)… You will have a separate virtual machine with an instance of AUT/SUT there. Being technical will help you understand when the code does not work and when the web server has issues. Memory leaks? You will not know how to monitor the system and stress it (or soak it a.k.a soak testing) unless you are technical. You will eliminate 50% of OPS and devs work if you know how to go about your code versioning system, your preferred build tool, firewall, do simple database or network administration on your testing environment.
  • You will have to be fast. Being technical helps in getting the job done sooner. Have you ever done text editing by hand for 200 files? Knowing Regex helps a lot.
  • The ability to debug and troubleshoot. I had 2 separate systems where knowing how to attach a debugger, see the exception and the input that produced it helped a lot.
  • Automate regression testing (a.k.a the boring part). Regression testing will never be fully automated (not until we have AI that passes the Turing test and more), but one can minimize it with automation leaving only the parts where human creativity and analytical skills are required.

In conclusion. We can each observe that IT industry can be split into professions that strictly require technical competency and where it is an additional value proposition, a good-to-have. One of these professions – not for the better – is software quality assurance. In this article I first presented this as a problem, defined what I mean by “being technical” and provided reasons for being technical in a list structure.

Let me know what you think about the listed reasons – maybe you have a good one of your own.

 

2 thoughts on “On: being “technical” in a QA profession

    1. I would agree on the distinction. However I would need to then explain the difference in terms btw/ QA and QC. QC is usually classified as a subset of QA, so choosing to stick with the larger category would convey the meaning I was shooting for. Great suggestion, nevertheless.

Leave a Reply to WhoCares Cancel reply