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?

 

my end goal: take an average software testers' application for a company and/or project, and it is possible to map those demands/terms of that job opportunity to the syllabus beneath. it is possible to map that here, here or here... and if it can NOT be mapped, then there's still some work to do... (on one of both sides (or both sides)) 

note that: the test syllabus is under construction. 
(and it will be completely in English soon)

click here for full screen view.