The journey to becoming the enlightened tester...
Submitted by Antony Marcano on Thu, 27/01/2005 - 14:21.
perspectives | test management
[textile]Yesterday, I attended the "Test Management Forum":http://www.evolutif.co.uk/tmforum/ in London.
Listening to the usual issues faced by Test Managers I picked up on a great deal of frustration in the room. Apart from myself and a few others in the room, there was a lot of negative feeling at first, particularly with the challenges we face as testers on a day to day basis.
At one point, we jested that the session was less like a forum and more like group therapy. Everyone laughed, but it did prompt a discussion on the issue of negativity and frustration and how this doesn't help us be heard by others in the organisation, particularly at the board level.
This seems to be a common theme among many testers and in my opinion is doing nobody any favours! Read on...
I feel **very** positive in my day-to-day life as a tester 99% of the time. I enjoy being good at my job despite the ongoing challenges that I encounter in terms of time, budget or the quality of the information I receive. In fact, finding innovative solutions to these challenges is a part of what I enjoy about testing.
I wasn't always like this, however... many years ago, I felt very negative about testing and sometimes felt as though my suffering was only justified by my commitment to the greater good of the project.
Over time, that changed. By being positive, focusing on the benefits of what I can do (rather than consequences of not doing what I say) and by talking in a language that the audience understands (e.g. money and time savings) I have found that I quickly progress to becoming a trusted advisor to the rest of the project team and sometimes to the board. I have had the ear of project managers and IT Directors alike.
Before I could achieve this I had to go on a journey to becoming a more enlightened tester...
**Good Enough**
The first set of articles that were particularly influential in changing my perspective were James Bach's articles on "Good Enough Testing":http://www.satisfice.com/articles.shtml
Often, however, after the analysis and consideration, you realise that the project constraints (budget, quality of information you receive, time), that are often beyond your control, don't allow you to do what you believe to be 'Good Enough' testing... no need to be frustrated... find out what is Good Enough for your customer and present any resulting risks that you identify.
This can provide a means of negotiation. You show your customer what can be done and if that is less than "Good Enough" for them - they have an incentive to give you more of what you need. If they choose not to - then they accept the risks and restrictions to what you are able to achieve. This leaves you to focus on doing the best job you can and enjoying the process.
Although, be wary of being a perfectionist. Perfectionism about what you do is one thing, but being a perfectionist about what others do can only lead to a frustrating existence. Aim to do the best with what you have - that should be satisfaction enough.
Be careful how you measure yourself, however. Remember that you can't just measure your own outputs based on your perception of 'Quality'. You need to be just as mindful of time, cost and quality in your testing as the project needs to be as a whole about the product you are building.
**When Helping isn't Helping**
So you have taken the 'Good Enough' approach. The project is progressing, more and more things are going wrong, software is delivered to you late, others cut corners on what they had promised to deliver to you and you now have less than you thought you were going to have (in terms of time, environments, useful inputs to your testing etc.)... You find that you put yourself under pressure to compensate for the constraints that result from the choices that others have made... whether that's by doing unpaid overtime or by doing work that you feel should have been done earlier and by someone else - like, say, requirements analysis...
A common complaint - leaving you feeling like something of a victim - a victim of other people's choices! But are we victims or are we actually the enablers in a co-dependent relationship?
One of the most powerful and thought provoking presentations I have seen was by Lee Copeland. **Lee related Testing to codependent relationships**... He took the audience on an emotional roller coaster ride as he told a story of an alchoholic's suffering family... That story alone left the vivid memory of the messages burned into my brain... he then showed how the behaviour of the alcoholic's family was not that dissimilar to testers' behaviour on software projects... Sometimes, by compensating for others mistakes, you are only making things worse for the future by showing them that they will never pay the price for their own choices... He did emphasise that you have to 'pick your fights' and be careful not to be seen as obstructive - a delicate balance.
Lee's article "When Helping isn't Helping":http://www.stickyminds.com/se/S2275.asp and "presentation slides (PDF)":http://www.stc-online.org/cd-rom/cdrom2000/webpages/leecope/codep.pdf don't do the presentation justice (because it really was that good), they do provide you with the messages that Lee was trying to get across...
**Zen & Positive Forces**
Despite all of this, if you still feel negative and frustrated as a Tester, read Danny Faught's "Testing, Zen & Positive Forces":http://www.stickyminds.com/se/S7169.asp as I have "previously mentioned":http://www.testingreflections.com/node/view/130
**Lessons Learned**
Many of the thoughts, feelings and perspectives that I have today have grown form my own experience, from reading about others' perspectives and from discussions with people that have been influential in my own personal development.
A superb book (that I am ashamed to say, I only read for the first time recently) articulates similar perspectives with many more that can only enhance your skills and job satisfaction as a tester.
"Lessons Learned in Software Testing":http://www.amazon.co.uk/exec/obidos/ASIN/0471081124/testingreflec-21 by Cem Kaner, James Bach and Bret Pettichord reflects the attitudes of a pragmatic tester and provides many practical and thought provoking lessons and constructive messages.
!http://images-eu.amazon.com/images/P/0471081124.02.MZZZZZZZ.jpg(Buy Lessons Learned in Software Testing from amazon)!:http://www.amazon.co.uk/exec/obidos/ASIN/0471081124/testingreflec-21
I strongly recommend this book to anyone involved in testing! If you are used to being the "Quality Police" or "Gate Keeper" and get frustrated because people don't follow processes to the letter - start to think about why you are in that position and why you feel that way before reading this book. Then open your mind to the possibilities, sit back and prepare for some self analysis and therapy!
People don't always follow 'the process' - sometimes for good reason - and I don't choose how the project is managed and often will only have a limited influence.
This doesn't need to mean that I can't do a good job of testing the system (within the context of the prevailing constraints)... Each constraint then becomes just another challenge from which to enjoy the gratification of finding yet another creative testing solution!
Listening to the usual issues faced by Test Managers I picked up on a great deal of frustration in the room. Apart from myself and a few others in the room, there was a lot of negative feeling at first, particularly with the challenges we face as testers on a day to day basis.
At one point, we jested that the session was less like a forum and more like group therapy. Everyone laughed, but it did prompt a discussion on the issue of negativity and frustration and how this doesn't help us be heard by others in the organisation, particularly at the board level.
This seems to be a common theme among many testers and in my opinion is doing nobody any favours! Read on...
I feel **very** positive in my day-to-day life as a tester 99% of the time. I enjoy being good at my job despite the ongoing challenges that I encounter in terms of time, budget or the quality of the information I receive. In fact, finding innovative solutions to these challenges is a part of what I enjoy about testing.
I wasn't always like this, however... many years ago, I felt very negative about testing and sometimes felt as though my suffering was only justified by my commitment to the greater good of the project.
Over time, that changed. By being positive, focusing on the benefits of what I can do (rather than consequences of not doing what I say) and by talking in a language that the audience understands (e.g. money and time savings) I have found that I quickly progress to becoming a trusted advisor to the rest of the project team and sometimes to the board. I have had the ear of project managers and IT Directors alike.
Before I could achieve this I had to go on a journey to becoming a more enlightened tester...
**Good Enough**
The first set of articles that were particularly influential in changing my perspective were James Bach's articles on "Good Enough Testing":http://www.satisfice.com/articles.shtml
Often, however, after the analysis and consideration, you realise that the project constraints (budget, quality of information you receive, time), that are often beyond your control, don't allow you to do what you believe to be 'Good Enough' testing... no need to be frustrated... find out what is Good Enough for your customer and present any resulting risks that you identify.
This can provide a means of negotiation. You show your customer what can be done and if that is less than "Good Enough" for them - they have an incentive to give you more of what you need. If they choose not to - then they accept the risks and restrictions to what you are able to achieve. This leaves you to focus on doing the best job you can and enjoying the process.
Although, be wary of being a perfectionist. Perfectionism about what you do is one thing, but being a perfectionist about what others do can only lead to a frustrating existence. Aim to do the best with what you have - that should be satisfaction enough.
Be careful how you measure yourself, however. Remember that you can't just measure your own outputs based on your perception of 'Quality'. You need to be just as mindful of time, cost and quality in your testing as the project needs to be as a whole about the product you are building.
**When Helping isn't Helping**
So you have taken the 'Good Enough' approach. The project is progressing, more and more things are going wrong, software is delivered to you late, others cut corners on what they had promised to deliver to you and you now have less than you thought you were going to have (in terms of time, environments, useful inputs to your testing etc.)... You find that you put yourself under pressure to compensate for the constraints that result from the choices that others have made... whether that's by doing unpaid overtime or by doing work that you feel should have been done earlier and by someone else - like, say, requirements analysis...
A common complaint - leaving you feeling like something of a victim - a victim of other people's choices! But are we victims or are we actually the enablers in a co-dependent relationship?
One of the most powerful and thought provoking presentations I have seen was by Lee Copeland. **Lee related Testing to codependent relationships**... He took the audience on an emotional roller coaster ride as he told a story of an alchoholic's suffering family... That story alone left the vivid memory of the messages burned into my brain... he then showed how the behaviour of the alcoholic's family was not that dissimilar to testers' behaviour on software projects... Sometimes, by compensating for others mistakes, you are only making things worse for the future by showing them that they will never pay the price for their own choices... He did emphasise that you have to 'pick your fights' and be careful not to be seen as obstructive - a delicate balance.
Lee's article "When Helping isn't Helping":http://www.stickyminds.com/se/S2275.asp and "presentation slides (PDF)":http://www.stc-online.org/cd-rom/cdrom2000/webpages/leecope/codep.pdf don't do the presentation justice (because it really was that good), they do provide you with the messages that Lee was trying to get across...
**Zen & Positive Forces**
Despite all of this, if you still feel negative and frustrated as a Tester, read Danny Faught's "Testing, Zen & Positive Forces":http://www.stickyminds.com/se/S7169.asp as I have "previously mentioned":http://www.testingreflections.com/node/view/130
**Lessons Learned**
Many of the thoughts, feelings and perspectives that I have today have grown form my own experience, from reading about others' perspectives and from discussions with people that have been influential in my own personal development.
A superb book (that I am ashamed to say, I only read for the first time recently) articulates similar perspectives with many more that can only enhance your skills and job satisfaction as a tester.
"Lessons Learned in Software Testing":http://www.amazon.co.uk/exec/obidos/ASIN/0471081124/testingreflec-21 by Cem Kaner, James Bach and Bret Pettichord reflects the attitudes of a pragmatic tester and provides many practical and thought provoking lessons and constructive messages.
!http://images-eu.amazon.com/images/P/0471081124.02.MZZZZZZZ.jpg(Buy Lessons Learned in Software Testing from amazon)!:http://www.amazon.co.uk/exec/obidos/ASIN/0471081124/testingreflec-21
I strongly recommend this book to anyone involved in testing! If you are used to being the "Quality Police" or "Gate Keeper" and get frustrated because people don't follow processes to the letter - start to think about why you are in that position and why you feel that way before reading this book. Then open your mind to the possibilities, sit back and prepare for some self analysis and therapy!
People don't always follow 'the process' - sometimes for good reason - and I don't choose how the project is managed and often will only have a limited influence.
This doesn't need to mean that I can't do a good job of testing the system (within the context of the prevailing constraints)... Each constraint then becomes just another challenge from which to enjoy the gratification of finding yet another creative testing solution!