Downloads

In der Cloud zu sein beziehungsweise etwas mit der Cloud zu machen, ist hip und modern. Gleich nach Scrum, Agile und DevOps ist die “Wolke” derzeit eines der Schlagwörter in der IT-Welt. Je nach Blickwinkel durchaus mal im positiven wie auch negativen Licht. Erstaunlicherweise taucht der Begriff aber verhalten wenig im Zusammenhang mit Testen auf. In anderen Bereichen wie E-Mail, Webservices, Apps usw. ist es bereits üblich, externe Dienste einzukaufen und diese tief in die eigenen internen Infrastrukturen und Prozesse einzubetten.
An dieser Stelle setzt der Artikel an und zeigt Szenarien auf, in denen es sinnvoll ist, Teile von Testprozessen mit Cloud-Diensten zu ergänzen. Neben den Vorteilen soll auch die Betrachtung der Grenzen nicht zu kurz kommen. Die zentrale Frage ist hier stets: Wann ist die Integration sinnvoll und wann nicht? Inhaltlich werden zunächst die verschiedenen Typen von Cloud-Diensten vorgestellt. Zu den einzelnen Diensttypen werden anschließend ausgewählte Dienste aus der Microsoft Azure Cloud für den Testbereich herausgepickt. Als Szenarien werden exemplarisch Testmanagement, Bereitstellung von Testumgebungen und Lasttests in der Cloud betrachtet.
Autor: Nico Orschel

Vor kurzem fielen mir meine alten Unterlagen aus Studienzeiten in die Hände. Beim genaueren Hinsehen entdeckte ich kurz hinter einem Wasserfall- und dem Spiralmodell meine Notizen zu “Kapitel 3: Anforderungs- und Projektmanagement”. Mit einem amüsierten Lächeln blätterte ich diese Seiten durch und dachte: “Früher war alles einfacher”. Meine anhaltende Erheiterung galt dabei der Dokumentation einem meiner ersten Softwareprojekte. Die Semesterarbeit trug den Titel “Medienverwaltung mit integriertem Leihsystem” (MVLS). Damals hatten wir zu viert tagelang die Anforderungen akribisch aufgenommen, nach Wichtigkeit und technischer Machbarkeit sortiert und schließlich unserem Professor zur Korrektur vorgelegt, bevor wir mit dem für einen angehenden Softwareentwickler angenehmeren Teil anfangen durften. Lesen Sie im Artikel, mit welchen Hürden wir vier als Studenten unser Projekt abgeschlossen haben und was wir alle daraus heute noch lernen können.
Autor: Stefan Mieth

Kavalierstart (Seite 10)
Ein Team, sieben Mitglieder, eine Aufgabe: Übermorgen soll‘s losgehen. Bis dahin muss die Entwicklungsumgebung mit allem Pipapo stehen. Ach ja: Kosten darf das Ganze auch nur sehr wenig. Mit Azure kann‘s klappen!
Autor: Boris Wehrle und Benjamin Fischer

Besser coden unter Aufsicht
Entwickler coden ja gern einfach drauflos. Im Team aber müssen Programmierrichtlinien den kreativen Drang kanalisieren und für andere nachvollziehbar machen. Ihre Einhaltung ist immer wieder zu überprüfen – am besten automatisch.
Autor: Boris Wehrle und Benjamin Fischer

