The pursuit of the all in one professional

A further response to the debate on here https://www.linkedin.com/groups/690977/690977-6145951933501882370?trk=hp-feed-group-discussion. I couldn’t fit it in a comment so put it here instead.

Hi Alan. Thanks – I’m not sure we are disagreeing, I think we’re debating from different perspectives, that’s all.

Your suggestion that other members of our software teams might need to re-skill or up-skill isn’t so far-fetched. This kind of re-assignment and re-skilling happens all the time. If a company needs you to reskill because they’ve in/out/right-sourced, or merged with another company, acquired a company or been acquired – then so be it. You can argue from principle or preference, but your employer is likely to say comply or get another job. That’s employment for you. Sometimes it sucks. (That’s one reason I haven’t had a permanent job since 1984).
 
My different perspective? Well i’m abolutely not arguing from the high altar of thought-leadership, demagoguery or dictatorship. Others can do that and you know where they can stick their edicts.

Almost all the folk I meet in the testing services business are saying Digital is dominating the market right now. Most organisations are still learning how to do this and seek assistance from wherever they can get it. Services business may be winging it but eventually the dust will settle, they and their clients will know what they are doing. The job market will re-align to satisfy this demand for skills. It was the same story with client/server, internet, Agile, mobile and every new approach – whatever. It’s always the same with hype – some of it becomes our reality.

(I’m actually on a train writing this – I’m on my way to meet a ‘Head of Digital’ who has a testing problem, or perhaps ‘a problem with our testers’. If I can, I’ll share my findings…)

Not every company adopts the latest craze, but many will. Agile (with a small a), continuous delivery, DevOps, containerisation, micro-services, shift-left, -right or whatever are flavour of the month (althoough agile IMHO has peaked). A part of this transition or transformation is a need for more technical testers – that’s all. The pressure to learn code is not coming from self-styled experts. It is coming from the job market which is changing rapidly. It is mandatory, only if you want to work in these or related environments.

The main argument for understanding code is not to write code. Code-comprehension, as i would call it, is helpful if your job is to collaborate more closely with developers using their language, that’s all.

DevOps is killing QA. Really?

I read a fairly, let’s say, challenging, article on the DevOps.com website here: http://devops.com/2016/06/07/devops-killed-qa/

It’s a rather poor, but sadly typical, misrepresentation or let’s be generous miunderstanding of the “state of the industry”. The opening comment gives you the gist.

“If you work in software quality assurance (QA), it’s time to find a new job.”

Apparently DevOps is the ‘next generation of agile development … and eliminates the need for QA as a separate entity’. OK maybe DevOps doesn’t mandate or even require independent test teams or testers so much. But it does not say testing is not required. Whatever.

There then follows a rather ‘common argument’ – I’d say eccentric – view of DevOps at the centre of a Venn diagram. He then references somene elses’ view that suggests DevOps QA is meant to prevent defects rather than find them but with all due respect(!) both are wrong. Ah, now we get to the meat. Nearly.

The next paragraph conflates Continuous Delivery (CD), Continuous Integration and the ‘measurement of quality’. Whatever that is.

“You cannot have any human interaction if you want to run CD.”

Really?

“The developers now own the responsibility rather than a separate entity within the organization”

Right. (Nods sagely)

“DevOps entails the use of vendors and tools such as BUGtrackJIRA and GitHub …”

“To run a proper DevOps operation, you cannot have QA at all”

That’s that then. But there’s more!

“So, what will happen to all of the people who work in QA? One of the happiest jobs in the United States might not be happy for long as more and more organizations move to DevOps and they become more and more redundant.”

Happy? Er, what? (Oh by the way, redundant is a boolean IMHO).

Then we have some interesting statistics from a website http://www.onetonline.org/link/summary/15-1199.01 I can’t say I know the site or the source of data well. But it is entirely clear that the range of activities of ISTQB qualified testers have healthy futures. In the nomenclature of the labels for each activitiy the outlook is ‘Bright’ or ‘Green’. I would have said, at least in a DevOps context that their prospects were less than optimal, but according to the author’s source, prospects are blooming. Hey ho. Quote a source that contradicts one’s main thesis. Way to go!

