Die Anatomie eines modernen Softwareentwicklungsteams - Rollen, Verantwortlichkeiten, Struktur, Methoden und Kultur

Das "Team" als ein Kollektiv, das mehr repräsentiert als das Zusammenspiel seiner Teilmitglieder, ist heute die Grundlage eines jeden erfolgreichen Softwareentwicklungsprozesses.

IT Outsourcing • UPDATED ON März 18, 2022

John Adam

Author

In diesem Blog befassen wir uns mit der historischen Entwicklung des modernen agilen Softwareentwicklungsteams als echtes Kollektiv, das seine individuellen Mitglieder überragt, sowie mit der Aufschlüsselung vieler der Rollen, woraus dieses Team besteht.

Ob Mobil- und Webanwendungen oder Embedded Software, die unsere Autos und Staubsaugerroboter benötigen, um zu funktionieren – die Welt von heute läuft mit Software. Die überwiegende Mehrheit dieser Millionen von Softwareprogrammen werden nicht von einzelnen Programmierern, sondern vielmehr von einem Software-Entwicklungsteam erstellt, das sich aus einer Vielzahl unterschiedlicher Rollen, Technologie-Stacks und Kompetenzen (Hard- und Soft Skills) zusammensetzt.

Der Bau eines Gebäudes erfordert ein Team mit unterschiedlichen Kompetenzen und Fähigkeiten. Ein Architekt, ein Bauingenieur, ein Vorarbeiter, Bauarbeiter mit verschiedenen Fähigkeiten, Elektriker, Klempner, Innenarchitekten und Dekorateure usw.

Es gibt viele Parallelen zur modernen Softwareentwicklung. Softwaresysteme und -produkte haben sich im Laufe der Jahre in ihrer Komplexität und Ausgereiftheit weiterentwickelt. Das Aufkommen des Cloud Computing war dabei ein wichtiger Wendepunkt. Parallel dazu haben sich auch die von den Software-Entwicklungsteams eingesetzten Technologien, Methoden und Frameworks für deren effektives Management weiterentwickelt.

Ein durchschnittliches Softwaresystem besteht aus einer Kombination von Front-End-, Back-End-, Test-Tools, Betriebs-Tools und -Technologien sowie UI- und UX-Fachwissen bzw. -Design. Daher müssen die Mitglieder eines Softwareentwicklungsteams, das mit der Erstellung eines Softwaresystems betraut ist, über Erfahrung und Kompetenz in diesem vielfältigen Spektrum von Tools und Technologien verfügen.

Jedes Teammitglied muss außerdem bereit und in der Lage sein, die – in der Regel agile – Methodik oder das Framework, das für die beste Organisation und Förderung der Arbeit ausgewählt wurde, zu übernehmen und effektiv zu nutzen. Und sie müssen das Gleichgewicht zwischen Qualität und Geschwindigkeit wahren und gleichzeitig die Erwartungen an beides übertreffen.

Die Bedeutung der Methodik für ein modernes Softwareentwicklungsteam

Die allgemeine Einführung agiler Softwareentwicklungsmethoden und -rahmen in den letzten zwanzig Jahren hat einen neuen Schwerpunkt auf das Softwareentwicklungsteam gelegt.  Die Kultur und die Praktiken des Teams, die durch den agilen Ansatz vorgeschrieben werden, sind darauf ausgerichtet, die Beziehungen zwischen den Teams zu festigen und gleichzeitig die einzelnen Mitglieder durch Verantwortung und Rechenschaftspflicht zu stärken.

Das Softwareentwicklungsteam ist nicht mehr eine Ansammlung von Einzelpersonen, die jeweils die ihnen zugewiesenen Teile eines Softwaresystems ausführen, bevor sie diese an den Projektmanager oder das Testteam übergeben und dann wieder gehen. Das Team, und nicht nur der Projektmanager oder der technische Leiter, ist kollektiv für die Qualität des Ergebnisses verantwortlich, und von jedem Mitglied wird erwartet, dass es persönliche Verantwortung für dieses Teamziel übernimmt.

