Testing Roles - it should be simple

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” - C. A. R. Hoare

The above quote had been sent around recently and it hit chord in me. I have started to look at everything with this quote in mind which brings me very swiftly to testing roles.

The list below is what I managed to find in a 15 minute search for roles online:

  • Test Analyst
  • Test Engineer
  • Test Manager
  • Quality assurance (QA) analyst
  • Agile test analyst
  • Automation test analyst
  • Test specialist
  • Manual test analyst
  • Functional tester
  • QA engineer
  • QA Lead
  • Performance tester
  • Non-functional tester
  • User acceptance tester
  • Programme test manager
  • Software Design Engineer in Test (SDET)
  • Developer in Test (DIT)
  • Test Architect

No doubt I have missed some but if we start to add in levels such as Junior, core, senior and consultant. Also consider specialisms in regards to industry i.e. manufacturing, avionics, finance, etc. it starts to get a bit ridiculous.

It really shouldn’t be this difficult.

As a test community we have been driving for our place within projects as we’ve often been the first to be cut and i’m still having to explain what we do in some instances. With this level of role confusion I can’t blame non testers for being a little frustrated.

If you hire a developer or a project manager their roles are a expected to cover the length and breadth of a project. Yet testers are split into various bands. If you consider developer roles everyone has an expectation that they should be able cover everything along the software engineering spectrum.

In my opinion there are two clear paths for testers and maybe the image below is an oversimplification but we all need to start somewhere.

Technically Focused Testers

With Developers In Test (DIT), Software Development Engineers in Test (SDETs) and TDD help increase the levels of automation we are seeing a strong drive across businesses for technical skills in testing.

So while QA engineers, SDETs and DITs target technical efficiency, it creates a new gap.

User Focused Testers

It may be argued here that this would be a ‘traditional tester’ (whatever that may deemed to be). There is however a clear need to keep the focus on the user, putting yourself in their shoes, working with the business to ensure the technical side doesn’t forget who it is delivering its product to.

With automation taking away the mundanity of repetetive tasks it allows people to focus on Exploratory Testing. For those who have had the pleasure of running in an delivery environment that promotes exploratory testing, you will find it difficult to go back to scripts.

Let’s not forget that UAT still stands and user focussed testers should be working with staff in regards to handovers, training and potentially early support.

Lastly……

Planning and ‘The Blend’

Planning: -

Whether it’s Agile methodologies or traditional sequential delivery we still need to plan! All testers whatever their role need to be involved to help keep quality a focus, drive the necessary plans and outputs.

‘The Blend’

Skills need to be transferable and both camps should be learning new skills from each other. A user focussed tester as an example should understand HTTP/API’s and technical focussed testers should spend time within a UAT phase to learn more about their users.

Keeping it simple….

This is a very simplistic way of looking things and yes there are many avenues that could be discussed. But, keep the quote in mind…… It is only as difficult as we choose to make it.

There are two other blog posts worth reading by James Bach that helped drive this particular post:

ISO-29119 - Do we need a software testing standard?

Standards can be a good idea. In many industries, standards ensure that products work as intended, and importantly, that they meet safety standards. Indeed, when I’m flying off on holiday, and indulging in that second complimentary beer from those lovely people at Virgin Atlantic, I’m pleased to know that there are robust safety standards in place in the aerospace industry and that I am more likely to be killed by a vending machine falling on top of me than in an airplane accident.

Standards work with engineering ball bearings, wheels, etc. it allows production to flow cross-border easily and promotes conformity.

But let’s stop there for a moment to consider the engineering and technological leaps we have made in history. The telephone, the combustion engine, electricity, the internet, aviation. Pick any of these leaps in progress and ask yourself ‘did anyone ask whether they followed a standard?’

While I wouldn’t want to put words into the mouths of Bell, Berners-Lee or any of their esteemed colleagues, I wouldn’t mind betting their response would be ‘A standard? Are you mad? I had a dream, a vision. I don’t want to spend precious time conforming to someone else’s standards, producing project plans, risk registers, issue logs etc. I want to develop a phone so I can phone someone on the other side the world, and tell them about my invention’. At that point, Mr Bell must have recognised that a single phone was pretty pointless and quickly rushed into production a second phone. But I digress…

You may consider the above points excessive, even off track from what ISO-29119 is and what standards are for. But ask yourself how many innovative ideas, good or bad, have been consigned to darkness in recent times because someone somewhere said it doesn’t adhere to safety standards or the board will not sign off without X?

ISO-29119 started in May 2007, has been worked on closely by approximately 70 people and reviewed by other members of ISO and IEEE. ISO-29119 is heavily based on IEEE-829 documentation standard for testing and in September 2013 3 of 5 parts of the standard has been agreed by the ISO community.

In the same 6 year period, the iPhone was introduced, spawned 6 generations and Netflix went from a DVD business to streaming to a plethora of connected devices.

I wonder whether the late great Steve Jobs concerned himself with aligning with standards……

The software engineering world is immense in its scale and pace of change. We need to consider hardware local, hosted and cloud. There are limitless combinations of operating systems, their versions and configuration. Thousands of languages that generate applications and services.

Testing has been adapting all this time to the dynamic nature of this type of industry, can testing support a potentially static standard?

So back to the standard…..

ISO-29119 states:

“ISO/IEC/IEEE 29119 Software Testing is an internationally agreed set of standards for software testing that can be used within any software development life cycle or organisation. By implementing these standards, you will be adopting the only internationally-recognised and agreed standards for software testing, which will provide your organisation with a high-quality approach to testing that can be communicated throughout the world.”

The offending word is ‘agreed’. I certainly don’t recall being consulted, let alone agreeing. It is pushed by the few to the many with power that most governments do not have.

ISO-29119 does not reflect the views and opinions of the wider testing community.

Only full ISO members it seems can directly influence standards and to be a full member involves personal investment and time. I’m sure the majority of members are individuals that sacrifice a lot to have an input. Although, larger organisations who have the resources to apply to this will find it easier to directly influence these standards which could breed the view of an elitist group.

You can, however, be a reviewing member through various committees. If you are a reviewing member of the organisations you can comment on the draft standards and see how your comment has been handled, by the other committee members? Software testing is fluid and dynamic. ISO-29119 is an unnecessary barrier that companies will wholeheartedly adopt without consideration for the impacts of time spent on plans and strategies to be held in the archives as a state of what once was.

Drop the standard and work on good practice and allow the wider community a voice. If not like many other standards before it will be viewed as a burden, mined for its value and discarded.

As someone who believes in innovation and progression, I pose the question, should we be oddly grateful? Without standards and rules, we wouldn’t be pushed into breaking them.

You can sign up to the petition here

The ISO29119 standard website can be found here

Posted January 22, 2015