4 Tips for Solo QA Engineers
I have one year of experience as a QA Engineer at wope.com. I would like to share the lessons I learned from my mistakes and the useful methods.
Adapting Quickly to Different Tasks
One of the most important topics for me is adapting to different tasks that I have to handle during the day. Therefore, I try to leave a few hours every day to adapt and keep track of work.
Some days I take one or two-hour breaks to attend team meetings; I examine newly opened tasks and plan when they will come to the test and which scenarios I will test. Although it is not always possible, I feel safer if I have free time blocks. When I can plan ahead of time, I get up knowing what tasks I will complete and spend the entire day focused on them.
Uncertainties often negatively affect my focus. So, I transform these into tasks and plan my days accordingly. I deal with these tasks by putting them in order of importance.
Tracking tools
It’s become much easier to follow processes now that I’ve added the “In Testing” state to the workflow for development teams.
We use the Linear.app, which provides a smooth user experience. I inserted “In Testing” the state after the “In Review” step to the development process through the tool. . I created a simple filter and added it to the issue tracking tool, so now I can access the tasks in the “In Testing” step with a single click. I implemented this for frontend and backend teams. After testing, I open it as a sub-issue and make the necessary assignment for any bug or defect.
In this way, I also record which part has a problem. Then, when the error is solved, I test again and set the status as “Done” if there is no problem.
Quality is my responsibility.
Think the opposite of what you mean by the title. Quality is a process that is nearly impossible for me to control on my own. So, even with a QA team, it is hard to manage every detail.
Teamwork. I am fortunate in this regard; everyone in our team has quality concerns regardless of experience. The neatest and least defective work is that which is planned correctly in the first place. The scope of action is determined accurately for all possibilities, and the job is explained to the developer clearly and with details… It’s a pretty long list. As a QA Engineer, I don’t describe myself as responsible for controlling the output. If I can make any process improvements, I share them with the team, attempt to ask questions and clarify, analyze the designs from the user’s point of view, and discuss the situations I notice. I do my best,
I try to stay in touch with the teams to be involved in this process; I take care to attend the meetings and be involved in the process.
Be Alarmed
In the first weeks that we passed to the sprint, I was trying to speed up from time to time with the rush of not being able to catch up with some work. So I tried to complete as much work as possible in a given time.
After a while, I realized that while I was focused on creating value, I was now focused on getting the task done. The important thing should not be the result but the accuracy of the actions that produce the result. When I examine and test the process with a detailed view, I know that the results are much higher quality.
If you don’t have a teammate, you may not notice that you are creating a fuss and being sloppy at first. Defining the steps and finishing the task before beginning the work will always contribute to this process.