Agile und DevOps-Methoden haben das Softwareentwicklungsteam in den Mittelpunkt gerückt. Ihre Prinzipien und Praktiken sollen dazu beitragen, dass ein Team mehr ist als die Summe seiner Teile. Wie ein gut trainiertes und motiviertes Sportteam, das mehr erreicht als seine weniger gut organisierten Konkurrenten, selbst wenn diese über beeindruckendere Einzelspieler verfügen.

Die Entwicklung von agilen und DevOps-Softwareenetwicklungsteams

Design-Thinking-Systeme sind seit den 1940er Jahren maßgeblich an den Versuchen beteiligt, die Effizienz von Produktionsprozessen und die Qualität ihrer Ergebnisse zu verbessern. Diese Systeme, wie der Toyota-Weg oder die Lean-Methode, wie sie besser bekannt wurde, wurden zunächst in der Fertigung eingesetzt, begannen aber auch, Softwareentwicklungsprozesse zu beeinflussen, als die digitale Transformation in den 1990er Jahren ernsthaft einsetzte.

In den 1980er Jahren wurden mehrere einflussreiche Bücher und Abhandlungen veröffentlicht, in denen iterative und nicht lineare Ansätze für die Softwareentwicklung befürwortet und skizziert wurden. Diese wurden zu den verschiedenen Frameworks, die unter dem Begriff „Agile Softwareentwicklung“ zusammengefasst, oder beeinflussten diese. Sie befassten sich mit dem wachsenden Problem, dass immer größere und komplexere Softwareentwicklungsprojekte so viel Zeit in Anspruch nahmen, dass sie zum Zeitpunkt ihrer Veröffentlichung bereits veraltet waren.

Die Softwaresysteme, die noch ihren Zweck erfüllten, wiesen oft gravierende Mängel in Bezug auf Benutzerfreundlichkeit und Funktionalität auf. Ihre Größe machte ihre Konzeption und Entwicklung zu einem schwerfälligen, schwer zu koordinierenden Prozess, worunter die Qualität litt.

Damals wurden die meisten Softwaresysteme, ob groß oder klein, komplex oder einfach, nach dem linearen Wasserfallmodell entwickelt. Jede Phase, von der Festlegung der Anforderungen über den Entwurf, die Entwicklung, das Testen und die Freigabe, wurde nacheinander mit nur geringen Überschneidungen abgeschlossen.

Ein umfangreiches, sehr komplexes Softwaresystem, z. B. für das Militär oder für Regierungsstellen, Krankenhäuser usw., würde zu Beginn des Softwareentwicklungszyklus in seiner Gesamtheit und bis ins kleinste Detail entworfen werden.

Softwareentwickler würden daraufhin den Code zur Umsetzung der detaillierten Spezifikation erstellen. Jeder war in erster Linie für die ihm von einem Projektleiter zugewiesenen Teile des gesamten Softwaresystems verantwortlich. Es gab nicht unbedingt viele Überschneidungen mit der Arbeit anderer Teammitglieder.

Da die Softwareentwicklungsprojekte immer umfangreicher und komplexer wurden, dauerte es oft Jahre, bis sie von Anfang bis Ende abgeschlossen waren. Das bedeutete, dass in der Planungsphase ein enormer Druck ausgeübt wurde, um alles richtig umzusetzen. Wenn sich 2, 3 oder 5 Jahre später herausstellte, dass falsche Annahmen getroffen worden waren, war es schwierig, zurückzugehen und Änderungen vorzunehmen.

Immer mehr einflussreiche Denker im Bereich der Softwareentwicklung begannen zu argumentieren, dass die lineare Entwicklung von Softwaresystemen nicht der optimale Ansatz sei. Und dass sie ab einer bestimmten Größe einfach nicht mehr funktioniert. Es wurde eine Verbindung zu einer der Hauptstrategien hergestellt, die bei der Lean-Optimierung von Fertigungsprozessen zum Einsatz kommt – die Begrenzung der Menge an unfertigen Erzeugnissen (WIP).

