Testing, one, two.
You have to test, there’s no two ways about it. You wouldn’t bake a cake without tasting it, would you? The same applies with embedded software (and no-one likes soggy cake either).
The main objectives of testing are:
A. to make sure it works
B. to find any bugs lurking in the system
It’s a technological flypaper if you will!
Here are a few methods we use at Bluefruit:
Test Driven Development
“If it’s worth building, it’s worth testing. If it’s not worth testing, why are you wasting your time working on it?” – Scott Ambler (Scott Ambler + Associates, Agile Strategy Specialists)
In traditional development, code is written with testing as an afterthought, but TDD means that all coding specifications should begin with a test. This first test should be designed to fail before the functional code is even written yet, so that it is easy to see from the first step whether it is working successfully or not.
Behaviour Driven Development/BDD on target hardware
The truth is, we can sometimes get lost in our world of acronyms, homonyms and techie-speak – so we ensure that when we test software we use basic language (English, no less!) to keep testing methods succinct and understandable.
The other benefit of using a more ubiquitous language is that the non or less technical members of the team can clearly see how a function is being used and why, enabling them to analyse the necessity of each one and reduce waste.
Working with/testing legacy code
Legacy code: the hand-me-down of the software world.
The continually changing field of technology means that when developing new products, there is an element of code that is superfluous to the platform (often through manufacturer’s upgrade or included to support older technology or file formats) which may have been written in a different style.
When it comes to testing and working with legacy code, we alter the code to bring it up to the highest quality, keeping the fundamental functions needed to support retrospective technology.
This is essentially compiling code using a different system than to what is intended (it sounds complicated, but an example is writing software on one operating system, when the code is destined for use on another).
The main reason for this is that the ‘host’ (programmer) system may be better suited to the task, possibly due to space constraints to code creation on the target, or ‘programee’ system.
Code review and Pair Programming
Otherwise known as peer review (or in laymen’s terms, ‘another set of eyes’), this is extremely effective way of finding faults and inconsistencies in code.
A specific method of code reviewing, known as Pair Programming, is where an ‘observer’ developer will review each line of code as the ‘driver’ developer writes it, keeping a keen eye out for potential bugs or mistakes.
As well as improving the software-in-case, both developers continually learn from each other, and are able to discuss solutions to any problems in a collaborative way – which suits us down to the ground!
A mechanized technique to find the bugs and stumbling blocks within software, static analysis is the examination of code without the need for executive written software.
Static analysis is usually performed using an automated tool, using programmes such as a compiler to find mistakes within human-written code.