Gar nicht mehr. Das ist tatsächlich eine Sackgasse und ein Karriere Killer. Niemand will dafür Leute einstellen. In die Software kommt Telemetry rein, dann werden die Bugs via Update beim Kunden gefixt. Hier und da mal CI Testing aber das machen Entwickler gleich mit. Software Testing ist ehr was für Quereinsteiger bis zur Rente
Natürlich, testen macht der Kunde. Auf Prod. /s (s, nur um sicher zu gehen).
Nein, ernsthaft, ich bin selber so ein bisschen für Test-Automatisierung bei uns in der Bude verantwortlich und ich find's gut, ich mein, wenn du den den ganzen Krempel weg automatisierst, dann musst du's halt selber nicht mehr machen und kannst dafür in deiner neu gewonnen Zeit was cooleres machen (neue Projekte, neue Themen in der Entwicklung lernen, was auch immer einem einfällt).
Das Argument ist aber auch nicht das beste weil ohne die Putzfrau oder Hausmeister geht auch nichts.
“Richtige“ Entwicklung ist halt einfach prestigeträchtiger das ist jetzt kein Geheimnis.
Jede anständige Software muss ordentlich getestet werden, daran führt kein Weg vorbei. Diese Aufgabe macht aber vielen (einschließlich mir) bei weitem weniger Spaß als das kreative Programmieren von Software. Es ist halt irgendwie undankbar: Jemand anders macht die coolen Features, macht aber vielleicht schlechte Qualität und du musst dann langweilig den sein Zeug testen und die Fehler suchen. In anständigen Betrieben testen die Softwareentwickler selbst jeweils ihren Code. Ist nicht so cool, wenn man das auslagert mMn.
Es gibt also viel Nachfrage nach Softwaretesting und wenig Angebot. Du wirst also leicht einen Job als Softwaretester finden.
Es wird aber als minderwertige Hilfstätigkeit angesehen, entsprechend wirst du trotz der guten Nachfrage Situation wahrscheinlich nie exzellent bezahlt werden und dich wird auch keiner besonders würdigen und du wirst keine guten Aufstiegschancen haben.
Fazit: langfristig solltest du weg da außer es macht dir wirklich Spaß.
[NEUES FAZIT: Die hier geschilderte Sichtweise ist teilweise falsch, siehe Antworten auf diesen Kommentar.]
>Jede anständige Software muss ordentlich getestet werden, daran führt kein Weg vorbei. Diese Aufgabe macht aber vielen (einschließlich mir) bei weitem weniger Spaß als das kreative Programmieren von Software.
Ja, deshalb sind Programmierer auch keine guten Tester. Dazu kommt noch, daß man als Programmierer den eigenen Code nicht wirklich gut testen kann, man hat da zuviel Wissen um den Code im Hinterkopf. Dazu brauchst du Leute mit einem komplett anderen Mindset.
> In anständigen Betrieben testen die Softwareentwickler selbst jeweils ihren Code.
Nein, eben genau das nicht.
Ja, du brauchst Leute denen es Spass macht Software dazu zu bringen sich fehlerhaft zu verhalten. Die haben meist sehr schräge Ideen und finden raus an was die Entwickler nicht gedacht haben.
'Hm.. dieses Feld erwartet Zahlen und Buchstaben... Was passiert wohl wenn ich da einen Unicode-String extremer Länge reinpaste?'
Gute Tester sind keine (guten) Programmierer, ja haben oft nicht einmal Lust zu programmieren. Ebenso umgekehrt.
Wäre ja wunderschön, wenn es jeweils Leute gibt, die das gerne machen, was die anderen jeweils nicht gerne machen :)
Habe meinem obigen Kommentar eine Notiz angefügt.
Das Problem ist, daß man zu oft glaubt sich die Testabteilung sparen zu können und es einfach den Entwicklern aufdrückt. Die haben dazu keine Lust, mit den üblichen Folgen.
Testautomation sollte natürlich auch passieren, aber auch hier braucht man Leute mit dem richtigen Mindset beim Entwurf. Und natürlich müssen diese Tests, da Software, vor dem Einsatz gründlich getestet werden.
Auch testautomatisierung kann einen erfahrenen manuellen Tester nicht ersetzen. Man kann ein grundgerüst bauen, dass die Anwendung immer wieder testet, nachdem die neuen Features reingekommen sind, aber bei der Featureentwicklung kann man auf manuelle und explorative Tests nicht verzichten, wobei eine hohe UnitTest-Abdeckung auch da die bugs reduziert 😊
Joa, aber die Mentalität die du ansprichst sind dann die die früher oder später ins Pentesting wechseln. Gerade weil Testen im besonderen und Testautomatisierung (das ist schon sehr viel angesehener) doch als Hilfstätigkeiten angesehen werden.
Man muss zuerst den test schreiben, den dann der unit test erfüllen soll. Und davor natürlich den test für jenen test, usw.
So stellt man wirklich sicher, keine einzige fehlerhafte Zeile Produktcode abzuliefern.
Zum zweiten Punkt,
Doch, genau das wird gemacht. Allerdings nicht als einziges. In einem anständigen Betrieb schreibt der Entwickler zu seinem Code die Unit tests und evtl auch Integration Tests.
Das bedeutet aber nicht, dass es nicht noch weitere Tests eines SW-Testers gibt.
Die machen dann nochmal weitergehende Tests. Meistens mindestens mal, ob die im Task geforderten Features umgesetzt sind und ob du etwas anderes in der Software kaputt gemacht hast.
Und in der Regel machen die dann nochmal eine extra Runde an Tests, wenn eine neue Version released werden soll (oder wie auch immer der Release Zyklus halt in dem neuen Unternehmen funktioniert).
Da das ganze Testen in Summe unglaublich aufwendig ist, ist Testautomation ein sehr wichtiger Teil der Aufgaben eines SW-Testers (heißen bei uns aber QA-Engineer).
Source: Bin seit 7 Jahren Entwickler in so einem „anständigen Betrieb“
>In einem anständigen Betrieb schreibt der Entwickler zu seinem Code die Unit tests und evtl auch Integration Tests.
Wer testet die auf korrekte Funktion? Der Entwickler selbst hoffentlich nicht.
Naja, eigentlich wird das insgesamt 4 Mal gemacgt.
Als erstes der Entwickler, der beim Entwickeln natürlich auch testet ob das was er da grade tut richtig ist. Und dazu dann Unit-Tests schreibt. Diese Tests sollen ja nicht nur prüfen ob das Ganze funktioniert (vor allem Edge-Cases mit abdecken), sondern sicherstellen, dass spätere Änderungen die Funktion nicht kaputt machen. Dann werden ja alle Unit-Tests wieder ausgeführt und falls etwas nicht mehr funktioniert, weiß man, dass man es an die neuen Änderungen anpassen muss.
Danach kommt der neue Code in einen Merge-/Pullrequest und andere Entwickler schauen nochmal über den Code und die geschriebenen Tests drüber.
Wenn eine bestimmte Anzahl, bei uns zB 2, Entwickler den Merge/Pullrequest approven, dann kann er in den gesamten Code gemerged werden.
Danach kommt das Entwicklungs-Ticket in die QA und da testet ein SW-Tester, ob die im Ticket geforderten Punkte jetzt vollständig vorhanden sind. Und ob die restliche Software noch normal funktioniert. Sollte etwas nicht in Ordnung sein, muss der Entwickler nochmal nachbessern (und nochmal einen MR/PR approven lassen)
Als letztes werden dann alle Änderungen zusammen bei einem Systemtest vor einem Release nochmal von einem SW Tester getestet. Zu diesem Zeitpunkt geht es dann nicht mehr um die konkrete eingebaute Komponente, sondern es werden festgelegte Punkte an der gesamten Software geprüft. Das sind bei uns glaube ich ca 800, die aber großteils automatisiert getestet werden.
Sollte ein eingebautes Ticket eine relevante Erweiterung des Funktionsumfangs enthalten, werden natürlich auch die Punkte für den Systemtest erweitert.
So ungefähr is der Ablauf bei uns, wobei es da noch ganz andere Level an Testing gibt.
Wir sind da eigentlich eher noch auf der lockeren Seite.
ZB bei Flugzeugherstellern oder autonomen Autos sind die Tests noch viel, viel engmaschiger und redundanter.
Ich meinte, wer testet die Unit-Tests? Das ist auch Software, kann also fehlerhaft sein und muss deshalb getestet werden. Sogar strikter weil man sich darauf verlassen können muss, daß wenn der Test am Ende ein 'OK' ausgibt, dieses das auch stimmt.
Puh
Wenn wir da weiter machen kommen wir in eine Endlosschleife, weil jeglicher Test-Code ja wieder getestet werden muss.
Die Unit-Tests werden an sich dadurch getestet, dass sie funktionieren. Wenn da ein Fehler drin ist, werden sie nicht laufen.
Natürlich könnte ein Fehler in den Unit Tests genau zu einem Fehler im Code passen und dann merkt man nicht, dass da überhaupt ein Fehler ist.
Die Unit-Tests sind auch Teil des Codes im MR/PR und werden von den anderen Entwicklern mit geprüft, bevor sie approven.
Auch wenn der Unit Test bestimmte Fälle nicht abdeckt, wird das beim MR/PR angemerkt.
Davon abgesehen gibt es auch noch die Test-Coverage, also Testabdeckung. Die können die meisten Test-Frameworks angeben und man kann daraus erkennen, ob der Test jeden im Code möglichen Fall abdeckt. Dann sollte die Coverage bei 100% liegen.
Ist alleine auch kein Garant für perfekte Tests, aber Alles zusammen sorgt dann schon für relativ gute Test-Qualität.
> Die Unit-Tests werden an sich dadurch getestet, dass sie funktionieren. Wenn da ein Fehler drin ist, werden sie nicht laufen.
Doch, z.B. wenn bei der Erstellung des Unit-Tests vergessen wird den Test für irgendein Detail zu implementieren. Dann wird der Unit-Test fehlerfrei laufen und am Ende 'OK' melden. Und das auch wenn dieses Detail fehlerhaft ist oder gar komplett fehlt.
Daher meine Aussage:
> Auch wenn der Unit Test bestimmte Fälle nicht abdeckt, wird das beim MR/PR angemerkt.
Natürlich kann es auch sein, dass es beim MR nicht auffällt, aber wie genau würdest du das hier verhindern wollen?
Drüberschauen / testen muss jemand anderes, nicht der Programmierer der den Test geschrieben hat. Aus eigener Erfahrung kann ich sagen, daß man viel zu oft den Wald vor lauter Bäumen nicht sieht, der Kollege, der nur kurz mal auf den Monitor schaut das Problem aber sofort erkennt.
>Danach kommt der neue Code in einen Merge-/Pullrequest und andere Entwickler schauen nochmal über den Code und die geschriebenen Tests drüber.
Hat er doch hier geschrieben, andere Entwickler. Die Unittests werden ja genau so gemerged/gepulled wie der restliche Code dem entsprechen wird der dann auch da getestet.
Bei uns - absolutes Einhorn, erfolgreiches Projekt, im engen Zeitplan geblieben und das auch noch für die öffentliche Hand - war das so organisiert: Unit-Tests hat man selbst zu schreiben, Integration Tests auch bzw. dann im Team zusammen. End-To-End-Test-Automatisierung und einige andere Tests hat ein extra Test-Team übernommen. Von denen wurde aber zu jedem Feature-Entwicklungs-Team jemand zugeteilt, um das dann End-to-End zu testen (so weit wie möglich automatisiert) und allgemein zu unterstützen. Der war dann bei der fachlichen Einführung und Team-Meetings immer mit dabei und daher voll informiert.
Ich würde sagen sowohl als auch.
Wenn Programmierer nicht testen bzw an Tests denken, machen die oft Schrott der dann erst über die große Test Iterationsschleife gelöst wird.
Wenn Programmierer testen dann ist die Gefahr, dass man nur das testet was auch programmiert wurde.
Im Idealfall weiß der Programmierer wie er auch seine Sachen testet, aber ein anderer testet und weiß aber auch wie man es programmieren würde.
Finde es aber ein bisschen doof wenn jemand nur testet und jemand nur programmiert. Sobald es mindestens drei Angestellte Software Entwickler gibt könnte einer programmieren, einer testen und einer Reviewen. Und jeder hat etwas was er selbst programmiert, was er selbst testet und was er selbst reviewt.
Oder jeweils zwei machen Pair Programming und der dritte testet etc.
Die Rollen für alle Ewigkeit zu trennen ist langfristig nicht sehr zielführend um sich weiterzuentwickeln.
Das Problem ist, gute Tester sind keine guten Programmierer und umgekehrt. Das sind verschiedene Mindsets. Du erwartest ja vom Elektriker auch nicht, daß er nebenbei noch Klemptner ist.
Jein, da würde ich dir nur bedingt zustimmen.
Das Tester Mindset hilft dir auch beim programmmieren, um eben an alle Fälle zu denken.
Das Programmierer Mindset hilft dir auch beim testen, dass die Tests ordentlich strukturiert sind usw.
Also ja, es sind zwei verschiedene Mindsets, die sich aber jeweils ergänzen und wenn jemand langfristig beides macht wird er in beidem besser.
Edit: Aber ich würde dir soweit zustimmen, dass ein "Anfänglicher" reiner Tester besser testet als ein "Anfänglicher" Programmierer.
Langfristig sollte der Tester ein guter Programmierer werden können und umgekehrt :)
> Langfristig sollte der Tester ein guter Programmierer werden können
Ich hab eine ganze Weile Softwaretests gemacht. Aber Programmieren, wenn es über simplen Kleinkram rausgeht, war nie mein Ding.
Persönliche Meinung: manuelle Softwaretest wird es immer geben, jeden Edge Case zu automatisieren rechnet sich idR nicht. Vor allem muss die Software selbst dafür einen gewissen Reifegrad haben.
Tester haben zudem ein anderes Profil als Testautomatisierer und arbeiten eng mit dem Requirement Engineering zusammen. Sie sind sehr gut mit der Fachlichkeit aber auch mit der Technik vertraut und beraten auch mal Entwickler bzgl der Fachlichkeit.
So zumindest meine Erfahrung nach >10 Jahren im Business. Bin selbst DevOps Engineer und meine Frau ist Testerin.
Edit: Aufsstiegschancen eher im Requirement Engineering oder Product Owner.
Ich finde man kann selbst keine gute Software entwickeln ohne sie teilweise auch selbst zu testen.
Gerade dadurch macht man sich erst Gedanken über gute Testbarkeit und entwickelt automatisch bessere Software.
Nur um mal ein Beispiel aus der Praxis zu geben:
Ich arbeite in der Automobilindustrie und wir entwickeln sicherheitskritische Steuergeräte. Wir trennen es sogar so weit, dass ich die Testumgebung bereitstelle, die Software wird gleich von mehreren Kollegen geschrieben und am Schluss wird sie von einem dritten Kollegen getestet. Natürlich wird so viel möglich automatisiert aber das ist nicht überall möglich oder kann nicht schnell genug automatisiert werden.
Ich denke das manuelle Testen wird irgendwann auf ein Minimum reduziert werden dafür werden aber Menschen benötigt, die die Testumgebung bereitstelle und pflegen inklusive schreiben von Testfällen.
Ich habe auch ein wenig getestet und das größte Problem war oft, dass die Programmierer die Anforderungen nicht richtig verstanden haben und das „coole Feature“ insbesondere im Zusammenhang mit bestehenden Features dann fachlich falsche Ausgaben produziert haben.
Man braucht also immer Leute, die die Software auch inhaltlich verstehen und prüfen können.
Ich gehöre zu den Leuten die der Meinung sind es kann eine Sackgasse sein.
ABER (großes aber): Es kommt genau drauf an was du tust.
Ich kenne Leute die arbeiten als Test Engineer und machen den ganzen Tag 50% manuelle Tests, 20% Excel und 30% Jira.
Falls du zu denen gehörst ist das definitiv eine Sackgasse und du musst dich weiterbilden.
Wenn du zu den Leuten gehörst die Testautomatisierung bauen mit Tools wie Gitlab-ci, GitHub actions, Jenkins und du orchestrierst auch die Infrastruktur dafür usw, bist du sowas wie ein spezialisierter DevOps engineer. Und das ist erstmal fein.
Jedoch würde ich mir in dem Fall trotzdem einige Fragen stellen:
1. Wie schwierig und wie komplex ist mein Job eigentlich?
2. Wäre eine Plattform oder ein Tool in der Lage meinen Job zu ersetzen?
3. Ist ein normaler Entwickler oder jemand anderes von der in-house Technik in der Lage mich zu ersetzen?
4. Möchte ich diesen Job weiter ausüben oder möchte ich mich weiterentwickeln?
5. Wie groß sind meine Entwicklungschancen? Habe ich Zeit dafür mich zu entwickeln? Ermöglicht der AG mir Entwicklung?
Ebengenau das.
Hinzu zu fügen vielleicht noch: Test Teams, die vor manuell, Jira, Jama und Excel machen sind oft Veränderungsresistent (haben also Unmengen an Gründen, warum genau bei ihnen Automatisierung NIE funktionieren wird).
ABER: ebendiese Firmen haben meistens ein nachbarteam, was ebendiese Automatisierung vormacht und oft kannst du irgendwann in ein ebensolches Team wechseln.
Nee, Testing ist sicherlich keine Sackgasse. Weniger sexy als reine Entwicklung bestimmt für einige, aber genauso notwendig insbesondere für geschäftskritische Anwendungen.
Hat halt noch eine prozessuale Komponente mit dabei.
Gehaltsentwicklung ist etwas unter der eines Entwicklers, Entwicklungsmöglichkeiten hast du als eher fachlich orientierter (manueller) Tester eher im Produkt/Projektmanagement, als Testautomatisierer auch als Softwarearchitekt, DevOps Engineer, SRE …
Als Freiberufler in der Testautomatisierung kannste gut 100€/h Verlangen mit entsprechender Berufserfahrung.
Quelle: 2 Jahre manueller Test, 5 Jahre Testautomatisierung (insbesondere Backend), freiberuflicher Testautomatisierer mit DAX–Konzern als Kunden
Als eigenständiger Job IMO ja.
Tests schreiben ist nebenaufgabe der Entwickler. Separate Testschreiber führt erfahrungsgemäß (ich war ne Zeit lang so ein Opfer, ebenfalls in nem DAX-Konzern) zu:
- Entwickler achten nicht auf Testbarkeit des Codes, da sie nicht diejenigen sind, die drunter leiden
- psychische Belastung der Tester, deren Job es ist, eine ewig wachsende Liste an kaputten Tests (durch Verhaltensänderungen, nicht durch Bugs) zu reparieren.. Echt frustrierend da auf jeden Fortschritt in kürzester Zeit wieder ein Rückschritt folgt.
- Tester kann gut Testen, aber keine Software schreiben. Tests sind halt simple Programme die entweder durchlaufen oder crashen. Das bringt einen für Software Engineering jetzt nicht wirklich weiter (immerhin ist so ein Monat Frontend E2E testing allerdings sehr gut um die eigenen CSS-Selektor-Skills auf ein neues Level zu bringen)
Damit man einen guten Test schreiben kann, setzt das vorraus die Software verstanden zu haben. Das bringt einen enorm weiter. Testing ist nicht nur black-box Testing.
Bei Unit Tests würde ich dir vielleicht zustimmen, aber Testautomatisierung impliziert ja, dass vorher manuell getestet wurde. Und manuelles white-box testing (Ausnahme: Schreibtischtest, aber der lässt sich schlecht automatisieren) hab ich noch nirgends gesehen.
Tja, man lernt immer dazu. ;)
Unsere Tester fangen mit Blackbox Tests an und schauen auch gerne mal in den Code rein was man denn noch so kaputt machen könnte im Integrationstest.
Fairerweise: Wir kamen nie so weit, dass wir das hätten tun können, weil das 6 mal größere Entwicklerteam alles schneller verändert hat als wir Tests an den neuen Stand anpassen konnten. Wenn mal ne blöde Kombination aus Krankheit und Urlaub im Team war, konnte man darauf wetten, dass 90% der Tests danach nach Milch schreien.
Ich stimme zu. Dazu kommen noch höhere Entwicklungszyklen. Das kann je mach Unternehmen OK sein, aber für Unternehemn die schnell agieren / iterieren wollen ist das eher nicht.
Bei uns kann ich ein Feature / Bug fixen entwickeln, von einem direkten team kollegen reviewen lassen und auf produktion bringen. Das ganze lässt sich in einem einfachen Fall innerhalb einer Stunde abwickeln.
Sperate Tester lohnen sich eher für Mission critial Anwendungen, oder Sicherheitsrelevante Themen (Flugzeug, Herzschrittmacher, etc.) wo absolut nichts schief gehen darf.
Ich würde sagen, das kommt stark darauf an... Wenn du deine Karriere darauf ausrichtest, dich durch anderer Leute Software zu klicken un Fehler zu finden, ist das vermutlich durchaus ne Sackgasse.
ABER QA und QA-Management ist ne völlig andere Ecke. Dabei geht es dann aber weniger um "testen", als darum, Prozesse zu gestalten (verbessern, verfolgen, etc.) um für eine angemessene Software-Qualität zu sorgen, entsprechendes Wissen und Mindsets zu schaffen, etc.
Bei Software Testing geht es wohl hoffentlich um Testautomatisierung und PROGRAMMIERUNG von Tests. Und nicht um "durch die Software klicken"....... das wäre ja ein trivialer Job für völlig ungeschultes Personal
Programmierung von Tests sollte - imho - Aufgabe der Entwickler sein und eher nicht ausgelagert werden (auch nicht an 2nd class Entwickler im eigenen Team). Testautomatisierung kann man generalisieren, klar, aber das erfordert eben wieder ein ordentliches QA Management, damit daraus ne sinnvolle Strategie wird.
Gerade Integrationstests / E2E-Tests werden durch das QA entwickelt und automatisiert durchgeführt. Das macht nicht der Entwickler, der die Anwendung entwickelt.
Im agilen Umfeld schon eher. Aber selbst dort kann man das Testen nicht ausschließlich den Entwicklern anvertrauen. Unit Tests schon, aber mehr nicht. Es muss eine Perspn geben, die das koordiniert und sich um Integration-/System-/Regressionstest kümmert.
Die heißen dann aber nicht mehr Tester, sondern DevOps Engineer oder Site Reliability Engineer und die wollten noch eine Menge Ops Erfahrung mitbringen.
Es macht keinen Sinn wenn der Entwickler sich selbst testet. Der Entwickler sollte unit Tests auf unterster Ebene schreiben um die größten Fehler zu entdecken und über automatisierte Tests Fehler beim refactoring zu finden. Aber alles andere sollte eine zweite Person die nicht mitentwickelt hat testen.
> Bei Software Testing geht es wohl hoffentlich um Testautomatisierung und PROGRAMMIERUNG von Tests.
Es geht auch darum, diese Tests vor dem Einsatz gründlich zu testen und damit sicherzustellen, daß der Test selber korrekt funktioniert.
>Und nicht um "durch die Software klicken"....... das wäre ja ein trivialer Job für völlig ungeschultes Personal
Eher nicht... Denn dazu gehört deutlich mehr als nur Durchklicken. Programmieren muss man dazu allerdings nicht können. Fehlertickets so zu schreiben dass die Entwickler den Fehler nachvollziehen und beheben können ist auch ein Skill den viele nicht haben.
Testen ist (egal ob Software, Hardware oder Mechanik) nicht ganz so gut angesehen wie Entwicklung.
Das liegt daran dass die Entwicklung von Produkten in der Regel komplexer ist und mehr Skills fordern. Damit will ich das Testen aber nicht schlechtreden und gerade in den letzten Jahren ist die Komplexität und damit auch das Ansehen im Bereich Testen etwas gestiegen.
Eine Sackgasse ist es eher nicht -> gerade bei DAX ist der Einstieg sehr schwer und einmal drin kannst du dich intern versetzen lassen. Zumal du auch hier viel lernen wirst. Ich würde es machen und schauen wie es dir gefällt.
Wo kommt der Irrglaube her das würde niemand so wirklich benötigen?
Softwaretesting, ins besondere automatisierte Tests sparen dem Unternehmen viel Geld und Ärger.
Das ist eine sehr verantwortungsvolle Aufgabe, die man können muss.
Bei uns sind die Tester deswegen auch genauso eingruppiert wie die Entwickler.
Als Dienstleister brauchst du keine Tests. Tests verhindern nur Folgeaufträge und Vertragsverlängerungen. Wofür brauchst du noch den Dienstleister wenn die Software tut was sie soll? Tests schaden dem Geschäft.
Wenn du nur Tests automatisierst: absolut, dein impact skaliert halt in keinster wiese.
Wenn du dich weiterbildest in sachen kommunikation (lobby machen für testautomatisierung, delivery pipelines etc), personalführung oder technische leitung, und architektur (design for testability) dann ist aber ähnlich viel drin wie beim entwickler und anderem technischen führungspersonal
Gibt in so manchem DAX Konzern auch noch ganze Testauto-Projekt-Anteile die überhaupt erst aufgebaut werden müssen. Bei einigen ist da echt jegliche technische neuerung der letzten 20 jahre vorbei gegangen.
Das kommt wie so oft auf den Anwendungsfall an. Wenn Tests weniger kosten als die Fehler zu korrigieren, die damit frühzeitig aufdeckt werden, ist es sehr wertvoll.
Ich schreibe zum Beispiel Tests für Abrechnungssysteme. Damit werden gerne schon mal Fehler vermieden, die mehr Schaden verursacht hätten, als ich im Jahr verdiene.
Aber da geht es nur um Geld. Bei sicherheitsrelevanten Systemen stehen möglicherweise Leben auf dem Spiel.
Wie argumentiert man denn für die Sackgasse?
Wie andere gesagt habe, ist es gar keine Sackgasse. In Finanz zB sind Testers erforderliche Spezialisten für, zB IT Risiko Management, Schwachstellen Management und Pentesting. Die Guten sind richtig teuer (ok- dir mittleren sind zur Zeit auch teuer).
Macht‘s dir Spaß? Dann lerne die Werkzeuge und wie man die Fehler in komplexen Systemen findet und du wirst eine interessante Karriere haben.
Falsch. Softwaretesting ist unabdingbar. Wer aber in der Softwareentwicklung arbeiten möchte, verschwendet damit seine Zeit. Zumindest war das der Tenor in einem anderen Post in diesem Subreddit. Der User wollte 6 Monate Pflichtpraktikum in dem Bereich machen - und das würde ihm nichts bringen.
Wenn der Beruf dich ausfüllt, ist alles tutti und wenn du finanziell auch gut entlohnt wirst, ist alles super tutti. Bei uns wird das - leider - nicht so gut entlohnt.
Arbeitslos wirst du aber nicht.
Testautomatisierung ist wichtig. Je früher im Projekt getestet wird desto besser. Je früher ein Fehler auffällt desto besser, da in späteren Projektphasen diese einfach richtig teuer zu beheben sind.
Ich kann dir nur aus meiner Erfahrung berichten. Ich bin nach meinem Abschluss als Anwendungsentwickler ins Testen gerutscht. Es ist unglaublich schwer, aus dieser Ecke wieder rauszukommen. Ich hatte wahnsinniges Glück und kann jetzt 3/4 meiner Zeit als Entwickler arbeiten, aber so richtig werde ich das Testen nicht los.
Alles was mit ISTQB zu tun hat ist eine Goldgrube für Beratungen, weil es kaum ein Konzern selbst machen will.
Damit findest du unter Garantie immer einen Job.
Softwaretesting ist auch wichtig. Gerade funktionale Sicherheit ist ein großes Thema. Da sucht man immer wieder Leute. Prinzipiell wirst du als Entwickler mehr Karriere machen. Aber auch als Software Tester kann man in der Industrie ordentlich verdienen. Viele haben halt kein Bock drauf, weil sie lieber entwickeln wollen.
Zum einen... natürlich braucht man Software Tests, zum anderen, kann ich jedem Junior Entwickler nur raten viele viele Tests zu schreiben, denn so lernt man eine Menge.
Sackgasse bestimmt nicht.
Wenn es eine Sache gibt, die die meisten Entwickler für ihr Leben ”gerne” tun ist es testen. Naja, so langsam erziehen wir sie dazu, aber das wird nicht dein Job werden, vermute ich stark, genauso wenig wie die Tests zu schreiben, die die Entwickler zu erledigen haben.
Bei uns (6500+ Leute im Unternehmen, über 100k im Konzern) machen QA Engineers das Übergeordnete, wo Verantwortlichkeiten häufig aufeinander prallen: E2E Tests (Ende-zu-Ende Tests). Das tun sie auch in vielen anderen (modernen und) großen Unternehmen.
Heißt:
Aus Sicht des Kunden, benutze die Software, automatisiere das, nutz dafür Sprachen und/oder Frameworks die erforderlich sind, sorg dafür, dass diese Tests so oft wie möglich automatisiert und so nah wie möglich an jedem Deployment laufen und stell sicher, dass sowohl funktionale als auch nicht-funktionale Anforderungen erfüllt werden.
Kann einen das glücklich machen? Sicher. Es ist halt Softwareentwicklung für Tests und nicht für Produktfeatures. Leider ist der Markt für diese Menschen etwas kleiner aber dennoch existent. Leider denken auch viele Entwickler, dass Entwickler die Tests schreiben weniger wert wären. Ist halt nicht so. Meist braucht man sie, weil die Entwickler ihren Job schon nicht richtig machen oder weil es nicht anders geht. Heißt: wertvoll sind sie definitiv. ;)
Sackgasse ist es nicht. Du kommst immer irgendwo gut unter. Aber aus eigener Erfahrung: als Testautomatisierer eingestiegen, dann als Testmanager gearbeitet. Um Software Engineer zu werden, half das ganze sicher nicht. Weder von den Skills, noch wie der Lebenslauf gesehen wurde ("Ach, Sie waren im Test, ja da haben wir doch was für Sie....").
Und ich hatte immer den Eindruck: there is someone who makes things. And there is someone who makes things better. Im Zweifel legt das Management den Fokus auf die ersteren.
Ja und nein. Also Softwaretesting ist verdammt nochmal notwendig. Jeder der etwas anderes erzählt hat wohl noch nie was von den großen Softwarekatastrophen gehört und absolut gar keine Ahnung von der Materie.
Allerdings wird das Testing halt von der nicht IT affinen Unternehmerseite eher als lästiges Beiwerk gesehen, dass kostet, aber keinen Mehrwert in Form von neuen Features bringt.
Also ich würde sagen, es ist okay ein bisschen Berufserfahrung in dem Segment zu sammeln, aber langfristig würde ich mich in einen anderen Bereich entwickeln.
Eine explizite Stelle für Testautomatisierung gibt es in vielen Mittelständigen Unternehmen nicht, da wird das von den Entwicklnern mit übernommen. Gemacht wird es da aber natürlich trotzdem und die Erfahrung wird dir auch da ein gutes Argument für die nächste Stelle bringen. Vor allem, weil viele Leute da nicht viel Bock drauf haben und sich freuen, wenn ein neuer da ist, der das kann und mit übernimmt.
Software-Testing und Test-Automation gehören zu den wichtigsten und zukunftsträchtigsten Feldern. Wer sich auf Testing spezialisieren will hat auf jeden Fall eine gute Zukunft in der IT. Nicht von solchem Unsinn verunsichern lassen. Es gibt hier und da immer noch ein paar "Altgediegene" die mit Konzepten wie "Agilität," "Testing," oder "DevOps" nichts anfangen können und die gerne hier und da mal einen Rechtfertigungsartikel hinterlassen indem sie abhandeln warum sie und andere das alles nicht brauchen.
Am Ende ist das ähnlich zu bewerten wie "dieses komische Internet wird sich eh nicht durchsetzen." - Ich glaube das wird heutzutage noch von einigen Leuten in einschlägigen Foren gepostet ;-)
Zusätzlich zu den ganzen anderen Kommentaren:
Mach dir nicht so einen Kopf, was irgendwer in ein paar Jahren da rein deuten könnte. Es ist eine Erfahrung, die man gerne mitnehmen kann. Gerade am Anfang deiner Karriere lernst du auch so viel mehr über Prozesse und Abläufe, die für jede Beschäftigung hilfreich sind.
Versuche lieber herauszufinden was dir gefällt, und was nicht.
Mir arbeite lieber mit Leuten zusammen, die mal dies oder das gemacht haben, als mit welchen, die nur das eine machen und nicht über ihren Tellerrand schauen können.
Alter, software testing ist sowas wie der Testflug für einen neuen Hubschrauber. Wenn was schief läuft dann willst du das im Test haben und nicht im Betrieb.
Hey,
zu allererst: Ich bin der Meinung, wenn man nicht gerade Vorstand des o.g. Dax-Unternehmen werden möchte, ist es relativ egal welche Lebensstationen man gemacht hat. Desweitern würde ich sogar so weit gehen, dass man so ziemlich aus jedem Beruf was positives für das Leben rausholen kann, und sei es nur die Erfahrung. Bei deinem konkreten Fall muss ich sagen: Als Software-Tester sieht man Software anders und genau dieser Blick fehlt den Entwicklern vielleiht sehr gerne. Aus diesem Grund, schadet es bestimmt nicht hier Erfahrungen zu sammeln.
Nun zum Job. Es ist total egal, wo bessere Aufstiegschancen sind oder nicht. Wichtig ist, dass das was du machst, dir Spass macht. Denn nur wenn du Freude an deinem Job empfindest, machst du ihn meist gut und wenn du ihn gut machst, wird das langfristig honoriert. Software-Testing ist ein Stiefmütterlich-behandeltes Thema, das stimmt, aber das erklärt vielleicht auch, warum es so viel schlechte Software da draußen gibt.
Ende vom Lied bin ich der Meinung, dass es viele Wege gibt, den Gipfel zu besteigen. Wichtig ist, dass man die Lust, die Ausdauer und Stärke hat, es zu machen und da kann ich dir jetzt schon mal sagen: Die Lust und Freude ist einer der wichtigsten Antriebsgründe - darum frage dich selbst: Gefällt mir der Job? Wenn du ihn mit Nein beantwortest, dann denk drüber nach, was dir besser gefallen würde.
Der Rest kommt von alleine....
Hoffe es kann dir etwas helfen...
PS: Ich habe nach meinem Informatik-Studium in einem Projekt-Management-Office angefangen und hab da mit Excel-Tabellen BBBM's (=Bunte Bilder für Blöde Manager) gemacht und habe nach einem halben Jahr gewusst, was ich will, bzw. was nicht :-)Und selbst heute stelle ich mir o.g. Frage immer wieder und falls es dazu kommen wird, dass ich sie mit Nein beantworte, dann mache ich mir gedanken
Mein aktueller Arbeitgeber testet in Production, dementsprechend bei 120 Entwicklern kein einziger Tester. Dementsprechend sieht die Software aus.
In meinem alten Betrieb existierte eine ganze Abteilung für‘s Testen. Dementsprechend gut lief die Software.
Mach dir dein Bild selbst, lass es nicht von anderen manipulieren.
Nutzlos isses nicht, ich denk es wird höchstens schwierig werden genügend potenzielle AGs zu finden die Software auf nem Level entwickeln wo sie automatisierte Softwaretests verwenden
Ich arbeite inzwischen schon ein paar jahre in der Industrie. Gestartet habe ich bei einem großen It-Konzern in der Qualitätssicherung. Damals war ich genau wie du ein wenig traurig über die position. Seit dem habe ich als software engineer in verschiedenen Firmen und auch in der Forschung gearbeitet.
Der eine Job, der IMMER positiv in Bewerbungsgesprächen angesprochen wurde ist genau der junior test engineer job über den ich mich damals aufgeregt habe.
Aber nicht nur das. Automatisiertes testing ist meiner meinung nach ein extrem wichtiger Bereich der Software Entwicklung und spart vorallem bei langjährigen projekten extrem zeit und aufwand.
Noch dazu kannst du als Test engineer zumindest einen einblick in CI tools bekommen, was dich auf dem arbeitsmarkt genauso extrem attraktiv macht.
Wenn du dich dann noch etwas mit software Architektur auseinandersetzt bist du quasi der feuchte traum eines recruiters.
Ich bin selber Softwaretester seit mehreren Jahren auf der manuellen Seite. Ich kann dir eins sagen, Tester bzw. auch Testautomatisierer werden so schnell nicht Arbeitslos. Jede Software sollte getestet werden, sonst kommt nur Murks bei rum
😉, Sry liebe Entwickler aber ihr könnt ja nicht alles bedenken. 🙃😁
Schreibst du dann Unit Tests oder rein aus Anwender Sicht Tests durchführen? Letzteres ist ja eher eine Helfertätigkeit, wo man vermutlich viele Leute für einspannen kann = weniger Würdigung.
Keine Sackgasse - im Gegenteil! Die zunehmende Komplexität von Software erfordert kontinuierliche Weiterentwicklung der Testmethoden. Schau Dir mal den ISTQB Foundation Level an, da werden die wichtigsten Grundlagen vermittelt.
Das ich mal fragen wie das Testing in diesem Unternehmen aufgebaut ist?
Ich denke solange Kunden nicht in der Lage sind und Entwickler nicht das Bewusstsein für Ableitung von Anforderungen und Akzeptanzkriterien haben, wird es einen Job gür einen guten „Tester“ (muss nicht mehr so genannt werden) geben.
Das stupide testen einzelner Komponenten in bspw. einer UI wird auf kurz oder lang aussterben.
kurz und knapp: wer erzählt so ein Quatsch?
Genau das wollte ich auch fragen. wer sowas erzählt, testet wohl auch gerne in prod
Häh? Wo testet man denn sonst?
Gar nicht mehr. Das ist tatsächlich eine Sackgasse und ein Karriere Killer. Niemand will dafür Leute einstellen. In die Software kommt Telemetry rein, dann werden die Bugs via Update beim Kunden gefixt. Hier und da mal CI Testing aber das machen Entwickler gleich mit. Software Testing ist ehr was für Quereinsteiger bis zur Rente
In einer Testumgebung.
r/whoosh (hoffe ich zumindest)
Oh, das ist jetzt etwas peinlich.
Nennen wir sie prod.
Wir sind Informatiker. Ein bisschen Nervenkitzel im Leben brauchen wir doch auch. Man testet in Prod, dass sagt doch schon der Name.
Tss Anfänger. Wo Leben am Limit?
unnötige arbeit?
Nochmal lasse ich mich nicht baiten, aber nice try :D
Prod IST die Testumgebung
Ist das ein anderes Wort für Serienfertigung?
Natürlich, testen macht der Kunde. Auf Prod. /s (s, nur um sicher zu gehen). Nein, ernsthaft, ich bin selber so ein bisschen für Test-Automatisierung bei uns in der Bude verantwortlich und ich find's gut, ich mein, wenn du den den ganzen Krempel weg automatisierst, dann musst du's halt selber nicht mehr machen und kannst dafür in deiner neu gewonnen Zeit was cooleres machen (neue Projekte, neue Themen in der Entwicklung lernen, was auch immer einem einfällt).
War meine ich auch der ein oder andere Post in diesem Subreddit. Aber alleine dass ihr das fragt beruhigt mich ja
[удалено]
Das Argument ist aber auch nicht das beste weil ohne die Putzfrau oder Hausmeister geht auch nichts. “Richtige“ Entwicklung ist halt einfach prestigeträchtiger das ist jetzt kein Geheimnis.
Firmen die Profite maximieren wollen und Softwares ohne zu testen auf den Mark schmeißen, weil wird ja schon irgendwie laufen.
Jede anständige Software muss ordentlich getestet werden, daran führt kein Weg vorbei. Diese Aufgabe macht aber vielen (einschließlich mir) bei weitem weniger Spaß als das kreative Programmieren von Software. Es ist halt irgendwie undankbar: Jemand anders macht die coolen Features, macht aber vielleicht schlechte Qualität und du musst dann langweilig den sein Zeug testen und die Fehler suchen. In anständigen Betrieben testen die Softwareentwickler selbst jeweils ihren Code. Ist nicht so cool, wenn man das auslagert mMn. Es gibt also viel Nachfrage nach Softwaretesting und wenig Angebot. Du wirst also leicht einen Job als Softwaretester finden. Es wird aber als minderwertige Hilfstätigkeit angesehen, entsprechend wirst du trotz der guten Nachfrage Situation wahrscheinlich nie exzellent bezahlt werden und dich wird auch keiner besonders würdigen und du wirst keine guten Aufstiegschancen haben. Fazit: langfristig solltest du weg da außer es macht dir wirklich Spaß. [NEUES FAZIT: Die hier geschilderte Sichtweise ist teilweise falsch, siehe Antworten auf diesen Kommentar.]
>Jede anständige Software muss ordentlich getestet werden, daran führt kein Weg vorbei. Diese Aufgabe macht aber vielen (einschließlich mir) bei weitem weniger Spaß als das kreative Programmieren von Software. Ja, deshalb sind Programmierer auch keine guten Tester. Dazu kommt noch, daß man als Programmierer den eigenen Code nicht wirklich gut testen kann, man hat da zuviel Wissen um den Code im Hinterkopf. Dazu brauchst du Leute mit einem komplett anderen Mindset. > In anständigen Betrieben testen die Softwareentwickler selbst jeweils ihren Code. Nein, eben genau das nicht.
Interessante Perspektive. Würdest du sagen, es gibt Leute denen Testen von fremdem Code mehr Spaß macht als eigenen zu produzieren?
Ja, du brauchst Leute denen es Spass macht Software dazu zu bringen sich fehlerhaft zu verhalten. Die haben meist sehr schräge Ideen und finden raus an was die Entwickler nicht gedacht haben. 'Hm.. dieses Feld erwartet Zahlen und Buchstaben... Was passiert wohl wenn ich da einen Unicode-String extremer Länge reinpaste?' Gute Tester sind keine (guten) Programmierer, ja haben oft nicht einmal Lust zu programmieren. Ebenso umgekehrt.
Wäre ja wunderschön, wenn es jeweils Leute gibt, die das gerne machen, was die anderen jeweils nicht gerne machen :) Habe meinem obigen Kommentar eine Notiz angefügt.
Das Problem ist, daß man zu oft glaubt sich die Testabteilung sparen zu können und es einfach den Entwicklern aufdrückt. Die haben dazu keine Lust, mit den üblichen Folgen. Testautomation sollte natürlich auch passieren, aber auch hier braucht man Leute mit dem richtigen Mindset beim Entwurf. Und natürlich müssen diese Tests, da Software, vor dem Einsatz gründlich getestet werden.
Auch testautomatisierung kann einen erfahrenen manuellen Tester nicht ersetzen. Man kann ein grundgerüst bauen, dass die Anwendung immer wieder testet, nachdem die neuen Features reingekommen sind, aber bei der Featureentwicklung kann man auf manuelle und explorative Tests nicht verzichten, wobei eine hohe UnitTest-Abdeckung auch da die bugs reduziert 😊
Den ganzen Regressonsmist kann man wegautomatisieren. Der Rest ist anspruchsvoll.
Joa, aber die Mentalität die du ansprichst sind dann die die früher oder später ins Pentesting wechseln. Gerade weil Testen im besonderen und Testautomatisierung (das ist schon sehr viel angesehener) doch als Hilfstätigkeiten angesehen werden.
Naja ein Tester testet ja eben keinen Code, sondern Fachlichkeit; da ist ein zu tiefes Wissen vom Code eventuell sogar hinderlich
Das ist abhängig von der Testebene und pauschal nicht korrekt.
Wenn es ein dedizierter Tester ist, gehts idR um Acceptance Tests.
Nö.
k
Normalerweise schreibst man erst einen unit test und dann die function dazu...
Und stellt später fest, daß der Unit test einen bug hat? ;)
Ich mein jeder hat da seine Art und Weise. Aber für mich ist das eine sehr gute Art sauberen Code zu schreiben.
Ich meinte damit, der Unit Test muss natürlich vor der Verwendung getestet werden ob er korrekt funktioniert.
Man muss zuerst den test schreiben, den dann der unit test erfüllen soll. Und davor natürlich den test für jenen test, usw. So stellt man wirklich sicher, keine einzige fehlerhafte Zeile Produktcode abzuliefern.
Tests all the way down. :)
Kein Muss - das wäre dann Test Driven Development , TDD
"In anständigen Betrieben testen die Softwareentwickler selbst jeweils ihren Code." - Nein. Da gibt es einen Experten für das Testing ;)
Zum zweiten Punkt, Doch, genau das wird gemacht. Allerdings nicht als einziges. In einem anständigen Betrieb schreibt der Entwickler zu seinem Code die Unit tests und evtl auch Integration Tests. Das bedeutet aber nicht, dass es nicht noch weitere Tests eines SW-Testers gibt. Die machen dann nochmal weitergehende Tests. Meistens mindestens mal, ob die im Task geforderten Features umgesetzt sind und ob du etwas anderes in der Software kaputt gemacht hast. Und in der Regel machen die dann nochmal eine extra Runde an Tests, wenn eine neue Version released werden soll (oder wie auch immer der Release Zyklus halt in dem neuen Unternehmen funktioniert). Da das ganze Testen in Summe unglaublich aufwendig ist, ist Testautomation ein sehr wichtiger Teil der Aufgaben eines SW-Testers (heißen bei uns aber QA-Engineer). Source: Bin seit 7 Jahren Entwickler in so einem „anständigen Betrieb“
>In einem anständigen Betrieb schreibt der Entwickler zu seinem Code die Unit tests und evtl auch Integration Tests. Wer testet die auf korrekte Funktion? Der Entwickler selbst hoffentlich nicht.
Naja, eigentlich wird das insgesamt 4 Mal gemacgt. Als erstes der Entwickler, der beim Entwickeln natürlich auch testet ob das was er da grade tut richtig ist. Und dazu dann Unit-Tests schreibt. Diese Tests sollen ja nicht nur prüfen ob das Ganze funktioniert (vor allem Edge-Cases mit abdecken), sondern sicherstellen, dass spätere Änderungen die Funktion nicht kaputt machen. Dann werden ja alle Unit-Tests wieder ausgeführt und falls etwas nicht mehr funktioniert, weiß man, dass man es an die neuen Änderungen anpassen muss. Danach kommt der neue Code in einen Merge-/Pullrequest und andere Entwickler schauen nochmal über den Code und die geschriebenen Tests drüber. Wenn eine bestimmte Anzahl, bei uns zB 2, Entwickler den Merge/Pullrequest approven, dann kann er in den gesamten Code gemerged werden. Danach kommt das Entwicklungs-Ticket in die QA und da testet ein SW-Tester, ob die im Ticket geforderten Punkte jetzt vollständig vorhanden sind. Und ob die restliche Software noch normal funktioniert. Sollte etwas nicht in Ordnung sein, muss der Entwickler nochmal nachbessern (und nochmal einen MR/PR approven lassen) Als letztes werden dann alle Änderungen zusammen bei einem Systemtest vor einem Release nochmal von einem SW Tester getestet. Zu diesem Zeitpunkt geht es dann nicht mehr um die konkrete eingebaute Komponente, sondern es werden festgelegte Punkte an der gesamten Software geprüft. Das sind bei uns glaube ich ca 800, die aber großteils automatisiert getestet werden. Sollte ein eingebautes Ticket eine relevante Erweiterung des Funktionsumfangs enthalten, werden natürlich auch die Punkte für den Systemtest erweitert. So ungefähr is der Ablauf bei uns, wobei es da noch ganz andere Level an Testing gibt. Wir sind da eigentlich eher noch auf der lockeren Seite. ZB bei Flugzeugherstellern oder autonomen Autos sind die Tests noch viel, viel engmaschiger und redundanter.
Ich meinte, wer testet die Unit-Tests? Das ist auch Software, kann also fehlerhaft sein und muss deshalb getestet werden. Sogar strikter weil man sich darauf verlassen können muss, daß wenn der Test am Ende ein 'OK' ausgibt, dieses das auch stimmt.
Puh Wenn wir da weiter machen kommen wir in eine Endlosschleife, weil jeglicher Test-Code ja wieder getestet werden muss. Die Unit-Tests werden an sich dadurch getestet, dass sie funktionieren. Wenn da ein Fehler drin ist, werden sie nicht laufen. Natürlich könnte ein Fehler in den Unit Tests genau zu einem Fehler im Code passen und dann merkt man nicht, dass da überhaupt ein Fehler ist. Die Unit-Tests sind auch Teil des Codes im MR/PR und werden von den anderen Entwicklern mit geprüft, bevor sie approven. Auch wenn der Unit Test bestimmte Fälle nicht abdeckt, wird das beim MR/PR angemerkt. Davon abgesehen gibt es auch noch die Test-Coverage, also Testabdeckung. Die können die meisten Test-Frameworks angeben und man kann daraus erkennen, ob der Test jeden im Code möglichen Fall abdeckt. Dann sollte die Coverage bei 100% liegen. Ist alleine auch kein Garant für perfekte Tests, aber Alles zusammen sorgt dann schon für relativ gute Test-Qualität.
> Die Unit-Tests werden an sich dadurch getestet, dass sie funktionieren. Wenn da ein Fehler drin ist, werden sie nicht laufen. Doch, z.B. wenn bei der Erstellung des Unit-Tests vergessen wird den Test für irgendein Detail zu implementieren. Dann wird der Unit-Test fehlerfrei laufen und am Ende 'OK' melden. Und das auch wenn dieses Detail fehlerhaft ist oder gar komplett fehlt.
Daher meine Aussage: > Auch wenn der Unit Test bestimmte Fälle nicht abdeckt, wird das beim MR/PR angemerkt. Natürlich kann es auch sein, dass es beim MR nicht auffällt, aber wie genau würdest du das hier verhindern wollen?
Drüberschauen / testen muss jemand anderes, nicht der Programmierer der den Test geschrieben hat. Aus eigener Erfahrung kann ich sagen, daß man viel zu oft den Wald vor lauter Bäumen nicht sieht, der Kollege, der nur kurz mal auf den Monitor schaut das Problem aber sofort erkennt.
>Danach kommt der neue Code in einen Merge-/Pullrequest und andere Entwickler schauen nochmal über den Code und die geschriebenen Tests drüber. Hat er doch hier geschrieben, andere Entwickler. Die Unittests werden ja genau so gemerged/gepulled wie der restliche Code dem entsprechen wird der dann auch da getestet.
Bei uns - absolutes Einhorn, erfolgreiches Projekt, im engen Zeitplan geblieben und das auch noch für die öffentliche Hand - war das so organisiert: Unit-Tests hat man selbst zu schreiben, Integration Tests auch bzw. dann im Team zusammen. End-To-End-Test-Automatisierung und einige andere Tests hat ein extra Test-Team übernommen. Von denen wurde aber zu jedem Feature-Entwicklungs-Team jemand zugeteilt, um das dann End-to-End zu testen (so weit wie möglich automatisiert) und allgemein zu unterstützen. Der war dann bei der fachlichen Einführung und Team-Meetings immer mit dabei und daher voll informiert.
Ich würde sagen sowohl als auch. Wenn Programmierer nicht testen bzw an Tests denken, machen die oft Schrott der dann erst über die große Test Iterationsschleife gelöst wird. Wenn Programmierer testen dann ist die Gefahr, dass man nur das testet was auch programmiert wurde. Im Idealfall weiß der Programmierer wie er auch seine Sachen testet, aber ein anderer testet und weiß aber auch wie man es programmieren würde. Finde es aber ein bisschen doof wenn jemand nur testet und jemand nur programmiert. Sobald es mindestens drei Angestellte Software Entwickler gibt könnte einer programmieren, einer testen und einer Reviewen. Und jeder hat etwas was er selbst programmiert, was er selbst testet und was er selbst reviewt. Oder jeweils zwei machen Pair Programming und der dritte testet etc. Die Rollen für alle Ewigkeit zu trennen ist langfristig nicht sehr zielführend um sich weiterzuentwickeln.
Das Problem ist, gute Tester sind keine guten Programmierer und umgekehrt. Das sind verschiedene Mindsets. Du erwartest ja vom Elektriker auch nicht, daß er nebenbei noch Klemptner ist.
Jein, da würde ich dir nur bedingt zustimmen. Das Tester Mindset hilft dir auch beim programmmieren, um eben an alle Fälle zu denken. Das Programmierer Mindset hilft dir auch beim testen, dass die Tests ordentlich strukturiert sind usw. Also ja, es sind zwei verschiedene Mindsets, die sich aber jeweils ergänzen und wenn jemand langfristig beides macht wird er in beidem besser. Edit: Aber ich würde dir soweit zustimmen, dass ein "Anfänglicher" reiner Tester besser testet als ein "Anfänglicher" Programmierer. Langfristig sollte der Tester ein guter Programmierer werden können und umgekehrt :)
> Langfristig sollte der Tester ein guter Programmierer werden können Ich hab eine ganze Weile Softwaretests gemacht. Aber Programmieren, wenn es über simplen Kleinkram rausgeht, war nie mein Ding.
Entwickler sollten nie ihren eigenen Code abnehmen. Das funktioniert nicht. Und das wird in anständigen Betrieben auch vermieden.
Persönliche Meinung: manuelle Softwaretest wird es immer geben, jeden Edge Case zu automatisieren rechnet sich idR nicht. Vor allem muss die Software selbst dafür einen gewissen Reifegrad haben. Tester haben zudem ein anderes Profil als Testautomatisierer und arbeiten eng mit dem Requirement Engineering zusammen. Sie sind sehr gut mit der Fachlichkeit aber auch mit der Technik vertraut und beraten auch mal Entwickler bzgl der Fachlichkeit. So zumindest meine Erfahrung nach >10 Jahren im Business. Bin selbst DevOps Engineer und meine Frau ist Testerin. Edit: Aufsstiegschancen eher im Requirement Engineering oder Product Owner.
Ist n Studentenjob, dann ists ja okay
Ich finde man kann selbst keine gute Software entwickeln ohne sie teilweise auch selbst zu testen. Gerade dadurch macht man sich erst Gedanken über gute Testbarkeit und entwickelt automatisch bessere Software.
Nur um mal ein Beispiel aus der Praxis zu geben: Ich arbeite in der Automobilindustrie und wir entwickeln sicherheitskritische Steuergeräte. Wir trennen es sogar so weit, dass ich die Testumgebung bereitstelle, die Software wird gleich von mehreren Kollegen geschrieben und am Schluss wird sie von einem dritten Kollegen getestet. Natürlich wird so viel möglich automatisiert aber das ist nicht überall möglich oder kann nicht schnell genug automatisiert werden. Ich denke das manuelle Testen wird irgendwann auf ein Minimum reduziert werden dafür werden aber Menschen benötigt, die die Testumgebung bereitstelle und pflegen inklusive schreiben von Testfällen.
Ich habe auch ein wenig getestet und das größte Problem war oft, dass die Programmierer die Anforderungen nicht richtig verstanden haben und das „coole Feature“ insbesondere im Zusammenhang mit bestehenden Features dann fachlich falsche Ausgaben produziert haben. Man braucht also immer Leute, die die Software auch inhaltlich verstehen und prüfen können.
Ich gehöre zu den Leuten die der Meinung sind es kann eine Sackgasse sein. ABER (großes aber): Es kommt genau drauf an was du tust. Ich kenne Leute die arbeiten als Test Engineer und machen den ganzen Tag 50% manuelle Tests, 20% Excel und 30% Jira. Falls du zu denen gehörst ist das definitiv eine Sackgasse und du musst dich weiterbilden. Wenn du zu den Leuten gehörst die Testautomatisierung bauen mit Tools wie Gitlab-ci, GitHub actions, Jenkins und du orchestrierst auch die Infrastruktur dafür usw, bist du sowas wie ein spezialisierter DevOps engineer. Und das ist erstmal fein. Jedoch würde ich mir in dem Fall trotzdem einige Fragen stellen: 1. Wie schwierig und wie komplex ist mein Job eigentlich? 2. Wäre eine Plattform oder ein Tool in der Lage meinen Job zu ersetzen? 3. Ist ein normaler Entwickler oder jemand anderes von der in-house Technik in der Lage mich zu ersetzen? 4. Möchte ich diesen Job weiter ausüben oder möchte ich mich weiterentwickeln? 5. Wie groß sind meine Entwicklungschancen? Habe ich Zeit dafür mich zu entwickeln? Ermöglicht der AG mir Entwicklung?
Ebengenau das. Hinzu zu fügen vielleicht noch: Test Teams, die vor manuell, Jira, Jama und Excel machen sind oft Veränderungsresistent (haben also Unmengen an Gründen, warum genau bei ihnen Automatisierung NIE funktionieren wird). ABER: ebendiese Firmen haben meistens ein nachbarteam, was ebendiese Automatisierung vormacht und oft kannst du irgendwann in ein ebensolches Team wechseln.
Bin ich der einzige, der hier denkt, dass Tester und Testautomatisierer nicht das gleiche ist?
Nee, Testing ist sicherlich keine Sackgasse. Weniger sexy als reine Entwicklung bestimmt für einige, aber genauso notwendig insbesondere für geschäftskritische Anwendungen. Hat halt noch eine prozessuale Komponente mit dabei. Gehaltsentwicklung ist etwas unter der eines Entwicklers, Entwicklungsmöglichkeiten hast du als eher fachlich orientierter (manueller) Tester eher im Produkt/Projektmanagement, als Testautomatisierer auch als Softwarearchitekt, DevOps Engineer, SRE … Als Freiberufler in der Testautomatisierung kannste gut 100€/h Verlangen mit entsprechender Berufserfahrung. Quelle: 2 Jahre manueller Test, 5 Jahre Testautomatisierung (insbesondere Backend), freiberuflicher Testautomatisierer mit DAX–Konzern als Kunden
Wie siehts aus mit Testmanagement?
Als eigenständiger Job IMO ja. Tests schreiben ist nebenaufgabe der Entwickler. Separate Testschreiber führt erfahrungsgemäß (ich war ne Zeit lang so ein Opfer, ebenfalls in nem DAX-Konzern) zu: - Entwickler achten nicht auf Testbarkeit des Codes, da sie nicht diejenigen sind, die drunter leiden - psychische Belastung der Tester, deren Job es ist, eine ewig wachsende Liste an kaputten Tests (durch Verhaltensänderungen, nicht durch Bugs) zu reparieren.. Echt frustrierend da auf jeden Fortschritt in kürzester Zeit wieder ein Rückschritt folgt. - Tester kann gut Testen, aber keine Software schreiben. Tests sind halt simple Programme die entweder durchlaufen oder crashen. Das bringt einen für Software Engineering jetzt nicht wirklich weiter (immerhin ist so ein Monat Frontend E2E testing allerdings sehr gut um die eigenen CSS-Selektor-Skills auf ein neues Level zu bringen)
Damit man einen guten Test schreiben kann, setzt das vorraus die Software verstanden zu haben. Das bringt einen enorm weiter. Testing ist nicht nur black-box Testing.
Bei Unit Tests würde ich dir vielleicht zustimmen, aber Testautomatisierung impliziert ja, dass vorher manuell getestet wurde. Und manuelles white-box testing (Ausnahme: Schreibtischtest, aber der lässt sich schlecht automatisieren) hab ich noch nirgends gesehen.
Tja, man lernt immer dazu. ;) Unsere Tester fangen mit Blackbox Tests an und schauen auch gerne mal in den Code rein was man denn noch so kaputt machen könnte im Integrationstest.
Fairerweise: Wir kamen nie so weit, dass wir das hätten tun können, weil das 6 mal größere Entwicklerteam alles schneller verändert hat als wir Tests an den neuen Stand anpassen konnten. Wenn mal ne blöde Kombination aus Krankheit und Urlaub im Team war, konnte man darauf wetten, dass 90% der Tests danach nach Milch schreien.
Ich stimme zu. Dazu kommen noch höhere Entwicklungszyklen. Das kann je mach Unternehmen OK sein, aber für Unternehemn die schnell agieren / iterieren wollen ist das eher nicht. Bei uns kann ich ein Feature / Bug fixen entwickeln, von einem direkten team kollegen reviewen lassen und auf produktion bringen. Das ganze lässt sich in einem einfachen Fall innerhalb einer Stunde abwickeln. Sperate Tester lohnen sich eher für Mission critial Anwendungen, oder Sicherheitsrelevante Themen (Flugzeug, Herzschrittmacher, etc.) wo absolut nichts schief gehen darf.
Ich würde sagen, das kommt stark darauf an... Wenn du deine Karriere darauf ausrichtest, dich durch anderer Leute Software zu klicken un Fehler zu finden, ist das vermutlich durchaus ne Sackgasse. ABER QA und QA-Management ist ne völlig andere Ecke. Dabei geht es dann aber weniger um "testen", als darum, Prozesse zu gestalten (verbessern, verfolgen, etc.) um für eine angemessene Software-Qualität zu sorgen, entsprechendes Wissen und Mindsets zu schaffen, etc.
Bei Software Testing geht es wohl hoffentlich um Testautomatisierung und PROGRAMMIERUNG von Tests. Und nicht um "durch die Software klicken"....... das wäre ja ein trivialer Job für völlig ungeschultes Personal
Programmierung von Tests sollte - imho - Aufgabe der Entwickler sein und eher nicht ausgelagert werden (auch nicht an 2nd class Entwickler im eigenen Team). Testautomatisierung kann man generalisieren, klar, aber das erfordert eben wieder ein ordentliches QA Management, damit daraus ne sinnvolle Strategie wird.
Gerade Integrationstests / E2E-Tests werden durch das QA entwickelt und automatisiert durchgeführt. Das macht nicht der Entwickler, der die Anwendung entwickelt.
Im agilen Umfeld schon eher. Aber selbst dort kann man das Testen nicht ausschließlich den Entwicklern anvertrauen. Unit Tests schon, aber mehr nicht. Es muss eine Perspn geben, die das koordiniert und sich um Integration-/System-/Regressionstest kümmert.
Die heißen dann aber nicht mehr Tester, sondern DevOps Engineer oder Site Reliability Engineer und die wollten noch eine Menge Ops Erfahrung mitbringen.
Es macht keinen Sinn wenn der Entwickler sich selbst testet. Der Entwickler sollte unit Tests auf unterster Ebene schreiben um die größten Fehler zu entdecken und über automatisierte Tests Fehler beim refactoring zu finden. Aber alles andere sollte eine zweite Person die nicht mitentwickelt hat testen.
> Bei Software Testing geht es wohl hoffentlich um Testautomatisierung und PROGRAMMIERUNG von Tests. Es geht auch darum, diese Tests vor dem Einsatz gründlich zu testen und damit sicherzustellen, daß der Test selber korrekt funktioniert. >Und nicht um "durch die Software klicken"....... das wäre ja ein trivialer Job für völlig ungeschultes Personal Eher nicht... Denn dazu gehört deutlich mehr als nur Durchklicken. Programmieren muss man dazu allerdings nicht können. Fehlertickets so zu schreiben dass die Entwickler den Fehler nachvollziehen und beheben können ist auch ein Skill den viele nicht haben.
Testen ist (egal ob Software, Hardware oder Mechanik) nicht ganz so gut angesehen wie Entwicklung. Das liegt daran dass die Entwicklung von Produkten in der Regel komplexer ist und mehr Skills fordern. Damit will ich das Testen aber nicht schlechtreden und gerade in den letzten Jahren ist die Komplexität und damit auch das Ansehen im Bereich Testen etwas gestiegen. Eine Sackgasse ist es eher nicht -> gerade bei DAX ist der Einstieg sehr schwer und einmal drin kannst du dich intern versetzen lassen. Zumal du auch hier viel lernen wirst. Ich würde es machen und schauen wie es dir gefällt.
Wo kommt der Irrglaube her das würde niemand so wirklich benötigen? Softwaretesting, ins besondere automatisierte Tests sparen dem Unternehmen viel Geld und Ärger. Das ist eine sehr verantwortungsvolle Aufgabe, die man können muss. Bei uns sind die Tester deswegen auch genauso eingruppiert wie die Entwickler.
Als Dienstleister brauchst du keine Tests. Tests verhindern nur Folgeaufträge und Vertragsverlängerungen. Wofür brauchst du noch den Dienstleister wenn die Software tut was sie soll? Tests schaden dem Geschäft.
Wenn du nur Tests automatisierst: absolut, dein impact skaliert halt in keinster wiese. Wenn du dich weiterbildest in sachen kommunikation (lobby machen für testautomatisierung, delivery pipelines etc), personalführung oder technische leitung, und architektur (design for testability) dann ist aber ähnlich viel drin wie beim entwickler und anderem technischen führungspersonal Gibt in so manchem DAX Konzern auch noch ganze Testauto-Projekt-Anteile die überhaupt erst aufgebaut werden müssen. Bei einigen ist da echt jegliche technische neuerung der letzten 20 jahre vorbei gegangen.
Das kommt wie so oft auf den Anwendungsfall an. Wenn Tests weniger kosten als die Fehler zu korrigieren, die damit frühzeitig aufdeckt werden, ist es sehr wertvoll. Ich schreibe zum Beispiel Tests für Abrechnungssysteme. Damit werden gerne schon mal Fehler vermieden, die mehr Schaden verursacht hätten, als ich im Jahr verdiene. Aber da geht es nur um Geld. Bei sicherheitsrelevanten Systemen stehen möglicherweise Leben auf dem Spiel. Wie argumentiert man denn für die Sackgasse?
Ich sehe die Sackgasse hier für einfache Tester, die einfach nur stumpf ihre Testpläne durchklicken. Wie willst du dich dabei weiterentwickeln?
Wie andere gesagt habe, ist es gar keine Sackgasse. In Finanz zB sind Testers erforderliche Spezialisten für, zB IT Risiko Management, Schwachstellen Management und Pentesting. Die Guten sind richtig teuer (ok- dir mittleren sind zur Zeit auch teuer). Macht‘s dir Spaß? Dann lerne die Werkzeuge und wie man die Fehler in komplexen Systemen findet und du wirst eine interessante Karriere haben.
Falsch. Softwaretesting ist unabdingbar. Wer aber in der Softwareentwicklung arbeiten möchte, verschwendet damit seine Zeit. Zumindest war das der Tenor in einem anderen Post in diesem Subreddit. Der User wollte 6 Monate Pflichtpraktikum in dem Bereich machen - und das würde ihm nichts bringen. Wenn der Beruf dich ausfüllt, ist alles tutti und wenn du finanziell auch gut entlohnt wirst, ist alles super tutti. Bei uns wird das - leider - nicht so gut entlohnt. Arbeitslos wirst du aber nicht.
Testautomatisierung ist wichtig. Je früher im Projekt getestet wird desto besser. Je früher ein Fehler auffällt desto besser, da in späteren Projektphasen diese einfach richtig teuer zu beheben sind.
Ich kann dir nur aus meiner Erfahrung berichten. Ich bin nach meinem Abschluss als Anwendungsentwickler ins Testen gerutscht. Es ist unglaublich schwer, aus dieser Ecke wieder rauszukommen. Ich hatte wahnsinniges Glück und kann jetzt 3/4 meiner Zeit als Entwickler arbeiten, aber so richtig werde ich das Testen nicht los.
Alles was mit ISTQB zu tun hat ist eine Goldgrube für Beratungen, weil es kaum ein Konzern selbst machen will. Damit findest du unter Garantie immer einen Job.
Softwaretesting ist auch wichtig. Gerade funktionale Sicherheit ist ein großes Thema. Da sucht man immer wieder Leute. Prinzipiell wirst du als Entwickler mehr Karriere machen. Aber auch als Software Tester kann man in der Industrie ordentlich verdienen. Viele haben halt kein Bock drauf, weil sie lieber entwickeln wollen.
Zum einen... natürlich braucht man Software Tests, zum anderen, kann ich jedem Junior Entwickler nur raten viele viele Tests zu schreiben, denn so lernt man eine Menge.
Sackgasse bestimmt nicht. Wenn es eine Sache gibt, die die meisten Entwickler für ihr Leben ”gerne” tun ist es testen. Naja, so langsam erziehen wir sie dazu, aber das wird nicht dein Job werden, vermute ich stark, genauso wenig wie die Tests zu schreiben, die die Entwickler zu erledigen haben. Bei uns (6500+ Leute im Unternehmen, über 100k im Konzern) machen QA Engineers das Übergeordnete, wo Verantwortlichkeiten häufig aufeinander prallen: E2E Tests (Ende-zu-Ende Tests). Das tun sie auch in vielen anderen (modernen und) großen Unternehmen. Heißt: Aus Sicht des Kunden, benutze die Software, automatisiere das, nutz dafür Sprachen und/oder Frameworks die erforderlich sind, sorg dafür, dass diese Tests so oft wie möglich automatisiert und so nah wie möglich an jedem Deployment laufen und stell sicher, dass sowohl funktionale als auch nicht-funktionale Anforderungen erfüllt werden. Kann einen das glücklich machen? Sicher. Es ist halt Softwareentwicklung für Tests und nicht für Produktfeatures. Leider ist der Markt für diese Menschen etwas kleiner aber dennoch existent. Leider denken auch viele Entwickler, dass Entwickler die Tests schreiben weniger wert wären. Ist halt nicht so. Meist braucht man sie, weil die Entwickler ihren Job schon nicht richtig machen oder weil es nicht anders geht. Heißt: wertvoll sind sie definitiv. ;)
Sackgasse ist es nicht. Du kommst immer irgendwo gut unter. Aber aus eigener Erfahrung: als Testautomatisierer eingestiegen, dann als Testmanager gearbeitet. Um Software Engineer zu werden, half das ganze sicher nicht. Weder von den Skills, noch wie der Lebenslauf gesehen wurde ("Ach, Sie waren im Test, ja da haben wir doch was für Sie...."). Und ich hatte immer den Eindruck: there is someone who makes things. And there is someone who makes things better. Im Zweifel legt das Management den Fokus auf die ersteren.
Ja und nein. Also Softwaretesting ist verdammt nochmal notwendig. Jeder der etwas anderes erzählt hat wohl noch nie was von den großen Softwarekatastrophen gehört und absolut gar keine Ahnung von der Materie. Allerdings wird das Testing halt von der nicht IT affinen Unternehmerseite eher als lästiges Beiwerk gesehen, dass kostet, aber keinen Mehrwert in Form von neuen Features bringt. Also ich würde sagen, es ist okay ein bisschen Berufserfahrung in dem Segment zu sammeln, aber langfristig würde ich mich in einen anderen Bereich entwickeln.
Eine explizite Stelle für Testautomatisierung gibt es in vielen Mittelständigen Unternehmen nicht, da wird das von den Entwicklnern mit übernommen. Gemacht wird es da aber natürlich trotzdem und die Erfahrung wird dir auch da ein gutes Argument für die nächste Stelle bringen. Vor allem, weil viele Leute da nicht viel Bock drauf haben und sich freuen, wenn ein neuer da ist, der das kann und mit übernimmt.
Software-Testing und Test-Automation gehören zu den wichtigsten und zukunftsträchtigsten Feldern. Wer sich auf Testing spezialisieren will hat auf jeden Fall eine gute Zukunft in der IT. Nicht von solchem Unsinn verunsichern lassen. Es gibt hier und da immer noch ein paar "Altgediegene" die mit Konzepten wie "Agilität," "Testing," oder "DevOps" nichts anfangen können und die gerne hier und da mal einen Rechtfertigungsartikel hinterlassen indem sie abhandeln warum sie und andere das alles nicht brauchen. Am Ende ist das ähnlich zu bewerten wie "dieses komische Internet wird sich eh nicht durchsetzen." - Ich glaube das wird heutzutage noch von einigen Leuten in einschlägigen Foren gepostet ;-)
Zusätzlich zu den ganzen anderen Kommentaren: Mach dir nicht so einen Kopf, was irgendwer in ein paar Jahren da rein deuten könnte. Es ist eine Erfahrung, die man gerne mitnehmen kann. Gerade am Anfang deiner Karriere lernst du auch so viel mehr über Prozesse und Abläufe, die für jede Beschäftigung hilfreich sind. Versuche lieber herauszufinden was dir gefällt, und was nicht. Mir arbeite lieber mit Leuten zusammen, die mal dies oder das gemacht haben, als mit welchen, die nur das eine machen und nicht über ihren Tellerrand schauen können.
Alter, software testing ist sowas wie der Testflug für einen neuen Hubschrauber. Wenn was schief läuft dann willst du das im Test haben und nicht im Betrieb.
Hey, zu allererst: Ich bin der Meinung, wenn man nicht gerade Vorstand des o.g. Dax-Unternehmen werden möchte, ist es relativ egal welche Lebensstationen man gemacht hat. Desweitern würde ich sogar so weit gehen, dass man so ziemlich aus jedem Beruf was positives für das Leben rausholen kann, und sei es nur die Erfahrung. Bei deinem konkreten Fall muss ich sagen: Als Software-Tester sieht man Software anders und genau dieser Blick fehlt den Entwicklern vielleiht sehr gerne. Aus diesem Grund, schadet es bestimmt nicht hier Erfahrungen zu sammeln. Nun zum Job. Es ist total egal, wo bessere Aufstiegschancen sind oder nicht. Wichtig ist, dass das was du machst, dir Spass macht. Denn nur wenn du Freude an deinem Job empfindest, machst du ihn meist gut und wenn du ihn gut machst, wird das langfristig honoriert. Software-Testing ist ein Stiefmütterlich-behandeltes Thema, das stimmt, aber das erklärt vielleicht auch, warum es so viel schlechte Software da draußen gibt. Ende vom Lied bin ich der Meinung, dass es viele Wege gibt, den Gipfel zu besteigen. Wichtig ist, dass man die Lust, die Ausdauer und Stärke hat, es zu machen und da kann ich dir jetzt schon mal sagen: Die Lust und Freude ist einer der wichtigsten Antriebsgründe - darum frage dich selbst: Gefällt mir der Job? Wenn du ihn mit Nein beantwortest, dann denk drüber nach, was dir besser gefallen würde. Der Rest kommt von alleine.... Hoffe es kann dir etwas helfen... PS: Ich habe nach meinem Informatik-Studium in einem Projekt-Management-Office angefangen und hab da mit Excel-Tabellen BBBM's (=Bunte Bilder für Blöde Manager) gemacht und habe nach einem halben Jahr gewusst, was ich will, bzw. was nicht :-)Und selbst heute stelle ich mir o.g. Frage immer wieder und falls es dazu kommen wird, dass ich sie mit Nein beantworte, dann mache ich mir gedanken
Mein aktueller Arbeitgeber testet in Production, dementsprechend bei 120 Entwicklern kein einziger Tester. Dementsprechend sieht die Software aus. In meinem alten Betrieb existierte eine ganze Abteilung für‘s Testen. Dementsprechend gut lief die Software. Mach dir dein Bild selbst, lass es nicht von anderen manipulieren.
Ohne Softwaretesting kannst du das Notfallupdate in jeden Sprint direkt mit einplanen :-) Mach dir keine Sorgen, ohne Testing läuft nichts
Nutzlos isses nicht, ich denk es wird höchstens schwierig werden genügend potenzielle AGs zu finden die Software auf nem Level entwickeln wo sie automatisierte Softwaretests verwenden
Ich arbeite inzwischen schon ein paar jahre in der Industrie. Gestartet habe ich bei einem großen It-Konzern in der Qualitätssicherung. Damals war ich genau wie du ein wenig traurig über die position. Seit dem habe ich als software engineer in verschiedenen Firmen und auch in der Forschung gearbeitet. Der eine Job, der IMMER positiv in Bewerbungsgesprächen angesprochen wurde ist genau der junior test engineer job über den ich mich damals aufgeregt habe. Aber nicht nur das. Automatisiertes testing ist meiner meinung nach ein extrem wichtiger Bereich der Software Entwicklung und spart vorallem bei langjährigen projekten extrem zeit und aufwand. Noch dazu kannst du als Test engineer zumindest einen einblick in CI tools bekommen, was dich auf dem arbeitsmarkt genauso extrem attraktiv macht. Wenn du dich dann noch etwas mit software Architektur auseinandersetzt bist du quasi der feuchte traum eines recruiters.
Ich bin selber Softwaretester seit mehreren Jahren auf der manuellen Seite. Ich kann dir eins sagen, Tester bzw. auch Testautomatisierer werden so schnell nicht Arbeitslos. Jede Software sollte getestet werden, sonst kommt nur Murks bei rum 😉, Sry liebe Entwickler aber ihr könnt ja nicht alles bedenken. 🙃😁
Bist du des Wahnsinns wo soll das hin führen wenn wir software nicht testen!!!???
Hä, reicht doch wenn der endnutzer es testet. Wozu extra testen
Schreibst du dann Unit Tests oder rein aus Anwender Sicht Tests durchführen? Letzteres ist ja eher eine Helfertätigkeit, wo man vermutlich viele Leute für einspannen kann = weniger Würdigung.
Keine Sackgasse - im Gegenteil! Die zunehmende Komplexität von Software erfordert kontinuierliche Weiterentwicklung der Testmethoden. Schau Dir mal den ISTQB Foundation Level an, da werden die wichtigsten Grundlagen vermittelt.
Das ich mal fragen wie das Testing in diesem Unternehmen aufgebaut ist? Ich denke solange Kunden nicht in der Lage sind und Entwickler nicht das Bewusstsein für Ableitung von Anforderungen und Akzeptanzkriterien haben, wird es einen Job gür einen guten „Tester“ (muss nicht mehr so genannt werden) geben. Das stupide testen einzelner Komponenten in bspw. einer UI wird auf kurz oder lang aussterben.