Nexthink Dashboards

Nexthink Dashboards

In einem Unternehmen sind Informationen auf allen Ebenen die Basis für strategische und operative Entscheidungen. Egal, ob der Vorstand die zukünftige Ausrichtung des internationalen Konzerns plant, der Bereichsleiter die Umsatzziele festlegt oder der Sachbearbeiter seine tägliche Arbeit plant. Die Ihnen zur Verfügung stehenden Daten bestimmen die Entscheidungen.

In unserer digitalisierten Arbeitswelt werden wir nun mit einer Flut von Daten konfrontiert. Aus dieser Flut gezielt und effizient die relevanten Indikatoren zu finden, die für unsere Aufgaben relevant und entscheidend sind ist oft nicht einfach aber von hoher Bedeutung.

Ein Werkzeug, das uns bei der Bewältigung der Datenflut helfen kann, ist das „Dashboard“.

Was ist ein Dashboard

Der Begriff Dashboard kommt vom englischen Begriff für das Armaturenbrett im Auto. Das Armaturenbrett liefert dem Fahrer alle für den Betrieb des Fahrzeugs notwendigen Informationen in einer bedarfsgerechten, intuitiven Darstellung.

Diese grundlegende Definition lässt sich auch auf andere Gebiete übertragen. „Armaturenbretter“ oder eben Dashboards finden sich deshalb sehr häufig in unserem Umfeld. Sowohl im privaten als auch im beruflichen.

In der IT verwenden es zum Beispiel die Administratoren, um auf einen Blick die wichtigen Parameter der Infrastruktur zu erfassen und Probleme schnell zu erkennen. So lassen sich z.B. auf einem Dashboard rasch die Verfügbarkeit der wichtigsten Web-Applikationen und der Zustand der Microsoft 365 Anbindung erfassen. Ein anderes Dashboard zeigt dem zuständigen Projektleiter den Zustand der Microsoft 365 Einführung und den Adaptionsgrad der neuen browserbasierten Office-Applikationen. Der Abteilungsleiter der Entwicklung bekommt über sein Abteilungs-Dashboard eine Übersicht der genutzten Visual-Studio-Lizenzen gegenüber den angeschafften Lizenzen und den damit verbundenen Kosten.

Dashboarddesign

Ein Dashboard soll dem Anwender Zeit ersparen und ihn in seiner Arbeit unterstützen. Damit das erreicht werden kann, müssen die Dashboards vor allem eines sein: Intuitiv und relevant.

Um das zu erreichen, sollten ein paar „Best Practices“ beim Design von Dashboards beachtet werden:

  • Klären Sie, was der Anwender vom Dashboard erwartet!
    Es ist wichtig, die Zielgruppe genau zu kennen. Sind die Anwender-Personas bekannt, lässt sich die Antwort auf die Frage nach den Erwartungen leichter beantworten.
    Bestimmen Sie die drei bis fünf wichtigsten Informationen, damit alles auf eine Seite passt. Für ein optimales Layout des Dashboards können dann die aus dem Webdesign bekannten Betrachtungsmuster (etwa Z- oder F- Muster) einbezogen werden.
  • Ein gutes Dashboard nutzt Schlüssel-Informationen, um den Anwender zu leiten!
    Dashboards, die das wesentliche mit deutlichen, klaren Zahlen darstellen, vermitteln Vertrauen und Entschlossenheit. Auf diese Weise erkennt der Anwender unmittelbar, was von Relevanz ist.
  • Strukturieren Sie das Informationsangebot!
    Beachten Sie beim Design des Dashboards die Prinzipien der Informationsarchitektur. Mit einer guten Informationsarchitektur kann das Dashboard den Bedürfnissen des Anwenders als auch des Betreibers gerecht werden. Sie hilft das Angebot für die Zielgruppe intuitiv und übersichtlich zu gestalten, berücksichtigt aber auch technische Einschränkungen.
  • Bieten Sie verschiedene Sichten auf die Daten an!
    Erlauben Sie es dem Anwender die Daten zu filtern. Ein Filter auf ein Gebiet oder einen Zeitraum hilft dabei dem Anwender relevante Daten zu präsentieren, ohne das Dashboard unnötig aufzublähen.
  • Verwenden Sie eine konsistente Designsprache!
    Auch wenn trockene Zahlen und Fakten angezeigt werden, kann ein Dashboard optisch ansprechend gestaltet werden. Wichtig ist dabei ein klarer und konsistenter Einsatz von Farben und Schriften, die dem Anwender helfen, sich schnell zurecht zu finden.

