New > Blogs

Geht Testleiter remote? 3 Tipps zum Aufbau von Vertrauen

QESTIT Team — Wed, 02 Sep 2026 13:42:56 GMT

Als Testleiter aus der Ferne zu arbeiten, bringt verschiedene Herausforderungen mit sich. Beispielsweise müssen Sie möglicherweise kulturelle Unterschiede bewältigen und ein förderliches Umfeld für Zusammenarbeit und Vertrauen schaffen. Da heute aufgrund der anhaltenden COVID-19-Pandemie immer mehr Unternehmen und Organisationen mit ausgelagerten Teams arbeiten und/oder aus der Ferne arbeiten, müssen Sie als Testleiter möglicherweise darüber nachdenken, wie Sie am besten mit Ihrem Team zusammenarbeiten. Wenn Sie von Anfang an Vertrauen innerhalb des Teams aufbauen, erhöhen Sie Ihre Chancen auf ein erfolgreicheres Team. Hier teile ich meine drei wichtigsten Tipps zum Aufbau dieses starken und entscheidenden Vertrauens.

Ob Sie Testleiter, Projektmanager, Coach oder in einer anderen Führungsposition sind, Vertrauen macht den Unterschied, wenn es darum geht, ein Team aufzubauen. Die Frage des Vertrauens kann knifflig sein und wird oft leicht übersehen oder zumindest nicht täglich berücksichtigt. Das ist bedauerlich, denn das Thema Vertrauen sollte immer ganz oben auf der Tagesordnung stehen und im Idealfall im Vordergrund der Gedanken jedes Leiters stehen – jeden Tag und in jedem Meeting. Sowohl aus der Ferne als auch im Büro.

Wenn Sie es nicht schaffen, zwischen Ihnen und Ihrem Team Vertrauen aufzubauen, ist dies ein sicherer Weg, um Stress und Konflikte innerhalb des Teams zu erzeugen. Dies wiederum führt dazu, dass das Team zusammen schlecht arbeitet – was letztlich zu unterdurchschnittlichen Ergebnissen führt.

Es gibt viele Möglichkeiten, wie Sie als Leiter Vertrauen aufbauen können, aber hier sind drei Faktoren, die meiner Meinung nach für den Erfolg wichtig sind:

Um Vertrauen zu gewinnen, müssen Sie Vertrauen geben.

Das ist wahrscheinlich für niemanden eine Überraschung, aber ich glaube, dass jeder in Ihrem Team Berge versetzen wird, um die einfache, aber kraftvolle Geste des Respekts zurückzuzahlen, die gutes Vertrauen bieten kann. Regelmäßig Ihre Autorität abzugeben ist immer ein guter Weg, um Vertrauen aufzubauen und Respekt zu verdienen. Warum nicht beispielsweise bei Besprechungen die Verantwortung wechseln und verschiedene Personen die Besprechung leiten lassen? Zweitens versuchen Sie, die Entscheidungsfindung so oft wie möglich an Einzelpersonen oder das gesamte Team zu delegieren.

Sorgen Sie immer für einen Informationsfluss.

Ihre Teammitglieder werden erfolgreicher sein, wenn sie den Kontext ihrer Arbeit verstehen, wenn sie erkennen, dass sie Teil eines größeren Ganzen sind und dass ihre Arbeit für den Erfolg des Projekts oder der Lieferung wichtig ist. Informieren Sie Ihr Team immer über Höhen und Tiefen sowie über das, was in Projektbesprechungen, Lenkungsausschüssen oder anderen nützlichen Informationen besprochen wird, die Ihrem Team einen ganzheitlichen Überblick über das Projekt oder die Lieferung geben. Ihre Transparenz zeigt, dass Sie Ihren Teammitgliedern vertrauen, wenn Sie wichtige Informationen mit ihnen teilen.

Zeigen Sie Führungsstärke.

Denken Sie daran, zu zeigen, dass auch Sie nur ein Mensch sind. Wenn Sie einen Fehler machen – geben Sie es zu. Wenn Sie an Feedback zu Ihrer Leistung interessiert sind, bitten Sie darum und tun Sie dann etwas Positives mit dem Input, den Sie erhalten. Wenn Sie Feedback erhalten haben, ist es auch wichtig, daran zu denken, dieses Feedback an Ihre Teammitglieder weiterzugeben und ihnen für ihren Input zu danken. Wenn etwas schief geht, sind Sie als Leiter derjenige, der den ersten „Schlag“ einstecken muss, es wagen muss, ins Rampenlicht zu treten und Ihren Teammitgliedern den Rücken freizuhalten. Wenn die Situation anschließend bewältigt ist, ermutigen Sie Ihr Team, die gewonnenen Erkenntnisse zu teilen. Ihre Fehler sind ein doppelter Gewinn – nutzen Sie Ihre eigenen Fehler, um andere zu lehren!

Im Gespräch mit Bouzid, SAP-Consultant

QESTIT Team — Wed, 02 Sep 2026 13:37:11 GMT

Ein Interview mit Bouzid Belmahdi über seine Rolle, Herausforderungen und Erfolge als SAP-Consultant bei QESTIT.

Im Gespräch mit Andreas, Recruiter

QESTIT Team — Wed, 02 Sep 2026 13:33:40 GMT

Ein Interview mit Andreas Barthel,Recruiter bei QESTIT.

IT-Sicherheit bei SAAS-Lösungen – das gilt es zu beachten

Jon Jezierski — Thu, 16 Jul 2026 08:02:17 GMT

Es wird immer üblicher, SaaS-Lösungen (Software as a Service) zu verwenden, vor allem, weil sie kostengünstig und einfach zu verwenden sind, da Betrieb und Wartung vom Anbieter übernommen werden. Außerdem können sie eine hohe Sicherheit bieten, da Dinge schiefgehen können, wenn Sie nicht vorsichtig sind und vor dem Kauf die Sicherheit gewährleisten. Zu viele Leute kaufen eine SaaS-Lösung mit der gleichen Einstellung wie beim Autokauf: Sie erwarten, dass die Person, die das Auto gebaut hat, dafür gesorgt hat, dass es sicher und intakt ist.

