Happy International Women’s Day Anaïs! Thank you for your time! We would love to hear a bit more about what a typical day looks like for you!
Becoming a Test Engineer (or Software Tester)
My journey to becoming a Test Engineer is pretty unexpected. I graduated from INSA Lyon with a Master’s degree in BioInformatics. I worked for 3 years, first, as a research engineer for the National Institute of Agricultural Research, a French public research institute dedicated to agricultural science, then at the National Institute for Research in Digital Science and Technology. I specialized in insect genomics (especially aphids and butterflies).
I decided to switch careers and retrain as a software tester in 2016. I didn’t know anything about this role, but I knew I wanted a more tangible job with a real and immediate application. When you test a software, the goal is clear, the software needs to work in the end. That’s what attracted me to this career.
My role is to test Fluid Topics, our software solution, to identify potential issues and ensure that it performs as expected.
When people think about software testing, they probably imagine someone doing the same tasks over and over again. Truth be told, that’s also what I thought before I got really interested in this job.
Obviously, I would be lying if I said that some of the tasks were not repetitive. But each day feels different to me and one of the things I love about this job is that I never stop learning. When it comes to the agile process, I love the fact that I am part of all the stages of Fluid Topics’ development lifecycle. From the project initiation to the release in production (and after), I have a role to play.
Finding bugs is my favorite part of the job and testing allows me to pinpoint and report most of them (hopefully!). Ensuring that the technical specifications are well-written, or that tests cases are clear is key to catching bugs early on. And the sooner we find bugs, the better it is!
We use JIRA to create stories, tasks or bugs. I also have a risk management board that I use to track the risk of each ticket. It highlights which story should be prioritized and it optimizes the testing effort. As you can imagine, I always prioritize tickets with the highest risk level.
One Day in the Life of a Test Engineer
My typical day is actually more of a typical week. I, obviously, spend a large part of it looking for bugs in our software but before getting to that, I need to prep my week. Here is what most of my mornings and afternoons in a typical week look like:
At Fluid Topics, we have a very flexible schedule. Personally, I either arrive early in the morning and leave early to pick up my daughters from daycare or I drop them off in the morning, start my day a little later and finish later.
When I get to work, I log onto JIRA and check all the tasks I’d like to work on during the day. I try to roughly allocate time for each task. I tend to schedule low-priority tasks at the end of the day so they can be carried over to the next day if needed. I like to have a precise idea of what I will be doing during the day. But of course, in an agile environment, you need to stay flexible. Software testers need to adapt all the time. Features are not set in stone and, sometimes changes must be made. I have regular meetings with the product owners to evaluate or re-evaluate priorities.
My mornings always include a standup meeting where we share updates on what we worked on the previous day and what we’ll do during the day. My first daily is at 9.15 A.M with my team and then I attend the developers’ stand-up meeting later in the morning.
Every Monday, I also attend a weekly kickoff meeting to discuss the upcoming weekly tasks. We plan and review each project with our product owners.
Once a week, I participate in brainstorming sessions or refinement meetings. These sessions are important to understand the fundamental concepts of certain features, the dependencies of each task, and the different implementation strategies. They’re also key to designing better test cases. Finally, they’re also a way for me to call attention to the bugs that could occur before coding even begins and prevent them from happening.
In the afternoon, with a majority of my sprint meetings over, I create or update test cases. An important part of the job is to understand the nature of the upcoming feature and how it will be used by the final end-user. It enables me to plan the appropriate testing methodology, define what the testing scope will be, find how to “break” the system, and reveal all the possible bugs. I use different types of software testing. My testing includes using multiple browsers, responsive modes, or multiple testing environments. When the feature includes a design then I catch up with the designers and give them my feedbacks.
During each test execution, many important questions arise:
- How would the user feel about this new feature?
- Is it easy to use?
- What if I do not follow the expected path? What if I try to do this? What if I try to do that?”
There are never too many what-if questions!
As mentioned earlier, when I find a bug, I write a ticket. I make sure that I add as much information as possible to help developers fix it. I also collaborate closely with them to define automated test scenarios.
In the afternoons, you’ll also see me run regression tests. We check that the new release did not introduce new bugs in existing features. In fact, from time to time, when we change one part of code (for example, to fix a certain bug), it causes a different function to no longer work. These tests ensure that everything works well for our clients.
Our company also puts a special effort into the security of our application. This dimension is analyzed in each story and manual tests are run regularly to check for certain types of vulnerabilities. At the end of each month, I run an automatic scan of our application with a penetration testing tool to detect any flaws that we may have missed.
And last but not least, at the end of the iteration, we have a retrospective. This session enables us to discuss:
- What went right during the sprint
- What didn’t go so well
- How we can improve our work
The typical day/week of a Software Tester is multifaceted, and this is what is great about it.
Last words of wisdom
Although software testers’ main goal is to find bugs, everyone on the team is working to ensure software quality. Software testers are advocates of good quality practices.
To become a software tester, you’ll need to enjoy collaborating with others. In fact, communication is a large part of the job. I personally spend a lot of time with Developers, Product Owners, Designers, Customer Support and Professional Services. As most of the team is based in Lyon (and I’m near Aix-en-Provence), this is done on Zoom 😊.
At Fluid Topics, we also have a great work/life balance and if you’re looking for a new adventure, I’d definitely recommend joining the team. We’re even looking for a Software Tester Apprentice.