Ch-ch-ch-changes:
Experiences of testers who have shifted left & right
In previous posts I’ve shared my own experiences with “shifting left and right”, also known as continuous testing, and how testing-related activities change when you make this shift. I’d like to share experiences from other testing practitioners as they have moved into participating throughout the software development build, observe, measure and learn loop.
Let’s learn what a few testers have found as they got involved with testing at various points in the continuous development cycle. If you haven’t yet been able to embrace continuous testing, these stories may give you some ideas on how to get started making the move.
p.s.
We had an expert panel with most of these folks where we had a lively discussion about how to shift to continuous testing in DevOps, how to encourage a whole-team-approach to testing, testing in CI/CD, and so much more. You can watch it here now: https://www.mabl.com/blog/how-to-shift-to-continuous-testing-in-devops
Shifting into a new role
Andrew Morton, now the DevBoss of Ministry of Testing and @TestingChef on Twitter, used a fairly radical approach to “shift left”. He shares a story about how he decided the best way to show developers how to test was to be a developer who tested. If you have some coding experience or are interested in learning, combining your testing expertise with hands-on development work is a great option.
Even in the first couple of years of my career, I realised that it wasn’t enough to just be handed something and be told ‘Test this’. I knew that to be as effective as possible, I needed to be around when decisions about a project were being made, from initial kick off onwards.
To this end, I used to check my colleagues’ calendars each day, and if there was a meeting scheduled I thought I should be in, would ask to be invited (which worked most of the time). This was the first step in shifting left, as I was now able to be involved at the start of a project, and when features were released to testing.
However, there was still a gap that meant I wasn’t testing throughout the entire development cycle, and that is the part where code is being written. In theory, as a tester, this is not my realm to work in and developers should be doing things required to check their own work. However, over the years I have noticed that most developers are not taught testing (rather, they pick it up ‘on the job’ and learn from code written by others in the same situation), and even if they are, they are not necessarily great at applying it.
The question became how do we fix that? The company I was in tried moving testers out of the dedicated testing role and into a test coaching role (i.e. we wouldn’t do any testing ourselves, but help the development teams do testing instead). Whilst this kind of worked, it wasn’t very satisfying to me, because I had the feeling (probably erroneously, I admit) that I wasn’t getting across to developers because I wasn’t one.
So I changed that. Deciding that the best way to show developers how they could test and develop, was to become a developer who tested and developed. I had quite a bit of programming experience from doing E2E automation, and had just come off a project backfilling unit tests to replace some integration tests that could be run at the lower level. I was now in the position of being able to be part of design, programming, and testing for features that I was assigned. That approach has stayed with me for the last couple of years as I have continued my developer journey.
Andrew’s desire to “shift left” led him into a new role where he can model good testing practices to other developers. Not all of us want to move into writing production code (some of us moved away from that into testing). Learning enough skills to be able to collaborate with developers can, in my experience, also be an effective way to help them learn testing skills. I’ve done a lot of pairing with developers, for automating tests, for exploratory testing, and for writing production code. All of those things helped transfer skills among team members so that we could prevent bugs and please customers.
Continuous testing is not a new idea!
If you’ve been working in the software industry for several years or more, you may feel that some of this talk about shifting left and right isn’t really a new thing. That’s my opinion too! I asked Isabel Evans, a well-known software and quality consultant and international speaker with more than 30 years experience in IT, how she has seen testing change, or not change. We both remember that the correct approach to testing in waterfall was to do testing at each phase, rather than only at the very end of all the phases, right before release.
I recall learning how to test a requirements document at a testing conference in the early 90s - I thought it might have been Isabel who presented that session! That was an effective testing activity that let me bring people different roles and from different teams together, from analysts and designers to developers, making sure we all shared the same understanding of feature requirements.
Isabel told me,
I had a job earlier in the eighties which combined testing with second line support,
and even before that, in the seventies, as developers we spent most of our time testing (dry runs mainly). But then, back then, you could only compile your code once a day, so you got careful! I do sometimes wonder if making everyone go back to 1 compile every 24 hours would improve quality… At some point, everyone let go of so much good practices – right through the life cycle.
Isabel shared another story about continuous testing:
I went to a training day run by Bill Hetzel (I think 1987?) and he was talking about the importance of "Test then code" - he had badges to promote it - and I went back to the place I was working, and started to implement it.
I implemented it to start from testing - first discussions, through testing requirements, through testing design stages, to unit tests designed before coding, and then testing running through the stages from unit to integration to system to acceptance testing. We had a "stop and think and test/review" at every stage in our projects. Some of those were longer waterfall projects running for several months, and some of them (I'm talking 88 through to 1991 here) we were running continuous maintenance assignments on client projects, running 4 week cycles to pull down changes, and deliver to production systems every 4 weeks. It was well structured, and relied on the application of test mindset at each stage.
There were about 200 developers and Business Analysts (BA')s, and at that stage I was the only "tester" so the BA's also tested, and the developers reviewed each other's code, and tested each other's code. My job was to train them in testing, and in review/inspection methods, and in how to tailor those to risk and project size. I would coach, help etc. Implementing this took time, and building of trust, and demonstrating that I could test, and find useful improvements, and help them ditto. It meant demonstrating that having me in a spec review, or a meeting added benefit for everyone, and helped everyone. I saw my role as serving everyone and enabling them to succeed.
We also went out and taught customers how to test and how to review so they could join in at all stages, and report back on anything in live. And (we were a software house) we also involved a technical person in each sales proposal, and proposal documents were also reviewed and tested. So in the end, testing started presales... and went on into post delivery customer care - especially on the maintenance projects.
As a system tester - the only one in the company - I wrote a report to the managing director to say "we could do things differently and it would save time, money and hassle" and he asked me to implement it.
I am still proud of what I achieved there, still in touch with some of those people. At his 70th birthday party, Managing Director made a speech about the effect I’d had on the company - it was his birthday, but he chose to speak about the difference end to end testing made.
Nowadays, I am taking the shift even more seriously - if you are focused on User Experience (UX), it is even more important that you start at idea stage with testing and never stop. Keep retesting your ideas, your preconceptions of who the users are and what they are doing, and what the products provide for customers.
When Isabel says “end to end testing” there, she doesn’t just mean some automated test that encompasses a full user journey through all layers of an application. She means testing from the idea end of a product to the customers using the resulting features in production - and no doubt, taking what customers learn and feeding that back into the next new product ideas. That’s continuous testing! This is a different approach than joining the development team, but it is another way to spread testing knowledge and help the team focus on both testing early and testing in production.
Curiosity and confidence to shift
I’ve met so many testers who came to testing in an unusual way. I love Ken Talbot’s tester origin story! He’s an English and Film graduate who started out on a path to be a writer and journalist. An interest in exploring tech and software led him to working on a small test team where the development followed a waterfall approach. When the company transitioned to agile development, Ken was able to learn much more and communicate directly with developers, system administrators and database engineers on a daily basis. He was able to shift away from the waterfall testing-at-the-end approach by applying his natural curiosity, along with the courage that all of us testers need.
I have found - at two companies so far - that an inquisitive nature, coupled with as much confidence you can muster, enables shifting left/right. My previous company converted from waterfall to agile and my current one is government sector, so anything “newfangled” is alien in most corners. In both environments, questions like “do you mind if I come to X meeting” or “would you like to look over my Y test planning together?” really helps. Occasionally there will be a reply of “why do you/we need to XY?” and it’s only a simple matter of explaining the value of roles bleeding into each other during the whole dev cycle
I recently held a mob testing session with some new testers and graduate devs. The devs turned into inquisitive testers after a few turns and the testers were asking questions about programmatic design. This is something they confessed would never have happened in their project team.
Ken’s previous company encouraged teams to keep learning and evolving their agile practices. That’s key to the whole team approach to quality and testing, which in my experience results in the highest-performing and happiest teams. Ken recently joined another company, a cyber security consultancy, which is also undergoing an agile and DevOps evolution. He enjoys the opportunity to learn while also passing knowledge on to other testers and development teams. Here’s an example:
After a recent visit to a local tech expo, our company’s engineers were evangelising about the DevOps ecosystem and how 'everything is a dev problem now' as cloud architecture and infrastructure as code managed by the team no longer requires the traditional Dev-QA process. This understandably impacted the confidence of some of the testers, particularly the non-technical demographic. I felt the need to assure teams that not only was the 'everything is a dev problem' somewhat misinterpreted, but that if we used that logic then test is a dev concern and dev is a test concern. Identification of risk and implementation of test structures - automated or otherwise - still requires areas of the team to specialise in these factors. Seeding of that knowledge must begin somewhere and this is why testers must always be involved in all stages of the development cycle, especially in the architectural planning of the shiny new cloud-based world we live in. Since then, I believe all of our testers have continued to not only take an active role in development, but also start to broaden their knowledge of newer technologies to better assess the changing tech landscape.
Even if you don’t have a lot of testing experience, you’re probably good at asking questions and learning! With some extra courage, you can make your own opportunities to start collaborating with developers, operations experts, designers and others to move into testing ideas on the “left”, and learning from production use on the “right” - along with everything in between. Testing is an integral part of product development, not a “phase” to be done at one particular time in the cycle. Many of us have practiced continuous testing for years with great results. Don’t be afraid to take your first steps to a more holistic testing approach.
