19. Juni 2018
Neco Giedrojc
0

Mocks in der Testumgebung Teil 2

Im ersten Teil wurden Grundlagen zum Mock und das Beispielprojekt vorgestellt. Im zweiten Teil bauen wir einen Mock auf, der unsere Rest-Service-Anwendung interaktiv testet.

Nun kommt es zu der Frage: „Warum sollte ich bei diesem Beispiel einen Mock verwenden?“ Es ist immerhin eine einfache, übersichtliche Anwendung. Wir müssen allerdings beachten, dass wir die Standardfunktionalität der API testen wollen. Wenn wir einen GET- oder POST-Befehl durchführen, wird innerhalb des Rest-Services der komplette Weg zur Datenbank genommen, um auf die Daten, die bereits gespeichert sind, zuzugreifen. An diesem Punkt kommt der Mock ins Spiel. Es wird der Zugriff auf die Datenbank, mit Hilfe des Mocks simuliert. Somit kann sichergestellt werden, dass, falls ein Fehler gefunden wird, dieser nichts mit dem Zugriff auf die Datenbank zu tun hat, sondern mit dem Bereich in dem wir den Test durchgeführt haben. Das wäre ein Beispiel für das Anwendungsgebiet. Ein weiteres wäre der Zugriff von außen auf die API. Im Normalfall würde eine solche API ein Frontend zur Eingabe der Informationen besitzen. Da wir allerdings die Pfade kennen, in die die Daten eingespeist werden, können wir ein API-Tool verwenden, welches das Frontend simuliert und spezifische Daten an die API schickt.
Ich werde in diesem Teil auf das Mock-Framework „Moq“ eingehen und das API-Test-Tool „Postman“.

Moq ist ein kleines und einfaches Mock-Framework für .Net oder C#. Es gibt mehrere Framework (NSubstitute, Rhino Mocks, etc …) doch diese sind meist recht kompliziert zu verwenden. Moq sticht in dem Sinne heraus, dass es eine einfache Syntax verwendet und für die meisten Anwendungsgebiete vollkommend ausreichend ist. Das Moq-Framework-Package kann über Visual Studio einfach mit dem Nuget-Tool heruntergeladen und direkt in dem Quellcode eingebunden werden.

using System.Net.Http;
using Moq;
using NUnit.Framework;

Hier ist der einfache Aufbau eines Unit-Tests. Wir erstellen eine neue Heldenliste, welche ihre Daten aus der Datenbank bekommt. Mit diesen Informationen können wir den Service erstellen, der von der API abgerufen wird. Wir rufen den vierten Helden auf, den wir eingespeichert haben. In diesem Fall wäre es „Maria“.

[Test]
  public void TestMethodwithoutMoq()
{
     //Arrange (Create)
   Heldenliste liste = new Heldenliste();
   var heldAPI = new HeldenService(liste);
   string shouldBe = „Maria“;
   //Act (Test)
   var ergebnis = heldAPI.GetHeroName(4);
   //Assert (Verify)
   Assert.That(ergebnis,Is.EqualTo(shouldBe),“Is Not as Aspected“);
   }
[Route(„api/Helden/{number}“)]
[HttpGet]
public string GetHeroName(int number)
{
   Held hero = heldenAPI.GetHero(number)
   Return hero.name;
}

Jetzt nehmen wir den bereits vorhandenen Aufbau und ersetzen die Heldenliste mit einem Mock. Somit verwenden wir nicht mehr die Daten, die in der Datenbank gespeichert sind und haben die Anwendung erstmal von der Datenbank getrennt. Mit diesem Aufbau ist garantiert, dass keine Fehler von der Datenbankverbindung den Test behindern.

[Test]
public void TestMethodwithMoq()
{
    Helden mockHero = new Helden()
{
    Name = „Detlef“,
    Klasse = „Zauberer“,
    Alter = 40,
    Level = 14
};
//Arrange (Create)
var moqHeldenliste = new Mock();
moqHeldenliste.Setup(x => x.GetHero(It.IsAny()))
    .Returns(() => mockHero);

var heldenapi_mock = new HeldenAPI(moqHeldenliste.Object);
var shouldBe = „Detlef“;
//Act (Test)
var ergebnis = heldenapi_mock.GetHeroName(It.IsAny());
//Assert (Verify)
Assert.That(ergebnis, Is.EqualTo(shouldBe), „Is Not as Aspectet“);
}

