Projektübergreifendes Testmanagement am Beispiel des Produkts Quality Center in einem Finanzunternehmen

Größe: px
Ab Seite anzeigen:

Download "Projektübergreifendes Testmanagement am Beispiel des Produkts Quality Center in einem Finanzunternehmen"

Transkript

1 Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Projektübergreifendes Testmanagement am Beispiel des Produkts Quality Center in einem Finanzunternehmen Bachelorarbeit im Studiengang Informatik von Sinan Botros Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Dr. Matthias Becker Hannover, 18. August 2006

2 Erklärung Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit selbstständig und ohne fremde Hilfe verfasst habe und keine anderen als die in der Arbeit angegebenen Quellen und Hilfsmittel verwendet habe. Hannover, Sinan Botros 2

3 Danksagung Ich bedanke mich bei Herrn Dipl.-Math. Thomas Flohr für die hervorragende Betreuung meiner Bachelorarbeit. 3

4 Inhaltsverzeichnis 1 Einführung Motivation Zielsetzung Vorgehensweise Struktur der Arbeit Systematisches Testen von Software Begriff und Ziel des Testens Arten von Tests Probleme und Fehler beim Testen Tätigkeiten beim Testen Dokumentation beim Testen Testen im Unternehmen Vorstellung des TestDirectors TestDirector-Struktur Analyse und Reports Rollenkonzept Ist-Zustand der Projekte im TestDirector Probleme beim Reporting Standardisierungskonzept Zweck der Standardisierung Ordnerstruktur und ordnende Attribute Test Plan Test Lab Defects Reporting Listenadministration Rechtekonzept Zielorientiertes Messen von Software Motivation Ziele des Software-Messens Software-Metriken Indikatoren Goal-Question-Metric-Ansatz Messplanung Messinstrumentierung Datenerfassung Datenanalyse Ableitung von Metriken nach der GQM-Methode Metriken für Tester Metriken für Entwickler Metriken für QS-Manager Metriken für Projektleiter Metriken für projektübergreifendes Reporting

5 7 Projektübergreifendes Reporting Motivation zum Einsatz eines Reporting-Systems Verbesserung der Kommunikation Verbesserung der Dokumentation Voraussetzungen für den Einsatz eines Reporting-Systems Umsetzung eines Reporting-Systems Vorstellung des Quality Center Dashboards Beispielhafte Implementierung der Indikatoren Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Anhang A

6 1 Einführung 1.1 Motivation Das Unternehmen ist mit mehreren Tausend Mitarbeitern und Präsenzen in verschiedenen Bundesländern eins der größten Informationstechnologie-Dienstleister in der Finanz-Branche in Deutschland. Die zentralen Funktionen der Abteilung, in der diese Arbeit geschrieben wurde, sind die Sicherstellung der eingesetzten DV-Systeme im Gesamtzusammenhang aller Systeme unter Einhaltung der Ordnungsmäßigkeit und Prüfung der Datenverarbeitung und die Bereitstellung von Testsystemen und Testwerkzeugen. Darüber hinaus werden die Entwickler und Tester durch umfassenden Support und Schulungen bzgl. der Testsysteme und Tools unterstützt. Zur Dokumentation und Durchführung von Tests wird im Finanzdienstleister das Tool TestDirector der Firma Mercury 1 von über 90 Projekten verwendet (siehe Kapitel 3 Testen im Unternehmen). Der Finanzdienstleister legt großen Wert darauf, seinen Kunden ausreichend qualitativ gesicherte Anwendungssysteme zur Verfügung zu stellen. Eine der wichtigsten Maßnahmen, die zur Qualitätssicherung beiträgt, ist Testen. Deshalb müssen im Projektverlauf eine sehr große Anzahl von Tests durchgeführt und dokumentiert werden. Zur Unterstützung des Testprozesses wird der TestDirector im Finanzdienstleister als verbindliches Testfallverwaltungstool verwendet. Deshalb enthält der TestDirector eine sehr große Menge von Informationen über den Teststatus der Projekte. Die Ablagestruktur der Testfälle in den Projekten ist jedoch unterschiedlich, Attribute und Auswahllisten sind nur teilweise standardisiert. Auswertungen über den Teststatus können deshalb nur innerhalb eines Projektes mit genauer Kenntnis der projektspezifischen Ablagestruktur erstellt werden, sind jedoch von außen, z.b. durch die Integration und Abnahme, nicht nachvollziehbar. Diese Tatsache wurde durch eine interne Befragung bestätigt. Außerdem wird der Anspruch an TestDirector-Projekte immer größer, Anforderungsmanagement und Releasetest benötigen eine projektübergreifende standardisierte Sicht auf den Status der getesteten Anwendungen. Die projektübergreifende Sicht ist mit dem Quality Center Dashboard 2 realisierbar. Dies ist nur dann umsetzbar, wenn die Projekte eine einheitliche Struktur sowie einheitliche Attribute und Attributwerte aufweisen. Aus diesem Grund wurde die Entscheidung getroffen, ein Nutzungskonzept zur Standardisierung der TestDirector-Projekte zu erstellen. Dieses Konzept wird im Laufe dieser Arbeit vorgestellt (siehe Kapitel 4 Standardisierungskonzept) und stellt die Grundlage für die Erreichung des Ziels dieser Arbeit. 1.2 Zielsetzung Ziel dieser Arbeit ist, es zu ermöglichen, den Teststatus der TestDirector-Projekte anhand quantitativ bestimmbare Maßeinheiten, sog. Key Performance Indicators (KPIs), graphisch als Portlets im Quality Center Dashboard darzustellen. 1 Mercury ist einer der weltweit führenden Anbieter im Bereich Business Technology Optimization (BTO). Es wird Unterstützung in Form von Dienstleistungen und Software angeboten zur Optimierung der Qualität, Performance und Verfügbarkeit von Applikationen sowie beim Management von IT Kosten und Risiken. Weitere Infos im Internet unter 2 Beim Dashboard handelt es sich um ein Tool der Firma Mercury zur Visualisierung der Daten in Form von Diagrammen oder Tabellen. Es bietet die Möglichkeit, eigene Metriken für die Software-Güte zu konfigurieren und diese durch den gesamten Qualitätssicherungsprozess hinweg zu erfassen und zu verwalten. 6

7 Der erste Schritt ist die Erstellung eines Konzepts zur Standardisierung der Testdokumentation der TestDirector-Projekte. Anschließend wird nach der Goal-Question- Metric-Methode vorgegangen, um Indikatoren und Metriken zur Überprüfung des Teststatus der Projekte abzuleiten. Diese Metriken richten sich an die verschiedenen Nutzergruppen entsprechend des Rollenkonzepts im Finanzdienstleister (Tester, Entwickler, QS-Manager, Projektleiter). Schließlich sollen die Indikatoren, die sich insbesondere für projektübergreifendes Reporting eignen, hervorgehoben und einige exemplarisch im Dashboard implementiert werden. Diese Indikatoren präsentieren eine Gesamtübersicht über den Teststatus der Projekte. Durch Bereitstellung dieser Gesamtübersicht über alle Projekte wird es zukünftig den Verantwortlichen möglich sein, auf einen Blick die Mängel sofort zu erkennen und dementsprechend zu handeln. Auf Basis dieser Übersicht können dann Messungen durchgeführt werden, um quantitative Aussagen zu bestimmten Systemqualitäten zu erhalten und den Fortschritt der Projekte zu kontrollieren. 1.3 Vorgehensweise Mit der Analyse des Ist-Zustandes der TestDirector-Projekte werden die benötigten Attribute verifiziert und für besseres Reporting geeignete Ablagestruktur der Testfälle mit den Projektmanagern diskutiert und abgestimmt. Anhand der daraus resultierenden Ergebnisse wird das Standardisierungskonzept erstellt. Anschließend wird nach der Goal-Question-Metric-Methode (GQM) vorgegangen, um Metriken und Indikatoren für den Status der TestDirector-Projekte abzuleiten. Zum Abschluss wird das Reportingtool Dashboard vorgestellt und dort exemplarisch einige Indikatoren implementiert. 1.4 Struktur der Arbeit In dem ersten Kapitel wurden Ziele der Arbeit und der Finanzdienstleister vorgestellt. Das zweite Kapitel ist ein Einstieg in das Thema Testen. Anschließend behandelt das dritte Kapitel das Testen im Finanzdienstleister und stellt den TestDirector ausführlich vor. Die im Zuge dieser Bachelorarbeit erarbeiteten Ideen zur Standardisierung der Testdokumentation der Projekte werden im vierten Kapitel erläutert. Zielorientiertes Software-Messen und die GQ(I)M-Methode stellen den Inhalt des fünften Kapitels dar. Im sechsten Kapitel werden die abgeleiteten Metriken für die verschiedenen Rollen präsentiert. Projektübergreifendes Reporting am Beispiel des Reportingtools Dashboard wird Thema des siebten Kapitels sein. Abschließend folgt im achten und letzten Kapitel eine Zusammenfassung dieser Arbeit. 7

