Testing Schools and Organizational Schools

In the last few days an interesting story was started by Paul Gerrard and James Bach as I mentioned in my previous post: Schools of testing, can you decide? The key in their story is the term Axioms. Can Axioms be defined, used and maintained to help us testers? Do we need Axioms? Can we live without Axioms? Or as Paul Gerrard mentioned in one of the comments: Is Axiom the right word?

Paul Gerrard's replied on both postings with a next posting: Schools Out!

With those articles in mind and their comments on user input I thought about it for this weekend. Somehow, I couldn't get it out of my mind. As was I thinking I'm tending to the Context-Driven school as explained in my previous post. Somehow Paul Gerrard's post makes a lot of sense. It makes sense to let us think about. Or even better, force us to think about.

To understand it all better I tried to paint a picture about it. To understand the object to paint I did a quick search on the internet and found these besides other information these sources about the Schools of testing.

Presentation of Bret Pettichord: Schools of Software Testing these schools are mentioned:

• Analytic School: sees testing as rigorous and technical with many proponents in academia;
• Standard School: sees testing as a way to measure progress with emphasis on cost and repeatable standards;
• Quality School: emphasizes process, policing developers and acting as the gatekeeper;
• Context-Driven School: emphasizes people, seeking bugs that stakeholders care about;
• Agile School: uses testing to prove that development is complete; emphasizes automated testing;

On the Blog of Cem Kaner: Schools of software testing these schools are mentioned:

• Factory school: emphasis on reduction of testing tasks to routines that can be automated or delegated to cheap labor;
• Control school: emphasis on standards and processes that enforce or rely heavily on standards;
• Test-driven school: emphasis on code-focused testing by programmers;
• Analytical school: emphasis on analytical methods for assessing the quality of the software, including improvement of testability by improved precision of specifications and many types of modeling;
• Context-drive school: emphasis on adapting to the circumstances under which the product is developed and used;

They already presented the differences between the schools. Therefore I shall not continue in my own view of schools. What could be interesting is the similarity of these schools. They reflect some timeframe of human thinking and approaching the world.

Something similar also occurred in organizational thinking. In Organization theory, a strategic approach, chapter 2 by Narayanan & Nath they mentioning 3 types of schools:

1. Classical theorists
2. Human relations school
3. Early modernists

Short description of the 3 classical theorist schools: Short description of the 2 Human relations schools:
Short description of the 3 Early modernists schools:

To me it seems that history is repeating in small and much quicker in the Information Technology industry. These schools were defined over the last century while our schools evolve in the last few decades. The challenge might be now how to make our schools fit in the Organizational schools. Here I make the assumption that Organization still tending to one of these schools.

To make testing fit and also work in those difference organizations depends strongly on the skills and experience of the tester. As Testing is getting Global and our occupation has new testers and experience testers it would help that we speak about the same thing. And also be able to explain it to the organization we work for.

In this I see at least 2 levels of communication. One is based how we communicate within our community. This can be done by explaining the principles of our schools. And try to work according to it.

Another level of communicating is making the organization understand what we are doing. This should be translated to the "Organizational School" the organization is based on. To translate we have to explain how testing is helping the organization and what we meant with it. If we are able to this we might be able to get the best out of our schools. I think using Axioms can help to explain the organization what we are doing for them and what we mean with them. Picking the Axiom can be depending on the school we tending to.

Perhaps there is some relation to Law's, we have different kind of laws, they all are captured in the book of laws. Only they apply only to a certain area. Those laws are made to communicate to each other and to make sure we are talking about the same.

To write the book of law's related to software testing would be wrong to do. At least now as we are working in a dynamic environment this needs some kind of flexibility. Though, a book or list of Axioms might help to explain to others what we mean with certain terms and how they can help the organization.

Coming back to my initial questions:

Can Axioms be defined, used and maintained to help us testers? We can define them and use them. Only maintenance would be hard. As who should maintain them.

Do we need Axioms? I think it depends on the skill and experience level of the testers and the understanding of the organization of our occupation.

Can we live without Axioms? I don't think so as there are still projects failing based on commitment of organizations towards obtaining their goal of quality understanding and related to that their undrstanding of the need for us tester's.

Is Axiom the right word? I think it is a better word then Law.