3 wichtige Dinge, die Sie vor dem Kauf einer SaaS-Lösung bedenken sollten

1. Verteilung der Verantwortlichkeiten

Finden Sie zunächst heraus, wer für was verantwortlich ist, um einen guten Überblick über die Lösung zu erhalten. Cloud hat viele verschiedene Modelle: Private Cloud, wo Sie Ihre eigene Umgebung einrichten, Ihre eigenen Maschinen betreiben und verwalten. Infrastructure as a Service, wo Sie als Kunde für bestimmte Teile verantwortlich sind und der Anbieter für bestimmte Teile. Dann gibt es „Platform as a Service“, wo der Anbieter den Großteil übernimmt, und „Software as a Service“, über das wir in diesem Artikel sprechen.

Es liegt in Ihrer Verantwortung, sicherzustellen, dass Sie ein Produkt kaufen, das die Sicherheitsklassifizierung der Daten verarbeiten kann, die die Lösung verarbeiten wird. Wie beim Autokauf ist Volvo dafür verantwortlich, dass Sie das Auto sicher fahren können und dass es nicht verunfallt. Sollten Sie jedoch einen Unfall haben und verletzt werden, ist das Ihr Problem.

2. Anforderungen

Bei der Bewertung von Lieferanten und während des Kaufs ist es wichtig, dass Sie die Sicherheitsanforderungen klar kennen, damit Sie sicherstellen können, dass Ihre Daten bei dem von Ihnen ausgewählten Anbieter absolut sicher sind.

Was eine Anforderungserklärung enthalten sollte, ist individuell. Beginnen Sie beim Erstellen Ihrer Anforderungserklärung immer damit, welche Art von Daten Sie in der Lösung haben. Wenn Sie beispielsweise Kreditkarteninformationen haben, muss die Lösung PCI DSS verarbeiten können, und wenn Sie personenbezogene Daten haben, muss die Lösung der DSGVO entsprechen.

Auch wenn die Anforderungen individuell sind, stellt die überwiegende Mehrheit normalerweise sicher, dass Penetrationstests durchgeführt werden. Etwas, das normalerweise vom Lieferanten erledigt wird. Ein Tipp ist, sicherzustellen, dass der Lieferant einen Pen-Tester von einer unabhängigen Partei hinzuzieht. Um besonders sicher zu sein, sollten Sie beim Kauf einer Lösung auch verpflichtet sein, Ihre eigenen unabhängigen Tester einzusetzen, was fast immer in Ordnung ist. Am Ende dieses Artikels finden Sie eine Liste der wichtigsten allgemeinen Dinge, die Sie in eine Sicherheitserklärung aufnehmen sollten.

Die Lieferanten stehen der Einbeziehung eines externen Partners und der Bezahlung der Sicherheitstests normalerweise sehr positiv gegenüber, aber ich denke, Sie sollten sicherstellen, dass der Lieferant diese Kosten übernimmt. Schließlich sind Sie der Kunde und werden für das Produkt bezahlen. Es ist, als würden Sie ein Auto kaufen und es dann in eine Werkstatt bringen, um zu überprüfen, ob es sicher ist. Das tun Sie nicht.

Je nach SaaS-Lösung können Sie benutzerdefinierte Konfigurationen und Integrationen vornehmen. In diesem Fall führen Sie die Tests auf eigene Kosten durch.

Meistens ist es gut, Ihre Anforderungen während der Evaluierung/vor dem Kauf mit dem Lieferanten abzuklären, aber leider finden viele dies zu spät heraus. Dadurch landen Sie in einer Situation ohne benutzerdefinierte Datenanforderungen, was das Ganze komplexer macht. Erstens sollten Sie sich die Lösung ansehen, einschätzen, wie wichtig sie für Ihre Informationen ist, und prüfen, ob Sie etwas ändern müssen/können. Zweitens sollten Sie herausfinden, ob der Lieferant bereit ist, diese Änderungen vorzunehmen, was er normalerweise ist. Von dort aus entwickeln Sie eine Reihe von Anforderungen, die Sie gemeinsam durchgehen, wobei Sie sich ansehen, was heute vorhanden ist und was behoben werden muss.

Die SaaS-Anbieter sind fast immer offen für Änderungen, aber Sie müssen verstehen, dass dies nicht über Nacht geschieht, sondern Zeit braucht. Wenn Sie ein Nein erhalten, müssen Sie einfach eine Entscheidung treffen, ob Sie mit dem Risiko leben oder sich nach einer neuen Plattform umsehen können.

3. Die Prozesse des Lieferanten in Bezug auf Sicherheit und Tests

Bevor ein Kauf getätigt wird, ist es auch wichtig, herauszufinden, wie der Testprozess des Lieferanten aussieht und wie er mit Sicherheit umgeht. Sie möchten keinen Produktbesitzer haben, der andere Dinge als Sicherheit und deren Maßnahmen priorisiert.

Finden Sie heraus, ob sie Sicherheitstests durchführen und wenn ja, welche Sicherheitstests sie durchführen. Finden Sie heraus, wie sie die Tests durchführen, wer die Tests durchführt, wie oft sie sie durchführen und wie der Prozess aussieht, um Schwachstellen zu beheben, falls sie auftreten. Fordern Sie ruhig Beweise an, um zu überprüfen, wie die Berichte aussehen und wie sie frühere Schwachstellen (falls vorhanden) behoben haben.

Ihre Sicherheitsarbeit sollte Kontinuität aufweisen, Tests sollten nicht nur auf Anfrage oder alle drei Jahre durchgeführt werden.

Zusammenfassung

Da immer mehr Unternehmen auf verschiedene SaaS-Lösungen umsteigen, ist die Anbieterseite völlig explodiert. Unabhängig davon, ob Sie Ihre eigenen oder SaaS-Lösungen betreiben, ist es äußerst wichtig, sicherzustellen, dass die Anwendung, die Infrastruktur und die Daten ausreichend geschützt sind. Das Problem ist, dass wir oft erwarten, dass Sicherheit vorhanden ist, ohne dies beim Kauf zu überprüfen oder Anforderungen zu stellen, was im Falle eines Angriffs fatale Folgen haben kann.

