Ihre Suche

Ihre Suche

Cloud Brokerage

Whitepaper Cloud Brokerage
Multi-Cloud-Ansätze im Griff
Zum Dokument

Referenzen

AH Rittersbacher

Mehr Tempo mit VaudisPro

Die Händlersoftware VaudisPro unterstützt die Verkaufs- und Serviceprozesse in den Niederlassungen der Autohandelsgesellschaft Rittersbacher.
Zur Kundenlösung
AH Prengemann

Mit Xenon alle Finanzen im Blick

Finanz- und Buchhaltungssystem Xenon liefert dem Autohaus Prengemann aktuelle Kennzahlen.
Zur Kundenlösung
AH Schade und Sohn

Mit VaudisPro breiter aufgestellt

Um neben Mercedes- auch VW-Kunden zu betreuen, führt das Autohaus Schade u. Sohn als weiteres Dealer-Management-System VaudisPro ein.
Zur Kundenlösung
HIL GmbH | Beispiel für ein hochsicheres Weitverkehrsnetz

Hochsicheres Weitverkehrsnetz dank Kryptoboxen

Beispiel für ein hochsicheres Weitverkehrsnetz: Die HIL GmbH arbeitet mit kryptologisch abgesicherter Datenübertragung bei allen Material- und Logistikanwendungen.
Zur Kundenlösung
Flughafen Scheremetjewo Moskau

Flughafen Scheremetjewo Moskau

Durch die Integration einer SAP-Rechnungswesenkomponente hat der Flughafen seine Rechnungsstellung automatisiert und die Liquidität verbessert.
Zur Kundenlösung
Baden-Württemberg

Landesweites SAP

Seit der Einführung eines zentralen SAP-Systems verfügt das Land Baden-Württemberg über Controllinginstrumente – wie ein privates Unternehmen.
Zur Kundenlösung
Magna International Inc.

Dynamic Sourcing als SAP-Betriebsmodell

Der österreichisch-kanadische Automobilzulieferer Magna hat den Betrieb seiner SAP-Systeme auf Cloud Computing umgestellt.
Zur Kundenlösung

Wählen Sie eine Kategorie, um auf der Übersichtsseite zugehörige Referenzen zu sehen.

Wählen Sie eine Kategorie, um auf der Übersichtsseite zugehörige Referenzen zu sehen.

13. September 2013 Lösungen

„Cloud Partner of the Year“ – T-Systems von Cisco ausgezeichnet

“Cloud Partner of the Year“

T-Systems ist für Cisco als Cloud-Partner erste Wahl.

Meine InfoBox

Die Anzahl der Dokumente in der InfoBox ist beschränkt auf: 20
Mit der InfoBox können Sie Informationen wie Grafiken, Whitepaper und sogar ganze Seiten der T-Systems Website komfortabel an einem zentralen Ort sammeln und später downloaden und versenden. Klicken Sie dafür einfach auf das InfoBox-Symbol, das sie auf vielen unserer Seiten finden können:Sie haben noch keine Dokumente in der InfoBox abgelegt. Ihre InfoBox ist zur Zeit leer.
Gesamtgröße 0 MB
Schließen Ihre E-Mail wurde erfolgreich versandt. Ich möchte diese Dokumente versenden. * Verpflichtende Angaben



(Mehrere Empfänger mit Komma trennen)

Testing Services Blog

Willkommen im T-Systems Blog zu Testing Services Hier diskutieren Experten den Einsatz der Technologie in der Unternehmenswelt. Wir freuen uns auf Ihr Interesse und laden Sie herzlich zur Teilnahme ein!

Kürzlich auf der iqnite: ‚agil in aller Munde‘

Testing Services Blog / 14.05.2013

Bei mehr als der Hälfte der Vorträge auf der iqnite 2013 standen meines Erachtens die Herausforderungen Flexibilität und Transparenz und der Wunsch wissen zu wollen was am Ende der Lieferkette raus kommt im Fokus.

Wie werden diese Herausforderungen angegangen?

Eigentlich jeder der Vortragenden beantwortete das mit dem Vorschlag zu einer agilien Vorgehensweise. Nur ein Vortrag beschäftigte sich mit den Themen „Testing as a Service (TaaS)“ und einem begleitenden Transitions- & Transformations-Modell. Interessanterweise sind auch hier die Aspekte Flexibilität, Transparenz und genau wissen was man bekommt, Auslöser für eine kundenspezifische Lösung.

Gibt es Unterschiede?