8 2 Systematisches Testen von Software Einen wichtigen Beitrag zur Qualitätssicherung in der Software-Entwicklung wird durch systematisches Testen von Software gewährleistet. Ziel dieses Kapitels ist, einen Überblick über das Thema Testen und die damit verbundenen Begriffe und Aktivitäten zu geben. 2.1 Begriff und Ziel des Testens Die Intuition der meisten Menschen entspricht der Vorstellung, ein System auszuprobieren und aus den resultierenden Ergebnissen und Beobachtungen zu folgern, ob es seine Funktionen erfüllt, d.h. es zu testen. In der Wissenschaft wird der Begriff Testen jedoch genauer definiert. In der Literatur werden oft folgende Definitionen gefunden: Testen ist die Ausführung eines Programms mit dem Ziel Fehler zu entdecken [1]. und Testen ist die Vorführung eines Programms oder Systems mit dem Ziel zu zeigen, dass es tut, was es tun sollte [2]. Auf den ersten Blick scheinen sich die beiden Definitionen zu widersprechen und es stellt sich die Frage, welche die korrekte ist. In der Tat beide. Es wird jedoch nicht vom Gleichen gesprochen. Im ersten Fall wird Testen als ein Prüfverfahren vorgesehen, bei dem Systeme oder Programme ausgeführt werden, um vorhandene Defekte und Fehler zu finden. In diesem Sinne ist ein Test erfolgreich, wenn es zu einem Ergebnis führt, das sich von den spezifischen Anforderungen des Systems unterscheidet. Im zweiten Fall dient das Ausführen des Programms dem Nachweis, dass die Vereinbarten Leistungen erbracht worden sind. Das Software-Produkt wird validiert und erprobt, ob es die von ihm erwarteten Funktionalitäten erfüllt. Hier spricht man auch von Abnahmetest. Andererseits ist nicht jede Ausführung eines Programms ein Test. Unabhängig von der Methode und dem Ziel gehört zu der Spezifikation eines Tests immer ein vordefiniertes Soll- Ergebnis, das mit dem Ist-Ergebnis zu vergleichen ist. Eine genauere Definition des Testens und dessen Ziel, die zusätzlich auf die Testdaten und die Testreferenz eingeht, ist in deutschen Normierungen [DIN] wie folgt eingeführt: Ziel des Software-Tests ist es, durch Ausführung des Testobjekts auf einem Rechner mit ausgewählten Testdaten in einer definierten Umgebung festzustellen, ob sich das Testobjekt in diesen Fällen so verhält, wie es eine definierte Testreferenz vorschreibt. Zur Prüfung einer Software existieren mehrere Verfahren. Der Software-Test besitzt aber einen entscheidenden Vorteil: Der Test ist in der Praxis das einzige Verfahren, mit dem die realen Einsatzbedingungen eines Software-Systems, zum Beispiel Zielrechner, Compiler und Betriebssystem, angemessen berücksichtigt und die dynamischen Eigenschaften des Systems, beispielsweise das Laufzeit verhalten und die durch den Zielrechner gegebene Rechengenauigkeit, geprüft werden können [4]. 2.2 Arten von Tests Beim Testen wird immer ein bestimmtes Ziel verfolgt. Durch das Ziel wird festgelegt, auf welche Aspekte die Testfälle ausgelegt werden. In [6] werden im Wesentlichen folgende Testarten unterschieden: Fehlertest: Das Ziel beim Fehlertest ist die Aufdeckung der evtl. versteckten Fehler in einem Softwaresystem bevor dies an den Kunden ausgeliefert wird. Dabei wird versucht, ein unkorrektes Verhalten des Systems auszulösen um Fehler zu erkennen. 8

9 Die wesentliche Arbeit beim Fehlertest ist die Auswahl von Eingabedaten, die mit hoher Wahrscheinlichkeit ein Fehlverhalten auflösen. Funktionstest: Eine andere Bezeichnung dafür ist Black-Box-Test, da das System wie eine Black Box ist, dessen Verhalten nur durch die Eingaben und die dazugehörigen Ausgaben untersucht wird. Dabei wird also nur die Funktion betrachtet und nicht die Art der Implementierung. Eine Funktion ist in der Regel die kleinste, beim Tests gesondert zu prüfende Programmeinheit. Eine Funktion ist also eine Software- Komponente, die innerhalb des Software-Systems eine spezielle, abgrenzende Aufgabe erfüllt. Die Funktionstests werden auf Grundlage der Spezifikation erstellt. Diese Tests sollen gewährleisen, dass die an das System gestellten Anforderungen erfüllt werden. Integrationstest: Beim Funktionstest werden die einzelnen Systemkomponenten untersucht. Werden durch die Integration mehrere Teile zusammengeführt, so muss beim Testen auch speziell auf das Zusammenspiel und die Schnittstellen zwischen diesen Teilen geachtet werden. Das Ziel des Integrationstest ist, die durch diesen komplexen Prozess aufgedeckten Fehler aufzufinden. Da die einzelnen Komponenten aufeinander zusammenwirken, ist es in der Regel schwierig, die Fehlerquelle zu identifizieren. Deshalb ist es ratsam, den Integrationsprozess inkrementell durchzuführen. Zunächst wird eine möglichst kleine Anzahl von Komponenten integrieret und getestet. Bei erfolgreichem Test werden neue Komponenten hinzugefügt und erneut getestet. Abnahmetest: Das Ziel des Abnahmetests ist zu zeigen, dass das System bei der Ausführung vordefinierter Abnahmetestfälle die Anforderungen bzw. Bedürfnisse des Auftraggebers erfüllt. Abnahmetest werden hauptsächlich in der Endphase des Projekts auf einer realen Umgebung des Auftraggebers durchgeführt. 2.3 Probleme und Fehler beim Testen Eine wesentliche Aufgabe beim Testen besteht darin, die Testdaten auszuwählen. Eine Schwäche des Tests ist, dass nur für die ausgewählten Daten nachgewiesen werden kann, dass das Testobjekt gemäß der Spezifikation keine Abweichungen aufweist und keine Fehlfunktionen enthält. Dijkstra (1972) beschreibt, dass Testen nur die Anwesenheit von Fehlern zeigen kann, aber nicht die Abwesenheit. Nur ein vollständiger Test mit allen Eingabewerten und allen möglichen Kombinationen kann die absolute Korrektheit eines Software-Programms nachweisen. In der Praxis kann so ein Test aufgrund von sehr großen Anzahl von Testfällen und die dafür benötigte Zeit nicht durchgeführt werden. Davon abgesehen, dass es bei einigen Fällen eine unendliche Anzahl von Eingabewerten geben kann. Ein anderes Problem tritt auf, wenn die Ist- und Sollergebnisse nicht korrekt ermittelt werden. Weicht nach der Testdurchführung das Soll- vom Ist-Ergebnis aus, so liegt nicht immer tatsächlich eine Fehlerwirkung des Testobjekts vor, da auch andere Faktoren wie z.b. Fehler in der Testspezifikation oder im Testfall selbst Ursache für eine beobachtete Differenz sein können. Zusätzlich können die Testergebnisse falsch interpretiert werden und so nicht fehlerhafte Funktionen als solche angesehen werden. 9