Wir haben daher eine Checkliste zusammengestellt, was Sie in der Kaufphase einer SaaS-Lösung in Ihre Anforderungen aufnehmen sollten. Die Checkliste finden Sie hier.

Die häufigsten Probleme, die wir in der IT-Sicherheit sehen

Mattias Döj — Thu, 16 Jul 2026 08:02:09 GMT

Die meisten Produkte, die Sie kaufen, sind auf Netzwerk- und Endpunktsicherheit ausgerichtet. Diese sind nicht sehr wirksam gegen Schwachstellen in Webanwendungen. In diesem Beitrag beleuchten wir daher die häufigsten Probleme, die wir bei unserer Arbeit sehen, von schwachen Netzwerken bis hin zur Benutzeraufzählung. Das Verständnis dieser Herausforderungen ist nicht nur für IT-Experten wichtig, sondern auch für Einzelpersonen und Organisationen, die ihre Sicherheitslage in einer zunehmend vernetzten Welt verbessern möchten.

Schlechte Passwörter

Wenn Sie eine Anwendung verwenden, werden Sie als Erstes auf eine Art Authentifizierung stoßen. Dies ist normalerweise eine Kombination aus Benutzername und Passwort. Und natürlich unterscheiden sich die Anforderungen von Site zu Site stark. Es ist recht üblich, dass Groß- und Kleinbuchstaben sowie möglicherweise einige Zahlen und Sonderzeichen erforderlich sind. Die Länge ist ebenfalls ein wichtiger Faktor. Eine gute Richtlinie ist, das Passwort lang genug zu halten, um Brute-Force-Angriffe zu verhindern, und komplex genug, damit es nicht in einem Wörterbuch auftaucht. Eine gute, empfohlene Länge ist MINDESTENS 10 Zeichen. Vorzugsweise viel mehr.

Wir sind auf zahlreiche Anwendungen gestoßen, bei denen die einzige Anforderung eine Länge von sechs Zeichen war. Ein Passwort wie „111111“ wäre also vollkommen akzeptabel. Selbst ein einfacher Computer würde eine kurze Zeit brauchen, um einen Hash dieses Passworts zu knacken. Ganz zu schweigen davon, dass es wahrscheinlich in einem Wörterbuch steht, sodass auch Brute-Force-Angriffe durchaus möglich wären. Weitere Informationen dazu, wie Passwörter geknackt werden, finden Sie hier.

Fehlende starke SSL-Implementierung

SSL Labs ist ein praktisches Tool zur Bewertung des aktuellen Status der SSL-Implementierung. Es ist schnell, einfach zu verwenden und umfassend. Es gibt auch das Tool SSL Checker, eine vereinfachte Version, die für Laien leichter zu verstehen ist. Es bietet außerdem die zusätzliche Möglichkeit, SSL-Sicherheitsheader zu überprüfen. Wir werden jetzt nicht auf alle Details zur SSL/TLS-Implementierung eingehen, das würde mindestens mehrere weitere Seiten in diesem Beitrag erfordern. Wir müssen also mit einem separaten Beitrag darüber zurückkommen. Wenn Sie jetzt mehr wissen möchten, gibt es ein weiteres praktisches Tool. Sie nennen es Google; wir glauben, dass es langsam ankommt! Oder kontaktieren Sie uns einfach und wir sorgen dafür, dass Sie die richtigen Informationen erhalten.

Benutzeraufzählung

Es gibt mehrere gängige Möglichkeiten, mit denen Anwendungen gültige Benutzer aufzählen können. Eine der gängigsten und einfachsten Möglichkeiten ist die Anmeldefunktion. Ein Beispiel: Sie melden sich bei einer Anwendung an. Wenn Sie den richtigen Namen eingeben, aber das Passwort verwechseln, lautet die Antwort „Das Passwort ist falsch“. Dies ist ein Hinweis darauf, dass der Benutzer ein gültiger Benutzer ist. Wenn Sie einen anderen Benutzernamen (der nicht gültig ist) ausprobieren und die Antwort „Kein gültiger Benutzer“ lautet, können Sie nun leicht feststellen, dass der erste Benutzer tatsächlich ein gültiger Benutzer war.

Für einen Angreifer wäre dies eine gute Gelegenheit, Benutzer der Anwendung mit Brute Force anzugreifen. Denn die Anwendung wird antworten und Sie darüber informieren, ob der Benutzer gültig ist oder nicht.

XSS/HTML/SQL-Injection

Das größte Problem der Jahre 2017 und 2018 waren Injections verschiedener Art. Was kann also injiziert werden? SQL-Abfragen, Betriebssystembefehle, HTML-Inhalte, ganze Seiten mit Inhalten und Skripten. Wo kann man das injizieren? Überall dort, wo eine Benutzereingabe erforderlich ist oder Benutzer Daten ändern können, z. B. in einem Textfeld, einem Benutzernamen-/Passwortfeld, Suchfunktionen, Feedback- und Kommentarfeldern, URLs usw.

Uneingeschränkter Dateiupload

Hochgeladene Dateien können schwerwiegende Auswirkungen auf die Anwendung sowie das Dateisystem haben. Es ist oft zu beobachten, dass es keine Filter dafür gibt, welche Arten von Dateierweiterungen hochgeladen werden können. Wenn nur ein oder zwei Dateitypen benötigt werden, sollten alle anderen auf der schwarzen Liste stehen.

Stellen Sie sich eine in PHP geschriebene Anwendung vor, bei der der Benutzer ein Profilbild hochladen kann. Sie würden annehmen, dass diese Funktion nur das Hochladen von Bilddateien (JPG und PNG) zulässt. Aber auch andere Dateiformate dürfen hochgeladen werden. Da wir es in diesem Fall mit PHP zu tun haben (und PHP direkt mit dem Betriebssystem interagieren kann), laden wir einen lustigen PHP-Code hoch, der uns eine direkte Kommunikation mit dem Dateisystem des Servers selbst ermöglicht. Dies kann zu noch fantastischeren Dingen führen, wie z. B. der Gefährdung von Informationen und möglicherweise auch zu einem weiteren Eindringen in das Netzwerk.

