#QConf2016 - Software Quality

Since last year, the individual IT areas have made significant progress. Across the Group, this more or less reflects what I am also tracking in the market: There are areas that are still in the early stages when it comes to agile software (quality) processes, while others, like us at otto.de, have been living and changing them for several years.

The QConf in numbers:

750 feedback slips
70 active participants
17 hours of software quality
16 speakers / workshop leaders
4 sponsors
4 orgs
1 huge room

Each area thus faces different challenges and yet one thought makes us all the same:

"How can we support delivering high quality software to our customer?"

We looked at this question from different perspectives, so there were topics like "What soft skills do I need to drive quality?", "How do I get the right mapping into the test pyramid?", "What test management tools do I use and for what?", "What does the microservices trend do to us?" and "How do we succeed in making a change to agile software development methods?".

By means of lectures, workshops and time for direct exchange between the participants, we were not able to find a universally valid solution. However, we see that a close cooperation with requirements and implementers demands a lot more from us QA people than it did a few years ago and is indispensable.

The question "How? I have to be able to read code now??" was particularly controversial. For the attendees who are currently in a pure QA team, the question has tended not to arise until now. Unless they are responsible for test automation and code themselves. Thus, the confusion about the question alone was quite high for some participants.

Participants from cross-functional teams, on the other hand, agreed that being able to read code is a much-needed skill. One of the big advantages of this is that it makes it much easier to talk about test levels with the developer. Both roles understand better where something is adequately tested, and a QA person has to have programming skills to do that.

I understand that this realization at least unsettles quite a few testers. After all, this is a field that has not been a tester's task for a long time, and has even been deliberately prevented. In the QA environment, the thesis has long been held that objectivity is lost when the content of the code is known. According to the motto: "Developers only test what works anyway! At that time it was only logical for quite a few that QA people must not deal with the code, because otherwise you run into the same problem. For those who still subscribe to this thesis, I recommend practicing TDD. Roughly speaking - for those who do not use this approach yet: You first write automated tests (from a requirements perspective) and then create and modify the program code until the test becomes positive.

"So are developers also QAers or the other way around?" Yes and no. Both should have broad knowledge of their respective expertise and be able to apply it. However, I am opposed to a complete role reversal of developer and QA. In depth, the two differ because they simply have different perspectives on the software.

The question of the test pyramid was similarly multi-faceted, with many different opinions and views coming together. It should be noted that it must be clear what kind of system is involved, and the individual test levels can then be applied to this (e.g. the entire otto.de store is one system, but it consists of many small systems). But on which of these levels does it make sense to test this or that requirement? There is no general answer to this question. At least I would like to share at this point that it is correct to approach from the customer's point of view and at the same time share that this should not necessarily lead to testing exclusively at the top of the pyramid.

I found it particularly exciting that many want to make a difference, just often don't know how to start or stay on. Much has been set in motion since last year's conference and great progress can be seen. There was also a lot of talk about change this year. And even at this point, there is no ideal solution path to shimmy along. However, one thing has already been internalized by most.

"I have to start change with myself!"

Since change never stops, I am glad that this format will further promote the exchange of us QSers and that we can continue to learn from and with each other. Maybe then we can philosophize about questions like "Is test automation really a programming/developer activity?" or even "Does very good monitoring completely replace functional testing?".

See you next year,

Your Diana

P.S.: Another personal view on QConf2016 has been published by attendee Katja in her blog.