Have you ever used a workaround to get something done?

You betcha. In this show I describe some examples and how important they have been in my testing and my career. And some of the risks you face when you use them.


This podcast hsa also been uploaded to facebook:

Show Notes

Workarounds

  • Reminded recently because
  • Would I have thought of that without my testing experience
  • Entire career has involved workarounds
  • Neill McCarthy - conf - “Don’t let tools limit your testing”
  • Examples
    • Test Management Tool
      • No API
      • Desktop
      • Server based on a database
      • reports I want to generate, but can’t
      • workaround - if I had access to the database, I could open a read only connection and do what I want.
      • database administrator wouldn’t give us the password
        • this happens a lot, we don’t get the access we need
      • but they hadn’t changed the default password
        • built prototype
        • told them what I’d done
        • they wanted to change the password
        • management wouldn’t let them because the reporting was useful
    • Locked down machines
      • Can’t install tools or programming languages
      • USB stick with portable apps
      • Write your own tools using Excel with VBA
      • Learning the extension capabilities of your tools
        • API
        • Hooks - they call your scripts
        • Scripting
      • Modern variants
    • Technical examples require skills
      • Programming skills
    • Process Workarounds
      • Probably the most common
      • Art to bending the rules
      • Sticking to the spirit but not the letter of the law
      • Might get you in trouble
      • Templates
        • standard document templates
        • Information theory
          • compression techniques
            • boiler plate is data that is compressable to tiny bytes
            • but we have to process it
            • because we don’t know what is noise, data, information
            • information harder to compress because its more unexpected
            • noise might be really hard to compress we want to filter it out
        • template police
          • is the boiler plate in the doc
          • yup - I just moved it all to the back in the appendice
          • create summaries
      • Tool Use - Test Management Tools
        • Test conditions
        • xref to Test Cases
        • xref to Test Scripts
        • write out Test scripts
        • mark each step as passed
        • look for the biggest text area, fill that in
        • 1 step in the script - did test case run correctly?
        • Modern Agile wouldn’t do this?
          • Complicated tool workflows
          • Mandatory fields
          • Special Test plugins
          • Special Test fields
        • Workarounds
          • Comments and Description fields
          • Tasks and Attachments
  • When you are testing
    • Blocking Bug
      • find a way around it
      • inject data so you don’t have to follow that path
      • use the API
      • go direct to a particular URL rather than follow a path
    • Those techniques that we use for workarounds are also valid for going direct to the part of the app we want to test
      • Don’t login via the gui, submit the form data as post requests, capture the session cookie and inject it into a browser session.
      • Don’t startup a new browser for a new GUI session. Clear the cookies then inject the cookies you want and refresh the screen
      • Workarounds come with risks, but the knowledge you and the team have let you decide if those risks are worth it or not.
  • Workarounds have been fundamental to my testing life and building the flexibility of thought to look for options and find tools or build technology to take those alternative paths incredibly useful.
  • As an exercise - think through the workarounds that you’ve had to use.
    • Probably loads
  • Life Hack - know what outcome you want - stuff get in the way - find the workarounds that allow you to keep pushing forward.

Don’t let things limit your outcomes.