23. TAV

Beschreibung

An industrial Perspective on Model Based Testing

Andreas Ulrich
Siemens AG Corporate Technology - Software & Engineering 1

The presentation gives an overview of the current practice in software development projects in industry and discusses the problems that formal and model-based testing techniques face when they are attempted in an industrial setting. One of the main observations is that software is developed in evolutionary steps. Software is seldom developed from scratch and is never a one-time solution. Instead it evolves in increments and product versions. As a consequence of the iterative development, automated test execution must be supported to deal with the validation of daily builds and small releases. In this context, the selection of the right set of regression test cases and the definition of suitable test stop criteria become essential. Both issues are typically answered by experience taking into account the number and distribution of bugs discovered in earlier iterations and releases and later test phases, but are rarely addressed in formal, model-based testing approaches.

Moreover, model-based techniques face further challenges if they are applied in the different development phases of requirement analysis, design and modelling, coding and system integration, and testing. First of all, requirements of a software product are typically incomplete, late, changing over development time, and even outdated. It is therefore very unlikely that a complete specification of the system can be made available for model-based testing. Graphical modelling languages, e.g. UML, if used, turn out to be frequently unproductive because of the complexity of related tools and scalability issues. Users get easily distracted from their original modelling task because they spend much time on getting the graphical layout of their model right. Another aspect relates to the configuration management of specifications using a graphical language. Comparing differences between two graphical models is not an easy task that complicates any tooling.

In the coding phase one is faced with the fact that most parts of the software product are reused from previous versions or come in from third-party components. For this reason, system integration and validation becomes the cornerstone of a successful product quality assurance. Due to the use of model-based design approaches, e.g. MDA, an increasing percentage of the production code is generated from a model automatically. This aspect has an influence on model-based testing approaches. It might be not desirable to derive tests from the same design model, for example, because they would simply test the correctness of the code generator. Instead, testing techniques should be applied that focuses on the integration of the generated code in its environment.

Last but not least, testing must not concentrate on functional aspects only. Usability aspects, performance and integration aspects must be considered as well. It is hard to see that any single formal test method can be used to handle all these different requirements together. Consequently, formal test methods should focus on a particular requirement domain, in which they can have their largest impact. In the end, the best gauge for any new method is the degree of productivity it helps to boost.

Secrets of Test Driven Development

Peter Zimmerer
Siemens AG Corporate Technology - Software & Engineering 1

Test-driven development (TDD) is a new approach for software construction in which developers write automated unit tests before writing the code. These automated tests are always rerun after any codes changes. Proponents assert that TDD delivers software that is easier to maintain and of higher quality than using traditional development approaches.

Based on experiences gained from real-world projects employing TDD, Peter Zimmerer shares his view of TDD’s advantages and disadvantages and how the TDD concept can be extended to all levels of testing. Learn how to use TDD practices that support preventive testing throughout development and result in new ways of cooperation between developers and testers.

Take away practical approaches and hints for introducing and practicing test-driven development in your organization.

Integration Testing - Looking for a Solution to Testing Concurrent Components and Systems

Andrej Pietschker
Siemens AG Corporate Technology - Software & Engineering 1

In integration testing we often face the problem of determining the verdict of a test run without having sufficient insight into the system. This problem is even more apparent in concurrent or embedded software because the traditional approach of using a debugger has limitations. Many developers create log statements to trace the program flow during development. This technology can be extended for use in integration testing.

However due to the large amount of data and the possibly complex behaviour of systems comprehending these traces can very difficult. We propose to use an automated approach to analysing system properties in traces. In this presentation we will motivate, and introduce two approaches to passive testing.

Special Track: Test eingebetteter Systeme Kopplung von Anforderungen und Tests: Überblick und Erfahrungen

TAV-Arbeitskreis "Test Eingebetteter Systeme"
Matthias Grochtmann, DaimlerChrysler Forschung und Technologie
Konrad Betz, beXtec Gesellschaft fuer Software-Entwicklung und -Beratung
Klaus Didrich, Siemens Rail Automation
Karoly Kiss, Siemens Med MR
Peter Wagner, Robert Bosch Corporate Sector Research and Advance Engineering

Basis für einen Black-box-Test eines Testobjekts sind die Anforderungen an das Testobjekt. Zwischen den Anforderungen und den Tests bestehen also semantische Beziehungen (zum Beispiel Anforderung X wird getestet durch Test Y).

Eine explizite Darstellung dieser Beziehungen ("Kopplung" - beispielsweise durch Verknüpfungen in einer Datenbank) verspricht Vorteile, zum Beispiel: - Nachweis der Vollständigkeit der Testabdeckung - Rückverfolgung von gefundenen Fehlern zu Anforderungen - Unterstützung beim Umgang mit Änderungen. Andererseits ist die Erfassung der Beziehungen und die Pflege der Kopplung aufwendig und bedingt einen methodischen Ansatz und Werkzeugunterstützung.