Dashboards im Nexthink Portal

Das Nexthink Portal bietet bereits zu vielen Themengebieten Dashboards an, die den genannten „Best Practices“ folgen. Nutzen Sie die Nexthink Library. Für viele Anwendungsfälle finden Sie hier fertige, professionelle Lösungen.

Sollten Sie in der Library nicht fündig werden, da Sie speziellen Anforderungen Ihrer Fachbereiche gerecht werden müssen, stellt das Portal Ihnen aber auch eine Reihe von Werkzeugen zur Verfügung, um diese Anforderungen zu realisieren. Die Einrichtung von Dashboards in Nexthink ist durch die webbasierte Oberfläche sehr einfach und intuitiv zu bewältigen.

Arten von Dashboards

Dashboards werden durch Nexthink in Module gruppiert. Das Modul bestimmt dabei, welche Arten von Dashboards erstellt werden können.

  • Basic Modul
    Dieses Modul erlaubt Metrik-basierte, sehr flexibel anpassbare Dashboards. Sie können verschiedene Metriken auf dem Dashboard darstellen und unterschiedliche Visualisierungen (Widgets) für eine Metrik verwenden.
  • Service Modul
    Das Service Modul erlaubt Dashboards, die auf Services basieren. Jedes Dashboard repräsentiert dabei einen Service. Es ist nicht so flexibel anpassbar wie ein Metrik-basiertes Dashboard. Durch ein vordefiniertes Set an Visualisierungen (Widgets) ist es aber einfacher zu erstellen.
  • Software Metering Module
    Sie benötigen eine Übersicht Ihrer Softwarelizenzen? Dann nutzen Sie das Dashboard in diesem Modul. Die Dashboards bieten Informationen über Installationen, Nutzung und Anzahl von Lizenzen zu den Applikationen an.

Die Werkzeuge

Zur Darstellung der Informationen auf dem Dashboard bietet das Portal eine Reihe von Widgets[1] an.

  • Key Performance Indicator (KPI)
  • Tabelle
  • Liniendiagramm (Line Chart)
  • Balkendiagramm (Bar Chart)

Storytelling mit Daten

Gute Dashboards helfen Zeit und Geld zu sparen. Sie schaffen Transparenz und ermöglichen fundierte Entscheidungen. Gute Dashboards erzählen eine Geschichte und präsentieren trockene Daten und Fakten in einer ansprechenden und aussagefähigen Form.

Fazit

Ein Dashboard innerhalb von Nexthink zu erstellen, ist keine Kunst. Die Kunst, ein erfolgreiches Dashboard-Projekt durchzuführen, liegt in der Planung und Konzeption der Dashboards und der Gestaltung der Informationsarchitektur. Es benötigt Erfahrung, Daten für unterschiedliche Stakeholder aufzubereiten, zu strukturieren und ergonomisch darzustellen.

Sparen Sie sich Geld und Zeit, diese Erfahrung durch „Trial & Error“ zu erlangen. Lassen Sie sich von unseren Experten beraten. Kontaktieren Sie uns!

[1] https://docs.nexthink.com/Experience/2021.4/Types-of-widgets.699466325.html

/von

Initiative Digitaler Reifegrad

,

Sind Sie fit für die Digitalisierung ?

Reifegradanalyse mit der Hochschule Hof

