How can you reduce interruptions to coding which relate to testing?

In a previous article, we explained how an essay by Paul Graham identifies cutting down interruptions to coding as a top priority. Here, we’ll explore how you can reduce the number of times your coding is interrupted by factors which relate to software testing in order to ultimately drive your productivity much higher. 

Here’s our suggestions below:

#1 | Test the same amount in fewer instances 

The most obvious way to save time here is to have fewer testing sessions with the same amount of total testing.  If you spend 30 minutes a day testing, in addition to the 2h30 you’ve spent testing, you’ll spend a further 30 minutes per day (2h 30 per week) getting back into focus. Further to that, you’ll break up your coding into 3h slots rather than 6 hour slots. 

In contrast, if you allocate that same 12% of your testing into a single calendar morning, you’ll waste just 25 minutes getting back into focus. Therefore, if you can lump your testing together, that’s a better way to spend less-time context switching and more time coding.

#2 | Make sure your testers have enough context to not waste your time

The risk with outsourcing something is that in the end, it doesn’t save as much time as you think it will when you sign up. What if you end up with a needy supplier, which keeps asking you things and wastes your time by sending irrelevant bugs and false positives? Or by asking constant clarifying questions? 

We want to cut down false positives and only spend time on results which are relevant; second, we want to minimize our supplier asking for more information and interrupting our day. And in order to do that, we can focus on sharing information with our supplier more effectively, or simply choosing a supplier less inclined to waste your time.

– Proactively and passively share information with your supplier

To share information with your supplier as effectively as possible, you may want to front-load all your information sharing. 

In general, it’s better to give as much information up front as you can think of, to ensure you’re saying your assumptions aloud and playing them back to people. That could be information like what kinds of bugs get resolved vs deprioritized; what success looks like; what issues you’re already aware of.

Many suppliers like to find ways to review what you’re doing passively such as with meeting recordings. Developing a culture of recording and summarising meetings with AI tools and sharing them as open-access has never been easier, and can ensure that information is democratically available to the whole team. 

– Convey to a supplier that your time is important

Unfortunately, some suppliers won’t appreciate that you need to save time in order for their work to be cost-effective for your business. 

Targeting your supplier based on time saved is one way of thinking about this. Or even identifying that a low false positive rate is part of their target is one way to ensure that the suppliers know how important it is to you that they save you time. 

It might be useful to passively build a resource to help your supplier identify what a false positive is and means. For example, each time a new “type” of false positive is surfaced (e.g. a UI change leading to a tester not finding a button), you could add the example to the resource so that your test manager can see different false positive categories and take steps to avoid them. With the information and the pressure together, you should start to see a drop in the number of false positives you see.

– Choose a better supplier

Global App Testing has invested in a number of features and service attributes which are designed to save time for our clients. You don’t need to choose Global App Testing, but it’s worth knowing what those features are so you can raise them with your current provider or you can screen new providers who ask for similar measures.

  • Get testers who know your product

Many crowdtesting suppliers will rotate through different testers who are all knew to your product. In these instances, “noise” associated with first-time testing and product familiarity is regenerated with every test cycle. Ask your supplier for the same people again and again, where appropriate.

  • Get testers who have tested similar products

Gameplay and payments testing are two great examples of where testing can be challenging and where it’s invaluable to select a tester which has worked with operational requirements similar to yours.

  • Ask about the way they build documentation about your bug prioritities

If a testing supplier doesn’t have a framework for building understanding about your preferences, they will never improve their false positive rate from what it is at the beginning. Ensure that your supplier is actively building an understanding about what it is that you require. 

  • Ensure the bug reports are clear

Nothing could be worse than swallowing an interruption to pursue a bug report which does not include enough information to pinpoint the bug in question. In addition to the time wasted trying to find a bug which is not properly documented, you will lose the re-focus time on either side of the interruption. Streamlining your bug pinpointing 

Your bug reports should include:

  1. Step-by-step execution details
  2. Media (e.g. video of the issue)
  3. Crash and session logs
  4. Device environment
  5. OS & Version environment
  6. Test location
  7. Multi-tester confirmation where applicable
  8. Easy retests with adjusted parameters

 

#3 | Optimize requests and interruptions which relate to testing 

Another way of saving time would be to ringfence “deep focus work” in order to prevent "meetings interrupting makers" per the Paul Graham essay.

How you do this is up to you, but it might involve ensuring that team members focusing deeply are shielded from the requests and interruptions which departments with competing priorities will try to get to them.The following techniques are commonly used to ringfence focus work:

  1. Having somebody “on-call’ to answer requests and demands from other departments
  2. Quiet rooms and no-interruption rooms; “no phone” rooms
  3. Slack notification settings solutions and hacks (or your preferred supplier)
  4. Add a little bit of friction to asking you for things
  5. If a request is actually urgent, troubleshoot how it arose? Was it impossible to foresee? Or was it actually possible to schedule ahead of time / know about, but the asker didn’t think about it until the moment they needed the information? 

 

Global App Testing can help you cut down on false positives and interruptions in your manual software testing 

Curious? We’d love to talk to you more. Global App Testing is the supplier designed not only to save you from having to do manual testing, but also to help you streamline your test process and become more efficient and effective at undertaking tests in the first place.

We can help you drive global growth, better accessibility and better product quality at every level. 

Contact us