Hi, I’m Patrick and I’m a tester for 18 years now. And I have a problem: I don’t care about testing! I care about Quality! Yet people see and treat me as a tester.
I have to add, that I don’t like testing, as many people see it. And I don’t do testing as most people do it. Most colleagues I have worked with over the past two decades see testing to verify functional correctness and sometimes even conformity with some non-functional requirements, such as load and performance.
My understanding of quality starts where most colleagues understanding ends – when explicit requirements are met. I see quality more like Joseph Juran defined it: “Fitness for use”. And the additions that have been made to Jerry Weinberg’s “Quality is value to someone who matters at some point in time” are very helpful in understanding the flow and continuous urge for adaptation when thinking about quality from my point of view. More on that in a later blog post.
Testing as an activity and my role as tester, especially as test automator, are for me the best means and position to influence a project’s and product’s quality. As long as you don’t put me in the waterfall-ish place after development finished and before delivery/operations and expect me to stay there! I’m usually all over the place, wherever people let me.
I couldn’t care less for approaches like decision matrix, boundary value analysis, path coverage, etc. Probably either because I learned about them in a formal way already in 2004 and have them internalized by now (I never explicitly use them!), or because they are the formal explanations of what I usually call “common sense of a tester”.
Tasks like “Test Analysis”, “Test Design”, “Creating test cases based on requirements” is something against my personal nature. I’m so much driven by the problems in front of me, the context I’m in, the problems that need to be solved, the things I’ve seen, explored and sensed, that coming up with “a full test set” up front, is just not my style of working.
Quality is relative, quality is in a constant flow, quality is highly subjective, quality is everywhere and nowhere, quality can’t be predicted, quality cannot be put in numbers. And that’s why my style of “testing” follows the same behavior. I just cannot reduce my work to writing and executing test cases. I just can’t!
When I have to look into a bugfix, and I see the commit is a one-liner that fixes exactly the problem at hand, probably I have even seen the code in that area before myself, had a short chat with the developer and I came to the conclusion that we are here in what Cynefin describes as the obvious domain, I’m very much fine with closing the issue and not testing it any further. Some colleagues would describe this as “not testing”. For me that is a lot of testing, even if the actual task of creating a test idea/case and executing the code against some predefined scenario never happened.
Don’t get me wrong, I’m not against test documentation and all that, which is probably required and necessary in several contexts. But writing 95% of the documentation upfront, even before any line of code is written, and just adding the fact that I did what is written there, was never for me.
My “testing” is a complex and unpredictable process, that uses a lot of experience, common sense, systems thinking, domain knowledge, and many more aspects. Which is actually causing a big issue for me. I was so far unable to teach other testers, especially the younger generation, to mimic my approaches. Except one. But from a senior role that is sort of expected. Here is an attempt to describe why I am not able to do that.
Being the tester in a team means for me that I support my team to establish and maintain trust in the code we build and deliver, help us optimize the way we work, help to come up with solutions for the problems our clients and we are facing. I try to open up bottlenecks, never be a bottleneck myself, enable the team to act fast, and most of all I help to uncover potential risks, so that we are at least aware of them, talked about them and included mitigations for them, if relevant, in the solution we came up with. I cannot describe what I’m doing any better or more precise than that. Simply because I don’t know where I can help next.
Tomorrow I might:
- write test designs, when I have to,
- automate some test cases,
- improve existing test scripts,
- pair up with a developer
- refactor the test automation framework,
- pimp the Jenkins pipeline,
- explore
- step in for the product owner
- participate actively in refinement meeting, and with actively I mean, I don’t only ask questions for clarification, I also propose actual solutions for the problems at hand,
- I might pick up a story to implement,
- do a code review
- discuss with the business architect
- help my tester colleagues
- suggest architecture improvements
- analyze test failures after the latest pipeline run,
- discuss how we can reorganize the team structure to become better
- update dependencies
- sit in a meeting and just listen
- step in for the scrum master
- take care of the test infrastructure
- or any other task that has to be done to deliver value to the customer, improve the quality of our own working, or just help future me to have a better day in a few weeks/months.
How many of these tasks do you read or expect in actual tester position descriptions. How many of those do you expect to be part of a tester training syllabus. And before the suggestions comes, I don’t see myself as a coach. I’m a hands-on person, I taste my own dog-food, and I want to stand behind things I propose. I lead by example, and hope that others are able to understand what I’m doing, and mimic my behavior to become better. Whenever I see behavior that is worth mimicking, I try to do that.
Quality, value, improvements, reducing waste, and making an impact drive my daily actions. I think, despite the level of Impostor Sydrome I suffer from, that I’m doing a good job, having a big impact on teams. At least that’s the feedback I get sometimes. I don’t even want to teach developers HOW to test. I’m rather good to help developers WANT to test.
But please don’t assign me any rookie and expect me to teach them how to test. In about 17 of 18 cases I will most probably fail miserably.
Something that just came into my mind when reviewing the post a last time:
I try to positively influence systems to heal, maintain, and improve. And as an embedded tester I have the chance to do that from within the system. But what I am doing to achieve that is so much more than just “testing”.
Test Pappy 
This is the first testing post I’ve read in over 3 years. Great words my friend, no wonder it feels like we are kindred spirits. Stay strong and stay true….
Thank you, Jim! Glad you liked it, my friend. That means a lot. Take care!
Thanks Patrick. A refreshing read.
I’ve never been a fan of huge tests suites or massive amounts of documentation. I do it if a client asks. I’ll keep (shared) notes on odd quirks of an existing product, but nothing more. If a user needs hours of on-boarding and explanation for a relatively simple application, then I’d say the bigger issue is the product itself and not the level of documentation.
In the UK we have a saying: “But what if you were run-over by a bus tomorrow…?” I feel that a good tester at any level will get to know the application by actually using it, instead of reading through documentation. Let’s face it, most documentation is not written for a complete outsider so it’s audience is reduced. Those who understand, don’t need it. Really it just becomes a check-box exercise. That being said, I still find it beneficial to write testing steps down sometimes, if only as one method of mapping out expected behaviour.
Plus a fresh pair of eyes (with a limited amount of context) can help expose existing, but overlooked issues.
As for the discussion of Quality. I completely agree. To add this, the title of Quality Assurance gives out the wrong impression of what the role is. I don’t agree with being some sort of software police, the main safety net, or somehow being accountable for the “Quality” of a product.
Beyond a certain point testers do not (and cannot) assure, ensure or insure Quality.
For me, I bring value to the team by being able to highlight assumptions, clarify expected feature behaviour, point-out potential unhappy paths, pair with devs for early feedback before code is deployed, discuss best ways of fixing an issue, get tooling and additional debugging included in the overall plan etc etc. And of course physical exploratory testing.
In other words: Issue prevention.
I try to avoid using the word “Bug” as that implies that somehow a foreign body has infiltrated the code and is causing mischief. Instead of the actual case, where the code is doing what it was written to do, and is just not behaving as we expected or wanted.
In regards to teaching testers a certain approach, I’ve also experienced difficulties.
For one, I’ve been testing so long that it’s closer to muscle memory than some sort of process that can be merely written down in logical steps. Most likely I need to talk about it more to improve this side of things.
Secondly, there are a huge number of courses and organisations that still teach a very waterfall interpretation of testing, this in turn creates an industry-wide expectation of what the role involves. Once individuals have spent enough time with these methodologies, it becomes very difficult to get them out of that mindset.
If truth be told, I do what I can to re-educate teams and departments. But there is only so much that can be accomplished by testers. Bad software cannot be fixed in test. I believe it’s outdated behaviour and mindsets at an organizational level that needs to be tackled to make a real difference.