Corona hat die Defizite im Bereich Digitalisierung – wie mit einem Brennglas – deutlich gemacht und den Handlungsdruck deutlich gesteigert. Dies gilt besonders für den öffentlichen Bereich, aber auch für die meisten privatwirtschaftlichen Unternehmen. Soweit so bekannt.

Häufig fehlt aber noch der methodische Ansatz für eine ehrliche und breit angelegte Bestandsaufnahmen im Unternehmen oder der Behörde. Diese wäre aber notwendig, um darauf aufsetzend die richtigen Prioritäten zu setzen und eine konkrete Roadmap zu erarbeiten.

„Ein weiterer wesentlicher Punkt ist“, so Prof. Dr. Heike Markus, „dass die fachliche Auseinandersetzung mit der Digitalisierung vor dem Einsatz der Technologie kommen muss.

Frau Prof. Dr. Heike Markus, Hochschule Hof

Wir haben dazu, gemeinsam mit der Hochschule Hof und ServiceNow ein Reifegradmodell erarbeitet, das eine schnelle und strukturierte Analyse unterstützt. Das Modell berücksichtigt 7 Dimensionen (Strategie, Führung, Prozesse, Technologie, Mitarbeiter, Daten und Steuerung.) und ist aktuell als Online-Umfrage implementiert.

Die Umfrage wird in kürze differenziert für den öffentlichen Bereich und Privatunternehmen zur Verfügung gestellt und die Teilnahme ist für alle Teilnehmer kostenlos. Die Ergebnisse der Umfragen werden anonymisiert ausgewertet und den  Teilnehmern zur Verfügung gestellt.

Interessiert

Weitere Informationen dazu gibt es in unserem Video und in kürze in einem weiteren Beitrag von uns.

Ansprechpartner

/von

Anforderungsmanagement – agil oder klassisch?

, ,

Das perfekte Projekt

In einem perfekten Projekt wäre alles ganz einfach:

  • Das zu entwickelnde Produkt wäre vollumfänglich bekannt. Sowohl der Kunde als auch der Auftragnehmer wüssten bis ins letzte Detail, wie es am Ende aussehen und was es können sollte.
  • Alle Wünsche und Anforderungen des Kunden wären zwischen diesem und dem Dienstleister(n) abgestimmt, vollständig dokumentiert und von allen am Projekt Beteiligten verstanden.
  • Basierend auf der Dokumentation würde eine nahezu wasserdichte Planung erstellt, die alle Anforderungen sowie Risiken berücksichtigt.
  • Anhand des Plans würde das Produkt entwickelt und natürlich in Time und in Budget fertiggestellt.
  • Und wenn das Produkt dem Kunden am Ende übergeben wird, steht fest: Auch an der Qualität gibt es nichts zu bemängeln. Es entspricht vollkommen dem Erwarteten und liefert den Mehrwert, den sich der Kunde davon erwartet hat, oder es übertrifft ihn sogar.

Die Realität

Wie wir alle wissen und um das ein oder andere Mal erfahren durften, kommt dieses Szenario in Wirklichkeit leider nicht, oder nur höchst selten vor.

Oft existiert zu Beginn eines Projekts nur eine sehr vage Vorstellung von dem Endprodukt.  Einige Anforderungen können vielleicht schon sehr konkret beschrieben werden. Andere, vor allem die komplexeren Themenbereiche sind allerdings für die Beteiligten noch mehr oder weniger eine Black Box. Manche Anforderungen erscheinen essenziell und werden daher mit höchster Priorität sowie unter teilweise großem Aufwand umgesetzt, ergeben sich später dann jedoch als überflüssig oder von nur geringem Mehrwert. Schließlich stellt sich dann noch während der Umsetzung heraus, dass dies und jenes in der ursprünglichen Planung vergessen wurde oder auf andere Art und Weise realisiert werden müsste. In Folge müssen die akribisch erstellten Dokumentationen aktualisiert und der Projektplan überarbeitet werden.

