Q&A with Paul Maxwell-Walters

Welcome to Q&A, a series in which we discuss testing and quality with guests from the world of technology and software development.

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

The format will be the same each time:

  • a little information about our 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 time around Q&A features Paul Maxwell-Waltersa British software tester based in Sydney, Australia.  Paul has been working in testing for around 10 years, including work in financial services, digital media, energy and agri-tech. He is a committee member, and former co-chair and social media officer, of the Sydney Testers Meetup Group, and has spoken at several conferences in Australia. Paul blogs on issues in IT and testing at his website – https://testingrants.blogspot.com – and tweets on testing and IT matters @TestingRants.

Welcome to Q&A, Paul. 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?

Due to caring responsibilities I have had to take time away from testing activities outside of work, however I did have the privilege to speak at Australian Testing Days and the first TestBash Australia conference.

I have also started doing live streaming and demoing of programming and test automation activities on Twitch (@TestingRants). Previous streams can be seen by searching for my name on Youtube or via the URL – https://bit.ly/2LMWGWE

I also have a list of free testing resource links I maintain on GitHub, which you can find here.

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?

When I first became a tester I was working in a tiny company where I was the only QA person and a part-time one at best. I based my testing on IEEE-829 and other (so-called) standards and spent far too much time on getting precise requirements, elaborate test cases, being process driven and doing lots of needless documentation. I also had the idea that devs couldn’t be trusted to help and acted as the gatekeeper of quality and releases. I was also much more bloody minded!

These days having worked in other environments and been influenced by the context-driven testing and agile communities, I am much more relaxed about documentation and rely much less on scripted tests and more on heuristics and my own experience and common sense. I also don’t act as a gatekeeper anymore. My younger self and I would certainly have been at odds over the conflicting approaches above.

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

Highlights include coming to Sydney and working at Avocado for seven years, particularly my four year stint in digital media. I also worked for the first time under a great test manager, Terry Doherty, for two years when placed at a bank and I learned a lot from him. I would also class as a highlight getting my current role at the Yield, working with a great team on a very interesting product.

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

My role in digital media was my first role managing people, including graduates who had never worked in testing before. It was also my first role in a tight agile team, so I had much to learn about the agile process, along with my first role in web testing. It taught me about pressure, tight deadlines and having to assist the PMs and devs in making difficult compromises – they won’t delay the Melbourne Cup or Wimbledon because your new Melbourne Cup/Wimbledon feature isn’t ready yet or still has bugs! These are all lessons I took into my current role.

I learned much under Terry, including how to manage the expectations of a wide range of difficult stakeholders, how to deal with offshore dev teams and how to manage large numbers of defects and write good reports and metrics. I also learned how to fit in within a test team under a dedicated QA manager for the first time in my career. All critical lessons.

When you consider the many organisations around the world involved in developing software and technology, is there an example of one which stands out for you as having a focus on quality?

I have been reading about the “Quality Assistance” processes created at Atlassian – particularly their focus on developers building quality in from the start and taking ownership of the test execution – working with a QA engineer to facilitate this, thus removing a specific QA end-step as a bottleneck. They have a focus on four principles – Quality, Speed, Independence and Experimentation which I really like. If anyone is interested there are details here: 



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

That it is easy and amounts to box-checking. It is neither of those things. It is a multifaceted role and demands a wide set of technical and soft skills to do properly. People who test or recruit and manage testers based on the fallacy above do great damage to software engineering.

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


What is… that vague thing that you know your customers want and have some pointers at (via. requirements, feedback, user stories etc.) but which can be best described as “the proof is in the pudding?”


What is… that set of activities that everybody should be doing throughout the software delivery lifecycle to determine what the software does under a wide range of scenarios and thus help to reveal where the customers will get “quality” and where they won’t?

Lastly, the ‘Pass it on’ section. This question was posed by Damian Synadinos:

What is a “requirement”, are they important (and if so, why?), where can they come from, and how can testers use them?

I regard requirements as a set of wishes, obligations and expectations that stakeholders, clients and users (not always the same people of course) have about the delivered product or the process done to deliver it. They can in principle come from anyone with an interest in the outcome of the product. They are anything but perfect and can be tainted or made redundant by:

  • lack of or incorrect knowledge of the users’ wishes
  • a lack of shared understanding of the end goal or an underlying business process
  • the passage of time and change in the clients’ needs and wishes
  • shifts and trends in the market and the effects of competitors
  • the need to accommodate what is achievable
  • the effects of positional power and irrational choices

Testers can use them as a basis for modelling the expected behaviour of the product under test but with respect to the caveats above and along with experience, investigative skills and common sense.

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

What should current testers do to keep themselves continually relevant and successful in their careers – is it just a case of continuous learning or is there more to it than that?

Thank you Paul for taking part in Q&A. We’ll be back with another guest soon!