Cloud ist nicht nur etwas für Entwickler und IT-Profis

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

Mehr Informationen

“Früher war alles besser” – eine Reise zu längst vergessenen Tagen

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

Mehr Informationen

DevOps und Continuous Delivery: sich gemeinsam kontinuierlich verbessern

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.

Mehr Informationen

Windows Developer 04/2014 Magazin – Artikel: “Auf Herz und Kacheln geprüft”

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

Mehr Informationen

Agilität in der Produktentwicklung: Wie agile Softwareentwicklung und klassisches Produktmanagement zusammenpassen

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.

Mehr Informationen