In case you are planning to change your career into software testing and ever wondered how the typical day of a software tester looks like you can read about mine.
My typical day as a remote software tester depends on two things. What type of project I work on and where we, as a team, are in the sprint currently. All days are similar in the fact that I have a lot of meetings:
- with the team,
- the client, and
- the devs or the designers when software testing.
At least thanks to corona, all my meetings are online which saves me a lot of time. I hope it will stay the same even after C-19.
There is a certain rhythm to working in software testing depending if it is a waterfall or agile project. In a typical waterfall project, the testing comes at the end. That can make the project quite expensive though because a lot of changes might be needed at once. I am currently working in an agile team, so the testing is continuous during the development. There is a specific life cycle of our product (web app in automotive) development. That determines the software testing life cycle and my typical day as well. It brings its owns challenges, for sure, that can be always solved.
Software tester in an agile team
An agile team works in sprints. That is a time frame for specific software product feature creation. Typically, the sprint lasts 14 days and goes from Wednesday till Tuesday. The reason is that it gives you enough days to work around the main events in the sprint. Those are:
1) sprint planning,
2) refinement,
3) sprint review, and
4) retrospective.
I also have a defect meeting for bugs triage every Wednesday with the client and the product owner.
We plan and review each sprint with the client. That way the team knows what needs to be done in the next two weeks. We also know if we finished everything we wanted to do.
We can plan the sprint only with refind storied. Refinement is the process of understanding the features which will be developed in the future. We give points to the stories and tasks based on the difficulty of their development and testing. The product owner saves the stories, tasks, and bugs in Jira in form of tickets. Then he/she prioritizes the tickets in the backlog based on the roadmap of the product development. There are also epics in the Jira that describe the business and legal reasons for the features. The product owner breaks the epics down into stories. At the end of each sprint, there is a retrospective. It helps the team evaluate what went well during the sprint and what can be improved.
The beginning of software testing
Wednesday start
In my current job, we plan our sprint on Tuesdays that means the last day of the previous sprint. On Wednesday, there usually are no stories or tasks to test because the devs just started to work on them. That is why I use Wednesdays for explorative testing. I take the last version of our product and just go through it looking for some bugs. I do not take pleasure in finding bugs but you know what I mean :-).
Our product needs to fulfill certain legal and business criteria as well as work and look good. If I find a bug or some kind of a deficiency, I write a bug or task ticket in Jira. I usually write a task when it includes a feature that has not been worked on yet. On the other hand, I write a bug ticket for already developed features with defects. When I encounter some ideas for improvement, I leave those for a special meeting with the client. I also make a presentation about it. That way the client has the opportunity to decide if they want to include that feature/improvement. The devs can provide input about its technical side as well.
Lately, I have been focusing a lot on accessibility software testing. If you have not heard about it then you should check it out for sure! Accessibility software testing is important to allow disabled people full access to the internet. It is also a legal duty in some countries (USA, Canada, Norway since 2021, and EU since 2025). This problem is similar to the past when staircases were everywhere. People in the wheelchair could not access those places. Just imagine for a minute, how horrible it must have felt for them. Then some smart architects included elevators and legislators inserted those rules into laws. This same is now happening with the internet. Thankfully we can easily change things for disabled people online. I will write about this in more detail in the future.
So yes, the first Wednesdays in the sprint are for explorative testing and improving my cypress skills. It is the perfect time to check the app and see where we are at with the cypress tests. I usually need to check whether the code coverage is optimal. We also have a meeting of all QA engineers in the company. We share knowledge and learn from each other. I find it very useful since we each work on a different project.
The middle of software testing
Thursday, Friday, Monday get ready
The next three days are usually about bugs’ validation and dealing with the client regarding those bugs. We deliver our app to the client before its integration into production. So some bugs show up later. It is a big project and we work on only a smaller part of it.
Our client has their TQA department that does software testing for the integration and regression. That means they do find discrepancies. However, a lot of times those are not bugs. Sometimes those are features that our team will implement in the future. Consequently, I have to explain to TQA this fact. Thankfully, I have a legal background which helps immensely when building my case :-). The same process applies to the client.
If the issue goes beyond my technical knowledge, I have to find a developer to help me out. Thanks to being curious and a quick learner, I have already picked up a lot. Many times I can help the client/TQA myself.
When I establish that it is a bug, I have to set up its severity based on its technical difficulty and time needed to have it fixed. After that, I send the bug to our product owner to have it prioritized in the backlog. The PO knows (or should know) its importance the best. The only exception is the blocker bug. That is a bug that is stopping the app from working and needs to be fixed immediately. In that case, I post it into our team slack channel. I make sure one developer takes care of it immediately.
Tuesday full speed onwards
Around Tuesday the second week, my main work starts flowing in. This is the time when the devs have finished some of the stories/tasks and I have to test them. I use all different types of software testing- mainly functional and visual, regression, smoke, and integration testing. My testing includes using multiple browsers, responsive modes, and multiple testing environments. I have to test some features on localhost. When the feature includes a design then I have to communicate with the designers. We test it together to make sure it is right. This part of the sprint gets quite hectic. Not only I have to do all the testing but the bugs also keep coming in. I have to be a great multitasker to prioritize my time well. There are some tools that I use to achieve that but will mention them some other time, so stay tuned!
First Tuesday in the sprint is also our first refinement meeting with the client. That is where we:
- look at the stories and tasks from the backlog,
- ask questions about them,
- assess their difficulty by story points, and
- get them ready for a future sprint.
This way I work for the rest of the sprint. I test deployed version of the features. If everything works well and looks good I:
- merge the branch,
- write a testing comment in the Jira ticket,
- move the workflow of the Jira ticket to development done and assign it to TQA.
The end of software testing
Monday heart attack
Monday before the end of the sprint is usually a crunch time. I have to test all the reminding tickets. Running a smoke test for all the stories and tasks I worked on that sprint comes next. Then I write a presentation for the review about all the tickets we have worked on that sprint. I have to keep in mind which tickets have been finished and which will spill over into the next sprint. Yes, it can happen that some of the stories/tasks/bugs can not be finished within one sprint. We also have our second refinement meeting on Monday.
Tuesday catch a breath
Tuesday is the last day of the sprint. It starts with the review of the current sprint. One of the developers presents to the client what we have achieved during that sprint. When we finish the review, the planning of the next sprint starts.
Together with the product owner, we choose which tickets need to be worked on next. As a software tester, I do not have that much of a say on what features will be developed. I understand the software product from the user’s, business, financial (and also legal) side.
The technical side is usually harder for me. That is also changing as I am learning to understand the product’s technical aspect. It is funny that way. When you are curious you can’t resist but to learn how the product works. Especially, when you work with it every single day. Imagine you were playing with your favorite app every day. You would get it after a while even if you did not want to. But it certainly helps that I truly want to understand it.
Tuesday afternoon is the second sprint planning session. The devs break the stories and tasks into subtasks and ask questions. The success of the refinement and sprint planning depends mainly on how the people write the tickets. The last thing on Tuesday is the retrospective. We talk there about what we liked and disliked in the current sprint. After that, we come up with new ideas on how to improve our work. With that, the sprint is dead, long live the sprint! Yes, the next Wednesday the next sprint begins.
I also have a couple of other meetings during the sprint. These include:
- a tech meeting with the devs where we learn the technical stuff,
- a meeting with my dev coach regarding my career,
- my mentor for product ownership,
- and mentoring group one for load and performance testing.
So there you have it. The typical day of a software tester is quite versatile. However, this versatility is repeating itself thanks to the app development life cycle. This allows me to track my improvement between the sprints. It also allows me to come up with ideas on how to improve our internal systems. I hope this will help you to make the right decision whether you would like to work as a software tester. You can check it here. Let me know what you think in the comments below.
Comments are closed.