Melanie Hanson is an associate Software tester at Audacia. Mel joined Audacia's academy programme in 2020 and has since become proficient in software testing, familiarising herself with various concepts and collaborating with her development team to deliver high-quality software to clients in a variety of industries.
Having spoken with Mel once about her career journey and ambitions, we’ve decided to share a little bit more about what it is a software tester does day-to-day, across a week period.
Monday
Every two weeks on a Monday we will have a sprint meeting. At Audacia, work is completed in 2-week intervals known as ‘sprints’. Here, we work toward developing and testing the most complete version of a piece of software, ready for further feedback from the client.
Our sprint meeting helps us and the client arrange when tasks will be carried out, as well as giving an opportunity to reflect on the work that has been completed in the previous sprint in the form of a demo. The demo gives us the chance to demonstrate the product's core features and functionality to the client.
Planning is also a big part of the sprint meeting, as you will usually plan all the work that's going to be completed in the next sprint.
There's a little bit of a retrospective too, which involves looking back over the last two weeks of work and discussing what went well and what didn't go well. Evaluating the sprint in this way allows the team to decide what improvements are going to be made moving forward. These calls are also an opportunity for the client to bring up anything that they wish to address with the development team.
We always aim to have all work completed within the same sprint, which means that software has been developed and tested by the internal tester by the end of the two weeks. This work then goes off to the client at the end of that for UAT testing where the software can be approved before running to live.
The structure of the sprint meeting can vary project-to-project and some projects may choose to have separate meetings for the demo, the planning, etc. It’s really just down to what the client and the development team agree is the most sustainable.
Having these meetings are really valuable in clarifying work schedules and requirements early on and are a great way of getting everyone on the same page.
Off the back of the sprint I’ll usually get to work on running some tests on the software. In this early stage of the week, I'm reviewing the work assigned and creating a general priority list for each task.
It makes sense to test the highest priority items first, so that's what I do after the planning meeting; I run through the general requirements and then decide which items I will start writing test cases for first.
When writing test cases, you include everything you need to do to test a specific aspect of the work. Here I’m thinking about testing each individual step that is required to carry out a requirement, down to the lowest level of granularity.
The test case itself would be an end-to-end version of what you would need to do to test that requirement. If you were testing an e-commerce site, for example, this might be a case of:
- Login to user account
- Search for a product
- Select the product
- Ensure that there’s an add to basket button
It is important to ensure that all the necessary test data is set up ahead of time and, in this case, the environment has an actual product that you can view so that you can test the functionality of the basket feature.
Organising my time this way means that by the time we’re reviewing the QA environment — where the software is tested in similar conditions to a production environment — it’s more a case of running through everything in order and double checking that the requirements have been met.
After work, some of us from the office will go to the weekly pub quiz, which starts at 8pm. It's a great way to meet other people outside your team since you can get quite engrossed in your work throughout the week. It's always a very well attended event with teams of 8-12 people. The promise of free pizza for taking part is always a draw-in too!
Sadly, we’ve never actually won yet but we’ve come a close third before 😬
Tuesday
The majority of my Tuesday mornings will be spent picking up where I left off on Monday and running some tests. A lot of the testing that I do in my role is manual testing which, as its name suggests, requires the tester to manually test the software without any support from tools or scripts. When I’m testing I’m essentially checking that the given software works that way it’s supposed to, according to the requirements outlined by the client.
At this initial point in the week, I’m usually identifying a lot of ‘bugs’ with the software. Many people consider a bug to be something that is 'wrong' with a website or a piece of software, but you can also have a bug with requirements if something is missing, or if there is a contradiction in some way.
I dedicate time each week to developing automated tests, usually on a Tuesday afternoon. This involves writing code that can perform the tests rather than manually following the steps in a test case. I'm usually writing API tests in C# or UI tests in TypeScript.
There are many benefits to writing automated tests, in particular, that it allows us to get feedback quickly on any breaking changes, and it cuts down on the amount of time spent running manual regression tests.
Manual regression testing is performed at the end of each sprint, which involves running tests in every area of the system to ensure that new functionality developed in the sprint has not adversely impacted any existing functionality. As you can imagine, this can be quite a time consuming and tedious job! The aim for my current project is to automate as much of the regression pack as possible so we can cut down on the manual testing time and have greater confidence in the software prior to a live release.
On Tuesday afternoons myself and the Project Manager will attend a ‘Requirements Definition Call’ with the project manager on the client’s side to run through the upcoming work in further detail and scope out any further requirements.
By this point in the project I’ve usually already received a plan of what the piece of work should entail, but this call really gives me the chance to clarify and further my understanding of the software that I’m testing and raise any questions regarding the requirements early on in the process.
The benefits here are clear; raising queries early on means that any potential issues can be tackled early on in the testing process, saving both the client and ourselves valuable time and resources. Internally, it also means that when the developer gets a piece of work, there’s not as many questions and the root details of the requirements have been satisfied.
Wednesday
In the middle of the week I will have an estimation session with the whole Audacia project team where we’ll go through each card and estimate how much effort we think these work items will require in the sprint. Cards represent individual work items or user stories that team members pick up as the sprint develops.
These tasks are estimated using an agile software development concept known as the Planning Poker; here we’ll use numbers to estimate how much effort we think tasks will require. The numbers used to estimate are based on the Fibonacci scale, which is a sequence of numbers that can be attached to each item. The higher the number assigned, the more time it is estimated that it will take to complete.
Defining work items in this way is a really useful and logical way of how much work you can take on and ensuring that your estimates are both accurate and achievable. Every project then has its own velocity which is a calculation of these points that measures how much work a time gets done in a day.
Due to the pandemic, these meetings are now almost always conducted via a Teams call with your team, however I still find these sessions really helpful as they allow me and my team to openly communicate our thoughts regarding workload. We will, for example, share our estimations at the same time so that our decisions are fair and unbiased.
Thursday
As part of our sprint timeframe, we typically dedicate two weeks to internal testing. During the first week of a sprint, there are usually many changes because you are generally finding bugs and fixing them. Having said that, towards the end of the first week and the beginning of the second week, things are beginning to stabilise.
Throughout this later phase, I tend to make little revisions and revisit the work that I've already done.
Of course, the specific tasks shift a lot depending on at what point we are in in the sprint. In the beginning of the sprint, a lot of work goes into writing test cases for all the cards and ensuring they're all fully scripted so they'll be ready for the QA environment.
When I receive a release to this environment I’ll continue testing as well as liaising with developers about the status of the work.
Overall, it's a cyclical process, which involves retesting bugs, rewriting test cases, and making sure everything passes. Even with this level of familiarity in my work, I never get bored as each part of this process can provide a new, unexpected challenge.
Friday
In addition to my testing duties, I'm also a member of the CSR committee at Audacia. Committee meetings take place every other Friday where we will have lunch (we prefer to order in) and discuss plans and progress.
Some of the areas that we focus on are Social Responsibility, Diversity & Inclusion, as well as Environmental issues and Charitable Giving. The responsibilities mostly relate to how Audacia can be more socially and environmentally responsible.
Each month, I also participate in a meeting with the other testers at the company. This QA catch up is an opportunity for all testers, junior and senior, to share their insights about testing and discuss any interesting parts of the projects they've been working on.
Working from an agenda, we’ll discuss a variety of areas pertaining to our role and share knowledge about how we’ve overcome challenges in our work. The event is usually quite informal, so everyone feels comfortable to share problems they might’ve been dealing with.
Because we’re often separated in our project teams most of the working week, meetings like this are really important in sharing knowledge; often, someone might find a solution to a problem they’ve been dealing with from this meeting.
For example, there was one instance where someone was needing to test a file upload tool for a project and another tester was able to advise them on a command that could be run to quickly generate the file size and type that was required. It was a super useful solution that has really helped others at the company get their test data up-and-running.
Audacia is a leading software development company based in the UK, with headquarters in Leeds. Find out more about what it's like to work here and our current open vacancies on our careers site.
Technology Insights
