Hallo Viktoras,

Zuerst VIELEN Dank für Deine Rückmeldung. Ein Ziel des Gesprächs heute MUSS es sein, die Diskussion weiter zu führen und Stück für Stück den Workflow unseres Unternehmens zu optimieren. Emails wie Deine tragen dazu bei! Einer Anregung von Marcus folgend schlage ich vor, dieses Gespräch in 4 oder 6 oder 8 Wochen zu wiederholen und auf diese Weise dauerhaft Kritik und Optimierung in unsere Arbeit aufzunehmen!

Aus meiner Sicht muss das "Testing"/"Überwachung" von xRes- und xMid-Systemen 3stufig sein:

automatisiertes Testing
manuelles Testing
Überwachung im Livebetrieb

Zu 1:
Deine Vorschläge für ein weitergehend automatisiertes Testing nehme ich sehr gern auf. Bereits vor längerer Zeit habe ich den Einsatz von Selenium und die Erweiterung von PhpUnit-Tests vorgeschlagen, beides sind aber Prozesse, die einige Zeit brauchen und erst zukünftig zu einer Reduzierung des manuellen Testings beitragen werden.
Wir sind dort aber auf einem sehr guten Weg (wir haben in 1,5 Jahren fast 2500 einzelne UnitTests erstellt) und ich BITTE Dich, dies auf diese herausragende Weise fortzusetzen.

Zu 2:
Was wir leider durch Automatisierung nicht lösen können, ist "miteinander zu sprechen" und "selbstständig zu denken". Ein automatischer Test:

hat eine begrenzte Reichweite (d.h. er testet nur vorgegebene Szenarien und begrenzte Komplexität),
ERSETZT nur dann einen manuellen Test, wenn der menschliche Tester von Existenz und Umfang des automatischen Tests weiß,
kennt die inhaltlichen Prozesse und Workflows der Veranstalter nur im einprogrammierten Umfang
findet keine Seiten-Effekte zu einer vorgenommenen Änderung

An diesen Stellen werden wir manuelles Testing weiterhin brauchen und müssen dieses aus kapazitiven Gründen durch die Entwicklung unterstützen. Zur Entlastung des Support ist es erforderlich, dass Entwicker das manuelle Testing vor-arbeiten durch

automatisches Testing UND dessen Dokumentation im JIRA-Task
manuelles Testing UND dessen Dokumentation im JIRA-Task
Hinterfragen / Abstimmen / Rückfragen zu Ist- und Soll-Zustand einer Aufgabe UND deren Dokumentation im JIRA-Task.

Zu 3.
Deine automatischen Report-Emails zum Thema Hotel und Flug sind wirklich große Klasse und entlasten den Support erheblich! Wenn Du dieses Vorgehen mit Carsten sogar noch erweiterst, hat dies meine volle Unterstützung!
Leider finden diese Reporte ein Problem frühstens dann, wenn es in einem xRes-Livesystem auftritt und kann damit Schritte 1 und 2 als präventives QM nicht ersetzen.

Fazit:
Haiko und ich haben heute vorgeschlagen, die Arbeitsweise der TraSo an den folgenden Punkten zu verbessern:

geänderter Release-Zyklus:
Es wird (besonders für den Support) vorhersehbarer und steuerbarer, was in einem Release enthalten ist und die Kunden-Kommunikation kann entsprechend optimiert werden.
Die zeitliche Differenz zwischen "Ich habe mal einen Task erstellt" und "Ich muss eine Änderung testen, habe aber den Task längst wieder vergessen" geringer. Darüber hinaus erfolgt die Testing-Rückmeldung des Support an den Entwickler zeitlich kürzer (nach der Entwicklung) und nachträgliche Anpassungen / BugFixes erfordern weniger "Hinein-Denken".
Im Sinne des Kunden sind wir in der Lage, dynamischer auf Kundenwünsche / -probleme einzugehen und arbeiten enger an der Anforderung.
Arbeit mit dem JIRA: Dort herrschte von allen Seiten große Unzufriedenheit und undurchsichtiger Task-Wildwuchs. Durch mehr Abstimmung und bessere Dokumentation werden wir dabei besonders dem Support gerecht. Auf der anderen Seite werden wir der Entwicklung damit gerecht, die immer wieder Tasks zurück gehen lässt und diese damit (teilweise längere Zeit) in eine unnötige Warteschleife schickt.
Unterstützung des Testings durch die Entwicklung: Deine Vorschläge (und Umsetzungen) zu automatisierten Tests und automatischem Monitoring finden meine volle Unterstützung. Dennoch betrachte ich sie als Teil eines weiter gefassten Qualitätsmanagements (siehe oben 1-3) und bin der Überzeugung, dass die heute eingeführten Maßnahmen unsere Prozesse ZUSÄTZLICH optimieren.

