Herbert Stauffer Beat Honegger Hanspeter Gisin

Größe: px
Ab Seite anzeigen:

Download "Herbert Stauffer Beat Honegger Hanspeter Gisin"

Transkript

1

2 Herbert Stauffer ist seit über 20 Jahren Projektleiter, Systemarchitekt und Dozent für Business Intelligence und Data Warehousing. Er ist seit 2008 Co-Leiter des TDWI-Roundtable in Zürich. Seine Arbeitsschwerpunkte sind Systemarchitektur und multidimensionale Datenmodelle sowie qualitative Themen wie Datenqualität und Testen. Beat Honegger ist Senior BI-Consultant und Partner bei der plus- IT AG in Winterthur. In allen seinen Tätigkeiten als Softwareentwickler, Testing-Consultant, CRM-Berater und seit 10 Jahren als BI- Consultant, Dozent und Instructor war und ist das Testen für ihn eine wichtige Grundlage für erfolgreiche Projekte. Hanspeter Gisin ist Projektleiter, Data-Warehouse-Designer und SAP BO Instructor und auch als Dozent tätig. Er entwickelt seit mehr als 20 Jahren maßgeschneiderte Business-Intelligence- Lösungen für diverse Kunden. Seine Tätigkeiten umfassen die gesamte Palette von der Aufnahme der Requirements über das Data-Warehouse-Design bis hin zur Reporterstellung.

3 Herbert Stauffer Beat Honegger Hanspeter Gisin Testen von Data-Warehouse- und Business-Intelligence-Systemen Vorgehen, Methoden und Konzepte Edition TDWI

4 Herbert Stauffer Beat Honegger Hanspeter Gisin Fachlektorat: Marcus Pilz, pilmar.com Lektorat: Christa Preisendanz Copy Editing: Ulla Zimpfer, Herrenberg Herstellung: Frank Heidt Satz: Reemers Publishing Services, Krefeld Umschlaggestaltung: Anna Diechtierow, Heidelberg Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, Paderborn Fachliche Beratung und Herausgabe von dpunkt.büchern in der Edition TDWI: Marcus Pilz Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. ISBN: Buch PDF epub Auflage 2013 Copyright 2013 dpunkt.verlag GmbH Wieblinger Weg Heidelberg Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen. Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen. Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen

5 v Vorwort Business Intelligence (BI) ist anders. Sowohl in den Projekten, der Systemarchitektur wie auch im Betrieb gibt es markante Unterschiede von analytischen Systemen gegenüber der Welt der klassischen Informatiklösungen. In BI-Systemen wird selten programmiert. Dafür wird parametrisiert und Datenbankabfragen werden visuell modelliert. Transaktionsorientierte Datenerfassungen sollten nie stattfinden, sondern es werden teils riesige Datasets aus den Quellsystemen gelesen 1. Referenzielle Integrität wird von BI-Entwicklern nicht angewendet. Mit guten Grund: Durch die unterschiedlichen Ladezeiten aus mehreren Systemen hat sich der Verzicht bewährt, da sonst einige Daten nicht geladen werden könnten. Wegen dieser Verschiedenartigkeit hat Gartner in einer Studie bereits vor einigen Jahren empfohlen, die verschiedenen Fähigkeiten, die für den Aufbau und Betrieb dieser Systeme notwendig sind, zusammenzufassen [Strange/Hostmann 2003]. Daraus sind die heute üblichen Business Intelligence Competence Center, kurz BICC, entstanden. Wenn es schon überall Unterschiede gibt, muss dies auch einen Einfluss auf die Testverfahren haben. So war unsere Annahme. Auch sind wir bei unseren Recherchen verschiedener Untersuchungen und der Auswertung unserer Praxiserfahrungen auf Unterschiede und Gemeinsamkeiten gestoßen. Es war das Ziel des Autorenteams, ein Buch zu schreiben, das Theorie und Praxis vereint. Dabei sind viele Erfahrungen und Beispiele aus unserer bisherigen Praxis eingeflossen. Zum Aufbau des Buches: Im ersten Kapitel (Einführung) werden ausführlich die Eigenheiten von BI-Systemen und des Testens von analytischen Systemen erklärt. Ergänzt wird dieses erste Kapitel durch Beispiele aus der Praxis, die auch die Problemfelder und Fallstricke aufzeigen. Außerdem wird erklärt, wieso vollständiges Testen nicht möglich ist und wie viele Prüfungen sinnvoll sind, gemessen an der Kritikalität des Systems. Darin enthalten sind Überlegungen zur Wirtschaftlichkeit des Testens. 1. Eine Ausnahme sind Simulations- und Planungssysteme. Hier findet eine Dateneingabe statt. Die erfassten Parameter und die Analysen werden anschließend persistent in der Datenbank gespeichert.

6 vi Vorwort In Kapitel 2 wird ein Referenzmodell vorgestellt, das den roten Faden durch alle weiteren Kapitel bildet. Verschiedene Normen, Standards und Projektmodelle werden auf Vollständigkeit überprüft und mit dem Referenzmodell verglichen. Das Referenzmodell kann umgekehrt auch als Vorgehensmodell angewandt werden. Verschiedene Verweise auf die folgenden Kapitel präzisieren das Modell. Somit ist es auch eine Art Dach über mehrere Normen und Vorgehensweisen, die nur einen Teilaspekt abbilden. In Kapitel 3 werden verschiedene gängige Normen und Standards erklärt und auf ihre Eignung für das Testen von Business-Intelligence-Systemen überprüft. Das Kapitel bietet Hilfestellung, wenn in einer Unternehmung bereits ein oder mehrere dieser Normen eingesetzt werden, um diese in den richtigen Bezug zu Business-Intelligence-Projekten zu setzen und anzuwenden. In Kapitel 4 liegt der Schwerpunkt auf der Definition von geeigneten Testfällen (engl. Test Cases) und der Klassifizierung von Fehlern. Dieses Kapitel konzentriert sich fast ausschließlich auf die operative Testvorbereitung. Zum Bestimmen der notwendigen Testfälle haben wir ein eigenes Drei-Schritte-Vorgehen entwickelt. Anschließend werden die Inhalte der Testfälle definiert. Hier gibt es den ausführlichen Weg nach ISO 9126 oder FURPS (Functionality, Usability, Reliability, Performance und Supportability) oder das vereinfachte Verfahren mit Checklisten. Kapitel 5 beschäftigt sich eingehend mit der Bedeutung der Daten, insbesondere der Quelldaten. In diesem Kapitel geht es nochmals um die Definition von Testfällen. Diesmal aus der Sicht der Daten. Ergänzt wird das Kapitel um die Themen Datenqualität und Data Governance, die einen wichtigen Einfluss bei Business-Intelligence-Projekten haben. Das nachfolgende Kapitel 6 enthält einleitend eine Beschreibung der verschiedenen Arten von Systemlandschaften. Die einfachste Architektur besteht aus einem einzigen Server für Produktion, Entwicklung und Test. Dieses Modell ist zwar sehr übersichtlich und einfach zu verstehen. An die Implementierung von neuen Änderungen und Anforderungen werden jedoch hohe qualitative Anforderungen gestellt. Es gilt in jedem Fall, eine Produktionsstörung zu vermeiden. Demgegenüber steht eine hochkomplexe Architektur mit mehreren Entwicklungs- und Testsystemen, die hohe Anforderungen an das Testmanagement und die Projektleitung stellt. Gilt es doch, hier die Übersicht nicht zu verlieren. Anschließend gibt das Kapitel einen ausführlichen Überblick über die Durchführung der Testfälle und die Fehlerbehandlung in den verschiedenen Testlandschaften. Der Testmanager in diesem iterativen Prozess übernimmt dabei die Rolle eines Dispatchers. Ein weiterer wichtiger Aspekt des Testens sind die Testdaten. In der Praxis werden häufig bereits die vorhandenen Daten verwendet. Das ist als Leitgedanke ein guter Ansatz, doch es gibt ein paar spezielle Anforderungen an das Testen mit