Wenn das Moq-Framework integriert ist, kann man die Klasse „Mock“ verwenden. Bei der Verwendung der Klasse gibt man an, welche Klasse simuliert werden soll. Der nächste Schritt ist es dann, den Mock mit der Setup()-Funktion zu konfigurieren. Wir geben an, dass egal, nach welchem Helden gefragt wird (It.IsAny), immer der mockHero (Detlef) ausgegeben wird. Würden wir den Mock nicht konfigurieren, würde er bei dem Aufruf der GetHeroName()-Funktion einen Default-Wert als Integer nehmen. Bei diesem handelt es sich meist um „0“. Da allerdings keine Daten aus der Datenbank geholt werden, würde er einen Fehler zurückgeben.
Das Moq-Framework lässt sich gut nutzen, um die Funktionalitäten, die die API innerhalb ihrer Anwendung aufruft, zu testen. Bei dem direkten Aufruf der API kommt sie allerdings an ihre Grenzen. Hier kommt das API-Tool „Postman“ ins Spiel.
„Postman“ kann man als separate Anwendung installieren oder als Chrome-Plugin verwenden. Er ist ausgerüstet mit den meisten REST-Befehlen (GET, POST, PUT, etc…) und weist eine leicht bedienbare Oberfläche auf. Es ist möglich, Testfälle zu schreiben, die während der REST-Befehle ablaufen und mit den gesendeten oder empfangenen Daten arbeiten. Somit bauen wir mit ihm einen Mock, der das Frontend simuliert.

Es können „Collections“ erstellt werden, in denen man die REST-Befehle, die wir im letzten Teil verwendet haben, gespeichert werden können. Mit dem POST-Befehl haben wir die Heldin Maria über die API gespeichert. Jetzt wurde noch ein Testfall hinzugefügt, welcher den Antworttext überprüft, den wir von der API zurückbekommen haben. In einem positiven Fall wird zurückgemeldet, dass der gewünschte Held hinzugefügt wurde. In einem Negativ-Fall würden wir eine andere Meldung bekommen und der Testfall würde Failed zurückgeben.

Unserer „Collection“ fügen wir auch die Abfrage nach dem letzten zugefügten Helden hinzu. Es können noch viele weitere Abfragen mit eigenen Testfällen der „Collection“ hinzugefügt werden, doch für unser Beispiel reichen diese beiden. Nun ist es möglich, die komplette „Collection“ zu starten. Der „Postman“ wird darauf hin nacheinander alle REST-Befehle aufrufen und ihre dazu gespeicherten Testfälle durchgehen. Somit bekommen wir am Ende solch ein Ergebnis:

Damit konnten wir nachweisen, dass der Zugriff von außerhalb auf die API funktioniert. Mit diesen Beispielen sehen wir, dass mit dem Moq-Framework die Anwendung hinter der API einfach getestet werden kann. Der „Postman“ hingegen vereinfacht, das Testen der API von Seiten des Internets.

Im nächsten Teil werden wir uns weiterhin mit diesem Thema befassen. Dabei werden wir in Docker eine kleine Testumgebung aufbauen, in dem der Rest-Service mit der Datenbank aufgebaut wird, und eine selbstgeschriebene Mock-Anwendung wird kontinuierlich versuchen auf die Rest-API zu zugreifen. Diese Variante könnte man im späteren Verlauf auch als Lasttest verwenden.

Das was „Mocks in der Testumgebung Teil 2“ – folgt hier vielleicht noch Teil 3?!?
7. Juni 2018
Eva Brumme
0

Design-Prinzipien reloaded: 13 wichtige Usability-Prinzipien

Vor längerer Zeit habe ich in einem Blogartikel unsere Design Prinzipien vorgestellt, nach welchen wir bei der Saxonia Systems AG nutzerfreundliche Software konzipieren und entwickeln. Im Rahmen der Entstehung unseres Custom Usability Index, mit dem der Erreichungsgrad der Usability eines Softwareprojekts gemessen werden kann, haben wir im Usability-Team diese Prinzipien noch einmal genau unter die Lupe genommen und auf 13 Oberkategorien erweitert, welche jeweils mehrere Usability-Aspekte umfassen. In diesem Artikel werden diese Kategorien und Aspekte genauer erläutert und durch Beispiele veranschaulicht.

Effektivität: Das Ziel erreichen. (Prinzip 1)

Die erste und somit wichtigste Regel ist die Einhaltung von Effektivität. Eine Anwendung soll dem Nutzer eine effektive Arbeitsweise ermöglichen, indem eine geeignete Funktionalität zur Erledigung seiner Aufgabe zur Verfügung gestellt wird. Der Nutzer wird nicht mit Informationen und Funktionen belastet, die für seinen Anwendungsfall unnötig sind. Entsprechend sollten Dialoge nur relevante oder häufiger benötigte Informationen enthalten. Jede zusätzliche Information lenkt den Nutzer von den wichtigen Inhalten ab, und es besteht die Gefahr einer Reduktion der relativen Sichtbarkeit.

Es gilt daher die zentrale Frage zu beantworten: Was ist wirklich die Aufgabe, die unterstützt werden soll? Eine gründliche Analyse der Arbeitsabläufe und deren Verständnis ist der Schlüssel, um die Aufgaben und Ziele der Nutzer zu verstehen und die Effektivität ihrer Umsetzung beurteilen zu können.

