Iāve heard of some companies getting rid of ātesting rolesā entirely. Does anyone have stories of how they end up getting on?
Iām also seeing the topic crop up more.
Thereās a meetup on the topic, for example: Testing roles are shifting, but where to? | Meetup
Also, Fiona Charles covered the topic at ETC - slides here - http://europeantestingconference.eu/slides17/FionaCharles.pdf
Where does testing fit into your organisation? And/or where is it heading?
These are trends in roles, and have been happening for a while based on what I see from TestBashāes, conferences, blog posts and twitter. My mission is to identify what I see ā¦ and present it to the stakeholders. 
When we label things, we can talk about them. We are mostly shift-lefting and shift-coachingā¦
Here are some additional resources:
Patrick Prill @TestPappy wrote this piece:
https://testpappy.wordpress.com/2016/11/13/shift-x-why-are-testers-not-happy-where-they-are-put/
After TestBash Manchester there was an Open Space on October, 22nd. The topic I choose to put on the schedule was āShift X ā Going up- or downstream?ā My motivation to choose that topic was that in two talks during the conference we heard ā again ā about testers on the move.
I wrote four pieces on my blog the directs I see (so far)
https://jlottosen.wordpress.com/tag/shift/
This DevOps & Ministry of Testing infograph is probably also relevant:
Great topic, Rosie 
Testing is certainly changing, but we could also say it might be growing. My personal interest is more on the āreinvigorationā of testing and testers. To me, itās important to focus on risk. Go beyond the purely functional testing perspectives. Find finding courage to enter domains where āwild animals lurkā!
I spoke about testing in āBlack Swan Domainsā, i.e. contexts where risks are really difficult to qualify through testing last time during āReinventing Testers Weekā at Anna Royzmans conference in New York back in September. I have blogged about it and what Anna and I are working on here:
I think companies that think ātesting is just checking requirementsā are getting rid of those ātestersā that are just doing that checking, as they are moving towards automating all those checksā¦
But as we know, testing is more that checking. Itās actually more focussed on investigation, and I think companies are starting to realize this. I think companies are starting to realize this but are struggling to hire people with the investigative skills, which is driving up the salary range for good testers.
I think our craft has some āgrowing upā still to do, in terms of having everyone on the same page with investigative testing, but I think itās getting better and more exciting!
In my company, when Iām hiring testers (regardless where weāre hiring in the world), I look for these investigative skills, but I also look for modern skills like agile, technical skills, etc. But I also look for a good attitude to learning and leading too. And as Itās a big company that I work for, I hope other companies are watching what we are doing and how we are hiring, and look to imitate us a bit in terms of hiring good investigative testers too.
Iām seeing the shift towards full stack tester - as in good at switching context and able to dive from one mode into an other: e.g. switching between exploratory, to automation, to security, to support back to automation.
With the argument of the - "manual testers are expensive because some things they do can be done in a less expensive way.
Itās an interesting one; my gut reaction is that I think it depends on where an organisation is at (and ultimately how testing is āsoldā in to the company).
Iāve found that sometimes the hard part is selling testing, and the benefits thereof, to the people that matter - and getting them to shift their thinking from āwe know we need testing but weāre not sure whyā to āwe totally understand the benefits of testing (and all the flavours it comes in)ā.
The problem with the former is, if people arenāt sure why they are paying for folk to do testing, itās a short hop from that to āwe can save money here, these people are just clicking buttonsā. Once critical mass is achieved with the latter, itās likely youāll end up disappearing down the various testing rabbit holes (automation, performance, security, etc) but that can be managed as long as thereās the right level of buy-in (and understanding).
I also feel itās necessary to make sure folk understand the importance of the learning aspects of testing, by being able to highlight and recognise successes in this area; a testers growth in to a level of domain expertise that rivals that of BAs/Product folk shouldnāt be underestimated due to the longer term benefits this can bring. Itās at this point at which we can start addressing the broader āquality assuranceā that testers can help bring to a team.
In contexts Iāve worked in for the past 10 or more years, there has been a lot of need for domain knowledge in testing, and since domain knowledge is something testers often provide better than people who focus on automation. So working together to make the most out of things really makes a better āstackā, I think than just requiring one person to be āthe full stackā (I canāt help thinking about the TCP/IP stack of Unix - or even a stack of beer 
)
Also, one thing I think we often forget is that domain knowledge often not only concerns how things should work, but also business risks. The automation guy will typically only be able to script tests of functionality, but what about the things that go beyond the purely functional?
I was seeing more of that in my last role too. We were expected to do more of it and across multiple platforms as well as digging into the backend too. Although I quite enjoyed it as it added more variety to my day.
I will have to agree to the neglected focus on domain testing/gaining domain knowledge
When it is being discussed on what kind of tester we need - there are two aspects - well but debs can also spent some time testing functionally - and - what stops you to add an end user if they are reasonably accessible.
Itās not per say attack on testers role, rather then grasping what of things we as a testers do, we have not made visible.
The argument that no matter how skilled - it is expensive when done by hand. This argument will not go away.
We are not being told to drop explorations and/or āmanual effortsā
Those will still be there, yet there is strong push on "we see value in you being able to do these 5-7 extra things and evolve " rather then āit is cheeper to replace you withā
It is fun to becoming more diverse as it helps with identifying problems.
Alarming is that with this the āI should spend less time on thisā , āI keep lagging behindā , āhow far I am from goof enoughā as a nagging voice keep adding pressure and is not helpful when one tries to build better relationship with failure (: I hope I will manage to learn to embrace them and make them be a great reason to evolve, but for now itās like being on Titanic.
Change is hard, it is necessarily but very very hard
I like how you classified them and derived the definitions from present day world and conferences.
Talking about removing the tester job title/role I actually took issue with something Rex Black (former head of the ISTQB) said this weekend on Twitter about SDETs. He suggested that testers became SDETs (which he considered a different job role entirely) as soon as they learned programming and automation, which I donāt think is right at all. Just different tools to aid testers in doing their work.
This article touches on the same topic in an interesting way and the difference between testing and QA.
I had a chat with a chap who used to work for me.
He was looking for a new contract, but the latest filters installed contained the key word āAutomationā and his CV wasnāt getting through.
āWhat should I be doing?ā, he says.
āHmmā¦ā, says I.
pauseā¦ I could have said many things, lie, learn, read, try it out, butā¦ time onā¦
āWhy not have a chat with the relevant people? Why not make a statement in your CV/initial contact about where you place automation in your skills toolbox? Why not write the skills profile in one page that describes you with a one-liner or two from different organisations you have worked with about the value add?ā
Were all the things I thought about saying, but didnāt.
āListenā, I said, āCheck out the MOT Dojo, Udemy, MountainGoat, Satisfice, Test Obsessed and take some advice from these sources. Learn some Javascript (seems to be hottest thing here in Dublin these days), look into SoapUI, LoadUI as low level simple testing tools. Fill your toolbox with direction, even if you havenāt much experience.ā
āThenā, I said, āCheck out the likes of TeamCity, Octopus, Jenkins etc. to see whatās happening in the build, deploy, test, rinse and repeat areaā
āAfter thatā, I continued, āLook into Selenium, Fiddler, Python, Perl etc. and how they are applied in this area of Test Automationā.
āOhā, he saidā¦ Pauseā¦
āJaysus Ivor, Iām just looking to get a contract testing, Iām no developerā, he said.
āI know! But if youāre looking to do that you need to look for the right role and not beating yourself up about Automationā, says I.
The truth is, testing is evolving. Traditional test roles, where test cases are written against large requirements sets and encased in reviews, approvals and sign offs, are disappearing. Testing adds value up and down the chain of an application/products development, whether in an Agile. Kanban, Waterfall or any other methodology we can throw out there.
Except, now Business/System/Product Analysts are building testing into what they do. Now, good developers are building good quality tests into what they do. ETL developers are working hard at verifying the data pipelines they are laying down. Weāve brought the user closer to us for testing purposes in UAT. Weāve cut our product/products up into self managed deliverable chunks and it seems to work.
As testers we now have a role to play by asking the hard questions (usually at the wrong time , by designing tests to be executed on a regular basis that are more about our insight than making sure the software works, by automating the tests that will be executed again and again, but most of all for thinking outside of the normal box, connecting thoughts, design and more with people and making things work.
As I see it, after going round the houses, the testing roles are evolving and have become more technical. The traditional testing roles have been dissipated and incorporated into other functions. The sapient tester is identified as a āTest Analystā, while the more technical tester is a āSoftware Developer in Testā. Specialist roles of āPerformance Testersā are more like DevOps and provide detailed insight into what happens to the product under duress. āRelease Engineersā make sure the automated tests are run, the process executed faithfully to deliver a working product. The āTest Managerā is more of a supporting role, as cross functional teams form and disband to meet the needs of the organisation. This particular role is most at risk as testing becomes more embedded with the political clout once associated with it being taken up by āProduct Owners/Managersā.
I do realise that I posit a view that is relatively narrow in its scope. I donāt include Governmental organisations or Banking/Financial institutions. These have typically been well behind the curve in adopting new and ultimately better ways of doing business internally.
Maybe this post should have been in the āRantsā section 
Anyways, tis my ā¬0.02c.
Thanks, Ivor
Nice Rant @ivor! IT ties into what I see and have outlined above. Great stories
This reminds me of one trend I do see: The subject matter expert in the business section is doing all the testing - because they can, have the tools (SAP SolMan etc) and the best knowledge. If the tester is not the best SME - then the tester is out of the game. And UAT is not even dead in the corporate landscape.
I think there are some very large successful companies out there that have a reputation of not hiring testers cough Facebook cough. However every company has a different risk profile, Facebook has agressive dog fooding tactics (they release their software to their staff first for some time to screen for usability issues), Google employs similar tactics. Spotify, Facebook and Google all have amazing experimentation frameworks baked into their products with teams of researchers/data scientists helping to validate ideas with data. When you have these teams of people trying to improve the quality of their products and the frameworks in place help mitigate/reduce most of the risk with a product, where can a tester add value?
One role that facebook has is called a Trust Engineer (they seem to be responsible for engineering feelings of trust with users), there is an interesting radio lab talk here: http://www.radiolab.org/story/trust-engineers/ on it
With the increase of dog fooding, testers are probably more important but should be involved at the start of the cycle rather than the end. If a tester can look at a work item with the devs during an agile planning phase they can highlight the potential problem areas up front. Most dev departments suffer from having the same type of error reported over and over again - in one case Iāve seen almost every new piece of work gives the same basic fault despite the testers talking the devs through them every time. If testers can be involved in the devsā planning stage then simply saying "I think thereās a risk of ā¦ " in this piece of work may well prevent that problem being built in. Far better to train the dev in writing software to pass test than to pick the problems up during test and spend time re-working.
Itās simple. Many companies (and indeed many recruitment consultants) donāt have a clear understanding of what or who they are looking for.
They trot out the same old guff about setting up automation frameworks, etc blah blah when in fact they likely donāt even know what this looks like or what the benefits (if any) are going to be had. In the next breath theyāll say you must have an ISEB this or an ISTQB that. I wonder sometimes how much copying and pasting goes on when preparing role vacancies. Many advertised roles seem to blindly demand everything - a bit like using a blunderbuss.
I recall a telephone interview once with a large satellite broadcasting provider and it was clear there were major misunderstandings between what they were looking for and the matter being compounded by the further confusion surrounding role titles e.g. failing to differentiate between a test engineer and a developer in test, etc. I can talk intelligently about test automation strategy but I am no developer. I wouldnāt necessarily be able to write the actual ācodeā behind the tests unassisted. Moreover I wonder how many companies realise test automation is not in fact the same as software testing. Scary.
I guess itās all a bit of a mess and will continue to be a mess until something is done to better align our often misunderstood industry.
Hereās an additional shiftā¦ The tester becomes the Product Owner or even more knowledgeable than the PO or any other Subject matter expert or business analyst.
I see plenty of places where the UAT is not even dead but done by various BAās and other SMEās - as they have the required domain knowledge. ā¦ and thatās OK. What we can add is making it smarter and more exploratory.
I wrote more about it here: https://jlottosen.wordpress.com/2017/05/30/the-domain-expert-is-the-tester/