Software Tester, Zukunftssicher ?!

[Rabber]

30 Euro Stundensatz in Rechnung für eine IT finde ich ebenfalls mager.
Als Stundenlohn für den Mitarbeiter ist es wieder zu hoch angesetzt.
Von daher verwirren diese Zahlen auch mich.

[L-1011-500]

• Ich habe hier einen Freelance in meinem Team der als funktionaler Black-Box Softwaretester (günstige) 72,50€ + MwSt / Stunde auf die Rechung schreibt.
• In Richtung Agil mit Schwerpunkt Testautomatisierung steigen die Preise für einen Tester um ~15€ / Std.
• Testmanager (die wir hier nicht als externe haben) sind aber bereits im 3-stelligen Bereich unterwegs.
• Beraterfimen, die Ihre Leute aus welchem Grund auch immer hier her senden, erhalten meist ein Fixum / Monat und werden nicht auf Stundenbasis abgerechnet

Bearbeitet 27. November 2017 von L-1011-500

[L-1011-500]

Ich habe im übrigen soeben die Zertifizierung zum  iSQI CAT Certified Agile Tester hinter mich gebracht. Aus den Gesprächen mit den anderen Lehrgangsteilnehmern wurde gundsätzlich deutlich, das ich mit meiner Einschätzung gar nicht so falsch liege:

• Während bei mir (als Testmanager) die Aufgaben seit Jahren in etwa gleich geblieben sind, wird von Softwaretestern im Rahmen der  agilen Vorgehensmodelle immer mehr Entwicklungs-Know-How für Testautomatisierungsaufgaben gefordert.

Das die Entwickler ungleich mehr Euros erhalten als die Softwaretester kann ich aber nicht bestätigen. Da gibt es ja auch einen aktuellen Gehaltsreport in den man diesbezüglich einmal reinschnuppern kann.

Bearbeitet 27. November 2017 von L-1011-500

[Whiz-zarD]

vor 4 Minuten schrieb L-1011-500:

• Während bei mir (als Testmanager) die Aufgaben seit Jahren in etwa gleich geblieben sind, wird von Softwaretestern im Rahmen der  agilen Vorgehensmodelle immer mehr Entwicklungs-Know-How für Testautomatisierungsaufgaben gefordert.

Dieser Trend ist auch eine logische Konsequenz aus den Versäumnissen vieler Firmen. Dir wird ja wohl auch die Testpyramide bekannt sein. In den meisten Firmen steht sie aber auf dem Kopf, d.h. wenig Unittests und viele Integrationstests, die durch UI-Tests abgedeckt werden. Das macht die Tests aber sehr instabil und sehr zeitaufwendig. Also will man nun die Pyramide wieder richtig hinstellen und nun braucht man Unittest-Know-How.

[Gast Arvi]

vor 17 Stunden schrieb L-1011-500:

Das die Entwickler ungleich mehr Euros erhalten als die Softwaretester kann ich aber nicht bestätigen. Da gibt es ja auch einen aktuellen Gehaltsreport in den man diesbezüglich einmal reinschnuppern kann.

Ich habe schon in einigen Softwarefirmen gearbeitet und die Softwaretester haben als Angestellte prinzipiell immer weniger verdient als die Entwickler. Mag sein, dass sich das in Gehaltsvergleichen  durch sehr gut verdienende Berater/Consulting Firmen wieder ausgleicht. In meiner aktuellen Firma liegen die Einstiegsgehälter auch im Schnitt für Softwaretester 400€ unter dem eines regulären Entwicklers. Einstiegsgehalt für einen Entwickler (FH oder Uni) ca. 42.000€/Brutto und für einen Softwaretester ca. 38000€/Brutto.

Ich kenne es nicht anders.

[L-1011-500]

Zitat

Dieser Trend ist auch eine logische Konsequenz aus den Versäumnissen vieler Firmen. Dir wird ja wohl auch die Testpyramide bekannt sein. In den meisten Firmen steht sie aber auf dem Kopf, d.h. wenig Unittests und viele Integrationstests, die durch UI-Tests abgedeckt werden. Das macht die Tests aber sehr instabil und sehr zeitaufwendig. Also will man nun die Pyramide wieder richtig hinstellen und nun braucht man Unittest-Know-How.