7 Vorwort vii produktiven Daten, wie beispielsweise die Berücksichtigung der Datenschutzanforderungen, die unbedingt beachtet werden müssen. Neben den organisatorischen Anforderungen an den Testprozess spielt der Mensch eine wichtige Rolle. Unterschiedliche Charaktere reagieren anders. Persönliche Motive beeinflussen das Handeln. In Kapitel 7 behandeln wir die psychologische Seite des Testens. In Kapitel 8 werden die Projektmodelle auf ihre Anwendbarkeit für Business Intelligence überprüft. Wir unterscheiden die Projektmodelle nach ihren vier Hauptkategorien: Phasenmodelle, iterative Modelle, Prototyping und agile Projektmethoden. Je nach Methode hat Testen eine unterschiedliche Bedeutung. Bei den neueren, nicht linearen Projektmethoden stehen teilweise recht kurze Zeitfenster zum Testen zur Verfügung. Dies macht das Testen nicht einfacher. In Kapitel 9 sind speziellere Themen zu finden, die in diesem Buch zwar nicht abschließend behandelt werden, aber doch der Vollständigkeit halber aufgegriffen werden sollten und als Denkanstöße für die Praxis zu verstehen sind. Die einzelnen Themen stehen nicht in einem direkten Zusammenhang, vielmehr ergänzen sie die zuvor behandelten Themen. Zu Beginn des Kapitels werden Kategorien von Testtools definiert. Auf eine Bewertung der Tools haben wir bewusst verzichtet, da eine Bewertung nur eine Momentaufnahme der vorhandenen Releases sein kann. Schon in einem halben Jahr nach Veröffentlichung des Buches wäre die Liste nicht mehr aktuell. Kapitel 10 führt Testfälle auf, die wir den verschiedenen Komponenten einer Referenzarchitektur zugeordnet haben. Diese Sammlung ermöglicht einerseits die schnelle Definition von Testfällen und andererseits bildet sie die Basis für eine eigene Bibliothek von Testfällen. Kapitel 11 enthält vier Dokumentenvorlagen, die wir für eine minimale Testdokumentation in der Vorbereitung und während des Testbetriebs als notwendig erachten. Wie in jedem guten Fachbuch gibt es auch hier einen Anhang. Die Literaturund Linkliste gibt Informationen zur weiteren Vertiefung. Das ausführliche Glossar hilft die verschiedenen Begriffe nachzuschlagen. Für uns war es ein wichtiges Hilfsmittel beim Schreiben des Buches, da wir selbst im Alltag die Begriffe teilweise unterschiedlich verwendet haben. Oder wir hatten mehrere Begriffe für denselben Sachverhalt. Ein Stichwortverzeichnis rundet das Buch ab. Es ist nicht notwendig, das vorliegende Buch von Anfang bis Schluss durchzulesen. Es ist eher als Nachschlagewerk geeignet. Ein guter und wichtiger Einstiegspunkt ist dazu die Darstellung des Referenzmodells in Abbildung 2 1 auf S. 16.

8 viii Vorwort Ein Projektplan ohne Testphase Ein Industrieunternehmen ist dabei, eine neue Business-Intelligence-Plattform einzuführen. Damit soll eine einheitliche Lösung für Reports und Analysen zur Verfügung stehen. Verschiedene Auswertungen aus anderen Systemen sollen migriert werden. Einige Auswertungen haben strategische Bedeutung und unterstehen rechtlich den Regeln des IKS (internen Kontrollsystems) 2. Der zuständige Projektleiter hatte zwar einen Projektplan. Darin enthalten waren jedoch keine Aufwände für das Testen. Es war einzig ein zweiwöchiger Projektunterbruch geplant. Hier hatte er Tests durch Fachanwender vorgesehen, die am Ende die Ordnungsmäßigkeit der neuen Plattform bestätigen sollten. Der Projektleiter hatte nicht vorgesehen, entsprechende Testfälle zu definieren oder zumindest Rahmenbedingungen für die Tester zu liefern. Genauso wenig waren Aufwände für Fehlerkorrekturen vorgesehen. Obiges etwas überspitzt formulierte Beispiel zeigt auf, wie teilweise mit Tests in der Projektdurchführung umgegangen wird. Das ausschließliche Verlagern der Verantwortung auf die Endbenutzer zeigt das geringe Verständnis des Projektleiters für vollständiges Testens auf. Der ganze Projektplan benennt keine Tester, enthält keine Abnahmekriterien und keine Aufwände für Fehlerkorrekturen. Welche Tests sinnvoll sind und wie eine realistische Planung und Vorbereitung aussieht, wird in diesem Buch ausführlich beschrieben. Um die Theorie verständlicher zu vermitteln, haben wir grau hinterlegte Praxisbeispiele eingefügt. Die Beispiele wurden auf die wesentlichen Aspekte reduziert und anonymisiert. 2 Beim Schreiben des Buches war die einheitliche Verwendung der Begriffe eine weitere Herausforderung. Wir selbst haben festgestellt, dass im Alltag einige Begriffe mehrdeutig verwendet werden. Durch das Glossar am Ende des Buches haben wir für uns einige Begriffe vereinheitlicht. Ein weiteres Dilemma war, ob wir englische oder deutsche Bezeichnungen nutzen. Wir haben uns entschieden, die Bezeichnungen in nur einer Sprache zu verwenden, nämlich in Deutsch. Nur englische Fachbegriffe, die auch in der deutschen Sprache üblich sind, haben wir belassen, beispielsweise das Wort»Data Warehouse«. Uns ist bewusst, dass in der beruflichen Praxis teilweise die englischen Begriffe üblicher sind. Eine kurze Übersetzungsliste haben wir dazu im Anhang aufgeführt. 2. Die gesetzlichen Vorschriften für das Vorhandensein eines internen Kontrollsystems (IKS) sind in nationalen Gesetzen unterschiedlich geregelt. Üblicherweise ist die Geschäftsleitung in der Verantwortung, dass ein Kontrollsystem vorhanden ist, das alle Systeme und Prozesse überprüft, die für die finanzielle und strategische Führung der Unternehmung eingesetzt werden.

9 ix Inhaltsverzeichnis 1 Einführung Ungenügendes Testen ist leider Praxis Wirtschaftlichkeit des Testens Vollständiges Testen ist nicht möglich Gegenüberstellung von BI- mit klassischen Projekten Einfluss von Daten aufs Testen Die 7 Prinzipien des Testens Validieren und Verifizieren Was Testen nicht kann Referenzmodell für das Testen Drei Phasen des Testprozesses Organisation Ebene Testmanagement Ebene Testoperation Elemente Aktivitäten Menschen und Rollen Werkzeuge (Tools und Daten) und Hilfsmittel Im Dreiklang: Organisation, Elemente und Phasen »Würfel«in der Phase Planung »Würfel«in der Phase Durchführung »Würfel«in der Phase Abschluss

10 x Inhaltsverzeichnis 3 Methoden und Standards V-Modell IEEE IEEE 829 Software Test Documentation IEEE 1008 Unit Testing IEEE 1012 Software Verification and Validation Rational Unified Process (RUP) ISO ISO/IEC 9126 Qualitätsmerkmale ISO/IEC Cabinet Office ITIL 2011 Validation and Testing PRINCE ISACA COBIT CONCT Definition von geeigneten Testfällen und Fehlerkategorien Bestimmung von zu testenden Komponenten Schritt 1: Aufzeichnen des gesamten Systems Schritt 2: Kennzeichnen der Komponenten Schritt 3: Ableiten der Testfälle Zu prüfende Qualitätsmerkmale (nach ISO 9126) Funktionalität (engl. Functionality) Benutzbarkeit (engl. Usability) Zuverlässigkeit (engl. Reliability) Effizienz (engl. Efficiency) Wartbarkeit (engl. Maintainability) Übertragbarkeit (engl. Portability) Testmethoden und Testarten Statische Testverfahren Dynamische Testverfahren Gliederung der Testverfahren nach verschiedenen Kriterien Teststufen Definition und Beschreibung von Testfällen Vereinfachte Testfälle mithilfe von Checklisten Fehlerkategorien

