Qualität als Teamaufgabe: Einblicke in den Engineering- und Onboarding-Alltag bei CADS GmbH

Was wir aus „Lukas Windner, Division Manager Quality Engineering bei CADS“ mitgenommen haben

In der Session „Lukas Windner, Division Manager Quality Engineering bei CADS“ (Speaker: Lukas Windner, Company: CADS GmbH) bekamen wir einen selten klaren Blick auf die Strukturen, Rituale und Technologien eines Unternehmens, das Software für den Medizinproduktsektor baut und Qualität nicht als Endkontrolle, sondern als Teamaufgabe versteht. Der Standort: Perg. Der Kontext: ein Unternehmen, das zu einer Gruppe gehört und entsprechend breit aufgestellt ist – mit Entwicklung, Research, Prototyping, Marketing, HR und Geschäftsführung unter einem Dach.

Der Fokus der Einblicke lag auf dem Bereich Softwarequalität und dessen Verzahnung mit Entwicklung und Projektleitung. Unser Eindruck: Bei CADS wird Engineering-Kultur greifbar – in der Art, wie Rollen definiert sind, wie Teams zusammenarbeiten, wie Onboarding abläuft und wie pragmatisch mit Technologien, Cloud und KI umgegangen wird. Es sind genau diese Details, die Tech-Talente wissen wollen, bevor sie sich auf einen Job bewerben.

Auftrag und Umfeld: Software für den Medizinproduktsektor

CADS GmbH entwickelt Software im Medizinproduktumfeld – ein Feld, in dem Sorgfalt, Dokumentation und Risikoanalysen nicht verhandelbar sind. Dass Qualität hier strukturell verankert ist, überrascht nicht. Spannend ist eher, wie CADS das organisatorisch löst:

• Qualitätsverantwortung ist eine eigene Abteilung.
• Entwicklungsteams (Junior und Senior) bauen primär Web-Anwendungen; es gibt zudem Arbeiten in Augmented Reality (AR) und auch im KI-Bereich, verortet in der Research-Abteilung.
• Prototypenentwicklung, Marketing, HR und Geschäftsführung sind eng angebunden.

Der Mix aus reguliertem Umfeld und moderner Web-/Cloud-Orientierung setzt Rahmenbedingungen, die für viele Entwicklerinnen und Entwickler attraktiv sind: klare Prozesse, nachvollziehbare Qualitätsziele und gleichzeitig moderne Toolchains.

Die Struktur im Softwarequalität-Engineering

Lukas Windner führt die Abteilung Softwarequalität Engineering. Die Rollen sind klar getrennt – und doch eng verzahnt.

Die Kernrollen: Project Quality vs. Softwarequality

• Project Quality Software Engineer (PQE)
• Verantwortlich für Dokumentation und Risikoanalyse.
• Koordiniert die Arbeit der Softwarequality Engineers.
• Wird von Lukas als „linke und rechte Hand“ des Projektleiters beschrieben – nahe an Planung, Entscheidungen und Projektsteuerung.
• Softwarequality Engineer (SQE)
• Führt Tests durch: manuell, automatisiert, Security, Last.
• Bringt sein Erfahrungsprofil ein – je nach Seniorität und Vorerfahrung.

Die Zusammenarbeit ist praktisch organisiert: PQE und SQE arbeiten eng zusammen; der PQE hält die Fäden in Richtung Projektleitung und dokumentiert, der SQE bringt die Testtiefe und -breite ein.

Cross-Support statt Silos

Windner betont, dass sich Kolleginnen und Kollegen gegenseitig unterstützen – auch projektübergreifend. Wer Security-Testing-Erfahrung hat, hilft anderen Projekten aus. Rollen sind nicht starr: Je nach Bedarf ist man auch einmal als SQE oder PQE unterwegs. Das hebt zwei Kulturmerkmale hervor:

• Wissensaustausch ist gewollt und wird gelebt.
• Verantwortlichkeiten sind klar – aber nicht rigide. Kompetenz schlägt Organigramm, wenn es dem Projekt dient.

Engineering-nahe Qualität

Qualität ist bei CADS kein nachgelagerter Kontrollpunkt, sondern technisch eingebettet. Das zeigt sich an Tooling und Technologien (dazu mehr weiter unten) und daran, dass das Qualitätsteam eigene Skripte und Automatisierungen pflegt. Das Qualitätsmanagement ist damit spürbar „hands-on“.