Als Alternativen wurden iterative Ansätze für die Softwareentwicklung propagiert, die vorschreiben, dass ein Projekt zunächst auf das Wesentliche reduziert wird. Dabei handelt es sich um das kleinste, simpelste Paket von Kernfunktionen, das noch ausreicht, um den Benutzern der Software einen Mehrwert zu bieten. Nach der Freigabe wurde mit der Arbeit an der nächsten Iteration begonnen, die Korrekturen und Verbesserungen auf der Grundlage von Benutzerfeedback sowie das Hinzufügen neuer Merkmale und Funktionen umfasste.

Diese agilen Softwareentwicklungsmethoden und -frameworks dominieren heute die Branche. Sie schreiben nicht nur die Praktiken und Prozesse vor, aus denen ein Softwareentwicklungslebenszyklus besteht, sondern geben auch Auskunft über die Rollen und Verantwortlichkeiten, aus denen sich ein Softwareentwicklungsteam zusammensetzt.

Wie DevOps das Agile Softwareentwicklungsteam ergänzt und verbessert hat

DevOps und Continuous Delivery (CI) erweitern das Team auf den IT-Betrieb (hauptsächlich durch die Einführung von Automatisierung). Ein DevOps-Team hilft, das Problem zu vermeiden, dass das Entwicklungsteam das, was es für eine funktionierende Iteration eines Softwaresystems hält, an ein separates Betriebsteam weiterzugeben. Das Betriebsteam kämpft dann darum, dass das System in der Produktionsumgebung auf die gleiche Art und Weise läuft, da diese nicht genau mit der Entwicklungsumgebung übereinstimmt.

In einem DevOps-Team ist das gesamte Team aus Entwicklung und Betrieb dafür verantwortlich, wie ein Softwaresystem in der Produktion läuft. Entwickler und DevOps-Ingenieure müssen zusammenarbeiten, um sicherzustellen, dass neue Iterationen eines Softwaresystems in der Produktionsumgebung genauso ablaufen wie in der Entwicklungsumgebung.

Es hat sich gezeigt, dass das Aufbrechen der Silos zwischen Entwicklungs- und Betriebsrollen durch einen DevOps-Teamansatz die Agilität, Reaktionsfähigkeit und schnellere Markteinführung während des gesamten Softwareentwicklungszyklus unterstützt und verstärkt.

Die Rollen und Verantwortlichkeiten innerhalb eines Softwareentwicklungsteams können je nach der von einem Softwareentwicklungsteam angewandten Agile/DevOps-Methodik oder dem Framework leicht variieren und unterschiedliche Bezeichnungen haben. Die Kernrolle „Softwareentwickler“ kann auch in einer Vielzahl von Varianten der Seniorität und des Ausmaßes der Spezialisierung auf eine bestimmte Technologie oder Programmiersprache auftreten.

Teamrollen für agile und DevOps-Softwareentwicklung

Da es sich bei Scrum um die am weitesten verbreitete agile Praktik handelt, ist es sinnvoll, mit den Rollen in Scrum-Teams zu beginnen.

Ein Scrum-Entwicklungsteam hat drei definierte Kernrollen:

• Product Owner
• Scrum Master
• The Development Team

Das Entwicklungsteam ist in verschiedene Fachbereiche unterteilt:

• Front-end Developers
• Backend Developers
• Dev-Ops Engineers
• QA & Testing Experts,
• Business Analyst,
• Database Administrator or Engineer

In Scrum werden jedoch alle diese Rollen als Entwickler bezeichnet. Das Entwicklungsteam sollte auch keine Unterteams wie das Testteam, das Anforderungsspezifikationsteam usw. haben. Damit sollen Hierarchien innerhalb eines Softwareentwicklungsteams vermieden und eine Kultur der gemeinsamen Verantwortung gefördert werden.

Übersicht über das Scrum-Team

