Also sprach steppenhund am Dienstag, 7. Oktober 2008, 17:14 wie folgt:
Ich kenne dieses Horror-Szenario sehr gut. In einem größeren Rahmen erkläre ich den Leuten auch, warum Testen ein spezieller Job ist und ein spezielles Mindset benötigt.
Dass ein Entwickler sich selbst oder die Arbeit eines anderen Entwicklers testet, kann nie so effizient sein, wie es ein Testspezialist schafft. Das hat nach meiner Auffassung damit zu tun, dass die Denkweise des Entwicklers "produktiv" und lösungsorientiert ist während der Tester eine destruktive Kreativität entwickelt.
Deswegen kann man auch nicht "irgendjemanden" zum Testen nehmen.
Diese Aussage, die bei Militärflugzeugen oder der Formel-1, sowie bei medizinischen Überprüfungen kaum einer Argumentation bedarf, scheint in der Software-Industrie jedesmal einen großen Aha-Effekt zu bewirken.
Was so ziemlich zu beweisen scheint, dass die in der IT alle spinnen. Denn zu kapieren sollte das ja nicht so schwer sein.
In der Theorie hast du Recht. In der Praxis hat unser Team zuwenig "Wissende", die nach einen Test auf Richtig/Falsch entscheiden können. Wir haben auch zu wenig Budget um uns einen eigenen Tester leisten zu können.
Nein, wir sind kein IKEA... wir machen wie ein Tischler maßgeschneiderte und einmalige Sonderanfertigungen... ganz genauso wie es der Kunde braucht und möchte. Da findet der Reifungsprozeß während der Testphase statt.
@p2
Die Kleinheit eines Teams kann schon dazu führen, dass das Team selbst sich keinen Tester leisten kann.
Das Argument mit den "Wissenden" hält nicht, das erlebe ich tagtäglich bei Banken und anderen Großbetrieben, wo der Fachbereich meint, er kann das "Wissen" nicht ausreichend weitergeben, damit der Tester ausreichend versorgt ist.
Manchmal reicht es bereits, wenn der "Wissende" versucht, einen Testfall zu beschreiben, um die ersten Fehler zu finden. Aus einem fachlichen Testfall heraus findet der gute Tester noch einen ganze Reihe anderer Tests, an die weder der Fachbereich noch der Entwickler testet.
Und Theorie ist es nicht:)
Schau einmal auf www.isqi.org. Da geht es auch um Test-Zertifizierungen. Zufälligerweise habe ich bei der letzten Konferenz den Best-Paper-Award bekommen:)
Und da geht es um ein ganz banales aber schweres Beispiel der Testautomation!
Wir haben Entwickler die von dem Customizing nicht viel wissen und Organisatoren, die sich in der Programmierung kaum auskennen. Und die beiden müssen zusammen testen. Das ist keine so schlechte Kombination... der Organisator testet die betriebswirtschaftlich sinnvollen Standardfälle und der Entwickler die logisch-theoretisch möglichen Fälle.
Das ist eh der normale Wahnsinn.
Wobei das Wort "Customizing" ja mittlerweile einen besonderen Reiz gewonnen hat.
Was "gecustomized" wird, muss man doch nicht testen. Das sind ja "nur" Einstellungen.
Aber wir haben immerhin vier Tester bei einer Versicherung, die "gecustomizte" Software einsetzt:) hihihi
am Dienstag, 7. Oktober 2008, 17:14 wie folgt:
Dass ein Entwickler sich selbst oder die Arbeit eines anderen Entwicklers testet, kann nie so effizient sein, wie es ein Testspezialist schafft. Das hat nach meiner Auffassung damit zu tun, dass die Denkweise des Entwicklers "produktiv" und lösungsorientiert ist während der Tester eine destruktive Kreativität entwickelt.
Deswegen kann man auch nicht "irgendjemanden" zum Testen nehmen.
Diese Aussage, die bei Militärflugzeugen oder der Formel-1, sowie bei medizinischen Überprüfungen kaum einer Argumentation bedarf, scheint in der Software-Industrie jedesmal einen großen Aha-Effekt zu bewirken.
Was so ziemlich zu beweisen scheint, dass die in der IT alle spinnen. Denn zu kapieren sollte das ja nicht so schwer sein.
In der Theorie hast du Recht. In der Praxis hat unser Team zuwenig "Wissende", die nach einen Test auf Richtig/Falsch entscheiden können. Wir haben auch zu wenig Budget um uns einen eigenen Tester leisten zu können.
@theswiss
Yes... am Anfang ist es so.
@gulo²
Nein, wir sind kein IKEA... wir machen wie ein Tischler maßgeschneiderte und einmalige Sonderanfertigungen... ganz genauso wie es der Kunde braucht und möchte. Da findet der Reifungsprozeß während der Testphase statt.
Die Kleinheit eines Teams kann schon dazu führen, dass das Team selbst sich keinen Tester leisten kann.
Das Argument mit den "Wissenden" hält nicht, das erlebe ich tagtäglich bei Banken und anderen Großbetrieben, wo der Fachbereich meint, er kann das "Wissen" nicht ausreichend weitergeben, damit der Tester ausreichend versorgt ist.
Manchmal reicht es bereits, wenn der "Wissende" versucht, einen Testfall zu beschreiben, um die ersten Fehler zu finden. Aus einem fachlichen Testfall heraus findet der gute Tester noch einen ganze Reihe anderer Tests, an die weder der Fachbereich noch der Entwickler testet.
Und Theorie ist es nicht:)
Schau einmal auf www.isqi.org. Da geht es auch um Test-Zertifizierungen. Zufälligerweise habe ich bei der letzten Konferenz den Best-Paper-Award bekommen:)
Und da geht es um ein ganz banales aber schweres Beispiel der Testautomation!
@steppenhund
Wir haben Entwickler die von dem Customizing nicht viel wissen und Organisatoren, die sich in der Programmierung kaum auskennen. Und die beiden müssen zusammen testen. Das ist keine so schlechte Kombination... der Organisator testet die betriebswirtschaftlich sinnvollen Standardfälle und der Entwickler die logisch-theoretisch möglichen Fälle.
Wobei das Wort "Customizing" ja mittlerweile einen besonderen Reiz gewonnen hat.
Was "gecustomized" wird, muss man doch nicht testen. Das sind ja "nur" Einstellungen.
Aber wir haben immerhin vier Tester bei einer Versicherung, die "gecustomizte" Software einsetzt:) hihihi