Ja, und zwar einen entscheidenden: bei der Transformation zu einer agilen Vorgehensweise fielen immer wieder Sätze wie diese: „alle Mitarbeiter werden es nicht mitmachen wollen“, „ alle werden es nicht schaffen“, „man wird MA verlieren“. Das machte mir Angst! Im Transitionsmodell zu “Testing as a Service” hingegen gibt es eigenständige Schritte zum „Human Change Managment“ (HCM), die das Ziel haben alle Mitarbeiter und deren Expertenwissen in die Zielorganisation zu übernehmen und wo nötig für das künftige Vorgehen entsprechend zu qualifizieren.

Was ist für mein Umfeld die richtige Vorgehensweise?

Ich denke, eine agile Vorgehensweise ist nützlich und hat unter bestimmten Rahmenbedingungen Vorteile. Es ist aber kein Allheilmittel! Die Best Practices des Vortrags zum „Testing as a Service“ wiesen daraufhin : „Die gesunde Mischung macht‘s“.

Eine komplette Umstellung auf eine agile Vorgehensweise ohne eine durchdachte und nachhaltige Gesamtintegration kann nicht erfolgreich sein. Auch eine 100%ig Umstellung aller Testing Services auf ein TaaS-Modell ohne eine Möglichkeit Teilbeauftragungen über gewohnte kommerzielle Modelle abzuwickeln werden scheitern.

Meine Meinung: Erfolgreich ist nur eine Lösung, die sich an den Erfordernissen des Kunden ausrichtet und nicht an Vorgehensweisen die gerade ‚in aller Munde‘ sind.

 

Oft erscheinen die Rechnungen für erbrachte Leistungen intransparent, nicht nachvollziehbar oder überhöht. Und die Anwendung funktioniert vielleicht immer noch nicht fehlerfrei.

Was wäre, wenn der Kunde bei Softwaretests nur noch das bezahlt, was er auch wirklich an Leistung bekommt -also nach pay-per-use Modellen, dem klassischen Stückpreis, abrechnet? Er hätte damit eine Budget- und Planungssicherheit, sowie die gewünschte Transparenz über die erbrachte Leistung.

Klasse – aber wie soll das gehen?

Gerade bei Testservices, mit immer wiederkehrenden gleichartigen Leistungseinheiten, ist eine pay-per-use Bestellung und Abrechnung möglich. Ich denke z.B. an die Spezifikation und Durchführung funktionaler Tests, insbesondere Regressionstests. Auch die Testautomatisierung ist für mich ein möglicher Kandidat. Unterschiedliche Komplexität der Testfälle berücksichtige ich im entsprechenden Kalkulationsmodell.

Hört sich einfach an, aber was sind die Knackpunkte?

Es gibt sicher ein paar Voraussetzungen, die Kunden und Lieferant erfüllen müssen!

Dies sind z.B. ein hoher Reifegrad in der Testorganisation und der Prozesse. Klar definierte Messgrößen (KPI’s) und Service Level Agreements (SLA’s) unterstützen dabei. Damit der Kunde weiß was er für sein Geld bekommt sind die Liefergegenstände detailliert beschrieben.

Das Modell wird aber nur dann zur Erfolgsstory wenn beide Parteien ihren Verpflichtungen nachkommen:  flexible Lieferverpflichtung auf der einen Seite, Erfüllung von Mitwirkungsleistungen auf der anderen. Nur so kann es klappen.

Schon mal über die Implementierung von pay-per-use Modellen nachgedacht?

Sprechen Sie mich an!

 

Alles as a Service?

Testing Services Blog / 27.02.2013

Eine Gartner-Studie hat herausgefunden, dass PaaS (Platform as a Service) derzeit zwar im Schatten von SaaS (Software as a Service) und IaaS (Infrastructure as a Service) steht, aber in naher Zukunft wohl nachhaltig an Bedeutung zunehmen wird.

Spontan frage ich mich, ob der „as-a-Service“-Ansatz inzwischen inflationär gehandelt wird?

Überhaupt nicht. Es ist ein Teil von Everything as a Service und schließlich hängt alles mit der „Cloud“ zusammen - dazu existieren Unmengen von Materialien und (fast) ebenso viele Meinungen.

Spontan frage ich mich natürlich, ob es neuerdings auch „Testing-as-a-Service“ gibt? Diese Frage kann mit Fug und Recht mit „Ja“ beantwortet werden!

More

 

Wozu brauche ich eigentlich diese ISTQB-Kurse?

Testing Services Blog / 11.02.2013

Wozu brauche ich eigentlich diese ISTQB-Kurse? Ich kann doch auch ohne diese Kurse ein guter Tester sein! – Eine Frage eines Teilnehmers während des letzten Foundation-Level-Kurses. Eine gute Frage!

