Was benötigt ein Softwareentwickler um ein guter Testautomatisierer zu sein
 

Hallo zusammen,

ich mache für mich ein kleines Projekt und zwar geht es um die Frage was ein Softwareentwickler benötigt um der "perfekte" Testautomatisierer zu sein/werden.

Grundsätzlich stelle ich mir die Frage welche Sprache und Tools zum einsatz kommen. Meine Vorstellung bzw nach Recherchen im Internet bin ich zum entschluss gekommen das der perfekte Testautomatisierer auf jeden fall Java und JavaS***** beherrschen sollte, da das die Sprache ist mit der die meisten Firmen arbeiten.

Dann stellen sichi die meisten vor, dass wenn ich von einem Entwickler spreche das er sozusagen dick, brille und im Keller sitzt. Das ist heute natürlich nicht mehr so!
Dieser sollte Kommunikativ, Teamfähig und aufgeschlossen sein, da viele Firmen auf agilität setzen und zumindest diese Fähigkeiten benötigt werden.


Gibt es von eurer Seite aus noch Punkte die ich hier aufnehmen könnte ?


Viele Grüße und einen guten Start in die Woche

Wenn du in der Jobbörse der Arbeitsagentur nach Testautomatisierung suchst, findest du in vielen Stellenbeschreibungen genaue Anforderungen an den Bewerber, unter anderem auch die verschiedensten Tools

Der Softwareentwickler sollte in der Lage sein, seine Software selber zu testen.

In der Regel ist es so, das erst die Test geschreiben werden, welche die Anforderungen an die Software abtesten und dann erst die Software - ist bei uns in der Firma und bei vielen anderen die Regel.

Es klingt so, als wäre das sehr theoretisch. Ein Softwareentwickler MUSS kein Teamplayer sein, er MUSS auch nicht kommunikativ sein.

Die Tools variieren sicherlich, die Aussage Java und vor allem JS zu können halte ich für gewagt. Er muss aber natürlich die Sprache kennen. Gleichzeitig sollte er aber auch die natürlichen USE-Cases kennen, unter denen die Software betrieben werden soll. Habe ich z.B. eine Webanwendung, muss ich Menschen simulieren können.

Müssen tut man ja in der Regel gar nichts.

Ich arbeite im Bereich der Softwareentwicklung und leite selbst ein Team aus Business (Ich), 1x iOS, 2x Android, 2x Backend, 2x QA Engineers an.

Jeder dieser Software-Entwickler muss als Teamplayer arbeiten, denn die Realität ist, dass du im Job als Entwickler oft von der Geschäftsseite als Team einen Themenbereich verantwortest. Dieser kann sehr allgemein sein, wenn das Unternehmen kleiner ist oder sehr speziell, wenn das Unternehmen größer ist und mehrere Software Teams anstellt.

Schlechte Ingenieure arbeiten an Themen, die Sie spannend finden und als Agenda neben den Teamzielen puschen wollen, um irgendwelche hippen Frameworks zu lernen und sich dann in den nächsten Job zu stürzen.

Gute Ingenieure verstehen den Verantwortungsbereich des Teams, verstehen das Problem, was es zu lösen gilt und verstehen, was wichtig ist und was nicht. Sie arbeiten mit Designers, Geschäftsleuten, anderen Ingenieuren Hand in Hand und wissen iterative "agile" Arbeitsmethoden anzuwenden.

Was den aktuellen Jobmarkt angeht als QA, muss er natürlich die Technologien & Konzepte verstehen, die im Unternehmen Anwendung finden. Als kompletter Quereinsteiger sind Sprachen wie [Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...] sicher von Vorteil.

Test-Driven-Development ist aktuell eigentlich Gold-Standart in modernen Unternehmen, muss es aber nicht sein.

Interessante Talks zu dem Thema hat der Kanal [Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...].

Hi,

ich würde mit Unit-Tests starten, welche in der jeweiligen Sprache der zu testenden Sprache geschrieben ist. Danach mit einer Skriptsprache wie Bash/Powershell und Python weitermachen. Je nachdem was du Testen möchtest, ist es sinnvoll z. B. für Web-Apps ist die BurpSuite echt super oder Selenium um einen Browser zu Emulieren.

Nur ein Buch und Zeit für selbiges

Roy Osherove : The Art of Unit Testing ( [Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...] )

Wer nicht von Anfang an (=TDD) darauf achtet, dass der Code Unit-testbar ist, wird am Ende nicht unit testbare Grütze haben und sich mit kaum handlebaren Intergrationstest und manuel Tests herum schlagen.