During This Week in Testing, @ajwilson came up with a brilliant question.
Whatâs the most niche thing youâve tested?
We heard excellent stories about walking the streets of the UK to mimic finding a 3-meter squared location in the US, to driving into the middle of a field and also testing an old booking system for railway engineering called SABRE.
Iâd love to hear your stories, whatâs the most niche thing youâve tested?
An on-demand taxi rental app (Dryve NYC) once provided us with a Conditional Access Module that would unlock vehicles in the real world. To test how our app communicates with under certain circumstances, I placed the module on the top floor (3rd) of our building and then walked out of our office to try and connect to it.
Anti-detect browsers and spoofing digital fingerprint software, also, web scrappers, cookies import/export software, and captcha solvers. Generally speaking, this software isnât commonly used and does not belong to a popular niche
I was involved in an early health monitoring product.
It was designed to send a small electric current to get the readings.
For end users that meant a small electric shock once a week, for us testers we half jokingly compared it to spending your day periodically licking a 9 volt battery.
In hindsight we should have organised a few bring your kids to work days to help out.
Spend months preparing Excel spreadsheets. Couldnât speak to the developers.
This was 2003-2004 and my first job as a naive Test Analyst so I knew no better.
During the âtesting phaseâ, weâd hole up in a test lab, a dingy room tucked away on the ground floor of the office. Print all the spreadsheets out and stick them on the temporary felt walls. Pencil in hand ready to mark each test step as pass or fail.
Boot up the passbook printer. Shove in some empty passbook and start testing.
Within five or so minutes something would fail.
âRight everyone, pull down the rest of the sheets and letâs stop for today. Weâll need to update all the sheets and print them out again tomorrow.â
I used to test a piece of software that parsed plain text files that were handed off by various Global Distribution Systems.
All the application did was parse these text files into an SQL database⌠yet despite this, the application was over 100mb to install.
It was written and maintained by pretty much 1 person. Only ran on Windows. Couldnât run as a service (always had to be on screen). Often crashed with an error messages, stopping all text file parsing, the error on screen would need clicking - often lead to a backup of text files to parse.
It had an extremely unfriendly interface. All the buttons were pictures (for example, the âexitâ button looked like one of those green building exit signs)
It performed such an important job for the people using it, but the application was absolutely rubbish - and as far as Iâm aware the main reason for this was because no one else knew how to parse the different GDS systemâs text files (or could be bothered to learn how to)
In a application for logistics we added a map feature to see where all the drivers (by their mobile devices) are.
Most of the time we used recorded or generated data, but once in a while someone had to drive around to test this. Sometimes for regression, sometimes because of added features.
How often are coming the location updates?
How big are the differences between the locations?
âŚ
The Burger Collective app is the first one that comes to my mind, tho there were many other niche apps as well.
Itâs a social network for burger lovers, and v2.0 had geo-tagging feature that automatically adds an draft burger review to your profile when you enter some burger joint (based on your geo location).
Sure enough, I was eating at least one burger every day before going to production with 2.0, and it was quite interesting (and tasty) experience.
One of our customers used these coal mining machines, which basically use a type of rail track to push a cutter into the rockface.
This meant a trip 150 meters underground and being left alone for 2 hours. Alone in a dark echoey tunnel in 6 inches of black water with only a headlamp, laptop and one lightbulb, all connected to this long rock-eating machine. 2 Hours later I had a protocol dump and some working code, it was not so much a âtestingâ job at that time, but I used all of our testing tools to actually do the protocol dumps and then used the same test and simulation tools again once I got back into the sunlight.
When I was working in a home digital company, we had a device to control electric shutters (the ones that you usually find in Spain that roll up).
My dad has a company that makes and installs those type of shutters. My company ordered him one in a fake window that we could have in the office to connect the test devices to then test the programmes and make sure the shutter would behave as expected (eg: open 50%, close to 30%, etc)