Events

-- Since this post accompanies a talk in German, it is written in German, too.

Viele Entwicklungsteams stehen vor der Herausforderung, immer mehr Software in immer weniger Zeit testen zu müssen, weil erfolgreiche Software wächst und Release-Zyklen immer kürzer werden. Risikobasiertes Testen hilft hier, limitierte Testressourcen effektiv(er) und effizient(er) einzusetzen. Dieser Vortrag stellt risikoorientierte Analysen und Methoden vor, um Transparenz über Testfortschritt und -risiken zu schaffen, Tests zu beschleunigen und beschränkte Testressourcen effizient einzusetzen.

As software systems grow, so does the number of their tests. As a result, we increasingly often encounter test suites that run hours or days, which is painfully slow. To get fast feedback about new bugs despite slow tests, we can run a subset of all tests more frequently. If this subset is chosen well, these tests identify most bugs very quickly.

Because release cycles are getting shorter and shorter, development and test are often done in parallel. This is hard to align. In practice, this often causes test gaps, when untested changes are deployed in production. We will present both the research fundamentals and demo change-driven testing on our own software.

Many Teams must test more and more functionality in less and less time. Historically grown test suites are often not up to this challenge since they test too much and too little at the same time. Too much, since they contain redundant tests that post execution and maintenance costs but provide little value over similar tests. Too little since important functionality remains untested. In this talk, I present analysis techniques to uncover these problems in your own system.

Most errors in long-lived software occur in code areas that change a lot. To do things right, you have to make sure that no important changes go live untested. Test Gap analysis helps us to find untested changes.

Since this post accompanies a talk in German, it is written in German, too.

Um langfristig erfolgreich zu sein, müssen Softwaresysteme fortlaufend angepasst und weiterentwickelt werden. Qualität kommt dabei oft zu kurz, obwohl sie für die Zukunftssicherheit des Systems entscheidend ist. Wird die Migration in die Cloud funktionieren? Ist die Architektur für die Anbindung einer mobilen App gerüstet? Müssen Teile neu geschrieben werden? Oder gar das ganze System? Ein Softwareaudit hilft bei der Beantwortung dieser Fragen, indem es Transparenz bzgl. des aktuellen Qualitätsstands schafft. Damit wird es möglich, ein strukturiertes Vorgehen für die Zukunft abzuleiten.

Since this post accompanies a talk in German, it is written in German, too.

Quellcode zu kopieren und an anderer Stelle wieder einzufügen ist eine gängige Vorgehensweise in der Softwareentwicklung, die jedoch gravierende Nachteile haben kann. Erfahren Sie mehr über von Code-Klonen verursachte Probleme und wie Sie die Risiken duplizierten Codes für Ihr System reduzieren können.

Mit einem Software-System wächst auch die Anzahl automatisierter Tests. Wir sehen immer öfter Test-Suites, die Stunden oder Tage laufen. Das ist lähmend langsam. Um trotzdem sehr schnelles Feedback für die meisten neuen Fehler zu bekommen, kann man einen Teil der Tests häufiger ausführen. Wenn diese Teilmenge gut gewählt ist, findet sie einen Großteil der Fehler in sehr kurzer Zeit.

Die meisten Fehler treten bei langlebiger Software dort auf, wo viel geändert wird. Wer es richtig machen will, muss sicherstellen, dass keine wichtigen Änderungen ungetestet bleiben. Die Test-Gap-Analyse hilft uns ungetestete Änderungen zu finden.

-- Since this post accompanies a talk in German, it is written in German, too.

Wenn ein System wächst, wächst auch die Anzahl automatisierter Tests. Wir sehen immer öfter Test-Suiten, die Stunden oder Tage laufen. Das ist lähmend langsam. Wenn die Ausführung aller Tests zu lange dauert, kann man einen Teil der Tests häufiger auszuführen, um hierfür schneller Ergebnisse zu bekommen. Wenn diese Teilmenge gut gewählt ist, findet sie einen Großteil der Fehler in sehr kurzer Zeit. Die restlichen Tests können weiterhin im alten Rhytmus ausgeführt werden, um den Rest der Fehler zu finden. Damit erreichen wir, trotz langsamer Testsuite, sehr schnelles Feedback für die meisten neuen Fehler.