At the Agile Testing Days I led a small session at the Open Space day on the relevance of craftsmanship with testing. Simon Schrijver and Zeger van Hese provided me their feedback on the Software Craftsmanship Manifesto as well as the Ethics we came up shortly after publishing the manifesto. When the momentum for this discussion seemed to decrease, the expected unexpected within Open Space session happened. Here is my summary and my thoughts on it.

After having made the connection between the four simple statements that we care, we learn, we practice, we share between the Ethics and the Manifesto, we discussed which of these four statements would be supported by a tester as well. The practicing part seemed pretty obvious to us. Sessions like Weekend Testing, Testing Dojos, or challenges over the internet help us to expose our skills, to learn from our short-cuts in a safe environment, and therefore help us to continue to grow.

The learning part applies similarly. Over the course of the professional life of a tester, we continue to learn new techniques, new technologies, and bring on new tools in order to evaluate the value of a product. We continuously work on extending our knowledge and our skills, so that we can take on the challenges of tomorrow’s world of products. In fact, one thing my father taught me was that he will stop learning once he’s dead. My father was a car mechanic, which pretty much impressed me. He explained to me that the stuff he learned during his apprenticeship years we merely the basis for further learning over his career. He made me understand that I won’t be finished learning once I dropped out of the university, instead I would start to learn at that point.

The third value that holds is the sharing understanding. We share our knowledge with others. In collaborative environments like Weekend Testing, Testing Dojos, or even conferences on software testing we share our knowledge and experiences with others who want to learn. We also build up a community of professionals thereby, as well as a reputation with our customers and project managers we have worked with. We can point out to others we have taught, as well as the ones who have taught us so many things. We help each other grow.

The last of the four values in the craftsmanship manifesto is a bit more diversified. In my opinion the caring part of software craftsmanship also bends if we understand care in terms of providing the right information. By congruently communicating with the project stakeholders, the programmers on our and the product owner we help them to make the right business decision and manage the project effectively and efficiently. Testers help to see the trees for the forest in the tar-pit of modern software development projects (I hope Fred Brooks forgives me this reference to his analogy). Testers are the headlights if we care about our work, and take on the responsibility of our actions accordingly.

That said, Simon suggested to create a tester’s manifesto based upon what not only software testers, but testers in general value. Here is the list us three could compile in the ten minutes remaining. There were two general statements we collected together. The first was

Our product must be safe for our customer therefore we mitigate all the risks that possibly are there.

and the second

We interact with the stakeholder to know what we must test in order to make the product which the customers want.

Beyond this we brainstormed a list of skills and abilities, which I would like to give some thought on here. Curiosity, critical thinking, systems thinking, a critical mindset, questioning skills as well as an open mind with model-building help us to bring in successful testing. We can model the application in our heads while asking critical questions whether the product solves the problem for our customers. We apply curiosity to try out the things that no one thought about before, while still thinking carefully about why a user would indeed do this to the software.

We solve problems not only by providing our customer an insight whether the software is useful to them, but beyond that by solving issues with the software at hand so that we can steadily continue to provide insights into the problems we saw while we tested the program. In this we are independent, so that we decide what we do today, but still having guidance by the project context around us. We are also relying on our independence in the regard to not blind us by the hopes and illusions others around us may have. With this independence we speak freely and we don’t fear the blame of some project managers. Instead we seek to understand not only the program at hand, but also the mood of the people we are working with, and why our bad news might upset them. In this we learn how to think empathetically so that we understand others around us.

We are eager to learn new things about testing, but also about the program at hand. We continuously improve ourselves in order to learn new things about that may help us be an even better testers. We build a reputation by providing our service to the project and the project team. We help them by articulating our ideas about how to improve testing, and gain more information. We seek hidden relationships and assumptions in order to understand how to test the program best next, and to see what the biggest area of risk for our customer is at that time.

We are willing to discuss problems and issues we found, so that we can provide the value our programmers, our customers and our companies need. By educating other we help not only them, but also ourselves, since teaching provides a major source of knowledge for the student and the teacher. Thereby we make others grow so that they will outperform our abilities one day. This does not mean that we don’t know who we learned from, quite the contrary. We point to others that taught us the skills and knowledge we have today. Thereby we give credit to the ones who provided their guidance to us in order to become a more professional tester today.

I really hope to extend this list based upon feedback. I would also love to see the missing connection to the software craftsmanship for me – but maybe there is none.