(Reprint) Bullying in Tech - It Has to Stop

(A reprint of an article I wrote for Testing Trapeze Magazine, published in its final issue in Dec 2017. Published on this blog as I still regard it among one of my best pieces of writing and its message remains as important as ever. Thanks to Katrina Clokie and Sarah Burgess for their editing).

From Pixabay, CC0 Creative Commons

"I see you're putting on a bit of weight, aren't you Paul!"

"Beg your pardon?" I turned around to face my boss at the time, who was standing behind me.

"You're getting fat aren't you."

I was nervous. How should I react to a senior manager making a statement like that? Do I argue back, remain silent, jokingly agree with him?

"If you say so..." I returned to work.

He said it again a few weeks later. One of many underhand comments about my weight. His power over me at an early stage of my work life, the power to determine if I was employed or not - if I could pay my rent or not - was enough to make me keep my mouth shut.

Some years later, in another team, I was frequently berated by some of the developers. Anger and open ridicule if I made a mistake (especially in front of my two colleagues as test lead), sarcasm in front of colleagues, commenting about and mocking the words I used in conversation. In the workplace I deemed it utterly unprofessional and unacceptable. However it took me several months to approach the project manager about it (who tried valiantly to stop it, however even he wasn't totally successful) and even longer to call it the "B" word.

I am by far not the only person who has had to deal with workplace bullying. The union Unite, based in the UK, reported the following in a ComputerWeekly 2008 article.

"One woman quit after she received e-mails last thing at night with work to be done for the next morning, was given impossible deadlines to meet, and was ridiculed in front of her colleagues."

A 2014 article on the HR website IDGConnect.com describes the story of another victim, "Alex", as follows...

“It was quite insidious... The odd comment here or there. And he’d work his way through the team. Then he started on me and I stood up to him… and it got really ugly. Really ugly - to the point where I went and got a lawyer.”

Apparently, it took "Alex" five years to start to overcome the mental trauma of her mistreatment.

These are not isolated cases. The scale of bullying and unfair treatment in the tech industry destroys health and careers, costing the industry billions in reduced performance, sick leave and staff turnover. We should be doing better.

The Scale of the Problem

Various surveys, and high profile bullying and staff mistreatment scandals over the past 20 years paint a gloomy picture.

The first survey I could find was written in 2002. 3500 UK staff were surveyed by Mercer Human Resources Consulting. 21% of respondents claimed they had been bullied at least once in the past year, with 7% of those suffering chronic bullying. Of those bullied at least once, 24% were middle managers and 17% were senior managers. Those lower down the management chain were more likely to be bullied. In reference to bullying flowing downhill, Mercer’s Patrick Gilbert states, "The high rate of bullying among managers is a particular area of concern. If managers are the victims of bullying, they are more likely to bully the people they manage."

In the previously mentioned Unite survey of 860 UK IT professionals, 65% believed they had suffered workplace bullying. Examples of the types of behaviours reported in the survey were -

"..unachievable deadlines, excessive monitoring and supervision, and constant criticism on minor matters. More than half said they had been bullied by a more senior member of staff."

"The survey found many victims felt unable to report bullying because of fears that it would get worse, or because they thought their complaints would be dismissed as an inability to cope." A wall of silence had developed with victims feeling unable to speak out.

The Kapor Centre for Social Impact's 2017 Tech Leavers Study surveyed  2006 workers in the US who had left a technology-related job in the past three years. It included questions on bullying, public humiliation, and rude and condescending behaviour, with a focus on minority groups.

Taken from the survey -

"LGBTQ employees were most likely to be bullied (20%) and experience public humiliation or  embarrassment (24%), both at significantly higher rates than non-LGBTQ employees (13%, p<.01).

White and Asian males experienced bullying (16%), public humiliation (16%), and rudeness (25%) more frequently than underrepresented men (9%, 11% and 19%).

Bullying and hostility were most often perpetrated by senior-level employees (53%)"

Uber

The culture of bullying and harassment among some Silicon Valley startups, particularly Uber, have been heavily criticised, notably by Margaret Heffernan in the Financial Times . Heffernan described a "frat boy culture of bullying and exclusivity" that limited the prospects and representation of women and minorities. She pointed to the scandals at Uber, which had recently fired 20 of its staff and deposed its CEO Travis Kalanick over 215 claims of discrimination, unfair treatment and sexual harassment. Of these 33 claims related to bullying.

France Telecom

An even more sad and devastating bullying scandal arose at France Telecom (now Orange SA) in 2009, following as many as 35 staff suicides in two years. Whilst France Telecom claimed that the rate of death by suicide was in line with the French average (16 per 100 000 in 2006), many left suicide notes blaming "unbearable work pressure, bullying and 'management by terror'". Alongside this  "scores of other staff, from senior technicians to staff who worked processing bills, were saved as they attempted to kill themselves." Some suicides were attempted in the office during the workday.

In the tragic case of the suicide of Michel, 51 -

"There was this pressure from the top to slim down operations by destabilising workers, people were undermined to the point that they got ill," his sister claimed. "He told me he was regularly sent messages from managers suggesting he find work elsewhere. Once they suggested he open a rural guesthouse. He accepted a far too heavy workload out of fear of losing his senior job."

According to an official report by the Works Inspectorate the blame was laid on a climate of "management harassment" which "psychologically weakened staff and attacked their physical and mental health". France Telecom was restructuring at the time making 22,000 jobs redundant and moving 14,000 jobs to different locations. The mishandling of the moves was seen as a major factor in some of the attempted suicides, a claim denied by the CEO, Didier Lombard.

Lombard, under heavy criticism for his poor handling of the tragedy - particularly his dismissing of the suicides as a "fashion" at the company - was forced to step down from his post in 2010. In 2012 French media published an internal memo from 2006 where he stated in a high level meeting that he would cut staff "...one way or another, through the window or through the door". Following these revelations, in 2016 the Paris Prosecutor recommended that he and other senior figures at France Telecom be put on trial for "moral harassment" (the legal term for bullying in France). According to the BBC, "the Paris prosecutor accuses France Telecom of enacting a policy in 2007 that resulted in unsettling workers and creating a "professional climate that provoked anxiety" at the time of a "delicate restructuring" of the company".

Effects of Workplace Bullying

Both the individual and the technology industry suffer when there is bullying in the workplace.

The Australian Human Rights Commission in its factsheet "Workplace bullying: Violence, Harassment and Bullying" states “If you are bullied at work you might:

• Be less active or successful

• Be less confident in your work

• Feel scared, stressed, anxious or depressed

• Have your life outside of work affected, e.g. study, relationships

• Have physical signs of stress like headaches, back aches, sleep problems”

In extreme cases, such as those arising from the toxic culture at France Telecom, the effects  can lead to severe depression, sickness and suicide.

At industry level, according to the Tech Leavers Study 2017, the cost of workplace unfairness (which combines bullying with other damaging practices such as sexual harassment, racial and sexual discrimination in promotion, skill underutilisation, and stereotyping) is  "astounding", both in terms of turnover and reputational cost. Based on an estimate of the turnover cost of a tech employee being $144,000 USD, and the findings that nearly 40% of employees reported leaving their jobs due to unfairness, an estimate to the US tech industry alone is $16 billion per year!

On top of that, according to the study, former employees who were unfairly treated would be 35% less likely to refer someone to that employer, and 25% less likely to recommend buying or using their products.

Compound that with increased sick leave and the risk of litigation and it makes good financial sense to eliminate workplace bullying from our industry.

Stopping Workplace Bullying

Julia Moriarty from The Network - a company that works with clients to stop workplace bullying - states in this article:

“The key to avoiding a negative and disrespectful work environment is to establish and continually support a strong, consistent corporate culture that stops the inclination to bully before the behavior starts.”

"Management has to take the lead. Many organizations don't want to acknowledge that bullying is happening in their workplace - but it is. Keep in mind that a lot of bullying activity may be covert and may not be visible to company leadership until the damage has been done..."

The risk of victims resigning or losing their job is a source of great worry. The article quotes data from the Workplace Bullying Institute that states "56 percent of reported bullies are the victims' boss; 33 percent report that a coworker is the bully, leading many victims to believe that either they'll be fired for reporting the abuse or that their bully will simply ignore their complaints and escalate the abuse."

Moriarty recommends that a “No Tolerance Policy” be instigated and that an executive level position or independent team be allocated to corporate ethics and compliance - reporting to the CEO or board of directors. The position or team must be able to set behaviour guidelines and make objective decisions such as disciplining or dismissal without fear of reprisal or overrule due to office politics or financial concerns. Management also needs to respond quickly to reports of bullying and conduct a transparent investigation with real consequences for those found guilty of bullying.

Managers should receive training on compassionate, effective management skills and techniques. Moriarty states, "All of the training and communication in the world will have no impact if the culture of the organization does not support what is being taught. Managers need to walk the talk and demonstrate respectful behavior themselves. Performance reviews should take into account management style and ethical behavior to ensure managers take the company's standards seriously. The company needs to provide coaching for managers who demonstrate bullying-type management practices and, if they cannot correct their behavior, remove them..."

Peter Skyte from Unite and Cary Cooper from the University of Lancaster offer various tips for managers including, having a strong anti-bullying mission statement and a clear process to be followed if bullying occurs (including escalation beyond the immediate manager if considered part of the problem). They also prescribe a process of swift and decisive action against the bully along with victim support.

What about if you are the target of workplace bullies? The University of Wollongong's Brian Martin offers advice on how bullies work and how to react. His tips are outlined below -

• Expose the bullying.

• Validate the target, by demonstrating good performance, loyalty, honesty and other positive traits.

• Interpret the bullying as unfair, and explain why contrary explanations are wrong.

• Refuse to be intimidated or bribed, and expose intimidation and bribery.

Interestingly, he recommends being sceptical of reporting to official channels, instead mobilise support in other ways. In his words,

“It's tempting to seek help by using formal processes, for example reporting the matter to the boss's boss or to the board of management, making a complaint using an internal grievance procedure, or making a submission to a review panel. Unfortunately, this seldom helps and can actually make things worse.

People high up in organisations nearly always support the chain of command. A top manager will almost always support subordinates in the face of challenges from lower-level employees."

The Workplace Bullying Institute offers additional advice in what it calls its “3-Step Target Action Plan”. It recommends naming the behaviour as bullying, taking sick leave to heal and decide on a counterattack, and then exposing the bully. Nevertheless, it makes the grim point that in most cases (77.7% of cases in its own statistics) targets of bullying are likely to either lose their jobs or choose to leave the company. It recommends starting the search for a new position.

Epilogue

Incidents of workplace bullying and harassment are causing reputational damage to the tech industry as a whole, and are a blight on the victims. We must come together as a community to stop bullying and the fight against workplace must be supported at the highest levels of the company.

Compliance teams must be given autonomy and power to remove toxic staff and cultures. Victims must be able to have their grievances heard without hurting their own job and career progression.

Stopping workplace bullying is a thing we must do. To protect the wellbeing of workers in our industry, as a moral imperative, and to reduce costs to companies and the industry as a whole.

On Being Called a Testing "Expert" or "Guru"

About a year ago someone contacted me on LinkedIn to thank me for a talk I did last year on test data  frameworks for automated UI tests. His words were "Thanks.. You're a Test Automation Guru!"

I was a bit stunned, although of course flattered and honoured, by this. The person who contacted me had about ten years of experience in UI test automation with what appeared to be a wide range of tools. I had between three and four years on and off, using a smaller motley of tools and frameworks from the rather redundant White Framework for .NET to Selenium (to good and bad results), along with being reasonably competent at knocking out code in C#, Java and Python. The difference between he and I is that I once had to solve some problem by using a very easy specimen test generation framework written by someone else off the internet and then got invited to speak at a few conferences on it. Much of my career (including my last few projects until changing jobs) has been in manual (or very limited automation) testing gigs. To me, he was the "guru"!

Not long after that I got a notification on Twitter that somebody had added me to a list of "Testing Thought Leaders". My first thought was "Have they confused me with someone else?"

In the last project before my current job I mentioned in the interview that I spoke at a few conferences and have a blog on testing. After I was appointed, in the first month or so I had at least three or four of my fellow testers telling me (in a quite reverential tone) that they heard I am a famous testing "guru" or "expert" and that they were desperate to learn from me. I downplayed it, saying that I had a blog and had done a few talks at conferences and meetups on testing - that was all. While I was lauded as particularly good at spotting and raising defects I don't believe that my performance in that place was vastly better than those of my colleagues who had never been to much less spoken at a testing conference, or blogged or tweeted obsessively about testing as I do.

The idea of being considered an "expert" or "guru" in tech or even testing is quite unsettling. I'm a long way from being considered a well-known and respected name in the testing industry - much less the next James Bach, Michael Bolton, Angie Jones or Rex Black. I'm not sure that even the really big names in our industry are comfortable to wear the title of "guru", such a loaded term as it is. Nobody has some irreproachable insight into achieving quality in all situations - there are no gods in this industry - and there are as many exceptions as there are rules.

Whilst I would imagine that being called an "expert" or "guru" provides benefits in having testers respect your opinions, getting gigs as a consultant or contractor, writing high-selling books or being invited as a keynote speaker to any number of conferences and seminars, it also comes with enormous expectation. In my last gig, while being labelled a "guru" by my colleagues I was petrified of making mistakes or stating an opinion that could be wrong or challenged. I also felt as if I needed to continually promote new ideas in meetings and be seen to be "cutting edge", regardless of the state of the testing processes, the resources available or whether people were capable of or interested in acting on those ideas.

The idea that some people may consider me as a "guru" or testing "thought leader" (as opposed to how I see myself as someone who just has ideas and likes to talk about testing topics, caveat emptor) has sometimes resulted in my censoring what I write about in this blog or post on Twitter - the idea being that if my thoughts and writings are not completely polished then I will be judged accordingly and should refrain from posting them.

I consider myself a good tester with an interest and active involvement in the field, however the field of testing and the fields it touches upon (development, devops, process management, reporting etc.) are so vast and change so rapidly that even in my ten years of working in the field I only know a small amount. I am about as much an expert as we are all - experts of the specific areas and projects that touched upon our own experience and interests at the times we did them - and our knowledge and our relevance becomes more redundant by the passing day  - a quite intimidating and humbling fact that I related to in my first "Tester Mid-Line Crisis" article. Self-study does help to counteract this and keep one relevant, however without the opportunity to put what you study into practice in a work context (a struggle I have had in some projects) it only gets one so far.

I also think if we put those who have had the privilege to speak at conferences and who write blogs one the pedestal of "testing experts" or "gurus" then we intimidate newcomers who want to do the same - many of whom are more than capable to adding great advice and perspective. James Bach, in his 2002 StickyMinds article "Becoming a Testing Expert" describes it so -

"What we're left with, a lot of times, are candidates who are overconfident in their ability to find good bugs. The same holds true for conference speakers. I've met dozens of interesting people at conferences who have helpful advice and interesting experiences. But when I encourage them to get up and speak or to write an article, most of them say, "Well, I'm not an expert. I don't know the right answers. I haven't read all the books." Valuable insight thus remains bottled up inside the self-skeptical minds of many excellent testers, while too many people who do speak and write could stand to put their ideas through a little more testing."

This is a shame as nobody is ever the polished article at the beginning (I am nowhere near it now) and testing as a profession and practice gains much from its diversity of background, experience and opinion. Saying that, what I have seen and quite liked in testing conferences is less of speakers relaying grand, abstract ideas in the style of university lecturers and more speakers talking about and critiquing the application of various testing practices in their environments, projects and teams - along with what they learned. In this vein, we are all experts in our part and have something others can gain from.

The Fear of Age and Irrelevancy - On the Tester's Midlife Crisis (1)

I have managed some notable achievements this year which I am proud of. I have spoken at three conferences (to mixed responses admittedly), been invited as a guest onto a couple of podcasts and got a new job with great colleagues that I am very happy with - only my third employer in testing in a ten year career. Thay was after seven years working for a really good testing consultancy on various projects.

However despite the achievements above I am just as uncertain about my career and progress as before. My father, who I was the main carer for was battling cancer for the past year, sadly passing away on the 3rd December. In order to look after and be there for him I stood down from various activities and roles I was proud of - notably my co-chair role in the Sydney Testers Meetup and my blog and test automation live stream. I also withdrew from my postgrad studies in CS for a semester, my second withdrawal in 18 months - delaying my graduation by a year.

My Worries Set In

I don't begrudge any of the above - one's family is invariably more important than one's job, extracurricular test-related activities and university studies - however I do feel angst about it. Angst that I am getting older and my technical skills in testing (learning Postman aside) haven't developed in the past year. Angst that everything is changing and my experience is no longer relevant - a redundant dinosaur. Angst that there are so many tools and techniques I haven't learned or had much commercial experience in - Devops, CI/CD, NoSQL, Protractor, mobile automation etc.

Angst that in a tech industry that values - even fetishises - youth and dynamism and where change can wipe out the benefits of experience in a heartbeat, I feel close to being seen as "past it" and "over the hill" as I imminently approach my 40s - to be replaced by younger hotshots on the cutting edge of testing.

Is this just Paul's paranoia getting to him? Maybe. However anecdotally, in chatting with Sydney Testers and conference attendees I have come across similar angst in others. Testers in their middle age concerned about being left on the scrapheap or not finding a job at all, or alternatively desperate to learn automation even if they don't like programming particularly. I have spoken to a few who have noticed their colleagues being younger, more technically skilled, clued up on the latest buzzwords and willing to put in long hours. Sydney, Australia where I live is about as brutal and competitive a tester job market as you can find with 300-400 job applications per advertised role a routine occurrence.

I have also come across people around my age and older who are greatly dissatisfied or apathetic with testing. They feel that they aren't getting anywhere in their careers or are tired of the constant learning to stay relevant. They feel that they are being poorly treated or paid much less than their developer colleagues even though they all work in the same teams. They hate the low status of testing compared to other areas of software development. They regret not choosing other employers or doing something else earlier.

A Tester's Mid-Life Crisis?

Within the past month, and especially with the inevitable introspection arising from my father's death,  I have begun to think of the above as a sort of tester's mid-life crisis - a career or professional identity crisis caused by one's approach to middle age. What are the features of a mid-life crisis?

According to Wikipedia, typical career related mid-life crisis symptoms may be -

• a deep sense of remorse for goals not accomplished
• a fear of humiliation among more successful colleagues
• longing to achieve a feeling of youthfulness
• ennui, confusion, resentment or anger due to their discontent with their marital, work, health, economic, or social status
• ambitious to right the missteps they feel they have taken early in life

The term "Mid-Life Crisis" itself is contentious. Evidence that it exists at a grand scale at all or the ages when it starts is mixed. According to this article it happens anywhere between between the ages of about 37 and 50.

While it is anecdotal and not scientific there is some evidence that the particular nature of the tech industry makes things worse and harder. This article in KrAsia uses the stories of various high fliers in the Chinese tech industry where long hours and high pressure, ageism, rapid change arising from company acquisition and restructuring and resulting periods of unemployment forced them into a mid-life crisis while in their mid to late 30s. This article in CNBC, following on a from a post on Quora, reports that Silicon Valley tech staff even no more than 35-40 years of age can feel over the hill in the tech job market. This was deemed partly down to ageism, an interview process that favours young recent CS grads and being surrounded by younger talent. Encouragingly it did also list success stories of those who were in their 40s and above who were progressing in their careers in the big Silicon Valley tech firms.

A Twitter Chat

I posted on Twitter the following update -

If there is such a thing as a Tester's Mid-Life Crisis, I think I may be in the middle of it....

— Paul Maxwell-Walters (@TestingRants) December 21, 2018

I was surprised at the number of responses I had from testers far more established and famed in the industry than I who offered consolation or stated that I was not alone. Posts of being unhappy with being a tester or that the testing community was great but stifling.

Epilogue

This is the first of a sequence of articles detailing what I consider my "tester's mid-life crisis". Based on the feedback from this and resources existing to alleviate the kinds of angst and worry listed above I will write further articles in the coming weeks. I would like to know your opinions and your experience - if you can share them then I would be most grateful.

In the meantime I wish you a Merry Christmas and a Happy New Year!

On What the Famous John Barnes Rap Can Teach us about Software Engineering Practice

A Short and Tongue-In-Cheek Treatise on what the famous John Barnes Rap (from England's World Cup 1990 official song) can teach us about development and Software Engineering practice.

1) "You've got to hold and give but do it at the right time"

Knowing what and when to delegate is a critical skill of any dev or test lead. Be always aware of the demands placed on your staff and ensure that you delegate work they have the skills and time to finish and no more.

2) "You can be slow or fast but you must get to the line"