11 Inhaltsverzeichnis xi 5 Einfluss der Daten aufs Testen Datengetriebene Testfälle als Schwerpunkt in Business Intelligence Datenqualität Validieren Datenqualität Verifizieren Funktionale Softwarequalität in Bezug zu den Daten Nicht funktionale Softwarequalität in Bezug zu den Daten Bedeutung von datengetriebenen Testfällen Datenqualität und Testen ein fließender Übergang Berücksichtigung der Data Governance Daten als Werte Daten als Eigentum (organisatorische Rollen) Hilfsmittel (Einsatz von Tools) Testorganisation, -infrastruktur und -betrieb Berücksichtigen der verschiedenen Systemumgebungen System-Landschaft Systeme-Landschaft Systeme-Landschaft Systeme-Landschaft Systeme-Landschaft Testdatenmanagement Definition von geeigneten Sets Anonymisieren und Verändern Berechtigungen Generieren von Testdaten Testen in Szenarios Vorbereiten des Testbetriebs Systeme bereitstellen Schulung der Tester (Test der Schulung) Minimales Kommunikationskonzept Testbetrieb Aufgaben des Testmanagements Iterativer Prozess auf der Ebene Testoperation Rolle des Dispatchers Auswirkung von neuen Versionen auf Testfälle

12 xii Inhaltsverzeichnis 6.6 Logs Testlog Fehlerlog Auswertungen und Reports Abschluss Schlussbericht Systeme bereinigen Lessons Learned Transfer Die menschliche Seite beim Testen Rollen im Testprozess Rollenkonflikt zwischen Softwareentwickler und Tester Rollenkonflikt zwischen Projektleiter und Testmanager Zwei Risikotypen des Auftraggebers in der Testphase Nachlassende Aufmerksamkeit bei Testern Wirtschaftlichkeit versus Ethik und Moral Testen nach Projektmodellen Phasenmodelle Iteratives Projektvorgehen Prototyping Agile Projektmethoden Sonderthemen Bewertung der verschiedenen Methoden und Standards Checkliste von vermeidbaren Fehlern im Testmanagement Einsatz von Softwaretools Kategorien Testautomatisierung Debugger Fehlernachverfolgung RACI-Matrix im Testprozess Session Based Testing Testen im Umfeld neuer Technologietrends Einsatz von spezialisierten Testteams

13 Inhaltsverzeichnis xiii 9.8 Zwei besonders zu beachtende Situationen Situation 1: Wenn das Testsystem zur Produktion light mutiert Situation 2: Korrekte Aufwandschätzung bei 1:1-Ablösung Die Aus- und Weiterbildung zum Certified Tester Bibliothek von Standardtestfällen Architekturmodell und Komponenten Standardtestfälle Generelle Testfälle Datenintegration und Schnittstellen zu den Datenquellen Datenspeicherung Informationsbereitstellung Plattform und Infrastruktur Externe Systeme und Prozesse Datengetriebene Testfälle Spezielle Projektsituationen Kontrollpunkte im Auditprozess Datenquellen und Schnittstellen Datenintegration Persistente Datenhaltung Informationsbereitstellung und Informationsempfänger Plattform Dokumentenvorlagen Testkonzept Testkonzept (Master Plan) Inhalt Einleitung Werkzeuge, Techniken, Methoden und Metriken Detailtestplanung Logs und Dokumente Testdurchführung Abschluss Anhang

14 xiv Inhaltsverzeichnis 11.2 Testfallspezifikation Testlog Fehlerlog Anhang Literaturliste Weblinks Begriffsübersetzung Englisch-Deutsch Glossar Nachweis der verwendeten Grafiken Index 251

15 1 1 Einführung»Debugging is twice as hard as writing the code in the first place. Therefore, if you write code as cleverly as possible, you are, by definition, not smart enough to debug it. «Brian Wilson Kernighan (kanadischer Informatiker und Koautor der Programmiersprache C) Das Zitat von Brian Kernighan klingt zwar witzig, doch es war durchaus ernst gemeint. Brian brachte in einem Satz auf den Punkt, dass an einen Tester hohe intellektuelle Anforderungen gestellt werden. Ein weiteres Zitat aus der Praxis stammt von einem Softwareentwickler in einer Lebensversicherung:»Ich habe noch anderes zu tun, als meinen Code zu testen.«eines seiner Module hatte gerade eine größere Produktionsstörung verursacht, nachdem er es ohne Abnahmeprozess und ungetestet im Produktionssystem implementiert hatte. Die notwendige Einsicht fehlte bei diesem Entwickler und führte zu seiner recht ungehaltenen Äußerung. Eine weitere Situation spielte sich einmal in einer Großbank ab. Es sollte ein Workshop mit einem erfahrenen Business-Analysten zur Definition von geeigneten Testfällen geplant werden. Ein großer Releasewechsel stand in den nächsten Monaten an und es waren noch keine Test- und Abnahmeverfahren definiert. Der erfahrene und ansonsten sehr kompetente Analyst lehnte das Meeting telefonisch ab mit den Worten:»Wieso soll ich mir die ganze Mühe für das Testen machen. Das Eröffnen eines Fehlers (engl. Defect) ist billiger.«gemeint hatte er, dass er bedeutend weniger Zeit für die Eröffnung eines Störungstickets benötigt als für die Definition und die Durchführung von Testfällen (engl. Test Cases). Ob die Behebung eines Fehlers in der Produktion wirklich billiger ist, hat er sich in dieser Situation sicher nicht überlegt. Diese drei Aussagen zeigen einige Eigenheiten des Testens auf: 1. Testen benötigt Intelligenz und Erfahrung. 2. Testen ist mühsam und unbeliebt. 3. Testen muss wirtschaftlich sein und bleiben. 4. Der Nutzen bzw. die Notwendigkeit ist den meisten nicht bewusst oder bekannt.

16 2 1 Einführung 1.1 Ungenügendes Testen ist leider Praxis Ungenügendes oder fehlendes Testen ist leider weit verbreitet. Nicht von ungefähr wird bei Softwarelösungen gerne der Begriff des»management by banana«verwendet. Gemeint ist»das Produkt beim Kunden reifen lassen«. Die Ursache liegt nicht in der bösen Absicht der Entwickler, sondern häufiger in deren Unwissenheit und Unerfahrenheit. Projektteams sind meistens bestens ausgebildet in den einzusetzenden Technologien, haben ein fachliches Grundwissen und sind geschult in den verschiedensten Projektmodellen. Selten verfügt aber nur ein einziges Mitglied über eine entsprechende Ausbildung im Testen. In vielen Fachbüchern zum Thema Data Warehousing und Business Intelligence ist zwar beschrieben, wie Systeme gebaut und später betrieben werden müssen. Aber selten enthält eines dieser Bücher ein Kapitel zum Testen. Sofern in einem Abschnitt das Testen erwähnt ist, wird es nur auf ein oder zwei Seiten behandelt. Im Verhältnis zu den mehreren Hundert Seiten einzelner Bücher ist dies auch eine klare Aussage zum Testverständnis der Autoren. Aufgrund des fehlenden Wissens wird mit dem Testen viel zu spät begonnen. Irgendwo am Ende einer Entwicklungsphase folgt in den meisten Projektplänen die Testphase, die nur als Vorgang definiert ist, der nicht weiter gegliedert ist. Dabei wird übersehen, dass ohne Testplanung leider keine effektive Testdurchführung stattfinden kann. Dies bedeutet, dass Testen schon viel früher in den Projekten zu beginnen hat. Idealerweise schon kurz nach dem Projektstart. Eine objektbezogene Planung ist heute in den meisten Projektvorgehensmodellen üblich für Analyse, Spezifikation und Realisierung. Das heißt, es wird für jeden Vorgang ein messbares Lieferergebnis als Output definiert. Oder, mit anderen Worten, jede Aktivität liefert am Ende ein bewertbares Resultat. Testen wird nur als Vorgang geplant, was meistens der Testdurchführung entspricht. Wenn die Testplanung fehlt, kann jedoch nichts Vernünftiges durchgeführt werden. Die Verantwortung für ungenügende Tests darf nicht allein dem Projektteam zugeschoben werden. Der Auftraggeber steht genauso in der Verantwortung, im Projektauftrag messbare Akzeptanzkriterien für die einzelnen Lieferobjekte und für das gesamte System zu definieren. Durch die fehlende Definition von Testfällen dient die Testphase in vielen Projektplänen nur noch als Puffer, um Zeit- oder Kostenüberschreitungen aus anderen Vorgängen aufzufangen. Durch die Verwendung der Testphase für andere Aufgaben werden der Projektplan, das Budget und der Einführungstermin eingehalten. Echte Tests werden nur wenig durchgeführt. Ein weiteres Problem besteht darin, dass Tests nur durch den Entwickler durchgeführt werden. Er prüft einzig, ob seine Module durchlaufen, ohne abzustürzen. Es existieren keine klar formulierten Testfälle und seine Prüfungen definiert er selbst. Das bedeutet, es werden nur minimale funktionale Modultests durchgeführt.

