At EWT22, Michael Bolton moderated a new type of session – listening to an audio recording “How To Think About Science” and finding parallels to software testing.
Background to the interview:
On July 3, 1992, the Canadian Fisheries Minister John Crosbie announced a moratorium on the fishing of northern cod. It was the largest single day lay-off in Canadian history: 30,000 people unemployed at a stroke. The ban was expected to last for two years, after which, it was hoped, the fishery could resume. But the cod have never recovered, and more than 15 years later the moratorium remains in effect. How could a fishery that had been for years under apparently careful scientific management just collapse? David Cayley talks to environmental philosopher Dean Bavington about the role of science in the rise and fall of the cod fishery."
The MISSION:
Listen to the recording. Take notes on what you’re hearing, with the goal of capturing lessons from the interview that might usefully influence how we test, and how we think about testing. Stories or patterns from your own testing experience that you can relate to something in the interview are especially valuable.
My experience tells me that it's good to take lots of notes, regardless if it's reviewing documents or acively testing. I fully expect to discard 90% of it but it can serve to confirm or discard ideas, theories and guesses.
So I listened to the interview and made notes about important events and their order, my raw data. I'd stop from time to time to listen again to passages to get a clearer understanding and to be able to keep up with note writing.
Michael clarified some terms that were used in Skype always shortly before I got to that passage. That was helpful on two fronts. One, I understood the term and context quicker. And two, I could tell that I was falling behind with my progress in listening as it took longer and longer between Michael explaining terms and me getting to the passage - a good way to measure progress, though fallible.
About 2/3rds in I changed the approach as I felt that I had enough data and because time was pressing. I started drawing parallels between the fishery events and software testing and noted those as well. Adding
to the raw data suffered as a result but that was fine as I was working towards the mission, drawing parallels and matching them to my experience. I concentrated on the similarities in process and process failings rather than thinking of 'fishing for bugs' or comparing the government quotas to test certification like some other people in the group did. Nothing wrong with either, I just took this particular approach.
Listening to the audio recording I noted several occasions of Hubris as reason for that monumental failure of preserving the cod population.
From Wiki: Hubris means extreme haughtiness or arrogance. Hubris often indicates being out of touch with reality and overestimating one's own competence or capabilities, especially for people in positions of power.
I reckon that is why the radio program was called "How to think about science", the idea that, while science has not all the answers, the ones it has can be taken as the truth.
That's only one part of it though, I don't want to make the same mistake and believe that one reason alone can explain the failures on many fronts.
Since I'm currently reading Jerry Weinberg's book "The Psychology of Computer Programming" (Thank you, Jerry, for giving me permission to use parts of this book) I saw some interesting similarities between his study of the psychology of computer programming and the events that lead to the disappearance of the Canadian cod. Here's Jerry's list from page 40 of his book.
1. Using introspection without validation
2. Using of observations on an overly narrow base
3. Observing the wrong variables, or failing to observe the right ones
4. Interfering with the observed phenomenon
5. Generating too much data and not enough information
6. Overly constraining experiments
7. Depending excessively on trainees as subjects
8. Failing to study group effects and group behaviour
9. Measuring what is simple to measure
10. Using unjustified precision
11. Transferring borrowed results to inapplicable situations
Matching my notes to this list I got the following results. We could argue with some of the matches, however the overall match of similarities should become clear:
1a. Key drivers were managing nature fluctuations in order to get back the money that was invested in the industry. Fluctuations turned out to be unmanageable – there was no driver to understand the model in detail
1b. Introducing averaging assumptions was one of the traps – the issue was not understood and two wildly different results had just been averaged with not thought of the consequences. One example of Hubris.
2. There was a simple model for the amount of cod in the sea which was far too simple and therefore wrong
3a Not all parameters of the model had been identified, for example parameter changes over time had been missed.
3b Some parameters had been misunderstood. These two points were the biggest mistakes made in my book. Science was not seen as fallible but a blind eye turned to the possibility that the current understanding does not fully cover the situation in question - see the definition for Hubris again.
4. There was constant interfering with the model as fishing continued throughout the years up to the point where the cod population didn't recover
5. Data from two sources was created, the scientific trawlers and the commercial fleet. They only seemed to look at total population, not age groups, etc
6. Local knowledge of inshore fishermen = “domain matter experts” has been ignored/dismissed as anecdotal – scientific methods were seen as more accurate and objective. Another example of Hubris
7. Not applicable in this scenario?
8. There were several examples of failing to recognise group behaviour, for example variation in location of spawning grounds and season, migration patterns, etc
9. Parameters found were dismissed as complicating the model too much (and making it unmanageable)
10. Not applicable in this scenario?
11. There were several examples of borrowing results from one are to another, for example assuming that inshore groups of cod behave the same as off shore groups
Some failings that I can't put into any of the categories but which are very important as well are:
A. The inshore fishermen’s protests have not been looked at in detail. They wanted to fish in the traditional way but reasons for that were not investigated. Scientists were supposed to speak truth. I'm wondering if, with a bit more questioning, some of the mistakes may have been prevented, for example damaging and destroying stock using the jigger (hook).
B. Investing in tools to make it cheaper became a driver to make more money which backfired. The parallel to automated software testing tools should be easy to see.
C. The fishing industry put pressure on the government to get higher allowable quotas. Available information was ignored and numbers changed against better knowledge to serve the industries need for money.
D. As the model got very complicated it didn’t help management as it didn't provide the control measures that were needed. In software terms this is the point where a project is either stopped or a drawn out death march begins
E. The target of management changed from figuring out how to achieve the goal to targeting people, the fisherman. Sounds oddly familiar, doesn't it?
I find it quite amazing how two, apparently unrelated areas like a book about the psychology of computer programming and discussing shortfalls of science in a fishery project are so similar at a higher level. I have a good number of other examples in mind, some of which I'll blog about shortly.
I'm in two minds about the message that science got it all wrong. I'd summarise it as scientists (bringing the people component in here) probably did their best but didn't look at their limitations. Results of their experiments were also disregarded and decisions taken based on politics and the industries needs/greed.
I come from a science background myself so may have a blind spot there. My overall (scientific approach/thinking) is to identify a problem, analyse it, put up some theories and experiments/tests that then either prove or disprove these theories. In other words, I'm building a close as possible picture or model of the issue in question. Any steps up to the results can be criticised, the result can not. The thinking behind that is that if you agree with the thinking behind all steps the result is independent. You don't get to argue with it if you don't like it. The result can be a pointer that something is wrong with your thinking, it's dangerous to build your thinking based on the results you want though. That's a different story though and far to involved to be discussed here.
I'd be happy to discuss these results in more detail so please feel free to agree or, even better, disagree with me.
I should note that these findings are based on a single source, the radio interview. What actually happened might or might not be exactly as portrayed, but I think it's useful to keep in mind that in testing as in life it's dangerous to believe only in one source without questioning it. Or would you believe a developer who tells you that a bug has been fixed and doesn't need re-tested?
PS: I would also like to point you towards an excellent blog of Jeroen Rosink who looks at this session from a slightly different angle.
Showing posts with label Software Testing. Show all posts
Showing posts with label Software Testing. Show all posts
Thursday, 17 June 2010
Saturday, 17 April 2010
ACCU2010 writeup
Here’s a short (OK, I got carried away a bit) summary of the conference and the talks/presentations I attended. I only went down for one day - Friday 16th April due to work commitments.
Friday morning:
Keynote talk from Russell Winder “The Multicore Revolution - We’ve only just begun”. Originally Dan North was down to present “Simplicity – the way of the unusual architect” but couldn’t get to the UK due to the airspace being closed because of the Icelandic volcano eruption.
Russell is clearly very knowledgeable and presented a good talk about the architecture of computers the way different programming languages address those. Good presentation that was probably more interesting to the developer community than for me but interesting nonetheless.
After a coffee break which I used for frantic telephone calls and trying to book train tickets I attended Rachel Davies “Understanding User Stories”. Not having written any before this was an interesting presentation with just the right amount of practical exercises for the participants. She mentioned the book “Agile Coaching” which she wrote or co-wrote which I’ll have a look at.
She explained that she and her team used a user story template which is now being used by many people around the world. I got the impression that she didn’t expect that and was pleasantly surprised that such a small thing created to make life easier in her project team has such a big impact. She did not that this template doesn’t work in all cases – especially when there’s no discussion with the business or if technical implementations are the order of the day rather than user workflows.
The template followed a
As a...
I want...
So that...
format which goes a long way getting all the necessary information onto a small card. She noted the importance of this being a physical card rather than a spreadsheet or electronic document. To me this format is similar-ish to the way use cases are created as the actor (As a xyz..) and workflow (I want...) and goal description (so that..) are all present. That’s not bad and I don’t confuse the two but just note the similarities.
After a practical exercise of writing user stories for an imaginary tool of our choice we discussed that. What I found interesting is that breaking down the user stories to the right level and amount of detail is really a team decision – something many people struggle with when writing use cases.
The importance about the user stories should be “Do the user stories help us understand user context and business value.” That’s a harsh abbreviation and there’s more to it but to me these are the essentials (together with acceptance criteria).
At lunch I met James Bach and after listening in to another conversation we spoke about some senior managers and their viewpoints on testing, the TA model (parent/adult/child modes) and implementing rapid testing in companies. As I’m following both James and Michael B’s blogs there was nothing groundbreaking new for me but it rather reinforced my own views but also highlighted that the problems I’m facing are not with the understanding of the rapid testing approach but in other, more business related areas. I left contemplating and thinking about this (which is a good thing) but will need some time before I’ll find answer. Interesting.
After lunch I attended Paul Field’s “Change, change, change – the 5 year evolution of an agile team.” It was an interesting presentations about his experience about starting out with a 2 man agile team taking on a failing project in an IT unfriendly environment – the internal customer (another department) got burned in the past and was wary of IT in general.
He spoke about the pitfalls of building a team and scaling that from 2 to 7 after a while. Generally a good talk although it could’ve been a bit condensed from my point of view.
I liked his use of the Timeline Retrospective where he mapped colour coded issues as experienced by the team in sprint retrospectives over the whole project time. This can be a good way not to measure the way the project is going but the way the team is feeling about it which doesn’t necessarily needs to be the same. (And indeed was not, the team thought that they delivered badly at a sprint when the customer was delighted).
The retrospective starfish was also interesting consisting of 5 areas for
More of
Start doing
Stop doing
Less of
Keep doing
In the burnup chart he presented he mapped the story points “Done” and the story points as asked for from the business. This was not per sprint but over the whole project which showed that after 4 months (in a 6 month project) the team had created as many story points as the business originally wanted (great) but wouldn’t be able to finish by immovable 6 month deadline – a big problem. This burnup chart showed the problem in time and action was taken to get the project back on track.
When new team members where added he found that his former “flat” structure didn’t work anymore as existing team members were more senior in terms of knowledge so not everyone was equal. This needed to be addressed and after the new team member were brought up to speed through pair programming and other measures the team picked up some momentum.
After a coffee break I went to Astrid Byro’s “Just in time – last minute testing” presentation. She jumped in for another presenter who couldn’t come due to “Volcano awareness week” as James Bach coined it.
This was the weakest talk for me, the title didn’t have very much to do with the talk which was basically a war story about a 2 year RUP project with very high risks (accepted), lots of stress and a “command and control” approach should have died out 20 years ago. System migrators where used as sole testers which would’ve made me uncomfortable (maybe she was as well). I can see that from a PM point of view using people with domain knowledge is a good idea and using testing as a training exercise so you save handover further down the line is good for project timelines as well. But I can’t shake off the feeling that professional testers would’ve done some good – apparently that wasn’t possible (or thought necessary). At the end of the project performance testing was started (always a bad idea due to the high risks involved, again they were lucky and their application performed well). Their clients infrastructure didn’t but that wasn’t seen as a problem as the project in itself delivered, even if that didn’t actually help the customer. My view is more holistic than just pointing at the customer and saying “it’s their problem, our application performs well”, but maybe that’s just me.
That concluded the official presentations but I saw about a dozen lightning talks, the highlight for me was James Bach’s “And...also” presentation (I’m predictable in that regard, I know).His fiery talk had a lot of passion and humour to be able to appeal to even the most hardened developers and I believe he got some people thinking. It was about thinking not only what the expected positive outcome is but also what he also expects to be there (or not). For example NOT getting error messages, expecting the result to appear for more than half a second, etc – all things an automated test suite might fail to notice but a human being would notice – sometimes instinctively, sometimes with a bit of thinking.
I won’t mention the other lightning talks, there were too many to mention and I didn’t take notes of all so wouldn’t be able to give a complete picture anyway.
After a longer break the conference dinner started which was very interesting as well, after the starter we played musical chairs with only the speakers remaining seated so that people got more opportunity to speak to different speakers and other attendees. At my first table I sat next to Jeff Sutherland, creator of Scrum, without recognising him which I found extremely embarrassing. I promised to put in a good word with the conference organisers to get him back next year so that I could have a longer discussion with him – so organisers, if you’re reading this, do all of us a favour and invite Jeff for next year as well!
That’s it, thanks to Volcano Awareness Week I’ve been able to write down these notes while on my train journey rather than sitting at home already so let’s all say thanks to the volcano gods
:-)
Thomas
Friday morning:
Keynote talk from Russell Winder “The Multicore Revolution - We’ve only just begun”. Originally Dan North was down to present “Simplicity – the way of the unusual architect” but couldn’t get to the UK due to the airspace being closed because of the Icelandic volcano eruption.
Russell is clearly very knowledgeable and presented a good talk about the architecture of computers the way different programming languages address those. Good presentation that was probably more interesting to the developer community than for me but interesting nonetheless.
After a coffee break which I used for frantic telephone calls and trying to book train tickets I attended Rachel Davies “Understanding User Stories”. Not having written any before this was an interesting presentation with just the right amount of practical exercises for the participants. She mentioned the book “Agile Coaching” which she wrote or co-wrote which I’ll have a look at.
She explained that she and her team used a user story template which is now being used by many people around the world. I got the impression that she didn’t expect that and was pleasantly surprised that such a small thing created to make life easier in her project team has such a big impact. She did not that this template doesn’t work in all cases – especially when there’s no discussion with the business or if technical implementations are the order of the day rather than user workflows.
The template followed a
As a...
I want...
So that...
format which goes a long way getting all the necessary information onto a small card. She noted the importance of this being a physical card rather than a spreadsheet or electronic document. To me this format is similar-ish to the way use cases are created as the actor (As a xyz..) and workflow (I want...) and goal description (so that..) are all present. That’s not bad and I don’t confuse the two but just note the similarities.
After a practical exercise of writing user stories for an imaginary tool of our choice we discussed that. What I found interesting is that breaking down the user stories to the right level and amount of detail is really a team decision – something many people struggle with when writing use cases.
The importance about the user stories should be “Do the user stories help us understand user context and business value.” That’s a harsh abbreviation and there’s more to it but to me these are the essentials (together with acceptance criteria).
At lunch I met James Bach and after listening in to another conversation we spoke about some senior managers and their viewpoints on testing, the TA model (parent/adult/child modes) and implementing rapid testing in companies. As I’m following both James and Michael B’s blogs there was nothing groundbreaking new for me but it rather reinforced my own views but also highlighted that the problems I’m facing are not with the understanding of the rapid testing approach but in other, more business related areas. I left contemplating and thinking about this (which is a good thing) but will need some time before I’ll find answer. Interesting.
After lunch I attended Paul Field’s “Change, change, change – the 5 year evolution of an agile team.” It was an interesting presentations about his experience about starting out with a 2 man agile team taking on a failing project in an IT unfriendly environment – the internal customer (another department) got burned in the past and was wary of IT in general.
He spoke about the pitfalls of building a team and scaling that from 2 to 7 after a while. Generally a good talk although it could’ve been a bit condensed from my point of view.
I liked his use of the Timeline Retrospective where he mapped colour coded issues as experienced by the team in sprint retrospectives over the whole project time. This can be a good way not to measure the way the project is going but the way the team is feeling about it which doesn’t necessarily needs to be the same. (And indeed was not, the team thought that they delivered badly at a sprint when the customer was delighted).
The retrospective starfish was also interesting consisting of 5 areas for
More of
Start doing
Stop doing
Less of
Keep doing
In the burnup chart he presented he mapped the story points “Done” and the story points as asked for from the business. This was not per sprint but over the whole project which showed that after 4 months (in a 6 month project) the team had created as many story points as the business originally wanted (great) but wouldn’t be able to finish by immovable 6 month deadline – a big problem. This burnup chart showed the problem in time and action was taken to get the project back on track.
When new team members where added he found that his former “flat” structure didn’t work anymore as existing team members were more senior in terms of knowledge so not everyone was equal. This needed to be addressed and after the new team member were brought up to speed through pair programming and other measures the team picked up some momentum.
After a coffee break I went to Astrid Byro’s “Just in time – last minute testing” presentation. She jumped in for another presenter who couldn’t come due to “Volcano awareness week” as James Bach coined it.
This was the weakest talk for me, the title didn’t have very much to do with the talk which was basically a war story about a 2 year RUP project with very high risks (accepted), lots of stress and a “command and control” approach should have died out 20 years ago. System migrators where used as sole testers which would’ve made me uncomfortable (maybe she was as well). I can see that from a PM point of view using people with domain knowledge is a good idea and using testing as a training exercise so you save handover further down the line is good for project timelines as well. But I can’t shake off the feeling that professional testers would’ve done some good – apparently that wasn’t possible (or thought necessary). At the end of the project performance testing was started (always a bad idea due to the high risks involved, again they were lucky and their application performed well). Their clients infrastructure didn’t but that wasn’t seen as a problem as the project in itself delivered, even if that didn’t actually help the customer. My view is more holistic than just pointing at the customer and saying “it’s their problem, our application performs well”, but maybe that’s just me.
That concluded the official presentations but I saw about a dozen lightning talks, the highlight for me was James Bach’s “And...also” presentation (I’m predictable in that regard, I know).His fiery talk had a lot of passion and humour to be able to appeal to even the most hardened developers and I believe he got some people thinking. It was about thinking not only what the expected positive outcome is but also what he also expects to be there (or not). For example NOT getting error messages, expecting the result to appear for more than half a second, etc – all things an automated test suite might fail to notice but a human being would notice – sometimes instinctively, sometimes with a bit of thinking.
I won’t mention the other lightning talks, there were too many to mention and I didn’t take notes of all so wouldn’t be able to give a complete picture anyway.
After a longer break the conference dinner started which was very interesting as well, after the starter we played musical chairs with only the speakers remaining seated so that people got more opportunity to speak to different speakers and other attendees. At my first table I sat next to Jeff Sutherland, creator of Scrum, without recognising him which I found extremely embarrassing. I promised to put in a good word with the conference organisers to get him back next year so that I could have a longer discussion with him – so organisers, if you’re reading this, do all of us a favour and invite Jeff for next year as well!
That’s it, thanks to Volcano Awareness Week I’ve been able to write down these notes while on my train journey rather than sitting at home already so let’s all say thanks to the volcano gods
:-)
Thomas
Wednesday, 20 January 2010
Testers - results orientation or integrity?
Hello,
this is my first blog post, I'd like to encourage you to leave criticism or feedback. I know I have a lot to learn so don't try and spare my feelings ;-) Here we go..
I started thinking about the importance of integrity for software testers after exchanging opinions on SoftwareTestingClub with Matt Heusser.
To me integrity has always been important but it was always a bit hazy and not very specific. I recently worked at job descriptions and put Integrity high on the list. It was later replaced with “Results Orientation” and “Planned and Organised” by the powers that be.
It could mean that these are a) more important or b) easier to understand by management. I argued for leaving integrity in but was overruled. In that case that wasn't a big issue for me even though I didn't like it.
If I say “Integrity”, what do I mean? I like the Wiki definition:
“Integrity is consistency of actions, values, methods, measures, principles, expectations and outcome.”
If a tester makes himself a name for having integrity what does that mean for their clients or employers? According to that definition it’s both clear and predictable what to expect from this person. By having a short discussion the values, methods, measures and principles can quickly be established. Or, in other words, integrity instils a sense of trust at the basic level. It still doesn’t mean that the tester in question is a good choice for a particular job, he might not have the right skillset, availability, etc.
In a software project context integrity is threatened in various ways – pressure from team members, Project Managers or people higher up in the food chain, customers, etc.
Project managers might ask testers to take shortcuts in the agreed test approach. When asked to mark tests as run even if they haven’t been executed or bugs not being reported as found; the tester will find themselves under a lot of pressure. Do you stand your ground and risk being shouted at, threatened or ridiculed? Or do you give in and take the shortcut to reduce the pressure? Under what conditions would you go against your values and principles?
Team members can put pressure on the tester to not log bugs as they might have run out of time to fix them before the deadline – anticipating pressure themselves from the PM.
In situations like that I found it important to remind myself that there is a two way relationship. One person asking to take the shortcut (maybe for a good reason) and the other person who can agree or disagree. Even though it doesn’t look like it at the time, one always has a choice.
For permanent staff and maybe even more so for contractors their integrity is an asset. If a contractor gets a name for not having integrity their career will quickly be at an end. Bowing out of the project might not be a good idea short term, long term that decision is invaluable.
Testers are not the gatekeepers of quality, even if it may sometimes feel that way, see the Enforcer in Rob Lambert’s light-hearted approach to tester types. Maybe there’s a reason why people are putting pressure on the tester and threaten their integrity.
Weinberg’s Rule of Three from his book “Secrets of Consulting” states "If you can't think of three things that might go wrong with your plans, then there's something wrong with your thinking." Finding out what the real goal is should be if not the first, but maybe the second reaction. Integrity might not be threatened at all.
The reaction to outside pressure is, of course, depending on the situation and personal values, methods, measures and principles. If the agreed test approach is no longer viable, maybe a new one should be agreed and documented.
If a project goes down that route there is a visible trace of why decisions have been taken and when. The tester protects themselves by getting agreement from the PM and other stakeholders which should be good engineering practice. The end result is the fear that comes with pressure – fear of not hitting the deadline resulting in loss of face, money or job – is removed by taking a realistic and professional stance.
Do I believe that integrity is important for a tester? Yes, of course. We’re some of the last cogs in the software development wheel who can highlight some of the things that might reduce the value of the product or solution our company is trying to sell. Should a tester be results orientated? Yes, knowing how to get the best results fast is important for the business. Let me ask though, when sitting in a plane waiting to take you on your holiday, would you rather have an airplane engineer with results orientation or integrity working on it?
Thomas
PS: Thanks to Rob Lambert for his help to get me started and kind words. I appreciate it.
this is my first blog post, I'd like to encourage you to leave criticism or feedback. I know I have a lot to learn so don't try and spare my feelings ;-) Here we go..
I started thinking about the importance of integrity for software testers after exchanging opinions on SoftwareTestingClub with Matt Heusser.
To me integrity has always been important but it was always a bit hazy and not very specific. I recently worked at job descriptions and put Integrity high on the list. It was later replaced with “Results Orientation” and “Planned and Organised” by the powers that be.
It could mean that these are a) more important or b) easier to understand by management. I argued for leaving integrity in but was overruled. In that case that wasn't a big issue for me even though I didn't like it.
If I say “Integrity”, what do I mean? I like the Wiki definition:
“Integrity is consistency of actions, values, methods, measures, principles, expectations and outcome.”
If a tester makes himself a name for having integrity what does that mean for their clients or employers? According to that definition it’s both clear and predictable what to expect from this person. By having a short discussion the values, methods, measures and principles can quickly be established. Or, in other words, integrity instils a sense of trust at the basic level. It still doesn’t mean that the tester in question is a good choice for a particular job, he might not have the right skillset, availability, etc.
In a software project context integrity is threatened in various ways – pressure from team members, Project Managers or people higher up in the food chain, customers, etc.
Project managers might ask testers to take shortcuts in the agreed test approach. When asked to mark tests as run even if they haven’t been executed or bugs not being reported as found; the tester will find themselves under a lot of pressure. Do you stand your ground and risk being shouted at, threatened or ridiculed? Or do you give in and take the shortcut to reduce the pressure? Under what conditions would you go against your values and principles?
Team members can put pressure on the tester to not log bugs as they might have run out of time to fix them before the deadline – anticipating pressure themselves from the PM.
In situations like that I found it important to remind myself that there is a two way relationship. One person asking to take the shortcut (maybe for a good reason) and the other person who can agree or disagree. Even though it doesn’t look like it at the time, one always has a choice.
For permanent staff and maybe even more so for contractors their integrity is an asset. If a contractor gets a name for not having integrity their career will quickly be at an end. Bowing out of the project might not be a good idea short term, long term that decision is invaluable.
Testers are not the gatekeepers of quality, even if it may sometimes feel that way, see the Enforcer in Rob Lambert’s light-hearted approach to tester types. Maybe there’s a reason why people are putting pressure on the tester and threaten their integrity.
Weinberg’s Rule of Three from his book “Secrets of Consulting” states "If you can't think of three things that might go wrong with your plans, then there's something wrong with your thinking." Finding out what the real goal is should be if not the first, but maybe the second reaction. Integrity might not be threatened at all.
The reaction to outside pressure is, of course, depending on the situation and personal values, methods, measures and principles. If the agreed test approach is no longer viable, maybe a new one should be agreed and documented.
If a project goes down that route there is a visible trace of why decisions have been taken and when. The tester protects themselves by getting agreement from the PM and other stakeholders which should be good engineering practice. The end result is the fear that comes with pressure – fear of not hitting the deadline resulting in loss of face, money or job – is removed by taking a realistic and professional stance.
Do I believe that integrity is important for a tester? Yes, of course. We’re some of the last cogs in the software development wheel who can highlight some of the things that might reduce the value of the product or solution our company is trying to sell. Should a tester be results orientated? Yes, knowing how to get the best results fast is important for the business. Let me ask though, when sitting in a plane waiting to take you on your holiday, would you rather have an airplane engineer with results orientation or integrity working on it?
Thomas
PS: Thanks to Rob Lambert for his help to get me started and kind words. I appreciate it.
Subscribe to:
Posts (Atom)