Softwareentwicklung ist Teamarbeit. Die sich immer mehr verbreitenden agilen Vorgehensmodelle sind das beste Beispiel dafür. Dabei wird beispielsweise ein Sprint bzw. eine Iteration gemeinsam geplant, sich täglich über den Fortschritt ausgetauscht und abschließend gemeinsam reflektiert. Am Ende des Sprints steht ein Softwareprodukt zur Verfügung, welches neue Features und Verbesserungen enthält und von den Kunden genutzt werden kann. Soweit die Theorie. Häufig ist die automatische Auslieferung neuer Softwareversionen mit dem Kopieren der Ergebnisse eines zentralen Server Builds auf ein Netzlaufwerk oder einen Webserver für Entwicklungsabteilungen beendet. Bis dahin ist diese Vorgehensweise als Continuous Integration in vielen Entwicklungsteams implementiert. Danach sind oft diverse manuelle Schritte notwendig, um anschließend die Qualitätssicherung durchführen zu können, welche die Codeänderungen mit manuellen und automatischen Tests auf unterschiedlichen Systemen und Umgebungen verifiziert. Continuous Delivery erweitert Continuous Integration um diese bisher zu wenig beachteten Aktivitäten. Neben diesen vorwiegend technischen Aspekten wird die notwendige Kommunikation zwischen Entwicklungsabteilungen und IT-Administration bzw. Konfigurationsmanagement allzu oft vernachlässigt oder findet überhaupt nicht statt. Hierfür hat sich in den letzten Jahren unter dem Codenamen DevOps die gegenseitige Annäherung von Entwicklung und Betrieb etabliert, wodurch Continuous Delivery tatsächlich erst realisierbar wird. Der Artikel arbeitet die wesentlichen Bestandteile von Continuous Delivery heraus, die damit einhergehende, notwendige Kooperation zwischen Entwicklung und Betrieb und gibt einen Überblick über die zur Realisierung notwendigen Schritte. Der Fokus liegt hierbei auf der konzeptionellen Ebene, technische Beispiele erfolgen unter Verwendung des Microsoft Team Foundation Servers.

Artikel: Auf Herz und Kacheln geprüft (Seite 28)
Windows 8.1 Store-Apps halten mittlerweile auch schrittweise Einzug in den Bereich der Firmenanwendungen. Im Nichtfimenumfeld gibt es bereits Apps in den unterschiedliche Qualitätsstufen, von der Einmann-“Hackathon”-App bis zur professionellen Teamarbeit-App. Dieser Artikel zeigt wie Windows-Apps mit Visual Studio 2013 getestet werden können…
von Nico Orschel und Marc Müller

Falls vorhanden, dann veraltet (Seite 88)
Wie wird aus dem friedlich im Regal verstaubenden Papierstapel der Dokumentation ein von allen Teammitgliedern wertgeschätztes Werkzeug? Der Schlüssel liegt in der Vereinfachung, der Reduktion auf das wirklich Notwendige.
Autor: Boris Wehrle

Artikel: Brückenschlag mit ALM
Testmanagement als Bindeglied zwischen Entwicklung und Qualitätssicherung
von Nico Orschel

Gegenwärtig kann man den Eindruck gewinnen, dass man mit einem nicht-agilen Vorgehen in der Softwareentwicklung nicht mehr wettbewerbsfähig arbeiten kann. Doch so schön sich die Welt der Product Backlogs, der ungestörten Sprints und selbstbestimmten Teams auch anhört, so gibt es in der praktischen Umsetzung doch erhebliche Unterschiede und Herausforderungen. Speziell in der Entwicklung von Produkten, bei denen Software lediglich eine Komponente darstellt, wie z. B. bei industriellen Maschinen, treffen hier Welten aufeinander. Produktlebenszyklen von 10 bis 20 oder mehr Jahren und lange Beschaffungszeiten stehen Sprints von wenigen Wochen gegenüber. Während das Produktmanagement auf hohem Abstraktionslevel plant, möchte die Softwareentwicklung auf Veränderungen reagieren können und sich erst sprintweise genau festlegen. Der Artikel zeigt, wie beide Welten zusammenspielen können. Außerdem wird dargestellt, wie man durch clevere Kombination die Vorteile von klassischem Produktmanagement und agiler Softwareentwicklung nutzen und sich dadurch einen Wettbewerbsvorteil verschaffen kann.

Als langjähriger Mitarbeiter sollen Sie Testautomatisierung in alten und neuen Softwareprojekten des Unternehmens einführen bzw. verbessern. Das Problem: Sie kennen das fachliche Umfeld, sind aber Einsteiger in der Testautomatisierung und möchten nichts falsch machen. Dieser Artikel dokumentiert den Verlauf…