Entwicklung, Research und mehr: Wie CADS aufgebaut ist

Neben dem Softwarequalität-Engineering gibt es Entwicklungszimmer mit Junior- und Senior-Developern, die „voll viel Web-Anwendungen“ bauen. Forschungsthemen wie AR und KI sind in der Research-Abteilung verankert – dort, wo „Stand der Technik“ erprobt und gezielt eingesetzt wird. Außerdem gehören Marketing, Prototyping, HR und die Geschäftsführung zur Struktur, die Lukas skizziert.

Der Gesamtaufbau signalisiert: Qualität entsteht nicht isoliert, sondern im Zusammenspiel aus Entwicklung, Research, Produkt und operativer Abwicklung – und wird von HR- und Management-Prozessen getragen, die das Onboarding und die tägliche Zusammenarbeit stützen.

Recruiting, Auswahl und Onboarding: Der Prozess im Detail

Was Tech-Talente selten so offen hören: Wie konkret läuft ein Bewerbungsprozess ab, wer sitzt wann am Tisch und was passiert nach Vertragsunterschrift? Bei CADS ist der Ablauf klar beschrieben – mit starker Einbindung der Fachabteilung.

Stellenausschreibung: HR und Fachseite arbeiten zusammen

• Head of Quality, Abteilungsleitung und HR definieren gemeinsam die Ausschreibung.
• Nach dem Review wird die Stelle publiziert.

Diese frühe Einbindung der Fachabteilung sorgt dafür, dass Profile realistisch beschrieben sind und Erwartungsmanagement von Anfang an passt.

Erstgespräch: virtuell und fachnah

• Nach Bewerbungseingang gibt es in der Regel ein erstes virtuelles Gespräch.
• Dieses führt in den meisten Fällen Lukas Windner selbst.
• Inhalte: gegenseitiges Kennenlernen, Vorstellung der Produkte, Rückblick auf bisherige Erfahrungen der Bewerberin oder des Bewerbers.

Das bedeutet für Kandidat:innen: Von Anfang an sprechen Sie mit der späteren Führungskraft – ohne Flaschenhals oder Verzögerungen.

Vor-Ort-Gespräch in Perg – meist mit COO

• Im nächsten Schritt folgt ein Vor-Ort-Termin am Standort Perg.
• Dabei ist „meistens auch der COO dabei“ – so lernt die Führungsebene die Kandidat:innen kennen und umgekehrt.

Im Anschluss wird bilateral und intern abgestimmt. Kommt es zu einem positiven Ergebnis, folgt der Vertragsabschluss und die Startplanung.

Patenprogramm: Drei Monate strukturierte Begleitung

Mit Arbeitsbeginn startet ein dokumentierter Onboarding-Prozess mit Patenprogramm:

• Für die ersten drei Monate wird ein Pate oder eine Patin zugeordnet.
• Der Pate nimmt vom ersten Tag an an die Hand: Empfang, Arbeitsplatz, Einloggen, benötigte Software installieren, Orientierung im Büro („Wo ist die Küche?“) und Einführung in den Arbeitsalltag.
• Frühzeitige Projektintegration: Der Pate nimmt neue Kolleg:innen direkt in Meetings mit, stellt Teammitglieder vor und verknüpft mit Stakeholdern.
• Online-Meetings sind häufig, weil CADS mit Kund:innen aus den USA und aus Deutschland zusammenarbeitet.

Das Entscheidende ist die Zugänglichkeit: „Da ist man bestens umgeben, den kann man immer fragen.“

Offene Kultur: Alle Türen, inklusive Geschäftsführung

Lukas beschreibt CADS mehrfach als „sehr offene Firma“:

• Fragen sind explizit erwünscht – „man kann wirklich jetzt auch beim Geschäftsführer reingehen“.
• Es wird nicht „zum nächsten“ verwiesen; man bemüht sich aktiv um Antworten.
• Auch scheinbar banale Themen („Wie stelle ich einen Urlaubsantrag?“) dürfen gestellt werden, ohne Hemmschwelle.

Für neue Teammitglieder reduziert das Reibung und Unsicherheit. Für die Organisation bedeutet es: Führung ist präsent und zugänglich, nicht nur auf dem Organigramm.

Wachstum und Reife: Vom Einzelkämpfer zur sechsköpfigen Qualitätseinheit