17 1.1 Ungenügendes Testen ist leider Praxis 3 Wenn Personen der Fachabteilungen in den Testprozess einbezogen werden, sind diese meistens ungenügend vorbereitet. Manchmal kennen sie nicht mal den Zweck des Systems, sondern erhalten einfach den Auftrag:»Das System steht auf dem Server XY bereit, macht mal in den nächsten zwei Wochen ein paar Tests.«Die Testpersonen sind damit überfordert und es finden im definierten Zeitraum gar keine Testaktivitäten statt. Um erfolgreich testen zu können, ist zuvor eine minimale Benutzerschulung notwendig und es müssen formulierte Testfälle vorhanden sein. Zusätzlich müssen die Tester frühzeitig informiert werden, damit sie die benötigte Zeit auch reservieren können. Eine Ursache für ungenügende Tests ist der Zeitdruck in Projekten. Das Reduzieren der Entwicklungsbudgets lässt eine Umsetzung manchmal nicht mehr zu oder führt zu mangelhafter Qualität. Daher wird jeder Projektleiter eine Testphase einplanen und das Budget dann anderweitig verwenden. Somit kann er zumindest die Funktionen zur Verfügung stellen. Wenn ungenügend getestet wird, gibt es auch keine zu korrigierenden Fehler. Somit erreicht er sein Ziel: die termingerechte Einführung des Systems. Die Folgen muss dann der Betriebsverantwortliche tragen. Er hat jede Menge Produktionsstörungen und muss sehen, wie er diese im Rahmen des im Service Level Agreement (SLA) vereinbarten Budgets behandeln kann. Der Projektleiter kümmert sich nicht mehr darum. Er hat eine unterzeichnete Projektabnahme und ist bereits an der Planung und Umsetzung seines nächsten Projekts. Der Umgang mit Fehlern (engl. Defects) ist in der Praxis ebenfalls oft ungenügend. Nicht in allen Projekten existieren Vereinbarungen zu Klassifikation von Fehlern und zur Projektabnahme. Die Fehler werden nicht zentral erfasst und die Lösung wird nicht protokolliert. Somit ist am Ende des Projekts nicht bekannt, welche Fehler mit welcher Gewichtung offen sind. Der Einsatz einer Softwarelösung zur Fehlernachverfolgung (engl. Defect-Tracking) würde hier die Arbeit erleichtern, beispielsweise das Open-Source-Tool Bugzilla. Des Weiteren enthalten einige Projektpläne kein Zeitfenster für das Korrigieren der Fehler und das erneute Testen, als ob Systeme nach den ersten Tests vollständig und perfekt wären. Eine weitere Unsitte ist das Korrigieren der Fehlerprioritäten. Fehler werden in tiefere Klassen eingeordnet, damit das System abgenommen werden kann. Dieses Herunterstufen (engl. Downgraden) von Fehlern nützt längerfristig niemandem. Man erhält dadurch ein System mit ungenügender Qualität. Die Liste von möglichen Ursachen für ungenügende Tests könnte beliebig fortgesetzt werden. Zusammenfassend kann gesagt werden, dass es sicher keine böse Absicht ist, ein ungenügendes System abliefern zu wollen. Meistens handelt es sich nur um fehlendes oder ungenügendes Testwissen. Dieses Buch möchte diese Wissenslücke schließen und insbesondere noch auf die Eigenheiten des Testens von analytischen Systemen, wie Business-Intelligence-Anwendungen und Data Warehouses, eingehen.

18 4 1 Einführung Ein offener Testfall in einer Großbank Als Tester war ich verantwortlich für die Verifikation eines geänderten Sourcing-Prozesses einer Shared Dimension. Im Testsystem blieb der geplante Ladeprozess längere Zeit unausgeführt und ein Testen war nicht möglich. An einem Abend, zwei Tage vor Ende der Testphase, rief mich der Chefentwickler an und fragte nach, wieso ich den Test nicht abnehme. Ohne meine Abnahme könne das Release nicht eingeführt werden. Das Release bestand aus mehreren Hundert Änderungen am gesamten Warehouse. Mein Einwand, dass der Ladeprozess noch nie ausgeführt wurde und ich somit keine Tests durchführen kann, interessierte ihn wenig. Seine Antwort war lapidar:»dann setz deine Testfälle einfache auf passed. Wir schauen uns das Ganze dann in der Produktion an. Alle anderen machen dies genauso.«hier musste ich zuerst einmal leer schlucken und tausend Gedanken gingen mir durch den Kopf. Einerseits wollte ich nicht der Verhinderer eines kommenden Release sein. Dies klingt nach Ärger und der späteren Suche nach Schuldigen. Andererseits wollte ich nicht Testfälle auf passed setzen, obwohl es nicht stimmte. Dies käme für mich einer vorsätzlichen Lüge gleich. Außerdem glaubte ich nicht daran, dass mir der Chefentwickler später in der Produktion die notwendige Unterstützung zur Behebung des Fehlers geben würde. Auch war ich über die Aussage entsetzt, dass es üblich sei, einfach Tests auf passed zu setzen. Ich entschied mich, bei meinen Prinzipien zu bleiben, und antwortete:»ich bin nur verantwortlich für die Testfälle und nicht für das gesamte Release. Solange ich die Tests nicht durchführen kann, werde ich sie offen lassen.«nun spürte der Chefentwickler den Druck, den er auf mich ausüben wollte. Er kümmerte sich um das Problem der nicht durchgeführten Ladeprozesse und er analysierte die Situation. Schlussendlich wurde festgestellt, dass sämtliche Einträge für das Scheduling der Jobs verloren gegangen waren. Die Ladeprozesse wurden deshalb nie ausgeführt. Noch in derselben Nacht liefen die Jobs erstmalig und fehlerfrei durch. Ein Tag vor Releasefreigabe konnte ich die Testfälle nun mit gutem Gewissen auf passed setzen. Zusammenfassend bedeutet dies, dass es nicht um ein erfolgreiches Testen ging, sondern nur um die Behauptung, dass getestet wurde. Ob es wirklich Praxis war, die Testfälle einfach auf passed zu setzen, habe ich nie herausgefunden. In diesem Fall hat es sich gelohnt, dem Druck nicht nachzugeben. Dieser Dimensionsladeprozess wäre wahrscheinlich nie korrekt gelaufen. 1.2 Wirtschaftlichkeit des Testens Testen muss wirtschaftlich sein. Abbildung 1 1 stellt schematisch die Folgekosten von Fehlern in der degressiven Kurve und die Kosten durch das Testen in der progressiven Kurve dar. Dies bedeutet, wenn nicht getestet wird, entstehen hohe Kosten durch Fehler. Einerseits sind dies direkte Kosten, die der Schaden des Fehlers verursacht. Andererseits sind es Kosten, die für die Suche und das Beseitigung des Fehlers notwendig sind. Über ein effektives Testen werden die Fehler und somit die Folgekosten reduziert. Doch auch das Testen verursacht Kosten. Wie die Kurven zeigen, stehen ab einem gewissen Punkt die Kosten des Testens in keinem Verhältnis mehr zum Nutzen.