There are times when it is understandable to prioritise speed over some quality (i.e. for a new startup with limited resources pushing to be the first to market), however generally it is good to prioritise project quality and delivery over fast completion for the sake of it. Be wary of demands by management for unrealistic or deleterious deadlines. Getting to project completion with good quality is all important.

3) "They'll always hit you and hurt you, defend and attack."

It is true that implementing process change in software engineering may well cause friction in teams. You may face resistance, be it by fearful defensive colleagues or naysayer managers. Influencing skills are crucial.

4) "There's only one way to beat them, get round the back..."

To implement quality principles you may have to alternatively solicit support and resources from PMs, stakeholders and CIOs.

You could also implement a pilot or smaller solution yourself and demonstrate it.

5) "So catch me if you can cause I'm your England man"...

The English software engineering job market is competitive and favours those with quick thinking and the ability to hit the ground running.

6) "And what you're looking at is the master plan"

Overarching master development and test plans are discouraged in agile development but can be sometimes useful. If you do use them, share and explain them with your team and appropriate stakeholders.

7) "We ain't no hooligans. This ain't a football song"

Hooliganism and other antisocial behaviour is deeply unprofessional and should play no part in well functioning software teams. Also remember that loud football chants in quiet workplaces may not be appreciated by colleagues.

10 Minute Rant 2: Ten Skills that are Probably More Important for Testers than Tools and Test Automation