Die Rollen und Verantwortlichkeiten eines Scrum-Softwareentwicklungsteams sind auf Selbstorganisation ausgelegt, d.h. es entscheidet selbst, wie es seine Arbeit im Rahmen von Scrum am besten erledigt. Es sollte auch ein funktionsübergreifendes Team sein, das alle erforderlichen Kompetenzen für die Realisierung des Softwaresystems, mit dessen Entwicklung es beauftragt wurde, repräsentiert, ohne dass die Notwendigkeit besteht, externe Hilfe hinzuzuziehen.

Es wird empfohlen, dass ein Scrum-Team aus 3 bis 9 Mitgliedern des Entwicklungsteams sowie dem Product Owner und Scrum Master besteht. Vor allem bei kleineren Projekten kann die Rolle des Scrum Masters von einem erfahrenen Entwickler zusätzlich zu seiner Rolle und Verantwortung im Entwicklungsteam übernommen werden.

Größere Projekte, an denen mehr Experten arbeiten müssen, werden in Teile aufgeteilt, die verschiedenen Teams zugewiesen werden. Abhängigkeiten zwischen Softwareentwicklungsteams, die an demselben Softwaresystem arbeiten, werden durch skalierte Scrum-Frameworks wie Scrum of Scrums verwaltet.

https://www.youtube.com/watch?v=_-7gZlCkXpA

Rollen im Scrum-Team

Die beiden einzigen Rollen, die die agile Scrum-Methode für Softwareentwicklungsteams vorsieht, sind, wie bereits erwähnt, der Product Owner und der Scrum Master.

Product Owner

In einem agilen Softwareentwicklungsteam geht es um gemeinsame Verantwortung und eine flache Struktur. Doch als Entscheidungsträger auf der Makroebene trägt der Product Owner in einem Scrum-Team die größte Verantwortung für die Qualität eines Softwareprodukts. Seine Aufgabe ist es, die Geschäftsanforderungen mit den Markttrends in Einklang zu bringen, um eine Geschäftsstrategie und eine Produktvision zu definieren, die die Bedürfnisse der Benutzer erfüllt.

Der Product Owner muss Entscheidungen zur Priorisierung des Product Backlogs treffen und festlegen, wann Marktveränderungen oder Kundenfeedback die Anforderungen und Arbeitsabläufe ändern sollten.

Die Rolle des Product Owner in einem Scrum-Team hat viele Überschneidungen mit den Aufgaben des Business Analysten in alternativen Softwareentwicklungsteams. Der Hauptunterschied besteht darin, dass die Rolle des Business Analysten in der Regel mehr Wert auf die technische Umsetzung der Vision legt, während der Product Owner mehr auf den Kunden fokussiert ist.

Scrum Master

Die Rolle des Scrum Master ist meist ein zusätzlicher Aufgabenbereich, der entweder von einem Mitglied des Entwicklungsteams oder manchmal von einem Projektmanager übernommen wird. Der Scrum Master ist dafür verantwortlich, dass die Arbeitsabläufe innerhalb des Scrum-Rahmens organisiert werden und das Team sich an die Regeln und Prozesse hält und im Allgemeinen eine „agile Denkweise“ einnimmt.

Eines der wichtigsten Elemente der Rolle des Scrum Masters ist die Beseitigung von Arbeitshindernissen für das Software-Entwicklungsteam, indem er dafür sorgt, dass das Team alles hat, was es braucht, wenn es gebraucht wird.

Es gibt Überschneidungen zwischen den Rollen des Scrum Masters und des traditionellen Project Managers, zugleich auch wichtige Unterschiede. Die Priorität eines Scrum Masters ist das Team selbst und die Einhaltung des Scrum-Frameworks, während ein Projektmanager auf einer höheren Abstraktionsebene arbeitet. Ihre Priorität liegt eher in der Verteilung der Ressourcen und der Logistik, die für das Funktionieren eines Projekts notwendig sind, wie Risikomanagement, Vertragsmanagement und Budgetierung. Ein Projektmanager muss nicht unbedingt viel über das zu entwickelnde Produkt wissen.