Doch wie kann man mit diesen Unsicherheiten umgehen? Ein agiles Vorgehen (bspw. nach dem Scrum-Framework) und ein damit einhergehendes agiles Anforderungsmanagement kann dabei unterstützen, flexibel und effektiv auf sich ändernde Gegebenheiten zu reagieren. Doch was unterscheidet das klassische Anforderungsmanagement von seinem agilen Pendant?

Klassisches und agiles Anforderungsmanagement – eine Gegenüberstellung

Nachfolgend wollen wir einige Faktoren unter Betrachtung beider Ansätze vergleichen.

 Klassisches AnforderungsmanagementAgiles Anforderungsmanagement
ProduktverständnisEs wird das Ziel verfolgt, das zu entwickelnde Endprodukt bereits zu Beginn vollständig zu erfassen und dessen Entwicklung damit möglichst vorhersehbar und kalkulierbar zu gestalten.Es wird davon ausgegangen, dass sich das Verständnis für das Produkt im Laufe des Projekts entwickeln muss. Hierfür wird auf Erkenntnisse und regelmäßiges Kundenfeedback  im Laufe der Umsetzung gesetzt.
Anforderungs-DokumentationDie Anforderungen werden  in einem Dokument (Lastenheft) vor Beginn der Umsetzung möglichst vollständig und detailliert dokumentiert.Anforderungen werden in Form von Themes, Epics und User Stories erfasst. Sie werden kontinuierlich (auch während der Entwicklung) angepasst und bewertet. Der Detaillierungsgrad von Anforderungen steigt entsprechend ihrer Priorisierung. Noch in weiterer Zukunft liegende Anforderungen werden erst dann näher betrachtet und beschrieben, wenn sie für die Umsetzung in absehbarer Zeit relevant werden.
KommunikationDie Abstimmungen mit dem Kunden erfolgen schwerpunktmäßig zu Beginn des Projekts im Rahmen der Anforderungsaufnahme.Die Abstimmung mit dem Kunden findet kontinuierlich statt. Regelmäßiges Feedback auch während des Entwicklungsprozesses ist ein wesentlicher Bestandteil.
ÄnderungenÄnderungen werden über einen Änderungsantrag initiiert, über den in einem Änderungsgremium (Change-Control Board) entschieden wird. Anschließende werden alle Dokumente und Pläne entsprechend angepasst und die Konfigurations-Baseline auf den neuen Stand gehobenÄnderungen werden durch Anpassung bzw. Erweiterung und Priorisierung des Product-Backlog eingesteuert. Durch die iterative Umsetzung in agilen Projekten kann schneller und flexibler auf sie reagiert werden.
Auslieferung des ProduktsDas Endprodukt wird nach Abschluss der Realisierungsphase an den Kunden übergeben.Eine erste Produktversion steht frühzeitig zur Verfügung und liefert dem Kunden bereits einen Nutzen (MVP – Minimum Viable Product)

Fazit

Klar ist: Das Management von Anforderungen darf nicht mit Beginn der Umsetzung enden. Die wenigsten Projekte kommen ohne Änderungen im Zuge der Umsetzung aus. Sei es, weil sich Anforderungen später als zu unpräzise oder fehlerhaft herausstellen, sich die Wünsche des Kunden ändern, neue Erkenntnisse einen anderen Blick auf das Produkt verschaffen oder Änderungen der Gesetzeslage oder des Marktes Anpassungen erfordern.

Letztendlich kann nicht pauschal das eine oder andere Vorgehen als besser erachtet werden. Beide Ansätze, ob klassisches oder agiles Anforderungsmanagement, haben ihre Berechtigung. In Zeiten komplexer werdender Produkte, sich immer schneller ändernder Rahmenbedingungen sowie neuen Arbeitsstrukturen können agile Vorgehensmodelle ihre Stärken ausspielen. Allerdings ist kein Projekt wie das andere und es muss nicht ausschließlich schwarz oder weiß sein. Aspekte aus beiden Ansätzen lassen sich durchaus sinnvoll miteinander kombinieren. Daher sollte für jedes Projekt beurteilt werden, welcher Mix sich anbietet und wie von den Vorteilen aus beiden „Welten“ profitiert werden kann.

