Someone else will do it

The testing activity has been under change for long. And it’s clear that the testing activity has shifted. Even the test managers have to re-calibrate – as other roles will be doing the test management activity. Be prepared, as someone else will do your testing job. Work on building self-reliance in others and be prepared to hand-over what you can do.

There is more to testing than testing specialists punching test cases. The testing activity as such, has shifted (both left and right), and testing is being done by more roles than “testing people”. Depending on the context, the explicit testing activity is done by a mix of developers, testing specialists, end users and others.

I often find myself as the only testing person on the project. The testing activity is done by automation specialists and end users in one project, and by technical operations staff and end users in another. In these projects either the technology or the business knowledge is paramount, and not so much exploration, flaws and edge cases for specialized testers to explore.

me, 2020. YMMV

Similarly for the test managers – there’s a trend/shift, that sometimes the test management activity is shifting away from the test managers. Even to me – even if I’m sometimes more an a “project manager of the testing activity“, a “Test coach” or similar. The trend is already there – coined sometimes as “whole team approach to quality“. Yes, most of the test management activity can be done by scrum masters, Release Train Engineers and even project managers ….

Recently I was asked to assist a large transition project for a holding company with many brands. Each brand had their own applications and technology stack, but the holding company had decided to move the hosting. So the holding company’s Project Management Office (PMO) was put in charge of facilitating the brand’s testing activities – an activity they had never considered nor done before. My role would only be to provide guidance, not do the actual facilitation.

Which got me thinking….

And after some deep thinking. – I do have the privilege to be able to adapt. I don’t need to hoard knowledge or make power moves (anymore) or worry about health-coverage or any of the lower Maslow pyramid terms (anymore).

It’s very natural for me to hand over project approaches to my co-workers. I’m often on the “blue team” to outline the strategy, My best field of work is to bring clarity and consistency, not scalability or repeatability to the practise.

I naturally hand over learning anyways, so why not re-calibrate when the thing I do has reached a stage, where it’s repeatable. And then focus on building the skills in others, work myself out of the test management role as we know it.

And don’t worry that someone else will eventually do my (testing and test management) job. The first step is to acknowledge the trend/pattern, second to redefine and bring clarity! Let’s explore and see what we find!

Someone else will do the building, not Emmet. His task is repeatable.
Someone else will do the building, not Emmet. His task is repeatable.

No Code, No Test?

If the testing activity can be integrated into the coding activity, who tests if there is no code involved? Does there have to be code in order for there to be a test activity – and when does the scale tip for testing to happen?

There is a new type of business applications emerging – the “Low Code / No Code” products. The WordPress platform like this one I’m writing from now could be one example. AirTable could be another example of a higher order solution, that enables some user to quickly and without code organize and automate information. What we see in the testing tools space with Cypress and Mabl, is similarly a trend, where the test cases and scripts are directly linked to the end-2-end business purpose, not the underlying technologies. Low Code tools has emerged as yet another type of “customization” and “configuration” business solution.

Evolution line and groups of products (Wardley Maps X-axis)

The trend is clear and has been on the horizon for a while.

Low-Code/No-Code will disrupt this entire pattern, as enterprises realize they can be even more successful with their digital transformations if they do away with hand-coding altogether, adopting Low-Code/No-Code across their organizations instead. “No-Code is here, and it doesn’t care about making your IT organization more efficient,” explains E. Scott Menter, Chief Strategy Officer at BP Logix. “Its only purpose is to turn your business into a digitally integrated, audit-defying, silo-resistant object of their customers’ desire.”

The Low-Code/No-Code Movement: More Disruptive Than You Realize

If a consultant can automate her unique process into a tool in hours, she can solve customer’s problem faster and show the value of her efforts. If a small business owner can build an app for his needs, he can increase business efficiency with automation and save valuable time to expand his business.

No-code Revolution. Why Now?
Wardley Mapping y-axis: User proximity / Code needed

To me there is a direct correlation between amounts of code required and business needs and end user visibility. The less “scripting” a business end user needs to do and “scripting languages” to understand the better. Airtable, as mentioned above, wins over spreadsheets in the end.

Similarly the faster cycles and feedback of Low Code tools is more attractive to the business than having “code high” teams develop applications. The “slow and high” code projects are never realized.

Wardley map: Low code evolves and outmaneuvers “high code”

One way to see this trends, is that while “Robot Framework” and other web-based open source “RPA like” frameworks exist, the emerging approach for testing standard software solutions trends towards Low Code:

Perhaps RPA tools and similar Low-Code tools can be compared to the macros of If This Then That, where you can automate tedious repetitive tasks – also among your business tools. But even with low-code tools the complexity of the scripts can make it a mess, and the visual scripts needing coding practices.

Similarly, the need for explicit testing of the business functionality emerges at some point in the evolution of the “low code” solutions. Every solution moves from Experiment to emerging practice and end as a standard/best-practice. The explicit testing need emerges along the way but becomes less visible on the left-side products/commodities.

Yet to me – testing happens everywhere. Testing is key to the experiments of the pioneer, testing is key for the settler bundling solutions and testing is key for the town planner to secure stable operations.

