Q&A with Patrick Prill (aka Test Pappy)

Welcome to this month’s Q&A. Each month we catch up with someone (from the testing community or beyond) with an interest in quality in software development and technology.

Some guests you may know well, and others might be less familiar. I hope you will learn something new about each of them, and something new from each of them. Each will bring their own perspectives and insights on quality and testing.

The format will be the same each time:

a little information about this month’s guest and what they are currently up to
some questions for them to answer
some answers for them to question (the ‘Jeopardy’ section where I will provide the answer and ask the interviewee to give me the question)
finally, the ‘Pass it on’ section with a question from last month’s participant and the opportunity to pose a question for next month’s guest

This month’s guest is Patrick Prill, perhaps better known to some as Test Pappy. Patrick is a Test Consultant working for QualityMinds (@QualityMindsDE) in Munich.

In Patrick’s own words:

I’m born and raised just outside of Munich, Germany, where I still live with my wonderful wife and daughter. If I’m not working, I used to turn some wood into pens and vessels or do some smaller carpentry in my workshop. I just need to find more time again for this hobby.

I am in IT for over 16 years now, being a tester for the last 13 years. The first 9.5 years I spent more or less in the same project with a few visits to other engagements closely related to it. I made my experiences from being a test specialist via several other positions, to release test manager, coordinating the work of 60+ people. I changed into the test lead role for product development in the Munich office of an American company for the next 3.5 years. And earlier this year I made the decision to change into test consulting, and found a new home joining the “Agile Testing Team” as Test Consultant in a young company called QualityMinds here in Munich.

You can read Patrick’s thoughts on testing and more by visiting his blog, at the link below:

https://testpappy.wordpress.com/

To kick things off, Patrick, would you like to tell us about anything interesting you’ve been involved in recently, any exciting upcoming ventures, or just what you are working on at the moment?

On top of that list would be that I’m helping to organize a testing event. This gives me a lot of opportunities to look behind the scenes of this kind of event. We are just past the early stages, and there is so much stuff to think about and dependencies to care about. It really challenges most of my project management skills.

The team will come out shortly with the announcement about the what, where, and when.
What I can say now already is, it will be fantastic!

Since joining my new company in September I’m also helping my team to enhance our portfolio and describe a role that helps teams with quality aspects, more focused than a “normal” tester would do. We see several approaches out there in that direction, and we also have lots of ideas circling around in the team. Which is for me fantastic to see, as it’s the first time in over 16 years in IT that I work together with so many engaged people at the same time into a direction that makes sense in the current software development world.

Another upcoming event I’m looking forward to is DEWT 7 (Dutch Exploratory Workshop on Testing) in Utrecht end of January, which I was invited to. It will be my first ever peer conference, and I’m very excited to be part of it.

If you encountered a version of yourself from earlier in your career, and talked about how you approach your work, what would you disagree on?

The “beginning” of my career, the first 9.5 years, I was part of a team called “Testfactory”. So, I guess, I don’t need to tell you what kind of testing approach it was. And I was usually struggling with that approach. From being a test specialist, taking “his” application apart to study how it works and gain confidence, ignoring test cases, to being a test manager, coordinating 60 people for different kinds of releases still focused on delivering what the customers wants now and not what he wanted a year ago when the plan was made.

I don’t actually disagree with my “past me”, but what I would tell my “past me” is that there are more approaches out there to testing. Maybe I would have found some more fitting approaches earlier in my career that would have helped me with my projects, to spend my time more efficient and made me realize that there are more like-minded people out there.

And then there is my “past me” from early 2013, the me that tried hard to be a +1 in a new company. I tried so hard to make a difference and follow the mission set by my boss far, far away in HQ, that I was actually a -1. The advice would be: “Feel the context first, understand why a project is at the state it is. Then plan your changes.”

When you look back at your career so far, what do you consider to be the highlight(s)?

That is a tough question. The highlights that came to my mind first were, watching my first webinar back in 2012, which kick-started my journey into a new world of testing; meeting people from the Twitter community in real life for the first time and getting integrated into that group in no time was another highlight; and then there is my first time on stage at a testing conference, in front of 300 people at TestBash in Brighton.

