What does it mean for Buggy Software to be normal? Does that mean we get complacent? What can we learn by coding in JavaScript and HTML? Do we reach for professional tools too quickly? Or even not at all? This collection of micro posts answers these questions, and provides some exercises and tool links.
The following slogans were all automatically generated by The Evil Tester Sloganizer. And I then thought about what they might mean, and posted my reflections on Instagram. I’ve collated them here because they might trigger thoughts for you.
“Buggy Software is normal”
Unfortunately buggy software is normal.
Normal in the sense that we are no longer surprised by the presence of bugs.
Most of the software we encounter is general purpose and not life threatening. We accept bugs as the norm. We don’t really think about it.
But when we do think about it, and as Software Professionals we are prone to think about it more than other people, we realise that there are many occasions when the wrong bug, at the wrong time could be devastating.
People lost their homes when a bug appeared in Wells Fargo Software (as reported on CNBC)
“Normal” has extremes that we never want to encounter.
The Wells Fargo example isn’t an obvious ‘devastating context’ that I identified when first coming up with a list of ‘software that I never want to experience bugs in’.
For a true exercise in paranoia - try to find the most inocuous software you have installed… and then imagine a devastating bug that it might contain.
The degree that we try to track the bugs down through investigative testing, depends on the perceived risks and impact. Risk that the bug might manifest. Impact to ‘someone’ if it does. There might even be other considerations that are less ‘moral’ e.g. impact of a lawsuit if it does.
But just because we view ‘bugs in software’ as normal, we can’t be complacent. Hopefully, every day we work on improving our processes to minimise, as much as we can, the creation of bugs, we improve our detection processes to maximise the chances that we find them, and we improve our mitigation processes so that we can fix them quickly when they are encountered.
Exercise: what impacts the degree that you track down bugs through investigative testing in your environment?
Exercise: have you identified improvements to your process? are you working through them effectively enough?
Lessons Learned By Writing Web Apps
There are a few things I like about Web Technology: JavaScript, HTML, CSS
- the barrier to entry for experimentation is low
- the separation of concerns
The separation of concerns is particularly interesting.
- JavaScript functionality
- HTML Structure
- CSS Aesthetics
And then the overlaps where they can all add functionality, structure and aesthetics. And it is that ‘overlap’ where testing risks often manifest.
Most recently I created my text to image generator to practice and learn more. Which is live here
https://eviltester.github.io/textrenderer/
and with additional CSS here
https://www.talotics.com/app/textimager
I love the way that CSS can completely change the user experience, and impact the testing required. But if we don’t understand CSS then we can’t test it effectively.
I’ve expanded this post on Patreon to cover more ’likes’, explore the separation of concerns more and describe a little bit more about what I experimented with. https://www.patreon.com/posts/31158840
Exercise: next website you visit which has perceived functionality, investigate how much JavaScript, CSS, HTML contribute to that functionality.
You don’t always need complicated tools
One of the temptations we have around tooling is to spend a long time identifying the best tool for strategic use and calculate the ROI on a spreadsheet and… never actually get anything done.
Instead approach tool introduction as an MVP process:
- identify what you want to do
- find the simplest way to implement it
- iterate
e.g
I want to create a single file JavaScript component, but it was getting too big to maintain. I needed to split it into individual files and classes. There are many JavaScript bundlers to do this but…
I first of all split it into two files, and combined them manually - just to check that this worked.
Then I created a simple “cat file1.js file2.js > output.js” script.
Then I started splitting up my class and updating my cat script.
And this worked. I haven’t yet investigated bundlers. Although I have added “" into my cat script to make it easier to read.
Every process change introduces risk. Every tool introduces risk. If we try and do everything at the same time, the risk might magnify. Work in small steps and build up.
Exercise: Is there a simple action you can take to test out a tooling idea?
People sometimes avoid professional tools
As a caveat to the previous section. Sometimes we need to move on.
If you keep improving your processes, and skills, your understanding of the domain and your end goals.
Sometimes you end up at a professional level.
At which point, many people never change and adopt professional tools.
Professional tools doesn’t always mean expensive, although professional features often do come at a cost, As a side-effect you may be helping a tool you rely on actually stay viable as a business. If you don’t pay for it, it might disappear.
Professional tools doesn’t always mean easy, it might mean a little more complicated to use, but you probably have the experience to handle it and might now be able to take advantage of those complicated features.
Professional tools doesn’t always mean complex, it might mean - faster, more streamlined, better or maintained features. I’ve paid money for tools that replicate functionality I coded myself - simply so that I didn’t have to keep maintaining my own code.
Your use of tools will adapt over time as you gain experience. And if you’ve built your skills and business to a higher level then you do yourself a disservice if you aren’t using the right tools for your level. You don’t have to use them, but you should be making a conscious choice.
Don’t let tools you’ve grown used to, hold you back if you’ve out grown them.
Exercise: Are you aware of the professional tools that apply to the tasks you undertake. What stops you using them?
Here are some professional tools I use and pay for: IntelliJ, Total Validator Pro, Web Site Auditor
These are the type of subjects I discuss in my book “Dear Evil Tester”. I also write short (and sometimes long daily blog posts on Patreon)