19 1.2 Wirtschaftlichkeit des Testens 5 Effizientes Testen ist somit bis zum Schnittpunkt der beiden Kurven sinnvoll. Das Problem ist, dass nur bekannte Fehler quantifiziert werden können. Es bleibt somit immer ein Restrisiko, dass der eine nicht gefundene Fehler den Millionenschaden verursachen kann. Kosten Testkosten Fehlerkosten Gesamtkosten Zeit Gesamtkosten = Testkosten + Fehlerkosten Abb. 1 1 Wirtschaftlichkeit des Testens Ariane 5 ein kleiner Fehler mit einer großen Auswirkung Ein gutes Beispiel für die Auswirkungen eines einzelnen Fehlers ist die Ariane-5- Rakete, die am 5. Juni 1996 explodierte. Ursache war ein Fehler in einem ADA-Modul, das für die Regulierung der seitlichen Steuerraketen zuständig war. Eine 64-bit- Floatingpoint-Variable wurde dabei mit einer 16-bit-Integer-Variablen verglichen. Dies führte zu einem Overflow-Fehler und die Steuerung der Raketenflugbahn war nicht mehr möglich. Da Ariane 5 die Flugbahn verließ und unkontrolliert abzustürzen drohte, wurde sie automatisch, nach erst 40 Sekunden Flug, über dem Meer gesprengt, inklusive aller Forschungssatelliten. Die Bilder gingen damals um die Welt. Die Herstellungskosten nur für die Rakete und die Satelliten wurden mit 500 Mio. USD beziffert. Die spätere Untersuchung zeigte, dass die Entwicklung dieses ADA-Moduls auf einer fehlerhaften Spezifikation beruhte, die nie verifiziert wurde, und dass das Softwaremodul ungenügend getestet wurde.

20 6 1 Einführung 1.3 Vollständiges Testen ist nicht möglich Die Komplexität von heutigen Informatiksystemen lässt kein vollständiges Testen zu. Jede einzelne Funktion bietet mehrere Möglichkeiten. Werden Kombinationsmöglichkeiten aller Funktionen berechnet, indem alle Varianten der einzelnen Funktionen miteinander multipliziert werden, entsteht eine unwahrscheinlich hohe Zahl. Jede dieser Kombinationen zu testen, würde Jahre dauern. Bereits der zweite der sieben Grundsätze des Testens beschreibt diese Situation. 1 Bei der Testplanung ist eine Risikoabwägung notwendig zwischen dem Testaufwand auf der einen Seite und der Wahrscheinlichkeit und Auswirkung von unentdeckten Fehlern auf der anderen Seite. 1.4 Gegenüberstellung von BI- mit klassischen Projekten Bill Inmon, einer der Urväter des Data Warehouse, prägte vor Jahren folgenden Satz [Inmon 2005]:»Traditional projects start with requirements and end with data. Data Warehousing projects start with data and end with requirements.«damit wollte er sagen, dass in klassischen Projekten transaktionsbasierte Systeme entstehen, mit denen Informationen erfasst und in Datenbanken gespeichert werden. Ein typisches Beispiel ist ein System zur Pflege von Kundenstammdaten. Business-Intelligence-Projekte verwenden die existierenden Datenbanken, um Analysen in den verschiedensten Formen zu erstellen, sei es als Listen in Papierform, elektronisch als Führungscockpits, Risikoanalysen mittels Data Mining oder in weiteren Varianten. Wenn sich die Projekte schon stark unterscheiden, muss dies auch einen Einfluss auf das Testvorgehen haben. In Tabelle 1 1 haben wir die Projekte einander gegenübergestellt und Unterschiede herausgearbeitet. Business-Intelligence-Projekte haben wir noch folgendermaßen unterteilt: ETL (Extract, Transform and Load) Dies sind alle Prozeduren, die Daten aus den Quellsystemen lesen und in ein Data Warehouse oder eine andere Form von analytischem Datenspeicher schreiben. ETL-Prozesse sind auch für alle Transformationen und Übertragungen von Daten innerhalb des Data Warehouse zuständig, beispielsweise von der Staging Area ins definitive Modell. 1. Alle sieben Prinzipien des Testens sind in Abschnitt 1.6 beschrieben.

Testen von Data-Warehouse- und Business-Intelligence-Systemen

Testen von Data-Warehouse- und Business-Intelligence-Systemen Edition TDWI Testen von Data-Warehouse- und Business-Intelligence-Systemen Vorgehen, Methoden und Konzepte von Herbert Stauffer, Beat Honegger, Hanspeter Gisin 1. Auflage Testen von Data-Warehouse- und

Mehr

1.1 Ungenügendes Testen ist leider Praxis

1.1 Ungenügendes Testen ist leider Praxis 1»Debugging is twice as hard as writing the code in the first place. Therefore, if you write code as cleverly as possible, you are, by definition, not smart enough to debug it. «Brian Wilson Kernighan

Mehr

Dr. Michael Hahne www.dpunkt.de/plus

Dr. Michael Hahne www.dpunkt.de/plus Dr. Michael Hahne ist Geschäftsführender Gesellschafter der Hahne Consulting GmbH, einem auf Business-Intelligence-Architektur und -Strategie spezialisierten Beratungsunternehmen. Zuvor war er Vice President

Mehr

Dominik Schadow. Java-Web-Security. Sichere Webanwendungen mit Java entwickeln

Dominik Schadow. Java-Web-Security. Sichere Webanwendungen mit Java entwickeln Dominik Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickeln Dominik Schadow info@dominikschadow.de Lektorat: René Schönfeldt Copy-Editing: Friederike Daenecke, Zülpich Satz: Da-TeX, Leipzig

Mehr

Uwe Vigenschow Andrea Grass Alexandra Augstin Dr. Michael Hofmann www.dpunkt.de/plus

Uwe Vigenschow Andrea Grass Alexandra Augstin Dr. Michael Hofmann www.dpunkt.de/plus Uwe Vigenschow ist Abteilungsleiter bei Werum IT Solutions. In das Buch sind über 25 Jahre Erfahrung in der Softwareentwicklung als Entwickler, Berater, Projektleiter und Führungskraft eingeflossen. Mit

Mehr

Nicolai Josuttis. SOA in der Praxis. System-Design für verteilte Geschäftsprozesse

Nicolai Josuttis. SOA in der Praxis. System-Design für verteilte Geschäftsprozesse Nicolai Josuttis SOA in der Praxis System-Design für verteilte Geschäftsprozesse Nicolai Josuttis Website zum Buch http://www.soa-in-der-praxis.de Die englische Ausgabe erschien unter dem Titel»SOA in

Mehr

Basiswissen Software- Projektmanagement

Basiswissen Software- Projektmanagement Bernd Hindel. Klaus Hörmann. Markus Müller. Jürgen Schmied Basiswissen Software- Projektmanagement Aus- und Weiterbildung zum Certified Professional for Project Management nach isqi-standard 2., überarbeitete

Mehr

IT-Controlling für die Praxis

IT-Controlling für die Praxis Martin Kütz IT-Controlling für die Praxis Konzeption und Methoden 2., überarbeitete und erweiterte Auflage Martin Kütz kuetz.martin@tesycon.de Lektorat: Christa Preisendanz & Vanessa Wittmer Copy-Editing:

Mehr

Tom Gansor Dr. Andreas Totok www.dpunkt.de/plus

Tom Gansor Dr. Andreas Totok www.dpunkt.de/plus Tom Gansor ist als Mitglied der Geschäftsleitung bei der OPITZ CONSULTING Deutschland GmbH unter anderem für die Weiterentwicklung des Portfolios, für Innovation und die Lösungsentwicklung verantwortlich.

