Of course, we can perform all kinds of testing without having an actual IT system to interact with. First of all we can test user stories, requirements and all kinds of early inputs to help verify the testability and viability of the proposed change. Secondly we can perform all kinds of static testing on the code, on documents in all matter of aspects. We can screen statistically for security flaws, spelling errorws and tone of voice 👀.
Loads of static testing these days can be tool supported, and hence it can be expected that whom ever produces an artefact runs basic static analysis on the deliverables. That goes for both code, for test plans and system documentation. This does not lower the bar. In my view it actually raises the bar for a first deliverable. Spellcheckers and code-compilers come to mind as quality checks we now expect to be part of the delivery. LLM-tooling in this space is just yet another shift-left (Shift-Left-Left, you saw it here first 😆), or rather a shift from one-off to integrated solution. Or from a hunch to a hard truth…
Desktop testing
A last example of testing without a system are table-top / desktop tests. It seems to be a forgotten skill among many testers. Perhaps it’s more of a strategic skill for staff-level testing roles. It it’s a thing and many contexts require this. Especially working on large migration programs, and major launches of new sites and systems. This is especially applied in the airline industry, for airport terminals and luggage solutions. But as a experienced test lead this should be in your utility belt.
Next time your team is doing a major migration – volunteer to lead.
And then make a manuscript, what happens when, by whom.
Test the manuscript before migrating even the smallest item
Desktop testing is similar to what happen in the production of movies or theaters. They rehearse the play sitting at a desk. Eventually they run a “dress rehearsal” or what ever the terms might be. For movies and plays they do this to rehearse the script and to give the customers a quality experience. Another aspect could also be mean-time to repair (MTTR). Read below for more situations where testing happens – without testers and without an IT system.
There is always a system
We are so caught up in an IT world, that we forget that a system can be generalized. A system under test can be anything: even a document, and an organization, but also a run book or marketing plan.
- we can use tools to test the deliverables statically
- we have host sessions where we walk-through and interact with the product
- we can setup test cases and log bugs towards the product
- we can setup requirements that we expect the deliverable to fulfill
Get in the minds of the people performing the exercise and be very very elaborate in the roles they play and how they can prepare. Yes, expect them to read the manuscript in advance if so required – or don’t if it’s a blind test. These are old-school practices that is especially important if interacting with people.