10 2.4 Tätigkeiten beim Testen Im Folgenden wird Testen durch die Testaktivitäten und ihr Zusammenwirken veranschaulicht. Abbildung 2.1 [4] zeigt eine graphische Darstellung dieser Aktivitäten. Die gegenseitige Beeinflussung wird durch die Pfeile dargestellt. Die Planung, Organisation und Dokumentation beziehen sich auf die Gesamtheit aller zu prüfenden Testobjekte. Die weiteren Tätigkeiten beziehen sich auf ein einzelnes Testobjekt. Abbildung 2.1: Testaktivitäten und ihr Zusammenwirken In Anlehnung an Systematisches Testen von Software [4] werden folgende Testtätigkeiten definiert: Die erste Tätigkeit, die sich auf ein Testobjekt bezieht ist die Testfallermittlung. In einem Testfall wird eine bestimmte Eingabekonstellation festgelegt, mit der das Testobjekt getestet werden soll. Die Testfälle werden in der Regel aus Anforderungen bzw. Spezifikationen abgeleitet. Das Ziel dabei ist Identifizierung von Testfällen, mit denen nachgewiesen werden kann, dass die System-Funktionen vorhanden und ausführbar sind. Die 10

11 Testfälle behandeln sowohl das Normalverhalten als auch das Ausnahmeverhalten des Systems. Bei der Testdatengenerierung werden den Testfällen konkrete Testdaten zugewiesen. Da die Anzahl der möglichen Eingabewerte sehr hoch ist, wird aus jedem Wertebereich ein Repräsentant ausgewählt. Bei der Bestimmung von Sollergebnissen werden zu jedem Testfall die Ausgangswerte aus der Testreferenz, i. A. der Anforderungsspezifikation oder des Software-Entwurfs, abgeleitet. Die Ermittlung des Sollergebnisses beim Testen hat eine sehr entscheidende Bedeutung, denn das Ergebnis eines Testfalls kann nur dann als erfolgreich bezeichnet werden, wenn ein gültiges Referenzergebnis zur Verfügung steht und anhand dessen das Fehlverhalten des zu testenden Objekts erkannt werden kann. Bei der Testdurchführung wird das Testobjekt mit den entsprechenden Eingabedaten ausgeführt. Voraussetzung dafür ist die Bereitstellung des zu testenden Systems. Dabei sind die Testergebnisse, d.h. die Ausgabewerte, die das Testobjekt generiert, in geeigneter Form festzuhalten. Um die Überwachung des Testablaufs werden durch Hard- oder Software realisierte Funktionen zur Verfügung gestellt. Dadurch wird während der Testdurchführung eine Aufzeichnung des Programms ermöglicht (Monitoring). Bei der Testauswertung werden die Testergebnisse, die bei der Testdurchführung erzeugt wurden, also das Ist-Verhalten, mit den in der Testspezifikation vordefinierten Sollergebnissen verglichen. Anhand dessen wird festgestellt, ob sich das System wie gewünscht verhält oder Fehler aufweist. Falls Abweichungen zwischen dem Ist- und Sollverhalten festgestellt werden, so ist als erstes zu überprüfen, ob das auf die getestete Software zurückzuführen ist und keine anderen Faktoren wie ungenaue Testspezifikation oder fehlerhafte Testfälle dafür verantwortlich sein könnten. Liegt tatsächlich ein Fehler vor, so wird dieser an den Entwickler gemeldet und die Behebung des Fehlers priorisiert. Nach der Behebung des Fehlers muss das Testobjekt erneut getestet werden bis der Testfall erfolgreich verläuft. Die Testplanung ist eine projektübergreifende Testaktivität. Dabei werden die Testobjekte, die zu testenden Merkmale, die Kriterien zur Auswahl der Testfälle sowie die Abbruch- und die Wiederaufnahmekriterien festgelegt. Weiterhin sind die Testfälle zu priorisieren und die Reihenfolge der Durchführung zu definieren. Ziel dabei ist, dass die kritischen Teile des Systems zuerst getestet werden. Darüber hinaus muss die Testumgebung, die Hardware- und Softwarekonfiguration einschließlich Betriebssystem festgelegt werden. Schließlich werden die für die Testdurchführung benötigte Zeit, Testpersonal sowie deren Aufgaben und Verantwortlichkeiten bestimmt. Im Rahmen der Testorganisation werden die Testfälle, Testdaten und die Testergebnisse verwaltet. Zu dem wird festgelegt, ob und welche Testunterstützungswerkzeuge eingesetzt werden. Weiterhin wird die Art der Dokumentation und die Speicherung der Testdaten festgelegt. Dies ist von entscheidender Bedeutung um Tests wiederholen zu können. Damit können Tests, die einen Fehler im System aufgedeckt haben, erneut ausgeführt werden um zu entscheiden, ob die Behebung des Fehlers erfolgreich war oder nicht. Eine sehr wichtige Testaktivität für die vorliegende Arbeit ist die Testdokumentation. Diese wird im nächsten Teilabschnitt ausführlich beschrieben. 11

12 2.5 Dokumentation beim Testen Um Tests systematisch auszuführen, müssen sie vorher sorgfältig geplant und vorbereitet werden. Diese Tätigkeiten erfordern einen großen Ressourcen- und Zeitaufwand. Deshalb sollte der größtmöglichen Nutzen aus diesem Aufwand gezogen werden. Die Dokumentation von Tests ist von zentraler Bedeutung für diesen Nutzen [5]. Die Dokumentation enthält die geplanten Testfällen sowie die beim Ausführen resultierten Ergebnissen. Auch bei der Beschreibung der Testfälle und bei der Testdurchführung können Fehler auftreten. Werden diese aber dokumentiert, so kann die Dokumentation selbst geprüft werden und die Fehler nachvollzogen werden. Die meisten Software-Programme sind an den Bedürfnissen der Kunden ausgerichtet und werden damit mit der Zeit aktualisiert und angepasst. Dabei muss erneut eine hohe Anzahl von Tests evtl. nur mit geringen Veränderungen durchgeführt werden. Die Dokumentation kann diesen Aufwand deutlich verringern und die Wiederholbarkeit von Testfällen sicherstellen. Werden Beim Testen Fehler entdeckt, so kann der Entwickler mit der Hilfe der Dokumentation den gleichen Testfall unter gleichen Bedingungen in gleicher Testumgebung wiederholen um den Fehler zu lokalisieren und zu beheben. Deshalb ist es nur dann sinnvoll, Programme zu testen, die unter Konfigurationskontrolle stehen. Denn nur so kann die getestete Version des Programms wiederhergestellt werden. Die Testdokumentation besteht aus mehreren Teilen. Dazu gehört der Testplan, die Beschreibung der Testfälle, die Testdaten und die Bedingungen, unter denen die Tests durchgeführt wurden sowie die Testergebnisse und die Dokumentation der evtl. gefundenen Fehler. Bei mittleren oder großen Projekten ist die Anzahl der durchzuführenden Testfällen und die damit verknüpften Testdokumenten so hoch, dass allein die Verwaltung dieser Dokumente einen großen Aufwand erfordert. Aus diesem Grund werden Testdokumentationswerkzeuge eingesetzt um den Testdokumentationsprozess zu unterstützen. An dieser Stelle ist noch mal darauf hinzuweisen, dass im Finanzdienstleister das Testdokumentationstool TestDirector als verbindliches Tool zur Dokumentation von Tests verwendet wird (siehe Kapitel 3 Testen im Finanzdienstleister). 12