Es liegt wohl eher an dem Wechsel vom klassischen zum agilen Projektvorgehen.

Der Softwaretester mit dem Fokus auf die manuelle Testdurchführung hat im agilen Team so gut wie keine Chance schnell ein Feedback zur Qualität zu geben. Hier muss vorrangig eine schnelle Reaktion auf Änderungen, die durch kurze Iterationen ermöglicht wird, erfolgen. Das bedarf einer Testautomatisierung und die funktioniert ohne Entwicklungskenntisse nicht (Record and Playback funktioniert nicht!)

[Whiz-zarD]

vor 41 Minuten schrieb L-1011-500:

Es liegt wohl eher an dem Wechsel vom klassischen zum agilen Projektvorgehen.

Auch im klassischen Wasserfall-Modell wird es immer wichtiger Tests zu automatisieren bzw. Unittests einzuführen, weil Software immer komplexer und umfangreicher wird, sodass man sie eben nicht mehr mit einem Testteam manuell testen kann. Auch hier ist es wichtig, dass ein Entwickler schnelles Feedback erhält. Vor allem wenn man Refactoring betreiben möchte, ist dies äußerst wichtig, denn man möchte nicht erst mal drei Wochen warten, bis ein Tester (oder im schlimmsten Fall der Kunde) einen Fehler/Seiteneffekt findet. Wenn man z.B. Refactoring mittels der Mikado-Technik betreiben möchte, sind Unittests/automatische Tests sogar unabdingbar.

[L-1011-500]

Im V-Model obliegen Komponenten- und Integrationstest der Entwicklung und nicht dem Test(er). Für den funktionalen System- und Abnahmetest (den Bereich den der Tester betreut) spielt eine Testautomatisierung keine oder kaum eine Rolle. Maximal kann man sich in diesem Kontext über eine Testautomatisierung im Regressionstest-Bereich unterhalten. Aber auch das ist, im klassischen Projektgeschäft, Entwicklungstätigkeit.

Hier liegt eben der deutliche Unterschied zu agilen Teams die eben nicht mit dieser Trennung arbeiten. Hier ist der Tester Teil des (Entwicklungs)Teams und betreibt die Automatisierung zu einem grossen Teil selbst. Das ist ein Punkt, weshalb sich das Anforderungsprofil des Testers Richtung Entwicklungs Know-How verschiebt.

Bearbeitet 28. November 2017 von L-1011-500

[L-1011-500]

Update: bin nach 18 Jahren Vollzeittester raus aus dem Testen.

Es ist und bleibt immer dasselbe ... erst will man (die GF) Testen, dann wird getestet ("oh .. das kostet Geld und verzögert mein Projekt") und dann wird alles in Frage gestellt. Das Aufdecken von Abweichungen während der Testphase wird fast immer als persönliche Kritik aufgefasst. Testen wird oft als destruktive Tätigkeit und nicht als Chance angesehen.

Du kannst Abweichungen aller Art noch so positiv kommunizieren: Es führt immer wieder zu Schwierigkeiten zwischen Testern, Entwicklern, Analysten, Projektleitern, Geschäftsführern ...

Immer wieder "Testen macht unser Projekt schlecht." Insbesondere in großen Projekten, in denen es verschiedene Teil-Projektleiter gibt, kommt oft an einem bestimmten Punkt des Projektfortschrittes die schlechte Nachricht vom Testmanagement. Während alle anderen Teilprojekt-Leiter GRÜN melden, verkünde ich als Testmanager berechtigterweise (!) in Bezug auf den vorgesehene Fertigstellungstermin ROT. Und dann ist man als Testmanager wieder mal der doof, weil der Überbringer dieser Nachricht auch als Verursacher des Problems angesehen wird.