Uhr Usebilitiy

Wie viel Information ist notwendig, um die Uhrzeit anzuzeigen?

Effizienz: Schnell zum Ziel kommen. (Prinzip 2)

Ebenfalls besondere Beachtung verdient die Optimierung von Effizienz. Dem Nutzer soll es ermöglicht werden, eine Aufgabe in minimaler Zeit zu erledigen. Zugleich benötigt die Anwendung nur minimale Zeit zur Reaktion und zur Ausführung einer Aktion. Dieses Prinzip bezieht sich also auf die Arbeitsgeschwindigkeit von Nutzer und System. Anhaltspunkte dafür, dass der Nutzer nicht effizient arbeiten kann, sind beispielsweise für ihren Zweck unpassend eingesetzte Interface-Widgets, fehlende Default-Werte, unzutreffende Suchergebnisse und hochauflösende Bilder, welche eine schnelle Internetverbindung voraussetzen.

Hinweise auf eine geringe System-Effizienz sind hingegen verzögerte Reaktionen auf Eingaben in Form von „ruckelnden“ Mauszeigern, langsamen Interface-Widgets und fehlendem Feedback.

Steuerbarkeit: Der Nutzer hat die Macht! (Prinzip 3)

Der Nutzer hat, unter Beachtung seiner Berechtigungen im System, die Kontrolle über alle Aktionen. Er kann Vorgänge abbrechen, pausieren und zu einem späteren Zeitpunkt fortsetzen. Er hat die Möglichkeit, eine Aktion rückgängig zu machen und ggf. einen neuen Anlauf zu starten, falls das Ergebnis nicht zufriedenstellend war. Für die Steuerung der Anwendung hat der Nutzer weiterhin die Möglichkeit, entsprechend seinen persönlichen Anforderungen zur Maus alternative Eingabegeräte wie Tastatur, Screenreader und Braillezeile zu nutzen.
Werden diese Punkte nicht eingehalten, führt das zu einer gesteigerten Frustration des Nutzers.

Individualisierbarkeit: Alles passt zum Nutzer. (Prinzip 4)

Die Anwendung soll flexibel genug sein, um verschiedene Herangehensweisen zur Erledigung einer Aufgabe zu unterstützen. Der Nutzer kann das System zudem an seine Vorerfahrungen, Kultur und Bedürfnisse anpassen, z.B. durch Änderung der Schriftgröße, Änderung von Default-Einstellungen und die Festlegung eigener Shortcuts. Ein gutes Beispiel für die Berücksichtigung von Individualisierbarkeit ist das Online-Portal http://www.elster.de/, über das man Steuererklärungen webbasiert erfassen und abgeben kann. Nach dem Login wird der Nutzer gefragt, welcher Benutzergruppe er angehört, um die Anwendung anschließend auf dessen Bedürfnisse anzupassen:

Elster

Individualisierbarkeit bei ELSTER Online.

Konsistenz: Alles passt zusammen. (Prinzip 5)

Die Bedienung der Anwendung soll in jedem Aspekt den Erwartungen des Nutzers entsprechen und allgemeine Konventionen (Plattformen, Styleguides etc.) befolgen. Einen Beitrag dazu leistet die einheitliche Verwendung von Begriffen, Icons und Layouts innerhalb der Anwendung und zwischen Produkt-Familien. Auch Prozessstrukturen folgen einem einheitlichen Prinzip. Durch die Einhaltung von Konsistenz kann vom Nutzer ein einmal erlerntes Verhaltensmuster wiederverwendet werden. Zum Beispiel weiß (und erwartet) der Nutzer im Verlauf der Benutzung der Anwendung(en), dass sich der Button zum Schließen eines Dialogfensters immer oben rechts in der Ecke befindet. Wechselt er jedoch auf das Betriebssystem Mac OS X, muss er sich gänzlich neu eingewöhnen. Anhaltspunkte dafür, dass sich eine Anwendung nicht erwartungskonform und konsistent verhält, sind überraschte bis verwirrte Nutzer und z.B. die Verwendung verschiedener Begriffe für ein und dieselbe Funktion.

Design und Layout: Auf den ersten Blick verständlich. (Prinzip 6)

Dieses Prinzip umfasst alle Aspekte der visuellen Gestaltung einer Anwendung. Demnach sollen die Art der Gruppierung und Anordnung der GUI-Elemente sowie der bewusste Einsatz von Farbe den Nutzer bei der Erkennung von Zusammenhängen unterstützen. Informationen und Komponenten werden dem Nutzer generell so präsentiert, dass er sie wahrnehmen und Textinhalte gut lesen kann. Gegenanzeigen hierfür sind z.B. unklare Zuordnungen von Labels zu Datenfeldern, winzige Schriftarten und ein schwacher Farbkontrast zwischen Vorder- und Hintergrund.