13 3 Testen im Unternehmen Der Finanzdienstleister ist sich über die Bedeutung des Testens im Klaren und legt sehr großen Wert darauf, seinen Kunden ausreichend getestete und qualitativ gesicherte Anwendungssysteme anzubieten. Um den Testprozess und die Tester bei ihren Aktivitäten zu unterstützen, setzt der Finanzdienstleister den TestDirector als verbindliches Werkzeug zur Testüberstützung ein. 3.1 Vorstellung des TestDirectors Der TestDirector ist ein webbasiertes Tool zur Dokumentation, Verwaltung und Durchführung von Testfällen. Darüber hinaus unterstützt der TestDirector die Erfassung und Verfolgung des Status von Anforderungen und Defects 3. Zusätzlich können (halb-)automatisch Statistiken und Analyse-Reports über den aktuellen Status des Testprozesses generiert werden TestDirector-Struktur Der TestDirector besteht aus folgenden vier Komponenten: 1. REQUIREMENTS Anforderungen des Kunden werden zunächst in RequisitePro 4 erfasst. RequisitePro hat eine Schnittstelle zum TestDirector. Nächtlich findet eine Synchronisation statt, sodass alle Anforderungen in den TestDirector-Beriech REQUIREMENTS übertragen werden. Im TestDirector werden den Anforderungen Testfälle zugeordnet. Jede Anforderung hat dann abhängig vom Status der ihr zugeordneten Testfälle ihren eigenen Status. Werden einer Anforderung keine Testfälle zugeordnet, so hat diese Anforderung den Status Not Covered. Sonst ist der Cover-Status einer Anforderung der Ausführungsstatus der damit verknüpften Testfälle. Siehe Ausführungsstatus eines Testfalls in Tabelle 4.3. Zur besseren Übersicht und effizienteren Verwaltung werden die Anforderungen in einer hierarchischen Struktur abgelegt. Siehe Abbildung 3.1. Abbildung 3.1: Anforderungs-Struktur und Status in einem TestDirektor-Projekt 3 In der Terminologie des Unternehmens sind Defects Abweichungen, Fehler oder Fehlverhalten in einem Programm, die während des Testens erkannt werden. 4 Bei RequisitePro handelt es sich um ein Anforderungsmanagementtool der Firma IBM Rational, das im Unternehmen zur Unterstützung des Anforderungsmanagements eingesetzt wird. 13

14 Weiterhin können jeder Anforderung zusätzliche Attribute zugeordnet werden, wie z.b. Priority für die Angabe der Priorität, mit der diese Anforderung umgesetzt werden soll, oder Type zur Beschreibung des Anforderungstyps, z.b. funktional oder nicht funktional. Siehe Abbildung TEST PLAN Abbildung 3.2: Attribute einer Anforderung Die Erstellung und Beschreibung der Testfälle geschieht im Bereich TEST PLAN. Die Testfälle können in einer hierarchischen Struktur abgelegt werden. Jeder Testfall besteht aus mehreren Schritten. In jedem Schritt werden die Eingangs- und die erwarteten Ausgangsdaten beschrieben. Siehe Abbildung 3.3. Abbildung 3.3: Testfall-Struktur und Beschreibung eines Testfalls 14

15 Einem Testfall können eine Menge von Attributen angehören wie z.b. Status, das den momentanen Status des Testfalls angibt und darüber informiert, ob der Testfall in der Beschreibungsphase Design oder Bereit zum Ausführen Ready ist. Siehe Abbildung 3.4. Abbildung 3.4: Attribute eines Testfalls Zusätzlich können verschiedene Arten von Dokumenten oder Bildern einem Testfall unter Attachments angehängt werden. Unter Regs Coverage kann einem Testfall eine oder mehrere Anforderungen zugeordnet werden. 3. TEST LAB Im Bereich TEST LAB findet die Testausführung statt. Zunächst werden die einzelnen Testfälle zu einem so genannten TestSet zusammengefasst. Ein TestSet besteht aus einem oder mehreren Testfällen, die in einer logischen Reihenfolge ausgeführt werden. Um verschiedene Testszenarien abzubilden, können die Testfälle in mehreren TestSets unterschiedlich kombiniert werden. Die Aufteilung der einzelnen TestSets in einer Baumstruktur erlaubt eine flexible Zusammenstellung der TestSets je nach Release, Teststufe oder Anwendung. Siehe Abbildung 3.5. Abbildung 3.5: TestSet-Struktur und Status in einem TestDirektor-Projekt 15

16 Einem TestSet können verschiedene beschreibende Attribute angehören wie z.b. Close Date, das angibt, an welchem Datum diese Tests aufgeführt wurden. Siehe Abbildung 3.6. Abbildung 3.6: Attribute eines TestSets Auch einem TestSet können unter Attachments verschiedene Dokumente angehängt werden. 4. DEFECTS Werden während des Testens Abweichungen oder Fehler festgestellt, so werden diese vom Testdurchführenden als ein Defekt im Bereich DEFECTS erfasst und einem Bearbeiter zugeordnet. Darüber hinaus kann ein Defekt einem entsprechenden Testfall zugeordnet werden. Beim Erstellen eines Defekts können verschiedene Attribute zur besseren Beschreibung des Defekts gefüllt werden. Siehe Abbildung 3.7. Abbildung 3.7: Attribute eines Defekts 16

17 Eins der wichtigsten Attribute ist der Status eines Defekts. Beim Erstellen des Defekts wird der Status auf New gesetzt. Wird der Defekt vom Lösungsverantwortlichen z.b. aufgrund falscher Zuordnung abgelehnt, so setzt dieser den Status auf Rejected. Nimmt er den Defekt an, so setzt er den Status auf Open. Nach Behebung des Defekts wird der Status auf Fixed gesetzt. Falls die Lösung vom Defektersteller nicht akzeptiert wird, so setzt dieser den Status auf Not accepted. Der Lösungsverantwortliche dokumentiert dann die erneute Annahme durch den Status Reopen. Wird der Defekt erfolgreich behoben und die Lösung akzeptiert, ist der Status auf Closed zu setzen. Siehe Abbildung 3.8 [3]. New Rejected Open Reopen Fixed Not accepted Closed Abbildung 3.8: Lebenszyklus eines Defekts als Aktivitätsdiagramm 17

18 3.1.2 Analyse und Reports In allen Bereichen des TestDirectors (REQUIREMENTS, TEST PLAN, TEST LAB, DEFECTS) können Standard-Reports in Form von Graphen oder Diagramme über den aktuellen Status eines TestDirector-Projekts erstellen werden. Mit Graphen wird eine Fortschrittanalyse der Daten auf Zeitbasis gezeigt. Eine Zusammenfassung der Datenbereiche kann als Diagramm dargestellt werden. Abbildung 3.9 zeigt ein Beispiel-Report für den aktuellen Stand der Defects bzgl. Status und Priorität in einem TestDirector-Projekt. 3.2 Rollenkonzept Abbildung 3.9: Beispiel-Report in einem TestDirector-Projekt Zur Administration und Nutzung des TestDirectors im Finanzdienstleister werden verschiedene Gruppen mit unterschiedlichen Rechten definiert. Im Folgenden eine Zusammenfassung der Aufgaben und Verantwortlichkeiten der für diese Arbeit relevanten Gruppen: TDAdmin: Dieser Gruppe gehört nur der technische User admin der TestFactory an. Er ist für die Einrichtung von TestDirector Repositories und die zentrale Benutzereinrichtung verantwortlich. Defect_Bearbeiter: Die Angehöriger dieser Gruppe haben ausschließlich eine Sicht auf den TestDirector-Bereich DEFECTS und dort nur eingeschränkte Modifikationsrechte. 18