Simple illustration of the Pioneers, Settlers & Town Planners Model.

Be aware that while testing is happening, it is not necessary by the tester. Don’t hawk the testing activity, let the experts play their part , have testers for the remaining exploration and have tools for the rest. The trend of less testers and more testing is still active and testing is shifting to the future even faster these days. A test happens every time a person doing something thinks and ask questions like: let me try this, could you test this, what happens if?

There doesn’t have to be code for testing to happen.

Go read Accelerate!

ACCELERATE – The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

by NICOLE FORSGREN, JEZ HUMBLE, GENE KIM

The authors have “multiple examples of applying these practices within mainframe environments, traditional packaged software application delivery teams, and product teams“. It’s not just for business-to-consumer web-based organizations.

The book is a tour the force into software delivery performance – the research and statistics shows a clear correlation from DevOps and Lean principles to high achieving organisations. Every arrow on the below model is backed with research. Read the arrow clearly as “drives”, “improves” and “lead to”. E.g. Continuous Delivery leads to Less Burn out.

Saved you a click: https://itrevolution.com/book/accelerate/

A last thing to highlight: High performing organisations have lower manual work percentages in areas like: configuration management, testing, deployments and in the (ITIL) change approval process.

So – if you want to increase the boxes on the right, go do the stuff on the left.

Read the book and act on it.

On Medium regarding Testing, AI, ML etc

I’m writing on Medium regarding Testing, Artificial Intelligence, Machine Learning etc:

More to testing than AI and ML can solve

Artificial Intelligence (AI) and Machine Learning (ML) can perhaps solve some testing challenges, but not all testing. The testing vs. checking debateand all the shift-left of checking, have revealed that some of testing is about critical thinking and some…

 See also

Similar posts: Testing is wicked, Test all the things,

mad-brain

OpsDev – more dev work by ops

The hyped mnemonic “DevOps” is equally true the other way around: OpsDev – that is, more and more work in the operations and infrastructure departments happens as development activities with scripts, code repositories and build managers. OpsDev is as tool-heavy as DevOps, and test involvement similarly pipeline focussed.

Guest blog post at http://www.plutora.com/blog/opsdev-test-environments-management 

Less Test Managers, More Test Coaches

One of the trends/shifts I experience in testing & test management in particular is the Test Coach as discussed initially here: The Shift-Coach Testing Trend (Oct, 2016). Recently (Aug 2017) it came up again in a Twitter thread, where Stephen Janaway stated the inspiration to the title of this blog post.

Less Test Managers and more coaches. That’s how I see it going.

Fittingly as he inspired the first post with his talk “How I Lost My Job As a Test Manager” presented at Test Bash 2015. This post is a further elaboration of the Shift-Coach test management trend. Here are some of my experiences:

  • I have been assigned to an agile development team to introduce them to 3 Amigos, Test data driven test automation and such things. The purpose of my involvement was to enable the team to continue the practices without me, and without testers besides the business analyst / product owner (See The domain expert is the tester) as they are doing Shift-left. Similar to an agile or scrum coach, my approach was to look at it as a change in the way of working.
  • Another project is an infrastructure project, there are no testers only technicians configuring Cisco routers that by software can replace firewalls, iron ports, VM servers and other network equipment. The project has to implement 80+ of these, so I setup both a test process and an ITIL change request process acting as a test and release manager – another quite frequent trend. I could continue in the project for the duration, but instead I setup guidance and leave when it’s sufficiently in place.

This might be similar to a test architect, a (internal) test consultant activity. It has nothing to do with diminishing testing. Rather I see it as more testing happening, something that would not have been done without the coaching from a test manager. It’s all about finding a test approach that is fit for the context.

Here are some things others have written:

The competence of the test coach is to have enough change management expertise (people skills) and test management expertise (domain skills) to know how to coach and facilitate the change. Should test coaches test too, perhaps when required, but not necessarily. The activity is primarily to up-skill the team to continue on their own.

The “Test Coach” is a trend similar to “shift-left” and all the other shifts in testing and test management. I see it as a pattern, and what I read from the threads and discussions is that many test managers gradually shift towards test coaches.

2017-07-03 13.57.42

Many Bits under the Bridge

I’ve been in the testing business for 14 years – when I started in late 2002 it was all about using HP Test Director 7.6 – in a browser… There was only one model of testing, v-model, and only one book of testing the ISEB (later ISTQB) vocabulary. And only one expected output of testing: Testers designed test cases, executed and perhaps wrote both a test plan document and test report document. Test process improvement was a thing, but even so testing was often a pointy cog…  

Many Bits under the Bridge Later

It is not about the test cases any more, it’s about being part of a team – that delivers an IT solution to the business. First of all, if it’s just about the test cases then it is a race to the lowest paid off-shore location, a run to the bottom in repetitiveness and mechanic activity. Checking! with more focus on crossing the t’s and dotting the i’s. We have tools for that now – the plates are shifting.

