Letzte Änderung: 13. November 2005 M. Winter
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.
[Kurzpapier] [Folien]
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.
[Kurzpapier] [Folien]
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.
[Kurzpapier] [Folien]
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.
[Kurzpapier] [Folien]
Anecon Software Design und Beratung G.m.b.H., Wien
In diesem Beitrag berichtet der Autor über seine Erfahrungen in der Systemtestpraxis.
[Kurzpapier] [Folien]
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.
[Kurzpapier] [Folien]
Peter Rösler
Hermann-Gmeiner-Weg 12
81929 München
ros@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:
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.
[Kurzpapier] [Folien]
Stefan Jungmayr
Arbeitskreis "Testen objekttorientierter Programme" (TOOP)
Bekanntgabe der Umfrageergebnisse zum Thema "Fehlerkategorien in objektorientierten Systemen" und Preisverlosung.
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.:
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".
Der Arbeitskreis Testmanagement wurde im März 1995 gegründet und dient in erster Linie dem Erfahrungsaustausch der Teilnehmer über folgende Themenbereiche:
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.
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@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 )
http://www.systematic-testing.de/tav
Tagungsort
Novotel
München-Perlach
Rudolf-Vogel-Bogen 3
81739 München Perlach
FON: (+49)89/638000
FAX: (+49)89/6351309
MAIL: H0792@accor.com
Anmeldung bitte bis 01. November
2005 per eMail
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.
Bad Homburg
Anfang Juni 2006
Themenvorschläge werden wie immer auf dem kommenden Treffen gesammelt.
|
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"! |
 |
Achtung: die Veranstaltung des ASQF/iSQI fällt leider aus!
Prüfung zum ISTQB®-Certified-Tester
Sie haben die Möglichkeit, die Prüfung zum ISTQB®-Certified-Tester abzulegen - ausnahmsweise auch ohne vorher einen entsprechenden Kurs belegt zu haben. Es wird davon ausgegangen, dass sie als Testexperte sich bereits gut in der Testproblematik auskennen. Falls sie ihr Wissen (und die Fachbegriffe) vorab im Selbststudium auffrischen wollen, kann das Buch "Basiswissen Softwaretest - Aus- und Weiterbildung zum Certified Tester - Foundation Level nach ASQF-, ISEB- und ISTQB-Standard" empfohlen werden, welches exakt den Lehrstoff umfasst. Das Glossar im Buch ist auch die Grundlage bei den Fragen, d.h., dass u.a. das Wissen um diese Begriffe und Definitionen eine Voraussetzung zum erfolgreichen Ablegen der Prüfung ist.
Derzeit gibt es bereits ca. 1700 zertifizierte Tester in Deutschland (in Europa ca. 16.000). Mittlerweile haben sich sich mehr als 14 Länder dem International Software Testing QuaIifications Board (ISTQB) Certified Tester Schema angeschlossen.
"Auf dem britischen Arbeitsmarkt wird man inzwischen ohne das Zertifikat in der Regel gar nicht erst zu einem Vorstellungsgespräch als Softwaretester eingeladen." (Dot Graham, Vorwort Basiswissen Softwaretest).
Hinweise zu Inhalt und Umfang der Prüfungen finden sie unter:
Übersicht und Lehrplan Certified Tester - Advanced Level
Bei entsprechender Nachfrage ist auch möglich eine Teilprüfung ( Testmanager, Functional Tester oder Technical Tester ) zum Certified Tester - Advanced Level abzulegen. Vermerken sie also bitte in ihrer Anmeldung (s.U.), ob sie die Prüfung zum Foundation Level oder eine Teilprüfung zum Advanced Level ablegen möchten. Aber: Advanced Level Prüfungen können nur geschrieben werden, wenn zuvor die Foundation Level Prüfungen bestanden ist und wenn der Zulassungsantrag bei der ISQI eingegangen ist.
Preis: der reduzierte GI-Mitgliederpreis von 225,00 Euro anstelle der 250,00 Euro, und darauf nochmals einen einmaligen "Sonderrabatt" von 25,00 Euro, also 200,00 Euro zzgl. MWSt.
Die Prüfung findet statt, wenn sich mindestens 5 Personen anmelden.
Zeitpunkt:
Donnerstag, 17. November 2005, 16.00 - 17.30 Uhr
Verbindliche Anmeldung zur Prüfung bitte per eMail
iSQI
International Software Quality Institute
Wetterkreuz 19a
91058 Erlangen, Germany
Tel +49-9131-91910-0