/von

Endlich alles auf einen Blick!

Wo gehobelt wird, fallen Späne und wo IT-Assets verwaltet werden, entstehen Daten.

Das Verwalten von Daten im Bereich des IT Assetmanagement passiert in den meisten Unternehmen mittels unterschiedlichster Systeme. Es gibt Software zur Verwaltung von Lizenzprodukten, Buchhaltungsdaten, Mobiltelefonen etc. Jedes System hat dabei seinen individuellen Fokus und Blickwinkel auf bestimmte Daten.

Nun leben wir aber in einer IT-Welt, wo Daten miteinander verknüpft und analysiert werden, und nicht nur als Ballast in einem Karteischrank landen. Wieso also nicht direkt einen zentralen Service aufbauen, der die einzelnen Datensätze miteinander verknüpft?

Ein gutes Management von IT-Daten bietet hier allen Beteiligten vom Einkauf über den Support bis hin zur Planung Vorteile. Welche wichtigen Schritte auf dem Weg zu so einem Service notwendig sind möchten wir in diesem Artikel vorstellen.

Weiterlesen
/von

Anwenderzufriedenheit als KPI

, , , , , , , ,

Anwenderzufriedenheit als Kennzahl eines ganzheitlichen IT-Ansatzes

Eine IT-Organisation, die Antriebsmotor im Unternehmen ist, muss selbst getrieben sein von Proaktivität, Serviceorientierung und der Ausrichtung auf die Bedürfnisse der Anwender. Diese Faktoren müssen für eine Bewertung in Form von quantitativen sowie qualitativen Kennzahlen umgesetzt werden. Kontinuierlich gemessen ergeben sie die Bestandsaufnahme der IT, die entlang der angebotenen Services den Endanwender stets im Zentrum der Wahrnehmung behält. Dabei ist für die Betrachtung des Gesamtprozesses „Enduser Experience“ entscheidend, wie die Verfügbarkeit von Services durch den Endanwender insgesamt wahrgenommen wird. Daher ist die Anwenderzufriedenheit als KPI zur Messung und Optimierung der IT-Organisation ein ausschlaggebender Faktor.

Weiterlesen
/von

CMDB – Bottom Up oder Top Down?

Bei einem letzten Gespräch mit einem Kunden bzgl. des Aufbaus einer CMDB kam die Frage auf, ob wie man denn so ein Projekt nun eigentlich angeht. Muss das aus der IT kommen und soll da Jemand die Initiative ergreifen oder soll der Auftrag vom Management kommen?

Wie immer ist die Frage im Grund schnell und leicht zu beantworten und doch steckt der Teufel dann wieder im Detail.

Weiterlesen
/von

Rubber Duck Debugging

Im Umfeld der Softwareentwicklung gibt es zahlreiche Modelle und Methodiken, um den Prozess der Entwicklung zu optimieren. Stichworte wie „Agil“, „SCRUM“ oder „Kanban“ sind quasi jedem Experten in diesem Umfeld bekannt. Aber wer hat schon Mal vom „Rubberduck Debugging“ oder zu Deutsch „Quietscheentchen-Debugging“ gehört?

Weiterlesen
/von

Erfahrungsbericht – Vom Projekt zum Service

Als IT-Dienstleister sind wir auf Kundenanfragen spezialisiert, die bestimmte Wünsche mit verschiedenen Messkriterien definiert haben, das sog. Projekt.

Dieses Projekt soll innerhalb eines bestimmten Zeit- (meistens sofort und schnell) und Budgetrahmens, unter Erzielung der Qualitätsvorgaben, durchgeführt werden.