Defekte Zugriffskontrollen (Sicherheit durch Verschleierung)

Dies geschieht, wenn nicht die richtigen Prüfungen für die gesamte Sitemap durchgeführt werden. Dadurch kann ein Benutzer auf Informationen zugreifen, die seine Benutzerberechtigungen nicht zulassen sollten (oder die völlig ohne Authentifizierung sind). Stellen Sie sich vor, Sie durchsuchen Ihre Zeiterfassungsanwendung mit Ihrem Konto mit niedrigen Berechtigungen. Das Einzige, was Sie davon abhält, Ihren eigenen Zeitbericht zu genehmigen, sind im Grunde kosmetische Dinge. Die Genehmigungsschaltfläche ist für Ihr Konto nicht sichtbar, sondern nur für die Administratoren der Anwendung. Wenn Sie die Anforderungsdaten kennen würden, könnten Sie den Zeitbericht tatsächlich selbst genehmigen.

In dieser Anwendung haben Sie und Ihr Unternehmen einige interne Dokumente gespeichert, die vertrauliche Informationen enthalten. Sie greifen auf eines der PDFs zu und laden es authentifiziert herunter. Wenn Sie sich von der Anwendung abmelden und dann dieselbe URL für dieses Dokument aufrufen und die Datei zugänglich ist, wäre dies erneut ein Beweis für fehlerhafte Zugriffskontrollen.

Schwache Benutzer-/Gruppensegmentierung (Least Privilege Practice)

Es wäre schön, in einer Welt zu leben, in der alle gleich sind. Aber wenn es um IT geht, ist dies ein absolutes No-Go, aber dennoch eine sehr gängige Sache. Alle Konten einer Anwendung oder eines Netzwerks haben die gleichen Berechtigungen, was Chaos mit sich bringt, insbesondere wenn diese Anmeldeinformationen von einem Angreifer kompromittiert werden. Dies bedeutet mehr oder weniger, dem Angreifer die Schlüssel zum Königreich zu geben, und wird allgemein als „schlechte Idee“ bezeichnet. Hier muss gefragt werden, ob Janice aus der Buchhaltung tatsächlich Zugriff auf die streng geheimen Dokumente benötigt, die für Leann und Kurt bestimmt sind? Benutzerrollen sollten nach dem Prinzip der geringsten Privilegien zugewiesen werden. Was Sie nicht wissen müssen, sollten Sie einfach nicht wissen oder keinen Zugriff darauf haben.

Schlechtes Patch-Management / End-of-Life-Management

Ein gutes Beispiel für dieses Problem ist der WannaCry/EternalBlue-Ausbruch am 12. Mai 2017. Infrastrukturen auf der ganzen Welt waren von dieser Sicherheitslücke betroffen, die Server und Computer von Unternehmen unterschiedlicher Größe wurden mit einem Cryptolocker infiziert. Laut IBM X-Force wurde in 150 Ländern allein durch den WannaCry-Vorfall ein Gesamtschaden von über 8 Milliarden Dollar gemeldet. Ich denke, das spricht für sich: Wenn Sie Ihre eigenen Daten und Server verwalten, können Sie kontrollieren, wann und was Sie patchen. Bei einem Drittanbieter haben Sie keine Ahnung, was er tut. Deshalb ist dies eine gute Frage an jeden Drittanbieter, den Sie in Betracht ziehen.

Schwache Netzwerk-/Datenbanksegmentierung

Wir hatten Fälle, in denen uns gesagt wurde, dass das Netzwerk oder die Datenbank richtig segmentiert ist, zumindest laut den Leuten, mit denen wir gesprochen haben. Als wir uns später bei ihnen meldeten, haben wir bewiesen, dass dies nicht der Fall ist. Anwendungen, bei denen die Vorproduktionsversion und die Produktionsversion auf demselben Server gespeichert sind wie die „richtig segmentierte“ Datenbank. Die tatsächliche Segmentierung der Datenbank bestand tatsächlich nur darin, dass es sich um zwei separate Zweige in derselben Datenbank handelte. Das bedeutete, dass die in der Vorproduktionsanwendung gefundene SQL-Injection auch zu einer vollständigen Kompromittierung der Produktionsdatenbank führte. Dies wurde auch bei Multi-Tenant-Systemen beobachtet, bei denen die Daten mehrerer Unternehmen alle in derselben Datenbank gespeichert sind.

Der dringende Bedarf an Cyber-Resilienz

Shahin Imanverdiyev — Thu, 16 Jul 2026 08:01:16 GMT

Der Global Cyber Resilience Report 2024 von Cohesity bietet wichtige Einblicke in den Stand der Cyber-Resilienz von Organisationen weltweit. Basierend auf einer Umfrage unter mehr als 3.100 IT- und Security-Entscheidern in acht Ländern, darunter die USA, Großbritannien und Deutschland, zeigt der Bericht erhebliche Unterschiede zwischen der Wahrnehmung von Organisationen hinsichtlich ihrer Fähigkeit, auf Cyber-Bedrohungen zu reagieren, und ihren tatsächlichen Fähigkeiten auf.

Eines der wichtigsten Ergebnisse der Studie ist die wachsende Bedrohung durch Ransomware. Im Jahr 2024 gaben 67 % der Unternehmen an, dass sie Opfer eines Ransomware-Angriffs geworden sind, und obwohl viele Unternehmen Richtlinien gegen die Zahlung von Lösegeld haben, gaben 69 % der Betroffenen zu, dass sie dennoch Lösegeld gezahlt haben. Besorgniserregend ist die Tatsache, dass 22 % dieser Unternehmen mehr als 3 Millionen US-Dollar für die Wiederherstellung ihrer Daten und die Wiederaufnahme des Geschäftsbetriebs gezahlt haben, was den enormen finanziellen Druck zeigt, den diese Angriffe auf Unternehmen ausüben.