Sprache: Die Sprache des Nutzers sprechen. (Prinzip 7)

Die Anwendung sollte grundsätzlich die Sprache des Nutzers widerspiegeln und dessen Denkweise entsprechen. Textelemente sollten daher eindeutig formuliert sein und einen für die Zielgruppe verständlichen Wortschatz gebrauchen. Dennoch werden Dinge oft systemtechnisch formuliert statt in der Sprache der Anwender. „Bestes“ Beispiel dafür sind Fehlermeldungen mit einem Detailgrad, in dem sie zwar für den Systementwickler von Wert sind, dem Nutzer aber nicht weiterhelfen. Um dies zu vermeiden, sollte der fachliche Sprachschatz der Endnutzer genau analysiert werden.

Sichtbarkeit: Der Nutzer erkennt seine Möglichkeiten. (Prinzip 8)

Damit der Nutzer seine Aufgabe erledigen kann und nicht die Orientierung verliert, muss er jederzeit wissen, wo in der Anwendung er sich befindet und welche Aktionen wie ausgeführt werden können. Auch weiß er jederzeit, in welchem Status sich das System gerade befindet. Das Hauptmenü sollte dem Nutzer daher dessen aktuelle Position anzeigen und bspw. über eine Breadcrumb-Navigation den Weg dorthin nachvollziehbar machen. Relevante Objekte, Funktionen und Optionen sollten sichtbar sein und den Nutzer das Gesuchte direkt finden lassen. Er soll beurteilen können, welche Folgen eine Aktion haben wird.

Feedback: Der Nutzer erfährt, was los ist. (Prinzip 9)

Das System sollte jederzeit auf Eingaben des Nutzers reagieren und ihn aktiv über Ereignisse informieren. Bei einem aufgetretenen Fehler sollte eine entsprechende Meldung dem Nutzer die Ursache des Fehlers aufzeigen und ihm, sofern möglich, einen Lösungsvorschlag unterbreiten. Weist die Anwendung in Sachen Feedback Defizite auf, ist dies beispielsweise bei einer komplexeren Operation an einem fehlenden Spinner-Icon ersichtlich und Nutzer-Eingaben werden gefühlt vom System ignoriert. Der Nutzer nimmt wahr, dass die Anwendung „hängt“.

Lernförderlichkeit: Leicht zu lernen. (Prinzip 10)

Das System sollte den Nutzer beim Kennenlernen der Benutzungsoberfläche unterstützen und ihn zum Ausprobieren von ihm unbekannten Funktionen ermutigen, ohne dass dies negative Auswirkungen für den Nutzer mit sich bringt. Vor allem in der ersten Phase der Benutzung sollte der Nutzer bei komplizierten Aktionen unterstützt und so mögliche Fehlschritte eingeschränkt werden. Hier helfen kurze Tutorials und beschreibende Texte. Eine Möglichkeit zum experimentellen Lernen bietet weiterhin ein Probemodus, d.h. ein gesonderter Testbereich in der Anwendung, in dem alle Funktionen ohne Konsequenzen ausprobiert werden können. Durch den Probemodus wird der Nutzer am System geschult und lernt den Umgang mit dem System, ohne einen Prozess vollständig durchführen zu müssen.

Hilfe und Dokumentation: Hilfe die hilft. (Prinzip 11)

Hilfesysteme sollen leicht auffindbar bzw. möglichst in die Interaktion eingebettet sein. Zu eingebetteten Hilfen zählen Tooltipps, Platzhalter, kurze Hilfetexte und Assistenten. Ist dies nicht hinreichend, sollte die Wahl auf kontextuelle Hilfen wie einem Hilfe-Panel, Einstiegsseiten und Suchfunktion fallen. Zu beachten ist, dass die Hilfesysteme dem Nutzer nur dann eine Unterstützung sind, wenn sie sich auf die Aufgabe des Nutzers beziehen und konkret auszuführende Schritte zur Lösung des Problems auflisten.

Fehlertoleranz: Nutzerfehler verzeihen und vermeiden. (Prinzip 12)

Das System sollte von vornherein so gestaltet sein, dass der Nutzer aktiv vor Fehlern bewahrt wird, beispielsweise indem unzulässige Funktionen deaktiviert werden und die Einschränkung zusätzlich begründet wird. Passiert es doch einmal, sollten fehlerhafte Eingaben oder Aktionen vom System erkannt werden. Im Falle von Eindeutigkeit behebt das System den Fehler dann, wenn möglich, selbstständig. Gibt es mehrere Möglichkeiten, werden alternative Korrekturvorschläge aufgezeigt. Niemals hingegen darf der Fehler zum Datenverlust oder gar Systemabsturz führen.

Nutzungsgefühl (UX): Die Software fühlt sich gut an. (Prinzip 13)