VG SRK

Mit freundlichen Grüßen
 
Stefan Rank-Kunitz
 - Lead Developer -
________________________________________________________
TraSo GmbH

Georg-Schumann-Str. 294
D-04159 Leipzig
Tel.: +49 341 355 740 - 43

E-Mail: s.rank-kunitz@traso.de
________________________________________________________
Handelsregister: Amtsgericht Leipzig, HRB 21850

Am 27.04.2016 um 11:56 schrieb Viktoras Bezaras:

Hallo Team,

leider sind unsere Meetings Zeitlich sehr limitiert und es ist nicht möglich alle Meinungen zuzuhören. Und ich bin der Meinung, dass die Vorgeschlagene Änderungen in großer Ordnung nichts oder sehr wenig bringen. Bisschen bessere Planung, bisschen bessere Kommunikation, ja schön. Löst das Problem, dass Support überfordet ist nicht.
Für mich ein kritischer Punkt ist: Entwickler müssen die Code Anpassugen selber testen und dann ein Test log schreiben, ansonsten werden die verfolgt. Das Problem an der Stelle ist, dass Teil 1 "selber testen" ist absolut richtig, währen Teil 2 bringt nichts und ist, meiner Meinung nach, schädigend. Ah ja, und löst das Problem immer noch nicht. Man bekommt dadurch nur Stress und Ärger, und den haben wir schon genug in unserem Alltag.
Wir sind 9 Entwickler, Support ist 6 Leute. Wir werden nicht weniger "Ausgabe" produzieren, Support wird immer noch nicht weniger testen müssen. Außer wenn die Idee ist durch noch mehr Jira-Verkehr und nicht-entwicklungs-Aktivitäten den Entwicklern bremsen.
Ich denke, wir müssen unseren Support dadurch unterstützen, dass wir für Support die Tools geben/bauen sollen. Wir selber benutzen gern git und stash, und bamboo, und phpstorm u.s.w. Weil die Tools manche Aufgaben automatisieren. Warum möchten wir denn nicht so viel wie möglich Support Aufgaben automatisieren? Ich selbe nehme die Schritte: Autocheck für Hotels und jetzt Flugcheck, und ich habe schon mit Carsten abgesprochen für ihm auch das gleiche machen. Mit Hotelcheck haben wir schon sehr viel Probleme sehr schnell gefunden. Und das reduziert die Last.
Die Unit-Tests sind auch sehr wichtig, obwohl, das hat direkt nichts mit Support zu tun. Meine erste Aufgabe bei Traso habe ich mir selber angelegt und in den habe ich nur Unit-Tests für MTS geschrieben. Heute sind bis zu 50% der Unit-Tests von mir. Das bedeutet, viele Bugs sind schon beim Testing gefunden, und nicht im Support. Und das reduziert die Last.
Es gibt auch weitere Test Tools, wie z.B. Behat und Selenium. Man kann die Tests für die Oberfläche machen, oder für die bestimmte Funktionalität. Z.B. Test-Fall: neues Hotel im xAdmin anlegen, oder ein Flug löschen. Würden wir 1000 solche Test-Fälle haben, werden wir sicher, dass die Funktionen funktionieren so wie erwartet. Und das ist möglich täglich automatisch prüfen. Und das auch reduziert die Last.
Es gibt noch viele weitere Tools für z.B. Monkey-Testing (das Tools versucht das System kaputt zu machen durch chaotische Angabe), oder auch Monitoring Tools, sodass wir die Probleme schnell finden, bevor die Kunden sich melden.
Ich glaube das ist die Richtung, die wir gehen sollen. Wenn wir natürlich nicht zu Beschäftigt für die Innovationen sind.

Viele Grüße
Viktoras
-- 

Mit freundlichen Grüßen
 
Viktoras Bezaras
 - Entwickler -
________________________________________________________
TraSo GmbH
 
Georg-Schumann-Str. 294
D-04159 Leipzig
Tel.: +49 341 355 740 44
 
E-Mail: v.bezaras@traso.de
Internet: http://www.traso.de
 
________________________________________________________
Geschäftsführer: Haiko Gerdes
Handelsregister: Amtsgericht Leipzig, HRB 21850
_______________________________________________
team mailing list
team@lists.traso.de
https://lists.traso.de/listinfo/team