Developing bug-free software however… that is an entirely different story. Take our internally developed tools as an example: First of all, our software is used in a myriad of different setups, running various Operating System versions. Secondly, the openness of our platform gives users the opportunity to tinker with options, connect external databases or third party software, play around with the backend themselves, and so on. This means that the software must be ready for the millions of possible usage scenarios our clients devise. And finally, developers are also human beings – making a mistake every now and then.
In order to avoid releasing buggy software, there are three things you can do:
- More testing
- …And even more testing
This may seem logical at first, but it’s not as easy as you might think. We have been developing software for many years now, and learned a lot about testing. Lessons we learned from mistakes in the past:
- Don’t let developers test their own work, but use a fresh pair of eyes instead. Compare it with reviewing a text you just wrote yourself: someone else will more easily spot typo’s and mistakes, while your own eyes glance over it (even after reviewing your own work multiple times). The same thing applies for software testing: someone else will try out a new version in a different way than you, thus increasing the chance of finding bugs.
- Don’t outsource your testing. Certain companies on the market are specialised in this – and while it might work for some, this was not the case with us.
As a result, we decided to start our own separate Quality Assurance department last year, by hiring Bram Bleyen. He’s now our QA and Test Engineer.
So Bram, what are you doing around here?
Well, my typical work day consists of three big parts. First of all, I am writing automated test scripts that run daily and mimic a lot of standard actions and interactions that a typical user executes several times per day – but at a much quicker pace than humanly possible. The main tools I am using for this are Visual Studio’s testing tools, combined with Team Foundation Server. Every day, all developers upload their coding work (eg. new features that will be included in future versions of the software) onto our code revision control and source code management server – we use GitHub for that. Their work is immediately tested the day after, so major bugs or errors can be adjusted quickly.
During the weekend, a separate automated performance test puts the software platform under extreme pressure. This helps us to find out what the latest versions can handle, and if there are breaking points.
In other words: you just sit back and relax all day, letting the automated scripts do the work?
Of course not. A lot of testing happens manually as well – that is the second part of my job – because new features are added, or because it takes too much time to cover exotic usage scenarios in automated scripts. Another important aspect of manual testing is to check the user-friendliness of the UI/UX design: sometimes, a great usability idea on paper just does not work in real life.
And the third part of your job is…?
From time to time, users still find bugs in released versions of our software. That is why I am collaborating closely with our support department, as they are mostly the ones receiving info about these bugs from customers. My job is to try to recreate the bug by mimicking the way the client was using the software at the exact moment the bug appeared, and reporting this to the right development team that can start working on fixing the problem.
All this information is collected and kept up-to-date using shared folders and documents.
Sounds like a lot of stuff to manage at once.
It certainly is, but we are really starting to see the fruits of this approach with the next big release of our software. In fact, we feel like this approach has been so successful so far, the testing team will be expanded with a new colleague next month.
Thanks for reading!
Want to know more about this topic, or MyForce in general? Contact us!