Ein weiterer kritischer Punkt, der in dem Bericht angesprochen wird, ist die Zeit, die benötigt wird, um sich von einem Cyberangriff zu erholen. Nur 2 % der Unternehmen gaben an, dass sie in der Lage waren, Daten wiederherzustellen und den Betrieb innerhalb von 24 Stunden nach einem Angriff wieder aufzunehmen. Tatsächlich gaben 16 % der Befragten an, dass die Wiederherstellung mehr als drei Wochen dauern würde, was den dringenden Bedarf an besserer Vorbereitung und schnelleren Wiederherstellungslösungen unterstreicht.

Der Bericht weist auch auf eine Diskrepanz zwischen Selbstvertrauen und Realität hin, wenn es um Cyber-Resilienz geht. Während 78% der Befragten von der Resilienzstrategie ihrer Organisation überzeugt sind, deuten langsame Wiederherstellungszeiten und die Abhängigkeit von Lösegeldzahlungen auf eine erhebliche Kluft zwischen strategischen Absichten und tatsächlichen Möglichkeiten hin.

Erschwerend kommt hinzu, dass viele Organisationen bei der Umsetzung grundlegender Sicherheitsmaßnahmen noch im Rückstand sind. Fast die Hälfte der befragten Organisationen (48%) hat bisher keine Multi-Faktor-Authentifizierung (MFA) eingeführt, wodurch ihre kritischen Systeme anfällig für potenzielle Angriffe durch externe und interne Bedrohungen sind.

Wie der Bericht zeigt, stehen Organisationen in Europa vor ähnlichen Herausforderungen. Mit Deutschland und Frankreich an der Spitze, wo jeweils rund 400 Organisationen befragt wurden, wird deutlich, dass europäische Organisationen nicht immun gegen die wachsende Gefahr von Cyberangriffen sind. Auch sie sehen sich mit einer alarmierend hohen Rate von Ransomware konfrontiert. Eine beträchtliche Anzahl von ihnen lässt sich trotz strenger Richtlinien bezüglich der Nichtzahlung zur Kasse bitten.

Die Daten zeigen auch, dass europäische Organisationen, ebenso wie ihre globalen Amtskollegen, ihre Fähigkeit, sich schnell von Cyberangriffen zu erholen, häufig überschätzen. Vielen fehlen auch wichtige Cybersicherheitsmaßnahmen wie MFA, was eine eklatante Lücke in ihrem Zero-Trust-Sicherheitsansatz darstellt und sensible Daten angreifbar macht.

Die überwiegende Mehrheit der Befragten (96 %) geht davon aus, dass die Landschaft der Cyberbedrohungen in den kommenden Jahren noch gefährlicher werden wird. Dies deutet darauf hin, dass Unternehmen dringend ihre Strategien zur Stärkung der Widerstandsfähigkeit gegen Cyber-Angriffe weiterentwickeln, ihre Datenwiederherstellungsfähigkeiten verbessern und proaktivere Maßnahmen ergreifen müssen, um die Fortführung des Geschäftsbetriebs angesichts zunehmender Cyber-Bedrohungen zu gewährleisten.

Zusammenfassend betont der Bericht, wie wichtig es ist, sich nicht zu sehr auf vorhandene Resilienzstrategien zu verlassen, sondern konkrete Schritte zu unternehmen, um die Wiederherstellungszeiten zu verbessern, die Abhängigkeit von Lösegeldzahlungen zu verringern und robustere Sicherheitsmaßnahmen zu ergreifen. Unternehmen müssen diese Schwachstellen angehen, um in der zunehmend feindlichen Cyber-Umgebung des Jahres 2024 überleben zu können.

Den vollständigen Bericht finden Sie hier: Globaler Bericht zur Cyber-Resilienz 2024 von Cohesity

Wir klären über die Begriffe der IT-Sicherheit auf

Patrik Jezierski — Thu, 16 Jul 2026 08:00:20 GMT

Rücken Sie Qualität in den Fokus

Unser Ziel ist klar: Unternehmen sollen digitale Produkte schnell liefern können, ohne Abstriche bei Qualität und Innovation. Mit Branchenexpertise, moderner Technologie und konsequenter QS senken wir Risiken, optimieren Kosten und schaffen Vertrauen über alle Phasen des Produktlebenszyklus hinweg.

Angetrieben von diesem Grundsatz sowie auf unserer mehr als 25-jährigen Erfahrung in Sachen Softwaretests und Qualitätssicherung, stellen wir Ihnen die Kompetenzen, das Fachwissen und Anleitungen bereit, die Sie für alle Phasen Ihrer Softwareentwicklung benötigen – von den Anforderungen bis hin zur Bereitstellung. Indem wir dem technologischen Fortschritt, den Branchentrends und den Unternehmensstrategien immer einen Schritt voraus sind, stellen wir proaktiv sicher, dass Ihre Software, Systeme und Anwendungen die Erwartungen der Benutzer nicht nur erfüllen, sondern übertreffen.

Unterschiede zwischen einer SAP-Migration und einer Standardmigration

QESTIT Team — Thu, 16 Jul 2026 08:00:17 GMT

Unternehmen migrieren ihre Systeme häufig, um ihre IT-Infrastruktur zu modernisieren und so strategische Vorteile zu erzielen. Ältere Systeme werden im Laufe der Zeit schwerer zu verwalten und behindern die Skalierbarkeit. Neue Plattformen dagegen ermöglichen den Einsatz fortschrittlicher Technologien wie KI und moderner Benutzeroberflächen, die die Produktivität steigern und fundierte Entscheidungen erleichtern.

12 Merkmale guter, automatisierter Tests

Viktor Laszlo — Thu, 16 Jul 2026 07:59:24 GMT