In den meisten Fällen kristallisiert sich nach der intensiven Initialphase heraus, dass die Ziele angepasst werden müssen. Weitere Interessenten und Zielgruppen werden auf die Inhalte des Projektes aufmerksam und möchten die Ergebnisse ebenfalls nutzen. So wird der Erfolg eines Projektes nicht nur an seinem reibungslosen Ablauf gemessen, sondern auch daran, wie die Ergebnisse im Anschluss an das Projekt weiter genutzt werden können.

Weiterlesen
/von

5 Links, die jeder Webentwickler kennen sollte

Jeder Entwickler hat seinen Pool aus nützlichen Online Tools. Wir haben in unserer Java Entwicklungsabteilung gefragt und wollen nun 5 Webseiten vorstellen:

Spring initializr

Aller Anfang ist schwer. Und so beginnt jedes Entwicklungsprojekt irgendwann mit der Erstellung einer Basis. Im beliebten JAVA Spring Umfeld gibt es hierfür eine praktische Variante namens „Spring initializr“. Mit ein paar Klicks stellen wir uns auf der Website das neue Projekt zusammen, setzen unsere Präferenzen und geben dem ganzen einen Namen. Gerade auch für Anfänger eine großartige Alternative, um direkt ins Coden einzusteigen ohne den üblichen Konfigurationsaufwand.

https://start.spring.io/

Crontab.guru

Einen Task manuell auszuführen ist einfach. Was aber wenn wir ein Programm oder ein Skript zu bestimmten Zeiten, wöchentlich, monatlich oder nur jeden Montag automatisch ausführen wollen? Wer so ein Thema umsetzt, stößt bald auf das Thema Cron Notation. Nur ist diese auf den ersten Blick meist nicht nachvollziehbar. Hier hilft uns „crontab.guru“. Einfach eine bereits vorhanden Cron String hineinkopieren und schon zeigt uns die Seite eine lesbare Übersetzung an. Mit diesem Tool wird das konfigurieren von cron jobs zum Kinderspiel!

https://crontab.guru/

RegExr

Ein mächtiges Tool zur Verarbeitung von Strings bieten Regular Expressions. Wir finden sie daher in verschiedenen Programmiersprachen wie JAVA, Python oder SQL wieder. Wer schon einmal komplexere Logiken damit implementiert hat weiß, wie umfangreich eine solche Expression werden kann.
Deshalb nun zu einem weiteren Tool, dass uns beim Entziffern von Code Hieroglyphen unterstützt: RegExr. Die Webapp bietet uns zahlreiche Möglichkeiten Regular Expressions zu bauen und zu testen. So werden z.B. die einzelnen Elemente der Expression ansprechend visuell dargestellt.

https://regexr.com/

Code Playgrounds: JSFiddle und Codepen

Zwei weitere interessante Tools sind die Code Playgrounds JSFiddle und Codepen. Wer neue Funktionalitäten im Umfeld von JavaScript, HTML und CSS ausprobieren möchte ohne gleich ein ganzes neues Projekt aufzusetzen ist hier richtig aufgehoben! Die Oberflächen der beiden Anbieter sind einfach zu bedienen und laden zum Experimentieren mit Code ein. Auch fürs Bugfixing eignen sich diese Tools wunderbar.

https://jsfiddle.net/

https://codepen.io/

/von

Testverfahren bei Media Solutions

Testen ist nicht sexy, aber unumgänglich!

Im Zeitalter von Tablets und Smartphones sind Anwender daran gewöhnt, dass Software reibungslos funktioniert. Wenn eine App beim zweiten Ausprobieren nicht die Ergebnisse wie erwartet liefert, fliegt sie vom Device und bekommt eine schlechte Bewertung. Nach Fehlern wird nicht gefragt, schon gar nicht gesucht. Doch um dahinzukommen, bedarf es immer noch eines wohlüberlegten Workflows von der Entwicklung über das Testen bis zur Auslieferung. Wir zeigen Ihnen heute, wie wir in unserem Unternehmen testen, welche Methoden wir anwenden und wie so ein Workflow bei uns aussieht.