19 Tester: In dieser Gruppe haben die Benutzer alle Rechte außer Löschen auf alle TestDirector- Bereiche. Im Allgemeinen werden folgende Rollen dieser Gruppe zugeordnet: Tester, Entwickler, Qualitätssicherer oder Integratoren und Abnehmer. Projekt_Manager: Diese Gruppe hat alle Rechte auf die TestDirector-Bereiche und zusätzliche Rechte zur Administration eines TestDirector Projektrepositories. Dieser Gruppe werden i.a. folgende Rollen zugeordnet: Projektleiter und Projektmanager. 3.3 Ist-Zustand der Projekte im TestDirector Momentan werden durch die Testfacotry keine Vorgaben oder Empfehlungen gegeben, wie die Ablagestruktur der Testfälle im TestDirector aussehen soll. So ist es jedem Projekt überlassen, die eigene Ordnerhierarchie in den Bereichen TEST PLAN und TEST LAB zu bestimmen. Demzufolge sind die Reihenfolge und die Anzahl der Ebenen sowie die Kriterien zur Gliederung der Objekte in den Projekten völlig unterschiedlich. Abbildung 3.10 zeigt beispielhaft die Strukturen von drei TestDirector-Projekten. In a) wird nach Teststufe, dann nach Release und Anwendung gegliedert. Bild b) zeigt eine Gliederung nach Release, Testart, Baseline und Team. In Bild c) wird eine Gliederung nach Anwendung, Release, Betriebssystem und Testart gezeigt. Abbildung 3.10: Strukturen von drei TestDirector-Projekten Außerdem sind die Attribute in den Projekten bzgl. Reihenfolge und Bestimmung von obligatorischen Feldern unterschiedlich. Einige Projekte enthalten zusätzliche Attribute, die in anderen Projekten nicht verwendet werden. Abbildung 3.11 a) und b) zeigt beispielhaft die Attribute im Bereich DEFECTS in zwei TD-Projekten. Formatiert Abbildung 3.11: a) Attribute im Bereich DEFECTS in einem TestDirector-Projek 19

20 Abbildung 3.11: b) Attribute im Bereich DEFECTS in einem anderen TestDirector-Projekt Auch die Attributwerte und Attributbezeichnungen sind nicht in allen Projekten einheitlich. Abbildung 3.12 zeigt die verschiedenen Werte des Attributes Priority in drei TestDirector- Projekten. Abbildung 3.12: Werte des Attributs Priority in drei TestDirector-Projekten 3.4 Probleme beim Reporting Um aussagekräftige Reports zu erstellen ist die genaue Kenntnis der projektspezifischen Ablagestruktur, der Attribute und deren Werte erforderlich. Eine Gesamtübersicht über den Teststatus von außen, z.b. aus Sicht der Integration und Abnahme, ist sehr schwer nachvollziehbar. Eine einheitliche Sicht über mehrere Projekte ist nicht möglich. Außerdem können die generierten Reports abweichende Ergebnisse vom tatsächlichen Status enthalten wenn einige Fälle nicht betrachtet werden wie z.b. das Verschieben von Testfällen in neuen Ordnern im jeweiligen Projekt oder das Kopieren und Einfügen von Testfällen zwischen verschiedenen Projekten. Solche Aktivitäten können zu Verlusten von Daten Führen wenn einige Attribute im neuen Projekt nicht existieren. Sind die Attribute physikalisch in verschiedener Reihenfolge gespeichert, so kommt es zu unkorrekten Zuordnung der Attributwerte. Demzufolge können die Statistiken keine korrekte Ergebnisse zeigen. Im TestDirector sind also eine große Menge von relevanten Informationen, die wegen fehlender einheitlicher Struktur nicht genutzt werden können, was ein großer Verlust für das Testmanagement darstellt. 20

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

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

Projektstrukturierung und eine maßgeschneiderte Reportinglösung für HP QC

Projektstrukturierung und eine maßgeschneiderte Reportinglösung für HP QC Projektstrukturierung und eine maßgeschneiderte Reportinglösung für HP QC Christian Köster Talanx Systeme AG Test Competence Center Bad Neuenahr 2014 Test Compentence Center (TCC) IT-Architektur TSY-AR.T

Mehr

Testen - Konzepte und Techniken

Testen - Konzepte und Techniken Testen - Konzepte und Techniken Magdalena Luniak 21.11.2007 Magdalena Luniak () Testen - Konzepte und Techniken 21.11.2007 1 / 42 Übersicht 1 Motivation 2 Grundbegrie 3 Testen im Softwareentwicklungsprozess

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

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

Mehr

TESTPLAN

TESTPLAN <Projektname> Firma TESTPLAN ID Version Ersteller: ------------------- Vorgesetzter des Erstellers:

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

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

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

Qualitätsmanagement im Projekt

Qualitätsmanagement im Projekt Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

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

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

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

Testen Prinzipien und Methoden

Testen Prinzipien und Methoden Testen Prinzipien und Methoden ALP 2 SS2002 4.7.2002 Natalie Ardet Definition Im folgenden gilt: Software = Programm + Daten + Dokumentation Motivation Software wird immer mehr in Bereichen eingesetzt,

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

Testen. SEPR Referat: Testen - Oliver Herbst

Testen. SEPR Referat: Testen - Oliver Herbst Testen Inhalt 1. Grundlagen des Testens 2. Testen im Softwarelebenszyklus 3. Statischer Test 4. Dynamischer Test 5. Besondere Tests 2 1. Grundlagen des Testens 3 Grundlagen des Testens Motivation erfüllt

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

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

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

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

Mehr

Dokumentation Eigenwartung

Dokumentation Eigenwartung Inhaltsverzeichnis 1 Allgemeines... 3 1.1 Copyright... 3 1.2 Einstieg... 3 2 Ordner Navigation... 4 3 Menüleiste... 5 3.1 Alle/Keine Elemente auswählen... 5 3.2 Kopieren... 5 3.3 Ausschneiden... 5 3.4

Mehr

JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper

JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper Wussten Sie, dass lediglich der kleinere Teil der Datenverarbeitung in Ihrem System von End-Anwendern generiert wird? Der größere Teil der Informationen

Mehr

Kundenanforderungen dokumentieren

Kundenanforderungen dokumentieren Requirements Engineering Kundenanforderungen dokumentieren Bereich Anforderungen Aktivität Kunden-Anforderungen erheben Ziele Gesteigerte Kundenzufriedenheit Dokumentation der genauen Erwartungen des Kunden

Mehr

Nach Ihrer erstmaligen Anmeldung sollten Sie Ihr Passwort ändern. Dazu klicken Sie bitte auf Ihren Namen.

Nach Ihrer erstmaligen Anmeldung sollten Sie Ihr Passwort ändern. Dazu klicken Sie bitte auf Ihren Namen. 1 Passwort ändern Nach Ihrer erstmaligen Anmeldung sollten Sie Ihr Passwort ändern Dazu klicken Sie bitte auf Ihren Namen Abb 1-1 Erstmaliger Anmeldung Danach erscheint ein PopUp indem Sie Ihr Passwort

Mehr

Nutzerhandbuch Softwaresystem Inspirata. Benutzerhandbuch Softwaresystem Inspirata

Nutzerhandbuch Softwaresystem Inspirata. Benutzerhandbuch Softwaresystem Inspirata Benutzerhandbuch Softwaresystem Inspirata 1 Inhaltsverzeichnis 1. Login und Logout... 3 2. Kalender/Buchungen auswählen... 5 3. Betreuer... 7 3.1 Buchung anlegen... 7 3.2 Betreuer zuordnen... 8 3.3 Notiz

Mehr

Programmieren I. Übersicht. Vorlesung 12. Handout S. 1. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011

