Projektwerkstatt: Testing Company

Lesetipps

1. Google Testing Blog
2. Projektwerkstatt: Wireframe Checker
3. Projektwerkstatt: Journaling-Proxy

Eigentlich stelle ich ja in der Projektwerkstatt immer Ideen vor für PHP Projekte auf Softwareebene, die ich so als Idee habe, bei denen ich aber weiß, dass ich niemals Zeit finden werde, sie wirklich umzusetzen. Bei vielen Ideen gibt es zwar ein schönes Einsatzgebiet, aber kein wirkliches Geschäftsmodell dahinter. Heute geht es aber gleich um eine Geschäftsidee, ohne ein konkretes Problem.

In der vergangenen Zeit habe ich es immer öfters mit Firmen im PHP Umfeld zu tun gehabt, die sich immer mehr um  Qualität kümmern. Webentwicklung wird als Disziplin immer ernster genommen und viele Unternehmen versuchen immer mehr auf Qualität zu setzen. Finde ich eine sehr sehr gute Sache. Oberflächentests mit Selenium und Unit Testing mit PHPUnit sind wohl die ersten Dinge, die derzeit in Projekten eingeführt werden, wenn es um Qualitätssicherung geht.

Ein großes Problem dabei ist es, eine hohe Testabdeckung zu erzielen, bei Projekten, die schon Jahre lang ihr Dasein gefristet haben. Es kann umheimlich teuer sein, seine Mitarbeiter hinzusetzen, um diese Abdeckung im Nachhinein zu erzielen. Und außerdem sind sie meisten so im operativen Geschäft involviert, das dies kaum möglich ist, ohne ein komplettes Feature Freeze zu machen.

Und genau hier setzt meine Idee an. Wie wäre es, wenn man eine Firma gründet, die den ganzen Tag nichts anderes macht, als Projekte mit Tests abzudecken. Funktionale Tests mit Selenium sollten kein Problem sein. Unit Tests könnten ein wenig komplexer werden, aber sind auch nicht unmöglich. Bei der Selenium Geschichte, bin ich mir sicher, dass es ohne Probleme mit einer Hand voll Studenten klappen könnte, die man einmalig schult und dann für diverse Projekte einsetzen kann. Diesen Service könnte man relativ günstig anbieten, da man hauptsächlich mit günstigen Ressourcen arbeitet und der Schulungsaufwand in diesem Falle nur einmalig wäre und nicht für jede Firma aufs neue zu stemmen ist. Sobald eine gewünschte Testabdeckung, z.B. 80% aller bekannten Use Cases erreicht ist, würde eine Übergabe statt finden und das Projekt wieder nach Hause geholt werden.

Ich kenne einige Firmen, die das ganze nutzen würden. Also falls jemand diese Idee umsetzen will, dann kann er mich ja mit 20% beteiligen. SO als Dankescvhön für die Idee.

Ach ja, wie man mit Unit Testing in dieser Sache umgeht, da bin ich mir auch nicht sicher. Sicherlich wäre hier das erstellen der Testabdeckung kostspieliger, aber kann ja nicht alles so einfach sein.

9 Kommentare »

• 
  

  Michael

  am 23. Juni 2009 um 08:10 Uhr

  Bin dabei

  PS: Wenn man deine Domain ohne “www” eingibt, kommt nichts. Könntest du bei Gelegenheit mal fixen.

• 
  

  LudwigR

  am 23. Juni 2009 um 08:17 Uhr

  Wirklich nette idee, das Frontend über Selenium zu testen halte ich sogar noch für realistisch. Wenn es aber dann darum geht den code selbst mit unittests zu überprüfen wirds heickel. Welche firma gibt schon gern den code aus der hand. (wenn er nicht OSS ist).

  Das wird nur dann funktioniern wenn der externe Dienstleister zugriff auf die Versionsverwaltung hat. Sonst käme es ja auch wieder von dem von dir angesprochenen Feature Freeze.

  Ein anderes Problem ist sicher noch die Qualität der UnitTests. Die kann man ja so und so schreiben. Dh. du brauchst mindestens eine instanz welche die unittests freigibt bevor sie zum kunden zurückgehen.

  Grundlegend wird wohl das problem sein, daß der kunde dir ja sagen muss was getestet werden muss, dh er muss erst mal einen test katalog schreiben. (im normalfall hat man in der zeit den test auch schon geschrieben

  Unterm strich viel arbeit, und wenn man die “Studenten” nicht wirklich preiswert bekommt wohl ziemlich teuer.

  Aber falls das jemand mal anbieten sollte, könnte ich mir gut vorstellen das beim einen oder anderen projekt mal auszulagern.

  my2c
  Ludwig

• 
  

  Nils Langner

  am 23. Juni 2009 um 08:36 Uhr

  @Michael: Bei mir gibt es eine saubere Weiterleitung auf die URI mit www vorne.

  @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.

• 
  

  dodger

  am 23. Juni 2009 um 08:39 Uhr

  Nils,

  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.

• 
  

  Nils Langner

  am 23. Juni 2009 um 08:48 Uhr

  Endlich mal wieder ein Beitrag mit Diskussionspotential.

  @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.

• 
  

  dcdieci

  am 23. Juni 2009 um 10:59 Uhr

  hallo,

  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.

• 
  

  Sebastian Bergmann

  am 23. Juni 2009 um 11:56 Uhr

  Re: “Endlich mal wieder ein Beitrag mit Diskussionspotential.”

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

• 
  

  Nils Langner

  am 23. Juni 2009 um 12:53 Uhr

  @Sebastian Ist natürlich besser, wenn man jemanden hat, der 100% hinter der Idee steht. Ich glaub nicht, dass wir da jemanden finden werden für so eine Diskussion

• 
  

  René Grundner

  am 25. Juni 2009 um 09:50 Uhr

  hoi,

  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é

RSS-Feed für Kommentare zu diesem Artikel. TrackBack-URL

Einen Kommentar hinterlassen