Quality in embedded software – how do we achieve it?

In our previous blog post we talked about why high quality software is so critical to Bluefruit and that it is at the heart of everything we do. This week we’d like to speak about HOW we achieve quality in our projects. Hint: it’s all to do with good communication, testing, and more testing!

When creating high quality software, there is a huge focus on trying to reduce the amount of bugs as well as looking for ways to respond to them quickly to lesson their impact. To help identify the source of bugs and then work to resolve them, we’ve found it useful to explore the core areas where the majority of bugs are generated and to expand the definition of bugs to include communication issues as well as issues around the coding.

At Bluefruit, we believe that high quality software depends on strong communication and feedback loops between the customer, product owners, and the software team:

Note:  for a refresher on perceived and conceptual integrity check out this post.

In this diagram the elements within the green section are where the customer is interacting directly with the product (and the product team). In this instance, poor quality would typically mean issues with the user experience.

The purple section deals with the ‘beneath the surface’ variables around the quality of the software within the device, with poor quality resulting from issues within the coding or possibly issues around detailing out the requirements.

To create high quality software and in turn a high quality product, effective communication between all three elements is critical. As we said earlier, it isn’t just about preventing bugs from happening in the first place, it also about identifying bugs early so they can be addressed as quickly as possible. Bugs linger when any elements of this communication cycle breaks down.

How do we minimise these communication issues?

We use a toolkit of Lean-Agile methodologies to help create effective, valuable feedback loops between the customer, engineering team, and the product. Even if the goal is to deliver a quality user experience, the Conceptual Integrity issues need to be solved first. Like with driving a car, you can’t have a smooth ride unless everything under the hood is working properly

To achieve quality within the software engineering process, we start with thorough sprint planning meetings with clients. At Bluefruit we refer to our planning meetings as a “Three Amigos” as we bring together the engineers, the testers, and the product owner, to ensure everyone is on the same page from the start. Within these meetings the “three amigos” sit together to outline the software features and requirements for that sprint. At the start of the sprint we also start to form test acceptance criteria, which will allow our software engineers to undertake Test-Driven Development (TDD) and Behaviour-Driven Development (BDD) as we go, two critical tools for fighting our battle against the bugs.

Test-Driven Development (TDD) a.k.a. build the thing right

Test-Driven Development is a software development technique whereby a “unit test” for the code is written before the functional code itself is written. When these automated tests are written, they are tested (again, before any functional code is added) to make sure they fail, to show that the test is working. When we know that the unit test is working, we can add the functional code and run the test on it. If it passes, the code is refactored (i.e. tidied up), tested again, and the process is repeated for each feature. If it fails, the code needs to be tweaked and simplified until it does pass.

Behaviour-Driven Development (BDD) a.k.a. build the right thing

Behaviour-Driven Development is all about creating a common understanding between the customer and the engineering team about what the requirements and features are for the software. In software engineering, BDD is a software development process that emerged from TDD. Behaviour-Driven Development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development. Although BDD is principally an idea about how software development should be managed by both business interests and technical insight, the practice of BDD assumes the use of specialised software tools to support the development process.

Testing early and often not only improves the quality of our code, it also improves the efficiency of our team. The earlier we discover and solve a problem, the easier it is to fix. It also makes it more likely that the issue won’t infect the rest of the project. TDD increases code test coverage and can be automated to highlight any regression failures sooner. By following up with a full suite of manual test and regression testing, we know we are doing everything we can to not only write great code, but to check that it does what it is supposed to do.

We close this series of posts on quality with a quote from Yan, one of our team leads, on the impact of quality both on projects and software engineers:

“I’m personally most impressed by how we deliver successful projects. In my pre-agile career projects were, more often than not, late and buggy and engineers were stressed. Our Lean-Aagile approach has fixed these as follows.
Late: The sprint/epic/story/velocity/continuous delivery TDD and testing tools we use mean that progress can be tracked and the product features adjusted to suit both commercial deadlines and users’ expectations.
Buggy: TDD/testing/vertical features/focus on risk tools allow us to evaluate challenging and risky areas early in the product; vertical stories also often expose hitherto unknown risks.
Stress: A philosophy that quality is paramount means that any project’s adjustable parameters are scope, time, and budget – never quality.
Nothing stresses a software engineer (or clients) more than poor quality, nothing pleases them more than continuous successful delivery.”

To learn more about the processes we use to ensure quality in embedded software development, head on over to our processes and quality pages.