I first heard the terms Navigating and Driving in relation to testing back in 2011. The context of the discussion was around one of the perennial challenges in SAP test management, particularly for user acceptance testing – how are the business users expected to test and “accept” the system when they haven’t been trained on it?
Project plans for SAP implementations usually include a section for Training, but there are frequently two big problems (from a test perspective) with the training plans:
- Training is planned way too late compared to your test schedule (frequently somewhere between UAT and Go Live); and
- Training is planned as a single block for the business users rather than being targeted initially towards testers.
Regardless of the testing phase you’re going to have some testers that may be business process experts but are new to SAP. These may be project super users and business analysts that will be testing in functional unit testing or integration testing phases, or business users that will be testing in user acceptance. As part of your Test Strategy you’ll need to formulate an approach to supporting all of your testers throughout the test phase(s), and the navigator/driver approach is one that has worked for me in multiple SAP implementations.
I was reminded of this approach to our test support while listening to the Testing In The Pub podcast with Maaret Pyhäjärvi and noticed the terms “navigator” and “driver” coming up frequently, alongside other similar terms such as mobbing and pairing, and I’ll try to explain further the approach that we’ve used below.
Our use of the navigator/driver approach is slightly different, in that we are using it to pair less experienced people with more experienced people. At some point in your testing you will have people that are less experienced and require support – these may be:
- Project-based business analysts that will be assisting in functional unit testing
- Project-based workstream super users that will move from blueprinting and design into integration testing
- Business testers expected to complete user acceptance testing in a greenfield implementation
- Business testers testing process changes in a transformation project
The pairing may be with project functional consultants, external consultants brought in specifically to shadow, or with business process experts. The pairing is usually supported by test scripts (either detailed or as transaction checklists) and in this way very quickly evolves into a standard support model where the testers are more comfortable testing on their own with the support available by exception. Where this technique is used in early test phases the testers can move from becoming navigators to drivers in following test phases (for example, functional consultants are drivers for business analysts during integration testing, and then the business analysts become the drivers for business testers during UAT).
The navigation/driver model (like any support model) needs to be confirmed with the relevant stakeholders:
- Whether the support is coming from functional consultants, externally, or business experts, someone else is currently paying for them. Their time and commitment to supporting your testing needs to be confirmed with the budget holders (PM, System Integrator, business line managers, etc). Test support may not be in the contract with the integrator so there may be an additional cost negotiation required.
- Where the people identified as being requested to support are already engaged in config or other activities (including BAU), these activities need to be balanced against the test commitment required. If design and configuration is running behind then it may be difficult to get a commitment for any time to support testing, and alternatives will need to be considered.
- Where travel is required (for example, UAT support onsite in a different location) the availability of the support needs to be confirmed. Visa restrictions and family commitments need to be taken into account, so identify support individuals early to avoid late changes.
- Business stakeholders need to be comfortable with the approach, so there is an amount of “selling” required to ensure that everybody is aware of how the testing will be supported and the roles that each player/actor will take.
Decide early on to what extent each actor will take control and for how long – Passive Observation vs Active Experimentation. An important part of setting up the navigating/driving model is to ensure that both parties are fully engaged in the process and that they know what is expected of each other. It won’t work nearly so well and will be extremely frustrating for everybody involved if the person needing support is expecting someone sitting next to them 100% while the supporting person is only expecting to be on call. Engage with all parties beforehand to walk them through the process and to confirm expectations, and where you have gaps in those expectations they can then be addressed well before the actual testing starts.
Whether we call it Navigating and Driving, mobbing, pairing, or simply an extended support model, the key objective is to complete our testing within the planned timeframe using all resources and techniques at our disposal. Projects do tend to use as many internal resources as possible even if they may not immediately seem to be the best persons for the task, but spending some time and effort in upskilling and supporting the testers (particularly business experts) pays off in the long run as they become super users and implementation change champions.