Programmieren I. Übersicht. Vorlesung 12. Handout S. 1. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011 Programmieren I Martin Schultheiß Hochschule Darmstadt Wintersemester 2010/2011 1 2 Übersicht Testen ist eine der wichtigsten, aber auch eine der Zeitaufwändigsten Arbeitsschritte der Softwareentwicklung.

Mehr

Information zu den Studienleistungen Projektplanung (SPO 1: 111232, SPO 2: 112232 ) und Bachelor Thesis (SPO 1: 111241, SPO 2: 112251)

Information zu den Studienleistungen Projektplanung (SPO 1: 111232, SPO 2: 112232 ) und Bachelor Thesis (SPO 1: 111241, SPO 2: 112251) Fakultät Technik 1 Studiengang Maschinenbau Prodekan Prof Dr-Ing W Elmendorf Information zu den Studienleistungen Projektplanung (SPO 1: 111232, SPO 2: 112232 ) und Bachelor Thesis (SPO 1: 111241, SPO

Mehr

Maintenance & Re-Zertifizierung

Maintenance & Re-Zertifizierung Zertifizierung nach Technischen Richtlinien Maintenance & Re-Zertifizierung Version 1.2 vom 15.06.2009 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0

Mehr

Konzeption. und prototypische Implementierung. eines Werkzeuges. für den funktionalen Klassentest

Konzeption. und prototypische Implementierung. eines Werkzeuges. für den funktionalen Klassentest Konzeption und prototypische Implementierung eines Werkzeuges für den funktionalen Klassentest Übersicht Motivation Zielsetzung Lösungsansatz und dessen Realisierung Anwendungs-Szenarien Präsentation von

Mehr

Anlage E.1 Fragenkatalog Nr. 4

Anlage E.1 Fragenkatalog Nr. 4 Anlage E.1 Fragenkatalog Nr. 4 Hinweise: Sofern sich aufgrund von Bieterfragen Änderungen/Ergänzungen an/zu den Vertragsunterlagen ergeben, werden Sie mit diesem Fragenkatalog hierüber informiert. Fragen

Mehr

Synergieeffekte der formalen QS von Geschäftsprozessen Referent: A. Peter Zimmermann. Unser Testprozess hat den LEVEL 4 nach ISO / IEC 15504 (SPICE)

Synergieeffekte der formalen QS von Geschäftsprozessen Referent: A. Peter Zimmermann. Unser Testprozess hat den LEVEL 4 nach ISO / IEC 15504 (SPICE) Synergieeffekte der formalen QS von Geschäftsprozessen Referent: A. Peter Zimmermann Unser Testprozess hat den LEVEL 4 nach ISO / IEC 15504 (SPICE) superdata auf einen Blick Produkte FIT Testverfahren

Mehr

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008 Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen

Mehr

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013 Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael

Mehr

Abbildung 1: Tool-Qualification-Kits für Testwell CTC++ Test Coverage Analyser

Abbildung 1: Tool-Qualification-Kits für Testwell CTC++ Test Coverage Analyser Qualification-Kit für Testwell CTC++ In der sicherheitskritischen Softwareentwicklung müssen die im Projekt eingesetzten Werkzeuge zunächst klassifiziert werden (Tool Classification). Diese Klassifizierung

Mehr

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal Softwaretechnikpraktikum SS 2004 Qualitätsmanagement I 5. Vorlesung 1. Überblick Planungsphase Definitionsphase Entwurfsphase Implem.- phase Fragen Was ist Qualität? Wie kann man Qualität messen? Wie kann

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

Swetlana Stickhof. Universität Heidelberg 03.02.2013

Swetlana Stickhof. Universität Heidelberg 03.02.2013 Modellierung einer Testdokumentation mit Suchfunktionen in Semantic MediaWiki und Implementierung einer Jira-Anbindung als Semantic MediaWiki Extension Universität Heidelberg 03.02.2013 1 Inhalt Motivation

Mehr

Qualitätssicherung (Testen) im Application Life Cycle

Qualitätssicherung (Testen) im Application Life Cycle Qualitätssicherung (Testen) im Application Life Cycle Metriken im Test Michael Wagner Triton Unternehmensberatung GmbH www.triton.at www.tritonqs.at Copyright by Triton Technologie Consulting GmbH, all

Mehr

Handbuch Schulungsdatenbank

Handbuch Schulungsdatenbank Handbuch Schulungsdatenbank Inhaltsverzeichnis Hinweise... 3 Überblick... 4 Themen... 5 Schulungsprogramm Verwalten... 6 Details... 7 Schulungsprogramm bearbeiten... 9 Anstehende Termine... 10 Schulungen

Mehr

Testskripten Beispiele für System- und Akzeptanztests

Testskripten Beispiele für System- und Akzeptanztests Testskripten Beispiele für System- und Akzeptanztests Dokument-Information Dokument-ID: BA-TSKR Version: 1.0, gültig ab: 01.05.2010 Ersetzt Version: Autor(en): Isabelle Neuburg Geltungsbereich: Entwicklung

Mehr

FUTURE NETWORK 20.11.2013 REQUIREMENTS ENGINEERING

FUTURE NETWORK 20.11.2013 REQUIREMENTS ENGINEERING 18/11/13 Requirements Engineering 21 November 2013 DIE GRUNDFRAGEN Wie erhält der Kunde den größten Nutzen? Wie kann der Kunde am besten spezifizieren, was er haben will? Welchen Detailierungsgrad braucht

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

Standard Inhaltsverzeichnis für Testvorschrift

Standard Inhaltsverzeichnis für Testvorschrift Standard Inhaltsverzeichnis für Testvorschrift Inhaltsverzeichnis 1. Zweck, Veranlassung... 1 2. Allgemeines... 1 2.1 Zweck der Testvorschrift... 1 2.2 Freigabe und Änderungen... 1 2.3 Prinzipien... 2

Mehr

Informationssystemanalyse Software Risk Evaluation 7 1

Informationssystemanalyse Software Risk Evaluation 7 1 Informationssystemanalyse Software Risk Evaluation 7 1 Software Risk Evaluation Um Risiken bei Software-Projekten abzuschätzen und ihnen zu begegnen, wurde am SEI die Software Risk Evaluation-Methode entwickelt.

Mehr

Praxiswissen Softwaretest - Testmanagement

Praxiswissen Softwaretest - Testmanagement Praxiswissen Softwaretest - Testmanagement Aus- und Weiterbildung zum Certified Tester Advanced Level nach ISTQB-Standard dpunkt.verlag 1 Einleitung 1 1.1 Basiswissen - komprimiert 4 1.2 Praxiswissen Testmanagement

Mehr

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2 Inhaltsverzeichnis 1 Einführung 2 1.1 Warum Softwaretests?.................................... 2 2 Durchgeführte Tests 2 2.1 Test: allgemeine Funktionalität............................... 2 2.1.1 Beschreibung.....................................

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

Qualitätsmanagement. Grundlagen

Qualitätsmanagement. Grundlagen Grundlagen Historie: Mit industriellen Massenproduktion erforderlich geworden (Automobilindustrie, Anfang des letzten Jahrhunderts); Qualitätsmanagement zunächst nur in der Fertigung Mitte des letzten

Mehr

Rollen- und Rechtekonzept

Rollen- und Rechtekonzept Inhaltsverzeichnis Rollen- und Rechtekonzept 1. Ziele...1 2. Konzeption zur Realisierung durch Access Control List und im Management-Interface...2 2.1. Ansatz...2 2.2. Safety oder Security...2 2.3. User-

Mehr

Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden

Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden Sperrvermerk Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden Bachelorarbeit Zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

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

CICERO.Test Datenbasierende Testautomatisierung für höchste Qualitätsansprüche

CICERO.Test Datenbasierende Testautomatisierung für höchste Qualitätsansprüche CICERO.Test Datenbasierende Testautomatisierung für höchste Qualitätsansprüche Ihre Software -Anwendung ist Ziel von Reklamationen? Die Qualität Ihrer Anwendung - eine Frage des Glaubens? Oder eine Frage

Mehr

Manuelles Testmanagement. Einfach testen.

Manuelles Testmanagement. Einfach testen. Manuelles Testmanagement. Einfach testen. Testmanagement als Erfolgsfaktor. Ziel des Testprozesses ist die Minimierung des Restrisikos verbleibender Fehler und somit eine Bewertung der realen Qualität

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

Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13

Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13 Service Transition Martin Beims WKV SS13 Karsten Nolte Inhalt Einführung & Ziele Transition Planning & Support Change Management Service Asset & Configuration Management Release & Deployment Management

Mehr

Anleitung fu r die Vorlage restpunkte.xlsx

Anleitung fu r die Vorlage restpunkte.xlsx Anleitung fu r die Vorlage restpunkte.xlsx Inhalt 1 Einleitung... 1 2 Grundsätzliche Bedienungshinweise... 1 3 Wichtige Regeln für das Ausfüllen... 2 4 Erfassen der Information... 2 4.1 Das Blatt Inspektionen...

Mehr

Verwertung und Wirtschaftlichkeit. Projektmanagement. Konzeptentwicklung. Technologische/Technische Klärung

Verwertung und Wirtschaftlichkeit. Projektmanagement. Konzeptentwicklung. Technologische/Technische Klärung Zielsetzung und Einsatz: Die Checkliste dient als Hilfsmittel für die Gestaltung und Umsetzung einer Voruntersuchung. Die hier vorliegende ist auf die Abwicklung vergleichsweise komplexer Voruntersuchungen

Mehr

SixCMS 6 Tutorial - Content-Manager. So erfassen Sie Inhalte mit SixCMS

SixCMS 6 Tutorial - Content-Manager. So erfassen Sie Inhalte mit SixCMS SixCMS 6 Tutorial - Content-Manager So erfassen Sie Inhalte mit SixCMS Inhalt Inhalt So erfassen Sie Inhalte mit SixCMS 3 Zu diesem Tutorial 3 Ablageort definieren 5 Content-Container erstellen 6 Einträge

Mehr

Automatisierung von Testmanagementaufgaben

Automatisierung von Testmanagementaufgaben Automatisierung von Testmanagementaufgaben Q-Event Luzern, 5.9.2013 «Effizienter Testen aber wie?» Heribert Neu Senior Testmanager www.bbv.ch Referent Heribert Neu, Senior Testmanager, bbv Software Services

Mehr

PROTOS. Vorbereitende Arbeiten. Inhalt

PROTOS. Vorbereitende Arbeiten. Inhalt PROTOS Vorbereitende Arbeiten Inhalt Dieses Dokument beschreibt, welche Daten Sie vor Inbetriebnahme der Projekt-Ressourcenplanungslösung PROTOS definieren müssen. Autor: AL, MZ Datum: 20.01.2015 Dokument

Mehr

Von Requirements zutests. gç~åüáãkpåüìäò]èì~äáíóé~êâkçé

