thoughts from the test eye

This article is about combining the role of the tester with other roles. These are observations based on my own experiences. I’ve not studied any books or other articles about this.

I assume that each role has its own mind set, focus and goals. I will try to identify the agendas and possible mind sets that I had at each time and then try to form an opinion on how a certain combination worked together with the tester role. I will cover the roles of test lead, test manager, project manager and documentation specialist.

A few objectives/goals of the tester are (taken from materials from Cem Kaner):

• Find defects that matter
• Find important bugs, to get them fixed
• Maximize bug count
• Block premature product releases
• Help managers make ship / no-ship decisions
• Check interoperability with other products
• Minimize technical support costs
• Assess conformance to specification
• Conform to regulations
• Minimize safety-related lawsuit risk
• Find safe scenarios for use of the product
• Assess quality
• Elucidate the design and prevent errors

The tester and test lead have similar, if not almost the same objectives. One observation I can share is that as a test lead or team lead for testing you sometimes dwell a lot on resource planning, keeping everyone occupied at testing. This stole a lot of focus from thinking of new test ideas.

The tester and test manager is a bit different. Depending on which stage you are in organization you will have different agendas as a manager. If you are focused on test processes, propaganda around testing, selling the test concept to the organization or whatever it is, you will behave differently. What I experienced was taking a step away from the actual testing and putting more focus on the processes. I even considered letting certain issues pass, thus not dwelling on them so that the organization can learn from the mistakes. I thought that going in to do this temporary fix would be good in the short run, but it is better for it to fail so that we can have good discussions and perhaps doing something in the long run. Many of these thoughts were contradictory to what I usually thought as a tester. So, in order for this to work I needed to be very clear when I was the tester or test lead in the project and not acting the test manager.

Another experience from being test manager combined with being a tester is the first months of my employment as a test manager. I entered as a tester in a project while at the same time was supposed to build the test organization at the company with everything from introducing tools to having presentations about what testing was. In the project there was a test lead that had no experience from being test lead and little experience from testing. We clashed several times since it was very hard to go from being a tester to being a test manager, often in the same discussion. As a test manager I wanted us to use a bug tracking system and a test management system in a certain way, while he saw no use for these. In any case, it was very hard to do a good job either as a tester or as test manager having different agendas at the same time.

In another situation I was project manager, test lead and tester. I was also supposed to be documentation specialist, but I was able to duck that in the last seconds since I was incapable of taking on a whole new focus in my work. Actually, I almost broke down completely since as a documentation specialist I needed to have full focus on the documentation and manuals. I would not have been able to maintain the meta-perspective as a test lead or project manager at that stage. Combining the project manager and test lead was not that hard, in some cases I made project management decisions with a touch of test lead focus. Still, it was easy to notice that the dominant role was project management having the focus on deliverables, time, cost and resources. In those situations quality was pushed down on the list automatically. When I took on the test role I had to be very clear on that I was tester and that I was allowed to focus on that. Combining these roles was very hard and sad to say, quality and testing did not get the attention that they should have seeing that project management became dominant.

As a summary, if possible do not combine the tester with any other role than test lead. It is too easy to push away the strengths of the tester’s mind-set and objectives. Seeing that project management becomes dominant might also mean that it can be hard to keep the focus on so many things as a project manager. If you think about all the things that testers and test leads do, it will just become too much. In projects where you do not have someone who have the role of tester and test lead you will miss so much. In projects where you have someone acting tester and test lead in combination with other roles, do know that you will not be able to use their full strength and expertise.

I’ve just gone through a three day course in Rapid Software Testing (RST) run by James Bach. This is the first time I’ve seen him in person. I’ve previously seen his responses and discussion from the yahoo group software-testing. I’ve seen the presentation on RST by Michael Bolton and I think either of them would do this well.

