When the tester's away… the team can test anyway!

by?Emily O'Connor?|?Read online at Ministry of Testing

The certification that gives junior testers confidence, community and connections.

Explore MoT Software Testing Essentials Certificate

I’m Emily, I’m a Principal Test Engineer, and I say it’s time to say?goodbye?to writing time-consuming handover documents and?hello?to effective testing when you're out of office!

In my role, I work across various teams and have a lot of context for the various projects going on around the business.

The many pitfalls of handover documents

This year, before I write my out-of-office from the day job to travel to Athens for the Ministry of Testing meetup on the beach, I will NOT be writing a handover document for the development teams I work with.

If this sounds like a strange arrangement I’ve come to, let me tell you why I've adopted it and how you can too.

In a former role, when I was due to go on annual leave, I’d be encouraged by my manager to do a handover call and create an accompanying document for the development team.

So, I’d spend the better part of a day creating a document with ticket numbers and task descriptions. I’d detail which part of the automated test pack needed adding to, updating, or running, and I'd provide instructions on linking the pipeline output to the tickets being tested. Then I’d define structured test cases and detailed instructions on how to perform this testing: against APIs; on the UI; and on various devices.

The result?

Two bottlenecks for the price of one

The developers would follow the document like a checklist and “pass” or “fail” the features created. The code for all the features would sit in the test environment until my return, so I could give the final signoff and feel all caught up.

So not only was valuable testing time BEFORE my leave taken up by creating the handover document, but the idle period after the team followed the test plan also meant users could have seen new features sooner, had I been online. Two bottlenecks, not just one.

We can see this solution isn’t perfect. But what’s the alternative? No tester, no testing? Obviously not testing while the tester is away is a bad idea! But writing a handover document and talking the tech lead through it before I was out of office wasn’t a good idea either.

The after effects of siloed testing expertise

Part of the reason I’d often be asked to write these handover documents was because, as is often the case, I was the only tester working on that specific part of the product. My manager worked in another area of the business, as part of a practice called matrix management. Matrix management is where an employee (Emily) reports to a manager in the same project or product area (the tech lead, an experienced developer) and another more experienced person of the same job family within the same office location. Although I’d describe the more senior tester as my main manager, this person doesn’t have all of the day-to-day context of my project.

I always thought that if I left the development team to their own devices, they’d just say, “We don’t need testers”, and the product quality would decline, leaving me to do even more work or, at a minimum, still have a backlog of tasks on my return.

But not writing a handover at all…?

In my current role, handover documents, calls, and holiday preparations simply aren’t a?thing. Based on my experiences, I’d like to encourage all testers to adopt this practice. In fact, I’d go as far as to advise testers NOT to do handovers anymore, because it discourages the development teams from taking ownership of testing tasks.

Claim Your Space in the Ministry of Testing Universe ?? (MoTaverse)

Update your Profile Today ??

Enable your team to test effectively anytime

Let’s imagine that the handover document described the following test case; as a student, I can see the grades given to me by my tutors. To test this, I document the test steps: log in to the test environment using the tutor user role and ensure the tutor can assign grades to all students. Next, log in as a student and ensure that only the logged-in student’s grade can be seen on the results portal and that the grades assigned and received are the same.

This documentation would become restrictive and the development team would follow the scenario exactly. Often, they wouldn’t explore new features developed beyond the scripted test, and they would miss UI / UX bugs.

In this example, the handover document is a quality paradox because the developers would follow the guiderails so closely they wouldn’t be able to effectively test the system.

Don't write a handover—ensure everyone on the team can think like a tester

Day-to-day, it would always be me asking the questions, “How will we know when this task is done and working as expected?” (What are the expected behaviours?) Or “What does that look like if the student doesn’t have any results in the portal?” (How are edge cases presented?) Writing a handover blocked the development team from learning how to do this, too.

To ensure testing doesn’t depend on you while you’re away, don’t write a handover. Instead, teach your team about the types of testing you perform in addition to the structured test cases they see documented and?how?you came across any bugs in the system. This way, they too, can adopt these skills.

Forget the elaborate process documents, and make sure anyone on your team knows how to pick up the testing reins. This will take some time initially, but it will pay off later!

Don't write a handover—ensure that quality is everyone's responsibility

When the handover describes changes and additions to automated tests, provides instructions, defined test cases and detailed instructions on how to perform this testing, it’s obvious that the development team is following a guide.

If?James May’s Toy Stories?(a British TV show about complex, large-scale projects based on notable toys) taught me anything, it was that when you abandon standard instructions for a different approach, you engage in better problem solving and develop a stronger sense of creativity, ownership and understanding. So by not writing a handover, you foster a greater sense of team-wide responsibility.

By educating the team on how to perform exploratory testing and pairing with them day-to-day, these tasks become everyone’s responsibility and speed up development. Everybody in the development team has their own focus areas (adding features, gathering requirements etc.), meaning although quality engineers need to challenge and support teams to deliver better products, all team members can contribute to system-wide testing.

Don’t write a handover—ensure documentation is written regularly

