TEAM Engine - Eine Validierungs-Engine für OGC Geodienste und -formate - Wie kann ich von diesem Tool profitieren?
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 95 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/36209 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
1
6
10
11
12
14
15
16
23
28
37
39
41
50
53
54
58
60
62
68
70
71
72
74
76
77
78
79
82
83
86
90
95
00:00
ValidierungWort <Informatik>RechenschieberDateiformatVorlesung/Konferenz
00:43
Open SourceImplementierungImplementierungSoftwareStandardabweichungComputeranimation
01:25
SoftwareOpen SourceImplementierungProgrammiergerätKomponente <Software>
01:53
SoftwaretestComputeranimation
02:15
LADY <Programmiersprache>Computeranimation
02:48
ValidierungClientDienst <Informatik>SoftwaretestComputeranimation
03:14
ValidierungURLClientQuellcodeOpen Source
03:39
Web-ApplikationTestNGSchnittstelleCoin <Programmiersprache>Differentiation <Mathematik>SoftwaretestComputeranimation
04:35
CodeTestNGETS <Programm>Dienst <Informatik>SoftwaretestTwitter <Softwareplattform>CodeURLFRAMEWORK <Programm>VerschlingungComputeranimation
05:28
ETS <Programm>Twitter <Softwareplattform>SoftwaretestRepository <Informatik>
05:51
Computeranimation
06:26
Microsoft Transaction ServerWindows SharePoint ServicesParametersystemBrowserRechteckDatensichtgerätDienst <Informatik>InformationConstraint <Künstliche Intelligenz>AggregatzustandComputeranimation
07:50
SoftwaretestKlasse <Mathematik>XML
08:49
ImplementierungClientURLSoftwaretestComputeranimation
09:42
URLSoftwaretestService PackTouchscreenSchnittstelleComputeranimation
10:58
URLApache MavenSoftwaretest
11:25
ErweiterungSoftwareentwicklerSoftwareImplementierungSoftwareproduktionPasswortFunktion <Mathematik>ImplementierungSoftwareZugriffOpen SourceVersion <Informatik>SoftwaretestMomentenproblemStandardabweichungSchnittstelleComputeranimation
14:53
SoftwareDatenhaltungInformationsqualitätInformationsqualitätSoftwareStandardabweichungGravitationsgesetzExpertensystemDatenhaltungSoftwareentwicklerComputeranimation
16:23
SoftwareentwicklerSoftwaretestComputeranimation
16:52
ExpertensystemDienst <Informatik>SoftwaretestMatrizenringBildschirmmaskeStandardabweichungImplementierungVerschlingungSchnittstelleSoftwareentwicklerComputeranimation
18:03
Dienst <Informatik>ImplementierungDatensatzEigenwertproblemExpertensystemSpielkonsoleSoftwaretestTabelleAggregatzustandComputeranimation
20:56
SoftwareentwicklerDatenunabhängigkeitDienst <Informatik>SoftwaretestExpertensystemComputeranimation
21:15
KonfigurationsraumSchnittstelleDienst <Informatik>Computeranimation
21:54
FokalpunktBenutzerfreundlichkeitDatenunabhängigkeitFokalpunktExpertensystemComputeranimation
22:26
FokalpunktBenutzerfreundlichkeitDatenunabhängigkeitDienst <Informatik>ErweiterungLaufwerk <Datentechnik>InternetSoftwaretestVorlesung/Konferenz
Transkript: Deutsch(automatisch erzeugt)
00:07
Ich möchte jetzt den nächsten Vortrag ankündigen, es geht um die Team Engine, auch ein OGC-Thema und der Dirk Stänger von der Firma Latlon wird den Vortrag halten und ich wollte ihn schon vorstellen und dann meinte
00:22
er, ich habe einen Slide dazu, deswegen das war es von meiner Seite mit den Worten. Dirk, the floor is yours. Hallo erstmal, mein Thema heute ist Team Engine, eine Validierungsengine für OGC, Geodienste und Formate
00:43
und ich möchte besonders auf die Fragestellung eingehen, welche Benutzergruppen besonders von diesem Tool profitieren können. Wie Artina eben schon gesagt hat, habe ich auch selber eine Vorstellungsfolie, ich bin Diplomgeograf, arbeite seit 2012 bei Latlon
01:04
und wir beschäftigen uns hauptsächlich mit OGC-Standards und alles was dazugehört, bauen Anwendungen darum, besonders mit dem Degree Framework, das ist Software die eine Implementierung für solche oder für die OGC-Standards bietet, zudem sind wir auch Mitglied des OGC
01:29
-Side-Teams und das schon seit sehr lange und seit Juni 2017 übernimmt Latlon die technische Leitung der OGC-Compliance-Tools
01:42
und das umfasst im Prinzip alle technischen Komponenten des Side-Programms. Das ist die Agenda, was ich heute vorstellen werde, ich werde erst kurz erzählen, was ist die Team Engine überhaupt und welche Testsuites gibt es für dieses Tool, dann werde ich noch auf die aktuellen und zukünftigen Entwicklungen eingehen
02:03
und dann komme ich zu der Frage, welche Nutzergruppen gibt es überhaupt, die die Team Engine sinnvoll einsetzen können und auch von der Team Engine profitieren. So auf dieser Folie sieht man erstmal auf der rechten Seite die Oberfläche der Web-Version der Team Engine,
02:27
dies ist auch die offizielle Installation vom OGC, also wenn man die URL, kann auch jeder Nutzen sich selber angucken. Links davon sieht man jetzt ein Capabilities-Dokument von einem WFS und man
02:41
kann jetzt diesen WFS, der links dargestellt wird, mit der Team Engine validieren. Richte die Team Engine ausgeschrieben Test Evaluation and Measurement Engine, das ist eben eine Testausführungs-Engine, mit der verschiedensten Ressourcen getestet werden können, dazu gehören unter anderem Services,
03:02
das ist auch der häufigste Anwendungsfall, wie z.B. WMS oder WFS, aber auch Clients können getestet werden, es gibt z.B. eine Testsuite für WMS Clients, aber auch Schemas, wie z.B. GML Schemas oder auch Direct-Daten wie Geopacket.
03:25
Die Team Engine ist in Java geschrieben und der komplette Quellcode ist frei verfügbar um Source und liegt auf Jithub, da folgende URL kann man sich anschauen, auschecken und selber bauen.
03:40
Die Team Engine führt wie gesagt Test-Skripte aus, fast ausschließlich werden die beiden Sprachen Compliance-Test-Language und Test-NG genutzt. Die Compliance-Test-Language wurde vom OGC spezifiziert und die Test-NG kommt mehr aus der Java-Welt, sie hat
04:10
ein Java-Test-Framework, aber man kann nun auch in Java die Tests schreiben und damit der Team Engine ausführen. Wie ich schon sagte gibt es eine Web-Oberfläche für die Team Engine, aber inzwischen gibt es
04:26
auch eine REST-Schnittstelle und ein Kommandozellentool, also man kann immer verschiedenste Wege die Team Engine ausführen. Es gibt über 20 Test-Suite vom OGC, die mit der Team Engine ausgeführt werden können,
04:46
also ich würde sogar sagen, dass es inzwischen zwischen 30 und 40 Test-Suite sogar sind. Der Code aller Test-Suite befindet sich auch auf Github und jeder kann ihn sich anschauen und wie gesagt alle Test-Suite nutzen entweder die Sprachen CTL oder Test-NG bzw. Frameworks.
05:11
Jetzt habe ich hier einfach mal drei Beispiele für Test-Suite aufgelistet, inklusive der URLs. Dies Jahr ETS steht für Executable Test-Suite, WFS 1.1 wäre der WFS 1.1, hinter diesem Link findet man die Test-Suite zu diesem OGC-Standard.
05:35
Analog gibt es auch für WFS 2.0 und WMS 1.3 in der Test-Suite. Und wenn man einfach den letzten Punkt wegnimmt, hat man auch eine Übersicht aller verfügbaren Test-Suite.
05:49
Ganz wichtig, auf Github hat ja jedes Repository seinen eigenen Issue-Tracker und den nutzen wir auch ganz aktiv. Das heißt, wenn jemand eine Test-Suite nutzt oder auch die Team Engine selber und
06:02
man einfach eine Frage hat, kann man ein Issue hier anlegen und den beantworten wir dann. Also das ist so der beste Weg eigentlich Fragen zu den Test-Suite oder zur Team Engine selber zu stellen. Es kann natürlich auch sein, dass einem irgendwie was komisch vorkommt und wenn man vielleicht einen Bug vermutet oder ein Feature fehlt, dann das kann man genauso da reinschreiben.
06:27
So jetzt zeige ich kurz, wie sieht das eigentlich aus, wenn man mit der Team Engine Dienst testet. Ich zeige das Ganze mit dem Webbrowser Interface. Also das erste, was man machen muss, ist sich einen Account anlegen.
06:43
Kann auch jeder machen, also da gibt es jetzt keine Beschränkung. Dann muss man so eine neue Test-Session starten und kommt zu dieser Oberfläche. Dort wählt man die Organisation aus, das ist in jedem Fall OGC, wenn man die OGC-Installation nutzt.
07:02
Und darunter, welche Spezifikationen man testen möchte. Also in dem Beispiel hier will ich einen WFS 2.0 testen. Klickt man auf start a new session und kommt dann zu diesem Bildschirm. Und das ist jetzt eine Beschreibung der Test-Suite.
07:22
Oben erstmal Informationen, was wird getestet, welche Inputparameter werden benötigt. Und unten gibt man dann wirklich die relevanten Parameter an. Das wichtigste ist eigentlich immer das Capabilities-Dokument. Das gibt man hier an, damit die Test-Suite überhaupt weiß, welcher WFS getestet werden soll.
07:42
Und dann folgen unten immer noch optionale Angaben. Das ist auch ganz unterschiedlich bei Test-Suite. Dann muss man auf start klicken, kriegt diesen Bildschirm. Den hat man dann auch eine Weile zu sehen. Weil das ist genau die Darstellung, die erscheint, wenn die Test-Suite ausgeführt wird.
08:05
Und irgendwann ändert die Darstellung dann zu dem Testergebnis. Das ist jetzt auch wirklich das Testergebnis für ein WFS 2.0. Das ist die Referenzimplementierung, die von uns bereitgestellt wird.
08:20
Das heißt, die besteht auch, wohl alle Testklassen nicht, aber fast alle. Also nur die sehr stark Spezialisierten nicht. Und hier seht ihr auch direkt, das ist auch ein neues Feature, ein neuer Report. Also man sieht hier die Tests aufgelistet und kann sich dann noch Details abrufen.
08:43
Es ist besonders interessant, wenn ein Test fehlschlägt. Dann will man ja wissen, warum schlägt er fehl. Das kann man dann alles in diesem Report sich anschauen. So, wie ich schon häufiger gesagt habe, stellt das OGC wirklich eine Installation der Team Engine bereit. Die erreicht man über folgende URL.
09:01
Und diese Installation der Team Engine wird produktiv genutzt, wenn ein Unternehmen die Implementierung eines OGC Services zertifizieren möchte. Das heißt, man kann seine Implementierung eines OGC Services testen lassen und sich dann vom OGC als OGC Compliant labeln lassen.
09:27
Eine weitere Sache ist, dass auch Referenzimplementierungen dort zertifiziert werden. Das ist aber eigentlich nur ein weiterer Schritt, weil Referenzimplementierungen der Allgemeinheit oder auch immer für einen bestimmten Zeitraum verfügbar sein müssen.
09:41
Dass jeder die Referenzimplementierung nehmen kann, um zu gucken, das ist ein Dienst, der alle Tests besteht. Eine Liste der Referenzimplementierungen findet sich unter folgender URL. So, dann komme ich schon zu den aktuellen Entwicklungen der Team Engine.
10:04
Es wurde jetzt vor ungefähr einem halben Jahr die Team Engine 5.0 veröffentlicht. Also inzwischen sind wir auch schon bei Team Engine 5.2 angelangt. Die großen neuen Features von Team Engine 5.0 waren, dass das Reporting komplett überarbeitet wurde.
10:21
Also eben im Screenshot hatte ich auch schon das neue Reporting. Und es wurde auch das REST-Interface eingeführt, mit dem man Tests ziemlich komfortabel über eine REST-Chance-Stelle ausführen kann. Richtig, wir haben noch 5.1 und 5.2 sind auch erschienen.
10:40
Die enthalten sehr große Anzahl an Bugfixes und weiteren kleinen Verbesserungen in der Oberfläche und auch am REST-Interface. Zudem gibt es seit ungefähr einem Jahr ein Docker-Projekt zur Team Engine. Es hat auch ein eigenes Repository, das man unter dieser URL erreichen kann.
11:04
Dort wird beschrieben, wie man sich ziemlich einfach mit Maven ein Docker-Image zusammenbauen kann. Mit einer beliebigen Kombination oder nicht ganz beliebig, aber mit einer konfigurierbaren Kombination aus installierten Test-Suites.
11:23
Die zukünftigen Entwicklungsschwerpunkte sind, dass wir das User-Interface weiter verbessern wollen. Also vor allem von der Web-Oberfläche, dass das Managing von Sessions einfacher wird. Einfach kleine Funktionen dazukommen, wie z.B. man kann sein Passwort noch nicht zurücksetzen. Da haben wir eine ganze Liste auf Github, was wir dann noch machen wollen.
11:43
Eine weitere Sache ist, dass wir das REST-Interface erweitern wollen. Im Moment kann man mit diesem Interface einfach nur Tests ausführen und kriegt dann in der Response des Requests das Testergebnis. Es ist aber nicht möglich, diese Testergebnisse zu speichern oder einen Nutzer zuzuordnen, dass der Nutzer die später verwalten kann.
12:03
Da wollen wir einfach noch neue Methoden einführen, dass z.B. eine Ausführung eines Test-Runs über die REST-Schnittstelle auch unter einem Nutzer gespeichert wird und dann z.B. später noch eingesehen werden kann.
12:23
Eine weitere Sache ist, die planen wir auch schon seit Längerem, dass die Docker-Images, die wir mit diesem Maven-Projekt erstellen, und wir nutzen das auch sehr regelmäßig, täglich würde ich sagen diese Docker-Images, aber dass die auch auf Docker-Hub geschoben werden sollen, dass es dann für Nutzer noch einfacher ist,
12:44
einfach mit einem Docker-Pull diese Images runterzuziehen und direkt eine lauffähige Version der Team Engine Plus einer ausgewählten Anzahl an Test-Suite zu haben. Und klar, ein weiterer großer Punkt ist, an dem wir immer arbeiten, dass alle bestehenden Test-Suite weiter verbessert werden,
13:03
machen konstant Bug-Fixes und wenn die Zeit da ist, setzen wir uns auch an Enhancements. Nun komme ich zu der zentralen Fragestellung, die ich in dem Vortrag bearbeiten will. Welche Nutzer können überhaupt wie von der Team Engine profitieren?
13:22
Ja, erstmal stellt sich die Frage, wer kann alles die Team Engine nutzen, das ist relativ leicht zu beantworten, die kann nämlich jeder nutzen, weil sie frei verfügbar ist, sowohl die Installation, es gibt eine frei verfügbare Installation, als auch der Source Code, also jeder hat Zugriff auf alle Ressourcen, kann sich das anschauen, die Team Engine bauen und ausführen.
13:48
So, aber noch wichtiger ist natürlich die Frage, welche Nutzer überhaupt von der Team Engine profitieren können, weil nur, wenn man sie nutzen kann, hat man ja noch nichts davon.
14:01
Und dafür sollte erst die Frage beantwortet werden, welche Art von Nutzer es überhaupt gibt. Also ich habe dann einfach mal so ein paar Gruppen erstellt, wo ich glaube, dass das typische Nutzer der Team Engine sind. So, die erste Gruppe davon sind die Softwareentwickler, richtig sind eher, haben eine technische Expertise, entwickeln Designsoftware
14:24
und sind jetzt in unserem Fall für die Implementierung von OGC-Standards in Software zuständig. Das heißt, diese Gruppe bezieht sich jetzt wirklich auf Personen, die sich ein OGC-Standard nehmen und Software dazu schreiben,
14:41
die diesen OGC-Standard umsetzen. Klar, typische Arbeitsfelder sind in der Softwareherstellung, in der Softwarepflege auch. So, die zweite Gruppe war ein bisschen schwieriger. Es war auch schwer, Begriffe überhaupt dafür zu finden.
15:01
Ich habe sie jetzt einfach Giz-Experten genannt. Das sind Personen, die sowohl eine fachliche als auch technische Expertise haben und sich in ihrem Beruf einfach mit Giz beschäftigen oder auch Giz als zentrales Arbeitsfeld haben, aber keine Softwareentwickler sind.
15:22
Also das trifft glaube ich auch auf viele Leute, die auf der Konferenz hier sind, zu. Wichtige Tätigkeiten sind Konfigurieren von Software, aber auch mit Datenbeständen arbeiten, sich um die Datenhaltung kümmern, Datenqualität, Migration von Daten und so weiter. Diese Personen sind ja meistens so nah noch an den Standards dran, dass sie sich auch an diesen Standards auskennen
15:47
und die OGC-Standards auch für ihre tägliche Arbeit benötigen richten. Die dritte Gruppe, die ich identifiziert habe, sind Giz-Anwender. Das sind Leute, die jetzt wirklich eher keine technische Expertise haben, sondern in irgendeinem fachlichen Feld arbeiten.
16:08
Wir haben zum Beispiel Planer, die die Planungsaufgaben übernehmen, dafür einfach ein Gizsystem nutzen, aber eigentlich technisch keine Ahnung haben, was macht das Giz jetzt.
16:21
Diese Leute nutzen ja häufig auch ein WMS und laden die da irgendwie als Hintergrundkarte ein in ihre Anwendung. Richtig setzen die OGC-Standards also in der Praxis ein. Das ist so die dritte Gruppe, die ich identifiziert habe. So, jetzt nochmal die Zusammenfassung aller Gruppen, die ich als typischer Anwender der Team Engine sehe.
16:45
Jetzt stellt sich aber die Frage, können alle drei Gruppen wirklich alle Testsweets des OGC gleichermaßen effizient nutzen? Ich würde dafür euch einfach mal eine kleine Matrix erstellt. Man sieht hier in der linken Spalte verschiedene Standards, zu denen es eine Testsuite gibt vom OGC und hier oben dann nochmal die drei Gruppen.
17:10
Ich gehe jetzt einfach mal exemplarisch auf ein paar Standards ein, also die WFS 2.0 Testsuite. Richtig, sehr wichtig für die WFS 2.0 Testsuite ist, dass sie datenunabhängig ist.
17:22
Das heißt, man kann jeden Dienst, den man irgendwie konfiguriert hat, in diese Testsuite stecken, die den Dienst damit validieren. Für Softwareentwickler ist es auf jeden Fall sinnvoll, wenn sie eine Implementierung des WFS 2.0 machen, müssen sie auch wissen, haben sie die Schnittstelle auch richtig implementiert. Für GIS-Experten ist es auch eine sinnvolle Testsuite, weil die Leute haben eventuell einen WFS 2.0 konfiguriert oder kriegen einen bereitgestellt
17:49
und wollen dann wissen, ist da auch wirklich Compliance im OGC-Standard. Hier würde ich auch sagen, es ist definitiv sinnvoll, wenn es von Interesse ist, ob der
18:03
WFS 2.0 wirklich zu 100% dem Standard entspricht, dass auch GIS-Experten die Testsuite nutzen. Bei GIS-Anwendern sieht man auch, habe ich überall eher nein oder nein, weil den typischen Anwender interessiert es wahrscheinlich nicht, ob der WFS 2.0 dem Standard entspricht, sondern er will einfach nur,
18:20
dass es irgendwie funktioniert, aber ob da jetzt irgendwelche Requirements nicht erfüllt werden, mancher Anwender interessiert es vielleicht, weil die meisten wahrscheinlich eher nicht. So, dann gehe ich nochmal auf den WFS 1.1.0 ein.
18:40
Hier ist der entscheidende Unterschied, dass ich hier beim GIS-Experten eher einen GIS-Anwender nein geschrieben habe. Und der Grund hierfür ist, dass diese Testsuite datenabhängig ist. Das heißt, wenn man seinen WFS aufgesetzt hat, muss man einen ganz bestimmten Testdatensatz einspielen. Und die Testsuite funktioniert auch nur mit genau diesem Testdatensatz.
19:03
Das heißt, für Softwareentwickler, die irgendwie eine Implementierung für den WFS 1.1.0 gemacht haben, ist das kein Problem. Die importieren den Datensatz und testen dann die ganze Zeit damit. Für GIS-Experten, die jetzt vielleicht auch verschiedene Dienste damit testen wollen, ist das eher ungeeignet, würde ich sagen. Also in Einzelfällen vielleicht schon sinnvoll, aber man kann halt nicht jeden frei verfügbaren WFS damit testen.
19:27
Für GIS-Anwender würde ich sagen, die dann sogar noch ihren eigenen Datensatz importieren müssen, ist das eher zu aufwendig. Deswegen hier ein Nein hingeschrieben. Dann gibt es hier noch teilweise, das sind Testsuites, die zum Teil datenunabhängig sind, zum Teil datenabhängig.
19:48
Da muss man halt immer wissen, was will man testen. Richtig, hier unten, die beiden Testsuites sind vielleicht auch noch ganz interessant. Die GML-Testsuite kann sowohl ein GML-Schema als auch ein GML-Datensatz validieren.
20:03
Geo-Package, klar, kann ein Geo-Package-Datensatz validieren, sind beide datenabhängig, würde ich definitiv sagen, dass die auch für GIS-Experten sinnvoll sind. So richtig, was man jetzt hier sieht, für Software-Entwickler sind alle Testsuites sinnvoll zu nutzen.
20:23
Das heißt, oder es ist auch im Prinzip der Ursprung der Team Engine, die wurde für Software-Entwickler geschrieben. Man sieht aber auch, dass immer mehr Testsuites auch für GIS-Experten anwendbar sind. Und das ist eigentlich so die Kernaussage von dieser Tabelle, das war nämlich früher noch nicht so.
20:44
Also diese unabhängigen Testsuites sind alle sehr neu, aber ich würde jeden motivieren, sich die mal anzuschauen und zu nutzen. Weil die wirklich gut geworden sind und für eine breitere Masse nutzbar sind.
21:01
Das ist jetzt eigentlich nochmal eine Zusammenfassung von dem, was ich eben schon gesagt habe. Software-Entwickler können sehr gut alles nutzen, GIS-Experten, die datenabhängigen Tests und GIS-Anwender. Das interessiert es meistens eher nicht, würde ich sagen, um Dienst OGC-konform zu sein, wenn eine Ausnahme fällen.
21:23
Und dann komme ich auch schon zum Fazit. Die Team Engine hat eine Möglichkeit, schnelles Testen auf OGC-Compliance. Das ist sowohl für Konfigurationsarbeiten als auch für Implementierungsarbeiten sinnvoll, dass man immer wieder gucken kann, ob man eine Schnittstelle richtig konfiguriert oder auch implementiert.
21:44
Dadurch können Bugtickets angelegt werden und Dienst im Prinzip OGC-compliant gemacht werden, indem diese Bugtickets behoben werden. Zudem können Testsuits natürlich auch als Regissionstests verwendet werden. Das ist jetzt noch ein bisschen das Fazit zu dem letzten Teil. Ursprünglich gab es halt eine Konzentration der Team Engine auf GIS-Entwickler,
22:04
aber auch GIS-Experten, zum Teil auch GIS-Anwender, rücken immer stärker in den Fokus und können die Team Engine sehr gut nutzen. Auch die Erhöhung der Nutzerfreundlichkeit ist hier natürlich sehr wichtig.
22:20
Klar, die Testsuits werden hauptsächlich dafür genutzt, um OGC-Standards zu zertifizieren, aber es gibt auch immer mehr in den Anwendungsfällen das komplett konfigurierte Dienst mit unterschiedlichen Daten getestet werden können. Gibt es noch Fragen?
22:43
Herzlichen Dank, Dirk. Es sind Fragen. Also Dirk ist wahrscheinlich der Experte in Deutschland, der alle Fragen rund um die Testsuit beantworten kann. Also mein Kollege Luis Bermudez aus den USA arbeitet sehr eng mit Dirk zusammen.
23:03
Ja, hallo. Kann man auch mit der Team Engine CSW testen oder dann noch zukünftig mit CSW 3.0? Ja, doch. Gibt es eine Testsuit dafür? Ich bin mir jetzt unsicher, ob die datenabhängig oder datenunabhängig ist, aber es gibt auf jeden Fall eine Testsuit dafür.
23:25
Weitere Fragen? Ganz kurz, wenn man so einen Test entwickelt, wie muss ich mir das vorstellen, wie lange dauert das? Ja, das ist unterschiedlich. Das liegt immer an der Spezifikation.
23:48
Also einen Test kann man innerhalb von einer Stunde schreiben, aber wenn es dann komplexer wird, kann das auch mal mehrere Tage dauern.
24:00
Also ich würde jetzt sagen, die Testsuits in die ursprüngliche Entwicklung sind sicherlich so ein, zwei Wochen gelaufen. Dann müssen die aber auch von Usern getestet werden und werden irgendwelche Bugs verwendet. Die Testsuits sind entdeckt, Erweiterungen noch gemacht. Es ist ein fortlaufender Entwicklungsprozess eigentlich. Und ich kann auch alle motivieren, die Issue Tracker zu nutzen.
24:22
Wir checken jeden Tag, ob es neue Issues gibt und beantworten dann auch meist relativ schnell alle Fragen.