Wrangling: Not Testing but Drowning 2

When a team is trying to get a system to work at all, I’d characterise their actions with the word Wrangling. Testers wrangle systems in a test environment. Their work is made harder if they don’t have permissions for that environment. They need to give that environment, and their system, the right configuration to gently hum with no input. They need tests to observe that steady state / ready state / several states - typically low-volume, happy-path stuff which often is called ‘smoke testing’. Ideally, but not always, they need their systems to be able to run those tests without restarting - which may need data to be re-generated, or (worse) environments to be purged, databases to be cleared or counters to be reset.

They may need information, and in the absence of information, to iterate towards something which may work. Over the years, I’ve worked with several teams which have spent weeks trying to get one transaction through their system. The typical pattern of bottlenecks involves: gaining access to they system – aligning test accounts (may be more than one needed if a key flow ie approvals needs more than one actor); gaining permissions through the layers of system hierarchy to act; gaining permissions through the layers of system and organisational hierarchy to observe; blocking off or stubbing outputs to other systems; mocking round-trips to other systems; using trial and error to discover the correct sequence of actions needed to get they system to do something; using trial and error to find the right information - lining up record validity, internal consistency, business rules and coherency with pre-existing data; working round and through points where the current knowledge is inadequate; working around and through points where the current knowledge is wrong; discovering output points for correct stuff; keeping track of different error messages and debugging towards those; observing different outputs and judging not whether the system is working or not, but whether the test is;  writing automation to do what a person can do;  much more (inc. limits of system here).

Each of these deserves an example - perhaps I’ll add those at a later edit. You don’t especially care about business stakeholders, when you’re wrangling, and they don’t particularly see what you’re doing. You don’t necessarily need a model of what the system does in terms of value to the organisation - but you’ll need a model of what the system is in terms of how its parts link together.