Software Testing Through the Eyes of a Newcomer, Volume II.

"Learn, learn, learn."

Domain knowledge, technical skills, soft skills, ISTQB certification... What are you looking for? What can you expect from your job as a software tester? And do you need to know how to program? So many questions, and so little time.

Before we begin, it is important to note that the objective of this series is not to provide absolute truths about the testing universe. Instead, it aims to introduce readers, through the perspective of a novice in the field, to some of the challenges commonly faced by those entering the IT (and specifically SQA) sector. These challenges are not limited to financial considerations, but also include the physical and mental demands of the role.

But now to the point - admittedly, I was originally going to kick the topic off elsewhere, but Google has a clear idea of what people are most interested in.

Does the tester need to know how to program? A burning question, and a potential "blocker" for many people who rush into SQA without a technical background. The short answer is, "They don't have to, but it's damn useful." Let's not get into debates about whether automated testing can (or should) replace manual testing at all - I don't have the knowledge. But whatever the future brings, manual testing is definitely not facing a heartbreaking sunset for now, and it's possible to work in the field without knowing any programming language. I am an example of this myself - I didn't start learning programming until just before I started working (honestly quite intensively).

During the first few months, I was able to avoid the necessity of writing any code. There was no pressure to do so. However, I was immediately convinced of the appropriateness of this step (and the faith with which I took it) by the fact that every colleague I met during my first few days on the project, within the first few small talks, asked me if I knew Python.

Take it as you will, sooner or later you'll come across a situation where even a basic knowledge of coding will at least make things easier. For my part, I'll add that learning programming is an extremely fun (however frustrating at times) activity, so I'd like to challenge you - even if strictly speaking you don't have to, try to sit down with a good course and go for a bit of luck.

Please note that if you are struggling with the language of the text in the attached image above, it is likely to be a greater obstacle to your potential career in SQA than not knowing programming languages. English is an essential skill for this role, and my experience is that you will need to write at least formal text output such as test scripts and bug reports in English. Even if you are fortunate enough to find a position where you are not required to do so, it would be to your disadvantage if you did not at least attempt to develop your passive comprehension abilities. There is one certainty in working at SQA: you will have to learn something new on a regular basis.

Luckily, nowadays we have education of the highest calibre at our fingertips online, often for free. However, it is important to note that the majority of excellent educational materials are in English. From my perspective, knowledge of the language is not a valuable asset, but rather a prerequisite. It is unlikely that every company will have a different perspective on this matter.

But what ultimately makes one a tester, that imaginary grail of knowledge, is twofold - in general terms, it is knowledge based on the International Software Testing Qualifications Board (ISTQB) certification curriculum, which is then applied in a specific way with the domain knowledge of the project you are working on.

The term "domain knowledge" inherently means something completely different in scope and technical complexity on each project, and in a way we defined it last time. But for the sake of clarity, let's reiterate that a tester has a responsibility to understand the software they are working on - not just in terms of where what is, but how it works. What we didn't point out last time is that if you're testing, for example, software for controlling electron microscopes, you can only fully understand how it works if you know what's physically happening in the microscope. And as you can probably suspect, this rabbit warren leads to the need to have at least a basic understanding of electron microscopy in general.

If such a prospect scares you, me- a notorious self-doubter - I admit almost throwing up from nervousness when I was told that I would be going on such a project.

But as the saying goes: "He that is afraid of wounds, must not come near a battle." Don't be afraid of challenges. While I often struggle with it myself, it's important to remember that no one has an a priori interest in throwing you somewhere only to have you fail, and everyone on the project knows how steep the learning curve is for what's in front of you. And while I'm personally not a big fan of the saying there are no stupid questions, I had to calm myself. Because what is crucial is indeed to ask right questions.

If domain knowledge is a kind of variable, the ISTQB certification syllabus is a constant that you simply cannot do without. I am deliberately talking about the material on which the exams are based, not the certificate itself.

It is important to be aware that the ISTQB core level (CTFL) is a fundamental requirement for those working in the testing profession. The CTFL syllabus is widely regarded as the industry standard and is likely to remain so in the future. However, it is also important to note that the difficulty of the exams themselves is artificially set by rich verbiage and practice problems that are often more challenging than anything you will find in the official materials. We will discuss the requirements for studying for the certificate and the exam itself at a later date (ed. note - spoiler alert!). For the moment, it is important to note that the information conveyed by the syllabus is essential for working in SQA.

And what about the certificate? I didn't have one, and I got the job. But I have two very important footnotes. Firstly, unlike programming, I had already been ordered to get this, so successfully obtaining it was one of the conditions of surviving the probationary period. Secondly, despite having escaped into software testing from my shattered dreams in digital illustration and translation, I joined the current Pactera (then VanceInfo) in Beijing, China, in the summer of 2011 as a localization quality assurance tester, and cumulatively spent more than five years at LQA with a few breaks. And despite language localization testing being dramatically less technically demanding than SQA, functionality testing was in our job description there as well.

Retrospectively, it is clear to me that when I started, we had been trained for a week on materials that were suspiciously similar to those from ISTQB. Long story short - it's safe to say that when I was interviewed for my current position, I already knew a bit.

On the other hand, my first project at SQA, I also personally met testers whose backgrounds were free of any certifications - no previous experience, no certification, from a completely unrelated (and on top of that, non-technical) field. They were given the chance anyway, and they do a great job. However, in their case too, the company (the customer I was deployed to as a freelancer) required proper formal training in the form of CTFL.

In a roundabout way, I come to the characteristic that no tester can do without and which is the most essential prerequisite for everything we have talked about so far. It is the willingness to learn.

It must not be an empty phrase for you to hear in an interview. You need a real desire to improve, to work on yourself. Humility in the face of what you can't do yet. Not to be bitter about how much you have to learn, but rather welcome the opportunity to push yourself further. Where and where exactly can a career in SQA go? Stay tuned for the next episode.

In the meantime, keep working on yourself so you not only take an entry-level small step into the world of IT, but also so that you kick out the door.