Mehr

Tilman Beitter Thomas Kärgel André Nähring Andreas Steil Sebastian Zielenski

Tilman Beitter Thomas Kärgel André Nähring Andreas Steil Sebastian Zielenski Tilman Beitter arbeitete mehrere Jahre als Softwareentwickler im ERP-Bereich und ist seit 2010 mit großer Begeisterung für die B1 Systems GmbH als Linux Consultant und Trainer unterwegs. Seine Themenschwerpunkte

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

Prof. Dr. Matthias Knoll

Prof. Dr. Matthias Knoll Prof. Dr. Matthias Knoll ist Professor für Betriebswirtschaftslehre an der Hochschule Darmstadt. Sein Spezialgebiet ist die betriebliche Informationsverarbeitung mit den Schwerpunkten GRC-Management, IT-Prüfung

Mehr

Praxisbuch BI Reporting

Praxisbuch BI Reporting Alexander Adam Bernd Schloemer Praxisbuch BI Reporting Schritt für Schritt zum perfekten Report mit BEx Tools und BusinessObjects Alexander Adam alexander.adam@googlemail.com Bernd Schloemer bernd.schloemer@googlemail.de

Mehr

Continuous Delivery. Der pragmatische Einstieg. von Eberhard Wolff. 1. Auflage. dpunkt.verlag 2014

Continuous Delivery. Der pragmatische Einstieg. von Eberhard Wolff. 1. Auflage. dpunkt.verlag 2014 Continuous Delivery Der pragmatische Einstieg von Eberhard Wolff 1. Auflage dpunkt.verlag 2014 Verlag C.H. Beck im Internet: www.beck.de ISBN 978 3 86490 208 6 Zu Leseprobe schnell und portofrei erhältlich

Mehr

VMware vrealize Automation Das Praxisbuch

VMware vrealize Automation Das Praxisbuch VMware vrealize Automation Das Praxisbuch Dr. Guido Söldner leitet den Geschäftsbereich Cloud Automation und Software Development bei der Söldner Consult GmbH in Nürnberg. Sein Unternehmen ist auf Virtualisierungsinfrastrukturen

Mehr

Basiswissen Software-Projektmanagement

Basiswissen Software-Projektmanagement isql-reihe Basiswissen Software-Projektmanagement Aus- und Weiterbildung zum Certified Professional for Project Management nach isqi-standard von Bernd Hindel, Klaus Hörmann, Markus Müller, Jürgen Schmied

Mehr

IT-Service-Management mit ITIL 2011 Edition

IT-Service-Management mit ITIL 2011 Edition Roland Böttcher IT-Service-Management mit ITIL 2011 Edition Einführung, Zusammenfassung und Übersicht der elementaren Empfehlungen 3., aktualisierte Auflage Heise Prof. Dr. Roland Böttcher roland.boettcher@hs-bochum.de

Mehr

Kennzahlen in der IT

Kennzahlen in der IT Kennzahlen in der IT Dr. Martin Kütz ist geschäftsführender Gesellschafter der TESYCON GMBH und Fachberater für IT-Controlling und Projektmanagement. Er verfügt über langjährige Erfahrungen im IT-Management

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Business Intelligence seit 1992 als

Business Intelligence seit 1992 als ing im BI-Umfeld Business Intelligence seit 1992 als (Senior) Consultant, Business Analyst Projekt Leiter, Teamleiter, BI Architekt Dozent HSLU Leiter TDWI Roundtable ZH seit 2009 Ausbildungen 1992 eidg.

Mehr

Basiswissen Softwaretest

Basiswissen Softwaretest Andreas Spillner. Tilo Linz Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard 3., überarbeitete und aktualisierte Auflage Andreas Spillner spillner@informatik.hs-bremen.de

Mehr

Basiswissen Softwaretest

Basiswissen Softwaretest Andreas Spillner Tilo Linz Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard 5., überarbeitete und aktualisierte Auflage Andreas Spillner andreas.spillner@hs-bremen.de

Mehr

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte DWH Projekt, Methodik, Stärken und Schwächen, Übersicht, Weg der Daten,

Mehr

Der Autor ist seit dem Jahr 2001 bei der Firma GeNUA mbh als Security Consultant und gegenwärtig als Koordinator für Intrusion Detection tätig.

Der Autor ist seit dem Jahr 2001 bei der Firma GeNUA mbh als Security Consultant und gegenwärtig als Koordinator für Intrusion Detection tätig. WLAN-Sicherheit Der Autor ist seit dem Jahr 2001 bei der Firma GeNUA mbh als Security Consultant und gegenwärtig als Koordinator für Intrusion Detection tätig. Seine Aufgabengebiete sind: Penetration Testing/Auditing

Mehr

er auch mit dem 3D-Programm Blender in Kontakt, über das er bisher zahlreiche Vorträge hielt und Artikel in Fachzeitschriften veröffentlichte.

er auch mit dem 3D-Programm Blender in Kontakt, über das er bisher zahlreiche Vorträge hielt und Artikel in Fachzeitschriften veröffentlichte. beschäftigt sich seit Beginn der 80er Jahre intensiv mit Computern und deren Programmierung anfangs mit einem VC-20 von Commodore sowie speziell mit Computergrafik. Der Amiga ermöglichte ihm dann die Erzeugung

Mehr

IT-Servicemanagement mit ITIL V3

IT-Servicemanagement mit ITIL V3 IT-Servicemanagement mit ITIL V3 Einführung, Zusammenfassung und Übersicht der elementaren Empfehlungen von Roland Böttcher 2., aktualisierte Auflage IT-Servicemanagement mit ITIL V3 Böttcher schnell und

Mehr

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11 xi 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Testprozess und Testwerkzeuge 11 2.1 Fundamentaler Testprozess.........................

Mehr

SQL Server 2005. Eine umfassende Einführung

SQL Server 2005. Eine umfassende Einführung SQL Server 2005 Eine umfassende Einführung E-Mail: petkovic@fh-rosenheim.de Lektorat: Barbara Lauer, Bonn Copy-Editing: Sandra Gottmann, Münster Satz: Just in Print, Bonn Herstellung: Birgit Bäuerlein

Mehr

Maik Schmidt www.dpunkt.de/plus

Maik Schmidt www.dpunkt.de/plus Maik Schmidt arbeitet seit beinahe 20 Jahren als Softwareentwickler für mittelständische und Großunternehmen. Er schreibt seit einigen Jahren Buchkritiken und Artikel für internationale Zeitschriften und

Mehr

Konfigurationsmanagement mit Subversion, Ant und Maven

Konfigurationsmanagement mit Subversion, Ant und Maven Gunther Popp Konfigurationsmanagement mit Subversion, Ant und Maven Grundlagen für Softwarearchitekten und Entwickler 2., aktualisierte Auflage Gunther Popp gpopp@km-buch.de Lektorat: René Schönfeldt Copy-Editing:

Mehr

Cloud-Computing für Unternehmen

Cloud-Computing für Unternehmen Gottfried Vossen Till Haselmann Thomas Hoeren Cloud-Computing für Unternehmen Technische, wirtschaftliche, rechtliche und organisatorische Aspekte Prof. Dr. Gottfried Vossen vossen@helios.uni-muenster.de

Mehr

Agile Testing. Der agile Weg zur Qualität. von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner. 1.

Agile Testing. Der agile Weg zur Qualität. von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner. 1. Agile Testing Der agile Weg zur Qualität von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner 1. Auflage Hanser München 2013 Verlag C.H. Beck im Internet: www.beck.de

Mehr

Agiles Produktmanagement mit Scrum

Agiles Produktmanagement mit Scrum Roman Pichler Agiles Produktmanagement mit Scrum Erfolgreich als Product Owner arbeiten 2., korrigierte Auflage Roman Pichler roman.pichler@romanpichler.com Lektorat: Christa Preisendanz Copy-Editing:

Mehr

IT-Servicemanagement mit ITIL V3