Im Vortrag werden ein Überblick über das Thema gegeben und konkrete Erfahrungen der Autoren mit der Kopplung von Anforderungen und Tests vorgestellt.

Testfallermittlung in der Systemtestpraxis

Harry Sneed
Anecon Software Design und Beratung G.m.b.H., Wien

In diesem Beitrag berichtet der Autor über seine Erfahrungen in der Systemtestpraxis.

Mitarbeitermotivation im Testteam - Lösungsansätze aus der Praxis

Harald Berning, Hans-Josef Eisenbach
EMPRISE Consulting Düsseldorf GmbH

Die Resonanz auf den Vortrag "kooperatives Testen" im Arbeitskreis Testmanagement auf der letzten TAV in Bremen animierte uns, unsere Erfahrungen bei der Motivation von Mitarbeitern in Testteams intensiver zu untersuchen. Diese umfangreichen Erfahrungen beruhen auf Projekteinsätzen als Team- bzw. Projektleiter in der Softwareentwicklung und bei der Abnahme von Software-Endprodukten. Unsere Projekteinsätze umfassen u. a. Hardware nahe Programmierung von Steuerungen, diverse teils umfangreiche Softwaresysteme zur Unterstützung der Bürokommunikation und die Abnahme von komplexen Abrechnungssystemen.

Jeder (Test-)Teamleiter muss gleichzeitig auch Motivator sein. Die Praxis hat aber gezeigt, dass die Motivation der Mitarbeiter nicht nur von den einzelnen Menschen abhängig ist, sondern auch von den unterschiedlichen Anforderungen an das Testen (während der Softwareentwicklung oder dem Abnahmetest von Endprodukten), von der Zusammensetzung der jeweiligen Testteams (Ausbildungsstand, Anteil der MA aus Fremdfirmen) und von den Randbedingungen der jeweiligen Projektsituation (Organisation, Termindruck).

Die von uns erlebten Erfahrungen mit oder durch diese Einflüsse gilt es, durch geeignete motivationstheoretische Modelle zu verdeutlichen. Das Ziel unseres Vortrags kann es nicht sein, einen allumfassenden Überblick über die Motivationstheorie zu geben. Wir wollen aber praxiserprobte Lösungsansätze als Anregung anbieten, um den Testprojektalltag angenehmer zu gestallten.

Warum Prüfen oft 50 mal länger dauert als Lesen ... ... und andere Überraschungen aus der Welt der Software-Reviews

Peter Rösler
Hermann-Gmeiner-Weg 12
81929 München 
ros(at)reviewtechnik.de
www.reviewtechnik.de

In Schulungen zu Software-Reviews steht der Trainer immer dann vor einer didaktischen Herausforderung, wenn es darum geht, die von Fachleuten genannten Zahlenangaben zu begründen, die von den Teilnehmern intuitiv in ganz anderer Größenordnung eingeschätzt werden.

Zwei dieser Zahlenangaben, die den Teilnehmern üblicherweise besonders unplausibel vorkommen, sind:

1. Die optimale Inspektionsrate für Textdokumente beträgt nur ca. 1 Seite pro Stunde (und liegt damit um ca. den Faktor 50 unter der reinen Lesegeschwindigkeit).
2. Das durchschnittliche Review findet nur ca. 5% der im Dokument vorhandenen Fehler.

Im Beitrag wird gezeigt, mit welchen Kurzexperimenten und Schätzungen, die von den Teilnehmern selbst durchgeführt werden, obige Zahlenangaben zumindest in der Größenordnung als durchaus plausibel dargestellt werden können.

Kurzvortrag und Verlosung: Fehlerkategorien für objektorientierte Software

Stefan Jungmayr
Arbeitskreis "Testen objekttorientierter Programme" (TOOP)

Bekanntgabe der Umfrageergebnisse zum Thema "Fehlerkategorien in objektorientierten Systemen" und Preisverlosung.

TAV-Arbeitskreis: Test Objektorientierter Programme (TOOP)

Das Ziel des seit Oktober 1995 bestehenden Arbeitskreises ist der Erfahrungsaustausch über Probleme und Lösungen beim Test (und Review) von objektorientierter und komponentbasierter Software in Industrie und Forschung.

Themenschwerpunkte im Arbeitskreis sind u.a.:

• Testbarkeit, Entwurf für Testbarkeit
• Reviews
• Test von Bibliotheken, Frameworks, Multi-Plattform Applikationen (CORBA...)
• Techniken für den Integrationstest von OO-Software
• Testmetriken und Testwerkzeuge
• OO-Testplan mit Methoden- und Werkzeugempfehlungen

In München werden die Ergebnisse der Online-Umfrage zu Fehlerhäufigkeiten in OO-Software sowie die Form der darauf basierenden Veröffentlichung diskutiert. In einem Kurzvortrag erläutert Mario Winter den momentanen Stand des ISTQB Certified Tester Expert Level Modul Proposals "Object Oriented Software Tester".

TAV-Arbeitskreis: Testmanagement

