[quote="Schrottie"]
Kurz zur Historie: Das Entwicklersystem auf Imagebasis war früher eine Forderung von Klaus und Oliver, um damit auf dem lokalen Entwicklungsrechner nahezu identische bedingungen zu Server zu schaffen. Identische Bedingungen im Sinne von verendetem OS, PHP-Version, etc. Dies war nötig, da lokal entwickelt, lokal getestet und dann ins Echtsystem eingespielt wurde. Lediglich ein kurzer Test auf Olivers lokalem Entwicklersystem erfolgte vorher. Inzwischen haben wir jedoch ein Testsystem, auf dem alle Commits unter wirklich echten Bedingungen getestet werden können. Damit ist es nicht mehr erforderlich, zu Hause identische Bedingungen vorzuhalten.
[/quote]
Probleme bei dieser Vorgehensweise:
- Die Entwickler können nicht schon während der Entwicklung selbst vollständig testen. Hat man z.B. PHP-Funktionen verwendet, die auf dem Produktivsystem fehlen, fällt das erst spät auf und man muss den Code nachträglich umschreiben.
- Die Entwickler können ihre Änderungen nicht auf dem "kleinen Dienstweg" (Entwicklerbranches austauschen) gegenseitig komplett testen; es geht nur noch zentral.
- Der frühzeitige Test von Änderungen, die noch nicht reif sind zusammengemergt zu werden, ist nicht möglich.
- Es gibt bislang niemanden, den zentralen Test systematisch organisiert / durchführt. Erfahrungsgemäß fallen die wenigsten Bugs während der Testphase auf dem Testserver auf.
Die bei den Entwicklern vorhandenen Testressourcen bleiben also teilweise ungenutzt, stattdessen entsteht mehr Aufwand und Organisationsbedarf an zentraler Stelle. Die Erfahrung mit der OC-Entwicklung zeigt allerdings, dass es an zentralen Stellen immer wieder an Personal und Organisation mangelt, während die Fortschritte auf Eigeninitiativen einzelner Entwickler beruhen. Die Entwickler warten immer wieder darauf, dass jemand ihre Änderungen prüft, einspielt, zum Test oder auf dem Produktivsystem freigibt. Eine weitere Zentralisierung des Tests könnte daher nach hinten losgehen.
Der erste Entwicklungsleiter im Opencaching-Verein (Metrax) hatte wegen dieser Problematik vorgesehen, dass auf dem Testserver für jeden Entwickler eine eigene Testumgebung eingerichtet wird, die er selbst mit seinen Git-Branches befüllen kann ...
Test und Entwicklersystem
-
mbirth
[quote="following"]
- Die Entwickler können nicht schon während der Entwicklung selbst vollständig testen. Hat man z.B. PHP-Funktionen verwendet, die auf dem Produktivsystem fehlen, fällt das erst spät auf und man muss den Code nachträglich umschreiben.
[/quote]
Zwischen z.B. PHP 5.4 und dem aktuell bei uns verwendeten PHP 5.3 gibt es kaum Unterschiede. Den Punkt kann man i.d.R. ignorieren. Es sei denn, ein Entwickler ist wirklich so verpeilt und programmiert PHP 5.6 Code. Dann hat er es aber auch verdient, dass er das Backporten muss.
OTOH darf nicht vergessen werden, dass das Test- und Livesystem auch regelmäßig aktualisiert werden sollte, so dass aktuelle Apache- und PHP-Versionen laufen.
[quote="following"]
- Die Entwickler können ihre Änderungen nicht auf dem "kleinen Dienstweg" (Entwicklerbranches austauschen) gegenseitig komplett testen; es geht nur noch zentral.
[/quote]
Das Entwicklungssystem ist ein Server. Den kann man doch auch ins Internet freigeben? Ansonsten sollte die Entwicklung eigentlich sowieso in einem Git-Branch stattfinden. Den kann der jeweils andere Entwickler lokal auschecken.
[quote="following"]
- Der frühzeitige Test von Änderungen, die noch nicht reif sind zusammengemergt zu werden, ist nicht möglich.
[/quote]
?
[quote="following"]- Es gibt bislang niemanden, den zentralen Test systematisch organisiert / durchführt. Erfahrungsgemäß fallen die wenigsten Bugs während der Testphase auf dem Testserver auf.
[/quote]
Auf lange Sicht sollten auch eher UnitTests (klassisch, aber auch z.B. mit Selenium) gebaut werden, statt dass jemand das von Hand durchklickt. Die kann dann jeder lokal ausführen und sieht (hoffentlich) gleich, ob was klemmt.
[quote="following"]Die bei den Entwicklern vorhandenen Testressourcen bleiben also teilweise ungenutzt, stattdessen entsteht mehr Aufwand und Organisationsbedarf an zentraler Stelle. Die Erfahrung mit der OC-Entwicklung zeigt allerdings, dass es an zentralen Stellen immer wieder an Personal und Organisation mangelt, während die Fortschritte auf Eigeninitiativen einzelner Entwickler beruhen. Die Entwickler warten immer wieder darauf, dass jemand ihre Änderungen prüft, einspielt, zum Test oder auf dem Produktivsystem freigibt. Eine weitere Zentralisierung des Tests könnte daher nach hinten losgehen.
[/quote]
Es sollte aber einen zentralen Tester geben, der genau weiß, worauf er achten muss. Wenn ich was programmiere, teste ich die neue Funktion. Aber ob ich damit irgendein anderes Feature ganz tief versteckt kaputt mache, merke ich dabei eher selten. Insofern ist jemand, der regelmäßig testet und genau weiß, was passieren muss, sehr sinnvoll.
[quote="following"]Der erste Entwicklungsleiter im Opencaching-Verein (Metrax) hatte wegen dieser Problematik vorgesehen, dass auf dem Testserver für jeden Entwickler eine eigene Testumgebung eingerichtet wird, die er selbst mit seinen Git-Branches befüllen kann ...
[/quote]
Wenn das Vagrantfile funktioniert, haben wir genau das - sogar zum Mitnehmen auf eine längere Bahnreise o.ä.. Die Versionen im Vagrantfile sind nah genug an der echten Umgebung dran, dass, wenn es dort läuft, auch auf dem Testserver und Livesystem laufen wird.
Da jetzt ein Fass aufzumachen und den Testserver zur Spielwiese umzubauen ist IMHO etwas zuviel des Guten. Zumal da noch andere Dinge dran hängen, wie z.B. CPU-Last des Servers, Speichernutzung und k.A., ob der Hoster noch Geld für Traffic haben will. Von der Sicherheitsproblematik mal ganz abgesehen.
- Die Entwickler können nicht schon während der Entwicklung selbst vollständig testen. Hat man z.B. PHP-Funktionen verwendet, die auf dem Produktivsystem fehlen, fällt das erst spät auf und man muss den Code nachträglich umschreiben.
[/quote]
Zwischen z.B. PHP 5.4 und dem aktuell bei uns verwendeten PHP 5.3 gibt es kaum Unterschiede. Den Punkt kann man i.d.R. ignorieren. Es sei denn, ein Entwickler ist wirklich so verpeilt und programmiert PHP 5.6 Code. Dann hat er es aber auch verdient, dass er das Backporten muss.
OTOH darf nicht vergessen werden, dass das Test- und Livesystem auch regelmäßig aktualisiert werden sollte, so dass aktuelle Apache- und PHP-Versionen laufen.
[quote="following"]
- Die Entwickler können ihre Änderungen nicht auf dem "kleinen Dienstweg" (Entwicklerbranches austauschen) gegenseitig komplett testen; es geht nur noch zentral.
[/quote]
Das Entwicklungssystem ist ein Server. Den kann man doch auch ins Internet freigeben? Ansonsten sollte die Entwicklung eigentlich sowieso in einem Git-Branch stattfinden. Den kann der jeweils andere Entwickler lokal auschecken.
[quote="following"]
- Der frühzeitige Test von Änderungen, die noch nicht reif sind zusammengemergt zu werden, ist nicht möglich.
[/quote]
?
[quote="following"]- Es gibt bislang niemanden, den zentralen Test systematisch organisiert / durchführt. Erfahrungsgemäß fallen die wenigsten Bugs während der Testphase auf dem Testserver auf.
[/quote]
Auf lange Sicht sollten auch eher UnitTests (klassisch, aber auch z.B. mit Selenium) gebaut werden, statt dass jemand das von Hand durchklickt. Die kann dann jeder lokal ausführen und sieht (hoffentlich) gleich, ob was klemmt.
[quote="following"]Die bei den Entwicklern vorhandenen Testressourcen bleiben also teilweise ungenutzt, stattdessen entsteht mehr Aufwand und Organisationsbedarf an zentraler Stelle. Die Erfahrung mit der OC-Entwicklung zeigt allerdings, dass es an zentralen Stellen immer wieder an Personal und Organisation mangelt, während die Fortschritte auf Eigeninitiativen einzelner Entwickler beruhen. Die Entwickler warten immer wieder darauf, dass jemand ihre Änderungen prüft, einspielt, zum Test oder auf dem Produktivsystem freigibt. Eine weitere Zentralisierung des Tests könnte daher nach hinten losgehen.
[/quote]
Es sollte aber einen zentralen Tester geben, der genau weiß, worauf er achten muss. Wenn ich was programmiere, teste ich die neue Funktion. Aber ob ich damit irgendein anderes Feature ganz tief versteckt kaputt mache, merke ich dabei eher selten. Insofern ist jemand, der regelmäßig testet und genau weiß, was passieren muss, sehr sinnvoll.
[quote="following"]Der erste Entwicklungsleiter im Opencaching-Verein (Metrax) hatte wegen dieser Problematik vorgesehen, dass auf dem Testserver für jeden Entwickler eine eigene Testumgebung eingerichtet wird, die er selbst mit seinen Git-Branches befüllen kann ...
[/quote]
Wenn das Vagrantfile funktioniert, haben wir genau das - sogar zum Mitnehmen auf eine längere Bahnreise o.ä.. Die Versionen im Vagrantfile sind nah genug an der echten Umgebung dran, dass, wenn es dort läuft, auch auf dem Testserver und Livesystem laufen wird.
Da jetzt ein Fass aufzumachen und den Testserver zur Spielwiese umzubauen ist IMHO etwas zuviel des Guten. Zumal da noch andere Dinge dran hängen, wie z.B. CPU-Last des Servers, Speichernutzung und k.A., ob der Hoster noch Geld für Traffic haben will. Von der Sicherheitsproblematik mal ganz abgesehen.
-
following
[quote="mbirth"]
Es sollte aber einen zentralen Tester geben, der genau weiß, worauf er achten muss. Wenn ich was programmiere, teste ich die neue Funktion. Aber ob ich damit irgendein anderes Feature ganz tief versteckt kaputt mache, merke ich dabei eher selten. Insofern ist jemand, der regelmäßig testet und genau weiß, was passieren muss, sehr sinnvoll.
[/quote]
Völlig richtig. Aber aus welchem Hut wollen wir den zaubern? Bei einem Projekt in dieser Größenordnung müsste das schon jemand mit professioneller Erfahrung in der Software-QS sein.
Die personellen Ressourcen von Opencaching.de im Bereich Entwicklung und Technik sind leider sehr beschränkt, trotz aller Aufrufe um Unterstützung. Du hast ja gesehen, dass es sechs Monate dauerte, bis dein Fix der Garmin-API online war, und solche Klemmer gibt es immer wieder mal.
De facto war es bislang so, dass der Test überwiegend am Code Reviewer hängen blieb, oder dass Änderungen mit Mut zur Lücke online gestellt wurden.
Es sollte aber einen zentralen Tester geben, der genau weiß, worauf er achten muss. Wenn ich was programmiere, teste ich die neue Funktion. Aber ob ich damit irgendein anderes Feature ganz tief versteckt kaputt mache, merke ich dabei eher selten. Insofern ist jemand, der regelmäßig testet und genau weiß, was passieren muss, sehr sinnvoll.
[/quote]
Völlig richtig. Aber aus welchem Hut wollen wir den zaubern? Bei einem Projekt in dieser Größenordnung müsste das schon jemand mit professioneller Erfahrung in der Software-QS sein.
Die personellen Ressourcen von Opencaching.de im Bereich Entwicklung und Technik sind leider sehr beschränkt, trotz aller Aufrufe um Unterstützung. Du hast ja gesehen, dass es sechs Monate dauerte, bis dein Fix der Garmin-API online war, und solche Klemmer gibt es immer wieder mal.
De facto war es bislang so, dass der Test überwiegend am Code Reviewer hängen blieb, oder dass Änderungen mit Mut zur Lücke online gestellt wurden.
-
mbirth
[quote="following"]
Völlig richtig. Aber aus welchem Hut wollen wir den zaubern? Bei einem Projekt in dieser Größenordnung müsste das schon jemand mit professioneller Erfahrung in der Software-QS sein.
[/quote]
Najaaaaa, so hoch würde ich nicht greifen. Wir sind kein Großunternehmen, was Aktionäre zufriedenstellen muss und sich keinerlei Fauxpas leisten darf. Als Tester wäre schon jemand geeignet, der die Webseite und das Verhalten so kennt, wie Mic@ die ganzen Informationsquellen.
Der Tester soll ja nur Feedback liefern, ob alles noch funktioniert, wie es soll. Das Fixing macht dann der Entwickler wieder.
Das Problem mit den Monaten Dauer war hauptsächlich auch, dass ich noch keinen Zugang zu allen nötigen Systemen habe und auch die Prozesse nicht genau kenne. Sonst hätte ich das nach dem "okay, funktioniert" von den verschiedenen Leuten auch selbst produktiv stellen können.
Wenn mich da mal jemand versorgen würde, kann ich natürlich auch fremde Änderungen übernehmen. Ich hab zwar auch nicht immer Zeit, aber Monate wird's bei mir nicht dauern - und das meine ich jetzt nicht als Kritik. Außerdem könnte ich dann auch mal im Ernstfall auf dem Server schauen, was los ist. (Wer ist eigentlich Technikbeauftragter, also hat das letzte Wort in Sachen Serverkonfiguration, Zugänge, etc.?)
Völlig richtig. Aber aus welchem Hut wollen wir den zaubern? Bei einem Projekt in dieser Größenordnung müsste das schon jemand mit professioneller Erfahrung in der Software-QS sein.
[/quote]
Najaaaaa, so hoch würde ich nicht greifen. Wir sind kein Großunternehmen, was Aktionäre zufriedenstellen muss und sich keinerlei Fauxpas leisten darf. Als Tester wäre schon jemand geeignet, der die Webseite und das Verhalten so kennt, wie Mic@ die ganzen Informationsquellen.
Der Tester soll ja nur Feedback liefern, ob alles noch funktioniert, wie es soll. Das Fixing macht dann der Entwickler wieder.
Das Problem mit den Monaten Dauer war hauptsächlich auch, dass ich noch keinen Zugang zu allen nötigen Systemen habe und auch die Prozesse nicht genau kenne. Sonst hätte ich das nach dem "okay, funktioniert" von den verschiedenen Leuten auch selbst produktiv stellen können.
Wenn mich da mal jemand versorgen würde, kann ich natürlich auch fremde Änderungen übernehmen. Ich hab zwar auch nicht immer Zeit, aber Monate wird's bei mir nicht dauern - und das meine ich jetzt nicht als Kritik. Außerdem könnte ich dann auch mal im Ernstfall auf dem Server schauen, was los ist. (Wer ist eigentlich Technikbeauftragter, also hat das letzte Wort in Sachen Serverkonfiguration, Zugänge, etc.?)
-
dl6hbo
[quote="mbirth"]
(Wer ist eigentlich Technikbeauftragter, also hat das letzte Wort in Sachen Serverkonfiguration, Zugänge, etc.?)
[/quote]
Nils (aka bohrsty) und ich als "Backup".
(Wer ist eigentlich Technikbeauftragter, also hat das letzte Wort in Sachen Serverkonfiguration, Zugänge, etc.?)
[/quote]
Nils (aka bohrsty) und ich als "Backup".
-
following
Wie gesagt - meine Erfahrung mit dem OC-Test ist, dass er nur bruchstückweise funktioniert. Es gab mal jemanden, der sich darum kümmern wollte, aber der war nach ein paar Wochen wieder verschwunden.
[quote="mbirth"]
Das Problem mit den Monaten Dauer war hauptsächlich auch, dass ich noch keinen Zugang zu allen nötigen Systemen habe und auch die Prozesse nicht genau kenne. [/quote]
Die Prozesse sind im internen Teamwiki dokumentiert.
[quote="mbirth"]
Das Problem mit den Monaten Dauer war hauptsächlich auch, dass ich noch keinen Zugang zu allen nötigen Systemen habe und auch die Prozesse nicht genau kenne. [/quote]
Die Prozesse sind im internen Teamwiki dokumentiert.
-
Siggiiiiii
- Micro
- Beiträge: 201
- Registriert: 04.06.2015, 16:46
Gibt's eine TestSpec für einen Regressiontest bzw. ist da was automatisiert?
[quote="Siggiiiiii"]
Gibt's eine TestSpec für einen Regressiontest bzw. ist da was automatisiert?
[/quote]
Hallo Siggiiii, eine automatisierte Testsuite o. ä. gibt es aktuell nicht, das wäre m. E. auch übertrieben. Kleinere Änderungen werden direkt von unserer Entwicklung getestet, größere Features auch schon mal auf einem internen Testsystem.
Darf ich in deine Frage ein gewisses Interesse zur Mitarbeit hinein interpretieren?
Gibt's eine TestSpec für einen Regressiontest bzw. ist da was automatisiert?
[/quote]
Hallo Siggiiii, eine automatisierte Testsuite o. ä. gibt es aktuell nicht, das wäre m. E. auch übertrieben. Kleinere Änderungen werden direkt von unserer Entwicklung getestet, größere Features auch schon mal auf einem internen Testsystem.
Darf ich in deine Frage ein gewisses Interesse zur Mitarbeit hinein interpretieren?
-
Siggiiiiii
- Micro
- Beiträge: 201
- Registriert: 04.06.2015, 16:46
[quote="mambofive"]
[quote="Siggiiiiii"]
Gibt's eine TestSpec für einen Regressiontest bzw. ist da was automatisiert?
[/quote]
Hallo Siggiiii, eine automatisierte Testsuite o. ä. gibt es aktuell nicht, das wäre m. E. auch übertrieben. Kleinere Änderungen werden direkt von unserer Entwicklung getestet, größere Features auch schon mal auf einem internen Testsystem.
Darf ich in deine Frage ein gewisses Interesse zur Mitarbeit hinein interpretieren?
[/quote]
Das hört sich nach recht isolierten Komponenten an, wo an anderen Komponenten bei Änderungen nicht viel kaputt gemacht werden kann.
Hab momentan keine Zeit, mich in ein neues SW-Projekt einzuarbeiten. Da müsste ich die Funktionen von OC auch viel intensiver nutzen, um die Web-Strukturen und Funktionen zu verstehen. Außerdem ist das Bottleneck ja eher nicht der Test, wenn ich mir Redmine so angucke. Da stecken ja noch etliche Personenmonate Entwicklung drinne.
[quote="Siggiiiiii"]
Gibt's eine TestSpec für einen Regressiontest bzw. ist da was automatisiert?
[/quote]
Hallo Siggiiii, eine automatisierte Testsuite o. ä. gibt es aktuell nicht, das wäre m. E. auch übertrieben. Kleinere Änderungen werden direkt von unserer Entwicklung getestet, größere Features auch schon mal auf einem internen Testsystem.
Darf ich in deine Frage ein gewisses Interesse zur Mitarbeit hinein interpretieren?
[/quote]
Das hört sich nach recht isolierten Komponenten an, wo an anderen Komponenten bei Änderungen nicht viel kaputt gemacht werden kann.
Hab momentan keine Zeit, mich in ein neues SW-Projekt einzuarbeiten. Da müsste ich die Funktionen von OC auch viel intensiver nutzen, um die Web-Strukturen und Funktionen zu verstehen. Außerdem ist das Bottleneck ja eher nicht der Test, wenn ich mir Redmine so angucke. Da stecken ja noch etliche Personenmonate Entwicklung drinne.
Zuletzt geändert von Siggiiiiii am 28.06.2015, 16:33, insgesamt 1-mal geändert.