Software muss getestet werden!

Wer kennt es nicht: “It’s not a bug it‘s a feature!” Das war in der Vergangenheit doch immer mal wieder eine Antwort des Supportes. Wenn was nicht ging, war es zuerst die „Dummheit der Anwender“.Das gehört immer mehr der Vergangenheit an. Klar gibt es noch Fehler, aber diese werden durch agile Entwicklungsmethoden, durch das 4-Augenprinzip und durch intensives Testen meist eliminiert, noch bevor die Software zum Kunden geht. Was früher den Anschein hatte, dass Software, wie Bananen, unreif ausgeliefert wurde, ist das heutzutage nicht mehr tragbar. Software muss von Beginn an fehlerfrei funktionieren. Durch ausgereifte Apps sind die Anwender verwöhnt und erwarten einfach, dass alles einwandfrei läuft. Dazu bedarf es umfangreicher Tests.

Unser Anspruch ist es, dem Kunden fehlerfreie Software zu liefern. Aus dem Grund haben wir einige Tester bei uns beschäftigt.

Wer testet Software?

Das sind ganz besondere Typen von Menschen, die dieses Gen: „Das muss sich doch zum Absturz bringen lassen!“, in sich tragen. Menschen, die sehr kreativ sein müssen, denn Sie müssen halt vom „DAU“ (Dümmster Anzunehmender User) ausgehen und sich die unwahrscheinlichsten Vorgehensweisen ausdenken, die ein Anwender mit einer Software anstellen kann. Doch diese Kreativität muss in Bahnen gelenkt werden, denn akribisches Arbeiten ist ebenfalls extrem wichtig, damit Fehler gefunden, reproduziert und dann natürlich behoben werden können.

Automatische Tests

Jetzt werden Sie denken, was soll das alles? Heutzutage wird doch alles automatisch getestet. Nein, denn auch heute noch können nicht alle Fehler durch automatisierte Testverfahren gefunden werden. Zwar helfen die Automatismen, einiges an Fehlern zu finden, aber in vielen Bereichen ist das manuelle Testen unumgänglich. Z.B. die Bewertung für die Handhabung und Bedienbarkeit einer Software, lässt sich allein durch eine automatisierte Testausführung nicht abdecken. Aber natürlich greifen wir auch auf Tools zur Testunterstützung zurück:

  • QF Tool (GUI Testautomatisierung)
  • ATF Tool (Automatisiertes Testen für die ServiceNow Instanz)
  • Testlink (open Source) Testmanagementsystem für die Testfalldokumentation und -auswertung)
  • Burp Suite (Security Testing)

In einem weiteren Artikel werden wir Ihnen die verschiedenen Anwendungsgebiete der unterschiedlichen Verfahren vorstellen.

Nur in enger Abstimmung mit der Entwicklung

Wer glaubt, dass Entwicklung und Test gegeneinander arbeiten, ist auf dem Holzweg. Die Arbeit der Tester besteht hauptsächlich aus der engen Zusammenarbeit mit den Kollegen aus den Entwicklungsteams. Nur so kann sichergestellt werden, dass die Entwicklung zügig voranschreitet.

Erfahrung machts

Genauso wichtig, wie in der Entwicklung, ist auch beim Testen die Erfahrung. Unsere Erfahrungswerte haben wir in der gesamten Leistungsbandbreite von Media Solutions, wie in der Anwendungsentwicklung, Digitalisierung und ESM (Enterprise-Service-Management) mit ServiceNow sammeln können.

Testverfahren

Wir verwenden Testmethoden basierend auf dem Blackbox Verfahren, ohne die Codierung zu berücksichtigen. Das Verfahren enthält Testarten wie GUI Tests, IT-Security Tests, Zustand basierte Tests, Positive Tests und Negative Tests.