Die meisten Frameworks für die agile Softwareentwicklung enthalten die Rollen des Product Owner und des Scrum Master oder grob vergleichbare Äquivalente. Das Framework Extreme Programming (XP) beispielsweise definiert diese Rollen:

• Customer
• Manager
• Coach

Die Rolle des Customer ist so etwas wie eine Kreuzung aus Scrum Product Owner und Business Analyst. Ein XP Manager übernimmt einige der Aufgaben, die normalerweise mit einem Projektmanager verbunden sind. Andere wiederum ähneln eher denen eines Scrum Masters. Der XP Coach hat viele Ähnlichkeiten mit der Rolle des Scrum Masters und ist für die Teamkultur und die Einhaltung der Praktiken und Regeln der Methodik verantwortlich.

Tech-Stacks und Spezialgebiete des Entwicklungsteams

Abgesehen von diesen spezialisierten Rollen besteht der Großteil eines Softwareentwicklungsteams natürlich aus den IT-Spezialisten, die ein Softwaresystem technisch entwerfen, codieren, erstellen, testen und betreiben. Auch wenn die meisten agilen Softwareentwicklungsteams die verschiedenen technischen Fähigkeiten und Tech-Stacks nicht als „Rollen“ definieren, lohnt es sich, die Hauptkategorien von „Entwicklern“ zu nennen, die durch Tech-Stack und Verantwortungsbereiche definiert sind.

Software architect

Ein Softwarearchitekt ist fast immer ein erfahrener Softwareentwickler, der in der Regel über ein umfassendes Wissen verfügt, um gute Entscheidungen treffen zu können. Auf der Grundlage der Softwareanforderungen, die vom Product Owner oder den Business Analysten bereitgestellt werden, erstellt der Architekt, ähnlich wie ein Bauarchitekt, Diagramme und Dokumentationen, die definieren, wie die endgültige Lösung im Einklang mit den geschäftlichen Anforderungen praktisch umgesetzt werden soll. Der Architekt ist verantwortlich für Designentscheidungen auf hoher Ebene und für die Festlegung technischer Standards, einschließlich der zu verwendenden Tools und Plattformen sowie der Software-Codierungsstandards.

Tech Lead

Der Softwarearchitekt kann, wenn auch nicht immer, gleichzeitig auch der technische Leiter des Softwareentwicklungsteams sein. Wie ein Architekt konzentriert sich auch der Tech Lead auf die technischen Aspekte oder das „Wie“ der Umsetzung der Anforderungen. Der Tech Lead ist jedoch viel stärker in den eigentlichen Entwicklungsprozess involviert und führt das Team zu einer gemeinsamen technischen Vision zusammen.

Während jeder Entwickler für die Qualität seines Outputs verantwortlich ist und die Qualität des Outputs seiner Kollegen nach Möglichkeit unterstützt, ist der Tech Lead für die Qualität der technischen Ergebnisse des gesamten Teams verantwortlich.

Front End Developer

Ein Front-End-Entwickler ist für die Programmierung der Benutzeroberfläche eines Softwaresystems verantwortlich – also für alles, was ein normaler Benutzer sieht und mit dem er interagiert. Sie haben in der Regel Erfahrung mit einer oder mehreren Frontend-Programmiersprachen wie HTML, PHP und JavaScript oder mit den gängigen Frameworks und Bibliotheken wie React, Angular und Vue.js. Alternativ können sie auch auf mobile-first und native Sprachen und Frameworks wie Flutter, React Native, Ionic, Java, Kotlin oder Swift (iOS) setzen.

Back End Developer

Ein Back-End-Entwickler ist für die Erstellung aller Teile eines Softwaresystems verantwortlich, die der Benutzer nicht sieht und mit denen er nicht interagieren kann, die aber dafür sorgen, dass alles im Front-End funktioniert. Um auf die Metapher des Bauens zurückzukommen: Das Backend eines Softwaresystems ist das Äquivalent zum Fundament, den Rohrleitungen, der Elektrik, den Gasinstallationen usw. in einem Haus. Nichts davon ist in der Regel sichtbar, aber sein reibungsloses, effektives Funktionieren trägt wesentlich zur Qualität des Wohngefühls bei, das das Haus bietet.