Lukas ist seit rund viereinhalb Jahren bei CADS. Bei seinem Start war er „alleine im Qualitätsbereich“. Heute ist das Team sechs Personen stark. Diese Entwicklung zeigt zwei Dinge:

• Qualität wird nicht nur rhetorisch priorisiert – sie wächst mit dem Produkt- und Projektportfolio.
• Wissensaufbau und Verantwortungsübergabe funktionieren: Aus einem Einzelnen wurde ein Team mit klaren Rollen und geteiltem Know-how.

Für Bewerber:innen ist das ein Indikator für eine lernende Organisation, die Strukturen anpasst, wenn das Arbeitsvolumen steigt.

Tooling und Tech-Stack: Pragmatismus mit Cloud-Fokus

Die genannten Tools und Plattformen zeichnen ein Bild einer modernen, entwicklungsnahen Qualitätssicherung:

• Planung und Kollaboration: Jira, „die komplette Atlassian Suite“.
• Code, Builds und Automatisierung: „Asha DevOps“ kommt in der Entwicklung und im Qualitätsmanagement zum Einsatz – besonders relevant für automatisierte Tests, die Source Code und Skripte benötigen.
• Hosting und Infrastruktur: Kein eigenes Rechenzentrum; Web-Anwendungen laufen auf AWS.
• Genutzte AWS-Services: S3, EC2-Instanzen, SNS und SQS. Insgesamt setzt CADS „relativ viel“ auf Services, um Build- und Betriebsaufgaben abzudecken.

Testautomatisierung und Testarten

• Automatisierte Tests: C#/.NET in Verbindung mit Selenium.
• Mobile Tests: Java und ein Framework „ähnlich wie Selenium“, das im Gespräch als „Abium“ genannt wird – für mobile Anwendungen.
• Lasttests: Es werden Tools für Last- bzw. „Load-Testing“ eingesetzt.
• Security-Tests: Orientierung am OWASP Testing Guide; als Tool wird die Burp Suite genutzt.

Wichtig ist der Engineering-Ansatz der Qualitätssicherung: Das QS-Team schreibt selbst Skripte, integriert sich in Build-Pipelines und arbeitet mit denselben Plattformen wie die Entwicklung. Wer als Quality Engineer arbeitet, ist damit ganz selbstverständlich Software Engineer.

Künstliche Intelligenz und AR: Gezielt statt „mit Gewalt“

KI ist für CADS Thema – sowohl in der Research-Abteilung als auch mit Blick auf künftige Unterstützung im Qualitätsmanagement, etwa um Fehler frühzeitig zu erkennen. Doch der Tenor im Gespräch ist bewusst nüchtern:

Stattdessen wird geprüft, wo der Einsatz „zielführend“ ist. Für das Qualitätsteam bedeutet das: KI wird dort eingesetzt, wo sie tatsächlich Mehrwert stiftet – nicht als Selbstzweck. Diese Haltung passt zum Gesamtbild einer Organisation, die Technologie pragmatisch auswählt und in bestehende Prozesse integriert.

Zusammenarbeit im Alltag: International vernetzt, intern nahbar

Der Alltag ist durch zwei Konstanten geprägt:

• Regelmäßige Online-Meetings – Kund:innen sitzen in den USA und in Deutschland.
• Intern kurze Wege – fachliche Fragen können direkt und ohne Formalien adressiert werden.

Dass Projektrollen flexibel unterstützt werden und Kolleg:innen mit Spezialwissen auch in anderen Projekten aushelfen, stärkt die kollektive Problemlösung. Für Tech-Talente heißt das: Wer gerne Verantwortung übernimmt und Wissen teilt, findet hier die passende Umgebung.

Was erwartet CADS von neuen Kolleg:innen? (abgeleitet aus dem Gespräch)

Auch wenn Lukas keine formalen Anforderungskataloge vorliest, lässt sich aus seinen Schilderungen ableiten, welche Eigenschaften zählen:

• Bereitschaft, Verantwortung zu übernehmen – ob als PQE nahe an der Projektleitung oder als SQE tief in Tests und Automatisierung.
• Freude an Zusammenarbeit und Wissensaustausch – projektübergreifendes Aushelfen ist normal.
• Technische Neugier und Pragmatismus – moderne Toolchains einsetzen, aber zielorientiert statt um des Buzzwords willen.
• Kommunikationsstärke – intern offen fragen, extern in Online-Meetings klar auftreten.

