Testers Knowledge Accommulation & Tracking

We are putting too little effort in knowing what knowledge we have, and what knowledge we should have in the future to cope with emerging technologies.

As systems get more complex, and we are facing systems of systems, and as the knowledge we are required to know is growing (demand of the companies as a direct demand from the systems), we are about to witness a knowledge crises with testers if we do not respond. The future tester, as I wrote in one of my presentations to a European conference, is going to be more multidisciplinary, and know more of different topics (i.e. project management, product management, risk management, system architecture and design, etc'). So in order to be that person, we should educate ourselves, and be prepared.

Having said that, you have many courses existing today on all areas. It is a matter of budget and priorities for the the manager where to send his/her team to.

I use a simple matrix to track the knowledge of my team of testers, and it helps me also know where I have an "exposure" or a risk in the future test design, infrastructure administration or anything else I choose to track and direct the training and education efforts to:

The matrix helps me to identify the testers who learn faster, the testers that have little knowledge about something, and the exposure I have in dealing with complex test design and execution. It brings out the best out of people that can learn individually, and let them have further topics of knowledge to study on. They have to present what they do once in a while, and that brings more responsibility into their work, and of course satisfaction.

I can also identify problems using the matrix: personal gaps of knowledge (i.e. Ruth is no expert in any topic), and project gaps of abilities (i.e. no one has done test design more than once on Appl#2).

Professional knowledge is power, and we testers should realize that lack of that knowledge is our failure to face the future of our profession.

Alon Linetzki

Best-Testing

Legitimacy to Test An Application Domain

12 years ago when I have trained a group of testers for one of the banks, a guy stood up in the middle of my testing course, and told me: "Do you have an economics degree?". "No." I have answered, and he continued: "Do you have any formal education in Finance at all?". "No." I have answered, "not formal". Then he said:" Then why should I give you a job testing my financial systems?".

That was a legitimate question, and on the break I have answer that "I do not have a financial degree or any formal finance background, but I have tested such systems (as they have) in two different banks in the last 2 years. That answer satisfied him well.

My point is that we are asked to test complex application domain systems, and sometimes (or many times) without the domain knowledge. Is that legitimate from a company to hire only testers with domain knowledge? or it is not? Can we test well enough, while not possessing the domain knowledge?

Let's take as example. A health care machine like CT, that has an analysis module analyzing the brain slices (pictures) - is that OK to test without being a doctor? I mean the user is a doctor, and we always take the user point of view in our end to end testing.

And, it experience is accounted for, like in my example, than when can we have the first experience?

Life tought me that the simple dynamics is that within a team there is at least one person that knows alot on the application domain, and a few others that learn from him/her. That is the case in most projects I have encountered. Some companies would not hire a tester, but rather hire someone that possesses the skills of the specific applcation domain (i.g. flight engineer, pilot, etc') and train him/her in testing skills.

I guess to summarize the discussion - it depends on the application domain and on the complexity of the system or type of system we must test. The fact that lives are at stake (mission-critic systems) could matter as well for making a decision as a test manager of that company.

Who says testers needs to know programming?

In the last couple of talks I had with a few testing colleagues of mine, I found out that some persisted that testers will be trained in the future with programming skills as a must in their portfolio. They presented a job activity request that testers will be engaged in code inspection, in root cause analysis of problems in the code and finding patterns of problems in the future. All of that plus test automation in code level.

Are we or should we go into that direction? Maybe: we [testers] are known as people who like to know more, want to find how to break things and build them better [improving processes]. But, the simple truth is that we are also interested in systems thinking and systems view, and NOT going into code is something I saw attracting testers into the profession many times in my career.

Testers are specializing in systems testing; they are familiar with the system architecture, requirements, and studied the processes and end to end scenarios that are possible from client perspective - all clients profiles are relevant not just the ones that are most common. So, I can say that these testers are not less professionals, representing the client perspective, are capable or testing the product with its many aspects.

Do we need to go into a future where every tester needs to know programming? I do not believe so. But, we should have some testers do that – I suggest they shall be the ones having the most technical tendency. Some others with a more process orientation, and wide system view should keep on doing mainly what they have been doing so far – kick the hell out of the system’s processes.

So, to summarize our discussion (or is it just a beginning...), in my eyes we shall probably need two kinds of testers in the future:

Technical approach – a tester that would have to know code, be involved in a more close relationship with the developers, knows how to read code, and try to influence developers in testing better (with their code).

Customer-like approach – a tester that would have to know the product on a super customer level, knows the different architecture and design aspects, the end to end possible scenarios or customer stories, that the customer might exercise with the product.

Both approaches may be going hand in hand, enableing us to get from detection to prevention when exercising the testing profession.