When should you engage with the testing team on waterfall projects?

I appreciate that most software development these days is done using the 'agile methodology' or a variation thereof. With agile, the testing team is (or at least should be) heavily involved with every sprint.

However, many organisations also deliver other types of projects that don’t have a continuous development path. These are one-and-done projects like bringing in or patching a 3rd party’s software; upgrading or replacing hardware or a whole range of changes that can impact your user base.

As with everything in your IT Infrastructure, these changes should be thoroughly tested before going live. The depth of testing undertaken should reflect the level of risk your organisation is willing to take and the impact of getting It wrong.

Often, a Project Manager isn’t fully aware of everything a good testing team does or how much time they require to carry out their work.

This lack of understanding can cause a number of problems for the project

Not engaging early enough with the testing team can delay the project because of the time required to carry out adequate testing. Then more time might be required to find and fix bugs identified and then repeat the process. If sufficient time for this process is not allocated by the project, it will likely impact the timeline. This problem can be exacerbated if the testing team has other commitments already scheduled.

I’ve seen cases where the support contract on critical 3rd party software is due to expire unless the software is upgraded by a certain date. A project is spun up to upgrade the software but if enough lead time isn’t planned for testing, there is a real risk the 3rd party supplier will stop supporting the existing software while the new software is being tested for compatibility. If there is an outage during this gap in support, it can be catastrophic for the organisation.

So, when is the best time to involve the testing team?

The answer is simple, as early as possible in the project lifecycle. Even before the project is accepted as a project. It’s rarely too early to involve the test function.
The key is that this doesn’t have to be a huge investment of time for anyone. You don’t need to know detailed testing requirements at this early stage. The project brief or business case should be enough to indicate what kind of testing may be required, e.g., Penetration Testing, Performance Testing, Usability Testing, Compatibility Testing, User Acceptance Testing (UAT), etc.

The Project Manager may not know all of this detail but the Test Team Manager will be able to quickly review a project proposal and determine if it’ll need testing or not. They will also know whether it’ll need one day, a week or a month to complete.

The Test Manager could even set up a simple checklist to be completed by the Project Manager or a stakeholder. This can consist of just a few very simple questions that will indicate to the Test Manager if they need to be involved or not.

Questions such as but not limited to:

• Will this project alter the user experience with any of our software or hardware?
• Will this project change or replace existing IT infrastructure?
• Who will use this software or system? (e.g., staff, students, visitors, IT only, customers, etc.)
• Is there a target go-live date? (If so, when?)

The advantages of this light-touch early engagement with the testing team are many

If the testing team is aware of a project coming down the pipeline, they can plan for it and ensure there is time in their schedule to carry out the testing. Even if the date for testing shifts a little, as it often does with projects; at least the testing team won’t be blind-sided with a short-notice demand on their time.

The testing team can plan for what kind of testing needs to be done and will have time to bring in additional resources if required. This is actually a really important point as if the in-house testing team doesn’t have the required skills or enough people; they will need time and money to bring in additional people and the project will need to budget for it. Knowing this cost upfront will help the Project Manager stay in budget or adjust the budget accordingly.

Earlier, I said waterfall projects were one-and-done projects but they often repeat. I’ve run many projects, such as major 3rd party upgrades, that happen every year or perhaps twice a year. This type of change is sometimes big enough to be a proper project but not quite frequent enough to fit with an agile methododolgy. For changes like these, it’s best to work with your testing team in an ongoing partnership. If the testing team is involved early on, each time a project repeats; they can ensure consistency across testing cycles, good documentation and anticipated test results based on previous experience. The team can often schedule the same Testers to do the work, which increases their familiarity with the software.

The alternative is to rush a project through go-live without adequate testing, leaving it up to your customers to test it and report bugs. This then takes time and money to fix outside of the project, to say nothing of the negative impact on customer satisfaction. If you are delivering change as an external supplier, your customer may decide to switch to another vendor as a result. So, if you want greater success with projects that require testing, engage with the Testers on day zero.

The software testing team should never be thought of as a ‘bolt on accessory’ to project delivery or even as ‘nice to have if there’s time.’ User satisfaction is critical to a project’s success, to say nothing of the cost involved in fixing a failed project. The testing team is there to ensure a successful delivery. As such, they should be seen as an essential resource on every project and should be involved early on in a projects lifecycle to decide if they need to be involved or not.

Ultimately, getting the testing team involved early in the project will help ensure the project is delivered on time and in budget, which is every Project Manager’s goal.