- 289
- 49 058
Richard Seidl
Germany
Приєднався 14 кві 2020
Die Digitalisierung wird nicht kommen - sie ist schon längst da. Und es ist höchste Zeit, dass wir aktive Gestalter dieser Epoche werden. Nur so können wir sicherstellen, dass Technologie ein Werkzeug ist und der Mensch im Fokus bleibt - und nicht umgekehrt.
Mit Technologie UND Menschlichkeit können wir die großen Herausforderungen meistern, eine lebenswerte Zukunft erschaffen und uns weiterentwickeln.
Mit Technologie UND Menschlichkeit können wir die großen Herausforderungen meistern, eine lebenswerte Zukunft erschaffen und uns weiterentwickeln.
Testing Embedded Systems - Alexander Eisenhuth #softwaredevelopment #softwaretesting #embedded
#softwareengineering #testmethoden #testarten #tools
00:00:00 Einführung in Embedded Systems
00:01:27 Qualitätssicherung und Testen von Embedded Systems
00:10:12 Agile Entwicklung und Zusammenarbeit
00:10:36 Einführung und Teamarbeit
00:12:23 Automatisierung und CI-Pipelines
00:15:28 Herausforderungen und Qualitätssicherung
"Bei den funktionalen Sicherungssystemen hast du ja ein regularisches Umfeld. Du musst, wenn du so eine gewisse Zielstufe hast, einfach nach bestimmten Normen entwickeln.” - Alexander Eisenhuth
In dieser Episode tauchen wir tief in die Welt der Embedded Software Entwicklung ein. Wir befassen uns mit den besonderen Herausforderungen beim Testen von Embedded Systemen, die häufig stark mit der Hardware verbunden sind. Dabei wird herausgestellt, dass Qualität und das Einhalten von Standards wie MISRA von entscheidender Bedeutung sind. Zudem wird die Rolle der Agilität in der Embedded-Entwicklung thematisiert und betont, wie wichtig eine gute Kommunikation im Team ist.
Highlights:
* Embedded-Systeme sind spezialisierte Systeme innerhalb anderer Systeme, wie zum Beispiel ABS-Systeme im Auto oder Kaffeemaschinen.
* Die Qualitätssicherung und das Testen sind bei Embedded-Systemen besonders herausfordernd, da sie eng mit der Hardware verbunden sind.
* Es gibt spezielle Codierstandards wie MISRA und statische Codeanalysen, die sicherstellen, dass der Quellcode bestimmten Regeln entspricht.
* Embedded-Systeme haben oft beschränkte Ressourcen, was die Wahl der Programmiersprache und Bibliotheken beeinflusst. C, C++ und Rust sind gängige Sprachen.
* Agilität und kontinuierliche Integration sind auch in der Embedded-Entwicklung wichtig, um eine hohe Qualität sicherzustellen.
Link zur Folge: www.richard-seidl.com/testing-embedded-software
00:00:00 Einführung in Embedded Systems
00:01:27 Qualitätssicherung und Testen von Embedded Systems
00:10:12 Agile Entwicklung und Zusammenarbeit
00:10:36 Einführung und Teamarbeit
00:12:23 Automatisierung und CI-Pipelines
00:15:28 Herausforderungen und Qualitätssicherung
"Bei den funktionalen Sicherungssystemen hast du ja ein regularisches Umfeld. Du musst, wenn du so eine gewisse Zielstufe hast, einfach nach bestimmten Normen entwickeln.” - Alexander Eisenhuth
In dieser Episode tauchen wir tief in die Welt der Embedded Software Entwicklung ein. Wir befassen uns mit den besonderen Herausforderungen beim Testen von Embedded Systemen, die häufig stark mit der Hardware verbunden sind. Dabei wird herausgestellt, dass Qualität und das Einhalten von Standards wie MISRA von entscheidender Bedeutung sind. Zudem wird die Rolle der Agilität in der Embedded-Entwicklung thematisiert und betont, wie wichtig eine gute Kommunikation im Team ist.
Highlights:
* Embedded-Systeme sind spezialisierte Systeme innerhalb anderer Systeme, wie zum Beispiel ABS-Systeme im Auto oder Kaffeemaschinen.
* Die Qualitätssicherung und das Testen sind bei Embedded-Systemen besonders herausfordernd, da sie eng mit der Hardware verbunden sind.
* Es gibt spezielle Codierstandards wie MISRA und statische Codeanalysen, die sicherstellen, dass der Quellcode bestimmten Regeln entspricht.
* Embedded-Systeme haben oft beschränkte Ressourcen, was die Wahl der Programmiersprache und Bibliotheken beeinflusst. C, C++ und Rust sind gängige Sprachen.
* Agilität und kontinuierliche Integration sind auch in der Embedded-Entwicklung wichtig, um eine hohe Qualität sicherzustellen.
Link zur Folge: www.richard-seidl.com/testing-embedded-software
Переглядів: 1
Відео
Testing forms with thousands of variants - Simon Bergler, Lilia Gargouri #softwaretesting #podcast
Переглядів 10416 годин тому
#softwaredeveloper #softwareengineering #testmethoden #tools #infrastruktur 00:00:00 Einführung in das Formulartesten 00:03:01 Herausforderungen beim Testen von Formularvarianten 00:08:02 Lösungsansätze und Automatisierung 00:11:35 Einführung in die Testbibliothek 00:12:22 Trennung von Implementierung und Test 00:20:00 Zukünftige Entwicklungen und Accessibility "Wir hatten einen wahnsinnig hohe...
Cyber Resilience Act (CRA) - Christoph Ranalter #cybersecurity #softwaretesting #softwaredevelopment
Переглядів 12014 днів тому
Cyber Resilience Act (CRA) - Christoph Ranalter #cybersecurity #softwaretesting #softwaredevelopment
Job description of tester - Jörn Münzel, Steffen Schild #softwaretesting #career
Переглядів 12121 день тому
Job description of tester - Jörn Münzel, Steffen Schild #softwaretesting #career
Best practices for (architecture) documentation - Falk Sippach #softwareengineering #architecture
Переглядів 11328 днів тому
Best practices for (architecture) documentation - Falk Sippach #softwareengineering #architecture
Secure by Design - Eoin Woods #softwaretesting #security
Переглядів 93Місяць тому
Secure by Design - Eoin Woods #softwaretesting #security
Software Test Survey 2024 - Karin Vosseberg #softwaretesting #agile
Переглядів 70Місяць тому
Software Test Survey 2024 - Karin Vosseberg #softwaretesting #agile
Testverfahren für das ZDF - Benedikt Broich, Anika Strake
Переглядів 134Місяць тому
Testverfahren für das ZDF - Benedikt Broich, Anika Strake
Quality Coaching - Bastian Baumgartner
Переглядів 77Місяць тому
Quality Coaching - Bastian Baumgartner
How AI can support accessibility - Valentin Dallmeier
Переглядів 852 місяці тому
How AI can support accessibility - Valentin Dallmeier
Systemic methods for collaboration - Vera Hofheinz, Christoph Jung
Переглядів 1262 місяці тому
Systemic methods for collaboration - Vera Hofheinz, Christoph Jung
AI Testing - a Checklist - Marco Achtziger, Gregor Endler
Переглядів 1082 місяці тому
AI Testing - a Checklist - Marco Achtziger, Gregor Endler
What you should know about change in post-agile times - Michael Mahlberg
Переглядів 1292 місяці тому
What you should know about change in post-agile times - Michael Mahlberg
Ask Me Anything about AI, test automation and skills
Переглядів 1442 місяці тому
Ask Me Anything about AI, test automation and skills
Software Engineering in 2034 - Kevlin Henney
Переглядів 2762 місяці тому
Software Engineering in 2034 - Kevlin Henney
Accessibility - Preparing for 2025 - Franziska Kroneck, Andrea Nutsi
Переглядів 683 місяці тому
Accessibility - Preparing for 2025 - Franziska Kroneck, Andrea Nutsi
Praxisnahe Tester-Ausbildung mit KI - Stephan Goericke, Werner Henschelchen
Переглядів 1123 місяці тому
Praxisnahe Tester-Ausbildung mit KI - Stephan Goericke, Werner Henschelchen
Sustainability in IT? Yes, please! - Carlos Fernandez
Переглядів 603 місяці тому
Sustainability in IT? Yes, please! - Carlos Fernandez
Acceptance test-driven LLM development - David Faragó
Переглядів 1103 місяці тому
Acceptance test-driven LLM development - David Faragó
ISTQB in practice at Bucher + Suter - Alexander Meister
Переглядів 1833 місяці тому
ISTQB in practice at Bucher Suter - Alexander Meister
Transition to open source test automation - Nikolaus Rieder
Переглядів 1344 місяці тому
Transition to open source test automation - Nikolaus Rieder
Stoicism in Software Development - Maryse Meinen
Переглядів 1144 місяці тому
Stoicism in Software Development - Maryse Meinen
Test pyramid - a critical look - Ronald Brill
Переглядів 4504 місяці тому
Test pyramid - a critical look - Ronald Brill
Quality from an architectural perspective - Alexander Lorz, Michael Sperber
Переглядів 1714 місяці тому
Quality from an architectural perspective - Alexander Lorz, Michael Sperber
Minimum Viable Test Strategy - Kathrin Potzahr
Переглядів 2415 місяців тому
Minimum Viable Test Strategy - Kathrin Potzahr
Planet Earth as a stakeholder - Jutta Eckstein
Переглядів 935 місяців тому
Planet Earth as a stakeholder - Jutta Eckstein
German Testing Day - Klaus Moritzen, Thomas Rinke
Переглядів 965 місяців тому
German Testing Day - Klaus Moritzen, Thomas Rinke
Welche Erfahrungen hast du mit der Entwicklung oder dem Testen von Embedded Systemen gemacht?
Buzzword Bingo, hm ?
Hast du schon einmal ähnliche Herausforderungen wie Lilia und Simon erlebt? Wenn ja, wie hast du sie gelöst?
Was denkst du über den Cyber Resilience Act?
Welche Skills haltet ihr für besonders wichtig, um in einem agilen Testteam erfolgreich zu sein, und warum?
Was hältst du von der Idee der Continuous Documentation?
Welche große Herausforderung siehst Du beim Theman „Security by Design“?
Wie steht ihr zu der Aussage, dass agile Methoden die traditionellen Projektmanagement-Ansätze im Software-Testing verdrängen? Habt ihr ähnliche Erfahrungen gemacht?
Welche Herausforderungen hast du in deinen eigenen Projekten bei der Testautomatisierung erlebt?
Wie gehst du mit dem Widerstand gegen Veränderungen im Team um?
Wie gehst du mit dem Spannungsfeld zwischen Sicherheit und Komfort in deiner Softwareentwicklung um?
Hast du Erfahrungen mit der Herausforderung, eine Webseite barrierefrei zu gestalten?
Welche Erfahrungen hast Du mit systemischen Methoden in deinem Team gemacht?
Welche Rolle spielen KI-Systeme in deiner täglichen Arbeit?
Welche Erfahrungen hast du mit agilen Transformationen gemacht?
Was sind deiner Meinung nach die größten Herausforderungen im Bereich Software-Testing heutzutage?
Was denkst du, was sich in deinem Arbeitsalltag in den nächsten 10 Jahren verändern wird?
Wie bereitet ihr euch auf die neuen Anforderungen ab 2025 vor?
Welche Möglichkeiten siehst Du noch für den Einsatz von KI in der Weiterbildung?
Welche Möglichkeiten siehst Du noch für den Einsatz von KI in der Weiterbildung?
Wie könntest du in deinem beruflichen oder persönlichen Umfeld für mehr Nachhaltigkeit sorgen?
Wie könntest du in deinem beruflichen oder persönlichen Umfeld für mehr Nachhaltigkeit sorgen?
Welche Möglichkeiten siehst Du noch für den Einsatz von KI in der Weiterbildung?
Welche Möglichkeiten siehst Du noch für den Einsatz von KI in der Weiterbildung?
Den Ton solltet ihr nicht von eurem Meetingtool verwenden. Besser ist, wenn jeder seinen Ton bei sich zB mit dem Handy aufnimmt. Diese Tonspuren legst Du dann unter das Video. Voraussetzung ist, dass alle Teilnehmer den Meetington über ein Headset hören, damit dieser nicht in die lokalen Handies gelangt. Ihr werdet so mit dem besten Ton belohnt, den ihr erreichen könnt. Cheers!
Wie könntest du in deinem beruflichen oder persönlichen Umfeld für mehr Nachhaltigkeit sorgen?
Wie könntest du in deinem beruflichen oder persönlichen Umfeld für mehr Nachhaltigkeit sorgen?
Danke für den Podcast! Die Publikationen von Sneed haben mich 2011-2014 sehr geprägt und beeinflusst, insbesondere die Vermessung von Software. Habe mich sehr gefreut, Harry jetzt nochmal in Farbe und Bewegtbild zu sehen! Lieben Gruß an ihn und danke für das Lebenswerk
Danke für das Feedback. Ja, Harry ist ein sehr besonderer Mensch! Ich plane gerade noch weitere Folgen mit ihm, er hat ja viele Geschichten zu erzählen
Welche Erfahrungen hast du mit der Implementierung oder dem Testen von KI-Systemen?
Ich würde so nicht wirklich „pauschalisieren „.. Testpyramide ist eine visuelle Metapher zu einer effizienten Gestaltung der Teststufen.. insbesondere in einem agilen Umfeld wie Scrum. Sie gibt eine sinnvolle Richtung für die Software-Qualitätssicherung vor. Daher würde ich sie nicht so einfach „weg lächeln “:) Microservises-Architektur hat selber kein einheitliches Kochrezept sondern sind Dinge im Kontext zu betrachten. Integrationstests feingranular betrachtet sind Tests der Komponenten auf Unittest-Ebene. Testpyramide ist übrigens ISTQB-konform und daher standard. .
Ich würde so nicht wirklich „pauschalisieren „.. Testpyramide ist eine visuelle Metapher zu einer effizienten Gestaltung der Teststufen.. insbesondere in einem agilen Umfeld wie Scrum. Sie gibt eine sinnvolle Richtung für die Software-Qualitätssicherung vor. Daher würde ich sie nicht so einfach „weg lächeln “:) Microservises-Architektur hat selber kein einheitliches Kochrezept sondern sind Dinge im Kontext zu betrachten. Integrationstests feingranular betrachtet sind Tests der Komponenten auf Unittest-Ebene. Testpyramide ist übrigens ISTQB-konform und daher standard. .
Was hältst Du von den ISTQB Zertifizierungen?
stimme dem Alexander zu, der Basiskurs liefert nen guten Überblick über die verschiedenen Themenbereiche von Softwaretesting und eine vereinheitlichte Nomenklatur, die Kommunikation unter Testern erleichtert. Advanced Levels hab ich selber noch keine gemacht.
Welche Herausforderungen hast Du bei der Testautomatisierung?
schreibt jemand heute überhaupt noch unit-tests selbst? ich lasse die von chatgpt oder gemini auf basis des codes der zu testenden methode - oder sogar nur auf basis der spezifikation - erzeugen, prüfe den test einmal und lasse ggf. weitere input-daten von der ai generieren. damit geht TDD so schnell. und wenn ich refactoren muss, mach ich dasselbe nochmal aber eben auf basis des neuen codes. die sicht auf diese hybriden tests teile ich. eine kombination aus integrations- und unit-tests in einem, z.t. ähnlich wie die von @caelis512 beschriebenen simulatoren, ist in einigen fällen bislang der effektivste weg gewesen, das verhalten des codes zu testen. kennt jemand dafür vllt einen fachbegriff?
Interessante Anregungen zu diesem Thema. Damit kann man prima in eine Diskussion einsteigen. Eventuell stelle ich das mal meinem Team vor.
Vielen Dank für den Podcast, tolles Video! Meinen Senf dazu: Was aus meiner Sicht ein pragmatischer Ansatz ist - und in den letzten Jahren bei “meinen” Projekten gut funktioniert hat … (Projekte sind meist kleine bis mittelgrosse Projekte, Hauptsächlich CRUD mit ein wenig Geschäftslogik, klassisch Client (Web) / Server (meist Spring) … ne DB und 1 bis 4 externe Systeme, ein Team von 3-6 Personen, nix Microservices, sondern Monolith oder modularer Monolith): Tests greifen so gut wie immer (und einzig) auf das “Public-API” zu. Pragmatisch umgesetzt bedeutet dies, das wir die Controller (HTTP-API) meist dumm gehalten haben (zu 80% sind die Methoden im Controller ein Einzeiler, die führen lediglich einen Call auf public Service durch). Die Tests verwenden somit dieselben Service-Methoden, welche auch vom Controller verwendet werden (nenne die “Public-API”). Alternativ denkbar ist, direkt das HTTP-API aufzurufen (ist etwas umständlicher; aber da der Controller dumm gehalten wird; ist es meist vertretbar die Service-Methoden zu verwenden). Frontend wird versucht (sofern Anforderungen das zulassen) so dumm wie möglich zu halten … Validierungen finden zu 95% rein im Backend statt (sind somit einfach mit-testbar). Externe Systeme werden beim Testen durch “Simulatoren” ersetzt. Diese sollten sich ähnlich wie das richtige System verhalten (werden bei der Testerstellung schrittweise erweitert / verfeinert; je nachdem was ich im Test benötige). Diese Simulatoren lassen sich währen der Testausführung manipulieren (z.B. mit Daten befüllen). Daten halten diese einfach In-Memory (z.b. in HashMaps). Die Simulatoren setzen möglichst spät an, üblicherweise direkt dort, wo das richtige externe-System per HTTP (oder gRPC, …) aufgerufen wird (Umgesetzt per Spring DI; haben dann 2 Implementierungen: Die eine ruft das externe System per HTTP auf, die andere Implementierung ist der Simulator). Für die Testausführung wird dann ne H2-DB verwendet (per Default). Bei der Test-Ausführung in der Pipeline kann die H2 mittels Testcontainers auch durch PostgreSQL/SQL-Server/… ersetzt werden. Beim Test-Setup (Daten für den Test vorbereiten) benutzen wir ebenfalls (zu 95%) nur das Public-API und die das API der Simulatoren (externe Systeme). Also manipulieren nichts direkt an der DB, sondern verwenden dieselben Funktionen, die auch ein Benutzer verwenden würde, wenn dieser nene Geschäftsfall anlegt (sind somit auch gleich mit-getestet). Tests testen die Spezifikation (wenig interne Details). Reine Unit-Tests verwenden wir eher wenig, lediglich in Spezialfällen aus Performance-Gründen; beispielsweise um eine eine komplexe Gebührenberechnungs-Funktion (Geld!, schlecht wenn das was falsch berechnet wird) mit allen Edge-Cases zu testen. Wir haben somit vielleicht zu 85% Integrationstests, 15% Unit-Tests. Da hauptsächlich das Public-API in Tests verwendet wird, sind die Tests auch relativ robust gegen internes Refactoring. Schöner Nebeneffekt mit den Simulatoren ist: Ich muss nicht warten, bis das externe System fertig entwickelt worden ist. Ich bin nicht betroffen von Ausfällen des externen Systems (kann passieren, falls sich das noch ein Entwicklung befindet). Und: Mit den Simulatoren und der H2-DB hab ich ein (falls ich das will; kann optional echte DB und echte externe Systeme einbinden) ein komplett eigenständiges Backend. Git-Checkout und starten… ich muss keine DB einrichten, kein Docker, brauche keine Verbindung zu den externen Systemen… könnte auf einer einsamen Insel offline entwickeln.
Vielleicht noch Nachtrag, wie das (angenommen Spring/Java) konkret umgesetzt aussieht: Angenommen mein Projekt heisst “myproject”: Maven-Modul “myproject”: * Hier befindet sich der eigentliche Code. * Echte Anbindung an die Produktiv-Systeme (HTTP/gRPC/SOAP-Aufrufe). * Die 15% Unit-Tests. * Application-Properties konfiguriert für die Produktion. * Das Modul wird in Produktion aufgeliefert. Maven-Modul “myproject-dev”: * Dieses Modul wird *nicht* in Produktion ausgeliefert. * Hat ne Dependency auf “myproject”. * Hier befinden sich die Simulatoren. * Application-Properties, welche die Prod-Services (für Externe-Systeme) durch die Simulatoren ersetzt und H2 Konfiguriert. * Hier befinden sich die 85%-Integrations-Tests (Grund: Benötigen die Simulatoren). * Kann auch verwendet werden um das Backend ohne externe Dependencies zu starten (ohne DB-Setup oder Verbindung zu externen Systemen). … ist ne Vereinfachung und andere Setups sind denkbar.
Danke für die Insights! Sehr spannend! 🖖🏻
Moin, schon Mal über Wiremock nachgedacht? So könntest Du dir die zweite Impl. sparen und die erste wird schon früher in den Tests ausgeführt - nicht erst auf dev/prod. Viele Grüße
Genau mein Humor: im RSS geht der Link zur Verlosung nicht und hier und auf Spotify sehe ich ihn erst nicht 🙂
Es muss halt auch mal ordentlich getestet werden :-) Hier der Link, ich hab ihn im Text ergänzt: swt.fm/saw8
@@richard-seidlJetzt klappt's. Wird akzeptiert. 😉
ehm...what? was für eine gequirlte kacke im strahl....von was redet die da?
Interessant! Gibt es schon Ansätze von Testroutinen KI-Ergebnisse selbst zu überprüfen?
Da würde ich mal direkt mit den Kollegen Runze und Röttger Kontakt aufnehmen: ua-cam.com/video/TIZIaOJ2l5c/v-deo.html
Thanks for the video Richard, hail from Brazil!
My pleasure!
spannender Perspektivwechsel von Testen mit KI zu Testen von KI. Wahnsinn, welche thematische Bandbreite dieser Podcast innerhalb des großen Themas Software bietet.
Danke für das Feedback 🤩
Sehr informative Videos! Ich lerne sehr viel dazu als Software Testerin👏🏻 Danke Richard Seidl!
Danke für das Feedback! Das freut mich sehr - viel Spaß und viel Inspiration weiterhin
cool sehr interessant. Danke dir
Danke fürs Feedback!
"Thorsten heißt der, kommt aus Hessen" - in dem Sinne "Guude!" 👋😊. (ua-cam.com/video/_RxTJfjcGYk/v-deo.html) Sehr angenehmes und gut verständliches Gespräch. Vielen Dank auch für den Hinweis auf mein "Thorsten-Voice" Projekt.
Vielen Dank Mariusz und Richard!