Ajeet Singh, Project Manager – Quality & Engineering, Cognizant Technology Solutions, argues for the five skills that matter the most when you’re just starting out.
Managing a test release for multiple projects on a heterogeneous platform requires a different mind set & stamina and therefore different skill sets when compared to the core test management.
The job of a Release Test Manager (RTM) though utilises the test management skills, which revolve around stakeholder management, planning, execution and co-ordination, it demands certain other skills that are far more important to acquire.
There is no alternate to the learning by doing. As Aristotle said, “For the things we have to learn before we can do them, we learn by doing them.” – but having an understanding of the skills that matter, definitely place you well prepared for the journey.
Here are five skills that the first time RTMs can look forward to.
Rising above the self – serve first and all attitude
‘Could you let me know the clusters for digital channel testing’, ‘I need build deployment next week to catch up with test timelines’, ‘We need weekend support from AD teams’, ‘Third party application is down, can we have the ETA please’, ‘Please can we get one more application added to the integrated test bed’, ‘Can’t understand the application flow, need a mentor & continuous support’, ‘we need exclusive control of batch environment due to exhaustive runs we plan’, are just some of the requests from test managers, RTM would be flooded with.
Having a single point ownership for the test release, RTM can’t choose favourites – all projects are a responsibility and every request matters. What works for him is the quick transformation into a servant leader role with a mentality to serve first and all. Of, course he could prioritise requests based on the criticality of functionality due for delivery unless they are invalid or can’t be achieved.
“Your reality is as you perceive it to be. So it is true, that by altering this perception we can alter our reality.” – William Constantine.
RTM sits as a layer between the senior stakeholders and the test teams – every activity and the status has to go through his lenses before reported to higher ups. Senior stakeholders are quick to intervene when they see a threat for release but is there really a threat or it is just a perception problem?
One fine day the test team reports some sev ’1’ defects. Before RTM could acknowledge it as a threat for release, he figures out that a critical functionality of third party application is failing which is perceived to be sev ‘1’ defect by the vendor but test team actually could proceed with a stub and should change the defect to sev’3’ just for tracking purpose – the news of sev ‘1’ defects could have given different impression of testing, had that not corrected.
Other instances include where RTM has to manage the views on testing interrupted by frequent environment issues – is there any real impact ? – project going ‘RED’ overnight as the test team perceives not making to the timelines – is this just a case of extraordinary precaution?
Intervene, bring the facts forward and manage the perceptions to keep everyone’s confidence in the testing.
Problem-solving ability over technical understanding
Linux servers, mainframe batches, mid-tier services, digital apps, jar files, pub files, XMLs, databases, properties, URLs, ports – the list of technical jargons to which the RTM has to put his head into, is endless. Does he need to understand everything ?
On a large heterogeneous application platform, test environment is the ‘God of messy things.’ Every now and then something will break and testing will be stuck. Rather than getting into technicalities of the issue, finding out what is the immediate blocker, who could resolve it and how soon it can be fixed, is the skill that matters and it inherently utilises your analysis and negotiation skills.
Conflict management – what can work best for everyone
Test teams could quite frequently knock the door of the RTM for conflicting interests. Some situations which would warrant the RTM’s intervention:
a.) Test environment has just one multi-channel gateway between digital and branch test teams, unlike the live environment which has dedicated channels. If a digital team goes for deploying their code on it the downtime will stop the branch testing – what holds the priority, code deployment or testing?
b.) Single batch environment and test teams want to run jobs with different system dates at the same time. Who gets the deal?
c.) Test teams claiming the same set of test data from an integrated bed.
Lay the ground rules, set the clear release priorities and bring teams together on a platform to brainstorm what works best for them and in the interest of the overall release. As they say, ‘the harder the conflict, the more glorious the triumph’ – the discussion would provide insight into the problem and may offer workable solutions between the teams or it will at least allow RTM to explore alternate options – can the projects severely in conflict be deferred to next release, can an additional batch environment be arranged, can some test data be tweaked with accepted risk, can a live cut be arranged on short notice etc.
Play devil’s advocate to safeguard the release
Imagine a situation where a highly influential stakeholder comes up with an ask to include a project in the release when SIT is half way – he has all the explanations to get into the release but as RTM you think it should shift to next release as the inclusion poses risk to the on-going testing – you counter argue.
A similar situation may arise when the previous release is not ready to hand-over the test environment because it is anticipating some live issues but then that impacts your release plan – you argue to defer to his stand and suggest other viable alternatives.
These are key takeaways from my experience in the role.