Von Requirements zutests. gç~åüáãkpåüìäò]èì~äáíóé~êâkçé Von Requirements zus gç~åüáãkpåüìäò]èì~äáíóé~êâkçé QualityPark Ihr Partner im Lifecycle Management Process Management Requirements Engineering IT & Development Process Expertise Process Implementation

Mehr

CBIS - CARE BED INFORMATION SYSTEM

CBIS - CARE BED INFORMATION SYSTEM CBIS - CARE BED INFORMATION SYSTEM Test Plan Dokumentänderungen Version # Datum Ersteller Beschreibung V1.0 18.04.2010 Anna Bruseva Erste Version Inhaltsverzeichnis 1 INTRODUCTION...2 2 TESTKOMPONENTEN...2

Mehr

Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement

Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement Dr. Markus Pizka Technische Universität München Institut für Informatik pizka@in.tum.de 3.3 Änderungsmanagement (CM) Evolution der Software

Mehr

Geschäftsprozessmanagement

Geschäftsprozessmanagement Geschäftsprozessmanagement Der INTARGIA-Ansatz Whitepaper Dr. Thomas Jurisch, Steffen Weber INTARGIA Managementberatung GmbH Max-Planck-Straße 20 63303 Dreieich Telefon: +49 (0)6103 / 5086-0 Telefax: +49

Mehr

Performance Zertifizierung

Performance Zertifizierung Performance Zertifizierung Alois Schmid alois.schmid@itf-edv.de www.itf-edv.de Copyright 2012 ITF-EDV Fröschl GmbH Inhalt Firma.... Kapitel 1 Gründe für die Zertifizierung der Massendatentauglichkeit.....

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Microsoft Solutions Framework. Daniel Dengler CN7. Unterschied MSF - MOF Microsoft Solutions Framework

Microsoft Solutions Framework. Daniel Dengler CN7. Unterschied MSF - MOF Microsoft Solutions Framework Einführung MSF MOF Microsoft Solutions Framework Microsoft Operations Framework Daniel Dengler CN7 Agenda Unterschied MSF - MOF Microsoft Solutions Framework Elementare Komponenten grundlegende Richtlinien

Mehr

ISTQB Certified Tester Foundation Level Exam Übungsprüfung

