Zo bewaken wij de kwaliteit van onze software

Alles begint met heldere afspraken

Wanneer een klant met een idee bij ons komt, starten we met een verkenning. Daarna leggen we de wensen vast in een System Requirement Specification (SRS). Dit document bevat functionele én technische eisen. Zo ontstaat er een concreet beeld van wat we gaan bouwen en waaraan het moet voldoen.

De SRS is het referentiepunt in het hele traject. Verandert er iets onderweg? Dan stemmen we dat af met de klant en werken we het document bij. Zo zorgen we ervoor dat verwachtingen en realiteit bij elkaar blijven.

Van eisen naar uitvoerbare taken

Op basis van de SRS gaan we aan de slag in refinement sessies. Tijdens deze sessies vertaalt ons team de eisen naar concrete ‘user stories’. Elke story beschrijft een stukje functionaliteit. Gezamenlijk vormen ze de complete scope van het project. Door vooraf alles uit te denken en op te delen, creëren we overzicht. We gebruiken hier tools als Atlassian Jira voor. Zo is voor iedereen duidelijk wat, door wie en wanneer er gebouwd moet worden.

Desondanks kunnen we een project pas écht perfectioneren als we tussendoor de juiste aanpassingen kunnen maken. Daarom werken we agile, zodat we tijdens de ontwikkeling flexibel kunnen schakelen.

Software bouwen met grip op kwaliteit

Software schrijven is één ding. Maar om de kwaliteit te waarborgen gebruiken wij verschillende elementen. Tijdens de implementatie houden we de controle met behulp van een vaste build environment (toolchain), verpakt in docker containers. Zo werkt iedereen met exact dezelfde tools en blijven de resultaten altijd reproduceerbaar. Zelfs jaren later wanneer iemand anders eraan werkt. De implementatie van de code wordt daarnaast altijd door een andere developer uit het team gecontroleerd via Pull Requests. Dit draagt bij aan de traceerbaarheid.

Voor onze CI/CD pipeline gebruiken we Jenkins. Die controleert automatisch elke wijziging die naar Gitea wordt gepusht. Denk aan checks voor code-style (linters), structuur (SonarQube volgens de MISRA C-standaard), documentatie (Sphinx) en compilatie. Pas als alles klopt accepteert Jenkins de samenvoeging van de code.

Testen, testen en nog eens testen

Kwaliteit bewaken betekent continu controleren of alles nog werkt zoals bedoeld. Daarom is testen een vast onderdeel van het ontwikkelproces. We hanteren drie testmethodes die elkaar aanvullen en versterken.

Unit tests (GTest) gebruiken we voor logica die losstaat van hardware. Denk aan functies die berekeningen uitvoeren of interne beslissingen nemen. Deze tests schrijven we direct mee met de code, zodat we bij elke wijziging automatisch kunnen controleren of alles nog klopt. GTest is een wereldwijd gebruikt testing framework van Google en draait bij ons volledig geautomatiseerd via Jenkins.

Unit tests on target (Unity) zetten we in voor code die afhankelijk is van hardware, zoals het uitlezen van sensoren of aansturen van microcontrollers. Dit type test voert de software uit op de daadwerkelijke hardware waarop het product draait. Unity is een lichtgewicht framework dat ons helpt om ook deze onderdelen betrouwbaar en herhaalbaar te testen.

Nightly builders voeren elke nacht een volledige reeks functionele- en regressietests uit. Deze tests bootsen realistische gebruiksscenario’s na, inclusief communicatie met servers of andere systemen. Het is als een digitale eindcontrole: voldoet het product nog aan de afgesproken werking? Fouten worden direct zichtbaar in onze dashboards en via Slack-notificaties zodat het team snel kan reageren.

Deze combinatie van testen geeft ons en onze klanten vertrouwen. We ontdekken fouten vroeg, zien direct de impact van wijzigingen en verkleinen de kans op problemen na oplevering aanzienlijk. Zo zorgen we voor stabiele, onderhoudbare software die doet wat het moet doen.

Versiebeheer en documentatie in balans

Elke oplevering leggen we vast in Gitea. Zo weten we altijd welke versie we hebben uitgeleverd en kunnen we eenvoudig teruggrijpen als dat nodig is. Ook documentatie nemen we serieus. We gebruiken Sphinx om documentatie direct aan de code te koppelen ('docs-as-code'). Hierdoor groeit de documentatie mee met de software en blijft alles actueel. Jenkins zorgt ervoor dat bij elke nieuwe softwareversie automatisch de juiste documentatie wordt gegenereerd.

Neem contact op!

Interesse in de mogelijkheden van embedded systems voor jouw organisatie? We gaan graag met je in gesprek om deze mogelijkheden te bespreken. Neem contact op voor een verkennend gesprek.

Wij kijken ernaar uit om van je te horen!

Neem contact op Neem contact op

Teamfoto van medewerkers tijdens meeting | Core-Vision