|
|
TPI, a tactical application
|
|
Posted On :
Oct-28-2011
| seen (227) times |
Article Word Count :
678
|
|
Ever since reading the Test Process Improvement book by Martin Pol and Tim Koomen, I’ve found it to be one of the more useful tools of my trade primarily because of its foundations in reality. I once had the opportunity to meet Martin Pol at a conference and baled him up for as long as I could with the express goal of understanding where TPI came from. I’d like to take this opportunity to both apologise and thank Martin for his patience and understanding!
|
|
Ever since reading the Test Process Improvement book by Martin Pol and Tim Koomen, I’ve found it to be one of the more useful tools of my trade primarily because of its foundations in reality. I once had the opportunity to meet Martin Pol at a conference and baled him up for as long as I could with the express goal of understanding where TPI came from. I’d like to take this opportunity to both apologise and thank Martin for his patience and understanding!
Since then I’ve spent a considerable amount of time reflecting on the various aspects of what TPI gives us and have used it as a tool on numerous occasions to frame solutions to various testing problems I’ve encountered across the testing spectrum. I think it’s now become such an integral part of how I approach test management and test design that I don’t even realise I’m using it.
The changes introduced by TPI Next refine the Key Areas further and, in my opinion, bring an even more realistic perspective on the test process although the concept of moment of involvement still stands true. The reason for saying this is:
1. being involved early can help determine stakeholder commitment as risks identified can influence the stakeholders.
2. the degree of involvement, partially determined by the stakeholder commitment, can be influenced.
What I have found is that the depth of stakeholder commitment can be very much determined by what level of pain has or is being experienced. Whilst this may sound cynical my experiences find this to be somewhat true.
A case in point is a recent performance testing project I worked on where the first attempt at implementation failed in one of those blaze of media coverage ways. The first iteration of implementation had not addressed performance testing in any significant way. The very public and highly publicised failure had significantly increased the stakeholders commitment to performance testing. Could being involved earlier have changed the stakeholder commitment?
On the flip side of this a fixed price project we did some years ago which made me very nervous due to the dependency we had on the developers, to this day is probably the most profitable project I’ve done. We were involved right from the early design stage and had significant input into the design process from a static testing perspective. This allowed us to develop a testing solution that significantly reduced the test effort for each code iteration. Ultimately, the project was finished 3 months early and encountered no post implementation issues.
So, rather than looking at the test process from a macro perspective, I utilise the key areas of TPI to provide a simple SWOT state of the overall project and, from that determine what needs to be done to firstly, achieve delivery and secondly, develop a basis for ongoing improvement. Fundamentally, irrespective of the stakeholder commitment the moment of involvement is the defining event in terms of what is possible to be achieved. The commitment of the stakeholder then determines what can actually be achieved.
At its most basic level time is the biggest asset a testing delivery person can have. When I refer to time it is not in the context of being able to do more testing but is from the perspective of being able to implement a better testing solution. This is especially true in the case of performance testing where execution windows are very limited and preparation times typically lengthy.
A high stakeholder commitment, for example, late in the delivery timeline will not significantly increase the range of testing outcomes that can be achieved.
A common counter argument to early testing engagement is the cost of bearing a testing capability throughout the early stages of the project. This moment of involvement does not necessarily mean a full time commitment to the project but engagement at critical times such as:
Project initiation;
Project costing;
Requirements analysis/walk throughs; and
Specification walk throughs.
|
|
|
|
Article Source :
http://www.articleseen.com/Article_TPI, a tactical application_97218.aspx
|
|
Author Resource :
Elliot Ashton is a Principal Consultant with TestLogistics Pty Ltd based in Sydney, Australia. With nearly 20 years experience in most areas of testing Elliot has been involved with some of the biggest and most complex deliveries across various industries. Most recently he has worked in the performance testing space. He is also an occasional speaker at various groups.
|
|
Keywords :
Software testing, Performance testing, Web Testing, Testing Sydney ,
Category :
Computers
:
Computers
|
|
|
|
|
|
