You often see them on LinkedIn: project managers daring to “sell” themselves as test managers. Sell might be the right word, because apparently, there are companies to which this combination appeals. It is understandable from the viewpoint of a manager who likes to achieve results with one’s projects. However, have you not already hired a project manager for that? What is the difference between project manager and test manager? Are you on the right path when you also hire a test manager managing the project result as well?
Difference between Project Manager and Test Manager
The question implies the answer: no. A good test manager acts as a counterbalance for the project manager. The test manager understands what the project manager is doing, but one should also have a broader view.
Risk Management
In the interest of the organisation, one should also assess whether the project result does not go against the organisation’s interests. This, of course, is known as ‘risk management.’ If the project manager chooses all kinds of quick solutions that threaten the continuity of the company, the role of the test manager is to counterbalance this. By means of one’s reports, the test manager should be able to advise the project’s principal (and one’s supervisors) about any risks in the project and especially the product as well as what threats these imply. When a balance between the risks and results originates, the point that the project can proceed to its completion is coming closer.
To be able to fulfil this role, a test manager should also have substantive test knowledge. By that, I do not mean process knowledge as provided by a Test Management Approach. A test manager should know one’s business: with what product, system etcetera are we dealing? What are the specific risks associated with this? What is the interest in terms of time-to-market versus continuity of the market in which the product is to be used? This is important input for a good risk analysis (in addition to all kinds of IT-related risks). When this substantive analysis has been conducted properly, the test manager should be able to translate those risks into a test approach that (partly) covers the risks.
The Good Test Approach
A good test approach principally does not consist of several test cases to be performed before moving to production. This way, one can insufficiently guide to progressive insight and one risks spending too much time on coming up with tests in advance, while it is better to spend one’s time on performing tests.
A good test approach consists of naming (a number of) test sessions one wants to perform in order to cover risks and/or testing (important) parts of one’s product. Here, the test manager should facilitate one’s testers optimally, so they can spend their time during the test sessions as wisely as possible. Think of taking care of test environments, test data etcetera.
Different Skills
Subsequently, a test manager should be able to perform the debriefing of such test session by asking follow-up questions; what is tested and how? What are the results? Has the risk been sufficiently covered? Are additional test sessions required to cover the risk? With this, one can inform one’s project manager and especially one’s principal about what risks are present and how ‘well’ the system functions in relation to the expectations that were present and tested at the (end) users of the system.
To me, it seems a test manager should have an essentially different set of skills than a project manager should have (and an approach perfectly applicable to an agile/scrum environment).
Oh, about the project manager’s planning? It can be thrown in the trashcan once the tester finds ‘unknown features.’
So the difference between project manager and test manager is clear. If you have other ways to distinguish them, please comment below.
