I recently attended a talk by Jeremias Rößler at Agile Testing Days titled “When will AI take my job as a tester?” where he showed the audience, without context, a screenshot of a software’s GUI and asked us if the calculated price of $550 was correct. No one could answer. Why? Because we didn’t know a single fact about the software — its intended purpose, its individual functionalities, its architecture.
Now imagine this in a work setting. You are given a piece of software you know nothing about and you are supposed to test it. You have no idea of the process it went through up until that point. What is its primary objective? Does it take into consideration edge cases? Has it been tested before? What is the best way for you test it?
Doesn’t sound awesome, does it?
To prevent scenarios like the one described above, it not only makes sense but is essential to involve testers in the software development process as early as possible. Starting the testing already in the first stages of the timeline, getting early and frequent feedback on software quality — this is widely referred to as “shifting left”. The concept is not a new one. Even in the traditional V model a — from today’s point of view — small shift towards the unit testing level was happening. Then incremental software development came up and testing began to be carried out earlier and more frequently, but still in a fairly strict “testing comes after development” manner.
These days many companies use agile approaches to build their products. Testers are in the process of going from being “defect detectors” to being “defect preventers” by fully engaging in the software development process as a whole. Moving outside the tester zone to collaborate with team members in other roles and other departments, thus shifting left, is key to achieving better quality.
But how far left can we shift? And how can software quality benefit not only from early testing itself, but from a tester’s general skill set? And what do I as the tester get out of it?
Let’s begin by looking at what happens directly to the left of the tester: code is being written. Writing unit and integration tests is a matter of course for many developers nowadays, so we’ve got that part of testing early covered, right? Well…yes and no (the most German answer ever). Unit and integration tests are fantastic tools to get early feedback on your code quality, so why not make them even better?
I’m about to throw two buzz phrases at you. Here it comes…test-driven development combined with pair programming; the developer and the tester being the pair here. Now, many testers I know (myself included) only have basic programming skills, so I’m hearing the cries of “But what can I as a tester bring to a pair programming session?”
Hear me out.
Testers are wired to convert requirements into testable units. Insert acceptance criteria, add coffee, receive test scenarios. That’s a lot how unit testing works. Together the developer and the tester break down requirements to a granular level and then transform them into unit tests. Perhaps they stumble upon inconsistencies in the logic, or they prevent each other from falling into the trap of misunderstood requirements that can lead to false positives both in automated and manual testing.
Ideally, the outcome of this collaboration is a more comprehensive set of unit tests that is tied closely to the given requirements. Only after the joint creation of each unit test the developer writes the piece of code that will make the test green. The result is user-centered, well-tested software.
Of course, pairing takes time which not every company is willing to give but consider this: Once implementation is finished and the software is handed over to the tester, he or she will know exactly how much of the code is unit-tested and where it’s safe to skip manual testing. This saves time, and what company doesn’t love that? So I say: testers should, nay, MUST demand unit tests be written wherever possible.
In addition to that, my team has come up with the so-called QA demo. After the implementation of a new feature has been completed, the developer shows me — the tester — what he did on his local machine. The point of this is not to test every nook and cranny in detail, but rather to check together whether all requirements of a user story have been met and that the feature is truly ready for in-depth testing. This is particularly useful when building and rebuilding a test environment after new commits takes several hours every single time — time that can be saved if defects are caught in the scope of a QA demo.
And even before implementation begins, testers can get involved. Larger projects in particular require some degree of technical planning in advance. Often there is more than one way to implement a feature, and sometimes two approaches are equally good. But what if one entails much more testing? In my experience, most developers have a good grasp on estimating testing effort. And yet, having a tester participate in technical planning and judging the expected testing effort in detail means a more precise plan and a more accurate prediction about time to market.
So far, we’ve shifted to the left to our direct neighbours, the developers. Let’s look a bit further. Who’s on their left? The answer to that might differ from company to company. In my case, it’s a trinity of product owners, UX/UI and UX researchers, with changing positions on the timeline among the three of them.
Generally speaking, product owners decide what is going to be built. They have the product vision. Sharing this vision with the team early on is crucial for every team member, not just the tester. A team that knows where the journey is going and why will be more motivated and take on greater responsibility. Aside from this emotional aspect — which should not be underestimated — early team involvement will result in better understanding the bigger picture and an improved ability to evaluate requirements together.
In this process, both the product owner and the tester can benefit from one-on-one sessions before a topic is presented to the whole team for estimation. I don’t know about you, but as soon as I see requirements, I start going through use cases in my head. A tester’s mind is trained to find weak spots and holes in a specification. Whether it’s a new feature or the redesign of an existing functionality — experienced testers often have the broadest domain knowledge within a team and can rattle off 26 edge cases from the top of their heads that the product owner may have missed. Don’t get me wrong: This is by no means a pointing out of shortcomings in a team mate’s work. It is rather drawing attention to possible stepping stones and adding puzzle pieces to make a specification as complete as possible. This early feedback can prevent defects that result from missing or misunderstood information, which in turn makes the tester’s life a little easier.
Of course, not all issues will be found before happening. But even after implementation and testing, a tester’s feedback to the product owner is valuable. Things that were noticed during testing — not necessarily defects, but parts of the feature that are not the best they could be yet, or ideas for the future. Even a root cause analysis of something that went horribly wrong is more than a final assessment of a project. Because in reality, the timeline in agile software development doesn’t end with the go-live of a feature, it goes back to the beginning where the next iteration begins.
The second member of the trinity mentioned above is UX/UI. Even though this role seems to have relatively little in common with that of a software tester at first glance, there is at least one trait that user experience designers and testers share: we think a lot about use cases and user flows. In my team we have established two platforms for exchange and collaboration between UX/UI and testers.
One is a meeting every other week where our UX designer sits together with the developers and me to give a preview of finished or on-going work before it makes its way into estimation meetings as a user story. It is an opportunity to receive feedback from a technical as well as a testing perspective. This often happens quite some time before the topic is to go into the implementation phase and thus leaves plenty of time to make adjustments if necessary.
The other is an informal desk get-together of UX/UI and me with a show and tell of mock-ups and user flows whenever it is needed. Just as in the collaboration with the product owner, I come with a basket full of use cases. With this input, UX/UI has the chance to gain more in-depth insights into the topic at hand, including specific details and any exceptions that may apply. This is especially useful for complex topics where many use cases need to be taken into account. In turn, I am granted an early peek at what’s to come and a detailed familiarity with UX/UI specifications that I will test against later on, which eliminates many of the “Why was it designed like this?” and “Did you really intend for it to work this way?” questions.
While UX/UI and the tester work together to collect use cases, collaboration with UX research is all about training the tester’s customer-centric mindset. In software testing, we don’t only test functionality but also usability. The problem is: after years of testing the same application or months of testing the same feature, we become blind to issues that real users may encounter. We tend to test isolated features and are liable to stop seeing the forest for all the trees.
How can we prevent that?
Joining user tests and reading reports with findings from user tests are great ways to bring the tester back to seeing the bigger picture. Do you sometimes catch yourself thinking “No one is ever going do THAT”? Because I do. But if there’s one thing I have learned in my years as a software tester it’s that there is always an actual user out there who will do exactly THAT and more things you’d never dream of testing.
This tweet by Brenan Keller hits the nail on its head:
Keeping an open mind is invaluable and watching your average customer become confused by the feature you thought was so carefully thought through can be quite humbling.
And there are more ways to feed the inner customer every software tester should nourish. Let testers from other teams test your feature before it goes live. They will have a fresh look at it and spot issues you may have missed. Then return the favour. You will learn about other parts of an application and understand business processes better. Speak to stakeholders. Read customer reviews. Ask customer service about feedback they receive. You might find out about problems that no one anticipated.
We’re pretty far left on the software development timeline by now. But we are not quite done yet. We can take shift left testing one step further by becoming the customer and eating our own dog food, as they say. This is obviously not possible with every kind of software, but if it is, I encourage you to use your company’s product like an actual customer would. Go through the entire journey of searching, comparing, adding items to our wishlist, leaving and coming back three days later, and finally making a purchase. It makes a huge difference when something is at stake for you personally — your money, the security of your personal details or the uncertainty of making the right choice. Every time I have done this, I have noticed something where I thought “If I — someone who works with this software on a daily basis — finds it difficult to understand this, how can a new user ever understand it?” That’s an invaluable insight.
A software tester, just like other team members along the software development timeline, cannot — and should not — exist as an isolated being. We are curious by nature and want to be involved. Shift left testing offers just that, and as we’ve seen it’s possible to move to the left a good deal if we limit neither the concept’s definition nor the job of a tester to testing only, but rather extend both to include knowledge transfer, striving for an understanding along every step of the way and providing helpful input wherever possible, all with the goal of bringing live relevant features with great quality faster. A product can benefit from a tester’s unique skill set in all of its stages. In turn, the tester is enabled to test better with more knowledge and gets the satisfaction of accompanying the creation of something new from beginning to end.