My second ten minute rant blog, designed to break out of a spate of blogger procrastination.

(With credit to Sprint 4: The Bloggers Club on the Club, Ministry of Test)

1) Analysis and Systems Thinking

2) The Ability to Communicate with Tech Colleagues, Support, Management, Business People and Stakeholders

3) Observation, Modelling and Note Taking

4) Curiosity and a Desire for Exploration

5) Tenacity

6) Empathy for the User

7) Business Domain Knowledge

8) Formulating Rational and Consistent Arguments

9) Persuasiveness and Influencing Skills

10) Common Sense

Each of these so-called "soft skills" are critical for testers to truly perform well (IMHO) and yet most generic testing or QA job ads I see these days gloss over the above (if they are even mentioned at all) and involve a checklist of test case management and defect reporting tools, programming and test automation technologies. People can learn tools and how to program - it is much harder to rectify deficiencies in most of the above.

I suspect that the reason for this is that employers and recruiters tend to think that programming and test automation can either overcome deficiencies in the above or that testers are fungible and all have some default level of skill in the above simply by virtue of the fact that they call themselves testers.

Sad really…

Reflections on the Scripted Test Case

I have my reservations about the pre-scripted test case. I am more happy to use exploratory testing charters, automating the checking part, in my work. Being quite confident in coming up with test ideas on the fly, I find it far more interesting and personally find it results in more defects.
In my career I have only ever worked in one company that used exploratory in a major way (and it was I who implemented it as test lead!). In my experience, where manual approaches are taken the majority of the work is done using pre-scripted tests - based on the examination of requirements documents or user story in some tracking system like JIRA, approved in advance by a test manager or stakeholder and then executed sequentially. The test lead or project manager would monitor the execution of each test, produce lovely graphs and may even set rough targets of “X” tests completed per day.