When testing professionals puts “writing test cases” on their LinkedIn description. It seems to me that they are stuck in the testing world of 10 years ago. Standing still and not seeing that Testers are Knowledge Workers – not workers of producing artifacts. It is much more important to see beyond the visibleUncovering better ways and seeing testing as an activity to provide information to the stakeholders, based on experiments and observations.

Skill up and be smarter! And don’t listen to old tapes – it’s not worth it :).

See also this from QA Symphony & Ministry of Testing:

The Software Tester: Modern vs. Traditional [Infographic]
The Software Tester: Modern vs. Traditional [Infographic]

The Shift-Coach Testing Trend

Shift-Coach is when testers and test managers trends towards being coaches and facilitators of the testing activities. Shift-Coach is more about leading the testing than leading the testers to paraphrase from @DevToTest Joe DeMeyers blog post.

The ground breaker for this trend, is to me, the talk “How I Lost My Job As a Test Manager” presented at Test Bash 2015 by Stephen Janaway. Stephen explains how reorganization of the test manager role forced him to be more a facilitator than embedded in the teams. Similarly many other great test managers talk more and more about people skills and coaching, especially in agile projects. I want to define shift-coach around the facilitation testing activities, and place testers that doubles as scrum masters in the Shift-Deliver trend.

In traditional (v-model) projects testing has often included people that were not professional testers; – in user acceptance tests this has often been business subject matter experts. The testing was done by someone with the best knowledge of the topic, and that may not have been the professional tester. That more and more projects do this – more and more, is a big challenge for many testing folks. But it is a significant trend in testing world of 2016.

Shift-Coach trend is visible when Alan Page  talks at Test Bash Philly 2016:

You’ve heard the rumors, and you’ve seen it happen. An organization or development team decides they don’t need testers, and you have big questions and massive concerns. Is quality not important anymore? Are they irresponsible or idiotic? Are their hats on too tight? Do testers still have jobs?

Alan Page is a career tester who has not only gone through the “no-tester” transition, he’s taking it head on and embracing it. Alan will share experiences, stories, strategies, and tactics (and failures) on how he’s taken everything he’s learned in over twenty years of software testing, and used those skills to have an impact on software engineering teams at Microsoft. Whether you’re going through this transition yourself, think it may be coming, or just want to tell someone what an absurd idea this is, this is the talk for you.

This trend goes along with Shift-Right, Shift-Left and Shift-Deliver discussed separately. I discussed these trend labels at Nordic Testing Days 2016 during the talk “How to Test in IT operations“ and coined the labels on the EuroStar Test Huddle forum.

legocoach
Drive the Testing – Coach!

Trending: Shift-Left

TL;DR: Shift-Left is about testing early and automated. Shift technical with this trend or facilitate that testing happens.

Shift-Left is the label we apply when testing moves closer to development and integrated into the development activities. The concept is many IT years old, and there are already some excellent articles out there: What the Shift Left in Testing Means (Smart Bear, no date), “Shift left” has become “drop right” (Test Plant 2014), Shift Left QA. How to do it. Why it matters (Work Soft, 2015).

To me Shift-Left is still an active trend and change how to do testing. This goes along with Shift-Right, Shift-Coach and Shift-Deliver discussed separately. I discussed these trend labels at Nordic Testing Days 2016 during the talk “How to Test in IT operations“.

Here are some contexts where Shift-Left happens:

  • Google have “Software Engineer in Test” as job title according to the book “How we Test Software at Google“.
  • Microsoft have similar “Software Design Engineer in Test” as discussed by Alan Page in “The SDET Pendulum” and in the e-book “A-word
  • A project I was regarding pharmaceutical  Track and Trace, had no testers. I didn’t even test but did compliance documentation of test activities. The developers tested. First via peer review, then via peer execution of story tests and then validation activities. No testers, just the same team – for various reasons.
  • A project I was in regarding a website and API for trading property information had no testers, but had continuous build and deploy with even more user oriented test cases that I could ever grab. (see: Fell in the trap of total coverage)

The general approach to Shift-Left is that “checking” moves earlier in the cycle in form of automation. More BDD, more TDD, more automated tests, continuous builds, frequent feedback and green bars. More based on “Test automation pyramid” (blog discussion, whiteboard testing video). Discussing the pyramid model reveals that testing and checking goes together in the lower levels too. I’m certain that (exploratory) testing happens among technicians and service-level developers; – usually not explicitly, but still.

To have “no QA” is not easy. Not easy on the testers because they need to shift and become more SET/SDET-like or shift something else (Shift-Right and Shift-Coach and Shift-Deliver). Neither is it easy on the team, as the team has to own the quality activities – as discussed in “So we’re going “No QA’s”. How do we get the devs to do enough testing?

Testers and test managers cannot complain, when testing and checking is performed in new ways. When tool-supported testing take over the boring less-complex checks, we can either own these checks or  move to facilitate that these checks are in place. Similarly when the (exploratory) brain-based testing of the complex and unknown is being handed over to some other person. Come to think of it I always prefer testing done by subject matter experts in the project, be it users, clients, testers or other specialists.

We need to shift to adapt to new contexts and new ways of aiding in delivering working solutions to our clients.

jollyrum