Point of View From Our Field CTO

Testing and Project Management in 2024

By Dean Cornish, Field CTO, PTP Consulting

The last 18 months have certainly delivered a series of business challenges: budgets slashed; market growth stalling and opportunities not landing. This coupled with external forces including the Victorian Government ‘s challenging balance sheet and an economy that has all but flatlined means the phrase ‘pivot’ is seemingly tattooed to the everyday vernacular for any executive or business leader.

Yet, over the past 3 months since joining PTP, I’ve seen grass shoots of encouragement that funding is being approved and tech projects are being kicked off (albeit slower in pace and smaller in scale and size.)

In my role as a Field CTO, I’m encouraging our clients (and in turn you) to approach testing very differently to how things have been done in the past. There are more rules and restrictions on budget and in simple terms, things aren’t going to go back to how they were before. Therefore, PTP encourages you to not look back. Instead, be decisive about when you start your testers up, what you get them to do and optimise their usage across projects.

When to start testers on your projects…

Testers don’t add quality with testing. Testers tell you whether you have quality, and how much is there to be found.

It should almost go without saying, but don’t start your testers when you (or your partner) are already developing or customising your solution. Starting testers at this point is essentially like trying to fix the design of a car after 10,000 cars have already been built. Anything you find will be horribly expensive to fix and hugely disruptive.

The ideal time to start testers is during business analysis and design phases. By starting at least some of your testers (usually your most senior) you are essentially “Front loading” your testers so they ask the right questions when the work is still young. That way your testers work more like analysts. If you do this what you get as an outcome is clear, concise requirements that are complete, clear and implementable. The benefit of this approach is that all requirements have testing thought built into them, so developers can build the feature completely and correctly the first time round, instead of having to do mountains of rework after testing is complete. In addition, any unit tests the developers write allow for the entire range of testing, instead of just low level code concerns, minimising the amount of duplication of effort in later stages of testing which in turn allows you to operate with the minimum number of testers. You can do this whether you’re following a quality engineering and quality coaching approach, or a traditional testing function. It applies equally well in both cases.

What your testers should be doing…

In most situations, when you bring in an expert tester, either a permanent or from a professional services company- they have a way of doing things. They’ll sometimes say the words “best practice” or “industry standard”. When challenged, they might even become visibly angry at being taken to task, as though what they’re saying is common sense. That passion is a praiseworthy aspect, but there is a need to understand up front, what the tester plans to do, when they plan to do it and what value that activity will provide. It is a conversation. To not discuss it, is a recipe for problems. We’ll explain. Testers really have no limit. If you ask them to test a feature, they can literally produce hundreds of test cases. You’d have to tell them to stop by saying “I’m satisfied you’ve covered all the important scenarios, you can move on to the next feature”. In most cases- testers have learned pragmatism- which is a nice way of saying- they’ve become aware through experience and prior confrontation- of what is realistic, acceptable and likely a point of diminishing returns. You can’t count on this though. We also recommend that you have this conversation with the product owner and the project manager in attendance. Project managers generally care about cost and time. Product owners care about customer and business outcomes and quality. The two provide a balanced viewpoint. With only one of these, the use of testers will be skewed towards their primary concern in obvious ways.

Testers across projects…

In an ideal world, you’d have the budget for a tester for every project. That isn’t always the case. So how do you know when and where to have a tester involved? What is the risk/consequence of having a tester thin on the ground? These are tough questions. We recommend you use your testers like you would any other resource in contention- think of graphic designers, UX specialists, database administrators/designers, infrastructure and devops specialists. You usually have a much smaller number of these than you have demand for their skills, so you and they manage their time carefully. Testers (and in particular test automators and performance testers) should be their own project manager, as in they should be managing their work, estimating it and managing the delivery of their own activities. This isn’t a skill all testers have, but you should expect it all the same. Time management, prioritisation, stakeholder management and internal consulting skills are also expected. Expected. That is a word we don’t use lightly, these are absolutely mandatory skills that should be assumed of all testers and who we deploy at PTP.. Any tester that doesn’t have these skills should be learning them and doing so in a hurry to stay current.

Summary
In my opinion, the industry is now about force multipliers. People are the main cost centre on projects. Having people who can be a “T” shaped person (expert in one thing, generalist in many things) is now almost an assumed characteristic and one in which we source for our clients here at PTP.

Any consultancy not providing “T” shaped people in 2024 is essentially not listening to their customers and anticipating their needs.

Keen to learn more, sign up to our newsletter today.