In fact, according to this 2017 survey on behalf of Practitest, 58% of respondents still used scripted testing (the second highest testing methodology behind exploratory) and 56% created detailed scripted test cases - the latter having actually gone up slightly from 2016.

As a tester I have an uneasy and visceral relationship with this approach, although I have and still do work in projects as a tester with scripted tests. The idea of testing as crossing off a long list of manual checks is a very poor definition – especially in an agile context. When test execution metrics are applied and a daily test execution target set the incentive is not to enquire and investigate but to get through as many tests as possible. We are judged on our efficiency, if this is such a measure of it, and not on our ability to evaluate the product, think outside the book, come up with new real-time strategies – the tasks that should be the “bread and butter” of the testing role. It also relegates our conception and reporting of the product to a sum of minute behaviours taken separately from other. A product is fit for purpose when “enough” of its test pass. Test cases may be regarded as a type of document but as far as documentation goes they are usually pretty poor. If they weren’t then we would be including them in manuals and posting them in our site support section, however this is never done without substantial rewrite.

They also make great presumptions about the product before its release, especially when detailed steps are included. It takes an incredible amount of detailed documentation or a very precise oracle to come up with test case steps that are still relevant at the end of the development process. Done afterwards, the current behaviour of the product can bias their steps and expected outcomes, not to mention the perverse fact that to write the test case steps you have to “test” the product anyway.
Nevertheless, from the perspective of a busy test manager these can be seen as a dream, especially in reporting, communicating and negotiation with the PM, development team and key stakeholders. They provide easy (if somewhat naïve) metrics, almost instant evidence that the test team is “doing something”, and fast answers.

