Ich beschäftige mich schon seit längerer Zeit mit diesem Problem.

Ich arbeite momentan noch in einer Firma, die vor genau diesem Problem steht, welches Nils angesprochen hat. Allerdings im klassischen Client/Server-Bereich.

Die Idee so einen Service anzubieten kam mir auch schon vor geraumer Zeit.

Allerdings müsste man viel früher ansetzen, da der erzielte Effekt nur von kurzer Dauer ist.

Folgendes Szenario: Eine Firma lässt die komplette Bandbreite über Ihr bestehendes Projekt laufen.
Oberflächentests, UnitTesting (mit grossen Refakturierungen mit Hilfe von 1-2 Mitarbeitern die an dem Projekt schon gearbeitet haben) und manuelle Tests zum Abschluss.

Alles läuft gut, alle zufrieden.

Aber was passiert?

Es wird weiter gearbeitet. Neue Features kommen hinzu. Aber die Unit-Tests liegen brach, Oberflächentests werden nicht erweitert und testen nur das was schon da war.

Man müsste die Firma viel stärker einbinden. Die Entwickler schulen, Ihnen zeigen wie umgebaut oder programmiert werden müsste, damit Unit-Testing geht. Das man Tests zuerst schreibt. Das auch Tests Fehler haben können. (OT: Das sie Clean Code lesen sollten

Das auch eine QA-Abteilung geschult werden muss. Bessere Fehlerbeschreibungen, Feature- und Bug-Tracking, vorbereiten von Test-Cases.

Man müsste ein Gesamtpaket verkaufen, nicht nur den Test.

just my 2 cents

René

Eigentlich will man doch mal eine Podiumsdiskussion zu diesem Thema auf der PHP Unconference oä. haben, oder?

ich halte die idee für sehr nützlich und auch für erfolgsversprechend, doch die Umsetzung halte ich für kritisch, denn
1. wollen die Firmen Extern wirklich den Code zugänglich machen?
2. wenn für solch einen Service gezahlt werden muss, erwarten die Kunden Garantien. Doch wer übernimmt diese am Ende, wenn die Applikation an einer Stelle zickt?

Gerade Unit Tests outzusourcen halte ich für wahnsinnig lukrativ, da viele Firmen diesen Aufwand nicht zu ihrem Kerngeschäft zählen, aber sich der Notwendigkeit solcher Tests nicht entziehen können.

@Dodger: Wie gesagt. Unit Tests nehme ich raus, da bin ich mir auch sicher, dass es nicht unbedingt klappen kann. Aber die ganze Selenium Geschichte kann doch (vielleicht) nach extern verlagert werden.
Sobald man keinen stabilen Wireframe mit IDs hat, wird es natürlich recht komplex bei Änderungen, da gebe ich dir Recht. Aber diese Komplexität habe ich doch auch, wenn ich es intern mache. Und die hohe Testabdeckung, die ich beschrieben habe, soll natürlich eine hohe Testabdeckung von Tests sein, die Sinn machen.
Aber vielleicht habt ihr ja auch Recht und das ganze geht nicht. Deswegen habe ich es ja auch hier vorgestellt und nicht gleich ein Gewerbe angemeldet.
PS: Aber überzeugt bin ich noch nicht wirklich.

sorry – das ist keine gute Idee.

#1: Selenium Tests müssen unter allen Umständen minimiert werden und wo möglich durch andere Tests ersetzt werden da sie schlicht zu langsam sind. Eine volle Abdeckung führt locker zu Test Laufzeiten von 24 Stunden und mehr und macht dergestalt die Tests für die Entwicklung nicht nutzbar. Von der Update Prozedur will ich gar nicht reden (was passiert bei GUI Änderungen wenn der Kunde nicht eindeutige ID’s einsetzt – und wer macht das schon?)

#2: UnitTests von externen? Welche Software ist denn bitteschön so entwickelt das du einfach UnitTests schreiben kannst ohne massiv zu refactoren? Das halte ich für komplett unrealistisch.

Insofern – nette Idee – aber nicht durchführbar.

Just my 2cents.

@Ludwig: Aus dem Grund habe ich auch Unit Testing ein wenig aus der Idee rausgenommen. Den testplan muss man aber schreiben, auch wenn man die Tests intern macht. Den schreiben aber auch meist nicht die Entwickler. So kann man dir Arbeit dann aufteilen.