- “In which cases would you use edge or border testing?”
- “Could you provide an example of a negative test?”
- “To apply to this job, you must have solid knowledge on automation tools.”
- “We are looking for someone with communication skills, since they will have direct contact with clients.”
And so on. Companies require very specific skills from applicants and ask lots of questions before hiring someone for a big project —with the client you always dreamed of. Once hired, you believe everything will be as you anticipated: for a junior employee, it’s time to learn from the best, and for seniors, to show what they’re capable of.
A Quality Analyst in the Stone Age
Let’s consider one of those traditional, vertical companies with testing teams of different levels of seniority in charge of assuring that the product in maintenance doesn’t crash. After using the same technologies for years, the only thing such companies want is for the software to be stable in order to keep making profits. In the end, the product is an image of Fred Flintstone holding an iPhone in his hand: outdated but embellished with some degree of innovation.
The skilled testers hired for the job think they will start working with the best technologies and processes available, which would explain why the company required that level of experience and knowledge from them. Once they’re in, the situation is quite different. If you’ve ever worked in a company like this, the following exchange will seem familiar.
Old QA: “This is a known issue, it was reported back in 2015.”
New QA: “Ok, what about this? We are getting three pop-ups in a row, one after the other.”
Old QA: “Oh yeah, that’s normal.”
New QA: “What about this field? It’s for e-mails and it allows to write more than 30 characters.”
Old QA: “We are aware of that too, but it’s not for us to solve.”
What could we recommend someone thinking of working as a quality analyst in a traditional, vertical company? If you’ve already been in this situation, you know what we’re talking about, but if not, we will outline what you should consider before taking the leap.
- There are long and detailed processes for management tasks: you might encounter this kind of processes, which usually cover the same issues over and over again and prevent you from focusing in more productive work. Nevertheless, it helps you understand the fundamentals of management tasks, in terms of form.
- Lack of access to the source code: it may be the case that development and testing teams aren’t located in the same premises, so quality analysts will have to be more technical-specific when describing the issue, or even create themselves the build process of the version they need to test. However, their curiosity and willing to know more can make them approach white box testing.
- Prioritization of issues: this is where it gets complicated. Apparently, not every issue is an issue, instead it can be: a feature, an expected result, a minor bug, an issue that’s beyond reach and, therefore, put in an endless waiting list. In this way, the perception of what’s right and what’s incorrect gets distorted.
- Finally, you must understand that the client decides on the product’s quality: as much as we would like to have a perfect product with high quality standards, the truth is that the clients will always have the last word before a release.
Although being part of a conventional company may look alluring due to all the years they’ve been in the market, sometimes they aren’t flexible to changes, technology migrations, new challenges, or growing horizontally. For such companies, what works today is enough. It’s always advisable to put everything in the weighing scale and get perspective about the type of company each professional wishes to work in.
In the end, the quality analyst is where the center of the action is.
And there, less is more: less bureaucracy, more quality.
Less Fred Flintstone and more intive-FDV.