One way to ensure an appropriate distribution of testing activities like managing test data, identifying pipeline failures, or writing tests is to put in place documentation of day-to-day tasks. This documentation could be what you’re doing, the questions you’re asking, risks you’re raising, so that the team can retrace your steps if you’re not about—just so long as it is not too prescriptive to impede the development team's ability to take ownership.

As an example, if you’re adding a feature to part of the system, you might create a small pack of regression test cases that always need to be run when working in that system area. For example, adding a new user role and ensuring they can still reset their password. This gives the development team a jumping-off point for their own exploratory testing and ensures a minimum quality bar is always met. It also gives a worked example of how to document test cases, enabling other contributions.

If others try to “cover” testing during your annual leave without proper experience, it may lead to overlooked bugs or inadequate test coverage. But if they are already in the habit of documenting the types of testing needed, they can gain that experience while you’re around to ask questions.

Don’t write a handover—ensure the team has "release confidence"

Teaching the team what testing?is, ensuring everybody can contribute, and providing documentation that meets or exceeds a minimum quality bar should provide the team with the confidence to release code to production without end-of-the-line testing. Release confidence means it’s never an individual tester's “fault” when a bug affects actual customers.

Make sure the team knows that you’re not the final quality check and that delaying releases by waiting for you will slow down the development cycle. Give them the confidence to release by ensuring that small rollbacks are practised frequently. For example, if a card introduces too many bugs into the test environment, use the card to practise reverting the changes rather than forward-fixing with pull requests for bug fixes.

As a bonus, the entire development team will begin to form their own opinions on the acceptable risks for deployment to various environments (such as test, UAT, stage or production). To enable this mindset, ask the development team to highlight riskier areas that might require more testing.

Asking the development team to highlight higher-risk areas gives me a focal point of testing on my return to work, but not nearly as much of the stress as I’d have catching up with a product that’s not been tested for two weeks!

While you’re in the office, try to quantify the impact of releases. In our team's results portal, a UI bug was introduced where the students' grades didn’t align with the assignments they related to. The development team determined that this was an acceptable bug in the test environment, but shouldn’t be released further as this would be confusing for our users. The impact of releasing this bug to production could have been usability or reputational.

A few days later, while quickly applying more UI improvements, a developer released buttons with a padding of 5rem instead of 0.5rem. This made using the test environment trickier for everybody! All stakeholders quickly stopped using the test site in frustration. This was a great way to practice reverting specific commits from the test environment and educate the team about evaluating acceptable risks.

Don’t write a handover—ensure work is showcased to internal stakeholders for UAT

After the development team has released work into an appropriate environment, it’s often the case that features will be part of user acceptance testing or percentage-based A/B tests before they are deployed to all users.

To enable UAT and remove the need for a holiday handover, encourage the team to maintain a wiki describing how to do certain user journeys, including key observations and images or GIFs of the system's functionality. This way a wider group of people can learn system context and point out bugs or assumptions that the development team might have made. On my return to work, a wider group of people from the development team and user acceptance testing groups have tested the team’s features without me.

This process means it’s easier to spot small errors and expected behaviours are documented as working if something does go wrong. That being said, UAT is unlikely to go through each user’s permissions and check the appropriate security or consider every boundary in a complex system.

To wrap up

None of these changes are overnight or simple fixes.

Ensuring the team understands the type of testing required and the types of questions that I often ask means everyone on the team can think like a tester. So I don’t need to document that in an out-of-office handover.

Documentation detailing the types of testing I perform, minimal regression test packs, and how to perform testing activities should be written regularly to enable team-wide ownership.??

I don’t want to return to work to a backlog of tickets in the “ready to test” column of the board, so ensuring that quality is everyone's responsibility and that work is showcased to internal stakeholders for UAT means I don’t need to write a comprehensive out-of-office handover.

Finally, ensuring the team has release confidence, with special attention to riskier areas that might require more testing, means testers don’t become an end-of-the-line quality check (or bottleneck). And with all this,?you’ll never have to write another holiday handover!

So, on my return to work, I look forward to reviewing a slimmed-down “ready to test” column on our maintained board so I can just slot right in again. Although I might keep my out-of-office on another day so I can settle into it, pair testing with the developers and showing off my holiday snaps!

For more information

• An introduction to continuous quality, Stuart Day
• Better Software, Faster: A Tester’s Report On The Quality Assistance Model, Nataliia Burmei
• A Really Useful List For Exploratory Testers, Simon Tomes

"MoT is becoming a paradise for testers to experiment, extend, and innovate. In a world of limited opportunities for testers, MoT is creating the difference we all needed!"?—?Rahul Parwal

Upgrade your software testing career with Ministry of Testing

Being able to access The Club & The Dojo to share or glean knowledge within the testing community is definitely an asset to my professional career. MoT Membership has helped me to keep up-to-date on the latest schools of thought and tools testers are using globally.- Kim Nepata

Make your testing smarter with MoT Pro. You can attend workshops and conferences to learn about the diverse range of topics in the testing space. You can deep dive in the back catalog of 100rds of talks and workshops to pick the topics that fit your learning path. Pro enables you to catch up at a time of your availability for personal or work reasons.- Jesper Ottosen