Originally posted at SQABlogs.com on { 03:55, 2009-May-13 } { Posted in Software Testing } { 0 comments } { 156 trackbacks }
As Test Practitioners, one thing that we all may agree upon is that there is no silver bullet to avoid the squeezing testing timelines when it comes to project schedule. Scope-creep in projects is almost predestined. Let me ask you a question. As a Test Manager, how many times have you come across the situation where the Project Manager walks up to you and asks you a little favor, “can we finish testing with lesser number of resources” or “can the testing be finished a little earlier” or “I know this is kind of late, but can we include this module too”; and in most cases the first thing you say is, “let me check”.
This ‘check’ has to be quick; and it should just not be based on assumptions, rather on measured inputs. ‘Something’ has to be in place somewhere throughout the testing life cycle which allows us to quickly adapt to the changed scope without risking the quality of testing and the delivery. Risk based testing is one such ‘something’ that assists testing teams in prioritizing the test deliverables conforming to the project plans.
What I am saying here is an overview of risk based testing; proposing it as a tool to shield yourself and your teams from the ever-changing requirements, scope-creeps and last minute surprises. Since a lot has already been written about Risk Based Testing, risk definition, risk identification, risk assessment and risk mitigation process, I don’t think we need to discuss it here.
All that I am mentioning here is basically a case study based on the system integration testing phases of the programme for implementing a common HR Integration System across all branches of the company using PeopleSoft. The HR system was based on customization of PeopleSoft as per the HR policies prevailing & impacting a particular branch of the company in that country.
Considering multiple implementations with overlapping phases and more than one project plans, a risk based approach to testing was adopted. Focus was on prioritization & re-usability and test artifacts were shaped considering these.
To further buttress this approach, every module of PeopleSoft was given a priority after discussion with the respective project manager. Once this base was prepared, timelines for testing as estimated by the Test Manager were mapped with the respective modules. As & when there was a change in project scope, minor changes in the matrices produced a new version of testing schedule, which was publicized to the whole group.
The Risk Based Testing approach proved highly beneficial to the project and testing team could successfully manage the scope changes throughout without bringing down the quality or morale of the team. Well done Team!
Recent Comments