Den Kampf kannst Du nicht gewinnen und wenn Du Dich noch so sehr anstrengst. Das zermürbt unendlich. Mich beruhigt nur immer wieder das das alles an der Rolle hing und nicht an meiner Person. Fast alle Testmanager berichten nämlich in ähnlicher Form wie ich.

Bin jetzt seit 4 Monaten Richtung Projektmanagement und Bereitstellung von kundenspezifischen System unterwegs. Das macht mir unendlich mehr Spaß und man erfährt manchmal sogar so etwas wie Wertschätzung.

Bearbeitet 26. April 2019 von L-1011-500

[pr0gg3r]

vor 4 Stunden schrieb L-1011-500:

Es ist und bleibt immer dasselbe ... erst will man (die GF) Testen, dann wird getestet ("oh .. das kostet Geld und verzögert mein Projekt")

 

"The growing cost of fixing bugs. The longer you wait, the more you’ll pay."

(Quelle: http://www.developertesting.com/archives/month200501/20050127-TheDeveloperTestingParadox.html)

 

[L-1011-500]

Solche Statistiken kannst Du jeder Rolle im Projekt zigmal erklären. Du kannst sogar alle Projektmitarbeiter zum ISTQB Certified Tester schulen und diese danach zertifizieren lassen.

Die meisten erkennen Testen nicht als Chance. Die wollen das nicht erkennen. Und ich wollte das auch nicht mehr ständig erklären.

Bearbeitet 29. April 2019 von L-1011-500

[tTt]

@L-1011-500

Ich finde deine Infos gerade sehr spannend, weil ich merke, dass das EAM dir dabei unter die Arme greifen kann.

Sofern das EAM bei der Entwicklung Hand in Hand geht, dürfte sich auch der Testaufwand reduzieren und damit auch die Kosten für die QS. 

Berücksichtigen die SW-Entwickler eine SW-Architektur-Philosophie, sinkt dadurch auch automatisch der Testaufwand, da EAM üblicherweise Anforderungen an die Modularität und Wartbarkeit der Software und Services stellt.

Ich bin zwar noch nicht lange in dem Bereich, aber bei uns sind QS/SW-Testing und EAM in der gleichen Abteilung angesiedelt - zurecht, wenn ich das hier so lese.

Vielleicht solltest du mal Ausschau nach Unternehmen halten, die EAM konsequent umsetzen und Architektonische Designprinzipen vorgeben. Dann dürfte QS/Testing auch wesentlich leichter fallen bzw. schneller sein, da Fehler leichter entdeckt werden können (Wenn das EAM die richtigen Designprinzipen vorgibt).

Vielleicht solltest du mit dem Backround auch in das EAM einsteigen. Deine persönlichen  Erfahrungen sind dabei von enormen Wert. 

[L-1011-500]

Enterprise Application Management hat aus meiner Sicht nichts mit der von mir geschilderten Situation zu tun

[tTt]

Da die Übergänge zwischen IT-Architektur und Testmanagement fließend sind, kann ich deiner Einschätzung leider nicht zustimmen.

Gibt man den Entwicklern die richtigen Impulse fürs Testing, habt ihr im Testmanagement deutlich weniger Arbeit.

Dabei unterstützt euch das EAM (Enterprise Architektur Management), welches Programmier- und Designrichtlinien definiert, die verpflichtend von den Entwicklern umzusetzen sind.

Für euch im Testmanagement springen dann z.B. einzelne Modultests heraus, die euch im Testing helfen. Bereits getestete Module sind von euch auch nicht mehr zu testen. Für euch sinkt dann der Aufwand.

Das geht halt Hand in Hand, sofern sich die Entwickler daran auch halten und das Testing fördern.

[thereisnospace]

vor 2 Stunden schrieb tTt:

Da die Übergänge zwischen IT-Architektur und Testmanagement fließend sind, kann ich deiner Einschätzung leider nicht zustimmen.

Das verstehe ich nicht ganz. Was genau hat das Testmanagement mit der IT-Architektur zu tun? Das Testmanagement sollte die Architektur kennen, weitere Zusammenhänge erschließen sich mir hier nicht.

vor 2 Stunden schrieb tTt:

Gibt man den Entwicklern die richtigen Impulse fürs Testing, habt ihr im Testmanagement deutlich weniger Arbeit.

Dabei unterstützt euch das EAM (Enterprise Architektur Management), welches Programmier- und Designrichtlinien definiert, die verpflichtend von den Entwicklern umzusetzen sind.

Für euch im Testmanagement springen dann z.B. einzelne Modultests heraus, die euch im Testing helfen. Bereits getestete Module sind von euch auch nicht mehr zu testen. Für euch sinkt dann der Aufwand.

Das geht halt Hand in Hand, sofern sich die Entwickler daran auch halten und das Testing fördern.

Das kann ich leider nicht so unterschreiben.

Nicht umsonst schreibt die ISTQB eine Rollentrennung zwischen Test und Entwicklung vor. Der Grund ist recht simpel. Die Entwickler tendieren dazu ihren Code zu testen und ihre Tests dem Code entsprechend anzupassen. Außerdem wird von Entwicklern das Testen auch eher als lästige Nebentätigkeit angesehen. Zu oft ist es hier schon vorgekommen, dass unvollständig und an der Anforderung vorbei getestet wird. Als Testmanager habe ich die Aufgabe, sicherzustellen, dass die Software auf ihre Vollständigkeit und Richtigkeit überprüft ist. Deshalb unterscheidet man hier auch deutlich zwischen Entwickler- und Integrationstest und dem System- bzw. Abnahmetest. Während die ersten zwei Teststufen meist eigenständig von der Entwicklung durchlaufen werden, wird der System- und Abnahmetest eher durch die separate Rolle des Testteams durchgeführt (Aufpassen, die Übergänge sind hier teilweise fließend, gerade auf den Testebenen Komponenten-/Integrationtest. Im agilen Umfeld kommt es auch öfter vor, dass der Agile Tester Unit-Tests schreibt.). Das Testmanagement steht natürlich der Entwicklung unterstützend auf den unteren Testebenen zur Verfügung.

Hier erstellt man anhand der Anwendungsfälle (Feinspezifikation/Lastenheft/Anforderungskatalog) die Testfälle. Das bereits getestete Module nicht mehr angerührt werden, ist ein großer Irrtum. Es wird die gesamte Software vollständig erneut überprüft. Gerade die Geschäftsprozesse können schwer von der Entwicklung abgebildet und getestet werden. Und diese sind letztendlich entscheidend für die Abnahme vom Kunden.

Das EAM, welches die Programmier- und Designrichtlinien definiert, unterstützt somit größtenteils nur bei den unteren Testebenen.

Die Kritikpunkte die @L-1011-500 hier erwähnt hat, kenne ich zur Genüge. Unsere Lösung im Unternehmen ist das Testen eine optionale, interne Dienstleistung ist. Somit müssen wir eigenständig von der jeweiligen Projektleitung/Projektteam gebucht werden. Hier kommt es dann auch nicht mehr zum "Testen kostet nur Geld und bringt nichts", wenn die Leistung freiwillig gebucht wurde. Da unsere Arbeit sich mittlerweile fest im Unternehmen etabliert hat, wird das Testen aber nicht mehr als lästig, sondern als hilfreich angesehen.

Das andere Problem bezüglich der Termineinhaltung und der roten Ampel ist aber auch bei uns allgegenwärtig und dafür wurde bisher auch noch keine Lösung gefunden. Immer ist der Testmanager der "Böse", wegen der Meldung, dass die Software aus Sicht des Testmanagement so nicht freigegeben wird. Dass durch das Entdecken der Fehler im Nachhinein viele Kosten gespart werden können, ist aber noch lange nicht im Bewusstsein der Mitarbeiter verankert. Ich merke aber auch, dass das Testen immer mehr als wichtige und notwendige Aktivität im Projekt angesehen wird und hoffe somit auch auf mittelfristige Besserung. Momentan ist es aber tatsächlich ziemlich anstrengend.

Bearbeitet 11. Mai 2019 von Gottlike
typo