ZA078 - Continuous System Testing

30.01.2014 00:00:00.000 Stunden 00:00:00.000 Minuten



On Air in dieser Episode

Zusammenfassung

Kontinuierliches Testen so wichtig extrem wichtig, gerade wenn mit einer großen Variantenvielfalt umgegangen werden muss. Ich bin im Gespräch mit Rudolf Grötz. Er ist Head of QA bei Jumio Inc. in Wien und erzählt über agiles Testen in seinem Umfeld.

Der Inhalt dieser Episode:

  1. Warum ist Continuous Testing so wichtig?
  2. Wie können mit komplexen Systeme effektiv getestet werden?
  3. Wie kann eine große Variantenvielfalt gehandhabt werden?
  4. Wie funktioniert Continuous Deployment
  5. Was sind Flaky Tests?

Rudolf Grötz im Netz:

Subscription link

Wenn Euch der Podcast gefällt, abonniert Ihn und erhaltet zukünftig kostenlos alle neuen Episoden direkt auf Eurer Smartphone:

iTunes | Zune | RSS

Euer Feedback

Wenn Ihr eine Idee habt für den Podcast oder eine Frage für eine der zukünftigen Episoden, schreibt mir eine Mail an feedback@zukunftsarchitekten-podcast.de

Wenn Euch die Episode gefallen hat, bitte bewertet sie bei iTunes und schreibt eine ehrliche Meinung. Das würde sehr helfen, die Commuity zu erweitern! Danke.

8 Kommentare
  1. H.-J. Tappe sagte:

    Wir testen ebenfalls eine embedded HW/SW Integration. In meinen Projekten sind wir damit angefangen, eine reproduzierbare Test-Umgebung zu erstellen. Dafür haben wir die Linux-Pakete ins Konfigurations-Management eingecheckt, daraus automatisiert eine Live-CD erstellt und diese auf der Test-Runner-Hardware laufen lassen. Andere Test-Umgebungen laufen mittlerweile einfach nur in einem chroot oder verwenden eine virtuelle Maschine, sofern das möglich ist (z.B. durch Trennung des Test-Runners und den Hardware-Analyzern). Das Problem, was man damit löst ist, dass es sonst auf einzelnen Systemen immer wieder undokumentierte Sonder-Einstellungen gab (z.B. durch Setzen spezieller Umgebungsvariabeln). Die Nutzung eines reproduzierbaren Umgebung hat dieses Problem gelöst…

    • R. Groetz sagte:

      Hallo,

      da hört sich ja voll nach Infrastructure as a Code an. Genau diese Sondereinstellungen verhindern wir mit dem Build-Deploy-Test-Destroy Konzept. Also stimmt das was Maik sagt: "Im Prinzip können wir (die Embedded Fraktion) das auch…"

      lg
      rg

  2. Jan sagte:

    Super Podcast Episode, mal wieder :) … und ein toller Gast.

    Ich arbeite als UX Designer in einem Team welches vergleichbar zu dem vorgeht was Rudolf beschrieben hat. Nur kann man eigentlich nicht, und das hat mir in der Episode etwas gefehlt, Aspekte der User Experience, funktionierende Interaktionskonzepte und Usability automatisiert testen (glaube ich :).

    Konkrete Fehler die ein UX Designer im Team finden könnte, sind z. B.
    – Das Logo ist 1 Pixel zu weit rechts
    – Die Linie der untersten Tabellenzeile ist 2 Pixel zu dick
    – Der OnPress State des Submit Buttons hat die falsche Hintergrundfarbe
    – Im Portrait-Modus bricht die Überschrift nicht korrekt um
    … usw. :)

    Da würde mich Euere Erfahrung interessieren.

    • R. Groetz sagte:

      Hallo Jan,

      danke für den "tollen Gast", das geht runter wie Honig.

      UI Glitches automatisiert finden ist ziemlich schwer und zum Teil sehr aufwendig weil das nur über Bildvergleiche geht. Trotzdem beschäftigen wir uns auch schon damit.

      Zur Zeit testen wir in unserer Test Pipeline automatisiert Responsive Design auf Android Emulatoren. Die Emulatoren beziehen wir über ein Cloudservice (testobject.com) die auch eine Testbench mit Image Recognition anbieten. Wie wir das machen stelle ich bei den Objekt Spektrum Informations Days vor. Die sind am 1/2/3.4 April in Stuttgart, Darmstadt und Köln. Gerne kann ich dir eine VIP-Karte für einen der Tage zukommen lassen und wir können darüber diskutieren.

      lg
      rg

  3. Gregor Gramlich sagte:

    Sehr gute Episode – ich habe vieles wieder erkannt, das wir schon machen, und auch einiges, das wir noch nicht machen.
    Wir sind in der "reinen" Software Entwicklung tätig und "auf dem Weg".
    Die Initiative zum Continuous Testen geht bei uns leider nur von den Entwicklern aus. Die Test Abteilung beschäftigt sich (auch aufgrund von vielen Altlasten) mehr mit anderen Themen. Ich werde den Podcast aber mal weiter empfehlen, vielleicht weckt er ja Interesse und man findet doch langsam mal zusammen.
    Das Video von Rudolf sehe ich mir heute Abend mal an.

    Schade dass Continuous hier in mehreren Varianten falsch geschrieben wurde :-)

    • Maik Pfingsten sagte:

      Hallo Gregor,

      Danke dir für dein Feedback! Irgendwann siehe ich meine eigenen Rechtschreibfehler einfach nicht mehr. Ich habe hoffentlich alle Continuous Varianten korrigiert :-)

      Schönen Gruß aus Köln,

      Maik

    • Rudolf sagte:

      Hallo Gregor,

      bemerkenswert, dass bei euch die Initiative von den Entwicklern ausgeht. Meine Erfahrung zeigt, dass bei den meisten Entwicklungsteam nichts mehr nach Continuous Integration kommt. So nach dem Motto: "Auf meinem Rechner läuft es!"

      lg
      rg

  4. Marco Jacob sagte:

    Wieder mal eine sehr spannende Folge. Hier habe ich für den Bereich der "normalen" Anwendungs-Softwareentwickler viele interessante Punkte mitgenommen. Wir bewegen grade das Thema Testautomatisierung sehr stark. Bei uns sind Integration vieler alter Backend-Systeme und Testdaten derzeit ein großes Thema. Da hat mir Rudolf Grötz die Augen geöffnet, wie viel bei uns eigentlich noch fehlt. Ein prima Anreiz für mein aktuelles Thema. Danke!

Kommentare sind deaktiviert.