productive on. Although it might be a good idea longer term to give Joe Bloggs the Inventory module so he can come up to scratch on it however if he’s the Invoicing guru then this could hinder your progress on both modules. Tiger-by-the–tail testing projects are not good training grounds!
Achievement re-evaluation —as you progress through your timeline, you will need to continually be reviewing your deliverable. There will be many occasions where due to circumstances beyond your control, eg. poor defect turnaround, that your deliverable will need to change. Make sure that you communicate to everyone what the revised expectations are and as you will no doubt receive challenges from your sponsors and project manager, be ready to justify. Ensure that you gain agreement, preferably in writing.
If you are able to identify your shortfall(s) early enough, the following suggestion can be a major time optimiser:
Early involvement —this can be easier said than done but the IT project that sees testing as the last step of the process will always place unbelievable pressure on the poor test team and on the remainder of the project team as they fight to fix up all the defects that could have been found earlier. A good test manager recognises the benefits of getting himself and his team involved right up front even at the analysis and requirements specification phase. You may well find that you’ve entered the foray too late in the day for this method to be effective however any opportunity you can get to deploy it will be of benefit.
A tester’s nose is a valuable asset in the early stages of a project as it can sniff out potential “gotchas” before they eventuate - prevention is always the best medicine. Sometime we find that analysts and developers bring their special talents in such a way that focuses on the positive (and nothing wrong with that) whereas the balancing nose of the tester, while not intended to necessarily be negative, can bring more of a quality equipoise to the process.
Because the time and cost of fixing defects increases dramatically through the system development lifecycle, defects and issues identified early are easier and less costly to fix. It will also reduce the incidence of related or regression-type issues further down the track so it pays more quality dividends than just improved time utilization.
Earlier in this session we talked about risk analysis. Starting risk analysis back at the requirement specification phase can help identify the risks associated with resulting test requirements and cases. If the test manager can gain agreement for test team involvement earlier in the development lifecycle, much of the risk analysis can be covered much earlier meaning more time for productive testing.
Early involvement not only assists in making best use of time but also assist in selling the project on the estimate for testing both in time and dollar terms and promotes testing as an integral part of the development lifecycle. It has the potential t
Test Environments As discussed earlier, we cannot test without something to test on. This should be a dedicated environment that is ‘owned’ by you as the test manager.
Sometimes the nature of our projects and the availability of environments might dictate that we have no movement or possible ‘creativity’ to make better use of the facilities available. However if this is not the case then some of the ideas below could be of benefit:
Duplicate test environments —if the nature of your application or environment means that your test team is constrained by only having a single test system,