But, hold on – there really is bad news …

“However, the BLS numbers are likely too generous because the bureau does not yet recognize “DevOps” as a separate profession at all

So stats from an obviously spurious source have no relevance at all. That’s all right then.

And now we have the killer blow. Google job search statistics. Da dah dahhhhh!

“As evidence, just look at how the relative number of Google searches in Google Trends for “sqa jobs” is slowly declining while the number for “devops jobs” is rapidly increasing:”

And here we have it. The definitive statistics that prove DevOps is on the rise and QA jobs are collapsing!

qa jobs vs devops jobs

“For QA, the trend definitely does not look good.”

So. That’s that. The end of QA. Of Testing. Of our voice of reason in a world of madness.

Or is it? Really?

I followed the link to the Google stats. I suggest you do the same. I entered ‘Software Testing Jobs’ as a search term to be added and compared on the graph and… voila! REDEMPTION!!!

Try it yourself, add a search term to the analysis. Here is the graph I obtained. I suggest you do the same. Here’s is my graph:

Now, our American cousins tend to call testers and testing – QA. We can forgive them, I’m sure. But I know the term testers is more than popular in IT circles over there. So think on this:

The ratio of Testers v DevOps jobs is around five to one. Thats testers to ALL  JOBS IN DEVOPS IS FIVE TO ONE.

ARE WE CLEAR?

So. A conclusion.

  1. Don’t pay attention to blogs of people with agendas or who are clearly stupid.
  2. Think carefully about the apparent sense but clear nonsense that people put on blogs.
  3. Be confident that testing, QA or whatever you call it is as important now as it was forty years ago and always will be.

It’s just that the people who do testing might not be called testers. Forever.

Over and out.

VOTE REMAIN!

 

Will Robots Replace Testers?

A recent study from the University of Oxford makes for interesting reading:

  • Over the next two decades, 47% of jobs in the US may be under threat.
  • 702 occupations are ranked in order of their probability of computerisation. Telemarketers are deemed most likely (99%), recreational therapists least likely at 0.28%. Computer programmers appear to be 48% likely to be replaced.

If programmers have a 50/50 chance of being replaced by robots, we should think seriously on how the same might happen to testers.

Machine Learning in testing is an intriguing prospect but not imminent. However, the next generation of testing tools will look a lot different from the ones we use today.

For the past thirty years or so we have placed emphasis on test automation and checking. In the New Model for Testing, I call this ‘Applying’. We have paid much less attention to the other nine – yes, nine – test activities. As a consequence, we have simple robots to run tests, but nothing much to help us to create good tests for those robots to run. 

In this paper, I am attempting to identify the capabilities of the tools we need in the future.

The tools we use in testing today are limited by the approaches and processes we employ. Traditional testing is document-centric and aims to reuse plans as records of tester activity. That approach and many of our tools are stuck in the past. Bureaucratic test management tools have been one automation pillar (or millstone). The other pillar – test automation tools – derive from an obsession with the mechanical, purely technical execution activity and is bounded by an assertion that many vendors still promote – that testing is just bashing keys or touchscreens which tools can do just as well.

The pressure to modernise our approaches, to speed up testing and reduce the cost and dependency on less-skilled labour means we need some new ideas. I have suggested a refined approach using a Surveying metaphor. This metaphor enables us to think differently on how we use tools to support knowledge acquisition.

The Survey metaphor requires new collaborative tools that can capture information as it is gathered with little distraction or friction. But they can also prompt the user to ask questions, to document their thoughts, concerns, observations and ideas for tests. In this vision, automated tools get a new role – supportive of tester thinking, but not replacing it.

Your pair in the exploration and testing of systems might soon be a robot. Like a human partner, they will capture the knowledge you impart. Over time they will learn how to support and challenge you and help you to navigate through your exploration or Surveying activity. Eventually, your partner will suggest ideas that rival your own. But that is still some way off.

To download the full paper, go to the Tools Knowledge Base.