IT-Servicemanagement mit ITIL V3 Roland Böttcher IT-Servicemanagement mit ITIL V3 Einführung, Zusammenfassung und Übersicht der elementaren Empfehlungen Heise Roland Böttcher roland.boettcher@fh-bochum.de Lektorat: Dr. Michael Barabas

Mehr

Social Media Analytics & Monitoring

Social Media Analytics & Monitoring Andreas Werner Social Media Analytics & Monitoring Verfahren und Werkzeuge zur Optimierung des ROI Andreas Werner aw@datenonkel.com Lektorat: Dr. Michael Barabas Copy-Editing: Annette Schwarz, Ditzingen

Mehr

Datenqualität erfolgreich steuern

Datenqualität erfolgreich steuern Edition TDWI Datenqualität erfolgreich steuern Praxislösungen für Business-Intelligence-Projekte von Detlef Apel, Wolfgang Behme, Rüdiger Eberlein, Christian Merighi 3., überarbeitete und erweiterte Auflage

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Validierung und Verifikation!

Validierung und Verifikation! Martin Glinz Thomas Fritz Software Engineering Kapitel 7 Validierung und Verifikation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Tobias H. Strömer. Online-Recht. Juristische Probleme der Internet-Praxis erkennen und vermeiden. 4., vollständig überarbeitete Auflage

Tobias H. Strömer. Online-Recht. Juristische Probleme der Internet-Praxis erkennen und vermeiden. 4., vollständig überarbeitete Auflage Tobias H. Strömer Online-Recht Juristische Probleme der Internet-Praxis erkennen und vermeiden 4., vollständig überarbeitete Auflage Tobias H. Strömer E-Mail: anwalt@stroemer.de http://www.stroemer.de

Mehr

Uwe Vigenschow Andrea Grass Alexandra Augstin Dr. Michael Hofmann www.dpunkt.de/plus

Uwe Vigenschow Andrea Grass Alexandra Augstin Dr. Michael Hofmann www.dpunkt.de/plus Uwe Vigenschow ist Abteilungsleiter bei Werum IT Solutions. In das Buch sind über 25 Jahre Erfahrung in der Softwareentwicklung als Entwickler, Berater, Projektleiter und Führungskraft eingeflossen. Mit

Mehr

Andy Hunt. Programmieren lernen mit Minecraft-Plugins

Andy Hunt. Programmieren lernen mit Minecraft-Plugins Andy Hunt ist Autor bzw. Co-Autor von mehr als einem halben Dutzend Büchern rund um die Themen Pragmatic Programming und Agile. Er spricht regelmäßig und weltweit auf Entwicklerkonferenzen. Minecraft nutzt

Mehr

erfolgreich steuern Datenqualität rä dpunkt.verlag Ldwi Praxislösungen für Business-Intelligence-Projekte Rüdiger Eberlein Edition TDWI

erfolgreich steuern Datenqualität rä dpunkt.verlag Ldwi Praxislösungen für Business-Intelligence-Projekte Rüdiger Eberlein Edition TDWI Detlef Apel Wolfgang Behme Rüdiger Eberlein Christian Merighi Datenqualität erfolgreich steuern Praxislösungen für Business-Intelligence-Projekte 3., überarbeitete und erweiterte Auflage Edition TDWI rä

Mehr

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1 30.01.2011 Seite 1 This flyer is exclusively for the use of client personnel. No part of it may be distributed, quoted or reproduced outside the client organisation without the prior written approval of

Mehr

Peter Meier. Die Umsetzung von Risikomanagement nach ISO 31000. - Leseprobe -

Peter Meier. Die Umsetzung von Risikomanagement nach ISO 31000. - Leseprobe - Peter Meier Die Umsetzung von Risikomanagement nach ISO 31000 Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen

Mehr

Testen in KMU Projekten Bern, November 2013

Testen in KMU Projekten Bern, November 2013 Testen in KMU Projekten Bern, November 2013 Beraterprofil Stephan Wiesner Beratungsschwerpunkte Beratungsschwerpunkte Testmanagement Testautomation Entwicklung und Testen im Mobile-Umfeld Applikationsschwerpunkte

Mehr

Testkonzept. Tipp-Star

Testkonzept. Tipp-Star Tipp-Star Version: V1.0-27.09.2015 Ablageort: Tipp-Star/01_Projektmanagement/03_Test Status: Fertig gestellt (In Bearbeitung / fertig gestellt / geprüft / freigegeben) Anzahl Seiten: 9 Autoren: tse Sergeyeva

Mehr

Leitfaden Web-Usability

Leitfaden Web-Usability Frank Puscher Leitfaden Web-Usability Strategien, Werkzeuge und Tipps für mehr Benutzerfreundlichkeit Lektorat: Barbara Lauer Copy-Editing: Alexander Reischert Satz: Frank Heidt Herstellung: Frank Heidt

Mehr

Basiswissen Softwaretest

Basiswissen Softwaretest Andreas Spillner Tilo Linz Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard 3., überarbeitete und aktualisierte Auflage I Technische l'^vrau«! D~w.-iE*arit

Mehr

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Einführung von Testautomatisierung reflektiert Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Matt Young Leiter Test Acquiring Inhaltsverzeichnis Einleitung Testautomatisierung PostFinance

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen

Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen Henning Wolf (Hrsg.) Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen Erfahrungsberichte aus der Praxis Henning Wolf henning.wolf@it-agile.de Lektorat: Christa Preisendanz Copy-Editing:

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,

Mehr

Nach Data Warehousing kommt Business Intelligence

Nach Data Warehousing kommt Business Intelligence Nach Data Warehousing kommt Business Intelligence Andrea Kennel Trivadis AG Glattbrugg, Schweiz Schlüsselworte: Business Intelligence, Data Warehouse Zusammenfassung Data Warehouse bedeutet, dass operative

Mehr

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Insert picture and click Align Title Graphic. Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Dr. Dieter Lederer, Geschäftsführer Vector Consulting Services GmbH

Mehr

Universal Testing. Intelligentes & effizientes Testen mit Universal. Consor AG Ottikerstrasse 14 CH-8006 Zürich +41 44 368 35 35

Universal Testing. Intelligentes & effizientes Testen mit Universal. Consor AG Ottikerstrasse 14 CH-8006 Zürich +41 44 368 35 35 Universal Testing Consor AG Ottikerstrasse 14 CH-8006 Zürich +41 44 368 35 35 Copyright 2001-2009 Consor AG Seite 1 von 5 Komplexe Applikationen, Geschäftsprozesse und Produktentwicklungen, die kontinuierlich

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Fundamentaler Testprozess 11

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Fundamentaler Testprozess 11 xiii 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Fundamentaler Testprozess 11 2.1 Testplanung und -steuerung........................

Mehr

Testphase. Das Testen

Testphase. Das Testen Testphase VIS Projekt Freie Universität Berlin N.Ardet - 17.4.2001 Das Testen Testen ist das Ausführen eines Software- (Teil)systems in einer definierten Umgebung und das Vergleichen der erzielten mit

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Curriculum Vitae. Personalien. Erfahrungen. Fähigkeiten. Referenz-Nr. 2002 Geburtsdatum 18.12.1961. Soft Skills

Curriculum Vitae. Personalien. Erfahrungen. Fähigkeiten. Referenz-Nr. 2002 Geburtsdatum 18.12.1961. Soft Skills Curriculum Vitae Personalien Referenz-Nr. 2002 Geburtsdatum 18.12.1961 Nationalität Schweizer Erfahrungen berufliche en Branchenkenntnisse 6 6 4 8 2 5 Projektleitung Consulting NT Systeme Krisenmanagement

Mehr

Testmanagement bei SAP-Projekten

Testmanagement bei SAP-Projekten Testmanagement bei SAP-Projekten Erfolgreich Planen Steuern Reporten bei der Einführung von SAP-Banking von Alberto Vivenzio, Domenico Vivenzio 1. Auflage Springer Vieweg Wiesbaden 2012 Verlag C.H. Beck

