Hochgeladen vonSwissQ Consulting AG
SwissQ Testing Trends & Benchmarking 2011
Der Bericht zu den Trends und Benchmarking im Softwaretesting von Swissq im Jahr 2011 beleuchtet die aktuelle Situation der Testmethoden in der Schweizer IT-Branche. Ein bedeutender Fokus liegt auf der Implementierung agiler Methoden wie Scrum, die eine verbesserte Zusammenarbeit und schnellere Rückmeldungen fördern, während die Bedeutung formeller Teststrukturen und -techniken hervorgehoben wird. Trotz der gestiegenen Wertschätzung für Testing bleibt der Reifegrad der Testaktivitäten oft unzureichend, wobei weniger als die Hälfte der Befragten die Qualität ihrer Testpraktiken als gut beurteilen.
Weitere ähnliche Inhalte
Ähnlich wie SwissQ Testing Trends & Benchmarking 2011
SwissQ Testing Trends & Benchmarking 2011
- 1. SwissQ Testing Trends& Benchmarking 2011 Autor: SwissQ At the of Software Testing SwissQ Event – 14. Juni 2011
- 2. Ziel des Abends/ Veranstaltung Page 2
- 3. Agenda Page 3 Line-Up Die Weltsteht doch nicht still! Basis des Reports Erste Zahlen und Trends Scrum Rock‘s – Testing Suck‘s 1 2 3 4 5 Die Welt der Testwerkzeuge Wissen – Das Lebenselixir unserer Unternehmen Wohin geht es: Trends & Co 6 7 8
- 4. Heutiges „Line-Up“ Page 4 SilvioMoser CTO SwissQ Marcel Rütschi Head Academy Adrian Stoll Scrum & Testing Geek
- 5. SwissQ ist… … Initiatorund Organisator des alljährlich stattfindenden Swiss Testing Day – und neu auch des Swiss Requirements Day. Page 5
- 6. Consulting Übernahme von Test- Aufgaben,Mobile und New Media Testing Management Software Testing Aufbau und Optimierung von Testorganisationen, Mentoring, Ad Interim Management Academy Aus- und Weiterbildung, Konferenzen und Events, Research and Development SCENESwissQ Serviceprofil Page 6
- 7. Was ändert sichin unserer Welt? Page 7
- 8. Was ändert sichin unserer Welt? Page 8 Community Plattform für Migros-Kunden Produktebewertungen & Kommentare Umfragen & Kampagnen
- 9. Was ändert sichin unserer Welt? Page 9 Coupons & Aktionen Mobile Payment iPhone & Android App diverse Schnittstellen
- 10.
- 11. Basis des Reports Page11 Source Umfrage bei über 1500 Software Tester der Schweiz 1:1 Gespräche mit ausgewählten Executives im Bereich Testing Gespiegelt mit nationalen und internationalen Experten
- 12.
- 13.
- 14.
- 15.
- 16. Projektart- und grösse Page16 Etwas über die Häl0e der Teilnehmenden haben auf die Frage nach der Art des aktuellen Projektes Neu-‐Entwicklung genannt. Dies spiegelt sich auch in der Grösse dieser Projekte, wo für je etwa 30% eine Grösse zwischen 500 Tsd. bis 1 Mio. bzw. 1 bis 5 Mio. angegeben wurde. Gemessen an der Medienpräsenz ist der Anteil an Standard-‐So0ware unerwartet gering.
- 17. Ausgangslage in denProjekten Page 17
- 18. Projekterfolg Page 18 Der vielziPerte Chaos Report der Standish Group wird o0 als Mythos bezeichnet, der auf die Schweiz nicht zutrifft. Die Umfrage zeigt jedoch ein sehr ähnliches Bild, mit nur knapp einem Viertel der Projekte die in Zeit, in Budget und mit gewünschter FunkPonalität beendet werden. Interessant ist die Tatsache, dass scheinbar keine Projekte gestoppt wurden, was jedoch hinterfragt werden muss.
- 19. Ansehen des Testens Page19 Der Stellenwert des TesPng in der eigenen OrganisaPon wird von einem Grossteil als sehr hoch bezeichnet. Natürlich hat dies auch mit der Eigenwahrnehmung der Tester zu tun. Es ist jedoch unbestri[en, dass allgemein Testen an Ansehen gewinnt und als eigenständige Disziplin aus der SW-‐ Entwicklung nicht mehr wegzudenken ist. Einzig in der höheren Fachausbildung wird das Thema noch sträflich vernachlässigt.
- 20. Reifegrad des Testens Page20 Weniger als die Häl0e der Befragten bezeichnen den Reifegrad der TestakPvität in ihrem Projekt als gut, ein paar wenige als ausgezeichnet. Dies deckt sich mit der eher negaPven Beurteilung der Ausgangslage. Trotz gesPegenem Ansehen, passiert es immer noch allzu o0, dass die Tester viel zu spät involviert werden und dass die So0ware spät und in ungenügender Qualität in die Testumgebung ausgeliefert wird.
- 21. Grundlagen Testfalldesign Page 21 Tester setzen sich als Grundlage für das Tes_alldesign mit Anforderungen unter-‐ schiedlichster Form auseinander, wobei Prosa und Use Cases am verbreitesten sind. O0mals wird auch das Altsystem beigezogen. Genauso mannigfach sind auch die Herausforderungen daraus Tes_älle abzuleiten, die eine hohe Testabdeckung bieten und Fehler finden, die in der ProdukPon wehtun. O0 wird unterschätzt wie viel Aufwand in die Analyse der Anforderungen invesPert werden muss.
- 22. Externe Ressourcen Page 22 Bei knapp 60% werden TestakPvitäten durch externe Ressourcen unterstützt. Dabei handelt es sich meist um Personen, die vor Ort im Unternehmen oder in der Schweiz täPg sind. Bei Ressourcen die vom Ausland täPg sind steht Indien im Vordergrund. Outsourced TesPng in Osteuropa findet erstaunlich wenig sta[.
- 23.
- 24. Wer führt Testsdurch Page 24
- 25. Einsatz agiler Methoden Page25 Agile Vorgehen, für die meisten gleichbedeutend mit SCRUM oder SCRUM-‐ähnlichen Methoden, sind in aller Munde und 2/3 der Teilnehmenden geben an, dass ihr Unternehmen bereits Projekte nach einer agilen Vorgehensweise durchführt oder für die nahe Zukun0 plant. Etwas über 20% arbeiten denn auch bereits in einem solchen Projekt mit. Seitens Entscheidungsträger wird der Wert von SCRUM anerkannt, vorausgesetzt es wird methodisch korrekt und für die richPgen Vorhaben eingesetzt.
- 26. Scrum Rocks, TestingSucks?! Adrian Stoll SwissQ Testing Trends & Benchmarking 2011 Zürich, 14. Juni 2011
- 27. Ziele der Präsentation Wie ein Scrum Team von einer dedizierten Person für das Testing profitiert Warum ein Embedded Scrum Tester besser ist, als die Testverantwortung auf das ganze Team zu verteilen Was trägt ein Tester zu den Scrum Prozessen wie Daily Scrum, Sprint Planning, Retrospective etc. bei ... und vor allem: Finden Sie heraus, weshalb Testing in Scrum Spass macht, weil man involviert ist und schneller zum Ziel kommt Page 27
- 28. Agenda 1. Scrum Testingin der Praxis 2. Warum Testing in Scrum rockt! 3. Scrum Testing im Detail – Techniken und Technologien 4. Lessons Learned Page 28
- 29. SCENE Adrian Stoll Wirtschaftsinformatiker, Testeraus Leidenschaft, Geek Senior Consultant, SwissQ Consulting AG Ihr Referent Scrum-Erfahrung: • Embedded Tester in 2 Siegerprojekten der "Best of Swiss Web"-Awards • Scrum Test Professional bei einer grossen Versicherung • Kursleiter "Testing in Scrum" Page 29
- 30. Agenda 1. Scrum Testingin der Praxis 2. Warum Testing in Scrum rockt! 3. Scrum Testing im Detail – Techniken und Technologien 4. Lessons Learned Page 30
- 31. Blick auf dieVorgehensweisen Page 31 ATST Konzept Design High Level Test EinführungCode Low Level Test Wasserfall ST/AT ST/AT ST/AT ST/AT ST/AT ST/AT ST/AT ST/AT S1 S2 S3 S4 S5 S6 S7 S8 Scrum
- 32. Scrum Testing imDetail ST/AT ST/AT ST/AT S3 S4 S5 Scrum ST/AT ST/AT S3 S4 S5 ST/AT Embedded Page 32
- 33. Embedded Scrum Tester GemeinsameVerantwortung: "Alle" sind für das Testen verantwortlich Ist (High Level) Test Know-How vorhanden? Ist Testing wirklich unabhängig, objektiv? Wie/wer verantwortet Bug-Fixing und Retests? Im Scrum Team wird Testing als gemein- same Verantwortung wahrgenommen. Oft werden Entwickler für das Testing zugeteilt, was einige Risiken mit sich bringt: Page 33
- 34. Embedded Scrum Tester EinEmbedded Scrum Tester kann diese Risiken minimieren: Spezial-Wissen vorhanden Unabhängig und „objektiv“ Fehler können umgehend behoben werden (sehr kurze Feedback-Zyklen) Gemeinsame Verantwortung: "Alle" sind für das Testen verantwortlich Embedded Tester: Test durch einen unabhängigen Spezialisten Page 34
- 35. Agenda 1. Scrum Testingin der Praxis 2. Warum Testing in Scrum rockt! 3. Scrum Testing im Detail – Techniken und Technologien 4. Lessons Learned Page 35
- 36. Why traditional Testingsucks Frustrierend – Fehler zu finden, die offensichtlich sind Undankbar – als Tester ist man bei Entwicklern oft unbeliebt Stressig – bei Verzögerungen verkürzt sich meist die Testzeit Eintönig – immer wieder dieselben Testfälle, repetitiv Isoliert – als Tester kann man selten die Umsetzung beeinflussen Page 36
- 37. Why Scrum Testingrocks Motivierend – Raschere Testresultate, schnellere Bugfixes Dankbar – Entlastung für Entwickler, positives Feedback Kontrolliert – eingebetted in Scrum Planung und Zyklus Abwechslungsreich – am Puls der (raschen) Weiterentwicklung Involviert – Mitreden und Lösungsvorschläge erwünscht Page 37
- 38. Agenda 1. Scrum Testingin der Praxis 2. Warum Testing in Scrum rockt! 3. Scrum Testing im Detail – Techniken und Technologien 4. Lessons Learned Page 38
- 39. Techniken und Technologien GrosserAnteil von Explorativem Testen Page 39
- 40. Techniken und Technologien TraditionelleTest-Techniken ja – unbedingt! – aber "Light" Page 40
- 41. Techniken und Technologien Entwicklungund Dokumentation von strukturierten (Regressions-) Testfällen fortlaufend Übersicht Regressions-Testcases Stand per Sprint XX Page 41
- 42. Beitrag des Testersin Scrum Prozessen User Story Review in enger Zusammenarbeit mit dem Product Owner Sprint Planning Page 42
- 43. Beitrag des Testersin Scrum Prozessen Abschätzen der Zeit, welche zum Testen von User Stories benötigt wird und dafür sorgen, dass diese bei der Aufwandschätzung berücksichtigt wird Estimation Meeting Page 43
- 44. Beitrag des Testersin Scrum Prozessen (auch Daily Standup): Was habe ich gestern getestet, was teste ich heute, wo hatte ich Probleme beim Testen? Daily Scrum Image: Danny (Danko) Kovatch Page 44
- 45. Beitrag des Testersin Scrum Prozessen Kennenlernen neuer Features vor dem Testing (oder: bereits getestete Features selbst demonstrieren) Sprint Review / Demo Die Demo lief diesmal richtig flüssig und wie aus einem Guss. Machte einen super-professionellen Eindruck, weiter so! Page 45
- 46. Beitrag des Testersin Scrum Prozessen Wo waren die Stolpersteine aus Tester-Sicht, was lief besonders gut? Was kann man neu/anders machen? Scrum Retrospective Image: IT-Zynergy ApS Page 46
- 47. Agenda 1. Scrum Testingin der Praxis 2. Warum Testing in Scrum rockt! 3. Scrum Testing im Detail – Techniken und Technologien 4. Lessons Learned Page 47
- 48. Scrum Testing –Best Practices Testing-Workflow im Scrum Tool einführen Anforderungsbasiertes Testing anhand von User Stories Der Entwickler schreibt ein "How to test" pro Story Sprint-Planung und Fortschritt stetig überwachen Tests möglichst rasch durchführen, Anhäufung von pendenten Testfällen vermeiden Nahe beim Team sein: Physisch präsent oder mithilfe von elektronischen Kommunikationsmitteln Integrationsfördernde Massnahmen zahlen sich aus: Anpassung an Kleidung, Sprache, Arbeitszeiten, Gewohnheiten des Teams etc. Page 48
- 49. Scrum Testing –Lessons learned Scrum erfordert Disziplin! Vorsicht vor "Technical Debts"! Dokumentation wird häufig vernachlässigt End-to-End Testing sauber planen Scrum Testing und Remote Testing: Tolle Kombination! Continous Integration Mechanismen nutzen "Explodierende" Regressionstests Page 49
- 50. Thank you foryour involvement defending the platform and the work done. Are you ready for the challenge? Da wären wir nie drauf gekommen. Toll, was du alles findest euer team hat wirklich einen super job gemacht. die letzten Tage sind wirklich weltmeisterlich verlaufen, an allen ecken. Eine echte Unterstützung! Ohne euch hätten wir das kaum geschafft. du bist ne echte testing maschine, wir sind froh haben wir dich dabei ;-) Page 50
- 51.
- 52. Tooleinsatz Page 52 Nicht überraschend, haben fast 80% der Befragten ein Testmanagement-‐ und Defectmanagement-‐Tool im Gebrauch, das vollständig implemenPert ist oder wollen dessen Einsatz erweitern. SystemaPsches Testen ist ohne diese Tools fast nicht mehr denkbar. Auch für die TestautomaPsierung haben rund 80% der Befragten ein Tool im Einsatz. Hier ist allerdings das Verhältnis zwischen vollständig Impl-‐emenPerten Tools und solchen deren Einsatz noch erweitert wird genau umgekehrt im Vergleich zu den Managemen[ools.
- 53. Testautomatisierung Page 53 Über 60% der Unternehmen geben an, dass weniger als 10% ihrer (Regressions) Tests automaPsiert sind. Nur 9% haben über 50% der (Regressions) Tests automaPsiert. Die Zahlen z e i g e n v e r s t ä n d l i c h a u f , w i e s o TestautomaPsierung als einer der grössten Trends im 2011 gilt.
- 54. Wohin geht esmit den Testwerkzeugen Page 54 FunktionalitätZukunft Marktabdeckung
- 55. Testwerkzeuge Slide-Set „removed“aufgrund CopyRight Vorbehalten der Hersteller. Bei Interesse nehmen Sie bitte direkt Kontakt mit SwissQ auf. Page 55
- 56. Funktionalität – Fokusauf Risiken Page 56 Eintrittswahrscheinlichkeit hoch >75% Niedrig <25% Mittel 25%-75% 1 23 4 5 6 7 1. Bereich / Funktionalität / Req. 2. Bereich / Funktionalität / Req. 3. Bereich / Funktionalität / Req. 4. Bereich / Funktionalität / Req. 5. Bereich / Funktionalität / Req. 6. Bereich / Funktionalität / Req. 7. Bereich / Funktionalität / Req. Auswirkung auf das Projekt (Termine, Kosten, Qualität) niedrig hochmittel
- 57. Aus- und Weiterbildung Wissen,das Kapital einer Unternehmung
- 58. Ausbildungsstand Page 58 Fast 75% der Teilnehmenden verfügen über ein ISTQB CerPfied Tester FoundaPon Level ZerPfikat und auch die Advanced Level ZerPfikate sind weit verbreitet. Gefragt sind daher in Zukun0 vor allem praxisbezogene oder verPefende Kurse wie TesPng in Scrum oder ZerPfikate in angrenzenden Themengebieten wie Requirements Engineering, Projekt Management, etc.
- 59. Theorie vs. Praxis Page59 ‘Theory without practice is idle, practice without theory is blind’ Ancient Chinese Proverb
- 60. Wissens-Management Wissen analysieren Das wissen wir schon Das sollten wir noch wissen Wissen aufbauen Theoretisches Wissen (ISTQB und ähnliche Kurse) Wissen umsetzen Praktisches Wissen (Best Practices, Austausch in einer Community) Praxisbezogene Kurse, Seminare und Project-Coaching Wissen pflegen Wissen vertiefen Wissen weiter geben und dokumentieren Wissen in der Unternehmung halten Page 60
- 61. SwissQ Weiterbildungs-Angebot Page 61 TestBasiswissen Zertifizierung Test Management Test Engineering Test Tools Angrenzende Themen Theorie Praxis
- 62. Testdesign in derPraxis Testideen Fokus auf Qualitäts- Dimension • Funktionalität • Zuverlässigkeit • Benutzbarkeit • Effizienz • Änderbarkeit • Übertragbarkeit Testobjekte Fokus auf Objektarten: • Arbeitsabläufe • GUIs • Schnittstellen • Batches • Datenbanken • ... Logische Testfälle Fokus auf Teststufe und Identifikation der Testmethode • Unit Test • Integration Test • System Test • Acceptance Test • Dynamisch - Black Box - White Box - Unsystematisch • Statisch - Manuell - Automation Konkrete Testfälle Fokus auf Testfall- Ermittlungsverfahren • Äquivalenzklassen • Grenzwertanalyse • ... • Knotenüberdeckung • Kantenüberdeckung • ... • Exploratives Testen • Intuitives Testen • ... • Technischer Review • ... Anforderungen Fokus auf Testbarkeit: • Verständlichkeit • Eindeutigkeit • Kein Design • Konsistenz Dieser Kurs beantwortet die Fragen aus der Praxis • So testen Sie Ihre Anforderungen richtig • So erarbeiten Sie die optimalste Testabdeckung • So kommen Sie zum perfekten Testfall • So vermeiden Sie Mehraufwand im Testing Der neue Kurs aus der Praxis für die Praxis im Testalltag Page 62
- 63. Stakeholder-Analyse? Tester Test Team Test Manager Entwickler LieferantenBenutzer / Kunde ProjektleiterReq-Engineer‘s Page 63
- 64. Projektumfeldanalyse Qualität der Verbindung +Perfekt o Normal K Kritisch Häufigkeit der Verbindungen 3 Intensiv 2 Mittel 1 Niedrig 0 nicht vorhanden Projekt- Leiter Konstruktion Berechnung Kollegen Allg. Dev Team 2. Zulieferer Kunde Referenz Berechnung Versuch Lead Engineer Abt. 1 Screen Designer RE-Unit User Abt. AB DB Intranet Internet FTL Abt. 4 o/0.5 k/0.5 o/1 o/1 +/2 +/2 o/1 /0 +/1 +/3 +/2 +/2 +/2 +/3 +/1 +/3 Page 64
- 65. Kapazitätsplanung Darstellung der Kapazitäten nach Kapazitätsstellen des Gesamtprojektes (A) und zeitlichem Verlauf je Kapazitätsstelle (B, C) 1 2 3 4 5 6 7 8 Jan Feb Mär Apr Mai Jun Jul Aug Sep Okt Nov Dez Jan Feb Mär Apr Mai Jun Jul Aug Sep Okt Nov Dez Kapazität (Stelle 1) Kapazität (Gesamtprojekt) Kapazität (Stelle 2) Kapazitätsstelle B C Max. Max. Max. A Page 65
- 66. Kostenplanung 0 10 20 30 40 50 60 70 80 Jan Feb MärApr Mai Jun Jul Aug Sep Okt Nov Dez Plankosten vs. Ist-‐Kosten in TCHF Plankosten Ist-Kosten
- 67.
- 68. Swiss Testing Trends2011 Page 68
- 69. Fazit Schneller – Flexibler- Agiler Page 69
- 70. Outsourcing Strategie Neue Technologien Head Count Kosten- reduktion Re-Organisation Far Environment Elemente,auf welche wir nur reagieren können (jedoch nicht beeinflussen). Data Privacy Business Alignment SCRUM Agile Near Environment Elemente, die wir beeinflussen können. Inner Environment Elemente, die wir kontrollieren können. End-2-End Testing Test Automation Tester Skills Marketing Unser Testing Placeholder Als Beispiel ein SAP Projekt mit eigenem Test Team, Prozessen und Tools. Disruptive Projects SAP Einflussfaktoren Page 70
- 71. Time AmountofChange The risk ofstrategic drift Page 71 Incremental Change Fortlaufend kleinere Änderungen, um die Organisation zielgerichtet in Bewegung zu halten. Strategic Change Grössere strategische Änderungen, um mit den Veränderungen im Unternehmen mitzuhalten. Change Sich dauernd verändernde Anforderungen aus dem Unternehmen und der Umwelt. AmountofChange
- 72. Detailliertes Wissen vonSwissQ in: Testing in Scrum & Agile (inkl. Übernahme von Test-Aktivitäten) Exploratives Testing Testing für „New and Social Media“ und Mobile Applications Testwerkzeug-Strategie Entschlankung der Testaktivitäten und –dokumente Praxisbezogene Aus- und Weiterbildung Strategische Ausrichtung und Optimierung Ihres Testings Übernahme von Testprojekten und -mandaten Page 72
- 73.
- 74. Besten Dank fürIhre Aufmerksamkeit! Fragen? Page 74
- 75.
- 76. Kontaktieren Sie unsunter Page 76 1 2 3 4 5 6 7 8 SwissQ Consulting AG Stadthaus-Quai 15 8001 Zürich Tel. +41 (0)43 288 88 40 Fax +41 (0)43 288 88 39 www.SwissQ.it info@swissq.it Koordinaten