tag:blogger.com,1999:blog-59166129144440057512024-03-13T05:06:55.201+01:00Softwaretest und SoftwarequalitätBlog rund um das Thema Softwaretest und Softwarequalität. News zu Trends und Veranstaltungen.Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.comBlogger64125tag:blogger.com,1999:blog-5916612914444005751.post-900750788384547122016-06-17T23:23:00.001+02:002016-06-17T23:25:47.140+02:00Vortrag zur Ethik -- German Testing Day 2016Das Thema Ethik ist en vogue auf den Veranstaltungen zum Testing. Das ist auch gut nachzuvollziehen durch immer mehr autonome Systeme in unserer Umwelt, die unter Umständen selber über Leib und Leben entscheiden müssen (autonomes Auto, dass möglicherweise einen Unfall hat).<br />
<br />
Der Referent Tobias Geyer (<a href="https://twitter.com/the_qa_guy" target="_blank">@the_qa_guy</a>) hat für mich einige interessante Aspekte in seinem Vortrag gebracht. So stellte er ein paar Beispiele eines sozialen Netzwerkes dar und hinterfragte die Ethik der Vorgehensweise. Im weiteren stellte er vorhandene Codes of Ethics von IEEE, ACM und ISTQB und Testguru James Bach vor und verglich diese miteinander. Außerdem unterzog er seine Beispiele einer Prüfung bezüglich der Codes.<br />
<br />
Seine Schlussfolgerung und sein Aufruf in der Diskussion:<br />
<br />
<ul>
<li>Wir sind alle als Tester mit verantwortlich für die Ethik in der Softwareentwicklung. Wir können und dürfen uns dieser Verantwortung nicht entziehen</li>
<li>Das German Testing Board sollte sich der Ethik annehmen und das Thema vorantreiben </li>
</ul>
Wir haben nach Ende des Vortrags noch intensiv die Pause für Diskussion genutzt. Dabei kamen von verschiedenen Personen unterschiedliche Statements:<br />
<br />
<ul>
<li>Wir brauchen eine breite gesellschaftliche Diskussion</li>
<li>In recht unbekannten Gruppierungen (z. B. GTB) hat dies zu wenig Breitenwirkung</li>
<li>Wenn ein Board es schafft, die Diskussion in die Gesellschaft zu tragen, wäre das super</li>
<li>Der Gesellschaft scheint das Thema noch nicht wichtig genug</li>
<li>Es sind nicht nur Tester, sondern alle Mitglieder von SW Entwicklungsteams für Ethik-Themen gefragt. Also auch PL, PO, ScM, Entwickler ...</li>
<li>Nicht immer können Menschen Partei für die Ethik ergreifen (was wenn man Familie zu ernähren hat - kündigt man einfach? - wahrscheinlich nicht)</li>
</ul>
<br />
Inspirierend. Aufweckend. Die Diskussion ist noch lange nicht am Ende. Ich hoffe auf Fortsetzung bei weiteren Events und über soziale Netzwerke...Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-81613765788734158622016-06-17T22:53:00.002+02:002016-06-17T22:53:26.631+02:00Vorträge am German Testing Day 2016Bei vier parallelen Tracks muss man sich immer für einen Track entscheiden. Ein paar Statements/Ideen aus den von mir besuchten Vorträgen.<br />
<br />
Navigieren, wo nie ein Test zuvor gewesen ist<br />
<br />
<ul>
<li>Session based testing sollte man für kreative Tests nutzen; diese Art fördert die Neugierde</li>
<li>Der Kunde verhält sich viel öfter anders, als man sich das vorher vorgestellt hat</li>
</ul>
<div>
<br /></div>
<div>
Das Ende des End-to-End Tests?</div>
<div>
<br /></div>
<div>
Ein wenig provokativ aber mit interessanter Idee war dieser Vortrag von <a href="https://twitter.com/mschlabinger" target="_blank">@MSchlabinger</a>. Im Schnitt haben 38 Systeme Beziehungen untereinander, für die man E2E Tests durchführen muss. Für eine gute Testabdeckung müssen viele Mocks und Stubs geschrieben werde. Doch diese kosten die Entwickler Zeit. Also verfällt man auf UI Tests und damit zur Ice Cream Testautomatisierung (Umkehrung der Pyramide und bekanntes Anti-Pattern). Dies ist teuer, instabil und unterliegt ständiger Anpassung. Ganz zu schweigen von der späten Durchführung. Deshalb wirbt er für eine Service-Virtualisierung. Diese basiert auf den Daten, die die Services austauschen. Diese können zum Beispiel aus "Mittschnitten" des Echtbetriebes gewonnen werden. Die Tests auf Basis der Virtualisierung können einfacher also die umfangreichen Mocks umgesetzt werden und werden damit von den Entwicklern umgesetzt. Auf jeden Falls ein Ansatz, den man überdenken sollte.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
Testmanagement in agiler Transition</div>
<div>
<br /></div>
<div>
Der Referent <a href="https://twitter.com/KayGrebenstein" target="_blank">@KayGrebenstein</a> stellte seine Überlegungen vor, wie sich die Aufgaben des Testmanagers aus klassischen Projekten im agilen Umfeld wiederfinden. So konnte er darlegen, dass sich die operativen Aufgaben (Testmanager) auf die verschiedenen Rollen in einem agilen Team verteilen und aus seiner Sicht auch vollständig wahrgenommen werden. Die Rolle des Testmanagers muss damit aus seiner Sicht im agilen nicht speziell besetzt werden. Die strategischen Aufgaben (Qualitätsmanager) sind jedoch nicht im agilen Entwicklungsteam angesiedelt. Dafür muss die Gesamtorganisation sorgen. Das kann zum Beispiel durch Gilden (kommt ursprünglich von Spotify) geschehen, die sich gezielt um Themenstellungen kümmern und vorantreiben.</div>
<div>
Gut gefallen hat mir auch das Mindset, dass in seinem Unternehmen herrscht. "Jeder ist für Qualität verantwortlich".</div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-26155253488004173352016-06-17T21:20:00.006+02:002016-06-17T21:31:11.769+02:00Keynotes auf dem German Testing Day 2016Zwei interessante Keynotes gab es auf dem German Testing Day 2016 in Frankfurt.<br />
<br />
Johannes Mainusch (<a href="https://twitter.com/docjoe" target="_blank">@docjoe</a>), der lange bei Xing und Otto als Entwicklungschef war, berichtete in der morgendlichen Keynote darüber wie sich Organisationen aufstellen sollten, um erfolgreich zu sein. Dabei kam er zu folgenden interessanten Schlussfolgerungen.<br />
<br />
"Software Architecture fails" (jedenfalls in den letzten Jahrzehnten). Das Problem ist in der Regel, dass Architekturen nicht vertikal konzipiert sind sondern horizontal (und so weiter wachsen). Dies führt zu einer starken Abhängigkeit, die Änderungen sehr schwer wenn nicht unmöglich machen. Die Matapher dazu: "Software ist wie Fichtenholz - wenn man sie nicht frühzeitig spaltet, wird sie unspaltbar".<br />
<br />
Zu Änderungen in der Organisation gab er folgende Erfahrungen weiter:<br />
<ul>
<li>Wenn ich dauernd was ändere, wird es weniger steuerbar und damit schlecht</li>
<li>Leider wollen Manager dauernd was ändern - Daseinsberechtigung/vor allem bei neuen Managern</li>
<li>Ändere langsam </li>
</ul>
"Zentrale QA fails". Das Testen und die Qualitätssicherung gehören in das Entwicklungsteam. Mit dieser Aussage stützt er voll den agilen Gedanken der cross-funktionalen Teams.<br />
<div>
<br /></div>
<div>
"Richte die Organisation und die Teams auf das Deployment aus". Hätten wir vor 9 Jahren noch über einen Auslieferungszyklus von 2 Wochen "wow" gesagt, sind Continuous Integration und Continuous Deployment das Ziel. Einen Change durchzuführen "darf nicht weh tun" und muss in wenigen Minuten erfolgen können...</div>
<div>
<br /></div>
<div>
Der Blogger und Autor Tim Cole (<a href="https://twitter.com/TCole1066" target="_blank">@TCole1066</a>) berichtete über die Aspekte des digitalen Wandels generell und in Deutschland im Besonderen. Aus seiner Sicht ist das Thema Vernetzung ein ganz zentrales Thema. Denn der derzeitige Wandel führt zu einer Vernetzung auf allen Ebenen der Technik, Systeme und der Gesellschaft. Dazu müssen wir uns auf Veränderung einstellen und diese auch gestalten.</div>
<blockquote class="tr_bq">
"Du kannst nicht vernetzen ohne zu verändern".</blockquote>
<div>
Weiterhin ging er auf ein typisch deutsches Dilemma ein. Wir dürfen nicht nur reden und ständig diskutieren über Veränderung. Wir brauchen Mut zur Veränderung. Wir brauchen Mut für Neues.</div>
<blockquote class="tr_bq">
"Wir müssen die Zukunft gestalten."</blockquote>
<div>
Kurzweilig (<a href="https://twitter.com/FrankStrube/status/742726525221490693" target="_blank">Beispiel</a>) und eloquent vorgetragen war es eine tolle Keynote zum Abschluss des German Testing Days 2016</div>
<div>
<br /></div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com1tag:blogger.com,1999:blog-5916612914444005751.post-5514080965201270292015-09-21T14:46:00.002+02:002015-09-21T14:46:50.065+02:00ASQF Testing-Day: Agiles Testen vs. ISO 29119Einen sehr unterhaltsamen und informativen Vortrag hielten zwei Referenten der imbus AG zum Thema Agiles Testen vs. ISO 29119. Beide Referenten polarisierten geschickt mit der Zuspitzung der beiden Positionen <br />
<ul>
<li>Agiles Testen ist doch: "jeder macht was er und wann er will" und "da wird ja gar nichts geplant"</li>
<li>ISO Norm ist doch: "da ist alles starr und fix vorgegeben" und "das lässt mir keine Freiheitsgrade"</li>
</ul>
Und eigentlich liegen beide Themen gar nicht so weit auseinander. Denn für beide Vorgehensweisen, egal ob agil oder stark an der Norm orientiert, gilt aus Sicht der Referenten:<br />
<ul>
<li>Nutze das aus der Norm, was interessant für das aktuelle Projekt ist (was bietet einen Mehrwert für das Projekt) - damit bietet auch die Norm Flexibilität</li>
<li>Nutze eine Norm (oder Teile der Norm) als Vorlage für Verbesserungen oder auch als Vorlage für test cases</li>
<li>kläre wieviel Dokumentation benötigt wird ("just enough documentation")</li>
<li>wie sieht ein Testreport am Ende eines Sprints oder Meilensteines aus? wieviel muss er enthalten? kann die Norm hier Hilfestellung geben.</li>
</ul>
Nicht nur der Vortrag war kurzweilig. Auch beim Get Together waren die Referenten interessante Gesprächspartner.<br />
<div>
</div>
<div>
</div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com1tag:blogger.com,1999:blog-5916612914444005751.post-64767669387228566002015-09-21T14:25:00.000+02:002015-09-21T14:25:11.430+02:00ASQF Testing-Day: Test meets SecurityEinen spannenden Vortrag gab es auf dem ASQF Testing Day in Erlangen. Dieser beschäftigte sich mit dem Thema des Security-Testing. Aus meiner Sicht stellte der Referent folgende Eckpfeiler dar:<br />
<br /><br />
<ul>
<li>Die zunehmende Vernetzung (Fahrzeuge, Industrie 4.0, etc.) rückt die Security-Tests stärker in den Focus</li>
<li>Derzeit nimmt der Referent zur IT-Sicherheit einen deutlichen Paradigmenwechsel wahr (Security wird immer wichtiger)</li>
<li>Die Tests sollten sich nicht nur auf die Applikationen beziehen sondern auch die IT-Infrastruktur berücksichtigen</li>
<li>Wesentlicher Bestandteil des Testens sind unit-Tests</li>
<li>Schwachstellen in Applikationen setzen sich aus zwei Kategorien zusammen:</li>
<ul>
<li>Entwurfsfehler</li>
<li>Programmierfehler</li>
</ul>
<li>Zur Prüfung auf Programmierfehler sollten automatisierte Fuzzing-Tests durchgeführt werden</li>
<ul>
<li>diese sind mit unit-Tests zu automatisieren</li>
<li>so kann eine hohe Variation in den Tests erreicht werden</li>
<li>dieses können zur Regression immer wieder ausgeführt werden</li>
<li>Modellbasiertes Testen ist für diese Tests sehr gut geeignet und sollte in Betracht gezogen werden</li>
</ul>
</ul>
Letztendlich zeigte der Vortrag, dass man bei der Entwicklung das Thema Eingaben und Dateneingabeformate immer intensiv beim Test berücksichtigen muss.<br />
<div>
</div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-22908665767482200372015-05-05T23:34:00.000+02:002015-05-05T23:34:01.824+02:00Testing, Checking oder einfach nur testen?Der Testexperte Gojko Adzic (<a href="http://gojko.net/" target="_blank">Link</a> zu seinem Blog) hat in einem seiner Artikel eine interessante These aufgenommen. Die besagt, dass das Testen eigentlich aus zwei unterschiedlichen Disziplinen oder Arten besteht:<br />
<ol>
<li>Das Überprüfen erwarteter Ergebnisse. In Testfällen wird beschrieben, wie sich eine Anwendung verhalten soll. Dies wird dann überprüft. Diese Disziplin wird als <em>checking</em> bezeichnet. Gängige Tests sind dafür Unit-Tests, Tests von Datenformaten, Datenmigrationen, Schnittstellen etc.</li>
<li>Die Analyse der Anwendung auf das Verhalten bei Nutzung. Damit wird getestet, ob sich eine Anwendung unerwartet verhält. Ob Undefiniertes und Unbekanntes auftritt. Diese Disziplin wird als <em>testing</em> bezeichnet. Darunter fällt z. B. usability testing und exploratives Testen.</li>
</ol>
Eine spannende Unterscheidung. Denn die Tests, die unter <em>checking</em> fallen, bieten sich auch stark für Automatisierung an und sind in der Regel vom Entwickler (z. B. im Pairprogramming) umzusetzen. Das <em>testing</em> wird dann von erfahrenen Testern manuell durchgeführt.Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com1tag:blogger.com,1999:blog-5916612914444005751.post-32180146463476799822015-04-23T14:08:00.000+02:002015-04-23T14:08:23.470+02:00Agile TestquadrantenAuch im agilen Projekt muss man jederzeit in den Sprints alle Qualitätsfaktoren im Blick haben. Doch welche Tests sollten wie durchgeführt werden? Welches Ziel verfolgen die Tests? Dazu geben die vier agilen Testquadranten Auskunft:<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYL_hhI5cw2B5Q7lOtJrTnWhtXyTUPQJ22MoSoP4TdJpHWQoy6Lv7XmualuXsHutghJYln2m37j8HrM06Z1CnlLUUs75r6HtV3v01q-9EYM1uve8duPpntAx2U9PvLKThrBt5m0ObhUPg/s1600/AgileTestquadranten.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYL_hhI5cw2B5Q7lOtJrTnWhtXyTUPQJ22MoSoP4TdJpHWQoy6Lv7XmualuXsHutghJYln2m37j8HrM06Z1CnlLUUs75r6HtV3v01q-9EYM1uve8duPpntAx2U9PvLKThrBt5m0ObhUPg/s1600/AgileTestquadranten.png" height="398" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Agile Testquadranten nach Crispin/Gregory</td></tr>
</tbody></table>
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
Im ersten Quadrant befinden sich die Tests, die Team unterstützend wirken und technisch orientiert sind. Das Test Driven Development ist eine Voraussetzung für die vielen Regressionstests, die in der agilen Vorgehensweise notwendig sind.<br />
Im zweiten Quadranten sind die Tests aufgeführt die das Team ausführt, damit sichergestellt wird, dass die Funktionen so umgesetzt wurden, wie diese geplant waren. Auch bei diesen Tests kommt die Testautomatisierung zum Einsatz, jedoch mit deutlich geringerem Umfang. Als Vorgehensweisen kommen oft Acceptance Test Driven Development (ATDD <a href="http://en.wikipedia.org/wiki/Acceptance_test-driven_development" target="_blank">Link</a> wikipedia) und Business Driven Development (BDD <a href="http://en.wikipedia.org/wiki/Business-driven_development" target="_blank">Link</a> wikipedia) zum Einsatz.<br />
In den dritten Quadranten fallen die Tests, welche die Geschäftstauglichkeit des Produktes hinterfragen. Es sind die Tests, die die Software sehr intensiv aus Sicht des Endbenutzers betrachten. Diese werden manuell durchgeführt.<br />
Die Tests des vierten Quadranten sind spezielle Tests, die oft auch Experten mit speziellem Wissen für Tests (z. B. für die Security-Tests) oder für die Werkzeuge (z. B. Last- und Performancetests) benötigen. In großen Organisationen werden diese oft in Testcentern gebündelt, damit nicht jedes Team mit hohem Aufwand die Infrastruktur und Know-How aufbauen muss.Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com2tag:blogger.com,1999:blog-5916612914444005751.post-63932580591426801542015-03-28T19:13:00.000+01:002016-06-17T22:18:02.298+02:00Magisches Quadrat der agilen SoftwaerentwicklungDas magische Quadrat der Softwareentwicklung beschreibt die vier Einflussfaktoren. Das sind<br />
<ul>
<li>die Kosten (im Prinzip das verfügbare Personal für das Entwicklungsteam)</li>
<li>die im Projekt vorgegebene Qualität</li>
<li>der Termin zu der das Produkt oder Release fertig gestellt werden soll</li>
<li>die Features, die im Produkt/Release umgesetzt werden sollen</li>
</ul>
Magisch, weil die Beeinflussung eines Faktors auch sofort auf die anderen Faktoren einwirkt. Es ist natürlich verständlich, dass ein Team in der gleichen Zeit nicht so viel entwickeln kann, wenn ein Mitarbeiter länger ausfällt. Oft tritt in der Praxis der Fall ein, dass ein Team mit der Entwicklung der Features im Rückstand ist. Statt diese Anzahl anzupassen, wird dann meistens bei der Qualität (Verringerung oder Entfall von Tests) eingespart.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJID3iXj3VJRn0yOjfXy-AxHc3ElzzEdyQChm483Mqdkgqu3TToKOYhyNZ22ksaDlfov8fh1JX7pBEdD8XHSPlc82OAU93UduiMAbyixBkwT5Rdw9hR7lPoOQyelRBehg7pARAHw4hY2U/s1600/MagischesQuadratInAgilenProjekten_QualitGeschuetzt.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="297" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJID3iXj3VJRn0yOjfXy-AxHc3ElzzEdyQChm483Mqdkgqu3TToKOYhyNZ22ksaDlfov8fh1JX7pBEdD8XHSPlc82OAU93UduiMAbyixBkwT5Rdw9hR7lPoOQyelRBehg7pARAHw4hY2U/s400/MagischesQuadratInAgilenProjekten_QualitGeschuetzt.jpg" width="400" /></a></div>
<br />
Im agilen Ansatz gibt es im Prinzip nur noch eine Variable in den Einflussfaktoren. In einem geschützten Team (Personal stabil) werden bei gleich bleibender Qualität (durch Test Driven Development und festgelegten Definition of Dones) bis zu einem bestimmten Termin (festgelegt durch den Sprintzyklus) eine variable Menge an Features entwickelt. Fehlen zum <i>Go live</i> notwendige Features, müssen entsprechend weitere Sprints durchgeführt werden. Ist der Termin jedoch fix, ist nur die umgesetzte Anzahl an Anforderungen/Features variabel.<br />
<div>
<br /></div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com1tag:blogger.com,1999:blog-5916612914444005751.post-49740260185353479292015-01-14T20:48:00.003+01:002015-01-21T18:41:29.864+01:00Was ist Software Qualität? Ein Beispiel<p dir="ltr">Was ist Software Qualität? Die Frage ist gar nicht so leicht zu beantworten. Denn unter Qualität versteht jeder Mensch etwas Anderes, denn jeder hat andere eine andere Sicht auf das Produkt und andere Anforderungen (oder gleiche mit unterschiedlichen Prioritäten) an ein Produkt.</p>
<p dir="ltr">Sicherlich stehen oft die funktionalen Qualitätsfaktoren im Vordergrund:<br>
Was kann die Software? Rechnet sie richtig? Zeigt sie die Ergebnisse richtig an? Sind die Daten korrekt und sicher abgelegt? Dort wird viel Aufwand in die Qualitätssicherung investiert. Diese Punkte stehen immer im Fokus.</p>
<p dir="ltr">Aber wie sieht es mit den nichtfunktionalen Qualitätsfaktoren aus?<br>
Einheitliche Benutzungsoberflächen. Einfache Bedienung. Effiziente Umsetzung der Arbeitsprozesse in die Software. Das sind z. B. Faktoren die unter die Usability fallen. </p>
<p dir="ltr">Und es gibt noch eine Menge andere Faktoren, wie die Wartbarkeit der Software, die Testautomatisierbarkeit, die Skalierbarkeit uvm. Man muss sich immer fragen, welche QS-Maßnahmen werden in diesen Gebieten durchgeführt? Wie wird die Qualität in diesen Themen konstruiert?</p>
<p dir="ltr">Aus Kundensicht spielt auch die Laufzeit eine wesentliche Rolle. Ein Faktor dabei ist sicherlich auch, wieviele Daten über das Netz übertragen werden. In LANs ist das wichtig, im mobilen Netz noch viel wichtiger. Werden viele Daten übertragen, können die Apps auf dem Smartphone langsamer werden. Das Risiko von Verbindungsabbrüchen steigt. Und die Flatrates der Kunden (oft bieten die Provider 200 oder 300 MB an) können ggf. für den Monat nicht ausreichen, was dann erhebliche Geschwindigkeitseinbußen zur Folge hat.</p>
<p dir="ltr">Seit Mitte 2014 hat Google die Smartphone-Apps auf ein einheitliches Design umgestellt und dies mit Android 5.0 konsequent fortgeführt. Es ist prima über alle Apps und das System eine einheitliche und einfache Bedienung zu erhalten. Doch der Datenverbrauch der Apps und Hintergrunddienste erhöhte sich mit den neuen Apps und Android 5.0 deutlich. Wenn Kunden bei gleichem Nutzungsverhalten neue Mobilfunkverträge abschließen, damit am 20. eines Monats nicht die Drosselung zuschlägt, wurden Qualitätsfaktoren bei der Entwicklung vernachlässigt. Auch wenn dann durch minor Releases nachgebessert wird, hat man für einen gewissen Zeitraum Qualitätseinbußen.</p>
<p dir="ltr">Nur wenn alle Aspekte berücksichtigt werden, liefert man ein Produkt mit "guter Qualität" aus...</p>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-62107632343734834762014-11-25T12:06:00.001+01:002014-11-25T12:06:24.932+01:00 Fehlermanagement in mehreren EntwicklungslinienIn der Regel hat man ja verschiedene Versionen (Releases) einer Software. Eine beim Kunden verfügbare Version und mindestens eine Variante für die Weiterentwicklung. Nun tritt in einer Komponente (unterschiedliche Versionen) ein Fehler auf. Wie organisiert man nun das Bug-Tracking und den Ausbau? Dazu gibt es zwei prinzipielle Ansätze:<br />
<ol>
<li>Im Bug-Tracker wird für jeden Softwarestand ein Bug angelegt</li>
<li>Im Bug-Tracker hat man einen Bug, der für alle Versionen gilt.</li>
</ol>
Was bedeutet dies nun, wenn man für jede Version einen Bug im System hat (1):<br />
<ul>
<li>Für jede Version muss man einen Bug im System einstellen (Aufwand ist aber eher ein kleiner) und bearbeiten.</li>
<li>Transparenz, wie weit die Umsetzung für die jeweilige Version ist. Das ist gut für das Team, da beim Ausfall eines Kollegen (z. B. Krankheit) sofort offensichtlich wird, was noch offen ist.</li>
<li>Es wird offensichtlich, in welchen Versionen der Fehlerausbau zu testen ist (unabhängig ob dies automatisiert oder manuell geschieht).</li>
</ul>
Und wie sieht es beim Ansatz (2) aus:<br />
<ul>
<li>Haben die Entwickler ihre Aufgaben wirklich gut im Griff (keine Ablenkung durch neue Prioritäten, neue Probleme etc.) reicht nur ein Eintrag im Bug-Tracker. Bei kleinen Teams ist dies ggf. eine praktikable Vorgehensweise.</li>
<li>Es ist allerdings zu klären für welche Version der Bug im System angelegt wird (das wird vor allem schwer, wenn verschiedene Releases beim Kunden verfügbar sind).</li>
<li>Die Transparenz über den Fortschritt bei Fehlerausbau und Test in den verschiedenen Versionen hat man natürlich nicht. Und wenn der Entwickler mal krank wird, ist nicht so einfach erkennbar, was bereits erledigt wurde.</li>
</ul>
<div>
</div>
Gerade in größeren Teams und Organisationen und bei Verfügbarkeit von drei (Freigabe-Release, Pilot-Release, aktuelles Release in der Entwicklung) oder mehreren Releases tendiere ich wegen der Übersichtlichkeit zur Lösung (1). Auch weil jeder Bug gleichzeitig ein Requirement für ein Release ist und damit deutlich wird was alles für das Release zu tun ist. Aber letztendlich muss jeder für sich entscheiden, welche Vorgehensweise für die eigene Organisation besser geeignet ist.<br />
<div>
</div>
<div>
</div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-43782267728613244222013-12-10T22:10:00.002+01:002015-03-03T15:04:39.167+01:00Testing Zeitschriften im Web<span style="font-family: Arial, Helvetica, sans-serif;">In den letzten zwei Jahren hat sich bei den Zeitschriften zum Testen doch einiges getan. Vor allem gibt es recht neues deutsches Test Magazin. Nachfolgend ein Update zum <a href="http://softwaretestandquality.blogspot.com/2011/06/informationen-im-web-zum-softwaretest.html">Artikel</a> von vor zwei Jahren. K</span><span style="font-family: Arial, Helvetica, sans-serif;">ostenlos verfügbare Zeitschriften:</span><br />
<ul>
<li><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;">Testing Experience Deutsch<br /><span style="font-size: x-small;">erscheint einmal im Quartal - <a href="http://www.testing-experience.de/" target="_blank">http://www.testing-experience.de/</a></span></span></li>
<li><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;">Testing Experience Englisch<br /><span style="font-size: x-small;">sehr umfangreiche Zeitschrift, die zweimonatlich erscheint - <a href="http://www.testingexperience.com/">http://www.testingexperience.com/</a></span></span></li>
<li><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;">Professional Tester<br /><span style="font-size: x-small;">sehr bekannte englischsprachige Zeitschrift, zweimonatlich - <a href="http://www.professionaltester.com/">http://www.professionaltester.com/</a></span></span></li>
<li><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;">Tea-time with Testers<br /><span style="font-size: x-small;">monatliche Zeitschrift - <a href="http://www.teatimewithtesters.com/">http://www.teatimewithtesters.com/</a></span></span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">Testing Circus</span><span style="font-size: x-small;"><span style="font-family: Arial, Helvetica, sans-serif;">englischsprachige Zeitschrift, die monatlich</span><span style="font-family: Arial, Helvetica, sans-serif;"> </span><span style="font-family: Arial, Helvetica, sans-serif;">erscheint - <a href="http://www.testingcircus.com/">http://www.testingcircus.com/</a></span></span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">Testmagazine - The European Software Tester</span><span style="font-family: Arial, Helvetica, sans-serif; font-size: x-small;">zweimonatlich - </span><a href="http://www.testingmagazine.com/" style="font-family: Arial, Helvetica, sans-serif; font-size: small;">http://www.testingmagazine.com/</a></li>
</ul>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-61699624233517420092013-12-02T06:55:00.000+01:002013-12-02T11:08:48.104+01:00Der Change von klassischen Vorgehensweisen zum AgilenWarum ändert man die Vorgehensweise in der Softwareentwicklung? Warum wird man agil, wenn man vorher klassisch Software erstellt hat? Na klar. Man möchte die Qualität erhöhen. Bezüglich der Kundenanforderungen. Bezüglich der Stabilität. Und auch bei den weiteren Qualitätsfaktoren.<br />
Doch die agilen Projekte liefern in der Regel keine besseren Ergebnisse als klassische Vorgehensweisen, wie die Umfrage Softwaretest ermittelt hat.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9W14_ermK0tM_BMAv9EcvIqn_VWerjZWMiYco_QkgpXEGDOk1MLal8XdWPBfwfrHEKjNJIgmaaUTCxbuSHBYxHghCGjdjzryevPO96VYjzCNaP_RSWJ_tFMEywN53pCVYyl3dG8HhWgE/s1600/SoftwaretestUmfrageFehlerNachAuslieferung.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9W14_ermK0tM_BMAv9EcvIqn_VWerjZWMiYco_QkgpXEGDOk1MLal8XdWPBfwfrHEKjNJIgmaaUTCxbuSHBYxHghCGjdjzryevPO96VYjzCNaP_RSWJ_tFMEywN53pCVYyl3dG8HhWgE/s1600/SoftwaretestUmfrageFehlerNachAuslieferung.png" height="276" width="400" /></a></div>
<br />
Doch was sind die Ursachen? Die Diskussionen mit Experten im letzten Seminar haben dabei folgende mögliche Gründe zu Tage gebracht:<br />
<br />
<ul>
<li><i>Alle Beteiligten</i> benötigen einen <i>Mindshift von klassisch zu agil</i>. Teilweise geht nicht.</li>
<li>"no test - no code"<br />Wer den Code nicht richtig gut getestet hat, darf diesen nicht einchecken. Sonst läuft es niemals.</li>
<li>"Agilität ohne Test Driven Development geht gar nicht" (Zitat Prof. Dr. Mario Winter)</li>
<li>Ohne testgetriebene Ansätze (TDD, XP, Pairing etc.) sind agile Vorgehensweisen absolut fragwürdig. Das ist dann nur "Hacken".</li>
<li>Ohne eine Definition of Done wird auch keine Qualität herauskommen</li>
<li>Planning Poker ohne Berücksichtigung der Testing Tasks (oder der jeweiligen Testaufwände in den user stories) ist nur Selbstbetrug</li>
</ul>
<div>
Halbe Sachen gehen also gar nicht. Ein Change-Prozess braucht viele Coaches und eine Basis, die für Veränderung bereit ist. Sonst wird aus einem Wasserfall nur ein "agiler Wasserfall"...</div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-58771342737632393272013-11-30T14:00:00.000+01:002013-11-30T14:02:16.770+01:00Neue Sicht zum explorativen TestenDas explorative Testen ist den letzten Jahren immer mehr ins Gespräch gekommen. Vor allem im agilen Umfeld hat man immer wieder vom Einsatz gehört. Was ich bisher darüber gehört hatte, hatte mich jedoch nicht überzeugt:<br />
Wer keine systemtischen Testverfahren verwendet, wer keine Requirements definiert und wer keine richtige Vorgehensweise hat, der macht eben exploratives Testen. Unstrukturiert und chaotisch...<br />
So habe ich bisher gedacht. Doch eine Veranstaltung mit Prof. Dr. Mario Winter (<a href="http://www.gm.fh-koeln.de/~winter/" target="_blank">Link FH Köln</a>) hat mir eine neue Perspektive gegeben (natürlich liegt an seinem Aufbau und Inhalten dieser Methode).<br />
<br />
Exploratives Testen<br />
<br />
<ul>
<li>ist eine zielgerichtete Vorgehensweise um Fehler zu finden (Test-Chartas)</li>
<li>ist eine strukurierte und kreative Methode (Testing-Touren und Session-basiert)</li>
<li>ist für die Tester sehr motivierend</li>
<li>dient als Ergänzung zu systematischen Testverfahren</li>
<li>ist natürlich auch eine Methode, die man nutzen kann, wenn kaum (oder keine) Konzepte vorhanden sind </li>
</ul>
<div>
Vor allem in agilen Projekten ist der Einsatz sehr spannend. Neben dem Seminar (extrem empfehlenswert) ist auch ein Buch von James Whittaker (Testing Evangelist) sehr zu empfehlen (<a href="http://www.amazon.de/Exploratory-Software-Testing-Tricks-Techniques/dp/0321636414" target="_blank">Link zu Amazon</a>) </div>
<div>
<br /></div>
<div>
<i>Später mehr zur Methodik...</i></div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-59356104338453435982013-11-20T19:58:00.000+01:002013-11-20T19:58:13.088+01:00Fazit vom German Testing Day 2013<div style="background-color: white; color: #222222;">
Viele Eindrücke und viele Gespräche gab es auf dem German Testing Day 2013. Doch welche Dinge sind bei uns hängen geblieben? Welche Statements haben uns beeindruckt? Und was lohnt es, umgesetzt zu werden?</div>
<div style="background-color: white; color: #222222;">
<br /></div>
<ul style="background-color: white; color: #222222;">
<li style="margin-left: 15px;">Tester werden weiterhin eine wichtige Rolle in Softwareentwicklungs-Projekten haben, doch die Skills müssen erweitert werden (wenn nicht schon geschehen)</li>
<div class="im" style="color: #500050;">
<br />
<li style="margin-left: 15px;">Test Engineers sind hochqualifizierte Personen, mit Fähigkeiten die über das reine Testen hinaus gehen - da muss man sich selber fragen, ob man die Anforderungen noch erfüllt...</li>
<li style="margin-left: 15px;">Testautomatisierung hat durch die agilen Projekte stark an Bedeutung gewonnen</li>
<li style="margin-left: 15px;">Manuelle Tests sind weiterhin notwendig. Aber nicht Alles muss/kann/soll automatisiert werden</li>
<li style="margin-left: 15px;">Entscheidend für den Erfolg von agilen Projekten und agilem Test ist das Mindset. Ohne eine entsprechende Einstellung werden sich keine Erfolge einstellen</li>
</div>
<li style="margin-left: 15px;">Qualitätssicherung und vor allem "Testing" sind endgültig in der agilen Welt angekommen und bilden dabei keinen Widerspruch, sondern waren schon immer implizit vorhanden</li>
</ul>
<div style="background-color: white; color: #222222;">
Beide Keynotes waren beeindruckend. T<i style="color: #500050;">esting @ ebay</i><span style="color: #500050;"> von Michael Palotas</span> kann einem schon die Augen öffnen und wer die Chance hat, mal den ehemaligen Schiedsrichter Dr. Markus Merk live zu hören, sollte diese wahrnehmen. Diese Keynote zum Thema "Sicher entscheiden" wäre die Reise alleine schon wert gewesen.</div>
<div class="im" style="background-color: white; color: #500050; font-family: arial, sans-serif; font-size: 13px;">
<div style="font-family: 'Times New Roman'; font-size: medium;">
<br /></div>
<div style="font-family: 'Times New Roman'; font-size: medium;">
Alles in allem hat sich der German Testing Day 2013, wie auch schon der in 2011, wirklich gelohnt. Am 02.07.2014 findet die dritte Auflage statt. Schauen wir mal...</div>
<div style="font-family: 'Times New Roman'; font-size: medium;">
<br /></div>
</div>
<div style="background-color: white; color: #222222;">
Ach: Auch Location und Catering waren ziemlich gut. Dies sollte nicht unerwähnt bleiben.</div>
<div class="im" style="background-color: white; color: #500050; font-family: arial, sans-serif; font-size: 13px;">
<div style="font-family: 'Times New Roman'; font-size: medium;">
<br /></div>
<div style="font-family: 'Times New Roman'; font-size: medium;">
<i>Fazit von Alex und Frank</i></div>
</div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-11799224683658269442013-11-18T09:18:00.000+01:002016-06-17T21:23:46.921+02:00Vorträge am German Testing Day 2013Nach der Keynote gab es einige weitere spannende Vorträge. Nachfolgend einige interessante Aussagen der Referenten zu den verschiedenen Themen:<br />
<br />
Scrum-Projekte<br />
<ul>
<li>Testing ist eine "gefühlt destruktive Aufgabe". Deshalb muss im Team der Wert dieser Aufgabe klar sein (bzw. gemacht werden)</li>
<li>Testing Aktivitäten sind nicht verhandelbar!</li>
<li>Die Notwendigkeit der Testautomatisierung wird systematisch unterschätzt.</li>
<li>Agile Methoden müssen geschult werden. Ein agiles Mindset muss entstehen. Agile Projekte mit Halbwissen gehen schief.</li>
<li>Scrum-Master ohne IT-Background tun sich sehr schwer.</li>
</ul>
<div>
<br /></div>
<div>
Mobile Entwicklung</div>
<div>
<ul>
<li>Testing im mobile Bereich ist bei den nicht-funktionalen Anforderungen nochmal komplexer (z. B. Netzverfügbarkeit, Bandbreite)</li>
<li>Die Hardwarevielfalt macht die Test-Planung und Testumgebung komplexer (welche Geräte und Betriebssysteme teste ich)</li>
<li>Der mobile Markt und damit die Anforderungen an die Software/den Test verändern sich sehr schnell</li>
</ul>
<div>
<br /></div>
</div>
<div>
Tracability</div>
<div>
<ul>
<li>In komplexen Entwicklungsumgebung kann zur Steuerung die werkzeuggestützte Verwaltung der Traceability zu deutlichen Fortschritten führen. Werkzeuge (u. a. OpenSource) gibt es auch dafür.</li>
<li>Damit können z. B. folgende Fragen schnell beantwortet werden:</li>
<ul>
<li>Welchen Test muss ich durchführen, weil sich ein Feature geändert hat</li>
<li>Welcher Code ist durch geänderte Anforderungen betroffen</li>
<li>Der Kunde wünscht eine Änderung. Welche Anforderungen ändern sich? Welche Tests müssen nochmal durchgeführt werden?</li>
<li>....</li>
</ul>
<li>Aber: Die Dokumentation und Verwaltung muss vollständig gelebt werden. Sonst ist es nur Aufwand ohne den letztendlichen Nutzen.</li>
</ul>
</div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-64627146251086109342013-11-14T21:41:00.001+01:002016-06-17T21:24:02.534+02:00Keynote vom German Testing Day 2013<div class="im" style="background-color: white; color: #500050; font-family: arial, sans-serif; font-size: 13px;">
<div style="font-family: 'Times New Roman'; font-size: medium;">
Eine beeindruckende Keynote mit dem Thema <i>Testing @ ebay</i> hat Michael Palotas auf dem German Testing Day 2013 gehalten. In der Stunde hat er wahres Feuerwerk an Aussagen losgelassen. </div>
</div>
<div style="background-color: white; color: #222222;">
Sicherlich können die Vorgehensweisen bei ebay nicht auf jedes Unternehmen übertragen werden, aber einzelne Ideen sind immer anwendbar. Hier der Versuch diese festzuhalten und zu strukturieren:</div>
<div style="background-color: white; color: #222222;">
<br /></div>
<div style="background-color: white;">
Skills und Vorgehensweise:</div>
<ul style="background-color: white;"><div class="im">
<br />
<li style="margin-left: 15px;">In 3-5 Jahren haben "normale Tester" keinen Job mehr. Produkte werden heute anders gebaut als noch vor einigen Jahren. Die kleinen Inkremente, die erstellt werden, benötigen ein anderes Vorgehen</li>
</div>
<li style="margin-left: 15px;">UI-Testautomatisierung: Suites waren und sind ein big failure:<div class="im">
Suites sind doch oft schon nach drei Sprints ohne Wirkung. Die mangelnde Disziplin in vielen Projekten sorgt dafür, dass die Suites nicht mehr aktuell sind. Schlimm ist es, wenn dann Testfälle herausgenommen werden, um einen "grünen" Zustand zu erreichen.</div>
</li>
<li style="margin-left: 15px;">Stecke die Energie in die Vermeidung von Fehlern (z. B. in das Testen von UseCases), statt in das Finden und die Verwaltung (sekundäre Artefakte) von Fehlern.</li>
<li style="margin-left: 15px;">Qualität entsteht nur gemeinsam im Team. Entwickler und Tester müssen und dürfen sich nicht abschotten.</li>
<div class="im">
<br />
<li style="margin-left: 15px;">Aus Effizienzgründen sollten man die Projekte mit so wenig Mitarbeitern wie möglich starten. Zu viele bringen zuviel Overhead</li>
</div>
<li style="margin-left: 15px;">Manuelle Tests sind nach wie vor unersetzlich</li>
<li style="margin-left: 15px;">"fast feedback" aus den Tests ist erwünscht und notwendig in der agilen Entwicklung. Effizienz steht hier im Vordergrund.</li>
</ul>
<div style="background-color: white;">
Haltung der Mitarbeiter:</div>
<div style="background-color: white;">
</div>
<ul style="background-color: white;"><div class="im">
<br />
<li style="margin-left: 15px;">Test Driven Development benötigt ein entsprechendes Mindset</li>
</div>
<li style="margin-left: 15px;">Agile Entwickler benötigen Testing Know-how und ein Testing Mindset</li>
<li style="margin-left: 15px;">Agile Tester müssen entwickeln können, um die Entwickler zu verstehen und Sie unterstützen zu können - Domainen-Wissen ist nicht mehr alles</li>
<div class="im">
<br />
<li style="margin-left: 15px;">Qualität entsteht nur, wenn die Organisation Qualität lebt</li>
<li style="margin-left: 15px;">In vielen Projekten liegt der Focus auf der Diskussion, ob man einen Fehler gefunden hat, anstatt diesen sofort zu beheben</li>
</div>
</ul>
<div style="background-color: white;">
Weitere spannende Aussagen:<br />
<ul><div class="im">
<br />
<li style="margin-left: 15px;">"THE RACE TO ZERO" ist ein Fehler. Die Kosten für qualitätssichernde Maßnahmen können nicht auf Null gesenkt werden. Qualität kostet.</li>
<li style="margin-left: 15px;">Outsourcing bringt nicht wirklich etwas bei den Kosten und der Qualität. Auch in Europa kann hohe Qualität mit hoch bezahlten Menschen erreicht werden. Summa summarum zumindest kostenneutral, aber mit höherer Qualität</li>
</div>
<div class="im">
<br />
<li style="margin-left: 15px;">Tester (Test Engineers) werden bei Ebay genauso gut bezahlt wie Entwickler. Bei guten Leuten darf man nicht sparen (beim Hygienefaktor Geld)</li>
</div>
<li style="margin-left: 15px;">Freiräume sind für Mitarbeiter enorm wichtig (kennt man ja auch von anderen amerikanischen Unternehmen) - Vertrauen und eine lange Leine sind hier unverzichtbar</li>
</ul>
</div>
<i>Alex und Frank</i>Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-77524042218910519572013-11-13T22:34:00.001+01:002013-11-13T22:34:34.873+01:00Pyramide der agilen TestautomatisierungIn agilen Projekten steht und fällt die Qualitätssicherung mit der Testautomatisierung. Doch mit welcher Art der Testautomatisierung? Dazu bietet die Pyramide der agilen Testautomatisierung Anhaltspunkte. Mir persönlich gefällt die nachfolgende Variante von M. Cohn recht gut. Die weiteren Varianten von Mezaros und Crispin unterscheiden sich aus meiner Sicht aber auch nur geringfügig.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWnr5FNLKWzXuwdK6So9zfRSp59FSyOxwmXeGvDoIctlvRXpMMd0LJYnBnAfKk9_xJkMbz3CTRgt2__PpK8iPam-wC5LLJcu9SBuDXaJCmEj6F3sfVvFSlQzukO5q_QIiTerM7s-mmldA/s1600/PyramideAgileTestautomatisierung.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWnr5FNLKWzXuwdK6So9zfRSp59FSyOxwmXeGvDoIctlvRXpMMd0LJYnBnAfKk9_xJkMbz3CTRgt2__PpK8iPam-wC5LLJcu9SBuDXaJCmEj6F3sfVvFSlQzukO5q_QIiTerM7s-mmldA/s1600/PyramideAgileTestautomatisierung.png" height="186" width="400" /></a></div>
<br />
Wie die Pyramide verdeutlicht, wird der Erfolg der agilen Testautomatisierung weitgehend durch die Unit-Tests bestimmt. Diese sollten am gesamten Anteil an der Testautomatisierung ca. 70% ausmachen. Sie sind auch verhältnismäßig einfach zu erstellen. UI-Tests werden in der Regel spät erstellt, müssen intensiv gewartet werden (bei jeder Oberflächenänderung) und sind auch wegen der Werkzeuge recht teuer (was allerdings kein Argument sein sollte, komplett darauf zu verzichten).<br />
Natürlich muss der tatsächliche Umfang manueller und automatischer Tests individuell im Projekt festgelegt werden. Und die Art der Applikation bestimmt auch, ob Unit-Tests 70% oder doch nur 60% ausmachen. Die Pyramide gibt jedoch einen wichtigen Hinweis, wie die einzelnen Ebenen zu gewichten sind.Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-63282191289619864262013-11-05T21:45:00.000+01:002013-11-06T06:00:55.047+01:00Testen kann doch jeder, oder?Ein wirklich spannenden Vortrag zum Testen in agilen Projekten hat heute <a href="http://www.xing.com/profile/Michael_Fischlein" target="_blank">Michael Fischlein</a> bei einer <a href="http://www.asqf.de/" target="_blank">ASQF</a> Veranstaltung gehalten. Nicht nur inhaltlich war das hörenswert, auch die agile Form des Vortrags war sehr gelungen.<br />
Die Zuhörer als Product Owner haben die Inhalte (es waren viele User Stories vorgegeben) ausgewählt und priorisiert, die im Vortrag (Sprint) präsentiert wurden. Nach dem Review bildete eine Retro zum Vortrag den Abschluss. Äußerst gelungen der Weg, über die Vortragsmethodik agile Vorgehensweisen zu vertiefen.<br />
<br />
Seine fachliche Kernaussage: Testen kann nicht jeder!<br />
Man kann nicht einfach einen Studenten (nichts gegen diese) hinsetzen. Man kann nicht diejenigen zum Tester im agilen Projekt machen, die sonst kaum oder nicht richtig einsetzbar sind.<br />
<br />
Und warum kann es nicht jeder:<br />
<br />
<ul>
<li>Im agilen Projekt mit den klaren Timeboxen kann keine Zeit vertrödelt werden. Die Testfälle müssen hochwertig sein und effizient ausgeführt werden. Die Tests müssen gut vorbereitet sein. Gutes Basiswissen zum Test (Certified Tester FL /AL) ist absolut notwendig.</li>
<li>Da agil vorgegangen wird, dürfen auch Kenntnisse wie z. B. zum explorativen Testen nicht fehlen.</li>
<li>Die hohe Automatisierung in agilen Projekten bedeutet, dass Grundverständnis zu Automatisierungswerkzeugen, und -vorgehensweisen verfügbar sein muss (also mindestens rundimentäre Programmierkenntnisse).</li>
<li>Das notwendige agile Mindset der Person verlangt umfangreiche social Skills, Selbständigkeit und effiziente Selbststeuerung</li>
</ul>
<div>
Es handelt sich also um einen gut ausgebildeten Generalisten. Im Gespräch kam aber rüber, dass dies im Management vieler Unternehmen nicht so gesehen wird. Es besteht also Handlungsbedarf, um agile Projekte nicht schon frühzeitig scheitern zu lassen. </div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com2tag:blogger.com,1999:blog-5916612914444005751.post-482744869557424972013-11-04T18:34:00.001+01:002013-11-04T18:34:30.701+01:00Rolle des Testers im agilen UmfeldAgil. Das Schlagwort schlechthin. Egal auf welcher Tagung/Veranstaltung man ist, alles dreht sich um agile Vorgehensweisen. Auch beim letzten ASQF Testing Day war dies wieder der Fall. Ich versuche die wesentlichen Aussagen aus einigen Vorträgen zusammen zu fassen:<br />
<br />
<ul>
<li>Unit Tests sind fester Bestandteil der Entwicklung (und sollten mit einer Ziel-Testabdeckung in der Definition of Done festgeschrieben werden)</li>
<li>Testen im agilen besteht zwangsläufig aus Testautomatisierung und (aber auch!) aus manuellen Tests</li>
<li>Die Integrationstests sind automatisiert und laufen maximal im Sprint +1 (ideal im selben Sprint)</li>
<li>Alle Tests laufen entwicklungsbegleitend (nicht am Ende des Projekts !!)</li>
<li>Teammitglieder, die die Rolle des Testers wahrnehmen sollten frühzeitig eingebunden werden (Planning Meeting / Daily Scrum)</li>
<li>Die Testautomatisierung übernehmen die Software Engineer in Test (SET), ggf. ein separates Testing-Team (wer es sich leisten kann)</li>
<li>Für die Testautomatisierung sollte bei der DoD eine Coverage festgelegt werden. Das macht die Messung für die Erreichung der Sprint-/Entwicklungsziele deutlich einfacher</li>
<li><span style="color: #38761d;">Bugfixing hat die Prio 1</span>. Es wird nicht weiterentwickelt, wenn die abgelieferte Qualität im letzten Meilenstein/Sprint nicht stimmt. <i>Das spricht mir aus der Seele :-)</i></li>
</ul>
<div>
<br /></div>
<div>
Folgendes fällt mir dazu ein:</div>
<div>
<ul>
<li>Bindet irgendjemand den Tester nicht richtig bzw. frühzeitig ein? (scheinbar schon, sonst kämen die Aussagen ja nicht)</li>
<li>Welche Rolle nimmt der Tester ein? Des letzten in der Kette, der eine ungeliebte, in Augen einiger wohl auch ziemlich wertlose Rolle, wahrnimmt... - dann sollte das Team drüber nachdenken</li>
<li>Der Tester wird mehr und mehr zum Engineer</li>
</ul>
</div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-9901263908591355702013-02-13T06:20:00.000+01:002013-02-13T06:20:00.289+01:00Soft-Skills eines Testers (TE)Hatte sich der Beitrag <a href="http://softwaretestandquality.blogspot.com/2013/01/welche-skills-braucht-ein-tester.html" target="_blank">Welche Skills braucht ein Tester?</a> eher mit den Hard Skills befasst (und die Anforderungen sind nicht gering), so möchte ich nachfolgend einige Soft Skills beschreiben, die nach meiner Ansicht einen guten TE (Test Engineer) ausmachen.<br />
<br />
<b>Verlässlich sein</b><br />
Wenn alle Probleme korrekt und umfangreich dokumentiert werden, kann der Entwickler oder Architekt diese gut nachvollziehen. Das führt nicht zu langen und überflüssigen Diskussionen. Man erwirbt sich nach einer gewissen Zeit auch das Vertrauen bei Anderen, so dass die dokumentierten Abweichungen ernsthaft und zeitnah bearbeitet werden.<br />
<br />
<b>Nachhaltig sein</b><br />
Nutze Werkzeuge und Checklisten. Gestalte die Tests so, dass die Abläufe und Ergebnisse für jeden transparent sind. Nur so sind die Tests auch wiederholbar und Ergebnisse belastbar. "Mach es ordentlich..."<br />
<br />
<b>Genau sein</b><br />
Es zählen nicht nur die schweren Fehler. Auch Schreibfehler in Dialogen gehören nicht in eine Software mit hoher Qualität. Die Aufmerksamkeit des TEs gehört damit allen Details der Software. <br />
<b><br /></b>
<b>Keine Kompromisse zur Qualität eingehen</b><br />
Was nicht passt, passt einfach nicht. Das muss auf den Tisch. Geht man Kompromisse ein, kommt es zum schleichenden Qualitätsverlust, der mittel- und langfristig für den Kunden dramatisch sein wird.<br />
<br />
<b>Ehrliches Reporting zur eigenen Arbeit</b><br />
Nicht alles kann 100% getestet werden. Nicht jeder Test hat wie geplant funktioniert. Der Zeitdruck bis zu einer Freigabe führt zum Testen nach Risikogesichtspunkten. Und da gibt es auch mal Lücken. Kein Problem, wenn es allen klar ist, und das Risiko begrenzt ist.<br />
<br />
<b>Skeptisch sein</b><br />
Man sollte nicht glauben, dass das abgelieferte Programm fehlerfrei ist und auch das macht, was in der Spezifikation definiert ist. Deswegen sollte man genau prüfen, und alle erworbenen Fähigkeiten dazu einsetzen, Fehler zu finden. Denn es gibt immer welche...<br />
<div>
<br /></div>
<div>
<b>Die Software aus Kundenperspektive betrachten</b><br />
Versuche beim Test alles aus Sicht des Kunden zu betrachten. Auch wenn das Konzept die Dinge so vorsieht, wie sie dann umgesetzt sind. Das User Interface. Die Stabilität. Die Funktionen. Kann der Kunde so damit leben? Und betrachte die Prozesse. Was ist, wenn er die Software doch anders nutzt?</div>
<br />
<b>Kooperativ sein</b><br />
Jeder macht mal Fehler. Auch der TE. Deshalb versuche immer einen Weg mit deinen Partnern (Entwickler, Projektleiter, Management, Tester, u. A.) zu finden, der auf Kooperation basiert. Ständige Konfrontation bringt einen nicht weiter. Ist man verlässlich, kann man auch sachlich jedes Gefecht positiv ausfechten.<br />
<br />
<b>Kommunikativ sein</b><br />
Mit seinen Partnern muss man die Ergebnisse eines Tests auch besprechen. Es bringt einen nicht weiter, eine Auswertung mit dem Kommentar hinzuwerfen "Das ist Mist". Und für die Partner muss man bei Fragen auch Rede und Antwort stehen.<br />
<br />
<b>Lerne aus den Fehlern</b><br />
Manche Probleme treten immer wieder auf. Nutze dieses Wissen für die Tests, auch wenn das Testkonzept einen interessanten Testfall nicht vorsieht. Exploratives Vorgehen ist sicher auch eine Fähigkeit eines wirklich guten TEs.<br />
<br />
Schon wieder eine Menge Qualifikationen, die ein guter TE besitzen sollte. Und die meisten Skills kann man nicht so einfach im Seminar oder Buch erlernen...Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-53911658391838519582013-01-22T22:20:00.001+01:002013-01-22T22:20:41.825+01:00Welche Skills braucht ein Tester?<span style="font-family: inherit;">Aus meiner Sicht ist ein Tester nicht jemand, der ein Dokument vorgesetzt bekommt und dann die Test-Schritte ausführt. Nein. Ein Tester (besser gefällt mir die englische Bezeichnung TE - Test Engineer) benötigt deutlich mehr Skills.</span><br />
<span style="font-family: inherit;"><br /></span>
<b><span style="font-family: inherit;">Testing Know-How</span></b><br />
<span style="font-family: inherit;">Der TE benötigt methodisches Know-How zum Erstellen von Testkonzepten, wie zum Beispiel die Äquivalenzklassenanalyse, Entscheidungstabellen oder die Grenzwertanalyse. Er beherrscht außerdem Review-Techniken, um in frühen Entwicklungsphasen Qualität sichernd mitzuwirken.</span><br />
<span style="font-family: inherit;">Er kennt die Begriffe zum Testing (wichtig ISTQB Curriculum) und aus dem Entwicklungsvorgehen (V-Modell XT, Agile Vorgehensweisen, CMMI etc.). Sonst klappt die Verständigung zwischen TE's und mit den Softwareentwicklern (SE) einfach nicht - auf jeden Fall nicht mit TEs aus anderen Unternehmen. </span><br />
<br />
<b><span style="font-family: inherit;">Testziele und Testfälle definieren</span></b><br />
<span style="font-family: inherit;">Die Qualitätsfaktoren (Funktionalität, Zuverlässigkeit, Robustheit, Benutzbarkeit, etc.) sind bekannt und für alle diese Faktoren kann er Testziele festlegen und Testfälle definieren. Damit nicht immer alles getestet wird, legt er Prioritäten pro Test fest und kann Risiken (Produktrisiken, Fehlerrisiken, Komplexitätsrisiken etc.) abschätzen. Er hat also eine Teststrategie.</span><br />
<br />
<b><span style="font-family: inherit;">Tests organisieren</span></b><br />
<span style="font-family: inherit;">Selbstverständlich kann er auch Tests managen. Testumgebungen und Testdaten definieren und erstellen. Testressourcen (Maschine, Mensch, Testzeiten) festlegen ist selbstverständliches Handwerkszeug.</span><br />
<span style="font-family: inherit;"><br /></span>
<b><span style="font-family: inherit;">Werkzeuge kennen und nutzen</span></b><br />
<span style="font-family: inherit;">Viele dieser Aufgaben kann man nur effizient erfüllen, wenn man die entsprechenden Testwerkzeuge kennt und intensiv nutzt. Und </span><i style="font-family: inherit;">jeder </i><span style="font-family: inherit;">im Team muss die festgelegten Werkzeuge nutzen. Da spielt es keine Rolle, ob zur Testplanung Excel oder ein High-End Werkzeug genutzt wird. Natürlich machen integrierte Werkzeuge wie Quality Center, MS Test Manager, Test Bench oder auch Open Source Werkzeuge Sinn, in denen manuelle und automatische Testfälle (als Bestandteil von Testsuiten) definiert werden können und nach der Testausführung auch die Fehler gleich im System dokumentiert und verfolgt (</span><a href="http://softwaretestandquality.blogspot.com/2013/01/fehler-lebenszyklus.html" style="font-family: inherit;" target="_blank">Bug Life Cycle</a><span style="font-family: inherit;">) werden können.</span><br />
<span style="font-family: inherit;"><br /></span>
<br />
<b><span style="font-family: inherit;">Fachliches Know-How</span></b><br />
<span style="font-family: inherit;">Für hochwertige Tests benötigt der TE natürlich fachliches Wissen zum Produkt oder technisches Wissen, wenn das Testgebiet z. B. eher im Bereich von Backends oder Datenbanken liegt (in dem Fall ist das Fachwissen eben Wissen über die Technik). Ohne fachlichen Hintergrund kann kein guter Testfall und kein gutes Testkonzept entstehen. Dazu muss ein TE auch Fachkonzepte und Use Cases verstehen können.</span><br />
<br />
<b><span style="font-family: inherit;">Testen...</span></b><br />
<span style="font-family: inherit;">Ja klar. Selber testen ist auch ein wichtiger Teil des Jobs. Die Testfälle ausführen und Abweichungen hochwertig dokumentieren, machen ebenfalls einen guten TE aus. Dazu gehören z. B. die Fähigkeiten der Klassifikationen von Fehlern, der Bewertung von Fehlerschwere und -dringlichkeit aus Sicht des Kunden und auch eine Dokumentation, die ein SE nachvollziehen kann, um einen Fehler zu reproduzieren.</span><br />
<span style="font-family: inherit;">Gute Tester mit viel Erfahrung finden Fehler, an die vorher kein Entwickler gedacht hat.</span><br />
<br />
<span style="font-family: inherit;">Und er kann programmieren. Muss er das wirklich können? Wenn ja, ist das klasse. Dann steht der Testautomatisierung, und damit einer weiteren Qualitätssteigerung, nichts mehr im Wege. Aber viele TEs können es (noch) nicht. Doch vielleicht gibt ja auch hier Google vor, wohin der Weg in der Softwareentwicklung führt. Wie habe ich vor kurzem gelesen: "<span style="background-color: #fafafa; color: #333333; line-height: 19px;"><i>Test Engineers at Google do code</i></span>".</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">Noch eine Anforderung mehr an den TE. Dabei ist sein benötigtes Fachwissen und Aufgabengebiet schon sehr umfangreich. Eine permanente Weiterbildung ist unabdingbar, da geht des dem Test Engineer </span><span style="font-family: inherit;">genau so wie dem Software Engineer...</span><br />
<br />
<br />
<br />
<br />Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-82312381494048898402013-01-20T22:46:00.002+01:002013-01-20T22:46:50.747+01:00Warum wird man eigentlich Tester?<div dir="ltr">
Wann man tagtäglich mit dem Test von Software beschäftigt ist, egal ob in der Funktion des Testingenieurs, des Testers oder auch des Testmanagers, fragt man sich öfter, warum man dies eigentlich tut.</div>
<div dir="ltr">
Man findet Fehler, die keiner gemacht hat. Man prüft etwas, was sich nicht geändert hat, obwohl es sollte. Man bereitet einen Test vor, den plötzlich keinen mehr interessiert. Man designt Testfälle, die auf Grund extremer Agilität überflüssig wurden. Man prüft das Testobjekt, obwohl es noch gar nicht bereit für den Test ist. Ok. Sollte nicht passieren. Dinge, die jedem Softwaretester aber immer wieder unterkommen.</div>
<div dir="ltr">
Und trotzdem macht man dies. Warum?</div>
<div dir="ltr">
<br /></div>
<div dir="ltr">
Weil man etwas verbessern möchte</div>
<div dir="ltr">
Dem Kunden etwas möglichst Gutes zu bieten, das spornt an. Deswegen testet man. Deswegen bereitet man die Tests gewissenhaft vor. Und deshalb streitet man sich mit den "Bei mit geht's" Entwicklern.</div>
<div dir="ltr">
<br /></div>
<div dir="ltr">
Neugierde</div>
<div dir="ltr">
Irgendwie steckt die Neugierde ja in uns drin. Schauen, ob es wirklich das macht, was es soll. Das System ausreizen. "Und einen Spaß dabei haben", doch einen Bug entdeckt zu haben.</div>
<div dir="ltr">
<br /></div>
<div dir="ltr">
Kreativität</div>
<div dir="ltr">
Es ist auch interessant, immer wieder Neues vor sich zu haben. Neue Tests zu entwickeln. Die Tests immer wieder zu verfeinern. Und Dinge auszuprobieren, von denen man glaubt, dass keiner daran gedacht hat.</div>
<div dir="ltr">
<br /></div>
<div dir="ltr">
Hat jemand noch eine andere Motivation?</div>
<div dir="ltr">
<br /></div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com2tag:blogger.com,1999:blog-5916612914444005751.post-50694434456948782292013-01-17T06:30:00.000+01:002013-01-17T06:30:03.706+01:00Was ist Qualität?<div dir="ltr">
Gesehen bei einer netten Kollegin, die mir spannende Ansätze zur Verbesserung der Steuerung von QS- Maßnahmen vorgestellt hat.</div>
<div dir="ltr">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigO5XxlqTEt5C1E3-yUvhaH5UqJPFlrpQq301lWIFYdS3kbEJZnJ-0C8LQkfXiEx281CccykxXPUNapACWuEkEBM375PuzCSlkdC5cfXt2arew86gmjhLi6KH11W_HWsdSBi91zYMuR58/s1600/IMG_20130116_095331.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"> <img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigO5XxlqTEt5C1E3-yUvhaH5UqJPFlrpQq301lWIFYdS3kbEJZnJ-0C8LQkfXiEx281CccykxXPUNapACWuEkEBM375PuzCSlkdC5cfXt2arew86gmjhLi6KH11W_HWsdSBi91zYMuR58/s640/IMG_20130116_095331.jpg" height="400" width="300" /> </a> </div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-38774834784522441422013-01-15T08:30:00.000+01:002013-01-15T23:09:23.065+01:00Six Sigma für Software - kaum RelevanzSig Sigma für Software war in den Jahren 2005-2008 ein Trend, der inzwischen jedoch stark abgeflaut ist. Auf Tagungen zur Softwareentwicklung und auch in Fachzeitschriften ist davon fast nichts mehr zu hören oder zu lesen. Im besagten Zeitraum wurden von verschiedenen Anbietern (u.a. vom ASQF) Seminare dazu angeboten. Und auch in der Presse (Computerwoche und Computerzeitung) gab es Artikelserien.<br />
<br />
Was ist Six Sigma für Software?<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
Six Sigma ist eine Methode zur Verbesserung von Prozessen (<a href="http://de.wikipedia.org/wiki/Six_Sigma">Six Sigma bei Wikipedia</a>). Vor allem in der Industrie, mit teilweise komplizierten Fertigungsprozessen, wurde Six Sigma erfolgreich eingesetzt, um bessere Ergebnisse zu erzielen . Ein wesentlicher Bestandteil von Six Sigma sind statistische Methoden zur Analyse bestehender Prozesse oder von Kundenwünschen.<br />
Für die Software-Entwicklung hatte vor allem Dr. Thomas Fehlmann Methoden aus Six Sigma aufgegriffen und diese zu einem "Paket" für die Software-Entwicklung zusammengestellt. Er hat ein Buch darüber geschrieben und bietet auch Dienstleistungen auf diesem Gebiet (<a href="http://www.e-p-o.com/">euro project office</a>) an.<br />
<br />
Warum ist Six Sigma in der Software-Entwicklung kein großer Trend mehr? Was hat eine Marktdurchdringung verhindert?<br />
<ul>
<li>Six Sigma für Software ist kein echtes Vorgehensmodell, wie das V-Modell XT oder agile Modelle (z. B. Scrum), sondern eher ein Bausteinkasten.<br />Damit eignet es sich nicht, um einen kompletten Entwicklungsprozess danach auszurichten.</li>
<li>Six Sigma für Software eignet sich auch nicht als Modell für ein Audit, weil Teile fehlen, welche die ganzheitlichen Modelle wie CMMI oder SPICE enthalten.<br />Dazu war Six Sigma auch ursprünglich nicht gedacht.</li>
<li>Es gab kaum Unternehmen in der Software-Branche, die dieses Thema aufgegriffen haben, um es dann intensiv voranzutreiben. So ist auch keine Erweiterung oder Vervollständigung zu einem Gesamt-Modell entstanden.</li>
</ul>
<div>
Nichts desto trotz lohnt es sich, die Tools einmal anzusehen. Es gibt verschiedene Six Sigma Tools für die Kundenorientierung, die Prozessorientierung und die Nutzung von Metriken. Alle können auch im Software-Entwicklungsprozess eingesetzt werden.</div>
Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0tag:blogger.com,1999:blog-5916612914444005751.post-36933215624254562092013-01-09T09:00:00.000+01:002013-01-09T13:43:54.351+01:00Fehler-LebenszyklusIn der Literatur wird immer wieder vom Fehler-Lebenszyklus (Bug Life Cycle) gesprochen. Dieser wird in vielen unterschiedlichen Varianten erwähnt. Oftmals wir er als Ausschnitt des Softwaretest-Lebenszyklus betrachtet. Oft aber auch als eigenständiger Lebenszyklus. Die nachfolgende Grafik zeigt die relevanten Bestandteile des Fehler-Lebenszyklusses.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEizOI9QkSMmQTFTl-3dOxOPM0tlFxVDzdRuOOfzET_bKT4cb5pggct0IpfypI1inX4FAKEqhmNnRsiMj-BDarMogQsUGZPSWYv1T4UJYZxiHiQSib2RIQLYJ9JI2rwlOvgf2QQHQMPt9LE/s1600/BugLifeCycle.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEizOI9QkSMmQTFTl-3dOxOPM0tlFxVDzdRuOOfzET_bKT4cb5pggct0IpfypI1inX4FAKEqhmNnRsiMj-BDarMogQsUGZPSWYv1T4UJYZxiHiQSib2RIQLYJ9JI2rwlOvgf2QQHQMPt9LE/s1600/BugLifeCycle.png" height="372" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Bug Life Cycle</td></tr>
</tbody></table>
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />Frank Strubehttp://www.blogger.com/profile/16426703347659423525noreply@blogger.com0