Being a test manager, I have experienced that managing a test release for various projects on a diverse platform requires a diverse skill set. This is a little different from core test management.
It is in the job requirement of the Release Test Manager (RTM) to utilize test management skills i.e. stakeholder management, planning, implementation, and coordination. Even then, RTM requires some other skills that are very important to attain. This has no alternative.
Therefore, I have prepared a list of five skills that an RTM must have.
Paying Equal Attention to All Requests
RTM get numerous requests from test managers regarding digital channel testing, build deployment, and app flow.
Release test managers cannot prefer any requests. All requests must be treated equally because of every request matter. In this situation, the rapid conversion into a servant leadership role with a mindset to serve first and all is required. Of course, the manager has the authority to prioritize the requests based on the significance of the functionality.
Keep Everyone’s Confidence In Testing – Perception Management
RTM acts as a layer between the test teams and the stakeholders. He must review all the activities before reporting to the senior management. Senior stakeholders are first ones to interfere when they detect a threat in a release. Now the question arises, is actually a threat or a perception issue?
One fine day, some cycle 1 defects are reported by the test teams. The release test manager points out that a critical functionality of the third-party app is failing, prior to acknowledging it as a threat for release. This is perceived to be cycle 1 defect by the vendor. However, the test team could proceed with remains and must change the defect to cycle 3 only for tracking purpose. Therefore, the news of cycle 1 could have provided a different impression of testing.
Other cases could entail where RTM needs to manage the view on testing interrupted by regular environmental issues- is there any actual effect? – project going ‘RED’ instantly, as the test team observes not making to the timelines- is this only a case of extraordinary protection?
Interfere, bring the facts in the front and manage the perceptions to keep everybody’s confidence in the testing.
Problem-solving ability Is Given Priority Over Technical Understanding
Ports, URLs, properties, databases, XML, pub files, jar file, digital apps, mid-tier services, mainframes batches, Linux servers- this is the endless list of technical jargons to which RTM has to understand.
The test environment is the ‘God of messy things’, on a large varied app platform. Every time testing gets stuck because of something breaks. Instead of getting into the minute detail of the issue, you must focus on the following things.
- Find out what is an immediate blocker
- Who could fix it and how early can it be fixed?
- How much does the skill matters?
What Works Best for Everyone- Conflict Management
Test team often ask for the help of release test manager for their conflicting interests. There are three situations that could ask for the intervention of RTM.
- Unlike the live environment which has dedicated channels, test environment consists of a multi-channel gateway between branch test and digital teams. If a digital team wants to deploy their code on this, the downtime is likely to pause the branch testing – what holds the testing, deployment, code or priority?
- Test teams and Single batch environment want to run jobs with various system dates at one time. Who gets the deal?
- Test teams asking for the same set of test data from a United bed.
As an RTM, set the rules and clear release priorities and bring the team on one platform to think what works best for them.
Play devil’s advocate to safeguard the release
Think of a scenario, where an influential stakeholder orders you to incorporate a project in the release when sit is halfway. He gives you all the explanations to get into the release. However, as release test manager you find it appropriate to shift to the next release as its inclusion causes risk to the current testing.
An analogous situation may arise when the prior release is not prepared to capitulate the test environment because it is forecasting some live problem but then that influences your release plan – you argue to submit to his stand and suggest other feasible alternatives.
These are key takeaways from my experience in the role.
