Is testing merely a means of identifying bugs or maliciously attempting to compromise developers’ creations? Is it merely an entry point into the IT sector for those lacking programming skills? Can anyone truly perform this task (and perhaps not even require expertise)?
Software testing is a field with a number of misconceptions, many of which are deeply ingrained. On the other hand, there is a lack of awareness about what it entails. When I started as a tester, I was more often asked “So what do you do?” than congratulated. To be frank, it was often easier to respond with some of those clichés, as much as people in the industry like to roll their eyes at them, because they provide a general idea to the layman. Nevertheless, our day-to-day working reality is often anything but trivial. However, IT is a huge topic today, and people from completely different fields, including non-technical ones, are drawn to it. Even among my colleagues, there were those who required more detailed explanations about the process of identifying and rectifying errors. So, what am I doing?
If you have been interested in this topic for some time and you are not a stranger to the concepts from the world of software development, Honza has already written a great article about the role of a tester in a Scrum team. However, as a person who a few months ago had concepts like Scrum, Agile or regression testing in my (self-)study curriculum, I would like to take a few steps back, define our work a little bit more and dedicate this series of articles mainly to people who are just thinking about a career in software development.
A tester is essentially a quality controller who is also directly involved in the final level of the software. In a broader context, the process is about ensuring that the final software meets the customer’s expectations. In sub-details, we then break down the above definition into individual procedures and competencies falling into different phases of the software lifecycle. It is important to note that the act of probing the software with the intention of identifying potential issues is only one of the many tasks that testers are responsible for. Among the steps that precede or immediately follow this, it is often the less essential one. Indeed, the probing is only beneficial if the tester is aware of what they are probing, why they are probing it, and most importantly, if they understand what such probing is (in)intended to elicit. In other words, a tester must first analyse the input requirements for the functionality they are testing in order to conclude whether the real implementation meets these requirements.
The testing process is not an ad-hoc approach to modifying the user environment of the software. It is based on a structured set of formal test scenarios created by the tester based on the analysis described above. Ideally, the development process should commence before the code is written and the requirements and acceptance criteria for the functionality (or “feature”, if you prefer) are validated. This ensures that the programmer does not have to deal with an impossible task or a solution that may cause problems elsewhere.
Just as we base our testing on some formal documents, the conclusions of our work must of course be recorded in some way. The most eloquent example of such outputs are the reports on any errors found, which must be just comprehensive, specific and understandable enough to allow the developer to locate and fix the problem. It is not possible to know where the bug is in the code by test work, such magic is in the hands of the developers. Our job is to identify that a given functionality (or the whole application in general) does not behave in accordance with the expected result from the end user’s point of view and to record this split accordingly.
The scope, types and focus of the tests are planned based on an analysis of the project requirements (technical or personnel) and the risks associated with them. These are matters that are more competently assigned to senior test managers. However, it is not uncommon that a line tester may also be required to participate. A significant aspect of the role is the creation and maintenance of automated tests. In most cases (although not always), this requires at least a basic knowledge of programming.
This brings us to the oft-mentioned thesis that the term “tester”, while perfectly standard and certainly not pejorative, is slightly unfair to us because it in a way downplays what our job entails. Therefore, at least internally, terms like software quality (assurance) engineer are often used, and I hope the previous paragraphs sufficiently illustrate that it’s not really just because it looks better on a CV.
Well, we have a cursory idea of what the SQA job entails “on paper”, so we can start talking about what is (not only) expected of newcomers, what they can expect in their position and what they definitely can’t do without in their job.
But more on that next time.