Natürlich gibt es gute Tester, die nie einen ISTQB-Kurs besucht, sondern sich das notwendige Wissen selbst angeeignet haben, z.B. durch Selbststudium entsprechender Literatur (training-off-the-job) oder durch Projekteinsätze mit guter Einweisung (training-on-the-job).
Allerdings garantieren ISTQB-Kurse, dass sie tatsächlich ein Grundlagenwissen in allen relevanten Testbereichen aufbauen – bei einem Selbststudium besteht das Risiko, dass Sie ggf. wichtige Bereiche auslassen (außerdem ist ein Selbststudium nicht jedermanns’ Sache). Bei Projekteinsätzen besteht das Risiko, dass Projekte relevante Standards – z.B. IEE 829 für Testdokumentation – gar nicht oder nicht korrekt anwenden und so ein unvollständiges oder – schlimmer noch – falsches Testwissen aufgebaut wird.

Neben diesem Testwissen benötigen Sie allerdings noch technisches Wissen, z.B. grundlegendes Wissen über Softwarearchitekturen und ein paar technische Skills – wie komme ich an die Daten in der Datenbank? Wie interpretiere ich die Daten in den Logfiles? Usw. Diese Skills sollten Sie in Ihrer fachbezogenen Ausbildung erworben haben. Aber auch hier gilt: bleiben Sie up-to-date. Keine andere Branche ist schnelllebiger als die Informationstechnik.

Der dritte Skillbereich betrifft das entsprechende Anwendungsgebiet. Sie müssen Ihren Kunden und seine Prozesse kennen um Tests korrekt spezifizieren und durchführen zu können – denken Sie z.B. an die erfahrungsbezogenen Testmethoden. Diesen Wissensbereich können Sie sich nur durch training-on-the-job erwerben.

Neben diesen 3 Bereichen von Hard-Skills gibt es noch ein paar Soft-Skills, die sie als guter Tester mitbringen sollten.
Adam Osburn geht auf diese Skills in seinem Artikel “What makes a good tester?” in der Ausgabe der TestingExperience vom 19.09.12 ein.

Adam Osburn benutzt zur Charakterisierung der persönlichen Eigenschaften eines Testers das Fünf-Faktoren-Modell von Lewis R. Goldberg, nach dem sich der persönliche Charakter in 5 Bereiche einteilen lassen:

  • Agreeableness – Verträglichkeit
  • Conscientiousness – Gewissenhaftigkeit
  • Introversion/Extraversion – Introversion/Extraversion / weltoffen
  • Neuroticism – Neurotizismus
  • Openness to experience – Offenheit für Erfahrungen

Nach Osburn benötigt ein guter Tester ein hohes Maß an Verträglichkeit, ein mittleres Maß an Gewissenhaftigkeit, ein mittleres Maß an Extraversion/Weltoffenheit, ein geringes Maß an Neurotizismuss und ein hohes Maß an Offenheit. Neben dieser Einteilung gibt Osburn noch Tipps woran man solche Personen erkennt.

Zusätzlich zu diesen Charaktereigenschaften, die sich nur bedingt beeinflussen lassen, sind nach Osburn zusätzlich noch folgende Eigenschaften nötig, die sich trainieren und beeinflussen lassen:

  • Tester haben gute analytische Fähigkeiten
  • Tester haben hohe kommunikative Kompetenzen
  • Tester verstehen den Gesamtzusammenhang
  • Tester haben gute technische Fähigkeiten
    (diesen Bereich stellt Osburn in Frage – nach Osburn benötigen Tester kein Wissen über Kodierung)
  • Leidenschaft für Analyse und Test

Der letzte Punkt ist der ausschlaggebende. Nur wenn sie das, was sie tun – sei es privat oder beruflich – mit Leidenschaft tun, erst dann werden sie in diesem Bereich richtig gut.
Gerade dieser Bereich ist für Tester enorm wichtig – geht es doch darum Fehler zu finden, und wer möchte das schon?

Daher wünsche ich Ihnen für Ihren nächsten Test viel Spaß und viel Leidenschaft. Der Erfolg stellt sich damit zwangsläufig ein.

 

Test process improvement on an agile project

Testing Services Blog / 15.01.2013

Recently I attended T-System’s first Expert Level training course concerning test process improvement (this was the pilot course before official ISTQB accreditation). On one of these training days we discussed test process assessments with different Software Lifecycle Models.

We agreed that model-based test process assessments for projects using typical waterfall models is useful and will contribute to increasing maturity of testing processes as well as interfacing processes.

Later on the referent turned to agile methods such as SCRUM. Hey, everyone on this course knew that I’m driving agile methods in our company – so they turned to me. The implicit question was: “Does TPI NEXT® work on agile projects?”.

Spontaneously I was wondering why it shouldn’t work?! Of course you can interview agile team members concerning their experiences with tests.

