My Testing Manifesto

Introduction

I read. I read an awful lot. I read books, I read other blogs (most of which seem better than my attempts). I read articles on the agile space. I read developer articles. I read articles on test automation. I read a lot of articles on testing. I read twitter vignettes. Each thing I read I attempt to apply my critical thinking faculties. If a definitive statement is made I look for evidence. If an opinion is particularly strong I try and analyse it from their point of view. I agree with a lot, I disagree with just as many, but it's twitter, it's linkedin, it's medium, it's dev.to. They aren't platforms that encourage meaningful, in-depth debate.

Sometimes I find that I have a bazillion little voices in my head all vying for attention at once.

It can be exhausting attempting to quiet each idea so that I can focus on a particular thread that I'm interested in exploring at that particular time. I do this so I can incrementally improve my understanding of testing software and what that actually means in terms of adding value to the development effort. Whether that's challenging my preconceptions or facing my inherent biases. I'm not immune. They lurk beneath the surface, scheming in the background to skew my perceptions in favour of that with which I already agree with. The only saving grace is that I'm aware that this is happening so I can mitigate them to a certain extent.

So to help organise my thoughts, I decided to note down those things that I felt mattered to me in the testing space.

My own, personal, testing manifesto.

My values and principles are not binary constructs. They are not either/or, they are not yes/no. For example, I place skilled application over robotic application. It doesn't mean that I dislike automation, it doesn't mean that I don't think automation has a valuable place in software development. It means that I place more value in communicating the 'what' over the 'how'.

You may place different priorities on my things, which is as it should be.

What is a manifesto?

In its purest sense, a manifesto is a public declaration of intent, policy or aims.

I'm aware of these manifestos:

Agile manifesto - The grand-daddy of software development manifestos (as far as I'm aware). Much maligned and much misinterpreted. Hugely effective when implemented in the spirit in which it was created. Not so effective when it's used as a stick to beat teams into submission.

Testing manifesto - I remember reading about this a while back. It must have lodged in my brain. Concise and to the point, it definitely influenced how I thought about testing.

Modern testing - A creation of Alan Page and Brent Jensen. Highly recommended as a primer to articulating the role of testing in a software development environment. The beauty of this is that the seven principles can be applied in any testing model. It's not just for a team implementing an Agile model.

My Manifesto

I started off by listing values I strongly agreed with. From these I could form the principles that supported the values. The values I came up with:

• I want to provide value through my testing efforts.

• I want to expand my thinking.

• I want to continually improve.

Each principle was chosen to address a specific aspect of how I see myself and the value I bring to development teams. They aren't set in stone. They are open to modification as I gain new information.

I value those things on the right but I value those things on the left so, so much more

Questioning over compliance

I see a fundamental aspect of a tester of being an agent for change. There will always be an aspect of going against the grain to affect positive change, whether that's how people think about the impact of their mindset towards a quality goal or whether an automated suite can be optimised to provide useful information. Compliance in everything, at all times, can lead to apathy. I'm not in a team to fill a seat. I'm in a team to be a voice for the user, I'm in a team to be 'that' person.

Challenging over acceptance

I have two possible takes on this particular principle.

I think challenging accepted norms should be the default mindset of any skilled tester.

I think challenging opinions leads to progress, even if the resultant doesn't change the outcome. At the very least it forces others to articulate the *why. At the very least it forces me to internally articulate my approach.

Critical analysis over a quiet life

I cover critical analysis in more depth here. I've always advocated for critical thinking of claims, whether that's individuals, requirements, assertions or features. It's probably the single greatest improvement a tester can make in their professional development. The added bonus is that critical thinking not only adds value to a testers engagement with their team but it can also be applied outside the work environment to great effect.

Skilled application over robotic implementation

I firmly believe that a number of orgs see automation as the key to quality. Intelligent implementation of automation can contribute to a stated quality goal. I believe that automation used at the right time, for the right reasons, in the right context is invaluable as part of a joined-up, quality-driven approach. I have real issues with an 'automate all the things' mindset. This isn't just aimed at the toolset area though, this extends to unthinking script-oids that churn out factory test scripts.

Useful collaboration over tick-boxing

Useful collaboration involves taking the time to actively critique existing processes to identify if normalisation has happened. By tick-boxing I mean by-rote. Those activities that are regularly undertaken and become part of the furniture, they become a done-deal. I think that this approach can lead to fragility, whether it be the critique of expectations, the deployment model, the contribution to ceremonies, or my own, inbuilt acceptance of how things are. I choose useful collaboration.

Agile mindset over death by process

The Agile movement, as codified in the manifesto's values and principles, has at it's heart, an underlying mindset that expects an open attitude toward software development. In-place and accepted processes should be tested just as much as requirements. I see one of my hats as being the teams conscience, even when the team is delivering at a consistent velocity, even when the team is delivering to a consistent quality. Constant inspection and adaptation allows me to retain this agile mindset and communicate it to the teams via whatever method works at the time.

Empathetic debate over refusal to acknowledge differences

Empathy is an absolutely vital tool to employ when discussing differences. It's important to understand that other team members opinions on quality are just as valid as mine, I don't hold the keys to the kingdom, nor would I want to. I don't always agree with team members, I have a different perspective on quality matters gained from hard-worn experience. By the same token, they will also have a different perspective. Differences are a good thing, differences are a needed thing, differences ensure that I learn something from each encounter. I celebrate these differences. It's not always easy, one of us may be having an off-day, I may be under pressure to just accept an opinion so that the team can move forward. It's still important to recognise and empathise these differences.

Soft skills over technical skills

I discuss the importance of soft skills here and here. Technical skills have a relatively short period from novice to usefulness, technical skills are organisation dependent, technical skills can change overnight as a result of a shift in focus from stakeholders, technical skills are (usually) misunderstood by stakeholders outside of the immediate team. Being able to actively listen, discuss and debate ideas with team members will never be dependent on the org, the tech stack or in-vogue toolsets. Soft skills are infinitely transferable and work at all levels of stakeholders and in all situations where there is a potential for misunderstandings.

Creating opportunities to find defects at every stage over coding the way to quality

This is almost analogous to the next principle. Writing production code is a single, involved activity amongst the numerous activities that make up a product delivery cycle. I don't focus solely on finding defects in production code, either via test code or via exploration of the product. I refuse to be a passenger. Exercising my critical faculties and injecting considered queries from the beginning of the process is not an optional activity, it is a required aspect of my value to the team.

Exploratory over scripted

Where exploratory testing absolutely shines is where I can exercise the product and where I can utilise my experience, my oracles, my learning, my heuristics to gather information and present that information to my team and stakeholders. I can advise on impacts and risks to the product as they relate to the information I've gathered. Some of this information may be unanticipated behaviour which could be interpreted as a defect. That's not where exploratory testing shines. It's an information gathering exercise. Scripted activities have value. If a numeric calculation is undertaken, 2 + 2 == 4 is never going to be based on opinion. A + 2 will equal an error. They are facts governed by the mathematics. You can have scripted activities that don't utilise the same test data. You can have scripted activities that conform to a regulatory requirement.

Users over stakeholders

Stakeholders usually have a limited view of a system. They may have biases and incomplete expectations that stem from budget, anticipated demand, shareholders expectations. The ultimate arbiter of whether a product is fit for use is the user of the software. We are all users of software, we've all been frustrated with software at some point in time. I believe that I should think like a user at each phase of development. I don't need a GUI to frame the user experience, that happens from the very first backlog session.

People over technology

This is my own particular hill I am prepared to die on. People create the software, the technology is the medium. Without the artists inherent skill and talent, no amount of paint and canvas matters. What is often overlooked is the fact that people were instrumental in designing the very technology I rely on. Every technology in existence was seeded in the mind of a person. No technology I'm aware of has the ability to extract the sum of past experiences, no technology has the ability to react to unanticipated events. People, with all their quirks, opinions, wants and needs will always be paramount when developing

software.

Conclusion

I want to learn all the things. With this grand idea comes it's own difficulties. I needed a way to organise all the ideas that stemmed from the influx of this information. I decided to create my own testing manifesto. Each idea I have has to align with one of these principles. If it doesn't, I can discard it or otherwise store it. I can revisit it in future. Creating my own manifesto has helped me organise my ideas and my beliefs. It's also been encouragingly cathartic. It's also helped shore up my approach to testing in all it's varied forms.

It's about giving yourself a chance.