Mehr

Praxiswissen COBIT. Grundlagen und praktische Anwendung in der Unternehmens-IT. von Markus Gaulke. 2., akt. u. überarb. Aufl.

Praxiswissen COBIT. Grundlagen und praktische Anwendung in der Unternehmens-IT. von Markus Gaulke. 2., akt. u. überarb. Aufl. Praxiswissen COBIT Grundlagen und praktische Anwendung in der Unternehmens-IT von Markus Gaulke 2., akt. u. überarb. Aufl. Praxiswissen COBIT Gaulke schnell und portofrei erhältlich bei beck-shop.de DIE

Mehr

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649 Testautomatisierung Lessons Learned qme Software GmbH Gustav-Meyer-Allee 25 13355 Berlin Telefon 030/46307-230 Telefax 030/46307-649 E-Mail qme Software info@qme-software.de GmbH Testautomatisierung Lessons

Mehr

Requirements-Engineering Requirements-Engineering

Requirements-Engineering Requirements-Engineering -Engineering Copyright Chr. Schaffer, Fachhochschule Hagenberg, MTD 1 Was ist ein Requirement? IEEE-Standard (IEEE-726 83) A condition or capability needed by a user to solve a problem or achieve an objective.

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1 Test Dipl. Wirtsch. Ing. Alexander Werth 9-1 Phasen der Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung Methoden der 9-2 Software Test / Erprobung Messen der

Mehr

Marketing Intelligence Architektur und Konzepte. Josef Kolbitsch Manuela Reinisch

Marketing Intelligence Architektur und Konzepte. Josef Kolbitsch Manuela Reinisch Marketing Intelligence Architektur und Konzepte Josef Kolbitsch Manuela Reinisch Übersicht Mehrstufiges BI-System Architektur eines Data Warehouses Architektur eines Reporting-Systems Benutzerrollen in

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

Alexander Geschonneck ix-edition www.dpunkt.de/plus

Alexander Geschonneck ix-edition www.dpunkt.de/plus Alexander Geschonneck leitet als Partner bei der KPMG AG Wirtschaftsprüfungsgesellschaft den Bereich Forensic Technology. Sein Tätigkeitsschwerpunkt ist die Sicherstellung und Analyse von digitalen Beweismitteln

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Praxiswissen Softwaretest Testmanagement

Praxiswissen Softwaretest Testmanagement Andreas Spillner Thomas Roßner Mario Winter Tilo Linz Praxiswissen Softwaretest Testmanagement Aus- und Weiterbildung zum Certified Tester Advanced Level nach ISTQB-Standard Andreas Spillner spillner@informatik.hs-bremen.de

Mehr

Basiswissen Softwaretest

Basiswissen Softwaretest Basiswissen Softwaretest Vergleich der Vorlesung Software-Engineering Wartung und Qualitätssicherung (Stand WS13/14) mit der 4. überarbeiteten und aktualisierten Auflage von Spillner&Linz: Basiswissen

Mehr

Agile Softwareverträge

Agile Softwareverträge Zeitschrift Informatik-Spektrum der deutschen Gesellschaft für Informatik Ursula Sury Agile Softwareverträge AGILE SOFTWAREENTWICKLUNG Komplexität, steter Wandel, Umgang mit vielen Unbekannten das sind

Mehr

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Testplanung und Teststeuerung

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Testplanung und Teststeuerung 2007 Dr. Klaudia Dussa-Zieger P r a k t I s c h e Testprozess - Inhalt Testprozess Testen von Software-Systemen Systemen - Testprozess Lehrplan 2003 Testplanung Testausführung ierung Testendebewertung

Mehr

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Lehrplan 2003 Testplanung

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Lehrplan 2003 Testplanung P r a k t I s c h e Testprozess - Inhalt Testprozess Testen von Software-Systemen Systemen - Testprozess Lehrplan 2003 Testplanung Testausführung ierung Testendebewertung Testberichterstattung Lehrplan

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Ottostr. 15 96047 Bamberg Tel. +49/951/98046200 Fax +49/951/98046150 email: info@softcondev.de www: softcondev.de INHALT Vorwort Diese

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

Einführung Arten von Softwaretests Prinzipien Continuous Integration Tests in FLOSS-Projekten Quellen. Softwaretests. Christoph Betschart

Einführung Arten von Softwaretests Prinzipien Continuous Integration Tests in FLOSS-Projekten Quellen. Softwaretests. Christoph Betschart Softwaretests Christoph Betschart 27. Oktober 2014 Inhaltsverzeichnis Einführung Arten von Softwaretests Prinzipien Seven Principles of Software Testing Continuous Integration Tests in FLOSS-Projekten

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

arvato Heterogene Systemlandschaft

arvato Heterogene Systemlandschaft Verteiltes Testen heterogener Systemlandschaften Dr. Thomas von der Maßen Andreas Wübbeke Februar 2010 1 Inhalt 1 arvato services und das IT-Management im Bertelsmann-Konzern 2 3 Heterogene Systemlandschaft

Mehr

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Agenda Warum Testmanagement? Was sind die wichtigsten Schritte beim Testmanagement? Wie funktioniert Testmanagement Toolunterstützung Page 1/15

Mehr

Innovatives Reporting mit PM10: Analysen und Berichte mit Single Point of Truth 11.00 11.45 Uhr

Innovatives Reporting mit PM10: Analysen und Berichte mit Single Point of Truth 11.00 11.45 Uhr Copyright 2007 Infor. Alle Rechte vorbehalten. Innovatives Reporting mit PM10: Analysen und Berichte mit Single Point of Truth 11.00 11.45 Uhr Hubertus Thoma Presales Consultant PM Schalten Sie bitte während

Mehr

AUFBAU EINER TESTORGANISATION

AUFBAU EINER TESTORGANISATION AUFBAU EINER TESTORGANISATION ODER DIE GEISTER, DIE ICH RIEF... Software-Tester Forum Mittwoch, 16. November 2005 SWX Swiss Exchange, Convention Point Zürich Robin Heizmann, CS IT Quality Management 14.11.2005

Mehr

Softwarequalitätssicherung

Softwarequalitätssicherung Softwarequalitätssicherung Dipl. Inf. Andrea Meyer Medieninformatik (Bachelor), Wahlpflichtmodul: Softwareprojekt II, Dipl. Inf. Andrea Meyer Warum Softwarequalitätssicherung? 2 Fatale Softwarefehler Ariane

Mehr

Qualitätssicherung und Testen in mittelständischen Software-Unternehmen

Qualitätssicherung und Testen in mittelständischen Software-Unternehmen Workshop Hot-Spots der Software-Entwicklung Qualitätssicherung und Testen in mittelständischen Software-Unternehmen 27. November 2008 Technische Universität München Institut für Informatik Software & Systems

Mehr

Durchblick im Self-Service-Dschungel. Hannover, 16.03.2015 Patrick Keller, Senior Analyst

Durchblick im Self-Service-Dschungel. Hannover, 16.03.2015 Patrick Keller, Senior Analyst Durchblick im Self-Service-Dschungel Hannover, 16.03.2015 Patrick Keller, Senior Analyst Business Application Research Center (BARC) B Europas führendes IT-Analysten- und -Beratungshaus für Business Software

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

Modellbasierte Testautomatisierung von Back-End-Systemen

Modellbasierte Testautomatisierung von Back-End-Systemen FINARIS Produktpräsentation Modellbasierte Testautomatisierung von Back-End-Systemen Hans-Peter Möller (DekaBank) Werner Märkl (FINARIS GmbH) 2 Agenda Seite Einleitung 3 Modellbasiertes Testen in der Datenverarbeitung

Mehr

Mit CMMI Prozesse verbessern!

Mit CMMI Prozesse verbessern! Mit CMMI Prozesse verbessern! Dr. Jürgen Schmied ist seit mehr als 10 Jahren als Berater für Software- Engineering-Themen tätig. Bei der method park Software AG ist er Principal Consultant zu den Themen

Mehr