But – taking a closer look to the key areas of an TPI NEXT® assessment doubts came up. Honestly, can you imagine asking an agile team member about test planning? Or test strategy? Working out strategies which will determine the working guideline for the next 5 years? As far as I understood agile development this would be a NOGO.

Furthermore – if there are problems in an agile project isn’t it better to assess the whole process? Team responsibility and committed “Definition of done” are very valuable characteristics of an agile project. Looking only on testing for improvement would separate tester and their contribution from the whole team success.

Consequently, I suggest the use of API – agile process improvement – even for testing!

Anyone there who will work on that with me?

 

The success story of ISTQB-courses continues: the worldwide first expert level course “Improving the Testing Process” was completed with the second part at T-Systems in Munich from 19. to 22. november.

The course began with the first part held last year in Mülheim. The first part mainly consisted of the generic improvement process (Deming cycle, IDEAL improvement framework) and the different improvement approaches (model based approaches like TPI NEXT or TMMI, analytical based approaches like causal analysis or GQM approach).

The second part covered the change process including critical success factors as well as a lot of soft skills

Between the two parts every participant conducted a test process assessment in a real-life-project as a workplace exercise which was very valuable, as every trainee confirmed.

The course is quite demanding. I enjoyed the high-class discussions within the audience.

For more information about the course content have a look at the syllabus at http://www.istqb.org/downloads/viewcategory/18.html

Now we are all looking forward to the certification tests.

Participants of ISTQB expert level course "Improving the Testing Process"

Participants of ISTQB expert level course "Improving the Testing Process"

 

Taking shape! Career paths for testing

Testing Services Blog / 05.11.2012

Career paths for testers is a hot topic. As the demand for skills steadily increases, companies are looking for ways to get testing staff with top skills. As we all know, these skills don’t just grow on trees; they have to be built up over time. Having a defined career path for testers to follow is a great way to encourage the development of these top testing skills. The International Software Testing Qualifications Board (ISTQB) provides this career path.

Recently I had the chance to talk about this with over 120 people at the Hungarian Testing Board’s testing conference. Having accepted the invitation to talk about the ISTQB’s plans for career paths, I thought a few “hand-up” questions would be a good start. “OK, how many of you have already the ISTQB Certified Tester certificate at Foundation level”. Up shot the hands – almost 50% – great start! Let’s try with the Advanced Level. Again, about 50% of those raised hands remained raised. Fantastic! This was the kind of response I would like to see worldwide.

Now, career paths for testers don’t stop there – we have the Expert Level coming in 2013 and I was interested in the response to that. First an explanation of what it’s about and then a quick feedback – not so great. Why is that? Probably the main thing that puts people off Expert Level is the degree of difficulty. Yes, the bar is set high, but that’s why we call it “expert” – being an expert should have some value.

Closer discussion actually showed that people were a bit frightened by the challenge of expert level. My advice – don’t be! If you already achieved advanced level, all you need to do is take a look at the expert syllabus for, say, test management and make your own decision. I would bet you find yourself saying “I could do that”.

2012 is the 10th anniversary of ISTQB – happy birthday! So much has been achieved – over 260,000 certified testers worldwide. Why not take a look at the career paths that have been developed at ISTQB.

 

Kann man Qualität reintesten?

Testing Services Blog / 04.10.2012

Diese Frage stelle ich mir schon seit Beginn meiner Laufbahn als Testspezialist. Damals war ich in einem großen Testprojekt als Test Analyst eingesetzt. “Qualität kann man nicht reintesten”, behauptete mein damaliger Projektleiter. Ich war bestürzt. Schließlich war doch das meine damalige Aufgabe: effektive Tests spezifizieren und durchführen um mit so wenig Aufwand wie möglich so viele Fehler wie nötig zu finden. Mit der Behebung der gefundenen Fehler durch die Entwicklungsteams wurde die Qualität doch erhöht, oder etwa nicht?

Sicher, auf dieser einfachen Ebene stimmt das. Schon im ISTQB Foundation Level lernen wir, dass eines der Hauptziele von Tests das Finden von Fehlern ist:

“Weiterhin kann es dazu beitragen, die Qualität des Softwaresystems zu erhöhen, indem Fehlerzustände vor der betrieblichen Freigabe gefunden und behoben werden.” [ISTQB CTFL Lernplan 2011 deutsch]

Mit dieser Einstellung kommt man allerdings über ein gewisses Grundmaß an Qualität nicht hinaus, wie auch im Nachhinein ein Blick auf die Fehler beweist, die zwar gefunden, aber nicht behoben wurden (Gründe für nicht behobene Fehler sind z.B. hohe Kosten für die Behebung oder zu lange Behebungszeiten). Testen auf dieser Stufe wird von den meisten Projektverantwortlichen als notwendige Tätigkeit empfunden, die einfach der Kodierung nachgelagert ist und für ein prozesskonformes Vorgehen formal erforderlich ist.