Ein Aspekt, den wir bisher nicht berücksichtigt haben, ist die User Experience (abgekürzt UX). Das sogenannte Nutzungsgefühl resultiert aus dem Gesamterlebnis des Nutzers mit der Anwendung und setzt sich zusammen aus der tatsächlichen Nutzung, der Erwartung des Nutzers und der Vorerfahrung mit anderen Systemen. Die Anwendung vermittelt dem Nutzer ein Gefühl von Sicherheit und Zuverlässigkeit, macht Spaß und ist zweckdienlich. Das System begeistert den Nutzer, indem bestimmte Erwartungen nicht nur befriedigt, sondern auch übertroffen werden. Prinzip 13 wird also zum Großteil dadurch erfüllt, dass die zuvor genannten Prinzipien eingehalten werden. Eine langsame, inkonsistente Anwendung mit vielen Fehlermeldungen und Abstürzen wird hingegen nicht zur Zufriedenheit des Nutzers beitragen. Entsprechend sollte sich die Software immer auf dem aktuellen Stand der Technik befinden und aktuelle Steuerparadigmen unterstützen.

Abschluss

In diesem Blogbeitrag wurden 13 wichtige Prinzipien zur Erreichung einer nutzerfreundlichen, zufriedenstellenden Software vorgestellt. Zu beachten ist dabei, dass es keine einzig wahre, benutzungsfreundliche Lösung gibt. Wie gut eine Anwendung bedienbar ist, hängt immer von dem konkreten Anwendungsfall und der Nutzergruppe ab. Es ist daher zu empfehlen, die Bedürfnisse der Nutzer genau zu analysieren und sie durch Nutzertests einzubeziehen.

Weiterführende Literatur

  • J. Nielsen‘s 10 Usability Heuristiken (Web)
  • B. Shneiderman: 8 Golden Rules of Interface Design, In: „Designing the User Interface: Strategies for Effective Human-Computer Interaction“ (Web)
  • DIN-Norm EN ISO 9241-110: Grundsätze der Dialoggestaltung (Web)
  • B. Tognazzini, Principles of Interaction Design (Web)
  • J. Johnson, GUI Bloopers 2.0: Common User Interface Design Don‘ts and DOs, 2007
  • D. Norman, The Design of Everyday Things: Revised and Expanded Edition, 2013
  • Web Content Accessibility Guidelines 2.0 (Web)
5. Juni 2018
Neco Giedrojc
0

Mocks in der Testumgebung Teil 1

Die Komplexität und Interaktion der Softwareanwendungen, die in Unternehmen eingesetzt werden, ist in den letzten Jahren stark gestiegen. Werden heute Releases ausgerollt, steht ein Teil der neuen Funktionen immer im Zusammenhang mit dem Datenaustausch zu anderen Anwendungen. Das merken wir auch im Bereich Softwaretest: Der Fokus der Tests hat sich von reinem Systemtest auf den Bereich der Integrationstests erweitert. Darum kommen auch Mocks zum Einsatz.

Wir arbeiten in einem Testcenter und führen für unsere Kunden den übergreifenden Integrationstest über seine komplexe Anwendungsinfrastruktur durch. Daher bauen wir die Testumgebungen passend zur Produktivumgebung auf. Also wozu brauchen wir dann Mocks, wenn die Integrationstestumgebung bereits alle Software-Komponenten besitzt?
Zum Teil liegt man mit dieser Denkweise schon richtig, allerdings werden auf den unterschiedlichen Staging-Ebenen beim Test verschiedene Fokusse gesetzt. Mocks werden im Systemtest eher weniger verwendet, da in diesem Bereich die Funktionen der Software getestet werden. Dafür werden Mocks häufiger in Integrationstests verwendet. Da es aber nicht immer möglich ist, den kompletten Nachrichtenfluss zu testen, wird als Alternative die Kommunikation an der Schnittstelle geprüft.

Werden im Integrationstest drei Komponenten getestet, die im Nachrichtenfluss direkt hintereinanderliegen, kann bei Verwendung aller drei Softwarekomponenten nicht hundertprozentig sichergestellt werden, dass die Prozedur ohne Probleme läuft. Es könnte sein, dass die jeweiligen Fehler der Komponenten den Nachrichtenfluss verfälschen und im Nachhinein wieder richtiggestellt werden, der Fehler quasi maskiert wird. Daher stellen wir Mocks an die jeweiligen Enden der Komponenten, um gezielte Ein- und Ausgaben zu bekommen.

Um die beschriebenen Probleme und Eigenheiten eines Mocks zu erklären, nutzen wir als zu testende Anwendung einen Rest-Services. Der Rest-Service sollte in der Lage sein, ein GET- und ein POST-Befehl durchzuführen. Würde unsere Komponente nun nach personenspezifischen Daten beim Mock nachfragen mit einem GET-Befehl, könnten wir unseren Mock so konfigurieren, dass er standardisierte Antworten zurück gibt oder bei POST-Befehlen einfache Berechnungen durchführt.