Es gibt mehrere Gründe für das Schreiben automatisierter Tests, was zum Teil relativ einfach erscheinen mag. Das Schreiben „guter“ automatisierter Tests ist jedoch wesentlich schwieriger und erfordert umfangreiche Erfahrung und bewusstes Training.

In diesem Beitrag habe ich einige (hochrangige) Ziele zusammengestellt, die überprüft werden müssen, damit die automatisierten Tests gut werden. Die Ziele sind in zwölf Merkmalen definiert, und wenn sie erfüllt sind, ist die Definition von „guten“ automatisierten Tests erreicht.

Hier sind einige übergeordnete Ziele, die zutreffen könnten:

Tests sollten uns helfen, die Qualität zu verbessern.
Tests sollten uns helfen, das System zu verstehen.
Tests sollten das Risiko reduzieren (nicht erhöhen).
Tests sollten leicht durchführbar sein.
Tests sollten einfach zu schreiben und zu warten sein.
Tests sollten minimale Wartung erfordern, wenn sich das System um sie herum weiterentwickelt.

Tests sollten uns helfen, die Qualität zu verbessern

1. Test als Spezifikation

Wenn Sie testgetriebene Entwicklung (TDD – test-driven development) oder verhaltensgetriebene Entwicklung (BDD – behavior-driven development) verwenden, können Sie mit Hilfe von Tests erfassen, was das System tun wird, bevor Sie mit der Entwicklung beginnen. Das Durchdenken verschiedener Szenarien, um sie in Tests umzuwandeln, hilft uns, die Bereiche zu identifizieren, in denen die Anforderungen mehrdeutig oder widersprüchlich sind. Eine solche Analyse verdeutlicht das Ziel der Spezifikation, was zu einem genaueren Entwurf führt und die Qualität der Software verbessert.

2. Defektabwehr

Automatisierte Tests finden Fehler, aber das ist nicht der Hauptzweck der Testautomatisierung. Automatisierte Tests verhindern, dass Fehler eingeführt werden. Stellen Sie sich automatisierte Tests als Fehlerabwehr vor, die verhindern, dass Fehler in unsere Software zurückkommen, nachdem wir sichergestellt haben, dass sie fehlerfrei ist. Wenn wir gute und vollständige Regressionstests haben, wird es keine Fehler geben, weil die Tests die Fehler aufzeigen, bevor wir unseren Code überhaupt einchecken.

3. die Bezeichnung von Fehlern

Wenn die automatisierten Tests relativ klein sind (d. h. wir testen in jedem Test nur ein einziges Verhalten), können wir den Fehler schnell ausfindig machen, je nachdem, welcher Test fehlschlägt. Um dies zu erreichen, müssen wir Tests für alle möglichen Szenarien schreiben, um jede Einheit der Software abzudecken. Die Tests dürfen niemals Mehrdeutigkeiten enthalten. Daher ist es wichtig, die Tests so klein und trivial wie möglich zu halten (geringe Komplexität, konsistentes Format und Prüfung eines einzigen Verhaltens in jedem Test).

Tests sollten uns helfen, das System zu verstehen.

4. Tests als Dokumentation

Automatisierte Tests können klar aufzeigen, wie der Code funktionieren sollte. Sie zeigen, was das Ergebnis sein sollte (sie geben das erwartete Ergebnis einer oder mehrerer Anweisungen an).

Wenn wir wissen wollen, wie das System etwas tut, können wir den Debugger starten, den Test ausführen und den Code Schritt für Schritt durchgehen, um zu sehen, wie er funktioniert. Die Unit-Tests fungieren als eine Art Dokumentation für das System.

Tests sollten das Risiko verringern (nicht erhöhen)

5. Tests als Sicherheitsnetz

Älteren Code zu ändern ist riskant, weil wir oft nicht wissen, was wir kaputt machen könnten, und es ist auch schwer zu wissen, ob wir etwas kaputt gemacht haben! Wir müssen sehr langsam und sorgfältig arbeiten und viele manuelle Analysen durchführen, bevor wir Änderungen vornehmen.

Wenn wir jedoch mit Code arbeiten, der über eine automatisierte Testsuite verfügt, können wir viel schneller arbeiten. Die Tests fangen unerwartete Nebeneffekte von Änderungen auf und lassen uns wissen, ob wir etwas kaputt gemacht haben. Auf diese Weise wirken die automatischen Tests wie ein Sicherheitsnetz, das uns dazu bringt, Risiken einzugehen.

6. Kein Testrisiko

Wir müssen darauf achten, dass wir durch automatisierte Tests keine neuen Arten von Problemen in das System einführen. Halten Sie den Testcode vom Produktionscode getrennt, um zu vermeiden, dass testspezifische Abhängigkeiten im System entstehen (besonders wichtig für Unit-Test-Code). Der gesamte testbezogene Code und die Bibliotheken sollten ausschließlich im Test-Build und in der Testumgebung integriert werden. Testabhängigkeiten und Testcode dürfen im endgültigen Produktionscode niemals enthalten sein.

Tests sollten einfach auszuführen sein

Es gibt vier spezifische Merkmale, die die Ausführung automatisierter Tests erleichtern. Mit diesen vier Merkmalen können Sie einfach auf eine Schaltfläche klicken (oder besser noch automatisch auslösen), um das wertvolle Feedback zu erhalten, das die Tests liefern:

Die Tests müssen vollständig automatisiert sein, so dass sie ohne Aufwand ausgeführt werden können.
Die Tests müssen selbstauswertend sein, so dass sie Fehler ohne manuelle Überprüfung erkennen und melden können.
Die Tests müssen wiederholbar sein, damit sie mehrfach mit den gleichen Ergebnissen durchgeführt werden können.
Jeder Test sollte unabhängig sein, so dass er für sich selbst laufen kann.

7. Vollständig automatisierte Tests

Ein Test, der ohne jeden manuellen Eingriff durchgeführt werden kann, ist ein vollautomatischer Test. Die Erfüllung dieses Merkmals ist eine Voraussetzung für die Erfüllung der anderen.

8. Selbsteinschätzung

