If you want to talk about software testing, there are a couple of things you need to understand.

A tester on a project is in need of certain skills and knowledge. If you want to learn more about it, take a look at this page.

Notice where the ' Tools' sections is located!

Those tools are used at several layers of the test pyramid.

They can be aimed at UI level (Tosca, Selenium, Robot FrameWork, etc)
or Service Tests level (SoapUi. etc)
or unit tests level (..etc...)

Those tools have different kind of 'Programming experience levels needed'

Some tools you DON'T need any programming language experience at all.

Some tools you can work with if you have a little bit of programming experience.

Some tools you can only work with if you are very EXPERIENCED with programming languages.

You also got to understand, with some (framework) tools where you need a little-bit more then average programming experience, they can be used with several different programming languages as the basis:

That is not all. The knowledge you need about using the (framework) tools can be divided into sections:

first:
You need knowledge to know how to find the web elements, by means of RegExp, name, ID, Title, or CSS or XPath.

second:
(in some cases) You need knowledge about OOP.

third:
You need knowledge about the used programming language in general.
(Which is in it's turn actually a whole different world of knowledge on it's own and a "15 levels deep presentation" in Prezi.com worthy... click here for a basic overview in this case C# as an example,
And if you know all these basic C# things, then that doesn't mean that you know what .NET is, which is in it's turn.. well you guessed it... but click here if you still wanna dive deeper and get a headache because of an information overload.)

fourth:
And then you need the specific knowledge that is test automation related like how to give arguments, how to use the web-driver, how to use Docker with the automation etc....


Tip! as a recruiter/job interviewer: specifically ask questions in those 4 sections!! example: what is your knowledge about locating web-elements with test automation? (or OS winforms elements in case of a Windows application of-course)

So you see... although 'Tools' is only a small sub-section of what a software tester comes across on a daily basis (the complete picture). The whole understanding of using those 'Tools' is a complete world on it's own regarding the knowledge about it.
(Imagine: if it was a Prezi.com presentation we would have been 10 levels deep under/into the green arrow section by now...)

So in case you are providing a job opportunity to a software tester, make sure you prevent them from having to ask questions like:

-What are the programming languages used on the project (in general)?

• Can I view the current code(base) as a software tester? Can I also push commits and contribute to the codebase?

-What are the tools currently being used? oh is it Selenium? is Selenium used with Kotlin?

-Oh only a low-code automation tool is used? What tool is it? So does this mean I don't have to have programming language experience?

-Oh Okay Selenium with C# is used? Do I have to script taken into account OOP?

-Are there currently tools used on the integration level of the test pyramid?-

What is the balance between the test effort I have to put into 'Explorative testing' vs the 'automation' part? oh 75% Explorative testing aha okay.

-How many other testers are on the project? What is their level of test automation knowledge? oh very inexperienced, they don't have any Kotlin knowledge... aha okay...



Software testing is already difficult as it is,
so please provide as much information as possible in a (online/digital) test job opportunity!
("even if it looks obvious to you, but not every other company also uses Java!")

After-all 'time=money' and if a candidate comes to a job interview and it was completely for nothing then it's a waste if the answers of those questions could have been given by forehand.

Or even worse: they don't get asked at all and when time passes by it gets clear that a candidate has too little of the knowledge that is actually needed at some or several levels.

Also: (and this can be a little-bit contra-dictionary after reading the text above) remember that not everything is about the tooling aspects. If you have someone with super duper test automation knowledge, but he can't find a descent bug... I'd rather have testers that are great in discovering the BIG bugs, right?

So now you have some guidelines for the job description and the interview and hopefully a bit better understanding about software testing in general.

Thank you!

In software testing it is important to understand that changing something in one place, can create a bug somewhere else. I always see the 'Newton's cradle' in front of me when it's about this topic somehow. 

Lately I saw videos on YouTube about the UK post office Horizon scandal. I watched 2 actually.
This one and this one.

​I had a lot of thoughts when watching these two videos. 

We life in a digital world and there is a lot of digital crime helaas.
When we go to the airport our luggage's are being scanned. There is a lot of monitoring going on. Of course, this is needed, and we all understand that. 

We also know that in this digital area we are in, there might be some monitoring and control going on that is not just as easily visible to civilians as can be seen on the airport. 

Still those systems have to be tested. (as a whole, or as a test object)

So the question is: is in all the cases that you, as a software test consultant, are on a project, all of the code presented to you? Do you know about all of the functionalities that exist?
Are some (parts of) the code maybe restricted (for only certain people)? Or maybe not even visible at all?

I think that with some software it is the case that not every developer can view the code, not every developer can make adjustments, inherently not every software tester can test with the full knowledge, or full scope.

This means that it is possible to create a test plan, or a test strategy based on the code or functionalities that you do know of that it exists. 
But you cannot create test cases based on functionality or code that you don't know of.​

I think, sometimes when you want to do a bug root cause analysis, it is important not to have a tunnel vision (or narrow minded). But try to keep thinking outside the box. Maybe there is some info missing? People tend to have biases. 

In case there is some code that can only be viewed by certain people, and in case that there is a bug found in specific that section.
Then who's responsibility is it to check that there is not a 'Newton's Cradle' effect in the "visible for everyone" code section?
Who is going to do the regression testing of the complete system?
Who is going to do the integration testing of the complete system?

What happens if the not-hidden code is ready to go into production and online, but changes in the hidden section actually cause some counters to malfunction?

I think it can make the testing (process) very complex from time to time. Even opaque.

You don't want that the testcases of the "visible for everyone to see code section" turn up green(passed).
Whilst if the "confidential section is also taken into account they actually turn up red(failed).

Is it even possible to communicate clearly about all these things always?

 

It seems like the understanding of ChatGPT is that 'testing', as done by a human, can also be done (act of examining) by a tool....
I have to admit it got a bit better after giving it a couple of feedback rounds (3)

I think I made it finally too difficult for ChatGPT:

Ultimately I asked: