Loading

Welcome To Quality Firmware!

TestingComments are off for this post.

You Are Here:Welcome To Quality Firmware!

Quality Firmware you can test:

How do you know you wrote quality firmware? Well in order to answer the question, you first need to define what you mean by quality firmware. A couple items that come to mind are: the firmware meets all the requirements, it has no bugs, good code coverage, extensive unit test taht run automatically, low cyclomatic numbers, etc.

Manually inspecting code (code review) is a fundamental method for insuring you are producing good firmware of the highest quality. Firmware quality becomes harder to measure as the size (number of lines) increases. It is fairly intuitive that you can manually measure the quality of an amount of code that is under 2 pages, about 100+ lines of code, whether that be a complete code project or a simple function. That’s why code reviews should be done early and often. On a small project when commits are in the order of dozens of lines per day, having a weekly code review would be sufficient, but large project could have 100s or 1000s of lines of coding changing every day and it becomes simply impossible to have effective manual inspection. This is where the “test” part comes in. Teams need to setup automatic tests to insure code quality is where it needs to be. There are a number of automatic test that should be run at regular interval. Some test are run whenever a single line of code is changed, other are run nightly, some are run weekly, etc, depending of the size of the code base and the amount of time to run each test.

Example tests that can be run include nightly builds, automatic static code checker, unit test, stack size analysis, MISRA compliance, etc. Results of all those test can be pushed on a dashboard or simply emailed to the whole team, or only to the last author that broke something. Some test are simple pass / fail: Does the code compile, do all the unit tests run successfully? Some are more of a threshold level: cyclomatic number below 20, lines of code per function below 100, etc. where the threshold levels might change over the life of the project.

You then can keep track of your various quality metrics over time to make sure you are moving in the right direction.

To ensure your code is of the highest quality, make sure you test!

About the author:

Top