Ein Vergleich mit Testen auf höheren Reifegraden zeigt, dass für eine höhere Softwarequalität allerdings wesentlich mehr getan werden muss: Testen ist dann nicht länger entwicklungsnachgelagert, sondern entwicklungsbegleitend. Anforderungs- und Code-Reviews werden mit dem Ziel des frühzeitigen Findens von Fehlern eingesetzt und sind für das Bestehen von Quality Gates essentiell. Aber auch die Qualität des Testprozesses selbst wird betrachtet und immer weiter verbessert und optimiert.

Ein informelles Assessment zum Beispiel nach TPI (http://www.sogeti.de/tpi-test-process-improvement.html) oder TMMi (http://www.tmmifoundation.org/html/tmmiorg.html) bietet eine gute Standortbestimmung und den idealen Einstig in die Prozessverbesserung.

Heute weiß ich durch leidvolle Projekterfahrung und selbst durchgeführte Assessments, dass mein damaliger Projektleiter Recht hatte. Die Anlage für hohe Produktqualität – insb. gute Spezifikationen – lassen sich eben nicht durch die reine Durchführung dynamischer Tests sicherstellen – so umfangreich die Testspezifikationen auch sein mögen. Und der Schritt zu höheren Teststufen erfordert ein Umdenken auf allen Ebenen – nicht nur innerhalb des Testprojekts.

In diesem Sinne – viel Erfolg beim Erreichen des nächsten Testlevels!

 

Bei der Durchführung von Softwareprojekten stehen viele Unternehmen oft vor der Frage, wie zuverlässig und stabil die Implementierung ist. Die Fragestellungen hängen oftmals von den beteiligten Personengruppen ab. Während sich Anwender und Nutzer der neuen Software um die fehlerfreie Realisierung ihrer Wünsche und Anforderungen kümmern, sind aus IT Sicht eher Fragestellungen nach dem Verlauf des Projektes und dem Qualitätsstand relevant. Um hier keine Antworten schuldig zu bleiben, empfiehlt sich der Aufbau eines effizienten Testmanagements

1. Am Anfang war das Chaos…
Neulich im Lenkungsausschuss des Softwareprojektes Alles neu 2012:

„Wie steht eigentlich das Projekt? Welche Anwendungsfälle sind eigentlich schon fertig? Sind diese Anwendungsfälle auch ausreichend getestet worden? Waren die Testfälle fehlerfrei? Wie viele Fehler sind denn gefunden worden?“

Diese oder ähnliche Fragestellungen hat jeder, der sich mit der Implementierung von Software beschäftigt, schon oft gehört. Antworten darauf zu geben, fällt jedoch oft schwer, da der Test einer Implementierung in vielen Unternehmen immer noch stiefmütterlich behandelt wird. Testen erfolgt vielfach durch den Entwickler, der diese Aufgabe eher als notwendiges Übel betrachtet und wenig Aufwand in die Dokumentation von Testfällen und –ergebnissen investiert. Belastbare Aussagen zum Stand der Qualität sind somit nur schwierig und basieren meist auf Schätzungen. Ein weiterer Effekt dieses Testvorgehens ist die schwierige Reproduktion von Testszenarien und daraus resultierenden Fehlern. Werden Testfälle nicht beschrieben und entdeckte Abweichungen diesen nicht zugeordnet, ist die wiederholte Ausführung und die damit verbundene Überprüfung der Fehlerbeseitigung im besten Fall nur durch die gleiche Person möglich. Liegt zwischen Fehlerentdeckung und –beseitigung ein großer zeitlicher Abstand, wird es selbst für diese Person schwierig.

Die oben genannten Schwächen können durch den Aufbau eines Testmanagements behoben werden und führen so neben einer intensiv getesteten Software gleichzeitig auch zu der Möglichkeit qualitativ und quantitativ belastbare Aussagen zum Fortschritt und Stabilität eines Softwareprojektes machen zu können.

2. Wie viel Test ist notwendig?
Betrachtet man die aktuellen Zahlen des Chaos Report kann der Eindruck entstehen, dass Softwareprojekte eher dazu tendieren zu scheitern als erfolgreich abgewickelt zu werden. Der Einwand, dass die erhobenen Zahlen, nur für den amerikanischen Markt gelten, ist sicherlich berechtigt. Aber trotzdem wird man das Gefühl nicht los, dass diese Zahlen auch für den deutschen Markt gültig sein könnten. Es stellt sich daher die Frage, wie kann das Scheitern eines Projektes verhindert werden. Neben einer guten Anforderungsbeschreibung und einer kompetenten Umsetzung dieser Anforderungen kommt dem Test eine entscheidende Bedeutung zu. Je intensiver und früher die Erfüllung der technischen und fachlichen Anforderungen überprüft werden, desto geringer ist das Risiko des Scheiterns. Nur – wer erstellt und überprüft diese Testfälle?

Auch zu Beginn des Projektes Alles neu 2012 wird diese Frage gestellt. Der erste Schritt ist daher die Organisation des Testens zu klären. Vier mögliche Modelle werden geprüft:

  • Tester im Entwicklungsteam
    Bei dieser Organisationsform des Testens gibt es keine speziellen Personen, die den Test übernehmen. Vielmehr übernimmt ein Entwickler kurzfristig die Rolle des Testers und überprüft die Implementierung eines anderen Entwicklers.
  • Testteam im Projektteam
    Innerhalb der Projektorganisation wird ein Team von Mitarbeitern gebildet, dessen Aufgabe ausschließlich die Definition und Durchführung von Testfällen ist. Voraussetzung hierfür ist die Bereitstellung von lauffähiger Software in abgestimmten Zyklen.
  • Testcenter
    Unabhängig vom Projekt wird im Unternehmen eine eigenständige Organisationseinheit gebildet. Aufgabe dieser Instanz ist die Überprüfung aller Softwareprojekte vor Inbetriebnahme. Darüber hinaus ist es denkbar, dass Testspezialisten dieser Organisation unterstützend und beratend in den Softwareprojekten mitwirken.
  • Test Outsourcing
    Anforderungen an Umfang und Unabhängigkeit der Testaktivitäten können dazu führen, dass Überprüfungen von technischen und fachlichen Implementierungen von externen Testorganisationen durchgeführt werden. Bei der Auswahl dieses Testorganisationsmodells kommt der Anforderungsbeschreibung besondere Bedeutung zu.

Eine Empfehlung für die Auswahl eines dieser Modelle kann nicht pauschal gegeben werden. Faktoren wie Projektgröße, Kritikalität oder Ressourcenbedarf sind dabei individuell zu bewerten. Grundsätzlich gilt jedoch, dass die Unabhängigkeit einer Testorganisation von großer Bedeutung ist.

Da im Projekt Alles neu 2012 der Aufbau einer selbständigen und unabhängigen Testorganisation begonnen werden soll, entscheidet man sich hier für den Ansatz der Testexperten im Projektteam.

3. Naturtalente oder Ausbildung?

So vielschichtig wie die Aufgabe des Testteams sollte auch seine Besetzung sein. Betrachtet man die Anforderungen an ein Softwaresystem, sind nicht allein funktionale Gesichtspunkte zu überprüfen.
Kriterien wie Übertragbarkeit, Änderbarkeit, Effizienz, Benutzbarkeit und Zuverlässigkeit erfordern spezielle Kenntnisse, die im Testteam zur Verfügung stehen müssen.

Zur Abdeckung der verschiedenen Kompetenzen muss bei der Besetzung des Testteams auf eine heterogene Zusammensetzung geachtet werden. Sowohl Mitarbeiter mit fundiertem Domänenwissen als auch Techniker mit guten Architektur- und Implementierungskenntnissen sind gute Kandidaten für ein Testteam.

Nach der Auswahl der Mitarbeiter kommt der Ausbildung auf einen gleichen Wissensstand erhebliche Bedeutung zu. Die Anwendung von strukturierten Testfallermittlungsmethoden wie Ursache-Wirkungs-Analyse, Äquivalenzklassenbildung oder Grenzwertanalyse führen zu einer guten Testabdeckung. Die Anwendung dieser Methoden sowie die daraus abgeleiteten Spezifikationen von Testfällen sind Handwerkszeug jedes Testers und müssen erlernt werden. Ein Curriculum für die Ausbildung von Testern stellt der Lehrplan des ISTQB (International Software Testing Qualifications Board) dar. Anhand der hier vorgegebenen Inhalte lässt sich festlegen, welche Kompetenzen im Testteam vorhanden sein müssen. Es empfiehlt sich daher, die Mitarbeiter der Testorganisation zumindest mit den Grundlagen des Softwaretestens vertraut zu machen und eine Zertifizierungsmaßnahme durchzuführen.

4. Test early, test often!
Die Praxis in vielen Projekten sieht vor, dass System- oder Abnahmetests am Ende des Projektes durchgeführt werden. Dabei entsteht häufig die Situation, dass durch Entwicklungsabteilungen falsch interpretierte oder fehlerhaft implementierte Anforderungen erst spät im Projektverlauf aufgedeckt werden. Nachträgliche Änderungen oder Ergänzungen führen in vielen Fällen zu Zeit- und Budgetüberschreitungen.

Auch im Projekt Alles neu 2012 wird diese Problemstellung diskutiert. Um frühzeitig auf Missverständnisse hinweisen zu können, begleitet das Testteam von Anfang an die Entwicklung. Genauso wie die Mitarbeiter des Entwicklungsteams arbeitet sich das Testteam in Anforderungen ein. Die Interpretation des Testteams wird in Testfälle umgesetzt. Der Vorteil dieser Vorgehensweise liegt auf der Hand – die aufgetretenen Fehler wurden frühzeitig erkannt und können schnell und mit geringem Aufwand korrigiert werden. Eine Anpassung der Implementierung oder der Testspezifikation führt bereits in den ersten Phasen dazu, dass sichergestellt werden kann, dass sowohl Anforderungen getroffen werden als auch eine fehlerfreie Implementierung erfolgt. Bei konsequenter Verfolgung dieser Strategie und modularem Aufbau der Software ist es möglich, bereits im Verlauf des Projektes Teilabnahmen zu erzielen. Die Sicherheit bereits früh die Bestätigung der korrekten Implementierung durch den Anwender zu erhalten, verhindert im abschließenden Gesamtsystemtest böse Überraschungen.

Bei dieser Vorgehensweise kommt einem Regressionstest eine entscheidende Rolle zu. Hier stellt sich nun die Frage, wie bei voranschreitender Implementierung gleichzeitig der Aufwand für die weiterhin korrekte Ausführung der bereits abgenommenen Funktionen gewährleistet werden kann. Die Antwort heißt Testautomatisierung! Testautomatisierungsspezialisten des Testteams greifen die Spezifikationen auf und gewährleisten so, dass bereits abgenommene Funktionen wiederholt und automatisch überprüft werden. Dieses Frühwarnsystem sichert so die bestehende Software ab und erlaubt einen konzentrierten Fortschritt im Projekt.

5. Tue Gutes und rede darüber!
Einige Wochen später im Lenkungsausschuss des Projektes Alles neu 2012:

Manager: „So, jetzt haben wir einen neuen Testprozess eingeführt! Welchen Nutzen bringt mir das?“
Projektleiter: „Nun, ich denke, ich kann Ihnen bereits jetzt anhand von belastbaren Zahlen sagen, wie es um die Qualität der Software steht!“
Manager: „Das wäre großartig!“

Die strukturierte Durchführung von Softwaretests liefert bei gleichzeitiger Dokumentation von Ergebnissen eine auswertbare Datenbasis, die es erlaubt, zu jedem Zeitpunkt das Projekt bewerten zu können. Reporting ist daher ein zusätzlich entstehendes Erzeugnis, das viele Optionen des Projektmanagements unterstützt. Genauso wie die Entwicklungsabteilung zum Ende einer Phase lauffähige Software als Ergebnis zur Verfügung stellt, stellt das Testteam seine Ergebnisse in Form eines Testberichts zur Verfügung. Aussagen über die durchgeführten Tests, Einschätzung und Priorisierung der gefundenen Abweichungen und Informationen zum Reifegrad der Software werden anschaulich präsentiert.

Testfortschritt, verbleibender Aufwand, Testabdeckung oder Anzahl Abweichungen werden somit nicht mehr geschätzt sondern reproduzierbar und nachweislich dokumentiert. Die Dokumentation sollte auf keinen Fall im Schrank verstauben. Vielmehr ist sie ein wichtiges Hilfsmittel der Projektsteuerung. Die in einander greifenden Prozesse des Projekt-, Entwicklungs- und Testmanagements erlauben es, Situationsbewertungen und Prognosen zu erstellen. Betrachtet man allein die Anzahl der gefundenen Abweichungen, ist es dem Entwicklungsleiter möglich seine Ressourcen so einzusetzen, dass neben der Weiterentwicklung genügend Kapazitäten für die Fehlerbeseitigung zur Verfügung stehen.

Bevor nun jedoch der Eindruck entsteht, dass das Testen von Software ein destruktiver Prozess ist, der lediglich dazu dient Schwächen der Entwicklung aufzudecken, sollte man sich ganz klar den Gewinn für das Gesamtprojekt vor Augen führen. Natürlich dient die Durchführung von Tests dazu Fehler und Abweichungen aufzudecken. Genauso ist jedoch auch die Dokumentation und Veröffentlichung von erfolgreichen Testläufen integraler Bestandteil der Testdokumentation. Das Bild einer geprüften, verlässlichen Software bei gleichzeitiger Umsetzung von neuen Funktionen, schafft neben dem Vertrauen beim Management auch Benutzerakzeptanz. So trägt Testmanagement wesentlich zum Projekterfolg bei!

6. Tools, Tools, Tools

Nachdem im Projekt Alles neu 2012 die ersten Erfahrungen mit Testmanagement gemacht wurden, stellte sich nun die Frage nach dem Tooleinsatz. Die bisher genutzten Office-Tools sind ein guter Einstieg, um Testfälle zu beschreiben und auswerten zu können. Bei fortschreitender Komplexität ist der Einsatz von testunterstützenden Werkzeugen jedoch sinnvoll.

Vor der Suche nach einem Testmanagementwerkzeug wird zunächst ein Anforderungskatalog erstellt, der festlegt, welche Unterstützung das Tool bieten muss. Dabei kommt es nicht nur auf die reine Verwaltung von Testfällen und –ergebnissen an. Zu hinterfragen sind Konzepte wie das Versionsmanagement oder die Revisionssicherheit. Existiert in der Organisation ein Anforderungsmanagementwerkzeug, das integriert werden muss? Ist bereits ein Defectmanagementwerkzeug eingesetzt oder soll das Testmanagementwerkzeug dieser Funktion abdecken? Gibt es am Markt Werkzeuge, die eine Integration einer Testautomatisierungssoftware anbieten? Erst nach Erstellung dieser Anforderungsliste ist es sinnvoll, sich mit der Auswahl eines Testmanagementwerkzeugs zu beschäftigen.

Ein Vergleich von kommerziellen und Open-Source Produkten empfiehlt sich in jedem Fall. Die Flagschiffe am Markt bieten oft eine Funktionsvielfalt, die für das Testmanagement nicht unbedingt notwendig sind. Denn über allem steht die Forderung, dass ein Testmanagementwerkzeug den etablierten Testprozess unterstützen soll – nicht umgekehrt!

7. Am Ende wird alles gut

Nach der Auslieferung des ersten Meilensteins im Projekt Alles neu 2012 wird erneut ein Lenkungsausschuss einberufen:

Fachbereichsleiter: „Das war ein gute Auslieferung! Stabil mit passender Funktionalität!“
IT-Manager: „Das ist eine erfreuliche Nachricht!“
IT-Projektleiter: „Dank des strukturierten Testens können Sie auch in Zukunft von dieser Qualität ausgehen!“

Die Einführung eines strukturierten Testmanagements gewährleistet neben frühem Feedback für die Entwicklung eine reibungslose Auslieferung an den Anwender. Von entscheidender Bedeutung ist dabei nicht der Einsatz von Tools oder einer bestimmten Organisationsform. Wichtiger ist die Etablierung eines Prozesses, die Verteilung der Testzuständigkeiten und die Dokumentation von Testspezifikationen und –ergebnissen.

 

Test First oder der Nachweis des Higgs-Boson

Testing Services Blog / 31.08.2012

Am CERN wurde im Juli 2012 nach jahrzehntelanger Suche wahrscheinlich das “Gottesteilchen” Higgs-Boson gefunden und sogleich weltweit als “historischer Meilenstein” und Bestätigung des Standardmodells der Teilchenphysik gefeiert.

Zugleich wurde mir damit aber erneut vor Augen geführt, dass – unabhängig von Zeitskalen – jedes Modell der Bestätigung oder auch Widerlegung durch das Experiment bedarf.

Wie viel einfacher haben wir es doch im Test von SW-Systemen, wenn wir in unseren Testumgebungen weitgehend die Bedingungen herstellen und kontrollieren können, unter denen wir das Systemverhalten untersuchen!

Dennoch wird die Durchführung der Tests häufig verzögert unter Hinweis auf vermeintliche Prozess- und Dokumentationserfordernisse, fehlende Voraussetzungen, …  Jeder von uns könnte aus seiner Praxis sicherlich unmittelbar eine Vielzahl von Gründen beisteuern.

Umso wichtiger ist es, dass wir uns als Tester frühzeitig einbringen, die Anforderungen und Gegebenheiten verstehen und gestalten, damit wir rasch einen Mehrwert liefern und alles bereit ist, wenn die Zeit für “unsere Experimente” gekommen ist.

Wie sind Ihre Erfahrungen:
Was sind die häufigsten und grössten Hindernisse, mit denen Sie konfrontiert sind?
Wie und mit welchem Erfolg haben Sie diese gemeistert?

Ich wünsche uns die erforderliche ausreichende Energie, um die Durchführung unserer “Experimente” mit allen Beteiligten voranzutreiben und wertvolle Ergebnisse zu liefern.

Es muss ja nicht gleich ein neues “Gottesteilchen” sein, welches wir suchen und finden …