Über unsere ausgeschriebene QA-Stelle

Wir sind stetig auf der Suche nach neuen Mitarbeitern, unter anderem suchen wir auch QA-Spezialisten.

Franz-Xaver hatte dazu einige interessante Fragen, die wir euch zusammen mit den Antworten nicht vorenthalten möchten.

Here we go:

1. Ist Testautomatisierung Teil der QA-Tätigkeit? Falls ja, welche Erfahrung in welchen Programmiersprachen/Frameworks wird hier vorausgesetzt?

Ja, Testautomatisierung ist für uns ein sehr wichtiger Bestandteil. Für die Automatisierung der Web-Tests verwenden wir primär Python 3.
Die UI-Tests von den iOS und Android Apps sind in Java implementiert. Erfahrungen mit Appium oder Selenium sind sehr willkommen, beides setzen wir auch ein. Erfahrungen in der Nutzung klassischer Frameworks wie Page Object Pattern und der gängigen Build-Tools wie Jenkins ist auch ein großes Plus.

2.  Welche Art Tests soll genau durchgeführt und entwickelt werden (Akzeptanztests, Regressionstests, UI Testing, Backend-API Tests…)?

Es werden Regressions- und Akzeptanztests entwickelt und durchgeführt. Die Entwicklung und Durchführung der automatisierten UI- und Backend-Tests gehört ebenfalls zu unseren täglichen Aktivitäten.

3. Welche Anwendung soll genau getestet werden? Handelt es sich um die ottonova App? Falls ja, sollen beide Versionen (iOS und Android) getestet werden? 

In unserem QA-Team testen wir sowohl unsere verschiedenen Web-Anwendugen, als auch unsere mobilen Apps (iOS und Android).

4. Wie groß ist das Entwicklerteam und aus wie vielen Mitgliedern besteht das Testteam? Wie viele Releases wären pro Tag zu testen?  

Es gibt mehrere Entwicklungsteams, die aus Backend-, Frontend-, Mobileentwicklern und der QA bestehen. Die Entwicklungsteams nutzen die agilen Entwicklungsmethodologien wie Scrum und sind funktionsübergreifend organisiert (cross-functional), beinhalten also z.B. auch Product Owner oder Mitglieder unserer Versicherungsfachbereiche. Aktuell sind bei uns zwei dedizierte Personen Vollzeit für das QA-Testing zuständig, und kümmern sich dabei um manuelles sowie automatisiertes Testing.

5. Richtet sich das Stellenangebot für Werkstudenten ausschließlich an (immatrikulierte) Studierende oder können sich auch berufserfahrene Personen mit abgeschlossener Ausbildung bewerben? 

Wir sprechen in der aktuellen Stellenausschreibung gezielt Werkstudenten an, weil wir in der Vergangenheit gute Erfahrungen gemacht haben. Wir sind natürlich immer bereit, Studenten einiges an Wissen und Erfahrung zu vermitteln. Natürlich haben Personen mit abgeschlossener Berufsausbildung bei einer Bewerbung die gleichen Chancen.

6. Handelt es sich um einen zeitlich befristeten Vertrag? Wie hoch ist die wöchentliche Arbeitszeit? Welche Weiterentwicklungsmöglichkeiten habe ich in Ihrem Unternehmen im Bereich QA?

Wir sind bei allen Punkten flexibel und gehen gerne auf die Wünsche und Vorstellungen der Bewerber ein, das betrifft sowohl die Wochenstunden als auch die Vertragsbefristung. Werkstudentenverträge sind standardmässig auf ein Jahr befristet und besitzen einen fixen Stundenlohn. In unseren Arbeitsverträgen für eine Vollanstellung ist immer eine Probezeit von 6 Monaten vorhanden. Eine Festanstellung nach einer Werkstudententätigkeit (oder auch Praktikantentätigkeit) ist immer unser höchstes Ziel. Die Weiterentwicklungsmöglichkeiten sind je nach Mitarbeiter individuell, wir unterstützen bei der Verwirklichung deiner Ziele wo wir können.

Analogies between physics and IT project management

Could physics be helpful in solving the problems of IT project management?

Naturally! Physics is after all the science that describes how the world around us works. Actually, any domain – IT project management included – that belongs to our universe must exhibit regularities which implies there will exist certain laws that allow describing it, therefore also be to some extent under the scope of physics.