Beliebte Programmiersprachen für die Backend-Entwicklung sind Python, Ruby, PHP, Node.js und Golang. Die beliebtesten Backend-Frameworks für die Entwicklung mobiler Apps sind Django, Ruby on Rails, Express/Koa/Sails für Node.js und das von Google entwickelte BaaS-Tool (Backend as a Service) Firebase.

Full Stack Developer

Ein Full-Stack-Entwickler verfügt über Fachwissen und Erfahrung in Front- und Back-End-Programmiersprachen und -Technologien sowie Erfahrung im Aufbau von Front- und Back-Ends von Softwaresystemen. Die meisten Entwickler entwickeln sich zu Full-Stack-Entwicklern, wenn sie an Berufserfahrung und Kompetenz gewinnen und im Laufe ihrer Karriere neue Fähigkeiten erlernen.

Als Teil eines Softwareentwicklungsteams übernimmt ein Full-Stack-Entwickler die Verantwortung für Front- und Back-End-Aufgaben aus dem Produkt-Backlog oder trägt zu diesen bei.

In einem Software-Entwicklungsteam kann ein nomineller Full-Stack-Entwickler als reiner Front-End-Entwickler oder nur an Back-End-Backlog-Aufgaben oder an beidem arbeiten. In einem Agilen Softwareentwicklungsteam kann sich der ursprüngliche Plan mit den Anforderungen ändern und ein Entwickler, der ursprünglich für das Frontend vorgesehen war, kann Backend-Aufgaben übernehmen, wenn sein Stack dies zulässt.

Die Bandbreite an Fähigkeiten und Erfahrungen, die Full- und Fuller-Stack-Entwickler mitbringen, kann eine unschätzbare Flexibilität innerhalb ihres Entwicklungsteams bieten. In der freien Wildbahn findet man nur selten einen Senior-Entwickler, der kein Full-Stack-Entwickler ist und lediglich über Front-End- oder Back-End-Kenntnisse verfügt. Das Erreichen der Senior-Ebene ist in der Regel nur durch den Aufbau eines T-shaped oder Comb-shaped Tech-Stacks möglich.

UX Designer

Ein UX-Designer (User Experience) ist dafür verantwortlich, dass ein Softwaresystem so intuitiv wie möglich genutzt werden kann. Sie erstellen User Personas und Szenarien und verwenden diese, um das Layout der einzelnen Bildschirme einer Anwendung sowie den Informationsfluss auf der gesamten Website zu gestalten.

Sie entwerfen Wireframes und Prototypen, die das Layout und das „Gefühl“ eines Softwaresystems aus der Sicht eines Benutzers zeigen. Wenn Sie sich schon einmal darüber geärgert haben, dass Ihre Lieblingsapplikation aktualisiert wurde und nicht mehr so funktioniert wie früher oder dass sich Elemente geändert haben, die Funktionalität und die Merkmale aber gleich geblieben sind, dann ist das das Ergebnis eines UX-Design-Updates. Wenn man ein wenig Zeit hat, sich an das neue Layout oder die neue Navigation zu gewöhnen, stellt man oft fest, dass es tatsächlich eine Verbesserung gegenüber dem ist, was man anfangs vermisst hat.

UI Designer

Der UX-Designer ist für das Layout und die Benutzerführung innerhalb eines Softwaresystems verantwortlich, während der UI-Designer das visuelle Erscheinungsbild gestaltet – wie es aussieht und wie der Benutzer damit interagiert. Der UI-Designer wählt den Designstil aus, normalerweise im Rahmen von Stilrichtlinien, die oft unternehmensweit gelten. In kleineren oder jüngeren Unternehmen kann der UI-Designer auch für die Entwicklung von Branding- und Stilrichtlinien verantwortlich sein.

Während UX- und UI-Design unterschiedliche Fähigkeiten erfordern, verfügen einige UX- und UI-Designer über Fachwissen in beiden Rollen und können diese kombinieren.

DevOps Engineer