These are all connected to the community somehow, which gave my career a whole new direction. So overall I would say, finding the community which helped me to understand our profession better was my career highlight so far.

When you think back to these highlights, what were the most important lessons you learned?

I was uninspired for too long, surrounded by 9-5 testers, who did their job and didn’t care about learning besides getting a training every other year or so. Don’t get me wrong, most of them made a good job, but there was no general interest in learning and getting better. Something woke me up, it was a mere coincidence at the right time.

I guess the lesson I learned was “the power of serendipity”! It’s one of my strongest forces, it’s only tough to sell it to a manager as a plan.

The other lesson I learned is, to surround myself with people who care. That energy helps me to keep me motivated and invest time and energy myself.

When you consider technology and software development around the world, can you pick out an example of an organisation who really focus and deliver on quality?

To be honest, I don’t think I can. Quality is such a wide spectrum, concerning so many different stakeholders. There should be many companies who get a good balance on many aspects of quality, but none is outstanding to me.

Most companies, in the end, have the focus to make profit. Which is okay from my perspective. But this is also often the factor that negatively influences the focus on quality the most. It always depends on the point of view.

What do you think is the most common misconception about testing?

I misuse a famous quote by George Bernard Shaw: “The single biggest problem in testing is the illusion that it has taken place.” (Originally the quote says the same thing about communication.)

I would say, that most people outside of testing, and a huge number of people inside, think that testing is all about “test cases”, counting them and other pieces of documentation. The benefits of good testing are neglected or ignored. Testing is seen often too focused on finding “bugs” or just for getting a tick on a checklist. Testers focus too much on requirements and executing all these scripts.

I recently had a good discussion with four fantastic testers during the open space of Test Bash Manchester. My topic was the “Shift X”, and why do testers try to shift left, right, out or some other directions. At every conference in the recent past you find talks about testers not being happy with the position they are (put) in. And the heart of the problem we found is that testers are put into a position of the development life cycle where they have only restricted influence on adding value to a project or product. That’s why good testers tend to stretch out all along the SDLC to add the benefits of testing to all aspects of the life cycle.

Projects where the testers are locked up at the position between development done and ready for customer acceptance or hand over to operations don’t use the full potential. Which in turn creates the opinion that testers are not necessary or only produce additional, unplanned work, or are always the bottleneck. Which in turn either brings the testers into a position where they dig deep trenches around their silo or are trying to find a way out of testing.

And now, the Jeopardy section. I’ll provide you with some answers and ask you to give me the questions…

Quality

What is the thing that everybody talks about, only very few actually understand, and usually no two people share the same understanding of it for something?

Testing

What is the activity that everybody seems to talk about in software development, too many give this name to the wrong activity, and way too few do it on purpose and in a structured way?

Lastly, the ‘Pass it on’ section. The question posed by last month’s participant, Katrina Clokie, was “If we removed a tester from the team, would quality go down?”

Short answer: Not necessarily.

A tester doesn’t influence quality directly. Just by having a tester on the team doesn’t mean quality goes up. So, to answer the original question we need to find out more about the context.

How was the removed tester engaged in the team? Was it the only tester? What activities besides testing did the tester do on the team? How much awareness for quality did the tester already bring to the team? Are the testers seen as safety net for the developers?

And then we should ask how the team can compensate the loss of the tester. Are the developers willing to invest more time for testing their own code, and help others with testing their code? Pair programming, eg. comes to mind. Are the BA, PO or whoever writes the requirements able to incorporate more quality aspects into them? Is there someone on the team who creates a shared understanding about quality?

The longer answer is: it depends on how well the team can compensate the loss of the role and take over the activities. Losing a safety net might improve the personal awareness and let individuals deliver even higher quality. I’d even say a team can be able to stabilise the level of quality mid to long term. But only with a good tester or quality advocate on board you can improve it over time.

And finally, what question would you like to pose for next month’s participant?

What would non-context-driven testing look like?