Now the inspiration for this series of blog posts was quiet uninspiring (and expensive). I was having some building work done on my house and this work involved screeding a floor. Basically this is when a sand/cement mix (more sand than cement) is laid on a floor to give a level finish so that it can have some flooring laid on top of it.
Whilst I was chatting to the builders (after I had made them a bacon Sarnie and cuppa tea - I like to treat workman well) I thought to myself what do we produce as testers? These guys are 'building' something that will add value, for me the stakeholder. Now, as the stakeholder I could see a difference in what was there when they started and what was there when they finished. To me these builders
had 'built' me what I needed.
They were, in my opinion, the 'developers'.
So it got me thinking about what we produce as testers. If the builders had a tester what would they do in the process of screeding this floor?
I would imagine they would do things such as;
Now they may produce a mind map of how they plan to test it or a list of charters that they would like to investigate, they may even produce a specification that the builders and me need to sign off. However they would not actually 'build' anything. They would not help the builder finish the job, they may in fact hold the builder up with their questioning and enquiries about what the builder is doing. Although this information would be useful to the tester it may bug the builder as all they want to do is get the job done and move onto the next one.
Now consider the following 2 scenarios:
1) I'm in no rush to get my floor finished and money is no object
In this scenario I may be happy to have some testers investigating and uncovering information about the flooring that I am having laid. I would potentially see them as an important part of the team and that they are adding value to the whole process.
2) I want it done as quickly as possible as I have my in-laws coming over to stay and this room is where they will be sleeping and I have lots to do to get it prepared ready for their stay
In this scenario I may not want these testers doing stuff that does not seem to help to get the job done. I may see them as a hindrance as all I want is the floor laid so that I don't have
unhappy in-laws. As they are not helping to get the floor laid and are not 'building' anything
I don't really care about them I just want to make sure the builders build what I asked for.
Now as a tester consider the 2 scenarios. How would you feel in each? I'm guessing (like me) you would feel much better in the 1st one. But I'm sure you have worked in or experienced number 2 as well. In the software industry time to market can be essential and getting software out the door as quickly as possible is all that matters. This can effect our role as a tester and potentially we may be seen as less 'useful' as we don't actually produce anything on the finished product. We may hold up releases, we could ask too many questions which distract the developers. Yes we may do these things but If we add value we can become an integrated valued member of any team.
Now as tester we could produce some or all of the following:
There are more and I'm sure you can thing of some. Now if we think about developers and what they produce.
They produce amongst other things the application. They are the people who take
a blank IDE and create this 'thing'. Now this thing will be something that will
(hopefully) generate income for the company that they are working for. Whether this
be through sales to other companies or through users using to buy goods. (Please note, these are just examples)
Now for he senior managers and decision makers, what is produced is the thing
that will generate income and potentially help fund future products and
enhancements. So are developers (the people who produce that something) seen in a higher
regard than other team members such as Support and Testers?
To answer this lets take a look at what we do as testers that could support this view:
1) We give honest opinions about the software that we are testing
This may include issues that the management do not want to hear. If we are asked
whether it should be shipped we can sometimes be the one that says no and then
back this up with some evidence.
2) We don't produce anything of value in the managements eyes
Now before you scream and shout "I think testers do produce things that management find value in" Surely you have heard stories where testing progress reports are sent to management and never read? Sometimes management don't care about the details they only care about whether the product
will be completed on time. Often a simple Yes/No answer is all they need and any
'documents' are ignored
3) We are always asking questions
Asking questions is important to a tester as we are always looking to improve and build
on our knowledge of the system we are testing of the system. Also asking questions helps us to test and we can even find issues before we get hold of the application due to the questions we have asked. These questions could identify issues which in turn could delay the development of a project or even make the stakeholder rethink aspects of the application entirely.
Now If these views are held by key managers in the project, we are not helping ourselves and
how we are perceived.
In Part 2 I will discuss how this perception that we do not produce anything can effect us testers.
Whilst I was chatting to the builders (after I had made them a bacon Sarnie and cuppa tea - I like to treat workman well) I thought to myself what do we produce as testers? These guys are 'building' something that will add value, for me the stakeholder. Now, as the stakeholder I could see a difference in what was there when they started and what was there when they finished. To me these builders
had 'built' me what I needed.
They were, in my opinion, the 'developers'.
So it got me thinking about what we produce as testers. If the builders had a tester what would they do in the process of screeding this floor?
I would imagine they would do things such as;
- Question whether the builders had enough mix to complete the job
- Ask about the floor that the screed was being laid onto - what was it made of? Will it affect the screed? How will the builders know the floor is level?
- Speak to me about what I expected the screed floor to look like - How high? Should it cover the whole floor?
- When the screed is laid - test it. They would do things such as,
- Try different weights on the floor
- Place a ball at one end to see if the ball rolled in a particular direction (would indicate whether the floor was level)
- Lay small amounts of different flooring types to test to see whether various flooring types can be put on the new screed
Now they may produce a mind map of how they plan to test it or a list of charters that they would like to investigate, they may even produce a specification that the builders and me need to sign off. However they would not actually 'build' anything. They would not help the builder finish the job, they may in fact hold the builder up with their questioning and enquiries about what the builder is doing. Although this information would be useful to the tester it may bug the builder as all they want to do is get the job done and move onto the next one.
Now consider the following 2 scenarios:
1) I'm in no rush to get my floor finished and money is no object
In this scenario I may be happy to have some testers investigating and uncovering information about the flooring that I am having laid. I would potentially see them as an important part of the team and that they are adding value to the whole process.
2) I want it done as quickly as possible as I have my in-laws coming over to stay and this room is where they will be sleeping and I have lots to do to get it prepared ready for their stay
In this scenario I may not want these testers doing stuff that does not seem to help to get the job done. I may see them as a hindrance as all I want is the floor laid so that I don't have
unhappy in-laws. As they are not helping to get the floor laid and are not 'building' anything
I don't really care about them I just want to make sure the builders build what I asked for.
Now as a tester consider the 2 scenarios. How would you feel in each? I'm guessing (like me) you would feel much better in the 1st one. But I'm sure you have worked in or experienced number 2 as well. In the software industry time to market can be essential and getting software out the door as quickly as possible is all that matters. This can effect our role as a tester and potentially we may be seen as less 'useful' as we don't actually produce anything on the finished product. We may hold up releases, we could ask too many questions which distract the developers. Yes we may do these things but If we add value we can become an integrated valued member of any team.
What we produce as testers
- Test Strategy Documents
- Test planning documents (e.g. Mind maps)
- Bug reports
- Training material
- Automated tools (to aid testing)
There are more and I'm sure you can thing of some. Now if we think about developers and what they produce.
They produce amongst other things the application. They are the people who take
a blank IDE and create this 'thing'. Now this thing will be something that will
(hopefully) generate income for the company that they are working for. Whether this
be through sales to other companies or through users using to buy goods. (Please note, these are just examples)
What us testers do
Now for he senior managers and decision makers, what is produced is the thing
that will generate income and potentially help fund future products and
enhancements. So are developers (the people who produce that something) seen in a higher
regard than other team members such as Support and Testers?
To answer this lets take a look at what we do as testers that could support this view:
1) We give honest opinions about the software that we are testing
This may include issues that the management do not want to hear. If we are asked
whether it should be shipped we can sometimes be the one that says no and then
back this up with some evidence.
2) We don't produce anything of value in the managements eyes
Now before you scream and shout "I think testers do produce things that management find value in" Surely you have heard stories where testing progress reports are sent to management and never read? Sometimes management don't care about the details they only care about whether the product
will be completed on time. Often a simple Yes/No answer is all they need and any
'documents' are ignored
3) We are always asking questions
Asking questions is important to a tester as we are always looking to improve and build
on our knowledge of the system we are testing of the system. Also asking questions helps us to test and we can even find issues before we get hold of the application due to the questions we have asked. These questions could identify issues which in turn could delay the development of a project or even make the stakeholder rethink aspects of the application entirely.
Now If these views are held by key managers in the project, we are not helping ourselves and
how we are perceived.
In Part 2 I will discuss how this perception that we do not produce anything can effect us testers.
Comments
Post a Comment