Hallo liebes Forum, seit einiger Zeit beschäftige ich mich mit dem Berufsbild des Software-Testers. Besonders interessiert mich hierbei, welche Abzweige man in diesem Berufsbild gehen kann und wie die Gehaltsentwicklung in den verschiedenen Bereichen ist. Laut ISTQB startet man mit dem Foundationlevel, kann verschiedene Spezialisierungen erwerben (z.B. Last- und Performancetester, Testautomatisierung, ...) oder sich auf das advanced level konzentrieren. Dazu zählen Test Analyst, Technical Test Analyst oder auch Test Manager. Gibt es hier Software-Tester in oben genannten Rollen? Wie zukunftssicher ist der Job (vor dem Hintergrund KI)? Wie realitätsnah ist ISTQB wirklich? Wie sieht euer Arbeitsalltag aus? Wie seid ihr zum Testen gekommen, wo wollt ihr noch hin? Habe ich bei gleicher Ausgangslage (z.B. Studium Informatik) gleiche Gehaltsaussichten, wie wenn ich programmieren würde? Ich freue mich auf eure Erfahrungen, Meinungen und Antworten!
Peter H. schrieb: > Wie zukunftssicher ist der Job (vor dem Hintergrund KI)? KI ist das eine, Verlagerung nach Osteuropa, Nordafrika, Indien das andere. > Habe ich bei gleicher Ausgangslage (z.B. Studium Informatik) gleiche > Gehaltsaussichten, wie wenn ich programmieren würde? Wenn das Deine beiden Optionen sind: wahrscheinlich ja. Aber dann brauchst Du ein Krisen-, KI- und Offshoring-festes Nischenthema (Rüstung? Public Sector mit besonderen Anforderungen an Daten- oder Geheimschutz?), sonst sind es keine guten Aussichten.
:
Bearbeitet durch User
Peter H. schrieb: > Habe ich bei gleicher Ausgangslage (z.B. Studium Informatik) gleiche > Gehaltsaussichten, wie wenn ich programmieren würde? Nein. Bei uns war Softwaretester immer der mieseste Job. Ist ja kein Wunder, das sind arbeitslose Gamer. Entwicklung und programmieren erfordert Kreativität. Software-Architekt wurde entsprechend gut bezahlt. Aber am besten verdienen aber immer noch die Chefs. Die wirklich hilfreichen Tests machen Softwaretester sowieso nicht. Dazu gehört entweder tiefer Einblick ins Programm (test coverage, jeder executionspfad, unit tests), ggf. selbst geschriebene Spezialsoftware um Ergebnisse (PDF, renderings, mathematische Ergebnisse, CNC Fräspfade, whatever) gegen die gewünschte Realität abzugleichen oder noch besser GUI automatisiert zu bedienen auch bei anderer Bildschirmplatzierung) und all das können Tester sowieso nicht. Die können nicht mal Anwendern auf die Finger schauen um zu sehen woran es real hapert mit realen Benutzern, 'Karl Klammer'. KI hilft da wenig, die ist beim programmieren deutlich hilfreicher. Wir haben 1 Person die den build Prozess und Auslieferung überwacht und das Testbed verwaltet damit jeder gemeldete Fehler nachweislich bei jeder Auslieferung getestet bleibt. Getestet hat der nie selber, Tests laufen automatisch und wurden oft genug von Programmieren gemacht die spezielle Testvorrichtungen geschaffen haben, unsere GUI ist z.B. voll remote bedienbar um gewisse Tests skripten zu können, es gibt auch auch Testprogramme die die GUI Graphik selbst untersuchen.
Vielen Dank für euer Feedback! Reines manuelles Testen wird mich langfristig auch nicht zufriedenstellen, da relativ monoton und simple. Besonders interessiert mich die Testautomatisierung (z.B. mit Python, Robot Framework). Mein Ziel ist es, hier langfristig Fuß zu fassen.
Peter H. schrieb: > Laut ISTQB startet man mit dem Foundationlevel, kann verschiedene > Spezialisierungen erwerben (z.B. Last- und Performancetester, > Testautomatisierung, ...) oder sich auf das advanced level > konzentrieren. Dazu zählen Test Analyst, Technical Test Analyst oder > auch Test Manager. ISTQB-Zertifizierungen spielen nur in Testbuden eine Rolle. In anderen Firmen kommst du auch so auf entspr. Positionen. > Wie zukunftssicher ist der Job (vor dem Hintergrund KI)? Verschwinden wird er nicht, sich nur ändern. > Wie realitätsnah ist ISTQB wirklich? Die Realität ist dass Testbuden Dienstleister für Dritte sind, dafür müssen sie qualifiziertes Personal nachweisen, das machen sie indem sie ihre Leute in diese Zertifizierungen stecken. Die meisten Jobs dort sind lowend und machen äh sehr spezielle Leute. Die wenigen interessanten Jobs dort gibts naturgemäss kaum und kommst du als internen auch nur schwer ran. > Wie sieht euer Arbeitsalltag aus? Welches Essen schmeck am besten, ist eine ähnliche Frage. > Wie seid ihr zum Testen gekommen, wo wollt ihr noch hin? Da will man schnell wieder weg davon, weil nur nervig. Ausser man ist äh sehr speziell drauf und findet so einen Braindeadjob in einer Testbude toll. Der Rest ist da eher zufällig dazu gekommen als Entwickler immer mehr Testaufgaben übernommen,... will halt keiner machen, den adminstrativen nervigen Mist drumherum noch viel weniger. Einerseits ist das ein Vorteil von dir, wenn Firmen einen finden der das freiwillig machen will, sieht aber seltsam aus, wenn sich einer mit Hochschulabschluss auf so einen verhassten Job bewirbt. Die meisten Stellen beinhalten ja beides: Testen und Entwicklen, sind aber primär als Entwicklerstellen ausgeschrieben. Über so eine Stelle steigst du irgendwo ein und übernimmst freiwillig immer mehr Testaufgaben und den administrativen Kram drumherum, dann lassen sie dich auch nicht mehr weg. > Habe ich bei gleicher Ausgangslage (z.B. Studium Informatik) gleiche > Gehaltsaussichten, wie wenn ich programmieren würde? Teilweise verdienen die echt gut, kommt aber auf 1000 Faktoren an. Die meisten die das machen landen dort zufällig oder sind speziell gepolt und landen dann in so einer Testbude für den monotonen Kram. Ich kenne Einen, der ist ISTQB-zertifiziert, arbeitet 100% remote im Homeoffice, macht nicht die monotone Drecksarbeit und kassiert um die 80k, hat nicht mal ein Studium, ist aber eher die Ausnahme. > Ich freue mich auf eure Erfahrungen, Meinungen und Antworten! Halte dich von reinen Testbuden fern, wäre Verschwendung deines Studiums.
:
Bearbeitet durch User
Frank D. schrieb: > Halte dich von reinen Testbuden fern, wäre Verschwendung deines > Studiums. Vielen Dank für deine Antwort und Sichtweise! Frank D. schrieb: > Die wenigen interessanten > Jobs dort gibts naturgemäss Was wären die interessanten Jobs in deinen Augen? In einer reinen Teststelle und stumpf Tests machen möchte ich auf keinen Fall. Ich möchte den Schwerpunkt auf Testautomatisierung (da man hier auch viel programmieren kann) und auch DevOps setzen.
Peter H. schrieb: > seit einiger Zeit beschäftige ich mich mit dem Berufsbild des > Software-Testers. Berufsbild? Es gibt keins. Die Bandbreite ist einfach zu groß. An einem Ende gibt es Testaffen die nach Anweisung irgendwo auf ein Knöpfchen drücken, fest stellen dass irgendwas passiert oder nicht passiert und das in einer Testmanagement-Software abhaken. Am anderen Ende gibt es Leute die dir deine Software so dermaßen auseinander nehmen dass du nicht mehr weißt ob du Männlein, Weiblein oder Diverslein bist. Mir ist letzter Typus immer lieber. Mit denen kann man sich unterhalten[1]. Mit den Testaffen nicht. Allerdings hasst die Mehrzahl der Programmiere Tester wie die Pest und wenn schon zieht sie Testaffen vor. Weil die stören die Ruhe und das Selbstbild des unfehlbaren Hotshot-Programmierers weniger. > Besonders interessiert mich hierbei, welche Abzweige > man in diesem Berufsbild gehen kann und wie die Gehaltsentwicklung in > den verschiedenen Bereichen ist. Was für Abzweige? Wenn das Gehalt steigen soll, dann geht man nach oben, nicht irgend welche Abzweigungen. Leitender Tester, Gruppenleiter, Abteilungsleiter Software-Testing, Leiter QA, Chief Quality Officer (CQO), Vice President of Quality. So was in der Richtung. > Laut ISTQB Zertifikations-Bullshit. Ja, wenn dein Arbeitgeber solche Scheine haben will, dann machst du sie halt. Besonders wenn er sie bezahlt. Aber einen Vice-President-of-Quality-Schein wirst du dort nicht bekommen > Wie zukunftssicher ist der Job (vor dem Hintergrund KI)? Die Clowns-Ebene wird vermutlich hart von KI getroffen werden. Alles was automatisiert werden kann wird automatisiert. Das läuft schon seit Jahren, schon vor KI. Dafür bracht man keine Glaskugel. Die höheren Ebenen? Schwer zu sagen ohne Glaskugel. Das kommt drauf an wie weit KI integriert wird und wie viel Entscheidungs- und Handlungssspielraum man ihr geben wird (oder sie sich nimmt :)). > Wie realitätsnah ist ISTQB wirklich? Ich habe Firmen gesehen wo jeder Tester wenigstens den Foundaten-Level haben musste. Meist nur damit die Tester wenigstens eine einheitliche Sprache sprechen und nicht mit eigenem Kauderwelsch redeten. Also kann man sagen der Foundaten-Level löst zumindest ein reales Problem, Terminologie. Ich habe auch eine Firma gesehen wo das organisatorische Chaos beim Testen durch einen Test-Manager mit ISTQB-Scheinen aufgräumt wurde. Was dort dringend nötig war. Wichtig war aber mehr dass er erfahren und durchsetzungsfähig war. Die Scheine hätte er vermutlich nicht unbedingt gebraucht. Das war mehr Eintrittskarte und Dekoration. > Habe ich bei gleicher Ausgangslage (z.B. Studium Informatik) gleiche > Gehaltsaussichten, wie wenn ich programmieren würde? Ach hättest du doch was anständiges studiert :) __ [1] Heißer Tipp für Softwareentwickler: Redet mit euren Testern wenn es nicht nur Testaffen sind. Das sind die ersten Benutzer eurer Software und häufig der letzte Schutzwall zwischen euch und den Kunden. Ist hat ziemlich blöd wenn die Software beim Kunden dem Kunden in die Fresse fliegt. Dann nützt das ganze Hotshot-Programmierer, einsamer Held Getue gar nichts mehr.
Bei den Firmen wo ich bin und war (2 Konzerne und 2 Mittelständler) ist das Testen seit 30 Jahren eine Aufgabe, die stets halbherzig nebenbei passiert. Alle paar Jahre werden dafür neue Tools angeschafft und die Gründung einer eigenen QA Abteilung angekündigt - ist aber nie passiert. Am Ende mussten die Programmierer sich immer selbst bzw. gegenseitig testen. Seit einem halben Jahr nervt unser GF damit, dass wir (also wieder die Programmierer) die Tests vollautomatisch mit KI machen sollen. Es dürfen aber keine Betriebsgeheinisse abfließen, und für ein eigenes KI System wird fast kein Geld bereit gestellt (ein 5000 Euro Abo pro Jahr wurde bereits abgelehnt). Und das muss natürlich nebenbei passieren, denn die KI soll ja sofort Personal sparen, nicht umgekehrt. Langer Rede kurzer Sinn: Never ever will ich offiziell Tester werden. Das ist schmutzigste Arschkarte, die man im Unternehmen bekommen kann. Man wird nicht wertgesschätzt, bekommt kein Budget, hat nichts zu sagen (keine Macht), wird aber für jeden Fehler mit "Warum hat das denn keiner vorher getestet?" angemacht. Nein Danke.
:
Bearbeitet durch User
Peter H. schrieb: > seit einiger Zeit beschäftige ich mich mit dem Berufsbild des > Software-Testers. Es ist auch total sinnvoll sich mal so richtig ausführlich theoretisch mit irgendwelchen Berufsbildern auseinanderzusetzen. Gott bewahre man würde jetzt schon im SW Bereich arbeiten und hätte wirklich Einblick in SW Tests. Nein nein das wird am Studiertisch analysiert. Was machst du eigentlich bisher? Gärtner? Und nur mal so als Einblick: Wenn man ein paar Inder hat, denen es einmal zu oft in den Kinderwagen geschneit hat, und die auch weder Messer noch Gabel richtig halten können, und auch keinen Besen zum Hof kehren, exakt DIE werden dann halt SW-Tester. So viel zum Ansehen deines Traumberufs.
:
Bearbeitet durch User
Cyblord -. schrieb: > Wenn man ein paar Inder hat, denen es > einmal zu oft in den Kinderwagen geschneit hat, und die auch weder > Messer noch Gabel richtig halten können, und auch keinen Besen zum Hof > kehren Sag mal, findest du solche Äußerungen OK, oder warst du da unzurechnungsfähig?
Nemopuk schrieb: > Sag mal, findest du solche Äußerungen OK Die richtige Frage wäre ob es der Wahrheit entspricht oder nicht. Und nicht ob es deine Gefühle verletzt.
:
Bearbeitet durch User
Cyblord -. schrieb: > Die richtige Frage wäre ob es der Wahrheit entspricht oder nicht Nein wäre sie sie nicht. So etwas sagt man nicht, das gehört sich auch dann nicht, wenn es wahr wäre.
Cyblord -. schrieb: > exakt DIE werden dann halt SW-Tester. Also (in einer mir bekannten Firma) werden die top bezahlte Softwareentwickler dank Kenntnissen in der englischen Sprache, und auch sonst kennen die laut ihrem CV alles, jede Programmiersprache, jedes Framework. Nur fragen darfst du sie nicht, auch nicht auf englisch.
Nemopuk schrieb: > Cyblord -. schrieb: >> Die richtige Frage wäre ob es der Wahrheit entspricht oder nicht > Nein wäre sie sie nicht. So etwas sagt man nicht, das gehört sich auch > dann nicht, wenn es wahr wäre. Du musst hier keine kleinen Kinder erziehen, "sagt man nicht" hilft in der realen Welt nicht weiter. Auch Dir ist klar, dass Cyblord hier ausschließlich provozierend unterwegs ist! Zur Sache kann man heftig streiten, ich kenne eine größere Firma, die mit Test Auslagerung nach Indien eine Bauchlandung gedreht hat. Doof nur, als sie das gemerkt haben, war die erfahrene Gruppe in Franlfurt schon längst entlassen. In meinem Umfeld erstellt ein Kollege Listen und hakt tagelang Funktionen ab bzw. dokumentiert Auffälligkeiten - und das mit jeder neuen Firmware wieder von vorne. Für mich nichts, er ist damit glücklich. Was gerne übersehen wird, sind Benutzer. Ich habe mit unspezifischem Vorgehen "gib her, lass mal gucken" etliche Treffer gelandet, die der systematische Test übersehen hat. Oben drauf kommt noch, vom Produkt abhängig, ein Betriebsversuch. Der ist aber in der Umsetzung problematisch, weil viele Benutzer nicht anständig beobachten können, wo es klemmt. Was auch gerne übersehen / ignoriert wird, sind Meldungen aus dem Feld, die über die Servicetechniker kommen könnten.
Michael B. schrieb: > Cyblord -. schrieb: >> exakt DIE werden dann halt SW-Tester. > > Also (in einer mir bekannten Firma) werden die top bezahlte > Softwareentwickler dank Kenntnissen in der englischen Sprache, und auch > sonst kennen die laut ihrem CV alles, jede Programmiersprache, jedes > Framework. Nur fragen darfst du sie nicht, auch nicht auf englisch. Und jeder ist "Senior", mit 10+ Jahren Erfahrung im Bereich "alles". Auch 22 jährige. Oh ich kenne es!
Nemopuk schrieb: > Cyblord -. schrieb: >> Die richtige Frage wäre ob es der Wahrheit entspricht oder nicht > > Nein wäre sie sie nicht. So etwas sagt man nicht, das gehört sich auch > dann nicht, wenn es wahr wäre. Heißt es nicht "Trinken was klar ist, reden was wahr ist, vögeln was da ist."?
Cyblord -. schrieb: > Und nur mal so als Einblick: Wenn man ein paar Inder hat, denen es > einmal zu oft in den Kinderwagen geschneit hat, und die auch weder > Messer noch Gabel richtig halten können, und auch keinen Besen zum Hof > kehren, exakt DIE werden dann halt SW-Tester. Das ist einfach nur menschenverachtend und dumm. Cyblord -. schrieb: > Die richtige Frage wäre ob es der Wahrheit entspricht oder nicht. Und > nicht ob es deine Gefühle verletzt. So so wäre es das? Die richtige Frage wäre eher woher du weißt das das die Wahrheit ist?
Bernd schrieb: > So so wäre es das? Die richtige Frage wäre eher woher du weißt das das > die Wahrheit ist? Aus täglicher Erfahrung. Woher sonst?
Cyblord -. schrieb: > Bernd schrieb: >> So so wäre es das? Die richtige Frage wäre eher woher du weißt das das >> die Wahrheit ist? > > Aus täglicher Erfahrung. Woher sonst? Weil du es dir so zurechtlegst und es so sehen willst
Bernd schrieb: > Cyblord -. schrieb: >> Bernd schrieb: >>> So so wäre es das? Die richtige Frage wäre eher woher du weißt das das >>> die Wahrheit ist? >> >> Aus täglicher Erfahrung. Woher sonst? > > Weil du es dir so zurechtlegst und es so sehen willst Und das denkst du weil? Weil nicht sein kann was nicht sein darf? Weil die Wahrheit dich als Schneeflöckchen erschüttert und du gerne die Augen vor der Realität verschließen willst?
Cyblord -. schrieb: > Bernd schrieb: >> Cyblord -. schrieb: >>> Bernd schrieb: >>>> So so wäre es das? Die richtige Frage wäre eher woher du weißt das das >>>> die Wahrheit ist? >>> >>> Aus täglicher Erfahrung. Woher sonst? >> >> Weil du es dir so zurechtlegst und es so sehen willst > > Und das denkst du weil? Weil ich deine Beiträge lese und die keinen anderen Schluss zulassen. > Weil nicht sein kann was nicht sein darf? > Weil die Wahrheit dich als Schneeflöckchen erschüttert und du gerne die > Augen vor der Realität verschließen willst? Es geht nicht darum was ist, sein darf oder sein kann. Es geht darum das du Beiträge schreibst die einfach nur rassistisch sind.
Bernd schrieb: > Es geht nicht darum was ist, sein darf oder sein kann. Es geht darum das > du Beiträge schreibst die einfach nur rassistisch sind. Flöckchen, falls unqualifizierte Inder eine eigene Rasse darstellen, dann ja.
:
Bearbeitet durch User
Der "Schönwetterflug" beim Testen ist ja auch nicht so die Herausforderung, die kann man gerne und "einfach" automatisieren. Einfach alles nehmen was "erlaubt" ist, und rein stopfen in seinen Software-Test-Automaten. Alle Masken und Menuepunkte mit sinnvollen Daten füttern und abreiten. Sollwert und Istwert vergleichen, keine Abweichungen feststellen -> HURRA! "Die Software ist fehlerfrei" ;-) Wenn da zu dem Zeitpunkt schon was knallt, dann hat die Software nur einen ziemlichen "Basis-Reifegrad". Ja nicht daneben treten, sonst wirds krachen. Tretmine-im-Reisfeld-Software bzw. Testing. eine KI (oder ein unerfahrener oder unmotivierter Tester) kommt "von sich aus" nicht auf die Idee, dass es viele versteckte Besonderheiten gibt. # Text sieht auf dem Bildschirm anders aus als auf dem Drucker (abweichende Font-Implementierung, unangemeldete Schriftarten-Ersetzung). # Auf dem einen Browser passiert irgendwas (aber nur in einer speziellen version), auf dem anderen Browser passiert etwas abweichendes # Addition und Multiplikation sollte zwar nach mathematischer Lehre kommutativ sein, aber leider waren Datentypen (Größe, Type-Casting) nicht zueinander passend, und die blöden Automatismen haben das bei ihren speisenden Datenvektoren nicht berücksichtigt. 30% von 100 EUR ergibt dann nicht dasselbe wie 3% von 1000 EUR. Da gibt es noch jede Menge schräge Beispiele, wo eine Software scheinbar funktioniert, aber dann doch noch Fehler auftauchen, welche beim Test unentdeckt blieben.
:
Bearbeitet durch User
Cyblord -. schrieb: > Aus täglicher Erfahrung. Woher sonst? Was muß das für ein merkwürdiger Laden sein, in dem eine absolute Spitzenkraft wie unser Cyblordchen täglich von Hohlbirnen umgeben ist. Eigentlich sucht man sich doch Mitarbeiter, die sich in das Team einordnen...
Manfred P. schrieb: > Was gerne übersehen wird, sind Benutzer. Ich habe mit unspezifischem > Vorgehen "gib her, lass mal gucken" etliche Treffer gelandet, die der > systematische Test übersehen hat. Deswegen fangen wir immer so an, und führen die spezifizierten Tests erst danach aus.
Wegstaben V. schrieb: > 30% von 100 EUR ergibt dann nicht dasselbe wie 3% von 1000 EUR. Ein Klassiker dieser Art ist auch, Preise von Netto zu Brutto und wieder zurück umzurechnen. Eventuell sogar mehrfach. Dabei vergisst man schnell die Rundungsfehler, insbesondere wenn man mit Absicht auf 1 Cent rundet.
:
Bearbeitet durch User
Softwaretester alleine ist ein Knecht Job. Denn die Testmuster macht ein Anderer. Wie gut die dann auch sind. Besser ist einen Kunden/Anwender als Tester zu haben. Dann haben die Tests zumindest einen Realitaetsbezug. Man sollte auch Programmieren koennen um ueberhaupt von einem Karriereziel reden zu koennen. Und man sollte Richtung Anwendungs Entwicklung gehen, Dabei das Fehlertestin auch machen koennen.
:
Bearbeitet durch User
Ich finde das Testen von Software eine sehr interessante Tätigkeit. Sie ist objektiv betrachtet auch sehr wichtig. Ich kann jedoch nur abraten, den Softwaretester als Tätigkeit anzustreben. Als SW-Entwickler kann man sich als Softwaretester genauso austoben und wird besser bezahlt. Die Entscheider wissen leider gar nicht, warum Softwaretest wichtig ist und bezahlen die Tester auch schlechter, sie haben keine Entscheidungsbefugnis und das Ansehen ist mau. In meiner Firma musste ich mir gerade wieder anhören: "Das mit den JUnit-Tests sparen wir uns. Das wird aber keine Zeit dafür." Ich scherze nicht! 1. Die Person spricht sei jeher von JUnit-Tests (als das Framework nenen) anstelle von Unit-Tests oder Modultests. Die Person weiß nicht, warum es JUnit heißt. 2. Die Aussage zeugt von hoher Ignoranz, trotz > 15 Jahre Berufserfahrung. Außerdem gibt's noch ein großes Missverständnis. Wenn ich sage: "Softwaretest macht Spaß.", meine ich konkret: "Testautomatisierung macht Spaß.", also Tests ausdenken, implementieren, Fehler aufdecken. Wenn man die Techniken wie parametrisierte Testfälle beherrscht, ist das richtig wunderbar. In Kombination mit Softwareentwicklung, hat man dann auch sehr schnelles Feedback und keine seine gemachten Fehler korrigieren. Hauptamtliche Tester jedoch, so meine Beobachtung, werden als Klickaffen bemühmt. Die dürfen dann das Softwareprodukt aufsetzen und irgendwelche manuellen Tests durchklicken. Finger weg! Das hat mit ISTQB auch nichts zu tun. Dort lernt man vernünftige Sachen wie Grenzwerttests und Äquivalenzklassenanalyse. Damit hatten unsere Tester nie was am Hut, weil sie nur am Klicken waren. ISTQB liefert Methoden, um zu den richtigen Testfällen kommt, die man hinter automatisiert ausführen lässt.
Rudi R. schrieb: > Ich finde das Antworten auf vergammelte Threads stinkig. Bitte hier nur auf die ursprüngliche Frage antworten, für neue Fragen einen neuen Beitrag erstellen. ich sehe keine Antwort
Peter H. schrieb: > Vielen Dank für euer Feedback! > Reines manuelles Testen wird mich langfristig auch nicht > zufriedenstellen, da relativ monoton und simple. > > Besonders interessiert mich die Testautomatisierung (z.B. mit Python, > Robot Framework). Mein Ziel ist es, hier langfristig Fuß zu fassen. Dann werde normaler SW-Entwickler, weil wir bereits geschrieben, versteht die Entscheider unter einen Softwaretester was ganz anderes. Ich muss aber auch sagen, dass ich ungern die SW-Tests für jemand anderes schreiben möchte. Ich bin der Auffassung, dass viel zu viele ihre Software falsch konstruieren und überall Seiteneffekte einbauen, die die Software untestbar oder schwer testbar machen. Ich hatte mich im Sommer einer Sache angenommen. Da funktionierte etwas nicht, Kunde meckerte, der eigentliche Entwickler seit Jahren nicht mehr in der Firma. Es war sehr klar beschrieben in der Spec, es gab aber keine Testfälle. Es war ganz klassisch beschreibbar mit Eingabe und erwarteter Ausgabe, aber das konnte man nicht testen, weil die Fachlogik zwischen durch in der Datenbank nachschaute. Auch war alles darauf ausgerichtet, dass man etwas auf dem Bildschirm darstellt. (Kardinalfehler vieler Entwickler, dass die sich nicht gedanklich von ihrer Gui-Zeugs lösen können.) Die Lösung war für mich ein Komplettumbau dieser Logik mit klarer Trennung von fachlicher Logik und den cross-cutting concerns. Meine Architekten-, Enwickler- und Testskills waren gefragt Heraus kamen ca. 15 Unittest, die rasendschnell die Logik abprüften. Das hat sogar so viel Spaß gemacht, dass ich mich sonntags hinsetzte, vor meiner großen Fahrradtour nach Dänemark. Im Herbst ging das zum Kunden und der ist restlos zufrieden damit. Und das ist das beste, was passieren kann. Es wäre natürlich besser, wenn man es von Anfang mit Sinn und Verstand an die Sache herangehen würde. Kapieren nur viele Leute nicht. Intellektuelle Faulheit beobachte ich seit vielen Jahren. Die haben dreimal auf die heiße Herdplatte gefasst und es bewahrt sie nicht davor, es ein viertes mal zu tun. Die denken wirklich, die sparen Zeit, wenn sie auf die Testautomatisierung am Anfang verzichten. Die machen das Gegenteil dessen, was ich den Azubis erzähle.
Joachim B. schrieb: > Rudi R. schrieb: >> Ich finde > > das Antworten auf vergammelte Threads stinkig. > > Bitte hier nur auf die ursprüngliche Frage antworten, > für neue Fragen einen neuen Beitrag erstellen. > > ich sehe keine Antwort Dann lerne Lesen. Ist gehe auf den Fragesteller ein und ich korrigiere sein Bild vom Softwaretester. Er sollte Softwareentwickler werden. Eine sehr fundierte Antwort.
Rudi R. schrieb: > Außerdem gibt's noch ein großes Missverständnis. Wenn ich sage: > "Softwaretest macht Spaß.", meine ich konkret: "Testautomatisierung > macht Spaß.", also Tests ausdenken, implementieren, Fehler aufdecken. Ich sehe nicht, dass man manuell zu bedienende Software automatisiert testen könnte, wenn man nur Display und Tastatur hat. Auf einem PC mag es in seltenen Fällen anders sein: An einem System wurden Abstürze berichtet, wenn man Aktionen per Mausclick zügig und oft ausführt. Dafür hatte ich dann ein AutoIT-Script gestrickt, was stundenlang die manuelle Bedienung simulierte. Das war aber für genau diesen einen speziellen Fall gestrickt und hat mit automatisierten Tests wenig zu tun. > Hauptamtliche Tester jedoch, so meine Beobachtung, werden als Klickaffen > bemühmt. Die dürfen dann das Softwareprodukt aufsetzen und irgendwelche > manuellen Tests durchklicken. Genau ein solcher hatte das Büro neben mir, Tabellen geschrieben und tagelang abgehakt, nach der nächsten Änderung wieder. Ganz sicher nicht mein Ding, aber seine Erfolgsrate zeigt, dass man ihn braucht! Ich hatte mit den Service-Kollegen vom Außendienst und Kunden zu tun und auch Systeme auf dem eigenen Tisch. Mehr als einmal habe ich meinem Nachbarn neue / zusätzliche Testszenarien aufgeben können, an die man bislang nicht gedacht hatte. Nie vergessen habe ich die Vorstellung eines neuen Systems für die Außendienstler: Wir geben einem dieser das Gerät in die Hand, machen einen Bedienablauf und der Kollege erzeugt direkt einen Absturz. Benutzer eben, unbedarft und ohne Vorsatz, das wird kein systematischer Test jemals simulieren können.
Manfred P. schrieb: > Nie vergessen habe ich die Vorstellung eines neuen Systems für die > Außendienstler: Wir geben einem dieser das Gerät in die Hand, machen > einen Bedienablauf und der Kollege erzeugt direkt einen Absturz. > Benutzer eben, unbedarft und ohne Vorsatz, das wird kein systematischer > Test jemals simulieren können. Works as designed. Designed for IT Specialist but not for Endusers. ;-)
Manfred P. schrieb: > Rudi R. schrieb: >> Außerdem gibt's noch ein großes Missverständnis. Wenn ich sage: >> "Softwaretest macht Spaß.", meine ich konkret: "Testautomatisierung >> macht Spaß.", also Tests ausdenken, implementieren, Fehler aufdecken. > > Ich sehe nicht, dass man manuell zu bedienende Software automatisiert > testen könnte, wenn man nur Display und Tastatur hat. Es ist Aufgabe eines Architekten, dass die Geschäftslogik von der Oberfläche isoliert entwickelt ist. GUI-getriebene Entwicklung geht häufig schief. Das habe ich nun in über 15 Jahren Berufserfahrung miterlebt. Ist die Fachlogik isoliert, kann man da wunderbar automatisiert testen. Nun befreit das aber nicht davon, dass die Oberfläche getestet werden muss. Da kann man manuell testen, aber dann mit wesentlich geringerem Aufwand, weil die Fachlogik dank Isolierung mit Modultest auf Herz und Nieren getestet wird. Die Integration in die GUI fällt in die Kategorie Integrationtest, weil es da um das Zusammenspiel zweier Subsysteme geht. Und es gibt auch Möglichkeiten, mit Record-Replay, Mausklicks und Tastatureingaben aufzuzeichnen und immer wieder automatisiert auszuführen. Ich habe aber nicht erlebt, dass das irgendwie sinnvoll war: 1. Einstiegshürde ist viel zu hoch. 2. Oft lizenzpflichtig. 3. Pflegeaufwand ist viel zu hoch, denn eine GUI ändert sich eher als eine Schnittstelle zu einer Funktion, zu einem Modul. Und wenn es sich dort ändert, wird schon im Kompiliervorgang gemeckert, dass da etwas nichts passt. Die IDEs zeigen das sofort an. Tests werden schnell flaky. Für meine Softwareänderung im Sommer, die mir solchen Spaß machte, sagte ich auch: Den Integrationstest macht jemand anders. Und das tat auch jemand anders und es funktionierte. Aber das ist auch gut, wenn jemand anderes auch noch mal drüber schaut.
Rudi R. schrieb: > Da kann man manuell testen, Wenn man sein Handwerk versteht testet man das auch automatisiert.
:
Bearbeitet durch User
>> Da kann man manuell testen, > Wenn man sein Handwerk versteht testet man das auch automatisiert. Wer sein Handwerk versteht, kennt die Grenzen von automatischen Tests. Nicht jeder User verhält sich wie ein Automat.
Bradward B. schrieb: >>> Da kann man manuell testen, >> Wenn man sein Handwerk versteht testet man das auch automatisiert. > > Wer sein Handwerk versteht, kennt die Grenzen von automatischen Tests. > Nicht jeder User verhält sich wie ein Automat. Habe mich dazu ausführlich geäußert. Automatisierung findet natürlich irgendwo auch seine Grenzen. Die ganzen Testingstools wie Zephyr sind leider bei uns in der Firma gescheitert. Das wird dann aus Spieltrieb ausprobiert, oder der Kunde verlangt es, aber dann gibt es nur eine Person im Projekt, die sich damit auskennt. Am besten umgeht man das alles, indem man die architektonisch das so hochzieht, dass die Fachlogik isoliert ist dass man diese testen kann.
Ich denke, das gibt es mindestens zwei Aspekte, die völlig unterschiedlich zu bewerten und zu ralisieren sind. a) Die rein techninsche Funktionalität kann man m.E. früher oder später zu 100% automatisch bzw. von/mit KI testen lassen. Ob z.B. die Software für eine Motorsteuerung tut, was erwartet wird, kann man objektiv ermitteln ... b) Eine ganz andere Nummer stellt nach meinen Erfahrungen die Funktionalität einer GUI bei stark dialog-orientierter Software dar. Oft hat man das Gefühl "Haben die jemals mit ihrer eigenen Software gearbeitet?". Das wird besonders in Stress-Situationen bzw. unter Leistungsdruck sichtbar. Allerdings gibts natürlich auch verschiedene Herangehensweisen an ein und das selbe Problem, ich nenne nur "prozess-orientiert" oder "daten-orientiert" ... da werden wohl noch für längere Zeit Menschen benötigt.
:
Bearbeitet durch User
> b) Eine ganz andere Nummer stellt nach meinen Erfahrungen die > Funktionalität einer GUI bei stark dialog-orientierter Software dar. Oft > hat man das Gefühl "Haben die jemals mit ihrer eigenen Software > gearbeitet?". Das wird besonders in Stress-Situationen bzw. unter > Leistungsdruck sichtbar. Usability-Test, ja da kochen Emotionen hoch: https://youtu.be/ELYVpikRNEE?t=24
Bradward B. schrieb: > Wer sein Handwerk versteht, kennt die Grenzen von automatischen Tests. > Nicht jeder User verhält sich wie ein Automat. absolut, egal wie sicher wir Tasteneingaben am PC machen wollten, das Prüffeld fand immer Benutzer die komische Tastenkombinationen fanden die wir Entwickler nicht vorhersehen konnten. Das Prüffeldpersonal fand illegale Tastenkombinationen eher als wir uns Tests dafür ausdenken konnten.
Joachim B. schrieb: > Prüffeld fand immer Benutzer die komische Tastenkombinationen fanden die > wir Entwickler nicht vorhersehen konnten. Genau da ist der wunde Punkt der Beauftragung der Tests. Wenn die bloß beauftragen diese bestimmte Funktion zu prüfen, kommt solcher Mist raus. Da BWLer immer sparsam sind, kommt dann später erst das böse Erwachen. "Es sollte ja wenig kosten."
>> Prüffeld fand immer Benutzer die komische Tastenkombinationen fanden die >> wir Entwickler nicht vorhersehen konnten. > > Genau da ist der wunde Punkt der Beauftragung der Tests. Wenn die bloß > beauftragen diese bestimmte Funktion zu prüfen, kommt solcher Mist > raus. Dieses Szenario öffnet auch einen Blick auf die Bedeutung der Systemarchitektur. Man kann keine Fheler vollständig aus dem dem system (testen), man kann aber ein System konzipieren das zu simple für "komplexere" Fehler ist. Und man kann nichtspezifizierten (aka unerwünschte) Eingaben (beim Einlesen/Parsen) erkennen und (mit log und/oder mit log und Fehlermeldung oder ...) ignorieren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.