I thought he would be a lot more aggressive in person, but he was just inquisitive and straight-forward. It was very nice to hear him talk about ideas and war-stories that are similar to my own experience, but things that I might have not been able to think through. It is obvious that he has a vast experience in testing from many different situations. He talked many times about his integrity in testing (though phrasing it differently), that he has quit projects or jobs when he could not accept the “evil bureaucracy” or managerial demands that was outrageous.

The course itself focused heavily around how to do rapid testing and the concepts around exploratory testing. He had many exercises that were all of them thought through and challenging. I got lots of new ideas for testing, test managing, test theorizing and test planning. As always you were able to get a look at new tools that can be used in testing as well as books that you must add to the bookshelf.

I can recommend doing this course if you want to dwell deeper into the concepts of exploratory testing and rapid testing. I would have enjoyed working with him seeing that many of his ideas are great and along my own ideals.

I spent one day at Øredev 2008 (http://www.oredev.org) since they invited me to give the Where Testing Creativity Grows (http://www.thetesteye.com/papers/where_testing_creativity_grows.doc) presentation.
I arrived ten minutes after the start of James Bach’s keynote The Renaissance Thinker, where he argued that 1972 (Chapel Hill) ruined good software testing.
People started focusing too much on templates, processes, best practices; people forgot about people.
But things are getting better since the Exploratory Testing has been coined and used with more respect.
We also have Agile that is using cyclic learning, in opposite to Waterfall and V-Model where no learning is modeled.
He likes it if people say “James, maybe you are one of the mystics?” and explained his self-learning style of Buccaneer-Scholar.
“Software Engineering is primarily social.”
He has a lot of good things to say; and he presents them in a capturing manner.

This conference is nice since it includes developers, testers, project mangers et.al.
But I stayed at the Test Track all day; starting with Isabel Evans, who is interested in processes and people; and stresses that it is the people in the team, that needs to define the process.
Quality is difficult, since it has so many attributes; the customers view being the most important.
Isabel is criticizing the “standards” from the inside, but think it is important to measure things and report back, e.g. by showing how much money is saved by doing software testing.
“Agile works since it is cross-functional; we work together.”
She also broadened the spectra of our risk thinking; which too often focus on internal risks. But there are Contractual or Regulatory Risks as well as Social Ethical Risks. It is good to think bigger.

Then it was time for my own presentation with about 60 attendees. I had an interesting start with technical problems as my machine wouldn’t use the projector after I launched a movie inside PowerPoint (Yes, I use Vista.)
So I had to improvise a bit and focus on the audience instead of my slides.
After this the presentation went well; and I was happy that an attendant could tell about their paired testing (both scripted and exploratory) where they found three times as many bugs (plus the learning!)
A good question after the presentation was “When do you know you have used enough creativity?” with the answer “Well, you don’t…”

After a lunch break Kevlin Henney talked about “Know Your Units”, with the clarification that a unit test that interacts with something (file system, database, network) isn’t a real unit test.
Programmers are responsible for unit testing (“The programmer who wrote the code is in the best position to test it”) and ”QA” for system testing. (He didn’t mention any collaboration, which I think might be the best.)
POUTing -Plain Ol´ Unit Testing – is passive.
TDD – Test-Driven Development – is active.
DDT – Defect-Driven Testing – is reactive.
And sometimes we can settle with GUTs – Good Unit Tests.
He recommends a black-box perspective for unit tests, where you focus on behaviors, or even requirements. White-box testing can end up testing that the code does what it does.
“We say that system testing takes one month, but in reality, the testing takes a few days, the rest is spent fixing bugs.”
“Testing is a way of showing that you care about something.”
Kevlin is one of many presenters that seem to think and talk better while walking.

Mattias Göransson from Sony Ericsson presented how they have started to use Exploratory Testing with Session-Based Test Management with a Heuristics twist (the original title was “Heuristic Based testing”)
He had borrowed material from Michael Bolton (who has borrowed from James Bach), “with pride”, and explained the Heuristics concept and the flavors Guideword, Trigger, Model, Process.
“We spend more time on test execution and – SURPRISE – we find more bugs.”
They have about 25.000 requirements on a mobile phone, and uses test cases for the major areas, and Exploratory Sessions with Heuristics to get the depth, and higher coverage from the user’s perspective.
Unfortunately he wasn’t allowed to share their heuristics, but he told about the fantastic Staffanstorp Heuristic: if the phone works at a particular place in Staffanstorp, it probably works well almost everywhere.
He explained their heuristics as “experiences they have gained” and pointed out that the heuristics are reviewed after each session.
Other tips: Time-boxing of debriefings is very important.

Nikolai Tillman of Microsoft presented PEX (http://research.microsoft.com/Pex/); a tool that helps you explore single-threaded .NET code by automatically creating unit tests.
The tool analyzes the code and creates representative sets of input values; with 100% Code Branch Coverage.
I think this can be a really good help in getting started with some basic unit tests (and avoid null exceptions); and also a way of learning special cases in code you are re-using.
As merit it should also be mentioned that PEX has been used in .NET components, which resulted in bugs that were fixed.
The tool exists as Academic license for Visual Studio 2008; and early versions of Visual Studio 2010.
“dynamic symbolic execution”

The last presentation of the day before my train left was Pradeep Soundararajan (http://testertested.blogspot.com/) from India. He told his own stories, about how he got fired from a company because he didn’t meet the 95% pass rate of test cases (He found too many bugs!); about very successful testing in a team; and about changing the culture at a company that ran 3000 test cases every week, but never found any bugs.
A very nice end of the day from this member of the context-driven community.
“What is everything? It is secret.”
“Think about the customer’s customer”
“Scripts make people go mad, and sad”
“Using good practices in the right context”
“The brain is an important tool that you should consider using.”

It was a nice day at a nice conference which also included a discussion (or lecture?) in the hallway with James Bach about the schools of testing concept. I was pretty upset with him after some e-mail stuff, but in person I was pleasantly surprised. In his eyes, you can see that he is a really nice person; a main reason for his provocations is that he learns best by arguing; and probably thinks that other people does that as well.

Well, this was enough conferencing for me in a while; now it’s back to the wonderful world of parental leave.

This years EuroSTAR took place in den Haag, a city that had quite some rain, but also beautiful autumn leaves, and big churches.
The theme of the conference was “The Future of Software Testing”, and a recurring image was a traffic sign informing that the future is next turn to the right. I always thought the future was right ahead of us.

James Whittaker started with a really good and entertaining keynote where he argued that software is extremely important, and that the standard software testing will disappear (see http://blogs.msdn.com/james_whittaker/ for details.) On the other hand, he didn’t mention users or value (as Michael Bolton pointed out at the next sessions (sic!) questions), and he didn’t mention that testers do more than just verify requirements on different environments. We perform low-level and high-level validation and verification simultaneously.

Next I saw Derk-Jan de Grood who presented a mix of Exploratory Testing and structured process-focused testing. It didn’t feel revolutionary, since we Swedes have known about both these concepts for quite some time now.
The Austrian Strasser was a pleasant surprise. He told about Borland’s route from V-Model to Agile, and he stressed the people aspect many times. E.g. the teams themselves could decide if they would be split in smaller groups, and how. They have come a long way, and has a lot of unit test collaboration between developers and testers. “1 + 1 = 3”.
Tuesday ended with a keynote from the Google guys behind Testing On the Toilet (http://googletesting.blogspot.com/2007/01/introducing-testing-on-toilet.html) who has a really good story to tell. And it is a lot bigger than the Toilet, they have done a lot of things for more than three years in order to raise the awareness about testing at their company. A big accomplishment that I think is difficult to repeat at companies that don’t have “20% Time” (At twenty percent of your working time on Google you can do something completely outside your normal activities.)
After the presentation they were asked: “Do you have any objective metrics that can show your results?”
And I was really happy about the answer: “Metrics are difficult, there are so many factors involved. We rely on anecdotal information.”
They also stated: “There will never be a time when you don’t need a solid QA group.”
Wednesday started with Randall Rice sharing his thoughts on the trends that may shape the near future. Some general and good information, but not so much to write home about.
He recommended howtosplitanatom.com for articles on Web 2.0/3.0 and he said that a drawback of SaaS (Software as a Service) is that customers won’t have any control over which version they are running.
Julian Bensaid talked about outsourcing, and how to avoid, and quickly get out of “The Damage Zone”, the phase when thing are going a bit too bad for too long. He stressed “One Team” and said that “You have to innovate to make outsourcing successful.” “Devil’s Square”: quality, time, functionality, money. At question time, he let the audience answer their questions!

Then it was time for Michael Bolton’s double session workshop on Heuristics, which was the next best event for me at the whole conference. He really knows how to talk, he has important things to say, and the exercises stimulated good conversations with the other attendants. (The results are available at http://www.flickr.com/photos/23076491@N02/sets/72157608997920373)
Also, a good presentation stimulates your thinking to new ideas; and I thought of a new definition: “A good tester knows when to break the rules” and I’m wondering if some very good heuristics could be created at your company, where you have the details.
“Maybe testing isn’t supposed to be easy”, “We have to look complexity in the eye”, and he recommended positivedeviance.org.

Next it was my own presentation: Testing is an Island – A Software Testing Dystopia(link!). It went really well, except for one moment when I just couldn’t find any words. I excused myself, took a sip of water, and just started talking again; and after that I really can’t remember exactly what I said. I remember I said the important things, that I referenced some earlier presentations in the way I intended, but I can’t remember any details. I’m pretty sure I explained something in a completely new way that was really good, but I don’t know what it was. I see this as a good thing; my mind was in a state of flow.
Of course you only hear from the positive ones, but it seemed like people agreed that the human element is very important for us testers. I was also happy to hear that my presentation was very different from the other sessions, and that they like this different, thought-provoking angle.
I guess the introduction movie Mårten Ivert and Henrik Emilsson did was very helpful, just because it is so good!
One question afterwards was if/how I could convince people who think that emotions is a bad thing when testing. I said something about not having any proof, but that I might try by saying that we like emotions in life; so why shouldn’t we have them at work as well (Work is a part of our life.) Testers should also in some sense mimic users, that has feelings. I didn’t think about referencing Boltons excellent lightning talk on Emotions (http://www.developsense.com/2007/05/lightning-talk-on-emotions-and-oracles.html)
There was also a questioning regarding Agile development contradicting my dystopia; wasn’t that a way towards testers being more integrated in software development. I agreed, but also said that if the testers are brought in, in order to create unit tests instead of the developers, maybe it’s not totally positive. We need to look at many aspects.
Another good input was that testers who changes projects and companies, get a more holistic view, since they see more different things.
That’s a valid objection, and my defense was the team aspect, which is lost if people switch companies often. Best of both worlds might be to spend some time at a different place, and then come back.
Questions are the best part of presenting your ideas.

After this I went to a “Manifest Workshop”: Can the Past tell us the Future? This was nice because you got to spend some time talking to people about what has happened with our profession over the years. There are a lot of agreement and good ideas, but you also hear some things you can’t agree with, e.g. “Testers should have the mandate to change”, “Testers must have a special education with a title” etc.
This Manifesto extended over several workshops, and will be available at www.softwaretestingmanifesto.org; but I didn’t sign the acknowledgement list, even though they had an idea of “Anti-Manifesto” statements.
Wednesday ended with a casual session that generated some laughs: The EuroSTAR Testing Quiz.
Erik van Veenendal started Thursday with a keynote on TMMi. This is not my favorite subject, since “process-only” doesn’t say anything about how good the content is.
So I was glad that Erik started with saying that process isn’t enough; you need skilled people and a good infrastructure as well.
I also liked his statement that if you can take a Test Policy and apply it on a similar company; then the Policy isn’t worth anything. 
To succeed with a Process Improvement you need to have Management on board; and unfortunately they only listen to numbers (how long will that be true?)
You also need to spend a lot more time than Friday afternoons (Erik said 60% was necessary); and you need to focus on why you are doing it; what isn’t working good enough?
But Erik sometimes goes back to the Dutch formalized approach: the testing lifecycle should be Test Plan -> Test Design -> Test Script -> Execution.
“People want to change, but they don’t want to be changed.”
It was a good presentation, but unfortunately Test Process Improvement schemes aren’t generally good; most of all because it lacks aspects like creativity, and the ability to find all important errors.
I didn’t ask if there is a risk of becoming too mature, over-ripe, rotten.
On the other hand; you can read TPI, TMMi etc. and get really good ideas on what to do.

Egbert Bouman had presented his five favorite inspirational management Gurus, and how they could be applied to testing.
E.g. “Make company and personal interests run in parallel”, “People are complex.”
But I think it might be dangerous to transfer ideas from different areas without critical thinking. For instance, Collins Hedgehog Concept is about a company in the market that stick to doing what they are great at.
But in testing, we aren’t market-driven, we rather provide services/information to the project; and wouldn’t it be a bad idea to test software in the same way year after year?
He agreed a bit on this at the Gala Award Dinner, but also said that it differs if you are employed by a company, or if you are a consultant. But we discovered that we both were fans of Kierkegaard, and Morten Hougaard joined in this appraisal. “The truth is the subjectivity.”

I skipped Stuart Reid’s workshop on ISO29119. I was interested in how they are working, but I was sure I wouldn’t like the result; too much focus on standardization is killing creativity.
Tim Koomen jumped in at last minute and gave an overview of the testing industry in the past, present and future. He has a good understanding, and talked a bit about Pairwise (I don’t like it), Exploratory (I like it) and Model-based Testing (Surely good in the very few situations it is truly applicable.)
He also had survey results showing that only 1/3 of software testers are using Test Design Techniques (on the other hand; who isn’t implicitly using Equivalence Partitioning all the time?)
“Let’s use the existing techniques a little bit more.”
It was also nice that he brought up the classic Triangle Exercise.

John Kent have created a better Entity Model for Software Testing. “All models are wrong, but some models are useful.”
He used the name Test Condition for Test Ideas, which I think are central in our universe.
He showed a Test Case example, and I really feel sorry for all those testers that has to write or follow Expected Results for each and every test step in a Test Script.
He had a Real World Waterfall Model that started with “Produce requirements which are incomplete and slightly wrong.”
And he ended with the idea that in some situations you might better throw out these Entities and go for only Test Ideas; the tester will know what to do.

After lunch break Michael Bolton gave probably the best testing presentation I have ever seen: Two Futures of Software Testing.
He was wearing horns when talking about the Dark Future that is static and mechanic, and a halo when talking about the Light Future that has the testers human skills in the centre.
His message is very close to my own, with the difference that he has a lot more to say, and he does it extremely well.
It was so good, so I didn’t have time to write down any of all the good things he said, an old version of the presentation is available at http://www.developsense.com/presentations/twofuturesofsoftwaretesting.pdf.

The last keynote was James Lyndsay: Becoming Agile – Reshaping Testing for an Agile Team.
Agile exists, it is growing, and often succeeds with its projects, independent of the inclusion of testers or not!
But the testing performed is confirmatory, and that isn’t enough, so the tester approach is needed.
And in some ways; Agility and Testing is conflicting. Agile is highly optimistic, and testing is perceived as the opposite. Testing is used to be independent, must now be part of a team commitment. To explore for dangerous information might need feel good.
It is not necessary for a tester to know programming to enter an Agile team, but it is an invaluable asset.
He showed some statistics from www.ambysoft.com/surveys/agileFebruary2008.html.
And his main point in a very good presentation was that testers should help the team learn more about what they are building.

The conference was concluded with dinner in Grote Kerk where I sat next to a penetration tester; and beers at a pub, which really encourages many conversations.

Top 3 themes on the conference as I saw it was: People, Complexity and Agile.
EuroSTAR is a good conference, it has a nice aura of knowledge sharing.
Other things: Hoegaarden in Holland has so much more aroma than in Sweden.
Stuart Reid was walking around with a yo-yo.
My main attraction on the EXPO was the company that had a chess board. I played a game, won, and was thereby included in a lottery; and since only one other person won, I had the 50% luck of actually winning an IPhone!
I didn’t have the chance to see: Mieke Gevers, my nice Track Chair; The good title “Imagination is more important than Knowledge”; Fabian Scarano who in his paper and presentation mention serendipity.
It was a tie between really good Mexican and Argentinian dinner.
Isn’t it true that good testing should create low-hanging fruit?

Next Year EuroSTAR will be held in Stockholm, again! A bit boring; Barcelona seems like a more exotic place at least for me.
My current idea is to create a presentation consisting only of images; have a good name like “7 Ways to Explain Software Testing”, and then write a fluffy and nice abstract…
Or maybe try titles like Test Ideas – the Center of the testing universe; Generic Test Ideas for Data Types; What I Learned After 9 Years At Spotfire; The Holistic-Subjective School of Testing; The Eye of a Skilled Software Tester; Verification, Validation, and Everything In Between.
/Rikard

The short answer goes:
No, of course you can’t!

Once upon a time, I got the possibility to read a test strategy document written by a business colleague of mine. The strategy was a 47 pages document that tried to cover all aspects of testing that I guess would apply to all projects; because in the beginning of the document, it was stated that the strategy is “… generic in nature and should apply to any I.T. project.”

If you try to interpret the statement above, it means that the strategy is non-specific and there is no project that this strategy would not be applicable for.

How is that possible? And why would it even be interesting to use such strategy? And for whom is this strategy?

Would you trust your national army if they had a generic strategy that should apply for all wars? Could it be so that combat situations, terrains, opponents, stakes, etc could differ?

Would you feel confident in your company’s marketing department if they had a generic strategy that should apply for all future marketing engagements?What if you had a generic strategy for playing chess and not adapt to your opponent moves? A strategy that would treat each game same as the others.

What if you had a generic strategy for raising and fostering your children? Or what if you had a generic strategy for how to interact with your colleagues? What if these two strategies were the same, since they are generic and would apply to any human social interaction?
Is there a chance that other people might think that you are strange if you had one generic social interaction strategy?

The context differs between different projects; and the context often changes during a project.
We would be doing all project stakeholders and members a favour if we designed a test strategy that was driven by the current project context; a test strategy that would be updated whenever the context changes. That is, a test strategy that is specific to this project and is therefore only applicable to this project.

The other day I was using Google Chrome to browse through internet.

One thing I did during that session was to try to download an evaluation of HP Quality Center. I was struggling to register as a user and try to download, but it was not possible.

But how does this relate to Google Chrome? I am not sure if this might have to do with one of their EULA-paragraphs about google owning all data sent to their server:
The day after I had the attempts to download the demo, a woman from IBM called my cell phone. And what was she offering? You might have guessed it by now?

She wondered if she could tell me more about the IBM Rational Testing suite.

Was this just a coincidence? I don’t know…

At EuroSTAR 2008 in Haag I will present “Testing is an Island – A Software Testing Dystopia”. The paper can be downloaded at http://www.thetesteye.com/papers/redgren_testingisanisland.doc

The inspiration was the theme of the conference: “the future of software testing”; and I couldn’t stop seeing a very boring profession, where numbers and so-called objectivity is more important than people and feelings.
There are trends and silver bullets that miss our secret: we perform simultaneous verification and validation.

Test patterns, quality patterns, Q-patterns or whatever we wish to call it. I am referring to test ideas that can be reused in similar contexts. This could for instance be File Handling, Data Types, Installation, Upgrades etc. There is nearly an infinite list of areas that could test patterns could be available for.

When you start a new project with test areas that you are not all familiar with… you wish to have some test ideas or test patterns that you might be able to apply easily. Experienced testers usually have this documented or in their heads. The test patterns created for one company is usually proprietary, so you are not allowed to bring it with you.

So when you start from scratch at a company there is a lot to wish for. You try to use what you have and need to adopt to possibly new systems. Eventually you will notice that you have almost started from scratch. You start redoing the same things that you have done before at previous companies.

I have asked some of the major test consultancy companies about how they do with test patterns and test data. So far all of them has looked at my strangely and said that it is not possible to reuse the test cases they produce. Also, that these test cases are property of the customer.

Imagine that consultant companies with a few thousand testers start assisting each other with test data, test patterns and experiences. Generally, it seems like they are not doing this at the moment. The smaller companies would have a hard time to compete if this was the case.

If there was a public website where these kinds of data could be stored it would make things easier for all testers. Perhaps it is a dystopia, but I see no reason why we need to rethink our test ideas each time we get to a new company. I can understand that these test patterns in themselves hold great value to the company and that they would like it to be theirs alone. Still, I think it should be possible to have the general areas more public.

If anyone have thought of this before and know of a place where to find these so called public test patterns and test data please assist me in pointing me in the right direction. If not, is this something we should take the initiative in starting?

I need to recommend a great book by Rajiv Chandrasekaran: Imperial Life in the Emerald City.
The reason I recommend this book on this blog is that the more I think of it, the more I think it resembles the way how certain processes or methods are implemented in the sofware industry without taking the context into account.
I.e. this book is a great example on how to implement something in a non-context-driven fashion!

Right now, somewhere in the world, test processes are implemented:
* that are not tailored to the needs of the majority of the affected people;
* that will make it harder for the people involved to do a good job;
* that look ridiculous;
* that are best practices according to XXX;
* because of political reasons;
* because someone said so;
* etc…

When reading this book, you will sometimes laugh out loud.
But at the same time you wanna cry when you realize that this actually have affected thousands of people and indeed a whole nation. It is really scary…

Below is an excerpt from the authors’ site http://www.rajivc.com/book.htm

“Imperial Life in the Emerald City is an unprecedented account of life in Baghdad’s Green Zone, a walled-off enclave of towering plants, posh villas, and sparkling swimming pools that was the headquarters for the American occupation of Iraq.The Washington Post’s former Baghdad bureau chief Rajiv Chandrasekaran takes us with him into the Zone: into a bubble, cut off from wartime realities, where the task of reconstructing a devastated nation competed with the distractions of a Little America—a half-dozen bars stocked with cold beer, a disco where women showed up in hot pants, a movie theater that screened shoot-’em-up films, an all-you-could-eat buffet piled high with pork, a shopping mall that sold pornographic movies, a parking lot filled with shiny new SUVs, and a snappy dry-cleaning service—much of it run by Halliburton. Most Iraqis were barred from entering the Emerald City for fear they would blow it up.

Drawing on hundreds of interviews and internal documents, Chandrasekaran tells the story of the people and ideas that inhabited the Green Zone during the occupation, from the imperial viceroy L. Paul Bremer III to the fleet of twentysomethings hired to implement the idea that Americans could build a Jeffersonian democracy in an embattled Middle Eastern country.”

At www.context-driven-testing.com you can read “Metrics that are not valid are dangerous.”
I believe this is true, but I would rather prefer “Metrics are dangerous.”

Uninterpreted measurements are not bad by themselves, but when value is added to them, they become metrics, and dangerous because they state specific things without considering a lot of other things, that actually might be much more important.
If measurements are used together with knowledge of details, you might have an analysis that is fruitful.
But at many times, sound judgment not only is enough; it is better.

Measurements/Metrics are probably useful for dead things, like manufacturing objects, but m/m are not good for complex things involving people, e.g. software testing. Metrics uses numbers to reduce the complexity and thereby the “truth” disappears.