Für Quality-Engineering-Rollen ergänzt sich das um solide Test- und Automatisierungskompetenz (Selenium, Skripting in C#/.NET, Java im Mobile-Kontext), Security-Verständnis (OWASP, Burp Suite) und ein gutes Gespür für Dokumentation und Risikobetrachtung.

Gründe, warum Tech-Talente CADS spannend finden könnten

• Mission mit Wirkung: Software für den Medizinproduktsektor verlangt Sorgfalt, Tiefe und Sinn für Verantwortung.
• Klare Rollen, echte Nähe zum Produkt: PQE und SQE arbeiten Hand in Hand und eng mit der Projektleitung.
• Engineering-first-Qualität: Automatisierte Tests, Build-Integration, AWS-Services – Qualität ist Teil der Delivery.
• Starkes Onboarding: Patenprogramm über drei Monate, strukturierte Begleitung vom ersten Tag an.
• Offene Kultur: Zugänglichkeit aller Ebenen, kurze Wege, kein „Ping-Pong“ bei Fragen.
• Moderne Cloud-Landschaft: AWS mit S3, EC2, SNS, SQS; Atlassian; „Asha DevOps“; Selenium; Burp Suite.
• Breite Themen: Web-Anwendungen, AR, KI in der Research – genug Stoff für Lernkurven.
• Internationaler Kontext: Zusammenarbeit mit Kund:innen aus den USA und Deutschland.

Zitate und Formulierungen, die hängen bleiben

Diese Aussagen verdichten die Kultur: Verantwortungsnah, kollaborativ, pragmatisch.

Fazit: Qualität, die mitwächst – und ein Umfeld, das trägt

Die Session „Lukas Windner, Division Manager Quality Engineering bei CADS“ macht deutlich, wie CADS Qualität in die Produktentwicklung einbettet: mit klaren Rollen, teamübergreifender Unterstützung, einem geerdeten Technologieeinsatz und einem Onboarding, das wirklich begleitet. Die Abteilung ist in wenigen Jahren von einer Einzelrolle auf sechs Personen gewachsen – ein Zeichen, dass Qualität mit dem Projektgeschäft skaliert und nicht am Ende „draufgesetzt“ wird.

Für Entwickler:innen, Testautomatisierer:innen und Quality Engineers, die Verantwortung übernehmen wollen und gerne interdisziplinär arbeiten, ist dieses Setup attraktiv. Wer sich fragt, ob sich ein Wechsel lohnt, bekommt hier Antworten, die zählen: ein klarer Prozess vom Erstkontakt bis zur Einarbeitung, offene Türen bis zur Geschäftsführung und eine Toolchain, die moderne Softwareentwicklung ermöglicht.

Wer in Perg ein Umfeld sucht, in dem Qualität kein Schlagwort ist, sondern gelebter Prozess – die Einblicke von Lukas Windner zeigen, wie das bei der CADS GmbH konkret aussieht.

• 

  

  Building Products with Purpose

  Lukas Reinauer von CADS spricht in seinem devjobs.at TechTalk wie das Unternehmen das Thema der Produktentwicklung organisatorisch angeht.

  Jetzt ansehen
• 

  

  From Figma to Implementation

  Julian Zauner von CADS zeigt in seinem devjobs.at TechTalk welche Überlegungen hinter den grundlegenden Design Elementen in der Software stecken.

  Jetzt ansehen

• 

  

  Dominic Koch, Product Manager bei CADS

  Product Manager bei CADS Dominic Koch erzählt im Interview über die Abläufe im Unternehmen, was Neueinsteiger erwartet und mit welchen Technologien gearbeitet wird.

  Jetzt ansehen

• 

  

  Claudia Wittner, Researcher bei CADS

  Claudia Wittner von CADS redet in ihrem Interview über die ersten Berührungspunkte mit dem Programmieren bis hin zur aktuellen Arbeit, wie ihr Alltag als Researcher aussieht und gibt Tipps für Anfänger.

  Jetzt ansehen
• 

  

  Katharina Freinschlag, 3D Software Entwicklerin bei CADS

  Katharina Freinschlag von CADS spricht im Interview über ihren Weg zur Software Entwicklung, welche Challenges im 3D Development gibt und was ihrer Meinung nach Wichtig für Beginner ist.

  Jetzt ansehen