Why is a Robot Using our App – ArchiSnapper?
A few times a week, a robot is using our app ArchiSnapper.
He (or is it a she?) is clicking on almost every single button in the app.
Strangely enough, he (let’s stick with “he”) is doing the same set of clicks every time.
The scenario goes like this more or less, he:
- Makes a field report or punch list with some photos, some observations and some assignees on an iPad.
- Syncs it to the cloud.
- Checks if the report is in his online account.
- If yes, he writes down a “green” bullet on a screen, and continues…
- Clones that report on his iPad.
- Syncs the cloned report.
- Checks, in his online account, if there are two identical reports, the original one, and the cloned one.
- Puts another “green” bullet if it is the case, and continues.
- … (and so he goes on for almost 2 hours!)
Just imagine, what a fool!
He must have too much time, or does not know what to do with his life…
Let’s have a look at the robot in action, putting green dots…
Now, why is this robot doing this?
Here is the reason:
We have a couple of thousand users using our apps ArchiSnapper and SafetySnapper, almost on a daily or at least weekly basis.
Our apps works with business data and generates punch lists, field reports and safety inspections, which sometimes have legal value.
At the same time, our app is under constant development since 2013: on a weekly basis, new features are added, fine-tuned, and adapted.
Let’s say we add a new feature to locate an item on a PDF plan.
(This feature is already existing in our app btw, it’s just an example).
Now, you can imagine that this feature has an impact on quite a lot of places, screens and buttons in our app, as well as in the online cloud software:
- new fields to store in the database
- new buttons in different screens in the app
- new business logic which has to understand how this all works and interacts
- new images in the field report (PDF), being the PDF screenshot of the located observation
- … and the list goes on.
That means, in order to work out this feature, our team of developers has to tweak certain things in almost all parts of the existing code.
One small feature could easily lead to 200 lines of code changed in 20 different files, in order to get it shipped to production. A big change or new feature will easily “touch” 5000 lines of code in 100 different files.
Next to all the code changes, there are also lots of “possible paths” or ways how our app is used.
Some users typically first go to screen A, then to screen B. Then C. Some users skip B, and go from A to C. Some users first open screen C, and then go to A. Some work on iPad, some on iPhone. Some take photos, some not.
You get the point.
We have hundreds of screens, just imagine how much possible “pathways” there are! Thousands and thousands of possible ways to click through our app.
And we have to ensure that after changing either 5 or 5000 lines of code, all those “click paths” still work without bugs, on all of the possible devices, in all the supported languages.
Now, who has the time, energy, focus and concentration to test thousands of possible click paths through our app, on different devices, after some code changes?
Who doesn’t make human mistakes, is never late due to traffic jam, keeps on smiling and is not gossiping?
Exactly… our robot.
For the geeks: technically spoken, it’s not a robot but actually another piece of software, which is set up and written in such a way to test our main software in an automatic way. We call this test-driven development.
Our developers write and maintain as well the main software (our app) as well as the surrounding testing software. 20% – 50% of their time is dedicated to writing test-software: our robot.
Week after week, month after month, year after year, this robot will do what we ask him to do: thousands of clicks, and run through our whole application, after which he presents us a helpful report on where he got stuck or where everything went as expected.
Check this:
This is the robot saying: “I did 73 minutes of testing, I did check 4542 things, and I could not find any issue (0 failures).“
The beauty of this is that if we tell this robot to run the tests on Android, he will also run it on iOS. No problem! iPhone? Yes, sir! iPad? Of course.
So, our friendly robot can assure you and me that nothing has been broken, on any of the devices, of any of the possible paths and click combinations of our app.
Assure you and me that nothing has been broken, on any of the devices, of any of the possible paths and click combinations of our app.
We ♥ you so much, robot :-)
All fine, Peter, but why should I care?
I hear you thinking: “Pretty funky, but what’s in for me, Peter? Why should I care?“
Well, while it’s a lot of work to “train” that robot to do what he has to do (our developers spend easily 20% – 50% of their time on writing the robot-testing-software)….. it’s much more misery, pain, stress, headaches and reputation damage for us if there is a bug sneaking into the app, which results in (for example) data loss for all our clients.
A simple forgotten “dot” or “comma” in a database query in the code, could result in data loss.
That might be 20 full days of “punch list work” flushed through the toilet. Auuuuwch…
“data loss” times “100 users” = complaints, support, or worst case: a lawsuit or 2.
Our robot minimises that risk. For us and for you.
Our robot assures you, as a user, that you have a quite stable and future proof piece of software in hands, which is much less risky to crash randomly on updates, and result in big data loss or what so ever.
If you pick a software or app for, say, something like field reports, punch lists or construction collaboration (all things which have legal or business-critical value soon or later), you are for sure better off with a working and future proof piece of software.
Happy punching, snagging, and reporting :-)