Mit Microsoft Visual Studio kam man in C# schnell ein WebAPI-Projekt erstellen, welches die grundlegende Funktion eines Rest-Services besitzt. Die Methoden des Controllers müssen nur noch angepasst werden und man hat eine funktionierende Rest-API zur Verfügung.

Datei > Neu > Projekt > Visual C# > Web > Webanwendung

Wenn man sich die Controller der WebAPI anschaut, kann man sehen, dass bestimmte URLs, Funktionen innerhalb der API aufrufen. In diesem Beispiel wird eine kleine WebAPI verwendet, die als Helden-Datenbank genutzt wird.

Mocks in der Testumgebung Teil 1 heldenliste

Die Route beschreibt den URL-Pfad um die HttpGet(GET-Befehl)- oder HttpPost(POST-Befehl)-Funktion aufzurufen.

Beispiel: http:localhost/api/helden/add

Sobald man die Rest-API zum Laufen gebracht hat, ist es mit einem API-Tool(Postman) oder einem Browser möglich, unterschiedliche Rest-Befehle an die URL zu schicken. Wenn nun ein POST-Befehl an die Rest-API geschickt wird, nimmt der Service diesen an und erkennt anhand der URL, dass die Funktion AddHeldenDetails() aufgerufen werden soll. Die Funktion nimmt die mitgeschickten Daten auf und fügt sie ihrer Datenbank hinzu. Als Antwort liefert sie den Return-Wert der Funktion. In diesem Fall die Bestätigung über das Hinzufügen des gewünschten Helden.

POST-Befehl:

POST /api/Helden/zwei HTTP/1.1
Host: localhost:53521
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
Postman-Token: b169b96f-682d-165d-640f-dbcafe52789e
{ „Name“:“Maria“,“Klasse“: „Lord“,“Alter“:68,“Level“:57 }

Antwort:

Der Held mit dem Namen: Maria wurde hinzugefügt

 

Wir haben nun mit unserem POST-Befehl die Heldin Maria der Datenbank hinzugefügt. Nun können mit dem GET-Befehl die gespeicherten Helden abrufen werden. Hier ein Beispiel zum Format des GET-Befehls, welcher an die Rest-API geschickt wird mit der dazugehörigen Antwort der API:

Abfrage:

GET /api/helden/get HTTP/1.1
Host: localhost:53521
Content-Type: application/json
Cache-Control: no-cache
Postman-Token: b3f19b01-11cf-85f1-100f-2cf175a990d9

 

Antwort:

 

Mocks in der Testumgebung Teil 1

In der Antwort ist zu sehen, dass die Heldin Maria der Liste hinzugefügt wurde und nun jederzeit abgerufen werden kann.

Nun wissen wir um die Funktionsweise den Rest-Services Bescheid, d.h. welcher Input zu welchem Output führt. Mit dieser Information können wir uns dann an den Bau eines Mocks begeben. Mit diesem Thema werde ich mich im nächsten Teil genauer befassen.

Das war „Mocks in der Testumgebung Teil 1“ … Teil 2 folgt 🙂
9. Oktober 2017
Kay Grebenstein
0

Mauern einreißen – Wie die Digitalisierung den Fachbereichstest ändert

Digitalisierung und Industrie 4.0 stellen neue Anforderungen an Prozesse und Softwaresysteme in allen Unternehmens- und Geschäftsbereichen. Firmen, die ihre Software extern entwickeln oder einkaufen, haben eine zusätzliche Herausforderung. Die verschiedenen Systeme unterschiedlicher Hersteller müssen für die vernetzte Arbeit im Geschäftsprozess der Unternehmen noch stärker untereinander Daten austauschen. Trotz der Tests der internen und externen Entwicklungsteams, die in verschiedenen entwicklungsnahen Teststufen die Software, bevor Sie an den Kunden übergeben wird, validieren und der anschließenden Abnahme durch die Fachbereichstests, treten beim Zusammenspiel der einzelnen Komponenten Fehler auf. Als Lösung bietet sich hier ein Testcenter mit dem Fokus auf übergreifende Integrationstests an, das aber für seinen Erfolg besondere Anforderungen erfüllen muss.

mehr

6. April 2017
Niels Brestrich
0

Protractor – Automatisiert Testen mit Angular

Kritische Fehler, die erst im Rahmen des Live-Betriebes öffentlich werden, stellen ein großes finanzielles Risiko und nicht zuletzt eine negative Werbung für ein Produkt und die beteiligten Unternehmen dar. Deshalb ist das Thema Test in der modernen Softwareentwicklung ein grundlegender und integraler Bestandteil. Durch eine hohe Testabdeckung und der zeitnahen Rückmeldung der Testergebnisse lässt sich die Qualität und Reife des Produktes ausreichend genau nachweisen und bestätigen.

