What building software taught me about testing software.
This is a blog for people who build software, people who test software and people who build software that tests software.
“SoFtWaRe ThAt TeStS sOfTwArE iSnT rEaL tEsTinG” people - welcome to 2020, enjoy your stay.
I’ve been around in quality assurance in a variety of ways for a hot minute now and have spent most of that time;
A) working with high performing teams and
B) building tools/ automating tests
The vast majority of my professional career - most of my adult life - I’ve been embedded in efforts of various shapes and sizes building someone else’s application/ systems where my primary objective was to ensure we shipped good software.
Previously, I’ve been pretty confident that there isn’t much more I need to learn about the role quality assurance plays in development teams.
From what I see and hear personally, there still seems to be a sense within the community that testing/quality assurance is still a bit under represented and under appreciated in the wider ‘tech’ scene. To all the people who feel that I say, try building your own.
In the last couple of years my business partner Linford and I have been investing in building our own apps. Naively, I thought that having come from a quality background the one area we’d have nailed better than any other was our QA.
What that has meant in reality is that we’ve worn the many hats required to develop software products. When you’re trying to turn your ideas in to software products, especially when you’re doing it ‘on the side’ for the most part, some of the biggest time sinks are in design and communication. There’s also managing the finances, marketing, prototyping, research, architecture and obviously writing the thing.
Where I’m getting to with this is, despite our most established skillsets being in the implementation of quality assurance and the dark arts of automation that is not where we had been investing the hours we had available to put into our product.
As you can probably [hopefully] guess, this lead to some of the signature symptoms you’re trained to spot in a system that had under developed QA around it. We found bugs late, features became unstable, we had to invest time in refactoring code to be more testable.
I’ll take the opportunity at this point in my tell-all-warts-n-all blog on the quality challenges we’ve had to make a couple of points. This situation is now remedied. We have great quality focussed developers around us and dedicated QA resources in the supply chain. Things have improved and we do now practice what we preach.
One of the first lessons you learn about the importance of considering testing early is that its cheaper and faster to fix issues the earlier you find them in the software lifecycle. That is a principal I have leant on many times in my career to protect the integrity of the work I do, to encourage early investment in testing and to justify some of the time I have spent to sceptical leadership.
I heard an oddly relevant analogy from a chiropractor once who said “Do these exercises daily and you’ll spend the rest of your life wondering why you wasted your money coming here”. For me this summarises perfectly the attitude towards quality practices in software. While you’re doing them well you rarely find out what happens if you don’t - which is ideal.
So the TLDR is basically, a great way to remind yourself why your place in the world as a quality advocate, test person or developer of testy things is to try building your own without it. Feel the pain. Be reassured that your work is important, testing is important, it does save time, it does save money and it does make your software better.