Test cases are a deliverable in themselves (and I have often seen them required as a deliverable to stakeholders before allowing the start of testing).

What are testers doing right now? Writing Test Cases! Are they testing what we want? Take a look for yourself, read the test cases! Is testing efficient? We completed an average of X tests per day! How serious is that defect? It breaks Y test cases, it must be serious! Why do you need more testing staff? Our "velocity" shows that we will only have 75% test case completion by the end of the test cycle, without the extra hands we can’t complete testing!

Test cases, in much the same way as widget creation in factories, act to de-skill the testing process. The real mental effort is involved in coming up with testing scenarios beforehand, however once the cases are done, depending on their detail they can be given to anyone, tester or not, to complete. In this point the tester becomes a pair of hands, an admin assistant with a checklist. Once we decide we want to, we can replace the tester with an automation script – think of all the money saved!

Also, despite its inherent inefficiencies, deskilling, ennui and lack of real depth and flexibility a test strategy of rote execution of a suite of manual scripted checks can be effective and I have worked in successful projects where this has been done. Much of this depends on how much the initial requirements do not change between their elucidation into test cases and the completion of test execution, how “high level” and open to exploration the test scenarios are and the amount of time and human resources available.

The above reasons are why scripted manual tests are so common in IT teams outside of tech companies and those relying on heavy automation, CI and fast regular releases. In fact, where I see a test approach consisting of mostly scripted manual checks, it is nearly always requested from top-down or mandated as part of an overall quality strategy. Otherwise they are enforced by the use of tools such as QTP which have very prescriptive views of testing.

Scripted testing methods are very easy to manage and report on. I do not believe that they are ever going away unless we can apply reporting of exploratory, bug bash and other testing methods that address all of the management communication points above. James Bach and Michael Bolton, in Session Based Test Management, have provided some answers to the reporting challenges above – thus showing that addressing these is not intractable.