Der Arbeitskreis Testmanagement wurde im März 1995 gegründet und dient in erster Linie dem Erfahrungsaustausch der Teilnehmer über folgende Themenbereiche:

• Organisation von Testprozessen
• Methodische Unterstützung
• Einbettung in allgemeine QS-Aufgaben
• Rollen und Aufgaben im Testprozess
• Abgrenzung des Begriffs Testmanagement

Weitere Informationen zum Arbeitskreis Testmanagement finden Sie unter: www.caseconsult.com/tavtm

Alle Interessenten sind herzlich eingeladen, in unsere Diskussion einzusteigen. Eine Anmeldung zur Teilnahme an der Arbeitskreissitzung ist nicht erforderlich.

TAV-Arbeitskreis: Berufsbilder und Ausbildung im QS-Bereich

Das Ziel des Arbeitskreises "Berufsbild Software-Tester" ist es, eine einheitliche und für alle Beteiligten nachvollziehbare Ausbildung für den Software-Tester zu unterstützen, um die Qualität der Qualifikation sicherzustellen und damit auch insgesamt die Qualität der Software-Entwicklung zu verbessern.

Zur Zeit hat der AK  7 Kernmitglieder und weitere Interessierte. Ein Positionspapier  "Empfehlungen für das Berufsbild, die Ausbildung und die Qualifikationsstufen des Software- Tester" ist in den letzten Monaten erarbeitet worden und im Nov. 2004 in Petrasch, R. (Hrsg.): Schriften zum Software-Qualitätsmanagement. Analytische und konstruktive Qualitätssicherung in Theorie und Praxis. Reihe: Software-Qualitätsmanagement: Theorie & Praxis (herausgegeben von R. Petrasch), Band 3. Logos Verlag Berlin" erschienen.

Mitglieder des Arbeitskreises arbeiten aktiv bzw. gestalten eine einheitliche Zertifizierung von QM-Personal im Testbereich im nationalen und  europäischen bzw. internationalen Rahmen mit.  Entsprechende Seminare werden dazu von bekannten Trainingsanbietern angeboten den (siehe z.B. das Infoportal der IMBUS AG, die IMBUS-Seminarangebote und die SQS - Seminare).

Auch im Rahmen der TAV 22 wird die Möglichkeit angeboten (siehe Zeitplan) die Prüfung zum Certified Tester zu absolvieren.

Sprecher des Arbeitskreises ist Horst Pohlmann ( Horst.Pohlmann(at)german-testing-board.info ). Die HomePage des Arbeitskreises ist aktuell unter der folgenden URL erreichbar:www.softwarequality.de/Projects/GI/Tester/tester.html 

(Gespiegelt auf dem GI-Web-Server unter http://giserver.gi-ev.de/fachbereiche/softwaretechnik/tav/bb/st/index.htm )

TAV-Arbeitskreis: Test eingebetteter Systeme

http://www.systematic-testing.de/tav

Anmeldung und weitere Informationen zum kommenden Treffen

Hotels

Im Tagungshotel, dem Novotel in München-Perlach, ist bis zum 17. Oktober 2005 ein Zimmerkontingent abrufbar:

Referenznummer: 171.652 (Siemens AG)

Stichwort: TAV

Preis EZ: 94 EUR/ÜF, DZ: 118 EUR/ÜF (inkl. MwSt)

Novotel München- Perlach

Rudolf-Vogel-Bogen 3

81739 München

Anfahrt

U-Bahnlinie und Bahnstation S 6 NEUPERLACH SUED U 5 NEUPERLACH SUED

Weitere Möglichkeiten sind

EZ im Golden Leaf Euro 95,-- (Siemensrabatt)
Direkt an U-/S-Bahn (Siemens-Nähe)

EZ im Hotel Mercure Euro 94,-- (Siemensrabatt)

EZ im Hotel Aigner, Ottobrunn Euro 90,-- 

Die Preise sind in dieser Nähe fast alle gleich. Bei etwas günstigeren Hotels würden noch Fahrtkosten dazukommen, dann wären die o.g. Hotels günstiger, zumal sie direkt an der Bahn liegen.

http://www.bayerischerhiasl.de/ 30 Euro (Toiletten auf dem Flur evtl. für die Studenten??) ist neu renoviert und schaut recht zünftig aus!

Suche nach ....

... weiteren Hotels in München

... Straßen in München usw.

(Über-)Nächstes Treffen

Bad Homburg

Anfang Juni 2006

Themenvorschläge werden wie immer auf dem kommenden Treffen gesammelt.

Abendveranstaltung

Das "Social Event" findet ab 19:30 Uhr in einem berühmten (dem berühmtesten?) Münchner Lokal statt:

Im Hofbräuhaus, Erkerzimmer/Bräustüberl!

Wir freuen uns auf ein leckeres Abendessen, rege (nicht nur fachliche!) Diskussionen, a' zünft'ge Moaß, und ... natürlich viel "Gaudi"!

Adresse und Anfahrt