Ein Test mit Selbsteinschätzung kann alles kodieren, was der Test braucht, um zu überprüfen, ob das erwartete Ergebnis korrekt ist. Der Test benachrichtigt uns nur, wenn das Ergebnis nicht genehmigt wurde; folglich erfordert ein sauberer Testlauf keinerlei manuellen Aufwand.

9. Wiederholbare Tests

Ein wiederholbarer Test kann immer wieder durchgeführt werden und liefert immer noch genau die gleichen Ergebnisse, ohne dass ein menschliches Eingreifen oder eine Analyse zwischen den Durchläufen erforderlich ist.

Tests sollten einfach zu schreiben und zu pflegen sein

Wenn wir das Verhalten in einem Teil eines Systems ändern, sollten wir erwarten, dass eine kleine Anzahl von Tests von unseren Änderungen betroffen sind. Einer der Vorteile der Testautomatisierung ist die einfache Durchführung von Änderungen. Wir sollten daher stets darauf achten, dass unsere Tests nicht das Gegenteil bewirken (Änderungen erschweren). Tests sollten nur minimale Wartung erfordern, wenn sich das System um sie herum weiterentwickelt.

10. Einfache Tests

Das Hauptaugenmerk sollte auf den Tests liegen und nicht darauf, wie man sie programmiert. Das bedeutet, dass die Tests einfach/trivial sein müssen (einfach zu lesen, einfach zu schreiben und einfach zu warten). Wir sollten uns bemühen, eine Bedingung pro Test zu überprüfen, indem wir für jede einzigartige Kombination von Bedingungen eine eigene Testmethode erstellen. Jede Testmethode sollte das System über einen einzigen Pfad im System testen.

11. Aussagekräftige Tests

Eine Bibliothek von Hilfsmethoden, die eine domänenspezifische Testsprache aufbaut, ermöglicht es der Person, die den Testcode schreibt, die Konzepte auszudrücken, die sie testen möchte, ohne ihre Gedanken in viel detaillierteren Code übersetzen zu müssen.

12. Trennen Sie die Probleme

Halten Sie den Testcode vom Produktionscode getrennt (behalten Sie die Struktur und Logik des Produktionscodes bei, aber in einer parallelen Struktur). Jeder Test sollte sich auf ein einziges Problem konzentrieren, um komplizierte und unklare Tests zu vermeiden.

Zusammenfassung

Es gibt einen Unterschied zwischen einem Test und einem guten Test, aber es ist oft schwierig zu wissen, wie man einen „guten“ Test definiert. In dieser Checkliste habe ich 12 Merkmale für gute Testautomatisierungspraktiken aufgezeigt, die wiederum zu einfach zu schreibenden Tests und angemessener Wartung führen - beides Faktoren, die für ein System sehr wichtig sind.

Was sollten Sie nicht automatisieren?

Viktor Laszlo — Thu, 16 Jul 2026 07:59:20 GMT

Wenn wir automatisierte Tests schreiben, wollen wir mit möglichst geringen Kosten oder Zeitaufwand einen maximalen Mehrwert schaffen. Die Gesamtzahl der Testfälle, um zu überprüfen, ob ein großes, modernes, komplexes System fehlerfrei ist, ist nahezu unendlich. „Alles“ kann nicht automatisiert werden. In diesem Beitrag sehen wir uns genauer an, was nicht automatisiert werden kann/sollte und warum.

Wir müssen strategisch denken, um eine begrenzte Anzahl von Tests auszuwählen, die automatisiert werden sollen. Diese Tests sollten einen möglichst großen Teil des Systems abdecken, einfach zu implementieren, stabil und zuverlässig und kostengünstig zu ändern und zu warten sein.

Bei der Testautomatisierung geht es darum, Teile der Testarbeit zu rationalisieren, zumindest die Teile, die am besten geeignet sind. Daher gibt es einige Kategorien von Tests, die wir nicht automatisieren sollten.

Tests, die Intelligenz und Emotionen erfordern

Einem Computer fehlt es völlig an Intelligenz, Geschmack, Geschmack und Gefühl. Daher ist es nicht möglich, gute, automatisierte Tests zu erstellen, um Dinge wie die folgenden zu bewerten:

Ist das Layout lehrreich?
Ist die Benutzererfahrung angenehm?
Ist die Verwendung der Anwendung ergonomisch?
Ist die Verwendung des Systems leicht verständlich?

Ist die Benutzeroberfläche optisch ansprechend?

Verschwenden Sie keine Zeit und Energie damit, auch nur Teile dieser Aspekte zu überprüfen. Einem Computer fehlt die Fähigkeit, diese Aspekte zu bewerten. Die Tests werden komplex und unzuverlässig und können, selbst theoretisch, nur einen vernachlässigbaren Bruchteil dessen überprüfen, was wir wünschen.

Anwendungen, die noch nicht stabil sind
(zu früh im Lebenszyklus)

Tests, die über die grafische Benutzeroberfläche (GUI) mit der Anwendung interagieren, reagieren sehr empfindlich auf Änderungen. Scheinbar kleine Änderungen an der Benutzeroberfläche der Anwendung führen dazu, dass die Tests nicht mehr funktionieren. Daher ist es keine gute Idee, Tests für eine Anwendung zu automatisieren, die noch nicht stabil ist. Die Tatsache, dass sie nicht stabil ist, bedeutet, dass sie geändert, modifiziert oder repariert wird, was dazu führt, dass die Tests nicht mehr funktionieren.

Tests, die über die grafische Benutzeroberfläche mit der Anwendung interagieren, sind im Vergleich zu anderen Arten automatisierter Tests komplex, umfangreich, zeitaufwändig und schwer zu ändern. Daher ist es eine gute Idee, mit der Implementierung dieser Art von Tests zu warten, bis sich das System stabilisiert hat und keine störenden Änderungen mehr zu erwarten sind.

Anwendungen, die das Tool nur schwer unterstützt (API, GUI)

