Kaffeepause 11:15 - 11:45
08:50 Uhr
QA Navigation Board
Wie planen wir die Qualitätssicherung in agilen Projekten?
Details anzeigen
Autor:in:
Kay Grebenstein | ZEISS Digital Innovation | Germany
Sprache:
Deutsch
Zielgruppe:
Tester, Entwickler
Voraussetzungen:
Grundkenntnisse Agile Entwicklung
Überblick und Zusammenfassungen:
Bereits vor der Einführung der agilen Methoden und DevOps war das Ziel von Entwicklungsprojekten die schnelle Bereitstellung von hochwertigen Produkten. Im Vordergrund stehen die Überlegungen zur optimalen Architektur und zum passenden Design. Die Aspekte der Qualitätssicherung kommen meist später, was sich während der Tests bemerkbar macht.
In diesem Vortrag wird das QA Navigation Board vorgestellt. Mit dem QA Navigation Board haben die Entwicklungsteams ein visuelles Hilfsmittel mit dem sie frühzeitig die planerischen Aspekte der Qualitätssicherung beurteilen können. Dabei kann das QA Navigation Board innerhalb der Projektlaufzeit auch als Referenz des aktuellen Vorgehens und als Ansatz für potentielle Verbesserung genutzt werden.
Art der Vermittlung:
Methodenerklärung
Nutzen:
Verifizierung, Validierung und Dokumentation des Testprozesses durch ein einfaches agiles Werkzeug zur QA-Strategie: Der QA Navigation Board . Mit dem QA Navigation Board haben die agilen Projekte ein visuelles Hilfsmittel mit dem alle Beteiligten gemeinsam die Ausrichtung der QA-Strategie des Projektes zu gestalten können. Dabei kann derQA Navigation Board innerhalb der Projektlaufzeit auch als Referenz des aktuellen Vorgehens und als Ansatz für potenzielle Verbesserung genutzt werden.
09:45 Uhr
HiL und Continuous-Integration – wie passt das zusammen?
Continuous-Testing für Embedded-Systeme
Details anzeigen
Autor:in:
Thomas Schuetz | PROTOS Software GmbH | Germany
Sprache:
deutsch
Zielgruppe:
Embedded Entwickler, Tester, Projektleiter, Architekten, Qualitätsbeauftragte
Voraussetzungen:
keine
Überblick und Zusammenfassungen:
Jede kleine Änderung an einem Embedded System kann bösartigste Auswirkungen haben. Findet und behebt man die Probleme zu spät, ist die Behebung zudem sehr teuer.
Daher sollte jede Änderung an einem Embedded System innerhalb von Minuten getestet werden können. Nur so kann man sicherstellen, dass man die Probleme schnell entdecken und beheben kann.
Bei reinen Softwareprojekten hilft eine vollständige Automatisierung der Tests über Continuous-Integration (CI). Hierbei löst jede Codeänderung automatisch den Bau und Test der kompletten Software aus. Dadurch kann innerhalb von Minuten ein vollständiger Regressionstest Fehler in bestehendem und neuem Code entdecken.
Aber wie kann man das für System- oder Integrationstests bei Embedded Systemen erreichen?
Dafür nötige Hardware-in-the-Loop Tests (HIL-Test) oder manuelle System-Tests sind häufig schwer zu automatisieren.
* Echte Hardwareanteile im Testaufbau verhindern die Automatisierung und Wiederholbarkeit
* Häufig kann nur der „Happy Path“, nicht aber ein Fehlverhalten getestet werden
* Der Teststand ist häufig zu teuer um für jedes Projekt, jederzeit für Automatisierung verfügbar zu sein
Durch einen leichtgewichtigen Hardware-in-the-Loop Test kann man die Tests vollständig über Continuous-Integration automatisieren.
Wie geht das?
* Hardwareschnittstellen werden nur auf Signalebene simuliert, und passen daher gut in die Test-Automatisierung
* Testhardware wird größtenteils durch Softwaresimulationen ersetzt
* Fehlverhalten kann einfach über fehlerhafte Signale simuliert und getestet werden
* Die dazu nötige Hardware ist signifikant einfacher, kleiner und preiswerter als traditionelle HIL-Systeme. Für jedes Projekt steht jederzeit ein eigener Testaufbau für die Automatisierung zur Verfügung.
So kann jede Änderung innerhalb von Minuten automatisch getestet werden.
Erst durch die vollständige und schnelle Testautomatisierung kann effektiv in Teams gemeinsam komplexe Embedded Software entwickelt werden.
Der Vortrag schließt mit einer Live-Demo eines solchen Testaufbaus.
Art der Vermittlung:
Methodenerklärung, Beispiel und Demonstration
Nutzen:
* Klärung, warum Continuous-Integration für Embedded Systeme anders und schwierig ist
* Konzepte zur Umsetzung von einfachen HIL Sytemen
* Nutzen der Verbindung von Hardware-in-the-Loop Tests und Continuous-Integration
10:35 Uhr
Open-Loop Testing
DIE Testlücke bei Embedded-Firmware?
Details anzeigen
Autor:in:
Daniel Penning | embeff GmbH | Germany
Sprache:
Deutsch
Zielgruppe:
Projektleitung, Entwickler, Tester
Voraussetzungen:
Grundlegendes Verständnis für Embedded Entwicklung
Überblick und Zusammenfassungen:
Der Test von Embedded Firmware ist zu kompliziert. Enorme Ressourcen werden für einen Systemtest aufgewendet, der zu wenige Fehler entdeckt. Für Embedded Firmware ist der korrekte Umgang mit Mikrocontroller Peripherie (GPIO, CAN, ...) essentiell. Dazu werden Treiber programmiert. Open Loop Tests können diese Treiber im Detail prüfen.
Open Loop ist ein Begriff aus der Regelungstechnik. In der Regelungstechnik beeinflusst man einen Prozess so, dass ein gewünschter Zustand erreicht wird. Closed-Loop Regler messen kontinuierlich den Ausgang. Aus der Abweichung zwischen Soll- und Ist-Zustand wird ein Stelleingriff berechnet. Open-Loop Regler steuern „blind“ einen Prozess, sie sind also nicht vom aktuellen Systemzustand abhängig. Das vereinfacht die Handhabung.
Embedded Systeme werden üblicherweise in einer Art getestet, die mit Closed-Loop Reglern vergleichbar ist. Mit Open-Loop Prinzipien kann die Komplexität im Testen dramatisch reduziert werden. Tests werden kompakt und verständlich.
Der Vortrag wird zunächst den Stand der Technik im Testen vom Embedded Systemen beschreiben. Dann wird der Zusammenhang mit Closed-Loop Systemen verdeutlicht. Anschließend wird mit Open-Loop Prinzipien eine alternative Herangehensweise entwickelt.
Art der Vermittlung:
Vortrag mit Entwicklung einer Methode, Beispiele
Nutzen:
Der Autor hält Open-Loop Testing für eine wegweisende Möglichkeit der immer höheren Komplexität von Embedded Firmware mit einer praxisnahen Lösung zu begegnen.
Teilnehmer können den Methodenvorschlag mit Ihrer eigenen Praxiserfahrung abgleichen. Der Denkanstoß stellt Begriffe und Konzepte so vor, dass eine strukturierte Diskussion möglich wird.
11:45 Uhr
Statische Analysewerkzeuge jenseits klassischer Regelprüfung
Wie umgehen mit fehlenden und impräzisen Regeln?
Details anzeigen
Autor:in:
Dr. Sebastian Krings | Axivion GmbH | Germany
Sprache:
Deutsch
Zielgruppe:
Entwickler und Tester, Anwender statischer Analysewerkzeuge
Voraussetzungen:
grundsätzliche Kenntnisse der Softwareentwicklung
Überblick und Zusammenfassungen:
Bei der Entwicklung sicherheitskritischer Systeme werden Werkzeuge zur statischen Codeanalysewerkzeuge verwendet,
um die Compliance des Codes mit vorgegebenen Regelwerken zu überprüfen.
Je nach Einsatzfeld und Kritikalität können dabei Regelwerke wie MISRA, Cert oder Autosar zum Einsatz kommen.
Dabei sind nicht alle vorgegebenen Regeln uneingeschränkt automatisch prüfbar:
So können Regeln beispielsweise 'unentscheidbar', d.h. nur mit eingeschränkter Präzision durch ein Analysewerkzeug prüfbar sein.
Andere Regeln sind möglicherweise sogar als 'manuell' eingestuft, also für eine automatisierte Prüfung generell ungeeignet.
Zuletzt ist die Verfügbarkeit von Regeln durch die eingesetzten Werkzeuge begrenzt.
Im Vortrag argumentieren wir, dass auch in diesen Fällen statische Analysewerkzeuge gewinnbringend eingesetzt werden können.
So ist es abhängig von Projekt und Kontext denkbar, weniger präzise Regeln zu verwenden und dennoch die Ziele eines Regelwerks erreichen.
In anderen Fällen können Analysewerkzeuge manuelle Reviews unterstützen, indem sie kritische Stellen markieren und so ein zielgerichteteres Vorgehen ermöglichen.
Wir zeigen Beispiele und Möglichkeiten wie maßgeschneiderte Regeln verwendet werden können um Lücken in der Prüfbarkeit von Regelwerken zu schließen.
Art der Vermittlung:
Vortrag, Praxisbeispiele
Nutzen:
Die Teilnehmenden
- bekommen einen Überblick über die Prüfbarkeit unterschiedlicher Regeltypen,
- können einschätzen, in wie weit Regeln überhaupt präzise geprüft werden können,
- erfahren, wie statische Analyse im Reviewprozess hilfreich sein kann,
- erfahren, wie maßgeschneiderte Regeln bestehende Regelwerke sinnvoll ergänzen können.