ISTQB Certified Tester Foundation Level Exam Übungsprüfung BEMERKUG: Bitte nur eine Antwort auf jede Frage 1. Die statische Analyse kann höchstwahrscheinlich ICHT finden: (A) Die Verwendung einer Variablen bevor diese definiert wurde. (B) Unerreichbaren ( toten

Mehr

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Jan Düttmann Archimedon Software + Consulting GmbH & Co. KG Marienstraße 66 32427 Minden Stephan Kleuker Hochschule

Mehr

LISTENFILTER FÜR DIE MITARBEITER-STAMMDATEN

LISTENFILTER FÜR DIE MITARBEITER-STAMMDATEN LISTENFILTER FÜR DIE MITARBEITER-STAMMDATEN PRODUKT(E): KATEGORIE: Vivendi PEP Stammdaten VERSION: 2.95 ERSTELLT AM: 26.03.2014 Frage: Wie filtert man in Vivendi PEP die Mitarbeiterdaten nach bestimmten

Mehr

Service Innovation Lab. Prozessoptimierung für Dienstleistungen

Service Innovation Lab. Prozessoptimierung für Dienstleistungen Service Innovation Lab Prozessoptimierung für Dienstleistungen 2 Dienstleistungsprozesse im Unternehmen Ein reibungsloser Ablauf der unternehmensinternen Prozesse ist die Basis des wirtschaftlichen Erfolgs

Mehr

Softwaretechnik (Allgemeine Informatik) Überblick

Softwaretechnik (Allgemeine Informatik) Überblick Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Schnelleinstieg KASSENBUCH ONLINE (Mandanten-Version)

Schnelleinstieg KASSENBUCH ONLINE (Mandanten-Version) Seite 1 Schnelleinstieg KASSENBUCH ONLINE (Mandanten-Version) Bereich: Online-Services Inhaltsverzeichnis 1. Zweck der Anwendung 2. Voraussetzungen 2.1. Voraussetzung für die Nutzung 2.2. Organisationsanweisung

Mehr

TYPO3 Redaktoren-Handbuch

TYPO3 Redaktoren-Handbuch TYPO3 Redaktoren-Handbuch Kontakt & Support: rdv interactive ag Arbonerstrasse 6 9300 Wittenbach Tel. 071 / 577 55 55 www.rdvi.ch Seite 1 von 38 Login http://213.196.148.40/typo3 Username: siehe Liste

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Produktphilosophie erstellen

Produktphilosophie erstellen User Experience Produktphilosophie erstellen Bereich Anforderungen Aktivität Ziele Erleichterte Kommunikation zwischen Stakeholdern Designentscheidungen erleichtern/rechtfertigen schnell durchführbar einfach

Mehr

Ticket Center Quick Start

Ticket Center Quick Start AdNovum Informatik AG. Juli 13 2 Wozu dient das? Indem Sie Ihre Fehlermeldungen, Anfragen und Vorschläge zur Software stets im erfassen, helfen Sie uns, die Informationen zur einzelnen Meldung konsistent

Mehr

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist...

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist... Anwendungsbeginn Anwendungsbeginn dieser Norm ist.... Inhalt Einführung... 13 1 Anwendungsbereich... 16 1.1 *Zweck... 16 1.2 *Anwendungsbereich... 16 1.3 Beziehung zu anderen Normen... 16 1.4 Einhaltung...

Mehr

Software - Testung ETIS SS05

Software - Testung ETIS SS05 Software - Testung ETIS SS05 Gliederung Motivation Was ist gute Software? Vorurteile gegenüber Testen Testen (Guidelines + Prinzipien) Testarten Unit Tests Automatisierte Tests Anforderungen an Testframeworks

Mehr

Leitfaden zur Anlage einer Nachforderung. Nachforderung. 04.04.2013 Seite 1 von 11 RWE IT GmbH

Leitfaden zur Anlage einer Nachforderung. Nachforderung. 04.04.2013 Seite 1 von 11 RWE IT GmbH Leitfaden zur Anlage einer 04.04.2013 Seite 1 von 11 Inhaltsverzeichnis 1 Aufruf des RWE smanagements...3 2 Eingabe der Benutzerdaten...4 3 Erfassen der...5 4 Neue...6 4.1 Allgemeine Daten...7 4.2 Beschreibung...7

Mehr

Webseitennavigation mit dem Content-Management-System Imperia. Zentrum für Informationsverarbeitung Westfälische Wilhelms-Universität Münster

Webseitennavigation mit dem Content-Management-System Imperia. Zentrum für Informationsverarbeitung Westfälische Wilhelms-Universität Münster Webseitennavigation mit dem Content-Management-System Imperia Zentrum für Informationsverarbeitung Westfälische Wilhelms-Universität Münster 10. Januar 2006 Inhaltsverzeichnis 1. Einführung 4 2. Rubrikenstruktur

Mehr

Produkt und Methode. SIRIUSlogic 4.0 in der Praxis. SIRIUS Consulting & Training AG. www.sirius-consult.com. SIRIUS Consulting & Training AG

Produkt und Methode. SIRIUSlogic 4.0 in der Praxis. SIRIUS Consulting & Training AG. www.sirius-consult.com. SIRIUS Consulting & Training AG Produkt und Methode SIRIUSlogic 4.0 in der Praxis SIRIUS Consulting & Training AG www.sirius-consult.com SIRIUSlogic 4.0 Warum ein weiteres Prozessmanagement Werkzeug? Motivation Was muß das Tool leisten

Mehr

Request W17. PLANTA Request

Request W17. PLANTA Request PLANTA Request 2/8 Unternehmensprofil PLANTA Projektmanagement-Systeme GmbH ist einer der führenden Anbieter von Enterprise Project Management-Software auf dem europäischen Markt. PLANTA bietet seit 35

Mehr

Software Engineering II (IB) Testen von Software / Modultests

Software Engineering II (IB) Testen von Software / Modultests Testen von Software / Modultests Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Programm-Tests Tests sollen zeigen, dass ein Programm das tut was es tun soll sowie

Mehr

Kooperatives Testen Basis auch zur Testautomatisierung während der Softwareentwicklung. Dipl. Inform. Hans-Josef Eisenbach

Kooperatives Testen Basis auch zur Testautomatisierung während der Softwareentwicklung. Dipl. Inform. Hans-Josef Eisenbach Kooperatives Testen Basis auch zur Testautomatisierung während der Softwareentwicklung Dipl. Inform. Hans-Josef Eisenbach Der rote Faden Motivation zum Testen während der Softwareentwicklung Das Testkonzept

Mehr

Filterregeln... 1. Einführung... 1. Migration der bestehenden Filterregeln...1. Alle eingehenden Nachrichten weiterleiten...2

Filterregeln... 1. Einführung... 1. Migration der bestehenden Filterregeln...1. Alle eingehenden Nachrichten weiterleiten...2 Jörg Kapelle 15:19:08 Filterregeln Inhaltsverzeichnis Filterregeln... 1 Einführung... 1 Migration der bestehenden Filterregeln...1 Alle eingehenden Nachrichten weiterleiten...2 Abwesenheitsbenachrichtigung...2

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

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Alerts für Microsoft CRM 4.0

Alerts für Microsoft CRM 4.0 Alerts für Microsoft CRM 4.0 Benutzerhandbuch Der Inhalt des Dokuments ist Änderungen vorbehalten. Microsoft und Microsoft CRM sind registrierte Markenzeichen von Microsoft Inc. Alle weiteren erwähnten

Mehr

T1 - Fundamentaler Testprozess

T1 - Fundamentaler Testprozess AK 2 am Armin Beer, Support Center Test der Software- Entwicklung 1 für einen erfolgreichen Test? Projektteam strebt nach Qualität Aufwände sind eingeplant (Richtwerte) 20 bis 30% des Gesamtaufwandes In

Mehr

KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13. Dokumentation KREDITVERZEICHNIS. Teil 2. Konfiguration

KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13. Dokumentation KREDITVERZEICHNIS. Teil 2. Konfiguration KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13 Dokumentation KREDITVERZEICHNIS Teil 2 Konfiguration Stand 20.02.2013 KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 2/13 Inhalt 1. KONFIGURATION...

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche etutor Benutzerhandbuch Benutzerhandbuch XQuery Georg Nitsche Version 1.0 Stand März 2006 Versionsverlauf: Version Autor Datum Änderungen 1.0 gn 06.03.2006 Fertigstellung der ersten Version Inhaltsverzeichnis:

Mehr

Compliance Monitoring mit PROTECHT.ERM

Compliance Monitoring mit PROTECHT.ERM covalgo consulting GmbH Operngasse 17-21 1040 Wien, Austria www.covalgo.at Compliance Monitoring mit PROTECHT.ERM Autor: DI Mag. Martin Lachkovics, Dr. Gerd Nanz Datum: 20. Oktober 2014, 29. April 2015

Mehr

GRIDWORKS. GRIDWORKS Sitzungsverwaltung. innovative Lösungen für Microsoft SharePoint. Seite 1

GRIDWORKS. GRIDWORKS Sitzungsverwaltung. innovative Lösungen für Microsoft SharePoint. Seite 1 GRIDWORKS Sitzungsverwaltung Seite 1 Mit GRIDWORKS zur individuellen Lösung auf Basis SharePoint Mit GRIDWORKS lassen sich mit geringem Entwicklungs- und Anpassungsaufwand individualisierte Lösungen erstellen.

Mehr

Agiles Testen - Ein Erfahrungsbericht Thomas Schissler / artiso AG Michael Lierheimer/ infoteam software AG

Agiles Testen - Ein Erfahrungsbericht Thomas Schissler / artiso AG Michael Lierheimer/ infoteam software AG Agiles Testen - Ein Erfahrungsbericht Thomas Schissler / artiso AG Michael Lierheimer/ infoteam software AG Herausforderungen bei agilem Testen Klassische Projektstruktur Projektleiter Entwickler QS-Abteilung

Mehr

Prozessportal. Neben Prozessbeschreibungen, bietet es sich an, Abläufe grafisch zu visualisieren.

Prozessportal. Neben Prozessbeschreibungen, bietet es sich an, Abläufe grafisch zu visualisieren. Das Prozessportal der FHöV NRW Prozessportal Das Prozessportal bietet allen Mitarbeiterinnen und Mitarbeitern der der FHöV NRW die Möglichkeit, sich über bereits beschriebene und abgebildete interne Prozesse

Mehr