For some people, there comes a point when you start questioning your career choices, a kind of job midlife crisis. That was my case. Change and learning something new have always been important to me. That’s why I’ve also undergone a small evolution from a professional point of view: from an account manager in an online advertising agency, to project manager, to product manager in online marketing and finally to a CRM manager. But somehow, I never was 100% satisfied.

What interested me more and more with every year of professional experience was the look behind the scenes of what happens in the frontend. I’ve always been good at asking questions – to the chagrin of my colleagues. I asked my network who would hire career changers in the IT industry and that’s how I ended up at QualityMinds.

After the Meet the Minds Day, where I had to put my tester gene to practice, it was clear: I want to be a software tester! I can finally question things with a critical and examining eye – and everyone was happy about it. During this introductory phase, I got to know new tools and gathered initial tester knowledge. For example, I made a mind map with which I was supposed to record my test strategy for the test object. I ran my first “real” test right away, using Excel as a bug reporting tool to document the bugs, take screenshots, and write down the test steps for the developers to reproduce. After the bugs were fixed, they were retested.

I have found that Excel is not that unusual as a reporting tool. In one of my projects, the project environment was not yet “mature” enough to deal with professional tools. Therefore, the existing test suite was prepared only in Excel and the bug report was made with JIRA, which was also the only way to be able to communicate with the developers based in the UK. New test cases were not recorded in the tickets (or only rudimentarily), which also made the regression test not always easy. The structure and the recording of metrics in terms of testing had to be established in this project first, which gave me the freedom to go my own way as an explorative tester. Therefore, unless the smoke tests on the pre-production environment were pending, I usually used a session-based approach, which enabled me to test a specific area of ​​the software in a very focused manner.

In another project, I got to know the opposite: there were fixed rules for (almost) everything. In addition, I had my first points of contact with agile working methods there. In our daily we discussed what we had done the day before, what was due for today and whether there were any impediments. The workload was processed in defined 2-week sprints. At the end of the sprint, the developed features were presented and discussed during the system demo. These have always shown well whether our estimate of the features was realistic and whether everything could be developed and tested. For me as a tester, the requirements were clearly defined by the acceptance criteria that were stored in the stories in JIRA, which helped me in the test design. In addition, I was able to take further information from the technical concept and use it for the test concept.

In this project, all test cases written by me were documented in the “Aqua” tool, linked to the corresponding requirements in the tool and then compiled and executed in a test scenario. In this way, it was clear to me and the product owner and management which feature was tested with what intensity in which environment. This trackability was supplemented at the test case or feature level by the tool’s own reporting function, which can evaluate and graphically display a wide variety of metrics.

Another valuable experience was being able to exchange information directly with the developers, since we worked together in a Scrum team. By regularly setting up fixed time windows in which I, as a tester, tested a certain feature and a developer answered my questions and comments directly, not only could the quality of the software be improved quickly, but also the thought process of the other could be better understood and thus collaboration was more productive.

In order to make it easier for me, as a career changer, to get started with testing, my colleagues not only explained a lot to me ad hoc before starting the projects, but also gave me a very helpful and practice-oriented training course in the form of the “Testing for non-testers” guide. Test types, test procedures, test management, test levels and software development cycles: so many new terms that I gradually got to know and used during this training. In addition, it always helped that my colleagues showed me the parallels from my previous jobs, because quality assurance was important in all jobs. And testing is nothing else than improving the quality of the product. The quick start in my first customer project also helped to put what I had learned into practice – in addition to cramming for the ISTQB certification.

Looking back, I can say that when I finally took the leap to change careers, I did everything right and was lucky that I got the opportunity to do so at QualityMinds. I learn more every day, not only because I keep getting to know new contexts, from banking software to a platform for rental vehicles, but also because my more experienced colleagues are willing to share their knowledge with me. In the meantime, I have built up a solid basis from explorative, technical testing, test management and test design, which I can constantly expand. And currently I can get a taste of test automation and deal with Gherkin, Java and Cucumber – so it never gets boring.