English | EN 
I have several friends who work in the book business as editors. During the last 10 years, I’ve managed to get a glimpse into their work and see how a manuscript is transformed from the first draft into a full-fledged novel.
It is no secret that most authors thank first and foremost their editors when the book is finally published. The book itself has the author’s name on the cover but usually, they remark that they “could not have done it themselves”. This is because the book editor’s job is to make the author shine. They need to polish the work and help build something extraordinary from the author’s creation.
The 2011 blog post by Beth Hill tells us this about the tasks of the book editor:
“An editor polishes and refines, he directs the focus of the story or article or movie along with a particular course. He cuts out what doesn’t fit, what is nonessential to the purpose of the story. He enhances the major points, drawing attention to places where the audience should focus.”
Now this is the idea: the editor and the author both work together in order to make something brilliant.
That is something that we need to embrace also with the developer/tester relationship.
You cannot completely automate the book editor’s job because the book editor does more than just fixing typos. Actually, the autocorrect functionality in word processors is kind of a test automation tool. It automates the parts of the job that _can_ be automated. There is a lot of work that cannot be automated.
Let’s look at that quotation from the blog part by part.
“An editor polishes and refines.”
This is mostly the testing we are most acquainted with. We polish the final product and try to rid it of bugs. We create checklists according to the specifications. We try to make the product error-free. However, we should not just strive for error-free, we should strive for greatness.
“He directs the focus of the story or article or movie along with a particular course.”
This is usually the job of the product owner or product manager, to see if the product actually makes sense. However, the product owner is often not using the software as much as the testers are so the tester has a good view on the whole “idea” of the product. This is why testers should not succumb to “just” run tests, they should analyze the product accordingly. The key question should usually be:
“Would I use this software for a living? Why would I? Why would I not?”
“He cuts out what doesn’t fit, what is nonessential to the purpose of the story. He enhances the major points, drawing attention to places where the audience should focus.”
This is an idea that I haven’t often seen: the tester who tells that a feature actually doesn’t do anything. Usually, these features are later on analyzed to see what features are actually used. Maybe they could be checked upon also during the development phase?
In my opinion, a tester should always also point out if something in the system is needlessly complicated or difficult to use.
We are often discussing the value of tester, showing the risks and how much it would cost not to test the software. We however seldom undermine the value of a book editor. Instead of trying to prove our worth by finding bugs we should prove our worth by showing that the software becomes better, more rigid etc. after it’s been through our pummeling.
This is also something to think about when talking about replacing testers with test automation. Test automation is a vital tool to assist the tester’s work and let them concentrate on the things that cannot be automated.
Tester’s profession should be more than just test cases and bug hunting. I’m looking forward to the day when the software is published live and the developers remark that it might be their code, but they certainly could not have done it themselves.