mehr

3. April 2017
Sylvie Löffler
0

Traditionelles Handwerk trifft auf innovatives Software-Entwicklungshaus

Ergebnis: Prämierung auf der Spezialmesse für Werbemittel

Um bei Kunden und Partnern präsent zu sein, gibt es viele Möglichkeiten. Dazu starten wir immer wieder Kampagnen, die stets zeigen sollen, dass wir mit Geschwindigkeit nach Innovation und Qualität streben. Wir haben nun einen traditionellen Räuchermann innoviert und einen Räucherrechner für eine Bestandskundenkampagne zum Nikolaus 2016 kreiert. Diesen haben wir von der KWO Kunstgewerbe-Werkstätten Olbernhau produzieren lassen und wurden jetzt für unser sächsisches Gemeinschaftsprojekt mit dem Promotional Gift auf der „HAPTICA“ ausgezeichnet.

Hintergrund & Ziel unserer Bestandskundenkampagnen

Wir versenden mehrfach im Jahr an unsere Kunden und Partner Grüße zu den unterschiedlichsten Anlässen. Für jeden Gruß ist der Anspruch sehr hoch:

  • Wir wollen überraschen und im Gedächtnis bleiben.
  • Wir wollen mit außergewöhnlichen, kreativen Ansprachen und Give-Aways auf unser Kerngeschäft die Individualsoftwareentwicklung hinweisen.
  • Wir wollen Give-Aways, die nachhaltig sind und beim Empfänger Nutzen stiften.

Seit Sommer 2016 haben wir mit sogehtsoftware.de eine neue Webseite, die uns auch neue fokussierte Marktansprachen erlaubt. Mit unseren Grüßen wollen wir auf diese aufmerksam machen und leiten die Empfänger bei Interesse zu unserer Überraschung – In diesem Fall der Räucherrechner.

Entstehung der Nikolausgrußkampagne

Im Rahmen unseres agilen Vorgehens – auch im Marketing – haben wir in der Planung des Sprints die Nikolausgrüße hoch priorisiert und im ersten Kreativtermin Anfang September zusammentragen, was wir mit Nikolaus verbinden – Startschuss in und Vorfreude auf die Weihnachtszeit.

Die Weihnachtszeit ist geprägt durch viele Gerüche und kulinarische Genüsse, die unsere  Sinne ansprechen. Im Jahr 2014 hatten wir schon einmal großen Erfolg mit dem Ansprechen des Geschmackssinns. Wir haben eine eigene Glühweinmischung (von Georg Bauch eigens für unsere Weihnachtsgrüße kreiert) verschickt und es geschafft, unsere Kunden und Partner mit dem Geruch in eine vorweihnachtliche Stimmung zu versetzen. Wie können wir das wieder erreichen?

Als erstes entstand relativ schnell die Idee für das Grußkarten Give-Away.

Räucherkerzchen = Duft, Vorfreude, Startschuss in die Weihnachtszeit

skizze-saxonia-systems

Abbildung 1: Erste Skizze des Räucherservers

Was könnte noch passend zu den Räucherkerzen sein und auf unser Kerngeschäft verweisen? Nach umfangreichen Recherchen fanden wir einen Räuchermann, der vor dem Laptop sitzt und dessen Kopf qualmt. Dieser war jedoch nicht verfügbar. Ein Räucherhaus? Das passt nicht ganz. Schnell kamen wir dann zu einem Räucherserver (Abbildung 1), den es so noch nicht gibt. Wir waren einer Weltneuheit auf der Spur …

Auf Basis dieser Skizze entstand auch der Slogan für die Nikolausgrüße „Für Sie lassen wir unsere Rechner rauchen“ und so wurde auch aus dem Räucherserver ein Räucherrechner.

skizze-rechner-saxonia-systems

Abbildung 2: Skizze des Räucherrechners

Wer kann unsere Idee herstellen und produzieren? Ganz bewusst haben wir uns dann für das Erzgebirge und nicht China entschieden. Wir wollten etwas Traditionelles und vor allem hochwertige Qualität.

Eine entsprechende Skizze des Räucherrechners (Abbildung 2) diente anschließend als Basis für die Einholung von Angeboten zur Produktion.

Unsere Anfrage ging an mehrere Hersteller im Erzgebirge – nur KWO konnte unsere Anforderungen der individuellen Herstellung erfüllen. KWO produziert mit heimischen Hölzern aus nachhaltiger Forstwirtschaft, hat Erfahrung seit 1949 und Spezialistenwissen für Sonderanfertigungen im Werbeartikelbereich.

iteration-saxonia-systems

Abbildung 3: Entstehung in wenigen Iterationen

iteration-fertig-saxonia-systems

Abbildung 4: Der fertige Räucherrechner von KWO Olbernhau