Manchmal stoßen wir auf Komponenten oder Teile eines Systems, für die sich automatisierte Tests nur sehr schwer implementieren lassen. Dies kann verschiedene Gründe haben. Ein Beispiel ist die Sicherheit, bei der es darum geht, Bots oder unerwünschte automatisierte Manipulationen zu vermeiden. Ein weiteres Beispiel sind proprietäre Komponenten, bei denen die Implementierungsdetails unbekannt oder geheim sind.

Die Implementierung kreativer (oft komplexer) Lösungen zur Umgehung des Problems ist auf lange Sicht normalerweise eine schlechte Idee. Die Tests werden unvorhersehbar und komplex. Verbringen Sie also nicht übermäßig viel Zeit damit, sich mit Tests in fast unmöglichen Situationen herumzuschlagen, in denen die Ergebnisse schlecht ausfallen werden.

Verbringen Sie stattdessen Zeit und Energie damit, automatisierte Tests zu implementieren, wo dies einfach und erfolgreich ist. Was Nutzen und Wert bietet, sind Tests, die schnell ausgeführt werden, zuverlässig, robust und einfach zu ändern und zu warten sind.

Testfälle, die manuell nicht gut gelaufen sind

Wenn wir Tests haben, die bei manueller Ausführung nicht gut gelaufen sind, bedeutet das, dass die Anwendung noch nicht wirklich stabil ist. Scheinbar kleine Änderungen an der Benutzeroberfläche der Anwendung führen dazu, dass die Tests nicht mehr funktionieren. Daher ist es keine gute Idee, automatische Tests über die grafische Benutzeroberfläche (GUI) für eine Anwendung durchzuführen, bei der die manuellen Tests nicht gut gelaufen sind.

Andererseits gilt dies nicht für automatisierte Tests über eine API (z. B. WebServices wie REST oder SOAP). Denn automatisierte Tests über API sind im Vergleich zu automatisierten Tests über GUI vergleichsweise trivial, kurz und schnell zu implementieren und leicht zu ändern.

Wenn wir das System früh im Entwicklungszyklus über API testen können, ist es eine gute Idee, auf dieser Ebene mit der Durchführung umfassender Tests zu beginnen. Wenn das System begonnen hat, sich zu stabilisieren und keine revolutionären Änderungen mehr zu erwarten sind, ist es sehr erfolgreich, eine kleinere Anzahl automatisierter Tests über die grafische Benutzeroberfläche der Anwendung hinzuzufügen.

Informationen zur Funktionsweise des Systems und Unterstützung für den Testautomatisierungsingenieur fehlen

Der erfolgreichste Weg besteht darin, die automatisierten Tests parallel zur Implementierung des Systems durchzuführen. Die automatisierten Tests sollten auf einem möglichst niedrigen Testautomatisierungsniveau (Geräteebene, API-Ebene, GUI-Ebene) erfolgen, um Defekte so nah wie möglich an der Quelle (wo sie auftreten) zu erkennen.

Die Testautomatisierung auf GUI-Ebene erfolgt relativ spät in der Entwicklungskette. Wir möchten, dass sich die Entwicklung des Systems stabilisiert hat und keine radikalen Änderungen oder Neugestaltungen erwartet werden. Dies liegt, wie oben erwähnt, an der Komplexität und Größe dieser Tests sowie an den Kosten und der Zeit für Änderungen und Wartung.

Es ist wichtig, dass diejenigen, die die automatisierten Tests schreiben, wissen, wie das System im Detail funktionieren soll. Wenn das Wissen fehlt und das Team, die Organisation oder jemand anderes diese Informationen nicht vermitteln kann, wird es sehr schwierig sein, aussagekräftige automatisierte Tests zu erstellen.

New > Blogs

Geht Testleiter remote? 3 Tipps zum Aufbau von Vertrauen

Um Vertrauen zu gewinnen, müssen Sie Vertrauen geben.

Sorgen Sie immer für einen Informationsfluss.

Zeigen Sie Führungsstärke.

Im Gespräch mit Bouzid, SAP-Consultant

Ein Interview mit Bouzid Belmahdi über seine Rolle, Herausforderungen und Erfolge als SAP-Consultant bei QESTIT.

Im Gespräch mit Andreas, Recruiter

Ein Interview mit Andreas Barthel,Recruiter bei QESTIT.

IT-Sicherheit bei SAAS-Lösungen – das gilt es zu beachten

3 wichtige Dinge, die Sie vor dem Kauf einer SaaS-Lösung bedenken sollten

Zusammenfassung

Die häufigsten Probleme, die wir in der IT-Sicherheit sehen

Schlechte Passwörter

Fehlende starke SSL-Implementierung

Benutzeraufzählung

XSS/HTML/SQL-Injection

Uneingeschränkter Dateiupload

Defekte Zugriffskontrollen (Sicherheit durch Verschleierung)

Schwache Benutzer-/Gruppensegmentierung (Least Privilege Practice)

Schlechtes Patch-Management / End-of-Life-Management

Schwache Netzwerk-/Datenbanksegmentierung

Der dringende Bedarf an Cyber-Resilienz

Wir klären über die Begriffe der IT-Sicherheit auf

Rücken Sie Qualität in den Fokus

Unterschiede zwischen einer SAP-Migration und einer Standardmigration

12 Merkmale guter, automatisierter Tests

Tests sollten uns helfen, die Qualität zu verbessern

Tests sollten uns helfen, das System zu verstehen.

Tests sollten das Risiko verringern (nicht erhöhen)

Tests sollten einfach auszuführen sein

Tests sollten einfach zu schreiben und zu pflegen sein

Zusammenfassung

Was sollten Sie nicht automatisieren?

Tests, die Intelligenz und Emotionen erfordern

Ist die Benutzeroberfläche optisch ansprechend?

Anwendungen, die noch nicht stabil sind(zu früh im Lebenszyklus)

Anwendungen, die das Tool nur schwer unterstützt (API, GUI)

Testfälle, die manuell nicht gut gelaufen sind

Informationen zur Funktionsweise des Systems und Unterstützung für den Testautomatisierungsingenieur fehlen

Anwendungen, die noch nicht stabil sind
(zu früh im Lebenszyklus)