Die Rolle und die Aufgaben eines DevOps können je nach Softwareentwicklungsteam variieren. Im Großen und Ganzen ist ein DevOps jedoch für die Integration von DevOps-Prozessen, -Tools und -Methoden während des gesamten Softwareentwicklungslebenszyklus verantwortlich, wobei der Schwerpunkt auf der Automatisierung von Testsuiten und CI/CD-Tools liegt. Ihre Arbeit soll die Kooperation und Teamarbeit zwischen Entwicklungs- und Betriebsteams erleichtern.

DevOps sind in der Regel für das Release-Engineering, die Bereitstellung und Wartung der Infrastruktur, die Systemadministration und die Sicherheit zuständig und können sowohl aus der Entwicklung als auch aus dem Betrieb kommen. Der Schwerpunkt ihrer Rolle in einem bestimmten Softwareentwicklungsteam wird in der Regel durch diesen Hintergrund bestimmt. Ein DevOps-Spezialist mit einem Entwicklungshintergrund wird sich mehr auf die Automatisierung und die Einführung einer DevOps-Kultur und -Prozesse innerhalb des Teams konzentrieren. Von einem DevOps-Spezialisten mit einem Systemadministrationshintergrund wird erwartet, dass er eher eine operative Rolle übernimmt.

Quality Assurance (QA) Engineer

Qualitätssicherungsingenieure oder -techniker werden oft mit Softwaretestern verwechselt, aber es gibt bedeutende Unterschiede zwischen diesen beiden Rollen. Die Qualitätssicherung ist prozessorientiert und stellt sicher, dass die Prozesse, die zur Verwaltung und Erstellung der Ergebnisse eingesetzt werden, funktionieren und Fehlerfrei funktionieren. Ein QS-Ingenieur verwendet Audits und Metriken als Werkzeuge zur Überwachung dieser Prozesse.

QSs erarbeiten und integrieren Methoden, die häufig auf DevOps-Automatisierung basieren, um zu verhindern, dass Fehler in einem Softwaresystem auftreten und dass der von den Entwicklern produzierte Code den festgelegten Standards entspricht.

Testing Engineer

A testing engineer is responsible for Quality Control (QC) rather than QA. While QA is process oriented, QC is product oriented – the processes and tools designed to uncover bugs, poor usability and other defects. A testing engineer’s responsibility is to find any defects in a software system that have made it through QA processes and tools.

Ein Testingenieur ist eher für die Qualitätskontrolle (QK) als für die QS zuständig. Während die QS prozessorientiert ist, ist die QK produktorientiert – die Prozesse und Werkzeuge, die dazu dienen, Fehler, schlechte Benutzerfreundlichkeit und andere Defekte aufzudecken. Die Aufgabe eines Testingenieurs besteht darin, alle Fehler in einem Softwaresystem zu finden, die die QS-Prozesse und -Tools durchlaufen haben.

Die Aufgabe eines Testingenieurs besteht hauptsächlich darin, automatisierte Testsysteme einzurichten. In der Regel werden auch manuelle Tester hinzugezogen, die sich methodisch durch die User Stories arbeiten (in der Regel nach einem System, das von einem Testingenieur oder einem leitenden manuellen Tester entworfen wurde) und Fehler oder andere Probleme finden, die bei den automatisierten Tests übersehen wurden.

Mit der zunehmenden Komplexität von Softwaresystemen wird die Rolle des „Softwareentwicklungsteams“ als Grundlage für ihren Erfolg oder Misserfolg immer deutlicher, und nicht die Leistung einzelner Teammitglieder.

Es ist kein Zufall, dass Scrum zu Ehren eines Rugby-Scrums benannt wurde. Die agile Methodik war eine der ersten, die das gemeinsame Ergebnis des Kollektivs als mehr als die Summe seiner Teile in den Mittelpunkt des Softwareentwicklungsprozesses stellte. Es ist eine Philosophie und Kultur, die heute fast jedem erfolgreichen Softwareentwicklungsprojekt jeder Größenordnung zugrunde liegt.