In kürzester Zeit mit wenigen Iterationen hatten wir ein tolles Rauchobjekt in Rechnerform (Abbildung 3 und 4) und konnten unsere Nikolausgrußkarten (Abbildung 5) designen und in Druck geben.

grusskarte-saxonia-systems

Abbildung 5: Nikolausgrußkarte

Vor dem Versand hat jeder Kontaktinhaber persönliche und handschriftliche Grüße auf der Grußkarte verfasst. Zum Schluss der Konfektionierung kamen die Räucherkerzen auf die Grußkarten (Abbildung 6) und ab ging es mit 1500 Grüßen zur Post.

versandtasche-saxonia-systems

Abbildung 6: Nikolausgrußkarte Rückseite & Versandtasche

Unser Nikolauskonzept sah auch die Umsetzung auf der Webseite vor. Wir haben eigens eine Seite sogehtsoftware.de/nikolaus (Abbildung 7) entwickelt und diese URL auf den Grüßen mit angegeben. Alle Grußempfänger hatten somit die Möglichkeit, sich für einen der 100 einzigartigen Räucherrechner zu registrieren.

webseite-saxonia-systems

Abbildung 7: Umsetzung auf der Webseite – Registrierung für den Räucherrechner

Ergebnis

Die Feedbacks zur Grußkarte und dem Räucherrechner waren durchweg positiv und begeisternd. Wir haben sogar Fotos rauchender Rechner bekommen. Geschafft … mit unserem Räucherrechner und den dazu passenden Räucherkerzen haben wir unseren Kunden und Partnern die Vorweihnachtszeit verschönert.

Auf Initiative von KWO haben wir Anfang Dezember das Gesamtkonzept der Nikolauskampagne mit dem Räucherrechner eingereicht und am 14.12.2016 die Nachricht erhalten „ … herzlichen Glückwunsch zum Promotional Gift Award 2017! Die Jury war sich einig: Ihr Produkt: „Rechner als Rauchobjekt (Räucherrechner)“ ist herausragend und verdient es, mit einem Promotional Gift Award ausgezeichnet zu werden.“

Die Verleihung des Awards hat am 22.3. in Bonn (Abbildung 8) stattgefunden.

Ein preisgekröntes sächsisches Gemeinschaftsprojekt zwischen Saxonia Systems und KWO – So geht Zusammenarbeit!

preis-haptica-saxonia-systems

Abbildung 8: Am 22.3.2017 Verleihung des Promotional Gift Award

17. Februar 2017
Kay Grebenstein
0

Wie die Digitalisierung den Fachbereichstest ändert

Umfrage auf der OOP 2017

Ein wesentlicher Erfolgsbaustein eines jeden Dienstleistungsunternehmens ist es, die Zielgruppe Ihrer Services zu kennen. Nicht nur um seine Leistungen bestmöglich zu platzieren, sondern auch um den Kunden eine möglichst optimal auf sie zugeschnittene Lösung zu bieten. Schon seit Langem setzen wir als Saxonia Systems AG daher nicht nur auf eine möglichst enge und partnerschaftliche Zusammenarbeit mit unseren Kunden, sondern führen auf verschiedenen Konferenzen Umfragen durch. Ziel ist es dabei die Herausforderungen – mit denen Fachbereich und IT täglich zu kämpfen haben – besser kennen zu lernen.

mehr

4. April 2016
Jan Moßler
0

Kochrezepte für Testautomatisierung – (Teil2 – Datensalat)

Testomaten auf Datensalat an Stressing

DatensalatEine besondere Herausforderung für jede manuelle Testdurchführung und ganz besonders für die Testautomatisierung sind die Testdaten. Bei den meisten manuellen Tests stehen in den Testfällen meist nur grobe Hinweise zu den zu verwendenden Testdaten. Das Vorgehen funktioniert in der Testautomatisierung nicht.

mehr

25. Januar 2016
Kay Grebenstein
0

Testwerkzeuge für JavaFX

Testautomatisierungswerkzeuge sorgen für eine schnelle und kontinuierliche Rückmeldung über den Stand der Qualität der zu testenden Software. Aber bei ihrem Einsatz müssen verschiedene Punkte beachtet werden, z. B. die Eignung für neue Technologien wie JavaFX.

mehr

23. Dezember 2015
Jan Moßler
0

Kochrezepte für Testautomatisierung – (Teil1 – Suppe)

Zutaten, Küchengeräte und wer ist der Koch?

suppe1Ein Kollege sprach mich kürzlich an und fragte, ob ich ein Rezept für eine gute Testautomatisierung kenne. Ich sagte dass man dafür – wie für eine gute Suppe – nicht nur ein Rezept braucht, sondern es kommt auf die Ausstattung der Küche, die Zutaten und den Koch an. Entscheidend für die Testautomatisierung sind also die Projektrahmenbedingungen, die Auswahl der Testwerkzeuge und die Tester die an der Testautomatisierung beteiligt sind.

mehr