Der GUI (Graphical User Interface) Test

bezieht sich ausschließlich auf die Benutzeroberfläche. In diesem Verfahren werden folgende Aspekte von uns gesichtet und durchgetestet:

  • die grafische Darstellung (Bilder, Tabellen, Buttons)
  • die Funktionen (Exportieren, Suche ausführen, Speichern)
  • Anwendersicht, Usability
    Und natürlich, dass alle vorgegebenen Spezifikationen für eine Anwendung eingehalten werden.

Die IT Security Tests

berücksichtigen hier die Sicherheitsaspekte:

  • Passwortrichtlinien
  • Schutz der Anwendung vor Datenklau
  • Datenmanipulation
    So kann gesichert werden, dass unberechtigter Zugriff verweigert wird.

Der Zustand basierte Test

prüft nach einer Ausführung von einer Aktion das veränderte Systemverhalten:

  • Beinhaltet die Anwendung einen Statusworkflow so müssen die Statusveränderungen geprüft werden

Der Positive Test

soll den Nachweis erbringen, dass eine Anwendung das tun soll, was sie tun soll:

  • es wird gegen die System-Anforderung geprüft
  • es wird gegen die Kunden-Anforderung geprüft

Der Negative Test

prüft das Systemverhalten der Anwendung bei falscher Eingabe oder Bedienung:

  • bei falscher Eingabe wird dies mit einer Fehlermeldung abgefangen
  • bei falscher Bedienung ist die fehlerhafte Bedienung so nicht ausführbar

Die oben aufgeführten Testverfahren entsprechen dem ISTQB Testverfahren.

Unser Workflow

Wie schon erwähnt, stehen wir während einer Testphase in einer transparenten Kommunikation mit dem Entwicklerteam. Nachdem die Anforderungen mit dem Kunden abgestimmt worden sind, beginnt die Entwicklung mit der Umsetzung. Nach oder auch mal während der Umsetzung wird das Testteam mit einbezogen. Das ist der Beginn eines fließenden Workflows.

Von Anfang an, sind wir mit in den laufenden Projektprozess eingebunden. Der Testprozess startet sogleich mit unserer Aufwandsabschätzung. Bevor die eigentliche Testausführung beginnt, werden die Testdaten vorbereitet und die Testcases (Testfälle) geschrieben.

Je nach Anwendung führen wir die Tests, wie nach den oben genannten Methoden, aus. Wenn an einer bestehenden Anwendung, aufgrund vom Kunden, eine Erweiterung oder Änderung gewünscht ist, dann werden von uns die „Regressionstests“ ausgeführt. Dies beinhaltet den Test von einem kompletten System, ob die Änderungen oder Erweiterung vom System, eine Auswirkung hat, auf die bestehenden Module oder Komponenten im System.

Zur direkten Kommunikation und Dokumentation nutzen wird das Tool „Jira“, hier werden auch alle gefundenen Bugs erfasst und dokumentiert. Nach Abstimmung mit dem Entwicklerteam, werden die Bugs behoben. Von unserer Seite erfolgt dann ein weiterer Test, ob der Bug gefixt wurde.

Sobald wir mit allen Tests durch sind, findet die abschließende Testdokumentation statt. In diesem Zuge wird die Anwendung dem Kunden zum Testen zur Verfügung gestellt. Falls der Kunde jetzt noch einen Bug finden sollte, kommen wir wieder zum Einsatz, um den Bug zu reproduzieren. Anschließend findet seitens der Entwicklung wieder ein Bugfix statt. Prozesswiederholend müssen wir nun einen Regressionstest durchführen, um wirklich sicher zu gehen, dass der Bugfix keine weiteren Auswirkungen auf das Systemverhalten hat.

Wenn dann alles zu unserer Zufriedenheit getestet worden ist, geht dies final zum Kunden raus und wir schließen den Testprozess ab.

/von