“Okay, but why would anybody want to spend their time seeking analogies between project management and physics?” one could ask.

The answer is, that tools which could be helpful in solving problems that seem too difficult in the project management (PM) world, might be available and well known for physicists. In short – rummaging in the physicists toolbox might produce tools usable in IT PMs daily life.

This is why we would like to dedicate this article to show some of the analogies between the two worlds and – using some of them – to stress the importance of quality assurance in the world of IT.

Einstein supposedly said: “everything should be (made) as simple as possible, but not simpler”, let us therefore try to simplify the view of an IT project by making an analogue in the world of classical physics: namely, driving a car. Not to oversimplify things and not to draw false conclusions, we will have to keep alert for when the analogy becomes too far fetched and holds no more.

Before we enter the car, when wanting to go from a point A to point B, we would possibly have a look at the map, check the traffic to make sure we can make our travel in the expected time, take into account the terrain on our way, prepare the money for the gas and other expenditures, make sure if the car is in technically good driving condition and whether what the route demands of our vehicle meets what the car can deliver, then ‘simply’ go into the car and drive from A to B.

‘Nothing more to it’.

How should we translate this picture into the IT-world? What is the car? Who’s the driver? What is the road?
Let us start with the project and what it means to complete the project – since it involves the entire team cooperating on achieving a set goal – it would equate to having the car, its passengers and luggage reach a desired destination.
The PM – steering the project from point A to point B, at the same time trying to assure that the plan of making it on time and within given budget – seems to be an obvious choice for the driver.
The developer team’s analogue is the car’s engine – for those actually move the project/car and induce the changes in the surroundings/project state (what could also be called “the state” of the car) at the cost of burning fuel/budget.

This time, let us try to make one step further and ask some (rather rhetorical and sometimes absurdly sounding) questions:

  • when driving the car, would you consider having your eyes open?
  • what is the largest distance that you would dare to drive a car with constantly closed eyes (or, how long would you dare close your eyes when blinking them)?
  • how powerful a car would you dare to drive if your eye-blinking speed was restricted when driving it?
  • would you dare to drive if you were to only look through the side window?
  • how often would you consider stopping to verify all the car’s surroundings and its technical state?
  • would you risk driving your vehicle without doing required inspections and maintenance?
  • would you risk driving your vehicle using the incorrect gear and on too high engine-RPM?

‘Okay, well, that really sounds rather absurd to ask … any of the questions actually. What’s the point?’.

As it will soon turn out, even those ‘absurd’ questions can provide insight into project management. If that will prove to be so, this will also mean that some difficult-to-solve problems from one ‘world’ might be actually fairly simple in the other ‘world’.
Let us then see, how the ‘absurd’ questions translate into the IT-project-management world…

  • when doing an IT project, would you consider verifying how the software operates and evolves?
  • how many software releases would you dare to make without knowing the how the product works (or how much new functionality would you dare to release without ever checking it)?
  • how big a developer team would you dare to have if you had only very scarce quality-assurance resources?
  • would you dare to continue a project if the quality-assurance was focusing not on the most important features?
  • how often would you require your quality assurance team to test all possible product features?
  • would you risk running your project without checking the technology stack and ever adjusting it?
  • would you risk running your project requiring the developers not to use available languages, but having them develop everything from scratch?

Answers to those questions form some of the basic truths that should be known to experienced PMs:

  • Testing is necessary in order to know where the project is – what the software actually does.
  • There is a certain proportion between the amount of developers and testers that should be on a team.
  • Testing should focus on the most important features.
  • It does not make sense to test everything all the time.
  • Not doing thorough testing at reasonable time intervals introduces unnecessary risks.

One of the differences between the IT world and the classical physics example posted above is that actually looking at the road costs us seemingly no time at all. The information flows in in a steady stream. That is not so in the IT world.

Not only performing tests requires a given amount of time (and effort), the same applies for moving the car. Namely – developers need to commit code changes, those usually do not happen with every single character of code changed – as only specific units of code actually make any sense at all for the computer.

We can already see, that two things change in discrete amounts – the information and the time required to change that information. Discrete amounts are known in the physics world under the name of quanta.
Entering this realm – the quantum physics domain – will be the topic of another episode.