The Testing Myth

Une civilisation débute par le mythe et finit par le doute
Emil Michel Cioran – La Chute dans le temps

The question comes again and again, and it looks that it never will stop. What is testing? What is a tester? What is the ultimate goal for the tester? What is the goal of testing? This post is about the testing myth.

What is the tester?

A tester is the person who knows and understands the application.

The tester understands the business expectations, and has an overview on the technical implementation. A tester is “the” person that foreseen all the business/technical impact on the application, the tester will remind any impact that none team dreamed before : the business stake holders will ask him and listen him, idem for the developers, they need to be assured which component/s will be impacted with this new feature. Frequently I think that the tester is the “The Keymaker” on Matrix, he is not the architect or developer of the system, but he knows all the back doors and all the keys to the system, you can ask him any shortcut on the system, he will provide you the key and the exactly door

The Keymaker : There is a building. Inside this building there is a level where no elevator can go, and no stair can reach. This level is filled with doors. These doors lead to many places. Hidden places. But one door is special. One door leads to the source.
The Keymaker : Only the One can open the door. And only during that window can that door be opened.
Niobe : How do you know all this?
The Keymaker : I know because I must know. It is my purpose. It is the reason I am here. The same reason we are all here.
Trinity : Where are you going?
The Keymaker : Another way. Always another way.
The Keymaker : If one fails, all fail.

What is Testing?

Testing is the effort to become a tester.

If at this line you think that the previous sentence it’s wrong because I didn’t mention “quality” or “bugs” let me complete the thinking. Understand all the complexity in a evolving systems requirements, the resiliency and inertial of the application, all the teams, systems, variables, configurations and actors involved in the ecosystem make the task more difficult. But not impossible. Accomplish the full understanding of the system requires a methodology, a conceptual framework that will help the tester to … become a tester. The result of all this activity is the improvement in the reactivity of the team to search the quality, find errors and avoid them.

What is a test?

Is a an statement that is a thesis for the user, and an hypothesis for the tester.

The test is dynamic, transitive and deterministic point of discussion between all the actors, and enrich the communication between the members of the team. Has a value like a document about a small part of the application. All the tests of an application, are intended to describe the complete functionality of the system. In theory, if you give your set of test to any person, he must be able to understand the expected behavior of the system.

Try a shot! if a new member arrives on your team, give him/her the test set of your application.Ask a feedback about his/her point of view of the application after reading the test. Use this information to fine tuning your test set.

Myth #1 : Testing will provide quality

Quality is not provided for the Testing activity. Can help, and is true that is an important factor to achieve quality, but the quality is inherent to the application and all the actors involved. The challenge to the tester is help proactively to the team to find and avoid bugs.

Myth #2 : Testing will fix the system

Systems with severe quality problems, frequently, are because the cause of the problem is structural. And structural problems require structural solutions. Provide a testing framework (methodology and tools) is part on the solution, and the applicability depends on the test maturity of the team.

Myth #3 : My developer team has unit/integration tests, this is my testing framework

Unit testing are important in the verification of unit functionality for evolving code, and will help to redesign and assure about the impact in the different method and objects of the system. Integration testing, in the same way, will do the same, to validate the interaction between different components. But this is not a testing framework.

A Testing framework is a set of a methodology, description of process and interactions, conceptual definitions of about the “quality”, “incident”, “bug”, “priority”, etc means for an application, qualitative and quantitative indicators… and 1% of tooling.

On another hand, there are a lot of different kind of test to perform : functional testing, performance testing, load testing, monitoring, etc,etc.

Myth #4 :We don’t need a testing framework

I must admit, that after working 15 years on testing, I love to work on projects with this mind set. Is a beautiful challenge to convince people and organizations, break paradigmatic paralysis and show the benefits of testing like a catalysis in the search of quality.

Myth #5 : We do DevOps : Our testers are our developers

DevOps is a healthy evolution of Agile. In Agile that I practice 15 years ago, they forgot functional/performance/load Testing in the iteration, they forgot also to involve another key players on the iteration. In Agile approach they are limited only to unit/integration testing in the context of Continuous integration. DevOps is a proposal to enlarge the circle of teams not only for the testers, but also another players like infrastructure, data base engineers, architects, etc .

There is a misunderstanding on the conception of DevOps, to suppose that developer will take the place of the testers and everybody else.